Replication Options for KVM to DR Site



  • ok @scottalanmiller I will re-axe the question
    KVM w VMs at Site A
    For DR/HA (insert your fav term), how can I (call it replication or whatever verbiage you prefer) have a copy of the vm's at Site B ?



  • @FATeknollogee said in KVM VM Replication:

    ok @scottalanmiller I will re-axe the question
    KVM w VMs at Site A
    For DR/HA (insert your fav term), how can I (call it replication or whatever verbiage you prefer) have a copy of the vm's at Site B ?

    Oh, that's quite different. I'll fork as that's definitely a new thread and not what this one was about, which was HA failover or similar (LAN failover.)



  • DRBD actually has a mode designed specifically for this. It's different than what people mean when they talk about DRBD. Normally they mean Network RAID 1, which is DRBD's bread and butter. But it does an async mode, too, that is designed for exactly this purpose.



  • Let's talk product...
    What product is available to accomplish said task?
    Said product should be easy to setup & configure & not require a PhD.



  • @FATeknollogee said in Replication Options for KVM to DR Site:

    Let's talk product...
    What product is available to accomplish said task?
    Said product should be easy to setup & configure & not require a PhD.

    If we are talking exclusively async, site to site disaster recovery replication, then we have many options.

    I believe that oVirt handles this natively. And you can do it via the command line in multiple ways on your own without any tools. Remember that this kind of replication is as simple as making a snapshot and sending it to another location on a schedule, that's all Hyper-V is doing. So no tools or products needed for this.

    DRBD which is included with all KVM installations has a highly performant mechanism for this.

    Starwind has a mechanism for this.

    Scale HC3 has this in a fully managed and automated solution.

    oVirt appears to have this built in, as well.

    Most often, though you'd not do this from the platform but from the individual VMs. So you can use their own tools, Veeam, or any number of mechanisms for this.

    This is really a broader discussion. As the tools on other platforms are often seen as not being all that good for this task, looking for this here is quite limiting. There are loads of options, but chances are, none of them are really something you'd want to use if you are in a position of really choosing.



  • DRBD Proxy is the tool used for DRBD over a WAN.

    Also worth noting, the DRBD team is on ML.



  • 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.



  • @FATeknollogee

    Simplest option.

    At night shutdown the main VM, and rsync it to the off site location, then power it back on.

    If that is an option go for it.

    You will lose 1 day of work.

    You can do the same and rsync it to another KVM host, and have it ready and configured, so you can always power that VM ,and have it to have the same MAC ADDRESS, that way it will take the same IP, when disaster strikes, login to the secondary site and power it. Or ran script that will do that.

    I am simple man



  • @dyasny said in 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.

    Why complicate a perfectly good tool? DRBD isn't supposed to be a be all, end all DR tool. It does one thing and does it well.



  • @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.



  • @dyasny said in Replication Options for KVM to DR Site:

    Zerto

    Would never use, ever. Hacked ass shit.



  • @dyasny said in Replication Options for KVM to DR Site:

    @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.

    You are not understanding what DR is.

    DR has no mandate for versioning. Merely a means of recovering from a disaster.

    When it comes to any solution that does replication, that is not, ever, supposed to be a point in time recovery. Replication DR is for site failure. Nothing more and nothing less.



  • @JaredBusch said in Replication Options for KVM to DR Site:

    You are not understanding what DR is.

    Looks like I could say the same thing to you.

    DR has no mandate for versioning. Merely a means of recovering from a disaster.

    DR is for disaster recovery, exactly. An encoded disk can be as much of a disaster as a downed DC. Only DRBD would replicate the encoding, irrecoverably. DR solutions are there to bring you back from being down. Both replication based and copy based (backup) DR solutions have a PIT factor, otherwise they are not DR solutions, but merely a means of replicating a bunch of blocks. Have you ever seen Netapp advertise their metroclusters as DR solutions for example?

    When it comes to any solution that does replication, that is not, ever, supposed to be a point in time recovery. Replication DR is for site failure. Nothing more and nothing less.

    You are plain out wrong here. Replication DR is for site failure. And it is NOT an HA solution, it is not meant to perform a failover. It is there so that if the main site fails, you can bring up a secondary site within the configured SLA. That SLA always includes some work time lost. And that lost time always includes several PIT granularity periods.



  • @JaredBusch

    Would never use, ever. Hacked ass shit.

    I'm not a fan either, but it is a solution available out there



  • @dyasny said in 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.

    It's Network RAID. No RAID has versioning. If you want versioning, which is a great thing to have, that happens at a higher level. You can still do it, it's just not included in DRBD.



  • @dyasny said in Replication Options for KVM to DR Site:

    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.

    Like everything in the UNIX world, you build solutions from individual blocks. In the Windows world, people assume all solutions will do a single task and be pre-assembled for them. So you find a "product" that does what you need.

    In the UNIX world, it is generally assumed that you'll understand the tools and the concepts and use the existing tools transparently and put together what you need it to do.

    So nothing is a DR tool in UNIX, but DRBD is a perfectly valid building block to handle one of the pieces that becomes a DR solution.

    To paraphrase John Nicholson of VMware... disaster recovery is something that you do, not something that you buy.



  • @JaredBusch said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    Zerto

    Would never use, ever. Hacked ass shit.

    Hell to the no.



  • @scottalanmiller said in Replication Options for KVM to DR Site:

    It's Network RAID. No RAID has versioning. If you want versioning, which is a great thing to have, that happens at a higher level. You can still do it, it's just not included in DRBD.

    Exactly! Saying RAID is DR, is like saying it's the same as backup - only noobs do that.



  • @scottalanmiller said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    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.

    Like everything in the UNIX world, you build solutions from individual blocks. In the Windows world, people assume all solutions will do a single task and be pre-assembled for them. So you find a "product" that does what you need.

    In the UNIX world, it is generally assumed that you'll understand the tools and the concepts and use the existing tools transparently and put together what you need it to do.

    So nothing is a DR tool in UNIX, but DRBD is a perfectly valid building block to handle one of the pieces that becomes a DR solution.

    To paraphrase John Nicholson of VMware... disaster recovery is something that you do, not something that you buy.

    Well, no. DRBD (or any replication or storage sharding really) can be used if you want to protect yourself from a storage failure, just like with RAID you protect yourself from a disk failure. A DR solution should be able to bring you back from an outage. There is a huge difference there. Tape backup is more of a DR solution than RAID or storage replication. That's the point I'm trying to make.



  • @dyasny said in Replication Options for KVM to DR Site:

    @scottalanmiller said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    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.

    Like everything in the UNIX world, you build solutions from individual blocks. In the Windows world, people assume all solutions will do a single task and be pre-assembled for them. So you find a "product" that does what you need.

    In the UNIX world, it is generally assumed that you'll understand the tools and the concepts and use the existing tools transparently and put together what you need it to do.

    So nothing is a DR tool in UNIX, but DRBD is a perfectly valid building block to handle one of the pieces that becomes a DR solution.

    To paraphrase John Nicholson of VMware... disaster recovery is something that you do, not something that you buy.

    Well, no. DRBD (or any replication or storage sharding really) can be used if you want to protect yourself from a storage failure, just like with RAID you protect yourself from a disk failure. A DR solution should be able to bring you back from an outage. There is a huge difference there. Tape backup is more of a DR solution than RAID or storage replication. That's the point I'm trying to make.

    Yes, we use the term DA vs DR.

    RAID (including Network RAID like DRBD) is Disaster Avoidance, backups are part of Disaster Recovery.

    One is to prevent a disaster, the other is to recovery from a disaster.



  • @scottalanmiller said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    @scottalanmiller said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    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.

    Like everything in the UNIX world, you build solutions from individual blocks. In the Windows world, people assume all solutions will do a single task and be pre-assembled for them. So you find a "product" that does what you need.

    In the UNIX world, it is generally assumed that you'll understand the tools and the concepts and use the existing tools transparently and put together what you need it to do.

    So nothing is a DR tool in UNIX, but DRBD is a perfectly valid building block to handle one of the pieces that becomes a DR solution.

    To paraphrase John Nicholson of VMware... disaster recovery is something that you do, not something that you buy.

    Well, no. DRBD (or any replication or storage sharding really) can be used if you want to protect yourself from a storage failure, just like with RAID you protect yourself from a disk failure. A DR solution should be able to bring you back from an outage. There is a huge difference there. Tape backup is more of a DR solution than RAID or storage replication. That's the point I'm trying to make.

    Yes, we use the term DA vs DR.

    RAID (including Network RAID like DRBD) is Disaster Avoidance, backups are part of Disaster Recovery.

    One is to prevent a disaster, the other is to recovery from a disaster.

    Exactly. This is why DRBD is not a DR solution, like I've been saying all along. The problem with any kind of avoidance is that it can only target a limited number of potential problems, while a recovery solution covers everything.



  • @dyasny said in Replication Options for KVM to DR Site:

    while a recovery solution covers everything

    Well, in theory, lol. Nothing really covers "everything". There is always a scope, even if that is meteor strike or interplanetary warfare.

    Having worked on Wall St. where scopes are way bigger and people actually do DR planning while addressing things like entire regional destruction (e.g. all of a continent lost) is what most people would consider "ridiculously over the top" for DR planning. But to others, it's just normal scope.



  • @scottalanmiller said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    while a recovery solution covers everything

    Well, in theory, lol. Nothing really covers "everything". There is always a scope, even if that is meteor strike or interplanetary warfare.

    Having worked on Wall St. where scopes are way bigger and people actually do DR planning while addressing things like entire regional destruction (e.g. all of a continent lost) is what most people would consider "ridiculously over the top" for DR planning. But to others, it's just normal scope.

    LOL - for most, if a region is lost, so is their business.



  • @Dashrender said in Replication Options for KVM to DR Site:

    @scottalanmiller said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    while a recovery solution covers everything

    Well, in theory, lol. Nothing really covers "everything". There is always a scope, even if that is meteor strike or interplanetary warfare.

    Having worked on Wall St. where scopes are way bigger and people actually do DR planning while addressing things like entire regional destruction (e.g. all of a continent lost) is what most people would consider "ridiculously over the top" for DR planning. But to others, it's just normal scope.

    LOL - for most, if a region is lost, so is their business.

    Right, but for others, it's not. Hence why scope is important. One company's scope versus another changes what is DA vs DR for one or the other.



  • @scottalanmiller I've worked for a few banks as well, nothing to be too proud of 🙂 Seriously though, when you recover it is up to you to build the infra and get everything ready for recovery, when you avoid you need to target specific issues you're avoiding. You can restore from backup in pretty much any reasonable scenario. You can't avoid every, even reasonable, scenario, this is why backups were invented.



  • @dyasny said in Replication Options for KVM to DR Site:

    You can't avoid every, even reasonable, scenario, this is why backups were invented.

    That's my point. Losing the backups as well. Backups still don't protect from everything. Not when you lose whole regions. There are events that take out your backups as well, even if they are stored in another country, for example.



  • @JaredBusch said in Replication Options for KVM to DR Site:

    @dyasny said in Replication Options for KVM to DR Site:

    Zerto

    Would never use, ever. Hacked ass shit.

    Irony. On-High where I am is having us look at Zerto.



  • @EddieJennings said in Replication Options for KVM to DR Site:

    On-High where I am is having us look at Zerto.

    It's not a business tool. It's officially unsupported and puts your VMware installation at risk. If you use Zerto, you dont' believe in VMware. It is strongly advised officially to never, ever consider.

    If you use it, you voluntarily suspend any support guarantees from everyone. It breaches every possible support position. Not that Vmware would use that as an excuse to not support you, VMware isn't like that, but any legal responsibility that you've paid for them to have is completely gone.



  • @scottalanmiller said in Replication Options for KVM to DR Site:

    @EddieJennings said in Replication Options for KVM to DR Site:

    On-High where I am is having us look at Zerto.

    It's not a business tool. It's officially unsupported and puts your VMware installation at risk. If you use Zerto, you dont' believe in VMware. It is strongly advised officially to never, ever consider.

    I think it's being considering for our Hyper-V environment, which is what's used for our Citrix stuff. It's not something within my sphere of influence.



  • @EddieJennings said in Replication Options for KVM to DR Site:

    I think it's being considering for our Hyper-V environment, which is what's used for our Citrix stuff. It's not something within my sphere of influence.

    No idea what it does there, but you'd think you'd want backups to be from a reliable vendor of all things.


Log in to reply