Clustering - Looks alive & IS alive

Looks Alive Check:
This check performs a basic verification that the SQL Server service is running on the hosted node which should be online on a given interval of time. The default time that has been set is 5 seconds.

In case the check fails, the cluster service performs another check which is very thororugh in nature called the IsAlive Check to verify the failure. The LooksAlive check is also known as Basic resource health check in Windows Server 2008.

Is Alive check:
This process checks and verifies the cached result of the internal IsAlive process in the SQL Server resource DLL. The internal IsAlive process runs every 60 seconds and verifies if SQL server is online or not. The check uses SELECT @@SERVERNAME to verify the state of the SQL Server.

In case that the query fails, it runs an additional retry login to avoid failures. On the event of retry logic failure, the internal IsAlive process shuts down the SQL server service and a failover event is triggered. The IsAlive check is also known as the Thorough resource health check in Windows Server 2008.

Frequently Asked Questions (Server Clusters: Quorum Options - Windows Server 2003)

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What is a Majority Node Set cluster?
It is a cluster that has a quorum based on local disks in each node, rather than a shared disk.
How is the quorum information located on the system disk of each node kept in synch?
The server cluster infrastructure ensures that all changes are replicated and updated on all members in a cluster.
Can this method be used to replicate application data as well?
No, that is not possible in this version of clustering. Only Quorum information is replicated and maintained in a synchronized state by the clustering infrastructure.
Can I convert a standard cluster to an MNS cluster?
Yes. You can use Cluster Administrator to create a new Majority Node Set resource and then, on the cluster properties sheet Quorum tab, change the quorum to that Majority Node Set resource.
What is the difference between a geographically dispersed cluster and an MNS cluster?
A geographic cluster refers to a cluster that has nodes in multiple locations, while an MNS-based cluster refers to the type of quorum resources in use. A geographic cluster can use either a shared disk or MNS quorum resource, while an MNS-based cluster can be located in a single site, or span multiple sites.
What is the maximum number of nodes in an MNS cluster?
Windows Server 2003 supports 8-node clusters for both Enterprise Edition and Datacenter Edition.
Do I need special hardware to use an MNS cluster?
There is nothing inherent in the MNS architecture that requires any special hardware, other than what is required for a standard cluster (for example, there must be on the Microsoft Cluster HCL). However, some situations that use an MNS cluster may have unique requirements (such as geographic clusters), where data must be replicated in real time between sites.
Does a cluster aware application need to be rewritten to support MNS?
No, using an MNS quorum requires no change to the application. However, some cluster aware applications expect a shared disk (for example SQL Server 2000), so while you do not need shared disks for the quorum, you do need shared disks for the application.
Does MNS get rid of the need for shared disks?
It depends on the application. For example, clustered SQL Server 2000 requires shared disk for data. Remember, MNS only removes the need for a shared disk quorum.
If I have a 2-node MNS cluster, and lose one server, will the cluster continue to function?
No, in order to keep an MNS cluster running, it must have a majority of nodes online, i.e. (<Number of nodes configured in the cluster>/2) + 1. The following table shows the various combinations of configured nodes and node failures:

 

Number of nodes configured in the cluster	Number of node failures
1	0
2	0
3	1
4	1
5	2
6	2
7	3
8	3

How do I back up and restore an MNS cluster?
There is a separate white paper on backing up and restoring clustered configurations. It will be published at the same location as this paper.
Is there a way I can allow for a “minority set” to take control of the cluster?
Yes, there is a way for a “minority” set to be allowed to start up and initialize the cluster. But this is a manual process and has to be done in a specified manner. Details on the same are available in “help”.
What happens if majority count is lost?
The cluster service will gracefully shutdown the cluster and all resources. Clients will lose connectivity and access to any of the clustered services. This is done to prevent the “split-brain” scenario.
Are there any limitations with regard to network latency and topography in an MNS cluster?
Requirements are the same as that for vanilla clusters. With regard to topography, we envisage the MNS feature to be predominantly used in geographically dispersed clustering scenarios. This normally means specific semantic requirements in terms of storage usable and management. OEMs provide prescriptive guidance on the same and customers should carefully read the same.
For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at http://www.microsoft.com/windowsserver2003.

