Cloud Computing with Hyper-V 3.0

Organizations anxious to reap the benefits of cloud computing but reluctant to give up control of critical resources are building private clouds. Deploying a private cloud provides cloud-like functionality in a secure on-premises environment. But when it comes to actually building that private cloud, many administrators are left scratching their heads.

One problem is a private cloud seems to mean something different to almost everyone. So, the first step in building a private cloud is to define some goals and expected functionality for your environment. After doing so, you can determine how to use Microsoft Hyper-V to reach those goals.

A private cloud must possess the following three characteristics or capabilities:

1. A private cloud should treat server hardware as a pool of shared resources.
2. A good private cloud should include a self-service function, meaning an authorized end user can request resources and deploy preconfigured virtual machines (VMs) with minimal IT involvement.
3. A private cloud should provide administrators with a way to track which resources they are using. Using chargeback or showback is useful for capacity planning and to track costs.

f you consider these three primary characteristics of private cloud, then Hyper-V 3.0 does not build a private cloud; the software does not include an automated process. Still, it’s possible to build a fully functional private cloud based on Hyper-V.

Resource pooling in a private cloud

The first requirement of building a private cloud involves treating physical server hardware as a pool of resources an admin can dynamically provision. Hyper-V 3.0 actually makes it relatively easy to meet this. Here are some examples of how Hyper-V can pool these resources:

Hyper-V 3.0 separates the Startup Memory setting from the Minimum Memory setting, allowing some of the startup memory to be reclaimed once the VM becomes idle. And this enables far greater VM density. On the flip side, Hyper-V 3.0 allows for NUMA spanning — a single VM can access memory from multiple NUMA nodes. In this instance, the VM can access more memory than would be otherwise possible.

• Network: VMs connect to a virtual network rather than attaching directly to a physical network. This virtual network is based on the use of a virtual switch that usually connects to a physical network interface card (NIC).
  In Hyper-V 3.0, the virtual switch is extensible, which is useful for network management and monitoring. Hyper-V can make use of virtual LANs to isolate certain types of network traffic to a dedicated virtual network. At the physical level, multiple NICs can be teamed together to form a single logical NIC. This logical NIC is fault tolerant and provides higher network bandwidth than would be possible using a single physical NIC.
• Storage: Hyper-V has always supported the use of thinly provisioned virtual hard drives, but combining Hyper-V 3.0 with Windows Server 2012 makes it possible to virtualize physical storage. Windows Server 2012 offers a new feature called Storage Spaces that allows you to add multiple physical hard disks to a storage pool. This storage pool can provide the required fault tolerance and capacity to the entire virtualization infrastructure.
• Memory: The concept of dynamic memory was first introduced in Hyper-V 2.0, but has been enhanced in Hyper-V 3.0. In Hyper-V 2.0 the Minimum Memory setting had to meet the amount of memory a VM required at startup. However, VMs often consume more memory at startup than they do when in an idle state.
  Hyper-V 3.0 separates the Startup Memory setting from the Minimum Memory setting, allowing some of the startup memory to be reclaimed once the VM becomes idle. And this enables far greater VM density. On the flip side, Hyper-V 3.0 allows for NUMA spanning — a single VM can access memory from multiple NUMA nodes. In this instance, the VM can access more memory than would be otherwise possible.

Microsoft Hyper-V 3.0 and self-service provisioning

The second requirement to building a private cloud is that authorized users should be able to request and provision resources with minimal IT involvement. This functionality is not built into Hyper-V, however; Microsoft offers an add-on for System Center Virtual Machine Manager called the Self Service Portal.

The Self Service Portal acts as a Web interface that automatically deploys preconfigured VM user requests. You will also need Microsoft’s Deployment Toolkit, which helps you create VM images users can automatically deploy using the Self Service Portal.

Tracking resource use with the Self Service Portal

The final requirement of a private cloud is the ability to track resource consumption. The Self Service Portal in Hyper-V 3.0 includes a chargeback mechanism. This mechanism lets you specify a price for various resources and allocate a cost per user or a cost per department based on the resources consumed when a user requests a VM.

Active Directory Lightweight Directory Service Part 2

