I recently delivered a presentation on Highly Available Clusters focused on the scenarios related to Windows Storage Server 2003 R2 (WSS 2003 R2) and Windows Unified Data Storage Server 2003 (WUDSS 2003). The scenarios ended up being quite generic, so I decided to share them here.
In general, high availability will lead you to introduce redundancy in your computing environment, so you can tolerate the failure of any single component. The idea is that you will continue to provide the service even if one of the components stops working. To be effective, you need to cover all layers involved, including servers, storage and networks.
Because the presentation was focused on WUDSS, I targeted the two main scenarios for that product: File Server and iSCSI Target (using a SQL Server-based application as an example). The flow was to start with a simple scenario with no high availability and end up with a highly available SQL Server and WUDSS iSCSI storage back-end.
Also note that details about certain networking and storage technologies are missing in the diagrams. This was done on purpose, so you can picture in your head the technologies commonly used in your specific environment.
Scenario 1: File Server, no high availability
In the first scenario you have the simplest possible example, just to outline the components involved. You can see the client, the client-server network, the server (in this case a WUDSS box working as a file server) and the storage.
Scenario 2: File server with highly available storage
In this second scenario, highly available storage was added. This could be as simple as adding a PCI-RAID controller and mirroring your disks all the way up to adding a highly available SAN device with multiple controllers. Note that the other components in the solution are still not highly available.
Scenario 3: Highly available file server
This third scenario is the first to show all layers being highly available. The client-server network shows multiple switches, the servers are clustered (using Microsoft Cluster Services, a.k.a. Windows Failover Clustering), the server-storage network includes redundant paths and the storage is also providing fault tolerance. Since this is a file server scenario, this works in the very same way with Windows Server 2003 R2 or Windows Server 2008.
Scenario 4: Highly available SQL Server
This fourth scenario is similar to the previous one. The only difference here is the fact that we’re serving databases (using SQL Server) instead of serving files. Note that WUDSS can’t be used here, since that OEM product is not licensed to run this type of workload.
Scenario 5: Highly available Application Server
This fifth scenario adds a set of application servers, introducing a middle tier between the clients and the SQL Servers. This is a very common scenario today and most ERP and CRM systems work this way. You can still have a rich client, but that client talks to a application server that relays the requests to the database server. This is also the typical case of web applications, where the client is a browser and the application server is a web server like Internet Information Server.
The application servers usually do not need to shared data among themselves directly, typically relying on the SQL Server for that task. Because of this, you can use a simpler model to make them highly available. This scenario shows the two application servers using Network Load Balancing instead of a Failover Cluster.
Scenario 6: iSCSI back-end
This sixth scenario introduces a WUDSS iSCSI Software Target into the picture. This WUDSS box replaces the previous storage subsystem. The main difference here is the fact that the server-storage network is now a regular IP network, instead of typical storage connections like fiber channel, SAS or SATA. Note that this scenario is not highly available as shown here.
Scenario 7: Highly available iSCSI back-end
This last scenario introduces high availability in the iSCSI software target by using a Failover Cluster. Note that this type of cluster is being used here twice: once at the SQL Server layer and again in the iSCSI software target. Also note that the storage behind that iSCSI target needs to be fully redundant to make for a completely highly available solution.