ipsure logo
Logo and Language
Login icon Language selection icon
Hello, guest
*NIX BACKUP MSTIP category header image Right block of MSTIP category header image Final menu block of MSTIP category header image
MS TIP Active category menu left background Active category menu right background PKI PROJECTS WORDPRESS Türkçe HANDS-ON SERVICES IT BUSINESS CONTACT ABOUT REFERENCES TERMS RSS
Home page Hands-On Services IT Business Contact About References Terms of Use RSS

19/07/2010

Clustering MS SQL Server 2008 R2 on VMware Virtual Windows Server 2008 R2 – 2

Filed under: ms tip — Tags: , , , , , , , , — Mehmet Bora Teoman @ 15:06

Hi folks

This is the second part of our three part article series about MS SQL Server 2008 R2 clustering. In the first part , I created Windows Server 2008 R2 virtual machines in vSphere 4 environment. In this part, I will build the cluster infrastructure,  means create a two-node Windows cluster. Lets start with the requirements for failover cluster creation.

There are software, hardware, networking and accounting requirements for a two-node failover clustering. Therefore it could be easier to represent them as a table. Table 1 shows the requirements of a two-node failover cluster.

Table 1: Requirements for a two-node failover cluster

Component Requirement
Software Servers must have the same version of Windows operating system and same software updates and service pack as well. Failover Clustering feature has to be installed on the servers.
Hardware Servers It is recommended to use the same/similar server hardware and they have to be Windows 2008 compatible
Network adapters Must be Windows 2008 compatible. For an iSCSI scenario, adapter must be dedicated to network communication or iSCSI, not both.
Storage Must be Windows 2008 compatible. At least two shared disks have to be configured, one for witness disk and the other for clustered application/service.
Device Controllers If Serial Attached SCSI or Fibre Channel is used, in all clustered servers, the mass-storage device controllers that are dedicated to the cluster storage should be identical. They should also use the same firmware version. Parallel SCSI is not supported.If iSCSI is used, each clustered server must have one or more network adapters or host bus adapters that are dedicated to the cluster storage. The network used for iSCSI cannot be used for network communication. Gigabit interface is recommended.
Networking Infrastructure Network settings Use identical communication settings on network adapters (for example, Speed, Duplex Mode, Flow Control, and Media Type). In addition, compare the settings between the network adapter and the switch it connects to and make sure that no settings are in conflict.
DNS The servers in the cluster must be using Domain Name System (DNS) for name resolution.
Domain Role All servers in the cluster must be in the same Active Directory domain.
Domain Controller It is recommended that the clustered servers be member servers.
Clients For testing purposes, one or more networked clients can be connected to the failover cluster that is created, and the effect on the client can be observed when a clustered server is moved or failed over from one cluster node to the other.
Accounting When a cluster is created, it must be logged on with an account that has administrator rights and permissions on all servers in that cluster. The account must have the Create Computer Objects permission in the domain.

As a matter of fact, my environment meets all the requirements listed in the table. But I am strongly recommend you to read the requirements and be sure to meet them in your environment. As I talked about the requirements, lets start the creation of two-node failover cluster.

First of all, I have to configure the network settings of public and private network interfaces (Note: I renamed these interfaces as LAN and Heartbeat, respectively). To do this, I open the network connections page via Control Panel (Start -> Control Panel -> Network Sharing Center -> Change Adapter Settings) and open the properties of public network interface (LAN) on the first server. I open the TCP/IP v4 properties and fill the necessary fields as they are shown in Figure 1.

Figure 1: IPv4 settings of public network interface

After that I open the properties of private network interface (Heartbeat) and fill the necessary fields as they are shown in Figure 2. I give an IP address from 100.100.100.0/24 IP block, as you can see in the figure.

Figure 2: IPv4 settings of private network interface

After that I repeat the same steps for the second virtual machine. Table 2 represents the values that I give to each server.

Table 2: IP values for each server

  Server 1 (mstipcls01) Server 2 (mstipcls02)
LAN Heartbeat LAN Heartbeat
IP Adress 192.168.2.101 100.100.100.101 192.168.2.102 100.100.100.102
Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0
Default Gateway 192.168.2.1 <blank> 192.168.2.1 <blank>
Primary DNS Server 192.168.2.22 <blank> 192.168.2.22 <blank>

As you remember from the first part of the article, LAN interface has to be ordered before Heartbeat interface in the advanced settings (Figure 4 of the first part). After I verify it via the Advanced Network Settings, I control the communication between the two virtual machines by Ping command. All the verification process finishes smoothly in my case (I can successfully ping both machines from each other via each interface) and two machines are ready to be clustered in networking point of view. In this point, it can be a good idea to make the virtual machines  members of mstip.com domain.

After including the machines to the domain, the only thing left before the creation and configuration of cluster is enabling the Failover Cluster Feature for each machine from Server Manager snap-in. For this purpose I open the Server Manager snap-in (Start -> Administrative Tools -> Server Manager) and select “Add Features” from the Features field. From the opening wizard, I select “Failover Clustering” from the list (Figure 3) and complete it. After I finish the same procedure on the second server, I am ready to cluster the two machines.

