Fig. 1: A best practice and scalable, vSphere, SRM, and Compellent design showing how the components interact
Server Colour Coding Key:
Green = Virtual Server
Green/Blue = Can be virtual or physical - it depends …
Blue = Physical Server/Appliance
We have no existing suitable database servers, so we will build a virtual SQL Server in each site. To start off with we use the free SQL Server 2008 R2 Express which allows any number of up to 10GB databases to be created within it. As needs require; the SQL Server 2008 R2 Express can be upgraded to a full unlimited version of SQL Server 2008 R2.
For scalability and performance reasons, it is recommended to separate database server, VMware vCenter Server, and VMware Site Recovery Manager Server roles, and this is what we do here.
The Compellent Enterprise Manager Data Collectors by best practice should be on a physical server or a virtual server that is not on the Compellent SAN (this makes logical sense, since in the unlikely event there is a problem with the Compellent SAN, it is imperative to keep the Enterprise Manager data available.) In this scenario we will be deploying the Enterprise Manager Data Collector on available physical backup servers in either site - we can either use the embedded database that comes with the installer (this is good for a maximum of 30 days or 2 GB) or we could use any of the following databases - MySQL 5.0/5.1, Microsoft SQL Server 2005 to 2008 R2 with Express editions. The database used for storing Enterprise Manager data can be changed after installation.
Note 1: If we were using the Classic SRM Primary Site/DR Site Configuration, we would have just one Enterprise Manager Data Collector in the Recovery Site.
Note 2: Slightly off topic - the vCenter Servers in this scenario are configured in Linked Mode, and a requirement for Linked Mode is that the vCenter Servers are part of an Active Directory Domain.