What happens to a running Cluster if the quorum disk fails in Windows Server 2003 Cluster?

 In Windows Server 2003, the Quorum disk resource is required for the Cluster to function. In your example, if the Quorum disk suddenly became unavailable to the cluster then both nodes would immediately fail and not be able to restart the clussvc.



In that light, the Quorum disk was a single point of failure in a Microsoft Cluster implementation. However, it was usually a fairly quick workaround to get the cluster back up and operational. There are generally two solutions to that type of problem.


 1. Detemrine why the Quorum disk failed and repair.

2. Reprovision a new LUN, present it to the cluster, assign it a drive letter and format.

Then start one node with the /FQ switch and through cluadmin designate the new disk resource as the Quorum.

Then stop and restart the clussvc normally and then bring online the second node.








What happens to a running Cluster if the quorum disk fails in Windows Server 2008 Cluster?


 Cluster continues to work but failover will not happen in case of any other failure in the active node.

Keeping backups of Cluster Logs

 

 

 

 

In a previous blog, Understanding the Cluster Debug Log in 2008, you were given the information on how Cluster logging in Windows 2008 Failover Clustering and beyond has changed from the earlier versions. In this blog, you were shown how the size of the log can be manipulated in order to keep a recommended 72 hours’ worth of data. Just to recap:

‘It is generally recommended that your CLUSTER.LOG have at least 72 hours’ worth of continuous data retention. This is so that if you have a failure occur after you went home on Friday, you still have the data you need to troubleshoot the issue on Monday morning’

What if you wanted to get information from further back (i.e. a week, a month, etc)? One of the ways you could do this is to increase the size of the log with the /SIZE: switch. However, increasing the size for say a month could get you into gigabytes of space being used and text files being massive and hard to go through. Have you ever tried to open a 1 gigabyte text file with Notepad?
Here is a way that you can keep the file at a smaller size and keep backups that can be referred back to at any time. First, you must determine what size is needed to hold 24 hours’ worth of data. This way, you can have a Cluster Log generated for every day. The next thing to consider is where you want to store the files, local or network share. What if you wanted to do this for multiple Clusters? Let’s say that you figured that you need the log size to be at 200meg and you are going to put it on a server (JOHNMARLIN).
The previous blog mentioned will have you run the command Cluster Log /Size:200 to set the proper size based on the data needed. I do this for all my Clusters. I then go out to my JOHNMARLIN server and create a share for each Cluster (TXCLUSTER, NCCLUSTER, etc). Now I just have to go to one node in each of the Clusters to set things up.
On the node you doing the task on, go into Control Panel - Region and Language and change the Short date to yyyy-MM-dd.

On this node, you could create a CLUSTERLOG folder off the root of Drive C:. In this C:\CLUSTERLOG directory, create a batch file called Get-Logs.bat that has the following commands:

Net use j: /d
Net use j: \\johnmarlin\txcluster
Md j:\%date%
Cluster log /gen /copy:"c:\clusterlog"
Copy c:\clusterlog\*.log j:\%date%\*.log
Net use j: /d

I used Drive Letter J:, but you can use any available letter. So what the batch file will do when run today (June 18, 2012) is:
1. It will create a folder on the share named by the date

a. 2012-06-18

2. It will generate the Cluster on every node
3. It will copy the cluster logs from all nodes to the local c:\clusterlog folder and tag the Node Name as part of the filename

a. TXCLUSTER-node1_cluster.log
b. TXCLUSTER-node2_cluster.log
c. TXCLUSTER-node3_cluster.log
d. TXCLUSTER-node4_cluster.log

4. It will copy the cluster logs from this c:\logs folder to the share folder with the date and keeping the same name

a. \2012-06-18\TXCLUSTER-node1_cluster.log
b. \2012-06-18\TXCLUSTER-node2_cluster.log
c. \2012-06-18\TXCLUSTER-node3_cluster.log
d. \2012-06-18\TXCLUSTER-node4_cluster.log

When it runs the next day:
1. It will create a folder on the share named by the date

a. 2012-06-19

2. It will generate the Cluster on every node
3. It will copy the cluster logs from all nodes to the local c:\clusterlog folder and tag the Node Name as part of the filename