This article continues the discussion of the Active Directory Lightweight Directory Service (AD LDS) by explaining some techniques that you can use to plan for the deployment process, and by showing you how to deploy the AD LDS service.

The Planning Process

Planning for the deployment of AD LDS can actually be something of a trial and error experience because Microsoft really doesn’t give you a lot to go on. If you look at Microsoft’s AD LDS Overview on TechNet, you can see that the Hardware and Software Considerations section consists of a block of text telling you to “Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll outs to determine the capacity needs of your server.”

So what is Microsoft really saying here? Well, I think that the statement in the paragraph above can best be summarized like this:

In order to deploy AD LDS, one needs only to have a server that is capable of running Windows Server 2008. However, depending on how AD LDS is being used the server may have to support a considerable workload. It is therefore necessary to take measures to ensure that your server hardware is up to the job.

If this statement is true, then the most logical approach to AD LDS planning is to take a look at the types of resources AD LDS consumes, and base any capacity planning efforts on those types of resource consumption.

Being that Microsoft doesn’t seem to provide a lot of clear guidelines for AD LDS capacity planning, I tend to think that one of the best approaches is to treat the capacity planning process similarly to the capacity planning process that you would use for domain controllers. After all, an AD LDS server is very similar to a domain controller. Both AD LDS servers and domain controllers host nearly identical directory services. Of course there are differences that you have to keep in mind. Active Directory capacity planning usually takes the number of users into account, while AD LDS capacity planning is usually more about anticipating the number of LDAP requests that will be made against the server. However, both Active Directory and AD LDS capacity planning often require you to plan for things like topology and replication.

The Differences between Domain Controllers and AD LDS Servers

Of course even though domain controllers and AD LDS servers are very similar at the architectural level, the simple fact that domain controllers are used to authenticate logins and implement Windows security policies means that there are some aspects of domain controller planning that simply will not apply to the planning process for AD LDS.

One such difference is that AD LDS does not use the concept of forests like the Windows Active Directory does. In an Active Directory environment, a forest is a collection of domains. Every forest is completely independent, although forests can be joined together through the use of federated trusts.

AD LDS does not use the concept of forests and domains like Windows domain controllers do. Instead, the primary structural element used by AD LDS is that of a service instance (which Microsoft often refers to as an instance).  An instance refers to a single AD LDS partition. Each instance has its own individual service name, directory data store, and service description.

As I’m sure you probably already know, a Windows domain controller can only service a single domain. In contrast, a single server running AD LDS can host multiple instances. This means that a single AD LDS server can contain multiple directories.

Of course this raises an interesting question. In an Active Directory environment, clients communicate with domain controllers using the Lightweight Directory Access Protocol (LDAP). Like most other protocols, LDAP is designed to use specific port numbers. For example, LDAP typically uses port 389 for directory queries. If LDAP communications need to be encrypted then port 636 is uses instead. Domain controllers that are functioning as global catalog servers use ports 3268 and 3269 for global catalog related functions. With all of this in mind, you may be wondering which ports AD LDS uses.

Well, AD LDS does not have to worry about performing any global catalog functions, so we can rule out the use of ports 3268 and 3269 right off the bat. AD LDS does however make use of ports 389 and 636 in exactly the same way that a domain controller would.

So what happens if a server is hosting multiple AD LDS instances? Typically, the first instance to be created would be assigned to use ports 389 and 636. When the second instance is created, Windows sees that these ports are in use, and begins scanning for unused ports beginning with port 50,000. Assuming that port 50,000 is available it will be used for standard LDAP communications with the second AD LDS instance. Port 50,001 will be used for SSL encrypted LDAP communications with the second AD LDS instance.

If you were to create a third AD LDS instance on the server, then Windows would see that ports 389 and 636 were in use, so it would begin looking for unused ports starting with 50,000. Since ports 50,000 and 50,001 have already been assigned, the third LDAP partition will be assigned to ports 50,002 and 50,003.

DNS Requirements

Another difference between the Active Directory and AD LDS is that the Active Directory is totally dependent on DNS servers. Without DNS, the Active Directory cannot function. AD LDS on the other hand does not require DNS.

In some ways this makes sense. The Active Directory uses DNS as a mechanism for maintaining the domain hierarchy. There is no domain hierarchy associated with AD LDS, so DNS is unnecessary.

