Search This Blog

Failover Clustering:



Clustering is a technology, which is used to provide High Availability for mission critical applications. We can configure cluster by installing MCS (Microsoft cluster service) component from Add remove programs, which can only available in Enterprise Edition and Data center edition.
Failover Clustering Step by Steps Installation Guide
The reason I start with Failover Clustering is, it provides Availability at an Instance level and most of the Production Instances are implemented using SQL Server Failover Clustering.
Scope
Instance Level (All Databases in a single Instance)
Core Functionality
The main functionality of Failover Clustering is to minimize the downtime of the SQL Server on an instance level.
Requirements
The Hardware needs to be certified for Implementing Failover Clustering. Moreover all the participating Nodes in the Cluster need to be of Similar Hardware Configuration.
Advantages
1. Provides Automatic Failover of the SQL Instance to the Participating Node (Passive Node), hence no manual configuration is required when failover occurs.
2. Is not related to the Recovery model of the Databases.
3. Application that rely on more than one Database of an Instance, do not need changes as all the Database are available upon failover, where as in other 3 HA features, the dependent databases also have to be configured for availability.
Dis-advantages
1. Purely relying on Failover Clustering is not suggested since a Data Disk Failure would result in not having another copy of the Databases to Fallback immediately.
2. There is no redundant copy of the Database; hence if a Reporting Application requires the same copy of the Transactional Database, then it has to rely on the existing Database impacting the performance of the main application.
3. Cannot be implemented with distributed systems, the Nodes are required to be within 100 Miles ( I remember reading in BOL )

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Types of Clusters ?
In Windows we can configure two types of clusters
1. NLB (network load balancing): cluster for balancing load between servers. This cluster will not provide any high availability. Usually preferable at edge servers like web or proxy.
2. Server Cluster: This provides High availability by configuring active-active or active-passive cluster.
In 2 node active-passive cluster one node will be active and one node will be stand by.
When active server fails the application will FAILOVER to stand by server automatically. When the original server backs we need to FAILBACK the application

How many nodes can have in a Windows cluster?
What is the Maximum number of supported nodes in a cluster?

Operating System
Nodes
Windows Server 2014, Enterprise x64 Edition
Need to Launch
Windows Server 2012, Enterprise x64 Edition
1-64 Nodes
Windows Server 2012, Enterprise Standard
1-2 Nodes
Windows Server 2008, Enterprise x64 Edition
Windows Server 2008, Datacenter x64 Edition
Windows Server 2008 R2 Enterprise 
Windows Server 2008 R2 Datacenter 
Microsoft Hyper-V Server 2008 R2
Note:Windows Server 2008 X64 : up to 16 Nodes
Windows Server 2008 X86: up to 8 Nodes(not in R2)
Windows Server 2008 IA64: up to 8 Nodes
==========================================================
1-16 Nodes
Windows Server 2003, Enterprise Edition
Windows Server 2003, Enterprise x64 Edition
Windows Server 2003, Enterprise Edition for Itanium-based Systems
Windows Server 2003, Datacenter Edition
Windows Server 2003, Datacenter x64 Edition
Windows Server 2003, Datacenter Edition for Itanium-based Systems
==========================================================
1-16 Nodes
Windows 2000 Datacenter Server 1-4 Fibre Channel
==========================================================
1-4 Nodes
Windows NT 4.0 Enterprise Edition
Windows 2000 Advanced Server 
Windows 2000 Datacenter Server 
Windows Server 2003, Enterprise Edition
Windows Server 2003, Enterprise x64 Edition 
Windows Server 2003, Datacenter Edition 
Windows Server 2003, Datacenter x64 Edition                         
Windows NT 4.0 Enterprise Edition 
Windows 2000 Advanced Server
1-2 Nodes





How many IP addresses/names do you need for 2 node cluster? 
 Here’s a list:
IP(Public & Private)  Required :( Check below for more details)
------------------------------------------------------------------------------------------------------------------------------------
1 : For Sql Server Clustering : 2 node Active/Passive Cluster with 1 SQL Instance ? How many ip:7
2 : For Sql Server Clustering : 2 node Active/Passive Cluster with 2 SQL Instance  ?how many  ip:8
Require IP Address/Names for 2 Node SQL/Windows Cluster:

