@travisdh1 that's because DRBD isn't a DR tool, it's a block replication tool. All real DR solutions have granularity and versioning. SRM, Zerto, NeverFail, even old WanSync - all of them could do it. DRBD can only sync blocks, nothing else. This is not DR.
Posts made by dyasny
-
RE: Replication Options for KVM to DR Site
-
RE: New Infrastructure to Replace Scale Cluster
@Dashrender said in New Infrastructure to Replace Scale Cluster:
I definitely like the simpler solution - local storage for local VMs. If you need to move VMs between hosts for maintenance - fine - make sure you have enough resources to do just that, then move them. But moving to shared storage at two compute nodes and basically wasting the compute of the third node doesn't make sense to me, not to mention putting yourself in an IPOD situation - where if you loose the disk, you loose both compute nodes.
it is even easier this way, and you can even move those VMs around, but there will be no HA there. Migrating a local VM with it's storage is basically like live migrating a VM with the RAM size of the disk to be moved. Can take days on a gigabit link, if the disk is large. So again, it's about balance between factors. If HA doesn't matter, use local disks by all means. Just be sure to back up a lot, and you'll even get the benefit of faster disk access for the local VMs. Latency is key to some apps, so it might be a good thing
-
RE: New Infrastructure to Replace Scale Cluster
@Dashrender said in New Infrastructure to Replace Scale Cluster:
IPOD = Inverted Pyramid of Doom.
This a term that Scott Allen Miller coined ages ago.I am not a part of the Scott Alan Miller quote club, sorry
1 - SAN
2 - Switches
2+ - serversThe general belief is that the SAN is 'so good' it will fail less frequently than the other components. Now - in your setup it might be as good as the servers, since it's not one of those manufactured typical SANs, but it's still just a server.
Well, yes. And we are talking about proper brand name servers. The Dell PE series pretty much in its entirety across all the generations I've worked with (starting with the 4th) have redundant power supplies, redundant and in some models hot-swappable RAM modules, hot swappable drives that can be used in a RAID, so you can tolerate outages. Not everything is replaceable on the fly and not everything is duplicated, but all the components that typically experience outages are. For everything else there is backup, and the aforementioned budget/paranoia/f&f balance to consider and maybe play with.
The general idea around these parts you don't go to centralized storage until you have at least 4 hypervisor hosts, otherwise putting storage locally is often much less expensive and less risky.
How is that calculated exactly?
And of course, we haven't even touched on HA.
oVirt provides HA out of the box, as long as a living host has enough resources available to start the protected VMs.
-
RE: Replication Options for KVM to DR Site
DRBD has one problem - no versioning. If you mess up a VM in site-A, the garbage gets replicated over and you get it on site-B, no rollback to a PIT where it was absent, like you get with proper DR solutions.
-
RE: New Infrastructure to Replace Scale Cluster
@Dashrender said in New Infrastructure to Replace Scale Cluster:
Isn't that an IPOD though?
It's a server, not an ipod. If you mean SPOF, then yes, if the entire server just dies, you lose the cluster. Obviously, the server itself can be backed up, clustered, and installed with redundant components to avoid that. It's all a matter of balancing between budget, the admin's level or paranoia, and the desire to have a reliable setup without working too hard. I really like the latter, and in the long run this approach has always served me and my customers very well.
These 3 factors are up to the OP of course. All I'm trying to say with my suggestion is that you're not saving anything by hyperconverging, because you ARE making the setup much more complex, with many more moving parts that require configuration, tuning, updates and server resources than you would have by just sticking to the KISS principle.
-
RE: New Infrastructure to Replace Scale Cluster
@DustinB3403 no, in this particular setup, you have two options. The original one would be to go hyperconverged, installing both the storage and hypervisors services on all 3 hosts, and to also deploy the engine (vsphere equivalent) as a VM in the setup (that's called self hosted engine).
The better option, IMO, is to use two hosts as hypervisors, and the third - pack with disks, and use as the storage device (NFS or iSCSI). And also install the engine on it, as a VM or on baremetal - doesn't matter.
You will have less hypervisors, true, but having a storage service on the hypervisors is a resource drain, so you don't actually lose as much in terms of resources. And you gain a proper storage server, less management headache, and a setup that can scale nicely if you decide to add hypervisors or buy a real SAN. Performance will also be better, and you might even end up with more available disk space, because you will not have to keep 3 replicas of every byte like gluster/ceph require you to do.
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee doing it in a VM is convenient. You can always move that VM to another host, you can easily back it up by copying it's disk and domxml, you can even easily set it up as an HA cluster with pacemaker protecting the libvirt service. Databases though, feel more convenient on baremetal, so if you're going to build something with hundreds of hosts, I'd suggest you invest in the engine host as well.
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee said in New Infrastructure to Replace Scale Cluster:
@dyasny said in New Infrastructure to Replace Scale Cluster:
@FATeknollogee that really depends on your cluster size. If you can afford to dedicate a separate host to it, then why not.
You mean a separate host where the HE vm lives on?
Yes, it's your choice whether to do it in a VM though, it can be on baremetal
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee that really depends on your cluster size. If you can afford to dedicate a separate host to it, then why not. Besides scalability, your main benefit will be not having to deal with all the hosted-engine clustering overhead. It really makes life simpler
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee just a regular libvirt/KVM usually. If there is a multivendor virt environment, I install the engine in the second setup (vmware/hyper-v) and often the vCenter is installed in RHV
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee Yes, it's a simple setup where you run ovirt-engine-setup and it asks you a few questions in the command line. For ease of management, I usually deploy it in a standalone VM on a separate machine. This way, if I need more resources, I can stop the machine, give it some more cores/ram or move it's disk to a faster storage, and start it up again. BAcking it all up is as simple as copying the VM disk.
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee absolutely. Pretty much every setup with over 20 hosts I've ever built, wasn't using HE.
-
RE: New Infrastructure to Replace Scale Cluster
@FATeknollogee because it doesn't scale. For a small setup it will work (because you don't want to waste a machine on it), but at scale you will keep getting hit by problems. Remember, the engine runs two postgres databases, both under stress, as well as a java based engine, which is also a resource hog (it's java after all). Add the fact it's doing a lot of network traffic polling all those hypervisors and getting a lot of data about everything they do every 2 seconds, and you have a VM that is doing a LOT.
For a few hypervisors, it will not be a huge issue, but drive that up to a point and you end up in a world of hurt. So for anything large-ish and where reliability is important, just avoid HE.
-
RE: Ovirt
I can help you with the setup (been working with oVirt from before it was even called ovirt), but you have to answer my points in the other topic
-
RE: New Infrastructure to Replace Scale Cluster
I haven't read the thread, so apologies if I repeat anyone else's words.
Here are some points:
- Central storage is not an SPOF, if done right, it will have redundant parts that can keep it going in case of a component failure, and it can be cloned. I've never seen a well built SAN go completely down in over 20 years of working with them.
- On the other hand, hyperconvergence is a resource drain, with systems like gluster and ceph eating up resources they share with the hypervisor, with neither being aware of each other, and VMs end up murdered by OOM, or just stalled due to CPU overcommitment.
- Gluster and other regular network based storage systems are going to be the bottleneck for the VM performance. So unless you don't care about everything being sluggish, you should think about getting a separate fabric for the storage comms, even if you hyperconverge.
- oVirt can be really nice, but you have to understand what it was built for, and not try to bend it out of shape with ridiculous requirements. A well built and pretty much zero maintenance oVirt setup will have a central storage, proper power management (you do have DRACs, right?) and doesn't use Hosted Engine. That will require more than 3 hosts.
- How many and how powerful will the VMs be? I would really go with a two node cluster, and use the third as a NAS and a standalone libvirt VM for the engine. This is the usual approach for a budget setup, where you can't afford something better.
-
RE: Virt-Manager on multiple pc's
@FATeknollogee VPN based intranet, DNS working internally. Latency always under 150ms
-
RE: Virt-Manager on multiple pc's
@FATeknollogee if you have an ovirt-engine somewhere central, that can reach to all the other locations, you can create a datacentre per location and place standalone hosts in there, using local storage. You will still have a single pane of glass to manage it all from a single address, a centralized VM configuration store, and the option to scale to additional sites or add hosts in a specific DC. I've run a RHV setup with ~300 hosts spread out across the world like this, and it was much easier than dealing with entirely standalone machines.
-
RE: Virt-Manager on multiple pc's
When you have more than just a few hosts, even spread out across multiple sites, managing them with virt-manager can be painful. You definitely should start looking at something a bit more scalable, like RHV/oVirt
-
RE: KVM / Red Hat Virtualization Management
@scottalanmiller RHV now, after a rebrand in 2016-ish
-
RE: KVM / Red Hat Virtualization Management
Red Hat has 2 (well, actually 4) products that manage KVM. The main ones are RHV/oVirt and RHOS/RDO (their Openstack distribution).
Besides these two there is the localhost-oriented libvirt with virt-manager, cockpit and boxes, and kubernetes oriented kubevirt.
So if you're looking for a vCenter cluster replacement, RHV is what you should be looking at (or if you prefer the less stable opensource version - oVirt). If you want to build something larger, at the scale of AWS, you need Openstack. For local stuff, e.g. virtualbox - virt-manager, boxes, and eventually cockpit will do the job, and if you want to run a VM in a k8s pod - kubevirt is for you.