Installing the Active Directory Lightweight Directory Service

Installing AD LDS is actually a very simple process. To do so, open the Server Manager, and then click on the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s welcome screen and you will be taken to a screen that displays all of the available server roles.

Select the Active Directory Lightweight Directory Services check box, as shown in Figure A.

Figure A: Active Directory Lightweight Directory Service.

Figure A: Active Directory Lightweight Directory Service.

Click Next, and you will see an introductory screen that explains what the AD LDS is and what it does. Click Next and Windows will display a confirmation message indicating that the AD LDS server role is about to be installed. Click theInstall button to begin the installation process.

The entire installation process usually only takes about 30 seconds to complete. After the server role finishes installing, click the Close button to complete the installation process. Unlike some of the Windows 2008 server roles, installing the AD LDS role does not require you to reboot the server.

Conclusion

In this article, I have explained some of the differences between the Active Directory and AD LDS. In Part 3 of this series, I will begin showing you the basics of working with AD LDS.

Active Directory Lightweight Directory Service

Introduction

The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities.

When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended.

For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database.

Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory).

Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly.

Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it.

From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup.

My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions.

Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process – especially if that data changes frequently.

In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS.  A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM).

In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist.

A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however.

Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory.

The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet.

Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory.

To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS.

One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

Now that I have talked about what the AD LDS is and what it is used for, I want to turn my attention to using this service in your own organization. In Part 2, I will begin discussing the hardware and the software requirements for using AD LDS.

The Planning Process

Planning for the deployment of AD LDS can actually be something of a trial and error experience because Microsoft really doesn’t give you a lot to go on. If you look at Microsoft’s AD LDS Overview on TechNet, you can see that the Hardware and Software Considerations section consists of a block of text telling you to “Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll outs to determine the capacity needs of your server.”

So what is Microsoft really saying here? Well, I think that the statement in the paragraph above can best be summarized like this:

In order to deploy AD LDS, one needs only to have a server that is capable of running Windows Server 2008. However, depending on how AD LDS is being used the server may have to support a considerable workload. It is therefore necessary to take measures to ensure that your server hardware is up to the job.

If this statement is true, then the most logical approach to AD LDS planning is to take a look at the types of resources AD LDS consumes, and base any capacity planning efforts on those types of resource consumption.

Being that Microsoft doesn’t seem to provide a lot of clear guidelines for AD LDS capacity planning, I tend to think that one of the best approaches is to treat the capacity planning process similarly to the capacity planning process that you would use for domain controllers. After all, an AD LDS server is very similar to a domain controller. Both AD LDS servers and domain controllers host nearly identical directory services. Of course there are differences that you have to keep in mind. Active Directory capacity planning usually takes the number of users into account, while AD LDS capacity planning is usually more about anticipating the number of LDAP requests that will be made against the server. However, both Active Directory and AD LDS capacity planning often require you to plan for things like topology and replication.

The Differences between Domain Controllers and AD LDS Servers

Of course even though domain controllers and AD LDS servers are very similar at the architectural level, the simple fact that domain controllers are used to authenticate logins and implement Windows security policies means that there are some aspects of domain controller planning that simply will not apply to the planning process for AD LDS.

One such difference is that AD LDS does not use the concept of forests like the Windows Active Directory does. In an Active Directory environment, a forest is a collection of domains. Every forest is completely independent, although forests can be joined together through the use of federated trusts.

AD LDS does not use the concept of forests and domains like Windows domain controllers do. Instead, the primary structural element used by AD LDS is that of a service instance (which Microsoft often refers to as an instance).  An instance refers to a single AD LDS partition. Each instance has its own individual service name, directory data store, and service description.

As I’m sure you probably already know, a Windows domain controller can only service a single domain. In contrast, a single server running AD LDS can host multiple instances. This means that a single AD LDS server can contain multiple directories.

Of course this raises an interesting question. In an Active Directory environment, clients communicate with domain controllers using the Lightweight Directory Access Protocol (LDAP). Like most other protocols, LDAP is designed to use specific port numbers. For example, LDAP typically uses port 389 for directory queries. If LDAP communications need to be encrypted then port 636 is uses instead. Domain controllers that are functioning as global catalog servers use ports 3268 and 3269 for global catalog related functions. With all of this in mind, you may be wondering which ports AD LDS uses.