a. TXCLUSTER-node1_cluster.log
b. TXCLUSTER-node2_cluster.log
c. TXCLUSTER-node3_cluster.log
d. TXCLUSTER-node4_cluster.log

4. It will copy the cluster logs from this c:\clusterlog folder to the share folder with the date keeping the same name

a. \2012-06-19\TXCLUSTER-node1_cluster.log
b. \2012-06-19\TXCLUSTER-node2_cluster.log
c. \2012-06-19\TXCLUSTER-node3_cluster.log
d. \2012-06-19\TXCLUSTER-node4_cluster.log

It runs the next day, it creates the next dated folder and files. This way, you have an easily sorted folder structure that you can go to any day you want and get the file you need from whichever node you need.
The next thing to do is set up a Scheduled Task to run each day so it creates the files for you. This way, you do not have to remember to do it. From the Administrative Tools, open up Task Scheduler and select Create Task. You can then use the below information to create the task.
A. General Tab

i. For the Name, call it something like Cluster Daily Log Backups
ii. make sure use an account that has admin rights to this node, to the Cluster, and the network share
iii. select Run whether user is logged in or not
iv. You will also need to select Run with highest privileges

B. Triggers Tab

i. Set whatever time you want it to run.  One thing to keep in mind is that the Cluster Log is in GMT time, so account for it when deciding when to have them created
ii. Select it to run daily and recur for 352 days
iii. Make sure is Enabled

C. Actions Tab

i. Program/Script will be CMD.EXE
ii. Add Arguments will be /C C:\Logs\Get-Logs.bat

D. Conditions Tab

i. Don't really need change anything unless want to

E. Settings Tab

i. Check Allow task to be run on demand
ii. Check Run task as soon as possible after scheduled start is missed

So now you have your task that will do this for you. You can now just sit back and relax knowing that you will have a Cluster Log generated for every node every day.
There are a couple caveats to this that you must take into consideration. If the account you are using has its password changed on the domain, you will have to change it on the task as well.  It will stop running after 352 days, so if you want more, you would have to create it again.  But you will have a year's worth of Cluster Logs when it is done.
There are other ways of doing this. You could use scripting and the PowerShell command:

Get-ClusterLog –Destination

You could also use other methods than the batch file. This is just one of the ways of doing it.



Cluster comdlet :


https://technet.microsoft.com/en-us/library/ee461043.aspx

Finding out root cause for Cluster Failovers

We do get quite a few issues regarding root cause analysis for Cluster Failovers. Failovers mostly happen due to the IsAlive check failing for the SQL Server resource after which the following two




conditions arise:
1. SQL Server service restarts on the same cluster node
2. SQL Server resource fails over to a member cluster node
So, for looking into the possible root causes of a cluster failover, a SQL version of the MPS Reports capture is required from the node on which SQL is currently active. From the data requested by the



PSS Engineer, the following files would be of utmost importance:
1. All the SQL Server ERRORLOGs
2. Windows Event Logs (System/Application)
3. Cluster Log





Based on the SQL Server ERRORLOGs, we would check for any errors or tell-tale signs which would point us to why the IsAlive check failed for the SQL Server resource. After that, we would look into the cluster log and the windows event logs to find out co-relation among the events during the failover time on the server.
Since, the cluster log rolls over and also the SQL Server ERRORLOGs can roll over very quickly if a job is in place to recycle if after a certain size, it is a very good idea to save the cluster log and the SQL Server ERRORLOG(s) right after the failover to prevent them from rolling over and overwriting valuable data from the problem time period.
Sometimes, a post mortem analysis provides us a hypothesis of what happened but doesn’t paint the picture completely due to lack of data from the period the problem happened. Based on the nature of the problem, the PSS Engineer might ask to you to do the following for the the next problem


occurrence along :
1. Capture a light-weight PSSDIAG round the clock with file rollover so that we can track what sort of events were happening on the SQL instance right before the failover.


2. Or a filtered dump of the SQL Process during the problem period if there is heavy blocking on the server or if the failover had occurred due to memory dump(s) on the server


3. OR a round the clock Perfmon log if there were possible external memory pressure on the server.
NOTE: Keep in mind that the cluster logs are always in GMT format. So you need to add/substract the time difference between your timezone and GMT when analyzing the cluster logs.

