I've been doing a lot of scripting work lately, automating product installs, OS configuation and deployment of our core application with a lot of PowerShell scripts, with the ultimate goal of being able to automate a "bare metal" installation of our client's entire environment using the Microsoft Deployment Toolkit (MDT). Part of this process which has been challenging is testing the scripting of SQL Server installations for a multitude of scenarios, such as installing only a subset of features, upgrading between SQL Server 2005 to SQL Server 2008, and most importantly, the differences between installing SQL on a stand-alone server or a fail-over cluster.
Testing these scripts against stand alone machines isn't any big deal as I have a server I use as a Hyper-V host I use to test a lot of "what if" scenarios and can make, snapshot, revert, etc. virtuals at will. But the cluster presents a challenge. As happens in most environments, servers and SAN resources to create new clusters don't grow on trees, and while we do have development resources, since we're actively developing against them, I don't want to necessarily grind our primary development effort to a halt while I'm running installation scenarios on our cluster resources.
So I decided to see if I could virutalize my cluster. I was pretty sure clustering the nodes wouldn't be any big deal, but I was less clear about how I'd provision the shared storage as I don't happen to have my own SAN lying about. I did some research to see if anyone else had tackled this problem and stumbled upon this blog by our PFE Ireland team which pretty much detailed exactly what I wanted to do. However, their example used the Starwind Software product to create an iSCSI target for shared storage. Nothing against Starwind or their products, but I don't have a license (and need to keep this going past the 30 day eval) and I wanted to see if I could keep this entirely within the Microsoft family.
As noted on the PFE Ireland team blog, Windows Storage Server 2008 has been released and is available to MSDN users and provides, with the installation of the Microsoft iSCSI Software Target 3.2 add on, an iSCSI target which the cluster can use as shared storage for cluster resources.
My next dillema was hardware: Part of my contribution to the environment has been to aggresively embrace virtualization technology and I am down to my Hyper-V host, a stand alone domain controller, and a couple of laptops - in short I had no free hardware to re-purpose as a dedicated Storage Server. So I decided to see if I could get away with virtualizing Storage Server as well. The process turned out to be remarkably easy, as detailed below.
Setting up Windows Storage Server 2008 on Hyper-V
And that's it for the Storage Server - fairly easy.
On the cluster nodes
And voila - we now have shared storage for a cluster. The volumes should now show up as unallocated volumes in Disk Management. At this point you can allocate, format, and configure the cluster.
I was surprised at how simple the process is for doing this - it feels a little weird sharing VHDs within a VHD, but I've had flawless reliability and great performance. For my test needs this has been a great solution.