Mark Broadbent, a principal SQL consultant at SQLCloud, presents on the complexities of SQL Server clustering and failover setups. The document outlines several cluster configurations, their benefits, difficulties, and failures, highlighting the importance of understanding dependencies and the potential impacts of changes in a clustered environment. Key recommendations include thorough testing in a virtual lab and careful, informed decision-making to avoid unnecessary panic during operations.

1. Ye Olde Cluster Curiosity
Mark Broadbent
Principal SQL Consultant
SQLCloud
SQLCLOUD.CO.UK
Shoppe

2. About
Mark Broadbent.
“30 billion times more intelligent than a live mattress”
Microsoft Certified Master: SQL Server
Microsoft Data Platform MVP
Owner/ Principal at SQLCloud
Email: mark.broadbent@sqlcambs.org.uk
Twitter: retracement
Blog: http://tenbulls.co.uk
Event Lead to the UK’s first ever SQLSaturday (Cambridge) and
Cambridgeshire SQL Usergroup
Event #4 on 8/ 9/ 10th Sept 2016 (pre-con/s) and (Community day)
https://www.facebook.com/groups/sqlsaturdaycambridge/
http://sqlcambs.org.uk

3. Agenda
The occasional
demo fail
The best part of
the presentation…
Beer O‘Clock
Standalone
versus
Clustering
Incredibly tenuous
link between the
Curiosity Shoppe
and clustering!
1
4
2
5
Exhibits
3

4. Standalone Versus Clustering

5. Standalone deployment of SQL Server/s
MSDTC
Instance1
Instance2

6. Clustered deployment of SQL Server/s
MSDTC
Install (New) Install (add) Install (add)
*1 MSDTC clustered deployment can vary
greatly depending upon design considerations
*1
Failover
Cluster
Instance1
Failover
Cluster
Instance2
Install (New)
Install (add)Install (add)

7. Running Clustered Instances
Failover
Cluster
Instance1
Failover
Cluster
Instance2
failover
Failover
Cluster
Instance1
failover
Failover
Cluster
Instance1

8. Welcome to Ye Olde Cluster
Curiosity Shoppe!

9. The Shrunken Head
One physical node but one
(or very small number of)
instances that you would
have otherwise deployed
as standalone.
Useful for easy expansion
of HA infrastructure when
budget allows and
abstraction of network
name
Failover
Cluster
Instance1
10.0.0.15
sqlserver1
Cluster Role/
Group
Windows Cluster
is a single node
only running a
clustered instance

10. Port o’ Plenty
Failover
Cluster
Instance1
Failover
Cluster
Instance2
Failover Clustered
Instances can be executed
to all listen under the
default SQL Server
listening port.
This can provide various
benefits (and potential
negatives).
Remember there can only
be one default instance!
Failover
Cluster
Instance3
Port 1433 Port 1433 Port 1433

11. The Bearded Lady
Failover
Cluster
Instance1
Failover
Cluster
Instance2
Each node sees all storage
Each instance brings more
clustered disks.
This can result in too many
cumulative disks and
become unmanageable.

12. Many Headed Cluster
Failover
Cluster
Instance1
Failover
Cluster
Instance2
One to many (unused) SQL
Failover Clustered instances.
Excellent for pre-testing
Cluster node upgrades and
testing database upgrade prior
to risking production Failover
Clustered Instance.
Failover
Cluster
Instance3 Failover
Cluster
Instance4

13. “Cutting off one head” – upgrading
clustered instance
Fail test clustered instance onto upgraded
node to upgrade instance/ databases
Apply latest service pack
If upgrade fails we
can uninstall patch
or at worst case
evict node and
rebuilt/ reinstall
SQL instances. Our
production
instances have
suffered zero
downtime from a
failed deployment

14. The Zombie
Failover
Cluster
Instance1
Failed Network Name
causes dependent SQL
Cluster Resource to fail.
Forced online local service
can return a temporary
limited service
10.0.0.15
SQL Service
Network Name
Cluster Role/
Group
Dependency
Bring online

15. The Indestructible Network Name
Active Directory in
Windows 2008 and above
has a protection property
In Windows 2003 you
would need to Deny the
Everyone group for the
Delete and Delete Subtree
permissions
Deleted objects can be
recovered from Tombstone
in some situations.

16. Demo
Let’s do the Zombie!

17. The Marie Celeste
Failover
Cluster
Instance1
Cluster Groups can be
easily created with little to
no risk to the cluster. They
are great for testing
storage and other
clustered resources ahead
of time.
Cluster Group
New Cluster Storage
for Instance 1
Fail across all nodes

18. Montezuma’s Revenge
Failover
Cluster
Instance1
10.0.0.15
Network Name
Cluster Role/
Group
Empty Cluster
Role/ Group
Accidental move drags the whole dependent freakin’ lot!
Failover
Cluster
Instance1
10.0.0.15
Network Name

19. The Bodysnatcher
Failover
Cluster
Instance1
Failed Clustered Instance across all
nodes can spell panic (especially if the
clustered set up is inherited).
If the failure is serious and cannot be
repaired a reinstallation on a new
cluster can be attempted from old
installation files. 
Cluster Role/
Group
Install (New) Install (add) Install (add)
New Cluster
Role/ Group
Install to nodes using
reference files

20. Installation of Death!
Failover
Cluster
Instance1
Cluster Role/
Group
The Installation of SSIS has huge
ramifications for a Cluster.
What software and drivers will be
required by packages? This is always a
never ending moving set of goalposts
and risk to Cluster stability.
SSIS SSIS SSIS
TNSnames.ora

21. The Stone Fish
Failover
Cluster
Instance1
Failure to identify all
dependencies to resource
prior to its removal can
cause the whole failover
clustered instance to
unexpectedly fail.
Whoopsie!
10.0.0.15
Network Name
Cluster Role/
Group
“Hidden” or missed
dependent to disk

22. In Summary…
• Never attempt any operation on any cluster
object *unless* you understand the impact.
• Always validate anything you hear or read
with your own testing in a virtual lab.
• It is easy to make a mistake performing an
operation or start to panic. Always take time
to understand what you are doing and break it
down into smaller steps if necessary.
• It is worth repeating… DON’T PANIC!

23. Thank you for listening!
Email: mark.broadbent@sqlcambs.org.uk
Twitter: retracement
Blog: http://tenbulls.co.uk