Recently, I had the opportunity to work on a project involving a 2 node, clustered Windows File Share. No big thing you say. The interesting was that it was a Windows 2003 cluster. This was the time that Failover Clustering emerged from the primordial swamp to be a sort of reliable High Availability solution. My previous experiences and personal blog posts have dealt with Windows 2008R2 Failover Clustering and SQL Server 2008R2, so I wanted to build a prototype out in the L7TG lab before working on the problem in a production environment. Note to audience, my experience working with production environments is “…don’t screw up by pressing a button that will result in an outcome you’re unprepared to deal with or don’t know what the results will be.” So here’s, the story with some resource link for good measure.
The first thing I want to make clear that this is a rather high-level overview. After all who cares about the details of a 9 year old technology? I’m going to create a 2 node cluster on Windows 2003 R2 Enterprise x64 bit servers. The Windows File Share service will be installed on the cluster. The SAN will be a synthetic one using the Starwind Software solution. Information about Starwind can be found on their web site. My experiences using the solution is in the following blog posts: SQL Failover Cluster – Part 1, and V2V Conversion with Starwind.
Just to review, a cluster is a group of computers that work as a single system to provide high availability and high fault tolerance for applications or services. Windows 2003 Servers use Cluster Services to implement this technology. The primary take away is that if one member of the cluster (the node) is unavailable, the other computer(s) carry the load so that applications or services are always available.
All nodes of the cluster use a Shared Disk which is accessible for all nodes through SCSI or Fibre Channel. All data is stored on the shared disk.
A cluster can be Active/Active or Active/Passive. An Active/Active seems to be the best utilization of resources but you need to remember that when one node fails, the remaining node needs to be able to support the full load of the failed node and its own. The number of cluster nodes supported by Windows 2003 Enterprise and Datacenter is 8 nodes. Windows Server 2003 Standard and Web Edition doesn’t support a Cluster.
In an Active/Passive cluster – If one node in the cluster fails, the active cluster failover to another node which becomes Active. This is called Failover. If the failed node is back online, a Failback can be manually initiated or automatically configured in the Cluster Group properties.
Every cluster node must have two network interfaces. One network interface for the cluster communication called the private LAN and one network interface called the public LAN. You can link a cluster with two nodes with a simple cross link cable. If more than two nodes exist in the cluster you have to use a dedicated switch / hub. Make sure that the speed of the link is the fastest that you can afford – think in terms of Gigabits.
The private NIC is used for the Heartbeat communication (Cluster communication). A Heartbeat is much like a ping which can be used to test if the other cluster node is still available. If the heartbeat fails, the Failover process occurs.
The L7TG Windows 2003 Failover Cluster consists of the following components. The Names, Data and Heartbeat IP addresses are shown below:
- Cluster Name: L7TG2K3CL -192.168.100.195
- Cluster node #1: 7TGAPP2K3A – 192.168.100.221 / 10.10.1.21
- Cluster Node #2: L7TGAPP2K3B – 192.168.100.222 / 10.10.1.22
- Cluster Service Account: _2K3FC (Password never expires for those of you who don’t want to be bothered with high security anxiety)
My implementation relies on Starwind to create the SAN. To connect the nodes to the SAN, use the ISCSI initator for server 2003. This is not included with Windows. Download the latest version at http://www.microsoft.com/download/en/details.aspx?id=18986. The iSCSI Initiator enables the host to connect to an external iSCSI storage array using Ethernet NICs.
One thing to keep in mind when working with Failover Clusters is the concept of Dependencies. The following Microsoft Support article describes the components and their organization and dependencies on each other quite eloquently: http://support.microsoft.com/kb/171791.
Refer to the following Microsoft Support article to create a File Share on a Windows 2003 cluster: http://support.microsoft.com/kb/224967.
The following set of screen shots illustrates the steps in the L7TG cluster:
First, Launch the Iscsi Initiator to connect your SAN drives. Use Disk Manager to initialize, create partition, assign drive letters and name the volumes appropriately – Q: Quorum, F: – Data.
Use the Cluster Wizard to create the cluster on the first node, L7TGAPP2K3A as shown below with nothing more that the Quorum disk.
Set dependencies: The Cluster Name depends on IP Address, IP Address depends on nothing and the Quorum disk depends on nothing. See below.
Next step is to create the File Share Group which includes the Windows File Share service and the Data disk. This is shown completed below.
Set up your dependencies. The physical disk depends on nothing, the File Share depends on the physical disk. One thing to remember is to give the file share a name and assign permissions as you would any other.
Also, I found it useful to use the advanced option to share the subdirectories as well.
You can get another slant on building a cluster of your own from this article posted on TechRepublic: http://www.techrepublic.com/blog/datacenter/building-a-windows-2003-cluster/163.
When things go terribly wrong, the best thing to do is to start over. To delete a Windows 2003 Cluster, use the cluster command as shown in this example: “Cluster <node> /forcecleanup”. Run this on both notes for a clean restart.
Finally, no article will be complete without some recommendations for best practices. I’m going to leave it up to the experts and refer you to the following article: http://blogs.technet.com/b/askcore/archive/2008/04/12/top-10-best-practice-tips-for-windows-server-2003-cluster-service-mscs.aspx.
That’s it, happy clustering.This posting is provided “as is” with no warranties, guaranties or any rights whatsoever. All content is based on the author’s experiences and opinions and is not intended to influence the actions of the reader.