Questions on setup

[jeffmetcalf]

Production Site:
1) Dell R620 with VCenter and VEEAM (Physical)
5) Dell R620 ESXi 5.1 hosts (booting from SD card, no local storage)
4) Dell MD 32xx storage units

The Dell Vcenter and VEEAM backup server, VahallaCTRL, is physical, Windows 2008R2, SQL server 2008R2 (not express)
This system has VCenter DB, VEEAM backup and replication DB, and VEEAMOne DB

Connected backup repository is a Drobo 800fs (12TB)

DR Site
1) HP DL360 with VCenter (physical)
5) HP DL360 hosts ESXi 5.1 hosts (booting from SD card, no local storage)
4) MSA 3212i series storage with 2 MSA70 expansion units

The HP Vcenter is physical, (AvalonCTRL), Windows 2008R2, SQL Server R2 (not express)
This unit has a Drobo 800i (12TB). This unit is iSCSI connected as a target on the Windows physical server.
VEEAM B&R is NOT installed on this server.

The Vahalla stack has 2 proxies (virtual) , and the Avalon stack also has 2 virtual proxies.

All VMs (26 in total) on the Vahalla stack are covered by a backup job and a replication job. All non-transactional servers such as application servers etc that don't change often are spread across the week with a backup job, and a replication job to the Avalon stack that matches the servers in the backup job. This setup has been fully operational for about 10 days and seems to be working quite well while both stacks are on the local LAN.
Once the DR site gets sent to a satellite office we may have to revisit, but I'll fight that when I get to it.

Heavy transaction servers (SQL and Exchange, 2 each) are covered by a backup job and a replication job, but the replications are either running continuously or hourly.

The SQL databases for VEEAM backup and recovery (6.5) are backed up nightly to the Drobo unit connected to AvalonCTRL, the DR site.

Thoughts on this setup? I'm thinking that I have most bases covered. My databases are not large, so I can restore the VEEAM Backup db in a short amount of time and install VEEAM B&R on Avalon quickly in a DR situation, if the VahallaCTRL server goes unavailable. I'm pretty sure I can script a nightly DB restore to Avalon from the backups to even be quicker.

It would be sweet if the Drobo 800fs would replicate to the 800i, but the built in drobo software won't work from the FS version to the ISCSI version.
Seems kind of dumb to me, but so be it. Any thoughts on what tool I could use to handle this?

How can I build a sandbox to test the replications? There is no re-ip setup, as we'll want the replications to come online with the same IP.
If I lose the entire VahallaCTRL stack, is it really as simple as starting the replicas on AvalonCTRL based on whatever snapshot I chose? Can this be done without having the VEEAM B&R database available, or should I plan on restoring this first?
Any thoughts on what else I need to do to protect my environment? By the end of the year, all of my production critical servers will be virtual, except for the 2 VCenter/VEEAM servers.
Is there a way to integrate VM Site Recovery Manager into this scenario?
My VCenter/ESXi servers are 5.1 standard, running in a VM center cluster. I do not own the enterprise version, so the full HA/DRS tools are not available to me.

Thanks for the insights and advice.
jdm

[foggy]

Jeff, given physical Veeam server, your setup looks good to me. However, having it virtualized allows for faster failover using Veeam B&R UI in case of disaster.

It would be sweet if the Drobo 800fs would replicate to the 800i, but the built in drobo software won't work from the FS version to the ISCSI version.
Seems kind of dumb to me, but so be it. Any thoughts on what tool I could use to handle this?

Please review a couple of existing topics for possible solutions:
v6 - How to have a local and off-site backup copy?
Best backup setup for mirroring backup respository

How can I build a sandbox to test the replications? There is no re-ip setup, as we'll want the replications to come online with the same IP.
If I lose the entire VahallaCTRL stack, is it really as simple as starting the replicas on AvalonCTRL based on whatever snapshot I chose? Can this be done without having the VEEAM B&R database available, or should I plan on restoring this first?

Yep, this is covered in the sticky FAQ and in another existing thread also.

Is there a way to integrate VM Site Recovery Manager into this scenario?

Some of our customers successfully use both SRM and Veeam B&R to obtain different goals, you can review the corresponding thread for details.

Thanks.

[jeffmetcalf]

I've read thru most of those threads.
1) I don't get how to set up the replication sandbox by creating another vswitch, and if I do, won't it break the replications if I set up another management network? (I know, more of a VMWare question than a VEEAM question. But the advice here is pretty sound compared to some of the "watch me dump all this techno jargon on this newbie" you get from the VMWare forums)
2) I've looked at the rsync tools. Any one like one better than the other for moving this much data?
3) The SRM/VEEAM integration should be doable. The problem I think is that SRM has no way of knowing where the replicas live. VEEAM puts the replicas in the failover cluster based on what it thinks the host can handle. In my case, because it's a small set of servers, it actually puts them all on host 1 of the Avalon stack when picking the cluster name as the replica location.

It would be sweet if VEEAM could look into adding some kind of automated failover into VBR based on heartbeat.

[chrisdearden]

VEEAM puts the replicas in the failover cluster based on what it thinks the host can handle.

bear in mind that the replica's are powered off. If you have DRS enabled and set to anything other than manual, they will be started on the most appropriate hosts in the cluster.

[jeffmetcalf]

Yes, I know. Just wish VEEAM would give us an option to balance the number of servers across the available hosts in the cluster based on the # of VMs instead of what it decides each host could handle. I asked VEEAM support about this and they said that's the way it is, based on an algorithm.