No.IP
Description
Hostname
IP Address
Subnet Mask
Default Gateway
IP Add:1
Cluster IP Address
XXCLUSTER
192.168.1.3
255.255.255.0
N/A
IP Add:2
SQL Instance IP Address
XX2010SQL
192.168.1.5
255.255.255.0
N/A
IP Add:3
SQL Instance IP Address
XX2010SQL
192.168.1.6
255.255.255.0
N/A
IP Add:4
MSDTC Virtual IP
XX2010SQLDtc
192.168.1.4
255.255.255.0
N/A
IP Add:5
SQL Cluster Node 1
Node1
192.168.1.1
255.255.255.0
172.21.X.1
IP Add:6
SQL Cluster Node 2
Node 2
192.168.1.2
255.255.255.0
172.21.X.1
IP Add:7
HeartBeat interface on Node1
Node1
10.10.10.1
255.0.0.0
N/A
IP Add:8
HeartBeat interface on Node1
Node 2
10.10.10.2
255.0.0.0
N/A




Detail Description Cluster Expressions and Descriptions ( IP Address and Name Conversions)

Parameter
Expressions
Example
Desc
Domain Name
MyDomain.com
jayant.com
Node 1 Name
ClusterNode1
ClusterNode1
Node 2 Name
ClusterNode2
ClusterNode2
Node 1 Public Network IP Address/Mask
192.168.1.1/255.255.255.0
192.168.1.1/255.255.255.0
IP Add:1
Node 2 Public Network IP Address/Mask
192.168.1.2/255.255.255.0
192.168.1.2/255.255.255.0
IP Add:2
Private Network IP Address on Node1
10.10.10.1/255.0.0.0
10.10.10.1/255.0.0.0
IP Add:3
Private Network IP Address on Node2
10.10.10.2/255.0.0.0
10.10.10.2/255.0.0.0
IP Add:4
Admin Account Name and Password
Administrator/P@sswOrd101
UserID/P@sswOrd101
UID1
Windows Cluster Virtual Name
WindowsCLUSTER
WindowsCLUSTER
Windows Cluster IP Address
192.168.1.3/255.255.255.0
192.168.1.3/255.255.255.0
IP Add:5
MSDTC IP Address
192.168.1.4/255.255.255.0
192.168.1.4/255.255.255.0
IP Add:6
MSDTC Network Name
MSDTC
MSDTC
Virtual SQL Server Name (default or named)/SQL Inst1
SQLCLUSTER\MyInstance1
Jayant\SQLServerInst1
Virtual SQL Instance1   IP Address
192.168.1.5/255.255.255.0
192.168.1.5/255.255.255.0
IP Add:7
Virtual SQL Server Name (default or named)/SQL Inst2
SQLCLUSTER\MyInstance
Jayant\SQLServer
Virtual SQL Instance2   IP Address
192.168.1.6/255.255.255.0
192.168.1.6/255.255.255.0
IP Add:8
Cluster Service Account Name and Password
ClusterSVC/P@sswOrd101
ClusterSVC/P@sswOrd101
UID2
SQL Service Account Name and Password
SQL2K5SVC/P@sswOrd101
SQL2K5SVC/P@sswOrd101
UID3
SQL Server Domain Group Name
SQL Server Admins
SQL Server Admins
MSDTC Disk Letter
M:
M:
Quorum Disk Letter
Q:
Q:
Share Drives: Drive letter for SQL Server database files
N, O, P
N, O, P

How to add New nodes to fail over cluster installation?Click below for more details

MS SQL Server 2012 - Add Node to fail over cluster Installation
Or

Add node in SQL Server 2008, SQL Server 2008r2 and SQL Server2012 (GOOD)

