[ovirt-users] Multiple datacenters design

[Jorick Astrego]

On 09/08/2014 04:45 PM, Itamar Heim wrote:
> On 09/08/2014 12:54 PM, Finstrle, Ludek wrote:
>>
>> Hi,
>>
>> I'm quite new to ovirt and I'm going to deploy ovirt into several tens
>> location all around world.
>>
>> The connection between locations is neither dedicated nor 100% reliable
>> as it's connected via internet.
>> I'm going with Gluster storage domains mainly.
>> It's not important to me to do live migrations or even offline
>> migrations between locations (they're independent).
>>
>> What's the best design and components from your point of view? I believe
>> I'm not the first one with such design.
>>
>> I think about two possibilities:
>> 1) One central Engine
>> - how to manage guests when connection drop between engine and node
>> - latency is up to 1 second is it ok even with working connection?
>>
>> 2) Engine in every location
>> - is it possible to have also one central point with information
>> from all engines together (at least read-only)?
>> - what about central reporting at least?
>>
>> I like more one central Engine. My concern is how to work with consoles
>> and also just 1 ISO storage domain and 1 export storage domain (maybe
>> same hostname for ISO and export in every location). Another topic is
>> how to reach console/stop/start/migrate guest inside location while
>> there is connection down between the only Engine and nodes in the
>> location.
>>
>> Thanks ahead for you experience/ideas,
>>
>
> we run this with central engine and remote clusters, but remote 
> clusters have decent connectivity.
>
> oVirt 3.5 does bring several improvements to fencing management which 
> may help those with problematic links.
>
> for option #2 - ManageIQ (upstream of Red Hat CloudForms) is a "CMP" - 
> Cloud Management Platform, which can provide overall dashboard, 
> self-service, service catalog, automation, etc. across multiple ovirt 
> deployments.
> (they just released their first upstream release last week)
>
Using ManageIQ does work but is still more for the management of things 
running on the cloud. In this case you still will have separate ovirt 
environments that you have to manage.

That's not so bad and probably recommendable for a lot of use cases as 
you can't mess up all your DC's with one login.

Also it would be nice to have the frontend running somewhere that 
doesn't have to be on the management lan of all the virtual 
infrastructure and be able to reach even the IPMI's. If you have users 
accessing it, they could hake the management server and have access to 
all nodes in all DC's. You can build another interface with api calls to 
seperate them, but why bother when we already have a user interface.

Also when your connection to the DC's is interrupted you availabillity 
will suffer, but the reason we want to spread our virtual infrastructure 
accross multiple DC's is to remove SPOF of the datacenter.

What we would like to do is have a central datacenter that hosts our 
management infrastructure and is highly secure. When we access this 
management infrastructure, we can then manage all our other racks in 
other DC's through sattelite-systems/smart-proxies. Same like this:



A more distributed ovirt-engine would IMHO make the virtual 
datacenter/cloud infrastructure scale better across locations. While 
ManageIQ does that for multiple clouds. Two different use cases.

Kind regards,

Jorick Astrego
Netbulae B.V.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140909/e68d7782/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iejbjceg.png
Type: image/png
Size: 87279 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140909/e68d7782/attachment-0001.png>