Geographically-distrbuted Ovirt Cluster?

Hi, Right now I run a 1-server hyperconverged hosted-engine deployment. Other than requiring systemwide downtime to perform host maintenance, it has worked fairly well for me over the past few years. However, after a couple power and upstream-network outages, there have been questions about the ability to "distribute the load", so to speak. Considering what our workload is (main git repo, wiki, email list + archives, etc), it can't easily be distributed by a periodic resync and DNS round robin like a static web site. To solve this distribution problem I was wondering if there might be some way to deploy a handful of physical servers in different geographic locations that work together to create an HE environment for guest VMs? My initial fear would be that it would require dedicated 1Gb (or higher) between the sites to move data? Let's say we do NOT have that level of connectivity. I saw something about geographic replication in Gluster? But that would seem to be more about replicating a local cluster to a remote cluster? I suspect the answer is: no, a cluster must all be physically co-located. But I figured I would ask the experts. Thanks all for your insights. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant

A geographically distributed cluster is a very expensive random number generator: any cluster crtically depends on the assumption that the communication between nodes is at least an order of magnitude more reliable than the node itself. Otherwise you just multiply the chance of failures. That doesn't mean that you cannot replicate read-mostly content across data centers or geographies, you'll just have to manage the conflicts that might result e.g. via an eventual consistency approach, that is typically implemented at the application level, sometimes in middle-ware or databases. Geographic distribution in Gluster is a continuous back facility designed to support a warm standby (AFAIK without guarantee on storage consistency). You can use the oVirt REST API to turn that into an automated warm-standby activation duplicating in a way what oVirt does internally with VMs. But if you're not careful, this can go wrong far too many ways for mere mortals: The CAP theorem is as easy to cheat as the laws of physics and that's why oVirt doesn't deal with disaster scenarios.
participants (2)
-
Derek Atkins
-
Thomas Hoberg