Well, AD LDS does not have to worry about performing any global catalog functions, so we can rule out the use of ports 3268 and 3269 right off the bat. AD LDS does however make use of ports 389 and 636 in exactly the same way that a domain controller would.

So what happens if a server is hosting multiple AD LDS instances? Typically, the first instance to be created would be assigned to use ports 389 and 636. When the second instance is created, Windows sees that these ports are in use, and begins scanning for unused ports beginning with port 50,000. Assuming that port 50,000 is available it will be used for standard LDAP communications with the second AD LDS instance. Port 50,001 will be used for SSL encrypted LDAP communications with the second AD LDS instance.

If you were to create a third AD LDS instance on the server, then Windows would see that ports 389 and 636 were in use, so it would begin looking for unused ports starting with 50,000. Since ports 50,000 and 50,001 have already been assigned, the third LDAP partition will be assigned to ports 50,002 and 50,003.

DNS Requirements

Another difference between the Active Directory and AD LDS is that the Active Directory is totally dependent on DNS servers. Without DNS, the Active Directory cannot function. AD LDS on the other hand does not require DNS.

In some ways this makes sense. The Active Directory uses DNS as a mechanism for maintaining the domain hierarchy. There is no domain hierarchy associated with AD LDS, so DNS is unnecessary.

Installing the Active Directory Lightweight Directory Service

Installing AD LDS is actually a very simple process. To do so, open the Server Manager, and then click on the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s welcome screen and you will be taken to a screen that displays all of the available server roles.

Select the Active Directory Lightweight Directory Services check box, as shown in Figure A.

Figure A: Active Directory Lightweight Directory Service.

Click Next, and you will see an introductory screen that explains what the AD LDS is and what it does. Click Next and Windows will display a confirmation message indicating that the AD LDS server role is about to be installed. Click theInstall button to begin the installation process.

The entire installation process usually only takes about 30 seconds to complete. After the server role finishes installing, click the Close button to complete the installation process. Unlike some of the Windows 2008 server roles, installing the AD LDS role does not require you to reboot the server.

Conclusion

In this article, I have explained some of the differences between the Active Directory and AD LDS. In Part 3 of this series, I will begin showing you the basics of working with AD LDS.

Installing SQL Server 2008 on a Windows Server 2008 Cluster – Part1

There have been a lot of changes regarding clustering between Windows Server 2003 and Windows Server 2008. It took quite a lot of effort for us to build a cluster in Windows Server 2003 – from making sure that the server hardware for all nodes are cluster-compatible to creating resource groups. Microsoft has redefined clustering with Windows Server 2008, making it simpler and easier to implement. Now that both SQL Server 2008 and Windows Server 2008 are out in the market for quite some time, it would be a must to prepare ourselves to be able to setup and deploy a clustered environment running both. Installing SQL Server on a stand-alone server or member server in the domain is pretty straight-forward. Dealing with clustering is a totally different story. The goal of this series of tips is to be able to help DBAs who may be charged with installing SQL Server on a Windows Server 2008 cluster.

Prepare the cluster nodes

I will be working on a 2-node cluster throughout the series and you can extend it by adding nodes later on. You can do these steps on a physical hardware or a virtual environment. I opted to do this on a virtual environment running VMWare. To start with, download and install a copy of the evaluation version of Windows Server 2008 Enterprise Edition. This is pretty straight-forward and does not even require any product key or activation. Evaluation period runs for 60 days and can be extended up to 240 days so you have more than enough time to play around with it. Just make sure that you select at least the Enterprise Edition during the installation process and have at least 12GB of disk space for your local disks. This is to make sure you have enough space for both Windows Server 2008 and the binaries for SQL Server 2008. A key thing to note here is that you should already have a domain on which to join these servers and that both have at least 2 network cards – one for the public network and the other for the heartbeat. Although you can run a cluster with a single network card, it isn’t recommend at all. I’ll lay out the details of the network configuration as we go along. After the installation, my recommendation is to immediately install .NET Framework 3.5 with Service Pack 1 and Windows Installer 4.5 (the one for Windows Server 2008 x86 is named Windows6.0-KB942288-v2-x86.msu). These two are prerequisites for SQL Server 2008 and would speed up the installation process later on.