Cluster failover logs needed for root cause analysis

Purpose:
  Logs required for analysis
Overview:

• Sudden Failover of cluster node.
• Switching between nodes.
• Unable to run one cluster group on a specific node, but other node no.
• Cannot start SAP or DB after some maintenance on one specific node.

Procedure:

1. Timestamp of when issue occurred.
2. Windows event viewer logs.
. Open the Event Viewer with "Start" -> "Control Panel" -> "Administrative Tools" -> "Event Viewer". Alternatively, use the command "eventvwr.exe".

• Windows Server 2003: Right-click the relevant logs and choose "Save Log File as". Save as type "Event Log" (evt format).

• Windows Server 2008: In the "Windows Logs" category, right-click the relevant event logs and choose "Save Events as". Save as type "Event Files" (evtx format).

 Compress the files (preferably use the "zip" format, e.g. use tool 7-ZIP from http://www.7-zip.org which has the best compression of all zip tools). You can also use sapcar.exe to compress the files, if no zip tool is available.
 Attach files to the incident.
 3. Windows Cluster log.  In Windows 2003 this is located at /system32/cluster  name of the log is cluster.log, For Windows 2008 or Windows 2008R2 you can use the cluster.exe command line
CLUSTER [cluster-name] LOG /GEN /COPY:"pathname A detailed trace log from each of the nodes is generated and copied to the path you specify. Need to attach several pages from the time of the failover
4. Trace files from the work directory of the failing instance ie ASCS or SCS in zip formatZip and attach  dev_disp, dev_w*, dev_ms, dev_rd. the stderr files, sapstartsrv and sapstart.log
Again use 7-ZIP to compress the files or sapcar.exe if no zip application is avaible

MSDTC Service will not start after SQL Service Pack is applied

Recently a team in our company rolled out SQL service packs to a number of different servers (both SQL Server 2005 and 2008). When I was asked to check the state of the server afterwards, I noticed the MSDTC (Distributed Transaction Coordinator) service would not start.

The System Log reported the following error : 

Event ID : 7024

Details : The Distributed Transaction Coordinator service terminated with service-specific error %%-1073737712. 

and the Application Log included the following errors :

 Event ID : 4407

Details  : MS DTC Tracing infrastructure : the attempt to flush the existing trace data failed. Internal Information : none available.

 Event ID : 4404

Details : MS DTC Tracing infrastructure : the initialization of the tracing infrastructure failed. Internal Information : none available. 

 Event ID : 4163

Details : MS DTC log file not found. After ensuring that all Resource Managers coordinated by MS DTC have no indoubt transactions, please run msdtc -resetlog to create the log file. 

I checked the account the Distributed Transaction Coordinator service was running under, and re-applied the default security (NETWORK SERVICE account with a blank password) just to make sure. This made no difference.
After re-reading the Event ID 4163, it mentioned the log file was not found. The MSDTC log resides in C:\Windows\System32\Msdtc. I checked this directory and found the NETWORK SERVICE account had no permissions.
To fix the above issue, I gave the NETWORK SERVICE account full control of the C:\Windows\System32\Msdtc directory.
Once this was done, the Distributed Transaction Coordinator service started without any issues. I can only assume the SQL service pack applied on this server removed or changed permissions on this directory.

How to Move the Quorum (Witness) Disk to Another Node in a Failover Cluster

I have recently had issues with a Server 2008 Failover Cluster where one node was rebooted, then wouldn't join the cluster again, causing issues. All clustered services were manually failed over to the second node before reboot, but the witness (or quorum) disk was still owned by the first node. Usually on a reboot the second node would have taken ownership of this.

For some reason this process didn't happen so when Node 1 came back up, it thought Node 2 owned the cluster and tried to join. Node 2 rejected this request saying Node 1 owned the cluster - at this point, Node 1 tried to start a new cluster but wasn't able to take the witness disk away from Node 2, which currently owned that resource.

After much deliberation, we finally rebooted both nodes and this time the cluster was gracefully established.

Anyway, lesson learned and from now on I will be manually failing over the witness disk if it is currently owned by a node I am about to restart.

To find which cluster node currently owns a witness disk, you can check in Failover Cluster Manager to see which node owns the "Disk Witness in Quorum".

You can also open a command prompt and enter the command

cluster group

This will list all cluster resources  as follows :

Listing status for all available resource groups:

Group                Node            Status
-------------------- --------------- ------
Cluster Group        NODE1 Online
Available Storage    NODE1 Online
SQL Server (INSTANCE1)  NODE2 Online
SQL Server (INSTANCE6)  NODE1 Online
SQL Server (INSTANCE3)  NODE1 Online
SQL Server (INSTANCE4)  NODE1 Online
SQL Server (INSTANCE7)  NODE1 Online
SQL Server (INSTANCE5)  NODE1 Online

From this, you can see the the "Cluster Group" is currently owned by NODE1 - the quorum disk resides in this group. To move it to the other node, you can enter the command

cluster group "Cluster Group" /move

You would then see something like

Moving resource group 'Cluster Group'...

Group                Node            Status
-------------------- --------------- ------
Cluster Group        NODE2 Online

If you had more than 2 nodes in the cluster, you could choose a specific node as follows

cluster group "Cluster Group" /moveto:node4

Source: http://www.greytrust.com

Installing Failover Clustering With Windows Server 2008 R2

Creating a failover clustering means you have at least two servers connected to a shared storage. 

Failover Clustering System Requirement:

• Windows Server 2008/R2 : Failover Clustering feature is available with Windows Server 2008/R2 Enterprise/Data Center editions. You don't have this feature with the Standard edition of Windows Server 2008/R2.
• Domain role: All servers in the cluster must be in the same Active Directory domain.
• DNS: The servers in the cluster must be using Domain Name System (DNS) for name resolution.
• Account for administering the cluster : When you create a cluster or add servers to it, you must be logged on to the domain with an account that has administrator rights on all servers in that cluster ( if the account is not a Domain Admins account, the account must be given the Create Computer Objects and Read All Properties permissions in the domain ).
• Servers : Two identical servers in brand, model and configurations.
• Device Controllers ( HBA ) : i/SCSI or Fiber , both also to be the identical.
• Storage : You must use shared storage that is compatible with Windows Server 2008 R2.

Now that you know the requirement for Failover Clustering, lets start:

Configuration on Server A

1. To install Failover feature, open Server Manager, click on Start > Administrative Tools > Server Manager
   
2. Expand Features, and then click on Add Feature.
   
   
   
   The list of available features will be listed, select the Failover Clustering and click on Next
   
   
   
   Click Install
   
   
3. The Failover Clustering feature will be installed. Click Close
   
   

Configuration on Server B

1. Again on Server B, we will need to install Failover Clustering feature as well, so click on Start > All Programs > Administrative Tools >Server Manager
   
   
   
   Click on Features and then click on Add Features
   
   
2. Choose the Failover Clustering feature and click Next
   
   
3. Confirm installing Failover Clustering by clicking on Install
   
   Close the Add Features Wizard once installation is completed. 
   
   

Now that both servers have Failover Clustering feature installed on them, we can create the cluster on one of these server and join the other one to the cluster.

Now, we need to open and configure our cluster name, IP and nodes.

To open Failover Clustering, click on Start > Administrative Tools > Failover Cluster Manager

>> This needs to be done on a single server only <<

1. The first step in creating a successful failover clustering, is by validating the existing systems and shared storage. This is done by the optionValidate a Configuration
   
   
   
   When you click on Validate a Configuration, you will need to browse and add the Cluster nodes, these are the servers that will be part of the cluster, then click Next
   
   
   
   Choose to Run all tests and click Next
   
   
   
   The available tests will be displayed in the confirmation window, click Next to begin validating your cluster
   
   
   
   
   
   
   Review the validation report, as your configuration might have few issues with it and needs to be addresses before setting up your cluster.
   
   
2. Now that the configuration is validated and you are ready to setup your cluster. Click on the second option, Create a Cluster, the wizard will launch, read it and then click Next
   
   
3. You need to add the names of the servers you want to have in the cluster. You can start creating your cluster with a single server and then add other nodes in the future.
   
   Browse to your servers and then once all the servers ( nodes ) are listed, click Next
   
   
4. After the servers are selected, you need to type a name and IP for your Cluster
   
   
5. On the Confirmation window, review your settings. The following will be displayed in this window: cluster name and IP address, selected servers name. If all info is proper, then click Next. Else click Previous and correct which setting needs to be adjusted.
   
   
   
   After you click Next, creating the cluster will begin.
6. The summary windows will be displayed after a successful setup of the cluster. 
   
   
7. Open Failover Cluster Manager and you will see your nodes and setting inside the MMC. Here you can configure your cluster, add new nodes, remove nodes, add more disk storage and so on.
   
   
   

Summary

In this article, I have created a two node cluster using Failover Clustering feature which is available with Windows Server 2008 R2 Enterprise and Data Center editions.

source : http://www.elmajdal.net/

PART 1

PART 2

PART 3 

PART 4

Maximum number of supported nodes in a cluster

The Windows Server Failover Clustering feature supports a certain maximum number of servers in a cluster. Servers in a Failover Cluster are also called nodes. The maximum number of nodes varies depending on the version of the operating system.

The following table outlines the maximum number of nodes that are supported in a cluster and the required shared disk configuration.

Operating System	Number of nodes	Storage
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	1-2	SCSI
Windows NT 4.0 Enterprise Edition Windows 2000 Advanced Server	1-2	Fibre Channel
Windows 2000 Datacenter Server	1-4	Fibre Channel
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 Windows Server 2008, Enterprise Edition Windows Server 2008, Enterprise Edition for Itanium-based Systems Windows Server 2008, Datacenter Edition Windows Server 2008, Datacenter Edition for Itanium-based Systems	1-8	Fibre Channel, iSCSI, or SAS
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	1-16	Fibre Channel, iSCSI, or SAS

Properties

Article ID: 288778 - Last Review: March 20, 2012 - Revision: 11.0

APPLIES TO

• Microsoft Windows Server 2003, Enterprise Edition (32-bit x86)
• Microsoft Windows Server 2003, Datacenter Edition (32-bit x86)
• Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
• Microsoft Windows Server 2003, Datacenter Edition for Itanium-Based Systems
• Microsoft Windows Server 2003, Enterprise x64 Edition
• Microsoft Windows Server 2003, Datacenter x64 Edition
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows NT Server 4.0 Enterprise Edition
• Windows Server 2008 Datacenter without Hyper-V
• Windows Server 2008 Enterprise without Hyper-V
• Windows Server 2008 for Itanium-Based Systems
• Windows Server 2008 Datacenter
• Windows Server 2008 Enterprise
• Windows Server 2008 R2 Enterprise
• Windows Server 2008 R2 Datacenter
• Microsoft Hyper-V Server 2008 R2

Keywords:

kbclustering kbenv kbinfo w2000mscs KB288778

Windows Cluster Interview Questionsand Answers

Here are some windows cluster Interview Questionsand Answers for windows administrator

What is Clustering? Briefly define & explain it?

 Clustering is a technology, which is used to provide High Availability for mission critical applications. We canconfigure cluster by installing MCS (Microsoft cluster service) component from Add remove programs, which can onlyavailable in Enterprise Edition and Data center edition.

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 highavailability. 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 nodeactive-passive cluster one node will be active and one node will be stand by. When active server fails the applicationwill FAILOVER to stand by server automatically. When the original server backs we need to FAILBACK theapplication

What is Quorum ?

 A shared storage need to provide for all servers which keeps information about clusteredapplication and session state and is useful in FAILOVER situation. This is very important if Quorum disk fails entirecluster will fails.

Why Quorum is necessary ?

 When network problems occur, they can interfere with communication between cluster nodes. A small set of nodesmight be able to communicate together across a functioning part of a network, but might not be able to communicate

with a different set of nodes in another part of the network. This can cause serious issues. In this “split” situation, at

least one of the sets of nodes must stop running as a cluster.To prevent the issues that are caused by a split in the cluster, the cluster software requires that any set of nodesrunning as a cluster must use a voting algorithm to determine whether, at a given time, that set has quorum. Becausea given cluster has a specific set of nodes and a specific quorum configuration, the cluster will know how many

“votes” constitutes a majority (that is, a quorum). If the number drops below the majority, the cluster stops running.

Nodes will still listen for the presence of other nodes, in case another node appears again on the network, but thenodes will not begin to function as a cluster until the quorum exists again.

For example, in a five node cluster that is using a node majority, consider what happens if nodes 1, 2, and 3 cancommunicate with each other but not with nodes 4 and 5. Nodes 1, 2, and 3 constitute a majority, and they continuerunning as a cluster. Nodes 4 and 5 are a minority and stop running as a cluster, which prevents the problems of a

“split” situation. If node 3 loses communication with othe

r nodes, all nodes stop running as a cluster. However, allfunctioning nodes will continue to listen for communication, so that when the network begins working again, thecluster can form and begin to run.

Different types of Quorum in Windows server 2008 ?

 1.Node Majority

 –

 Used when Odd number of nodes are in cluster.2.Node and Disk Majority

 –

 Even number of nodes(but not a multi-site cluster)3.Node and File Share Majority

 –

 Even number of nodes, multi-site cluster4.Node and File Share Majority

 –

 Even number of nodes, no shared storage

Different types of Quorum in Windows server 2003?

Standard Quorum :

 As mentioned above, a quorum is simply a configuration database for MSCS, and is stored inthe quorum log file. A standard quorum uses a quorum log file that is located on a disk hosted on a shared storageinterconnect that is accessible by all members of the cluster.Standard quorums are available in Windows NT 4.0 Enterprise Edition, Windows 2000 Advanced Server, Windows2000 Datacenter Server, Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition.

Majority Node Set Quorums:

 A majority node set (MNS) quorum is a single quorum resource from a server clusterperspective. However, the data is actually stored by default on the system disk of each member of the cluster. TheMNS resource takes care to ensure that the cluster configuration data stored on the MNS is kept consistent acrossthe different disks.Majority node set quorums are available in Windows Server 2003 Enterprise Edition, and Windows Server 2003Datacenter Edition.

Explain about each Quorum type?

 Node Majority: Each node that is available and in communication can vote. The cluster functions only with a majorityof the votes, that is, more than half.Node and Disk Majori

ty: Each node plus a designated disk in the cluster storage (the “disk witness”) can vote,

whenever they are available and in communication. The cluster functions only with a majority of the votes, that is,more than half.Node and File Share Majority: Eac

h node plus a designated file share created by the administrator (the “file sharewitness”) can vote, whenever they are available and in communication. The cluster functions only with a majority of

the votes, that is, more than half.

No Majority: Disk Only: The cluster has quorum if one node is available and in communication with a specific disk inthe cluster storage.

 How is the quorum information located on the system disk of each node kept in synch?

 The server cluster infrastructure ensures that all changes are replicated and updated on all members in a cluster.

Can this method be used to replicate application data as well?

 No, that is not possible in this version of clustering. Only Quorum information is replicated and maintained in asynchronized state by the clustering infrastructure.

Can I convert a standard cluster to an MNS cluster?

 Yes. You can use Cluster Administrator to create a new Majority Node Set resource and then, on the clusterproperties sheet

Quorum

 tab, change the quorum to that Majority Node Set resource.

What is the difference between a geographically dispersed cluster and an MNS cluster?

  A geographic cluster refers to a cluster that has nodes in multiple locations, while an MNS-based cluster refers to thetype of quorum resources in use. A geographic cluster can use either a shared disk or MNS quorum resource, whilean MNS-based cluster can be located in a single site, or span multiple sites.

What is the maximum number of nodes in an MNS cluster?

 Windows Server 2003 supports 8-node clusters for both Enterprise Edition and Datacenter Edition.

Do I need special hardware to use an MNS cluster?

 There is nothing inherent in the MNS architecture that requires any special hardware, other than what is required fora standard cluster (for example, there must be on the Microsoft Cluster HCL). However, some situations that use anMNS cluster may have unique requirements (such as geographic clusters), where data must be replicated in real timebetween sites.

Does a cluster aware application need to be rewritten to support MNS?

 No, using an MNS quorum requires no change to the application. However, some cluster aware applications expect ashared disk (for example SQL Server 2000), so while you do not need shared disks for the quorum, you do needshared disks for the application.

Does MNS get rid of the need for shared disks?

 It depends on the application. For example, clustered SQL Server 2000 requires shared disk for data. Remember,MNS only removes the need for a shared disk quorum.