[ovirt-users] Local and Shared storage in same datacenter

[Yaniv Kaul]

On Sun, Oct 30, 2016 at 12:47 PM, Mike (maillinglists) <maillist at probie.nl>
wrote:

> Hi Yaniv,
>
> Op 30-10-2016 om 11:35 schreef Yaniv Kaul:
>
>>
>>
>> On Sun, Oct 30, 2016 at 12:02 PM, Mike (maillinglists)
>> <maillist at probie.nl <mailto:maillist at probie.nl>> wrote:
>>
>>     Hi guys,
>>
>>     There have been a few related questions already that I could find,
>>     but I did not find anything relating to my specific use case.
>>
>>     Currently it is not possible to mix local storage with shared
>>     storage in the same datacenter.
>>     The reason seems to be because of the storage pool manager (SPM).
>>     This is a role in the datacenter provided to one specific host.
>>
>>     While I understand that this makes having local storage impossible,
>>     I believe there is a use case to have local storage in a shared
>>     storage datacenter.
>>
>>
>> Indeed, this is one of the more appealing use cases. There are others s
>> well.
>>
>>
>>     Consider the following:
>>     I have a few applications that require 1 milli second latency and at
>>     most 2 milli second.
>>
>>
>> For read, write or both?
>>
> Both I'm afraid.
>
>>
>>
>>     That is not consistenly achievable with shared storage, to that end
>>     I added flash storage to a few hypervisors.
>>
>>
>> You could have flash on your shared storage.
>>
> The problem with shared flash storage is the storage network required in
> between. I have seen shared NFS storage at 1ms latency, but that has not
> been stable and this application requires stable 1ms latencies.
>
>>
>>
>>     About 5% of my servers require this and are not that resource hungry
>>     to require a dedicated physical server.
>>     That same 5% also has no requirement to be migrated if a host fails.
>>
>>     So in short I have 5 heavy hosts running ovirt with a shared storage
>>     domain on NFS for 95% of my servers.
>>     All running fine, but I am now unable to run my remaining 5%.
>>
>>
>> Perhaps, if there are no HA requirements, those VMs with local domain
>> needs can be in their own DC, a local one? If it's just 5%, shouldn't be
>> much of an effort?
>>
> Can a host be in 2 datacenters?
>

No, I suggested to dedicate a host (or several) with their own local DC for
those 5%.
Y.


> I was not aware of this and I will investigate.
>
>>
>>
>>     To finish up my summary I have been testing various virtualization
>>     technologies, like VmWare and Hyper-V.
>>     They allow such configurations as I mentioned.
>>
>>     I already had some chat on irc with various guys and they suggested
>>     that I put this on the mailing list, so here goes.
>>
>>     My suggestion would be to evoluate from SPM to SDM.
>>
>>
>> Easier said than done... We have worked on this for quite some time,
>> it's not as easy as one might think.
>>
> I appreciate your honousty, but still hope this can be achieved.
>
>>
>>
>>     SDM stands for Storage Domain Manager.
>>     This would create the possibility to have all nodes in the
>>     datacenter participate in the storage handling.
>>     A extra benefit would be that local storage could be added.
>>
>>     What do you think?
>>
>>
>> There are other use cases we think flash on the host can be used, some
>> may be of use for your use case.
>> For example, dm-cache[1].
>>
>> We are still looking at this. I think Gluster already can make use it
>> for cache, for example.
>> Y.
>>
> Gluster is an angle we are investigating, but takes time to look into.
> Thanks!
>
>>
>> [1] https://people.redhat.com/mskinner/rhug/q1.2016/dm-cache.pdf
>>
> Thanks!
>
>>
>>
>>
>>     Thanks for reading.
>>
>>     Kind regards,
>>     Mike van Goor
>>     _______________________________________________
>>     Users mailing list
>>     Users at ovirt.org <mailto:Users at ovirt.org>
>>     http://lists.ovirt.org/mailman/listinfo/users
>>     <http://lists.ovirt.org/mailman/listinfo/users>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20161030/56decfa9/attachment-0001.html>