Geoff N. Hiten Blog

SQL Server thoughts, observations, and comments

Clustering for Mere Mortals (Pt2)

Planning.

I could stop there and let that be the entirety post #2 in this series.  Planning is the single most important element in building a cluster and the Laptop Demo Cluster is no exception.  One of the more awkward parts of actually creating a cluster is coordinating information between Windows Clustering and SQL Clustering.  The dialog boxes show up hours apart, but still have to have matching and consistent information.

Excel seems to be a good tool for tracking these settings.  My workbook has four pages: Systems, Storage, Network, and Service Accounts.  The systems page looks like this:

 

Name Role Software Location
East Physical Cluster Node 1 Windows Server 2008 R2 Enterprise Laptop VM
West Physical Cluster Node 2 Windows Server 2008 R2 Enterprise Laptop VM
North Physical Cluster Node 3 (Future Reserved) Windows Server 2008 R2 Enterprise Laptop VM
MicroCluster Cluster Management Interface N/A Laptop VM
SQL01 High-Performance High-Security Instance SQL Server 2008 Enterprise Edition x64 SP1 Laptop VM
SQL02 High-Performance Standard-Security Instance SQL Server 2008 Enterprise Edition x64 SP1 Laptop VM
SQL03 Standard-Performance High-Security Instance SQL Server 2008 Enterprise Edition x64 SP1 Laptop VM

Note that everything that has a computer name is listed here, whether physical or virtual.

Storage looks like this:

Storage Name Instance Purpose Volume Path Size (GB) LUN ID Speed
Quorum MicroCluster Cluster Quorum Quorum Q: 2    
SQL01Anchor SQL01 Instance Anchor SQL01Anchor L: 2    
SQL02Anchor SQL02 Instance Anchor SQL02Anchor M: 2    
SQL01Data1 SQL01 SQL Data SQL01Data1 L:\MountPoints\SQL01Data1 2    
SQL02Data1 SQL02 SQL Data SQL02Data1 M:\MountPoints\SQL02Data1      

Starting at the left is the name used in the storage array.  It is important to rename resources at each level, whether it is Storage, LUN, Volume, or disk folder.  Otherwise, troubleshooting things gets complex and difficult.  You want to be able to glance at a resource at any level and see where it comes from and what it is connected to.

Networking is the same way:

 

System Network VLAN  IP Subnet Mask Gateway DNS1 DNS2
East Public Cluster1 10.97.230.x(DHCP) 255.255.255.0 10.97.230.1 10.97.230.1 10.97.230.1
East Heartbeat Cluster2   255.255.255.0      
West Public Cluster1 10.97.230.x(DHCP) 255.255.255.0 10.97.230.1 10.97.230.1 10.97.230.1
West Heartbeat Cluster2   255.255.255.0      
North Public Cluster1 10.97.230.x(DHCP) 255.255.255.0 10.97.230.1 10.97.230.1 10.97.230.1
North Heartbeat Cluster2   255.255.255.0      
SQL01 Public Cluster1 10.97.230.x(DHCP) 255.255.255.0      
SQL02 Public Cluster1 10.97.230.x(DHCP) 255.255.255.0      

One hallmark of a poorly planned and implemented cluster is a bunch of "Local Network Connection #n" entries in the network settings page.  That lets me know that somebody didn't care about the long-term supportabaility of the cluster.  This can be critically important with Hyper-V Clusters and their high NIC counts.

 Final page:

 

Instance Service Name Account Password Domain OU
SQL01 SQL Server SVCSQL01 Baseline22 MicroAD Service Accounts
SQL01 SQL Agent SVCSQL01 Baseline22 MicroAD Service Accounts
SQL02 SQL Server SVC_SQL02 Baseline22 MicroAD Service Accounts
SQL02 SQL Agent SVC_SQL02 Baseline22 MicroAD Service Accounts
SQL03 (Future) SQL Server SVC_SQL03 Baseline22 MicroAD Service Accounts
SQL03 (Future) SQL Agent SVC_SQL03 Baseline22 MicroAD Service Accounts
           
Installation Account          
administrator          

 Yes.  I write down the account information.  I secure the file via NTFS, but I don't want to fumble around looking for passwords when it comes time to rebuild a node.

Always fill out the workbook COMPLETELY before installing anything.  The whole point is to have everything you need at your fingertips before you begin.  The install experience is so much better and more productive with this information in place.