8.2 The Cluster

---

By bringing a number of servers together to work as a single unit, we have seen that single points of failure can be avoided. This cluster of servers is not a particularly new innovation, but its application in a Web-based product from Microsoft is. Previously, clusters were mainly used in database products, such as Microsoft SQL Server, or mail servers, such as Exchange. Application Center clusters are broader, since they are designed to deal with the Web tier, serving HTTP-based clients, and the business tier, which serves the COM-based business logic (see Figure 8.2).

Figure 8.2: Application Center cluster.

There are three types of clusters supported by Application Center Server:

1. General (Web tier) cluster

2. COM+ application cluster

3. COM+ routing cluster

8.2.1 General Cluster

This is the conventional cluster that readers may be familiar with since it provides servers to manage a range of client requests and can include database, e-mail, and Web servers (see Figure 8.3).

Figure 8.3: The general Web cluster.

8.2.2 COM+ Application Cluster

This manages any method calls to instantiate business logic objects. These calls are load-balanced across cluster members to improve throughput. The COM+ application cluster deals exclusively with this type of load balancing (see Figure 8.4).

Figure 8.4: COM+ application cluster.

8.2.3 COM+ Routing Cluster

This will use component load balancing (CLB) to route any requests for COM+ components. In reality this would rarely be used, since Web clusters can communicate directly to back-end COM+ clusters, acting as their own router to determine the best server to activate for component use (see Figure 8.5).

Figure 8.5: COM+ routing cluster.

8.2.4 Single-Node Clusters

Application Center can be run on a cluster of one server or member. While not suitable for a production environment, it can be used as a stager, where content is placed onto a staging server. The content can then be fully tested before moving it across to the production environment.

8.2.5 Standard Web Clusters

This is probably the most common use of Application Center Server, where the Web cluster is used to serve both the Web site and COM+ components held locally with the use of a load-balancing system, such as NLB. This is useful since it will provide failover, so that if a member server should fail, the remaining servers would pick up the workload, since they are all copies of the cluster controller (see Figure 8.6 and 8.7).

Figure 8.6: NLB balancing workload across multiple servers.

Figure 8.7: Failover-the site continues to be available as other member servers pick up the workload.

Scalability is also improved since other servers can be added to the cluster to take on workload, which, in turn, will hopefully deliver improved performance (see Figure 8.8).

Figure 8.8: Adding additional servers will see the workload automatically redistributed across the cluster.

Non-NLB balanced clusters can still be built, but would use another load-balancing device from a list of supported third-party solutions available from Microsoft.

8.2.6 Building a Cluster

A cluster will always start from a single server (in effect a cluster of one) and then build outward as additional servers are added to the cluster set.

Assuming that you have the servers on the same network and they can see each other, adding a new server to a cluster is fairly straightforward and should be completed using the Add Cluster Member Wizard. The original server is called the cluster controller and must start the cluster build process with all of the site content and configuration material in a complete state. If you have decided not to use NLB, then each member cluster server must have its IP address bound to the cluster controller.

Most Application Server clusters will need to have the client and cluster communications configured. Client communication is normally done via a load-balancing mechanism to spread the load across multiple servers.

Cluster communications are put in place to ensure that Application Center can send management requests between cluster members to synchronize content and administer the cluster. As you would expect, all of the networking issues need to be resolved before using the New Cluster Wizard, since changing network settings after the cluster has been built will probably require a complete rebuild of the cluster.

---