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.
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
