1 Reply Latest reply: Jun 9, 2010 12:16 PM by jwhelan27 RSS

Virtualizing Microsoft Applications

Currently Being Moderated

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?





Abhinav Joshi


Reference Architect

Server and Desktop Virtualization


  • Re: Virtualizing Microsoft Applications
    Currently Being Moderated

    Hi Abhinav,


    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:


    1. What are other folks doing with respect to failing over their SQL Server from one vSphere environment to another?
    2. Why isn't this MAJOR gotcha documented in any TR reports?  Has this issue not been raised by anyone?
    3. Am I missing a more simplistic solution to this problem (I hope this is the case) or do I really need to look at a third party solution for my DR despite the investment made in NetApp and VMware?


    Any assistance you can provide would be very greatly appreciated.





More Like This

  • Retrieving data ...