Clustering for Mere Mortals (Pt2)
Posted
by Geoff N. Hiten
on SQL Team
See other posts from SQL Team
or by Geoff N. Hiten
Published on Thu, 18 Feb 2010 21:27:48 GMT
Indexed on
2010/03/11
4:41 UTC
Read the original article
Hit count: 621
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.
© SQL Team or respective owner