=============================================================================
Windows Server 2008 R2 Cluster Terminology
Before failover or NLB clusters can be designed and implemented, the administrator deploying the solution should be familiar with the general terms used to define the clustering technologies. The following list contains the many terms associated with Windows Server 2008 R2 clustering technologies:
  • Cluster— A cluster is a group of independent servers (nodes) that are accessed and presented to the network as a single system. 
  • Node— A node is an individual server that is a member of a cluster. 
  • Cluster resource— A cluster resource is a service, application, IP address, disk, or network name defined and managed by the cluster. Within a cluster, cluster resources are grouped and managed together using cluster resource groups, now known as Services and Applications groups. 
  • Services and Applications group— Cluster resources are contained within a cluster in a logical set called a Services and Applications group or historically referred to as a cluster group. Services and Applications groups are the units of failover within the cluster. When a cluster resource fails and cannot be restarted automatically, the Services and Applications group this resource is a part of will be taken offline, moved to another node in the cluster, and the group will be brought back online. 
  • Client Access Point— A Client Access Point is a term used in Windows Server 2008 R2 failover clusters that represents the combination of a network name and associated IP address resource. By default, when a new Services and Applications group is defined, a Client Access Point is created with a name and an IPv4 address. IPv6 is supported in failover clusters but an IPv6 resource either needs to be added to an existing group or a generic Services and Applications group needs to be created with the necessary resources and resource dependencies. 
  • Virtual cluster server— A virtual cluster server is a Services or Applications group that contains a Client Access Point, a disk resource, and at least one additional service or application-specific resource. Virtual cluster server resources are accessed either by the domain name system (DNS) name or a NetBIOS name that references an IPv4 or IPv6 address. A virtual cluster server can in some cases also be directly accessed using the IPv4 or IPv6 address. The name and IP address remain the same regardless of which cluster node the virtual server is running on. 
  • Active node— An active node is a node in the cluster that is currently running at least one Services and Applications group. A Services and Applications group can only be active on one node at a time and all other nodes that can host the group are considered passive for that particular group. 
  • Passive node— A passive node is a node in the cluster that is currently not running any Services and Applications groups.
  •  
  • Active/passive cluster— An active/passive cluster is a cluster that has at least one node running a Services and Applications group and additional nodes the group can be hosted on, but are currently in a waiting state. This is a typical configuration when only a single Services and Applications group is deployed on a failover cluster. 
  • Active/active cluster— An active/active cluster is a cluster in which each node is actively hosting or running at least one Services and Applications group. This is a typical configuration when multiple groups are deployed on a single failover cluster to maximize server or system usage. The downside is that when an active system fails, the remaining system or systems need to host all of the groups and provide the services and/or applications on the cluster to all necessary clients. 
  • Cluster heartbeat— The cluster heartbeat is a term used to represent the communication that is kept between individual cluster nodes that is used to determine node status. Heartbeat communication can occur on a designated network but is also performed on the same network as client communication. Due to this internode communication, network monitoring software and network administrators should be forewarned of the amount of network chatter between the cluster nodes. The amount of traffic that is generated by heartbeat communication is not large based on the size of the data but the frequency of the communication might ring some network alarm bells. 
  • Cluster quorum: A shared storage need to provide for all servers which keeps information about clustered application and session state and is useful in FAILOVER situation. This is very important if Quorum disk fails entire cluster will fails.
     The cluster quorum maintains the definitive cluster configuration data and the current state of each node, each Services and Applications group, and each resource and network in the cluster. Furthermore, when each node reads the quorum data, depending on the information retrieved, the node determines if it should remain available, shut down the cluster, or activate any particular Services and Applications groups on the local node. To extend this even further, failover clusters can be configured to use one of four different cluster quorum models and essentially the quorum type chosen for a cluster defines the cluster. For example, a cluster that utilizes the Node and Disk Majority Quorum can be called a Node and Disk Majority cluster. 
  • Cluster witness disk or file share— The cluster witness or the witness file share are used to store the cluster configuration information and to help determine the state of the cluster when some, if not all, of the cluster nodes cannot be contacted. 
  • Generic cluster resources— Generic cluster resources were created to define and add new or undefined services, applications, or scripts that are not already included as available cluster resources. Adding a custom resource provides the ability for that resource to be failed over between cluster nodes when another resource in the same Services and Applications group fails. Also, when the group the custom resource is a member of moves to a different node, the custom resource will follow. One disadvantage or lack of functionality with custom resources is that the Failover Clustering feature cannot actively monitor the resource and, therefore, cannot provide the same level of resilience and recoverability as with predefined cluster resources. Generic cluster resources include the generic application, generic script, and generic service resource. 
  • Shared storage— Shared storage is a term used to represent the disks and volumes presented to the Windows Server 2008 R2 cluster nodes as LUNs. In particular, shared storage can be accessed by each node on the cluster, but not simultaneously. 
  • Cluster Shared Volumes— A Cluster Shared Volume is a disk or LUN defined within the cluster that can be accessed by multiple nodes in the cluster simultaneously. This is unlike any other cluster volume, which normally can only be accessed by one node at a time, and currently the Cluster Shared Volume feature is only used on Hyper-V clusters but its usage will be extended in the near future to any failover cluster that will support live migration. 
  • LUN— LUN stands for Logical Unit Number. A LUN is used to identify a disk or a disk volume that is presented to a host server or multiple hosts by a shared storage array or a SAN. LUNs provided by shared storage arrays and SANs must meet many requirements before they can be used with failover clusters but when they do, all active nodes in the cluster must have exclusive access to these LUNs.
  • Failover — Failover is the process of a Services and Applications group moving from the current active node to another available node in the cluster when a cluster resource fails. Failover occurs when a server becomes unavailable or when a resource in the cluster group fails and cannot recover within the failure threshold. 
  • Failback— Failback is the process of a cluster group automatically moving back to a preferred node after the preferred node resumes operation. Failback is a nondefault configuration that can be enabled within the properties of a Services and Applications group. The cluster group must have a preferred node defined and a failback threshold defined as well, for failback to function. A preferred node is the node you would like your cluster group to be running or hosted on during regular cluster operation when all cluster nodes are available. When a group is failing back, the cluster is performing the same failover operation but is triggered by the preferred node rejoining or resuming cluster operation instead of by a resource failure on the currently active node. 
  • Live Migration— Live Migration is a new feature of Hyper-V that is enabled when Virtual Machines are deployed on a Windows Server 2008 R2 failover cluster. Live Migration enables Hyper-V virtual machines on the failover cluster to be moved between cluster nodes without disrupting communication or access to the virtual machine. Live Migration utilizes a Cluster Shared Volume that is accessed by all nodes in the group simultaneously and it transfers the memory between the nodes during active client communication to maintain availability. Live Migration is currently only used with Hyper-V failover clusters but will most likely extend to many other Microsoft services and applications in the near future. 
  • Quick Migration— With Hyper-V virtual machines on failover clusters, Quick Migration provides the option for failover cluster administrators to move the virtual machine to another node without shutting the virtual machine off. This utilizes the virtual machine’s shutdown settings options and if set to Save, the default setting, performing a Quick Migration will save the current memory state, move the virtual machine to the desired node, and resume operation shortly. End users should only encounter a short disruption in service and should reconnect without issue depending on the service or application hosted within that virtual machine. Quick Migration does not require Cluster Shared Volumes to function. 
  • Geographically dispersed clusters— These are clusters that span physical locations and sometimes networks to provide failover functionality in remote buildings and data centers, usually across a WAN link. These clusters can now span different networks and can provide failover functionality, but network response and throughput must be good and data replication is not handled by the cluster. 
  • Multisite cluster— Geographically dispersed clusters are commonly referred to as multisite clusters as cluster nodes are deployed in different Active Directory sites. Multisite clusters can provide access to resources across a WAN and can support automatic failover of Services and Applications groups defined within the cluster. 
  • Stretch clusters— A stretch cluster is a common term that, in some cases, refers to geographically dispersed clusters in which different subnets are used but each of the subnets is part of the same Active Directory site—hence, the term stretch, as in stretching the AD site across the WAN. In other cases, this term is used to describe a geographically dispersed cluster, as in the cluster stretches between geographic locations.

Maximum number of supported nodes in a cluster

Subscribe to: Posts (Atom)