fun and games with SQL 2005 MSCS, SMSQL and vmware…
Tonight I have been part of a team migrating, a two node Windows 32-bit Microsoft cluster, running a SQL 2005 database from old server hardware to HP’s latest and greatest 64 bit wonder. The migration also included moving the luns from a NetApp FAS3070 to FAS3170, iSCSI to FCP and new snapdrive / SMSQL host agents, just to keep things sweet. Straight forward bread and butter SAN admin work, 35 minutes job done! Then the fun started, hope this blog post helps you avoid the same issues later.
It is not possible to directly verify clusters on a cluster node so a 3rd machine must be used. The latest versions of SMSQL|(SMSME) allow this to be done on the snapmirror destination and therefore spare the primary storage system from the extra load. A great feature, especially on Exchange systems due to the high IO load created by the verification process. So to be able to go home I only had to get the verification box running with the cluster. Error! Can not use verification server. No problem, quick look on the now site, no hits! Bugger
Long story short, SMSQL not installed on the verification host, “surprise”. Easy fix, install. Try again. Error! Not able to create snapshot on SQL server. Confirm the configuration, no snapmirror for the snap_info drive. Easy fix, try again.
Error, verification server does not connect to luns. Much head scratching as verification server is on an ESX 3.5 box, with FCP. Prove vm can not connect to LUN as the initiators are not working. Further investigation shows no vmware tools installed on vm host. Install tools, snapdrive, SMSQL and test again. No license! Was filer based on old NetApp SAN, now application based. Install licenses onto MSCS nodes and verification server for both snapdrive and SMSQL. Test again, success! On the plus side it only took 3 hours to troubleshoot these avoidable issues.
Rule 2 ~ never believe what you are told. “Yes, it is ready to go; you just need to move 3 luns…”