Figure 3: Failover Clustering selection

Before cluster creation, I have to validate my virtual servers for clustering. For this purpose I open the “Failover Cluster Manager” snap-in (Start -> Administrative Tools -> Failover Cluster Manager) on one of my virtual machines. On the main screen which is seen in Figure 4, there is a “Validate a configuration…” link. I click on that link and a new wizard appears. The first screen is an informative one and by clicking Next button, server selection screen appears (Figure 5).

Figure 4: Main screen of “Failover Cluster Manager” snap-in

Figure 5: Server selection screen

Here I select my two virtual machines and add them to the list by the help of Browse button and click Next. In “Testing Options” screen, I select “Run all tests (recommended)” choice and press Next button again (Figure 6). The wizard starts to validate various components (Figure 7) and when it finishes the validation process, it creates a detailed report about what is wrong and what is OK. In my validation report, everything seems fine therefore I can proceed to the creation of cluster.

Figure 6: “Testing options” screen

Figure 7: Validation process working

To create a new cluster, I click on the “Create a cluster” link on the main screen of “Failover Cluster Manager” snap-in. It leads to a new wizard, of course :). On the first screen, I select my two virtual servers again and press Next button. On the second screen, I have to give a name and IP address to my new cluster. I fill the necessary fields as they are seen in Figure 8. This means that my newly created cluster will serve with this new name and IP address. The users or services that will utilize the cluster, won’t know about the real names and IP addresses of my two virtual machines. Figure 9 represents the nodes, cluster and their DNS records.

Figure 8: Cluster name and IP address

Figure 9: Representation of clustered nodes

After few Next buttons, I finish the wizard. This gives you a new working Windows Server 2008 R2 cluster. Now you check whether all the configuration is working without an error or not via “Failover Cluster Manager” snap-in. Actually the interface is helpful enough in a way that all the working components of the cluster are shown with a green OK sign.

This is the end of part two. In this part, I create my two-node Windows cluster. In the next part, I will install MS SQL Server 2008 R2 product on my clustered environment. See you next time.

Related Posts with Thumbnails
Subscribe to our RSS feeds Email Subscription via FeedBurner RSS Subscription via FeedBurner
  1. Clustering MS SQL Server 2008 R2 on VMware Virtual Windows Server 2008 R2 – 3
  2. Clustering MS SQL Server 2008 R2 on VMware Virtual Windows Server 2008 R2 – 1
  3. Step by step installation of Sharepoint Server 2007 on Windows Server 2008 R2 and MS SQL 2008 – 2

3 Comments »

Trackbacks

There has not been any trackback links yet.

Reader Comments

Lee Pirag23/07/2010 03:00

Hi Bora, great article & keep up the good work !!

I would like to add some additional info that is important when installing on VMware.

The following issues may potentially come up when the cluster is created and the Cluter Validation tests are run.

It’s an area that causes a lot of frustration for a lot of people.

a. Validate Windows Firewall Configuration test fails.

When (ESX) cloning the 2nd server, the NICs may have the same GUIDs. If that is the case, validation will show a failure with the “Windows Firewall Configuration” (and probably a few other network related issues).

To resolve this, use this PowerShell command to identify the GUIDs.

Get-WmiObject Win32_NetworkAdapter | fl Name,GUID

(this is simply a WMI call -nothing fancy)

If they are the same, then, using Device Manager, uninstall both NICs on one of the servers, reboot that server and retest. Validation should pass the Network tests this time.

b. Validate SCSI-3 Persistent Reservation fails

This is most likely attributed to the fact that both nodes of the Windows Cluster are on the SAME ESX host.

Separating them to different hosts usually resolves this problem (HOWEVER….read on)

Setting a VMWare DRS affinity rule to keep the VMs separate will work, BUT, not if the machines are already on the same host and powered up.

If the rule is set up after the VMs are powered and on the same host and DRS is executed, the rule will fail with this error.

“Virtual Machine is configured to use a device that prevents the operation: Device ‘SCSI controller 1; is a SCSI controller engaged in bus-sharing.”

(to see this message, do a manual Migrate)

To successfully move one of the nodes to another ESX host you will need to power down one of the VMs and then migrated it. After power up the DRS rule will work.

Again, many thanks for the article. It is great to see all the steps detailed out!

M. Bora Teoman23/07/2010 11:46

Hi Lee

Thanks for all your comments and compliments. I am sure these comments will help anyone that faces such problems. They add great value to the article.

Thank you again and keep support :)

Medeiros09/11/2011 22:29

Hi Mr. Bora

I´m really thankful with your great article but this is a full Windows Server 2008 cluster and not just MS SQL Server Cluster as informed on the title.

Tks as well and Best Rgds

Comment updated:

Hi Bora,

Kindly disrespect my first comment (on part 2) and sorry about the mistake. All my doubts was explain on part 3.

Tks again

RSS feed for comments RSS feed for comments on this post. TrackBack URL

Leave a comment