Clustering for Mere Mortals (Pt2)
- by Geoff N. Hiten
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.
