
Greetings to all.
In this article, I will describe my experience in converting an “iron” MSCS cluster into a virtual server.
')
Our cluster has been working since 2008, there are a lot of tasks accumulated, including critical ones, and it was impossible to pick up a new server. In addition, worn equipment was about to fail. For us, there was only one way out - server virtualization in our data center, on VMware. And for me the task was set - to leave clustering. Having studied a lot of information in the network, I did not find a suitable step-by-step instruction, so I decided to compose my own.
The initial state was as follows:
- MSCS cluster on Windows 2003 Enterprise edition SP2. Two nodes in Active \ Passive mode;
- SQL Server 2005 Standard Edition, running in cluster mode;
- Multiple WWW / FTP sites on IIS, not in cluster mode. For each of the 32 Web sites, one IP Address is a cluster resource. Roughly speaking, additional IP were attached to the network card. Sites only worked on the intranet;
- 9 logical data drives, 152 File Share resources, all data is stored on a disk array;
- A customized task scheduler, through it, some industry-specific programs were launched.
For preliminary preparation and testing of the server, we have created a virtual "laboratory".
We connected three machines to an isolated virtual network: a virtual copy of the active node of the cluster, a virtual copy of the domain controller and a regular machine with Windows 7, on which we will test everything. In advance, several disks with SQL databases, www / ftp sites, network folders, quorum disk were converted to VMDK.
We start the machines, configure network cards with the same TCP / IP parameters as in the real network. We connect the disks to our server, assign the appropriate letters, reboot. After this, the cluster should start. By the way, in the single node mode, the cluster immediately started working, but we no longer need it, all the more there is a risk that such a configuration will not work correctly in a virtual environment.
Now you need to save the network card settings and network resource settings, because after removing the cluster service, they will have to be manually restored. I previously prepared dump TCP / IP settings using the netsh command. I planned to create network resources again using the “net share” command. Perhaps there is a way to backup network balloon settings, but I did not find it.
So, we have a file ip.cfg and shares.txt (list of net share commands). Make a snapshot in order to roll back in case of failure.
We start declustering
- After starting the virtual copy, the second cluster node will no longer be available. Remove it with the Evict Node team.

There may be such a message, here without options, click OK.

- Next, configure SQL. We need it to run as usual. In the instructions found on the Internet, they suggest making copies of databases, deleting a clustered Instance, then installing Standalone Instance. I found a simpler way through the registry:
Remove branches
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.1 \ Cluster
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.2 \ Cluster

Change keys
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.1 \ Setup \ SqlCluster = 0
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Microsoft SQL Server \ MSSQL.2 \ Setup \ SqlCluster = 0

In the SQL Server configuration manager, we set services for autorun.

- We include services WWW Publishing Service, Task Scheduler for autorun. Previously, they were started manually only on the active node.


- Remove the last node from the cluster. After this, cluster resources such as IP address and File Share are permanently deleted from the system.

- So that users can then work normally with network folders, we again edit the registry:
In the registry section HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ LanmanServer \ Parameters
add the DWORD parameter "DisableStrictNameChecking", with the value 1

- Restoring network settings:
Netsh exec c: \ ip.cfg
- Restore network resources from the text file shares.txt. Just copy the commands and paste into cmd. I tried to make a bat-nickname, but there was a problem with the display of Russian characters in the resource descriptions.
- Reboot the server. After that, we check the operation of all ftp-, www-, share-resources in our laboratory.
If everything is in order, then the virtual server is ready to move to a regular network.
Briefly about the transition
The nuances here may be different, but the principle is the same: you need to disable the iron cluster, transfer resources and settings to the new server and enable it. In my case, resources are IP addresses, logical data disks, network spheres.
We did not completely remove the iron cluster from the network and AD, so that in case of failure we could return everything.
Our actions:
- Disconnect from the network and from the disks iron cluster. IP addresses are released.
- The total amount of data is 1.5 TB, so all the disks in the VMDK cannot be transferred at once, the information is constantly updated. We decided to temporarily connect them to the virtual server as RDM, thereby reducing downtime during the transition. As experience has shown, it is better to connect them to the machine turned off. After launch, the same letters should be assigned to these disks as on the old cluster, for example, in our database, the SQL server databases were launched from disk S.
- We include the virtual server in the general network, we reboot.
After a reboot, FTP, WWW services, SQL have earned correctly. All actions took a little less than an hour.
Some time later, there was a glitch with network balls, when some users cannot log in using the old cluster name. Possible fixes:
- Check the execution of paragraph 5 of the instructions.
- Delete old entries on the WINS server for the cluster name
- When deploying an MSCS cluster, in AD, besides the accounts of the first and second nodes, a third account is created with the cluster name: its description is “Server cluster virtual network name account”. This account must be disabled.
- In DNS, an alias was created by the name of the cluster on the first node.
Currently, the virtual server is working properly. No glitches are observed. Now you can safely celebrate the New Year 2015. Thank you all for your attention.