One of my readers sent me this question:
What is best practice to get a copy of the VM image from DC1 to DC2 for DR when you have subrate (155 Mbps in my case) Metro Ethernet services between DC1 and DC2?
In this particular case, you have to figure out what the Recovery Point Objective (RPO) is, or (to put it bluntly) how fresh the data should be. It’s also nice to know what the Recovery Time Objective (RTO) is, or how long it can take to restore the services.
With well-designed applications that store data in the database and not on local disk, it’s good enough to copy VM images every night or so, and have database replication enabled between data centers. Alternatively, you can use database log shipping and recover original data from backups if that’s acceptable from RTO standpoint.
There are plenty of backup solutions that allow you to ship VM images to a standby location every night; you can also use vSphere Replication to run continuous data synchronization in the background.
In any case, almost anything is way better (from bandwidth utilization or goodput perspective) than dumb block-level disk replication promoted by storage vendors – database replication or vSphere Replication is aware of the actual content, and can ship the modifications in optimized format, whereas disk replication transfers any change to the disk when it happens (including continuous updates to database indices as records are changed).
The reply I got back from the reader made me sad because it’s so typical of the state of the industry:
As expected, it is just managing expectations. Our problem is probably more Sales and Marketing. Trying to engineer a solution after promises have been made is always going to be a challenge.
I’ve been talking about that for years, but of course I’m always preaching to the choir, and nobody else seems to care.