As you move toward the goal of 100% virtualization in your data center, careful attention to the virtualization of business critical Microsoft applications such as Microsoft Exchange, Microsoft SQL Server and Microsoft SharePoint Server becomes essential. NetApp has joined forces with Cisco and VMware to create a complete solution for virtualizing these applications. This architecture combines the benefits of VMware vSphere 4, Cisco Nexus Unified Fabric, and NetApp Unified storage hardware and software. In the February issue of Tech OnTap I wrote an article that describes the reasons for virtualizing your Microsoft applications and highlights the important architectural and deployment considerations of this joint solution. You can check out the article at http://bit.ly/tot-virt-ms-apps
Do you plan to virtualize these applications or have you done so already? Why or why not? Would this joint solution make you more comfortable doing so?
Server and Desktop Virtualization
The problem we are having when engineering this solution specifically for SQL Server is how the system databases are replicated to the DR site. We have vSphere 4.0 Update 1 at both locations and have SRM working well. We are using NFS datastores for the OS/binaries and ESX ISCSI Software Initiators RDM LUNs for the application data as detailed in TR-3822. The issue I have come across that I cannot get an answer to is how to replicate my System databases (which reside on their own LUN). Because of the inability (I understand this is an MS limitation) to take a snapshot of the System databases (this is instead backed up to the Snapinfo LUN), I am unable to bring up those databases in a quiesced state on the DR side via SRM. I could manually take snapshots and then SnapMirror them over to the DR site but this is not quiesced and would potentially be unusable. The answer NetApp has provided is to restore the System databases once over to the DR site but because you have a non-quiesced copy of those databases, you are put into a "chicken or egg" situation. You need the system databases online to perform a restore of the system databases but since they are not stable, you cannot start the SQL Services to perform the restore.
The couple recommendations NetApp made were to do a repair of the system databases on the DR side during a failover and then do a restore....I would think this is far from an optimal DR solution and almost impossible to script. The other idea offered was to perform a database "pause" nightly and take a snapshot and replicate that system LUN to the DR site. I am not sure of the effect of this database "pause" on the entire SQL instance. This also does not cleanly tie into SMSQL as you would expect.
As a result of these limitations, we are now considering a DoubleTake DR solution for our SQL Servers which is a shame with all of this great SAN replication and virutal infrastructure.
The questions I have are:
Any assistance you can provide would be very greatly appreciated.