Carve out your shared disks

We had a lot of challenges in Windows Server 2003 when it comes to shared disks that we will use for our clusters. For one, the 2TB limit which has a lot to do with the master boot record (MBR) has been overcome by having the GUID Partition Table (GPT) support in Windows Server 2008. This allows you to have 16 Exabytes for a partition. Another has been the use of directly attached SCSI storage. This is no longer supported for Failover Clustering in Windows Server 2008. The only supported ones will be Serially Attached Storage (SAS), Fiber Channel and iSCSI. For this example, we will be using an iSCSI storage with the help of an iSCSI Software Initiator to connect to a software-based target. I am using StarWind’s iSCSI SAN to emulate a disk image that my cluster will use as shared disks. In preparation for running SQL Server 2008 on this cluster, I recommend creating at least 4 disks – one for the quorum disk, one for MSDTC, one for the SQL Server system databases and one for the user databases. Your quorum and MSDTC disks can be as small as 1GB, although Microsoft TechNet specifies a 512MB minimum for the quorum disk. If you decide to use iSCSI as your shared storage in a production environment, a dedicated network should be used so as to isolate it from all other network traffic. This also means having a dedicated network card on your cluster nodes to access the iSCSI storage.

Present your shared disks to the cluster nodes

Windows Server 2008 comes with iSCSI Initiator software that enables connection of a Windows host to an external iSCSI storage array using network adapters. This differs from previous versions of Microsoft Windows where you need to download and install this software prior to connecting to an iSCSI storage. You can launch the tool from Administrative Tools and select iSCSI Initiator.

To connect to the iSCSI target:

1. In the iSCSI Initiator Properties page, click on the Discovery tab.
2. Under the Target Portals section, click on the Add Portal button.
3. In the Add Target Portal dialog, enter the DNS name or IP address of your iSCSI Target and click OK. If you are hosting the target on another Windows host as an image file, make sure that you have your Windows Firewall configured to enable inbound traffic to port 3260. Otherwise, this should be okay.
4. Back in the iSCSI Initiator Properties page, click on the Targets tab. You should see a list of the iSCSI Targets that we have defined earlier
5. Select one of the targets and click on the Log on button.
6. In the Log On to Target dialog, select the Automatically restore this connection when the computer starts checkbox. Click OK.
7. Once you are done, you should see the status of the target change to Connected. Repeat this process for all the target disks we initially created on both of the servers that will become nodes of your cluster.

Once the targets have been defined using the iSCSI Initiator tool, you can now bring the disks online, initialize them, and create new volumes using the Server Manager console. I won’t go into much detail on this process as it is similar to how we used to do it in Windows Server 2003, except for the new management console. After the disks have been initialized and volumes created, you can try logging in to the other server and verify that you can see the disks there as well. You can rescan the disks if they haven’t yet appeared.

Adding Windows Server 2008 Application Server Role

Since we will be installing SQL Server 2008 later on, we will have to add the Application Server role on both of the nodes. A server role is a program that allows Windows Server 2008 to perform a specific function for multiple clients within a network. To add the Application Server role,

1. Open the Server Manager console and select Roles.
2. Click the Add Roles link.  This will run the Add Roles Wizard
3. In the Select Server Roles dialog box, select the Application Server checkbox. This will prompt you to add features required for Application Server role. Click Next.
4. In the Application Server dialog box, click Next.
5. In the Select Role Services dialog box, select Incoming Remote Transactions and Outgoing Remote Transactions checkboxes. These options will be used by MSDTC. Click Next
6. In the Confirm Installation Selections dialog box, click Install. This will go thru the process of installing the Application Server role
7. In the Installation Results dialog box, click Close. This completes the installation of the Application Server role on the first node. You will have to repeat this process for the other server

We have now gone thru the process of creating the cluster at this point. In the next tip in this series, we will go thru the process of installing the Failover Cluster feature, validating the nodes that will become a part of the cluster and creating the cluster itself. And that is just on the Windows side. Once we manage to create a working Windows Server 2008 cluster, that’s the only time we can proceed to install SQL Server 2008.