Step-by-Step: Configuring Windows Server 8 Beta iSCSI Target Software for Use in a Cluster

So you just download the bits for Windows Server 8 Beta and you are anxious to try out all the great new features including Windows Storage Spaces, Continuously Available Fail Servers and Hyper-V Availability. Many of those new features are going to require you become familiar with Windows Server Failover Clustering. In addition, things like Storage Spaces are going require that you have access to additional storage to simulate JBODS. Windows iSCSI Target Software is a great way for you to provide storage for Failover Clustering and Spaces in a lab environment so you can play around with these new features.

This Step-by-Step Article assumes you have three Windows Server 8 servers running in a domain environment. My lab environment consists of the following:

My three servers are all virtual machines running on VMware Workstation 8 on top of my Windows 7 laptop with 16 GB of RAM. See my article on how to install Windows Server 8 on VMware Workstation 8.

Server Names and Roles
PRIMARY.win8.local – my cluster node 1
SECONDARY.win8.local – my cluster node 2
WIN-EHVIK0RFBIU.win8.local – my domain controller (guess who forgot to rename his DC before I promoted it to be a Domain ControllerJ)

192.168.37.X/24 – my public network also used to carry iSCSI traffic
10.X.X.X /8– a private network defined just between PRIMARY and SECONDARY for cluster communication

This article is going to walk you through step-by-step on how to do the following:

The article consist mostly of screen shots, but I also add notes where needed.

Install the iSCSI Target Role on your Domain Controller

Click on Add roles and features to install the iSCSI target role.

You will find that the iSCSI target role is a feature that is found under File And Storage Servers/File Services. Just select iSCSI Target Server and click Next to begin the installation of the iSCSI Target Server role.

Configure the iSCSI Target

The iSCSI target software is managed under File and Storage Services on the Server Manager Dashboard, click on that to continue

The first step in creating an iSCSI target is to create an iSCSI Virtual Disk. Click on Launch the New Virtual Disk wizard to create a virtual disk.

Connect to the iSCSI Target using the iSCSI Initiator

Format the iSCSI Target

Connect to the shared iSCSI Target from the SECONDARY Server

Configure Windows Server 8 Failover Clustering

Step-by-Step: Configuring Windows Server 8 Beta iSCSI Target Software for Use in a Cluster

Microsoft now officially supports the iSCSI Software Target 3.3 in production

Just a few weeks ago I wrote an article about how to configure the iSCSI Software Target 3.3 in a cluster environment. While it is great for labs and testing, up until today it was not supported in a production environment. Well…that all changes today! Microsoft just announced that the iSCSI Software Target 3.3 is a freely available download and can be used on a production network.

This all starts to get interesting once you start considering the possibility of building shared nothing iSCSI Target clusters with DataKeeper Cluster Edition. Build 2-nodes locally for HA and then place a 3rd one in a remote data center for disaster recovery. Now that is a pretty sweet HA/DR solution without having to break the bank!

Microsoft now officially supports the iSCSI Software Target 3.3 in production

Configuring the Microsoft iSCSI target software for use in a cluster

Now that Starwind has stopped offering a free, limited version of their iSCSI target software you might be looking for an alternative for your labs. Microsoft has recently made their iSCSI target software available as part of the Windows Storage Server 2008 R2 download on Tech-Net and MSDN. It is not for use in production and has some of its own licensing restrictions, but it works fine and it is free for Tech-Net and MSDN subscribers.

I recorded some really quick and dirty videos that aim to show you how to configure the iSCSI target and iSCSI initiator software in under 7 minutes. At the end, you will have a shared disk array ready to start your shared storage cluster. Hopefully when I get some more time I’ll actually write these steps out, but in a pinch this will give you the general idea of what needs to be done. There are plenty of other features, but for a lab environment this will do the trick. – configuring the iSCSI target software and iSCSI initiator on the client – configuring the iSCSI initiator….continued

Configuring the Microsoft iSCSI target software for use in a cluster

You are the weakest link – Goodbye!

When building HA clusters, your application availability is only as good as its weakest link. What this means is that if you bought great servers with redundant everything (CPU, fans, power, RAID, RAM, etc) and a super deluxe SAN with multi-path connectivity, multiple SAN switches and clustered your application with your favorite clustering software you probably have a very reliable application – right? Well, not necessarily. Are the servers plugged into the same UPS? Are they on the same network switch? Are they cooled by the same AC unit? Are they in the same building? Is your SAN truly reliable? Any one of these issues among others is a single point of failure in your cluster configuration and needs to be considered.

Of course, you have to know when “good enough” is “good enough”. Your budget and your SLAs will help decide what exactly is good enough. However, one area where I am concerned that people may be skimping is in the area of storage. With the advent of cheap or free iSCSI target software solutions, I am seeing some people recommend that you just throw some iSCSI target software on a spare server and voilà – instant shared storage.

Mind you I’m not talking about OEM iSCSI solutions that have built in failover technology and/or other availability features; or even storage virtualization solutions such as FalconStor. I’m talking about the guy who has a server running Windows Server 2008 that he has loaded up with storage and wants to turn it into an iSCSI target. While this is great in a lab, if you are serious about HA, you should think again. Even Microsoft only provides their iSCSI target software to qualified OEM builders experienced in delivering enterprise class storage arrays.

First of all, this is Windows, not some hardened OS built to only serve storage. It will require maintenance, security updates, hardware fixes, etc. It basically has the same reliability as the application server you are trying to protect – does it make sense to cluster your application servers but yet use the same class of server and OS to host your storage? You basically have moved your single point of failure away from your application server and moved it to your storage server – not a smart move as far as I am concerned.

Some of the Enterprise Class iSCSI target software includes synchronous and/or asynchronous replication software and snapshot capabilities. While this functionality certainly helps in terms of your recovery point objective (RPO), it won’t help your recovery time objective (RTO) unless the failover is automatic and seamless to your clustering software. If the primary iSCSI storage array fails in the middle of the night, who is going to be there to activate the replicated copy? You may be down for quite some time before you even realize there is a problem. Again, this may be “good enough”; you just need to be aware of what you are signing up for.

One thing you can do to improve the reliability of your iSCSI target server is to use a replication product such as SteelEye DataKeeper Cluster Edition to eliminate the single point of failure. Let me illustrate.

Figure 1 – Typical Shared Storage Configuration. In the event that the iSCSI target becomes unavailable, all the nodes go offline.

If we take the same configuration shown above and add a hot standby iSCSI target using SteelEye DataKeeper Cluster Edition to do replication AND automatic failover, you have just given you iSCSI target solution a whole new level of availability. That solution would look very much like this.

Figure 2 – In this scenario, DataKeeper Cluster Edition is replicating the iSCSI attached volume on the active node to the iSCSI attached volume on the passive node, which is connected to an entirely different iSCSI target server.

The key difference in the solution which utilizes SteelEye DataKeeper Cluster Edition vs. replication solutions provide by some iSCSI target vendors is in the integration with WSFC. The question to ask of your iSCSI solution vendor is this…

What happens if I pull the power cord on the active iSCSI target server?

If the recovery process is a manual procedure, it is not a true HA solution. If it is automatic and completely integrated with WSFC, then you have a much higher level of availability and have eliminated the iSCSI array as a single point of failure.

You are the weakest link – Goodbye!