For example, if you run a FibreChannel SAN with no iSCSI connectivity and don't have the tremendous luck to have dark fiber running to your warm site, implementing SAN replication might be out of the question without hardware such as an FCIP gateway or software such as EMC's RepliStor. If you're in this boat, be sure to consider these factors the next time you are weighing an upgrade to or replacement of your current SAN.
On the other hand, users of devices such as NetApp filers should add more SnapMirror licensing, and users of Dell EqualLogic PeerStorage arrays (also sold under the Dell brand) have everything they need already. No matter what your SAN, to perform SAN-to-SAN replication, you're going to need a second one.
If performing SAN-to-SAN replication is out of the question, you still have options. There are several good host-based replication software packages available that will run on the ESX hosts and do direct host-to-host replication. These include Vizioncore vReplicator and NSI DoubleTake for VI. They are usually licensed per VM rather than per host, which can make them unattractive depending upon the number of guests you want to replicate. The big caveat here is that you will need a large amount of directly attached storage on the old hosts that are being moved across to the warm site. (If they had been attached to your production SAN, they may no longer have any disks in them.)
No matter how you decide to do it, your storage configuration -- whether it involves SAN or host-based replication -- is the most important part of the warm site design and should not be treated lightly.
Step 3. Figure out your bandwidth needs
Once you've determined what the storage is going to be at your warm site, you need to consider how you're going to get your data there. If your warm site is on your campus or otherwise fiber-attached, there's not much to worry about unless your data sets are truly massive.
Although the network connectivity to your warm site is probably the most straightforward of all of the decisions that you need to make, it can easily blow your budget, since WAN bandwidth generally has a recurring monthly cost. Failing to properly estimate the required WAN bandwidth can have disastrous long-term budgetary consequences.
For example, let's say your initial calculations show that you're going to need two T1s' worth of bandwidth (3.0Mbps) to replicate an estimated 25GB of storage deltas per 24-hour period to maintain whatever RPO you've set. But it turns out you actually need to move 35GB per day to meet that RPO -- a difference of roughly one more T1 circuit. Depending on your bandwidth costs, that small difference could cost as much as an entirely new SAN or a few new virtualization hosts over three years' time.
So if estimating your replication bandwidth needs is so important, there must be a tried-and-true way of doing it, right? Not really. There are some tricks to determine how much data is turning over on your VMs, but you can't always trust what they tell you.
The first and easiest method is to use VMware's built-in snapshot functionality. Take a snapshot of every VM you want to replicate, wait a period of time equal to what you'd like your replication period to be based on your RPO, then examine the snapshot files on your VMFS volumes to see how big they are. (Note: Be sure you have enough free space on your VMFS volumes before you do this.) That figure is roughly how much data has changed on those VMs in that period. If you do this at several times during different parts of your production day and month, you should get a reasonably good idea of how quickly your data is changing.