General Clusters

A general cluster is nothing but a group of servers processing client requests. In this category you find the Web server cluster, which is the kind of cluster this chapter focuses on, in addition to database clusters, staging clusters (aka deployment servers) and stand-alone clusters. Yes, you read correctly. A stand-alone cluster is a cluster with only one member, which you will learn more about later in this chapter. A few other clusters also fit in the general category, but these are the most important ones.

The most common cluster using Application Center would be a Web server cluster that hosts Web sites as well as local COM+ components (or assemblies in .NET). These clusters can use several load-balancing techniques. Application Center does not care if you use load-balancing techniques other than Network Load Balancing. In Figure 3-10, you can see that during setup of a new cluster you can choose the type of load balancing you will use. You still get the advantages of clustering several servers that we have already discussed.

Figure 3-10: Specifying a load-balancing type for a new cluster

A typical scenario using Network Load Balancing might look like Figure 3-11. Application Center in this scenario eases the task of administering the cluster. Adding and removing (setting members online or offline) is handled through the Application Center user interface.

Figure 3-11: A typical scenario using Network Load Balancing with Application Center

Because Network Load Balancing dynamically distributes client workload even when you set members online or offline, the site is available during the whole process. This makes it easy to add more power to your site by adding servers during runtime.

Third-Party Load Balancers in Application Center

As already stated, you do not need to use NLB if you do not want to. Many sites use an external load-balancing device to distribute incoming client requests (see the following illustration). The device is simply a piece of hardware placed in front of the Web servers handling the requests.

These third-party load balancers can be monitored and managed through the Application Center user interface. Application Center monitors member status, sets members online or offline, and synchronizes content and configuration for all Web sites included. To make this solution work, you need to integrate the load balancers with Application Center. This is achieved by configuring the communication between the device and Application Center. All cluster members are synchronized with a cluster controller, and to avoid problems and unexpected behavior, you need to make sure that all content exists on this controller before adding any members.

To be honest, Application Center is a relatively bad tool to manage these load-balancing devices. Even though the Application Center Resource Kit, available from Microsoft Press, includes tools for third-party load-balancing integration with Application Center, it is still a very crude way of doing things. You will need to do a lot of work manually with scripts and command-line commands that you can avoid if you use Network Load Balancing.

One other thing to keep in mind is that Network Load Balancing is a distributed application and runs on all servers in the cluster, whereas an external load-balancing device provides a potential single point of failure. If a server in a Network Load Balancing cluster fails, the load balancing still works because every member runs a copy of NLB. If your hardware load balancer fails, you might have a problem if you lack a backup solution.

Single-Node Clusters

We mentioned single-node clusters. You might think they seem strange, since a cluster by definition ought to use more than one server. But sometimes it can be useful to operate Application Center on a single server, without the multi-member cluster context. If you use Application Center on a single-node cluster, it treats this cluster as a one-member cluster, which it in fact is. This is typically useful when you need a stager or a staging area—that is, a server where you publish content before you actually deploy it on the production cluster. This provides a way of testing quality and functionality from development and testing environments before going live with your site. Because the stager does not need to be as powerful as the production cluster, you can use a simpler cluster but still keep the Application Center functionality.

COM+ Application Cluster

In the Web pages of a Web application, different components are instantiated to serve the application with data of various sorts. You could, for instance, have an application where a salesperson looks up customer data by calling a COM+ component that has a function named GetCustomerData. It really does not matter whether the application is a Web application or if it is a thick Windows client, the instantiation is the same. If the GetCustomerData component resides on a different server than the application itself, and there are many users accessing this component, the workload on the server can be immense. To ease the pressure on the server, you can create a cluster of servers to handle these COM+ components, just as you might do with your Web site. The benefits of doing this are the same as for Network Load Balancing described earlier. Application Center COM+ clusters load balance the method calls to instantiate the components across multiple cluster members within the COM+ cluster. A simplified scenario of this is shown in Figure 3-12. This cluster uses Network Load Balancing as a load balancer.

Figure 3-12: A simplified scenario using Network Load Balancing for a COM+ cluster

To support Windows-based clients using DCOM, the cluster can understand DCOM calls and use Network Load Balancing to distribute these incoming client requests.

But in a more likely scenario than the one just described, the layering of the application would be different. To ease the load on the Web cluster, the COM+ components would probably be moved to their own cluster and Component Load Balancing would be used to load balance the activation requests for the COM+ components as shown in Figure 3-13.

Figure 3-13: A likely scenario using CLB for distributing the activation requests for a COM+ cluster and NLB for a Web cluster

COM+ Routing Clusters

In the scenario in Figure 3-13, we have also included something called a COM+ Routing Cluster. This cluster is located on the Web servers and uses Component Load Balancing to route requests for COM+ components from the general cluster to the COM+ Application Cluster. COM+ Routing Clusters are not really necessary, but serve their purpose when you need to load balance COM+ requests from a general cluster across multiple COM+ Application Clusters. This depends on a limitation in the Application Center 2000 release of Component Load Balancing that makes it possible for CLB to have only a single list of remote servers for every routing server. Otherwise, Web clusters can communicate with COM+ clusters over load-balanced DCOM without a COM+ Routing Cluster, since each Web cluster member acts as its own router for choosing the right COM+ server to handle component activation.

If you develop a new application entirely in .NET, you would not use COM Interop, of course. In this situation, you would use .NET Remoting with binary formatting either over HTTPChannel or over TCPChannel. You can scale .NET Remoting hosted in IIS just as you scale your Web clusters, and performance is high as well. The one thing you need to remember is that this only works when you use .NET Remoting hosted in IIS. When it comes to .NET Remoting outside IIS, we have not yet found a way to scale this, but suspect future versions of Application Center will solve this limitation.

On the other hand, when you have an integration project and cannot change the old components, CLB is a good way to enhance performance.

Component Activation

The fastest way of activating components is by having them on the local machine of the user (or Web server, if it is a Web application). But by using the scenario in Figure 3-13, you get a lot of other benefits that clearly outnumber the use of local components:

• COM+ Application Clusters can accept requests from both thin and thick clients. That is, they can handle both Web browser–based clients as well as Windows-based clients. This means you can reuse business logic in many applications.

• If the COM+ components reside on the Web server, they could consume resources, making the server unresponsive. You cannot let this happen. Otherwise, you may as well abandon the idea of the five nines (99.999 percent uptime). By creating a separate cluster for the components the Web server is relieved and can continue to handle client requests with better performance.

• To gain higher security, you can also place the component cluster behind a separate firewall. By doing this, you will restrict clients accessing the Web cluster from also being able to access the components. You will see more about this later in the chapter.

• Since you isolate COM+ applications on a separate cluster, you accomplish higher manageability. By having two clusters, you make it possible to have different developers and administrators maintain each cluster independently. Of course, this requires a large organization with lots of resources. This is nothing for the small Web site, obviously, which would not need load balancing anyway.

Network Load Balancing in Application Center

You use a wizard to set up and configure Network Load Balancing in Application Center. This wizard, the New Cluster Wizard, quickly sets up and configures Network Load Balancing (refer back to Figure 3-8). Remember, this is the same wizard you use for setting up any load balancer, as Figure 3-10 showed. You do not need to configure anything during this process; the wizard handles everything. However, if you do not like the default values, you can easily change them by using the Application Center user interface after you have created the new cluster (see Figure 3-14).

Figure 3-14: The Application Center MMC

The user interface makes it easy to add and remove cluster members once you are up and running with the cluster. This is also the place to go if you need to change other aspects of your Application Center configuration.

One thing to do before running the Application Center setup is making sure that you have at least two network interface cards. You will need to have one card for handling internal communication within the cluster and one for handling communication with clients. The latter card needs to have at least one static IP address that is used as the cluster IP address, or as we refer to it, the virtual IP address. This is the address clients use to access the cluster.

Monitoring Process

So let us look in more detail at how the process of Application Center monitoring is carried out. There are four steps in this process:

• Data generation

• Data logging

• Data summarization

• Data use

Data Generation

Figure 3-16 shows an overview of how Application Center, Health Monitor, and the operating system generate events and performance counters. It also shows how this data is provided to WMI.

Figure 3-16: The Application Center data generation process

Application Center subscribes to some of these WMI events and logs them for later use in the user interface. Microsoft Application Center is also smart enough to provide its own events with extended and troubleshooting information, a feature called event details.

Data Logging

During Application Center setup, if you choose to install Application Center Event and Performance Logging (see Figure 3-17), a SQL Server 2000 database is also installed. This is, as we are sure you have already guessed, where Application Center stores the logged data.

Figure 3-17: The Application Center custom setup

Because the infrastructure of this database is exactly like an ordinary SQL Server and also provides the same functionality, you can use the same ways of accessing this database as you would if you were to access a SQL Server. This means you can use SQL queries and stored procedures to access data. Other data accessing methods, like ADO.NET, are also possible to use, giving you the flexibility to choose for yourself the way you want to retrieve data. If you do not want to go through the trouble of making these queries, you can use the Application Center user interface to display the information you are looking for. The important thing to remember here is that these other accessing methods are available so that, when the user interface does not show you what you want, you can find the information yourself.

One benefit of storing the monitoring data in a database is that you can display information more flexibly. You can also let other applications and services access the data.

In the Application Center Event View, you can choose to view the data points for different time frames (see Figure 3-18). Application Center scans logs for 1-minute, 15-minute, and 2-hour time frames. The older the information is, the less detail it provides. This happens because as data is summarized over a longer period of time, say one day, there is no way of keeping the same level of detail as you can for the 1-minute interval. These logs are cleared by default after a specified number of days. A property called "Keep logged events for (days)" is available in the Event Properties dialog box.

Figure 3-18: The Application Center UI. Marked is the place where you choose the time frame to be displayed.

As you have seen, Application Center collects a large amount of data in a detailed format about the cluster and its members. This data quickly grows, and lots of disk space is required to hold it. Application Center therefore summarizes this data periodically and loads it into a summarization table. Two kinds of data sets are summarized:

• Event data: Data that is maintained in the log for a specified number of days as mentioned previously. The default is 15 days before any data is removed.

• Performance counter data: Data that is collected every 10 seconds. This data is summarized in four intervals: 1 minute, 15 minutes, 2 hours, and daily. The whole cluster is synchronized with these time intervals.

Because the summarization changes the granularity of the data, less and less detail can be shown as the time frame grows larger. If you want to be able to see the data in greater detail later, you must collect data more often. This requires, of course, more disk space, but luckily hard drives are cheap these days. So if you decide you have enough disk space, you can archive the detailed data before it is summarized, and then you can really dive into it when you want to.

Data Use

Figure 3-19 shows different ways of collecting data from Application Center logs and presenting them in a report. By using SQL queries, you can easily import the data into your favorite presentation tool and generate the reports you want to display.

Figure 3-19: Schematics of Application Center data use

But of course, you can also use Application Center Event View, Performance Chart, and Cluster Status to display information about the cluster and its members. It is also possible to customize these views.

Example 1

The first example (Figure 3-21) shows an internal network protected by a single firewall. The Web cluster, COM+ cluster, and stager are all behind this firewall. The database is also protected only by this firewall.

Figure 3-21: A simple scenario using COM+ and a single firewall

In a scenario like this, both the database and the business logic in the COM+ cluster as well as the stager are potentially exposed to users from the outside. To prevent some of these security risks, it is very common to add another firewall, thereby creating a perimeter network.

Example 2

Here we have added a perimeter network, as Figure 3-22 shows. This is commonly referred to as a demilitarized zone (DMZ). In this scenario, we protect the staging server and database server from being compromised by, say, a Trojan horse attack. But as you clearly see here, we have only partly solved the problem. While the database and staging server are protected behind the second firewall, we still potentially expose the business logic. The COM+ components often use role-based, or programmatic, security to keep data safe. This could be compromised if the components reside on the Web tier of our application. And we do not want to risk our business logic coming into the wrong hands, because this could jeopardize our business. We must do something about this.

Figure 3-22: By adding a second firewall, we create a DMZ.

Example 3

In the third example, we also move the COM+ cluster behind the second firewall, as Figure 3-23 shows. Here we use CLB to even further enhance security in the Web site. An unreliable client trying to access the business logic would be prevented from doing so by the second firewall. It would instead only allow COM+ components to be created by calls from the Web tier cluster.

Figure 3-23: The application logic is moved behind the second firewall.

But we still have a few problems left in this solution. We can even further enhance security by using Web services instead of COM+. If we let COM+ calls through a firewall, it means we must open up the specific ports necessary for this traffic to be let through. We instead want to keep the firewall as closed as we can and only allow HTTP traffic through. The next example shows how this kind of solution could be designed.

Example 4

Figure 3-24 shows the design of a solution where we have changed from exposing our logic as COM+ components and instead use Web services. One thing you need to understand before using this scenario yourself is that the inclusion of Web services comes with a certain penalty. Performance is negatively affected by having to use HTTP instead of COM+ calls. COM+ calls are generally faster than HTTP calls, but since in this example we are on our internal network, we have control of bandwidth usage, and we feel it is better to lose a little performance than to have too many holes in our firewall. Our own testing shows such tiny performance degradation that the move to Web services is well worth the effort just to have better security. But we strongly suggest testing such a method before deploying it.

Figure 3-24: In this scenario, we expose the business logic as Web services.

In all of these scenarios, we could also use .NET Remoting instead of COM+ or Web services over an HTTP connection. .NET Remoting is a generic and extensible interprocess communication system. You can use it to create Web services hosted in IIS, and have the security, scalability, and state management (both session and application state) that ASP.NET and IIS offer. If you are interested in security issues over performance, you should use ASP.NET or .NET Remoting hosted in IIS. If you use any other transport protocol, you would have to handle security yourself. The same goes for using the HTTPChannel outside of IIS.

It is not possible to load balance .NET Remoting if you host it outside of IIS. This we suspect will change in the coming versions of Application Center. In the meantime, in our scenarios we must host .NET Remoting in IIS if we want to use it.

If you want to keep the IIS hosting with its security, and still get increased performance, you should definitely use the binary encoding of .NET Remoting. Our own tests as well as several others show a performance boost when using the binary formatting, even if we use the HTTPChannel.

To get absolutely maximum performance from .NET Remoting, you should use the binary formatting over a TCPChannel. But then you must be certain that you are running entirely in a secure environment, behind a firewall. So in this case, we would not recommend it, since you need to expose objects to outside your firewall. The key issue as we see it is to keep the firewalls as closed as possible. If you open up ports in them, you have a potential security risk. This is why we recommend the use of only port 80 and HTTP traffic when you need to expose objects to outside your firewalls. This limits you to the use of Web services or .NET Remoting over the HTTPChannel, of course, but you should be able to live with that.

If you need to choose between .NET Remoting using binary formatting over an HTTPChannel and traditional Web services, you should consider some issues. Both methods are scalable when hosted in IIS, but keep in mind that .NET Remoting using binary formatting over an HTTPChannel is faster than traditional Web services. .NET Remoting, however, demands that the client have access to the .NET Framework to give full access to all its features, and if you need interoperability with other platforms, this is not always possible. However, you could use a J2EE implementation called JNBridge that connects .NET with Java, but we have not tried this ourselves. You could think of .NET Remoting as a substitute for DCOM, where you make many calls to a component during the session and need more extensible features than you can get from Web services. Especially when you have communication between .NET applications that do not have to cross a firewall, .NET Remoting is very useful, and you can be certain both ends support the .NET Framework in that case.

If you want a client not using .NET Remoting plumbing to access your Web services created from .NET Remoting objects, you need to think about some things first. If you carefully pare down your endpoints to bare-bones data types and semantics, you could use them. If you do not restrict parameters to built-in simple types and your own data types, you cannot interoperate your .NET Remoting Web services with other Web services implementations. You also need to avoid client-activated objects and events in that case. What have you really got left then? Not much more than a traditional Web service could offer. So if you want to support a wide range of clients, you should use traditional Web services.

A good suggestion is choosing Web services by default, even in a homogeneous environment, between internal systems and subsystems. Use .NET Remoting only in those special cases where you really need it. This would be when you know that the client supports the full .NET Framework, and you need the extensible features of the full Framework. This could also be when performance is an issue, since .NET Remoting generally is faster than Web services.

Our recommendation for using .NET Remoting with some transport protocol other than HTTP is to make sure the client is placed behind the same firewall as the Remoting object. If it is not, you need to open up the firewalls, which gives you a potential security hole. You would also need to implement security yourself in code, since you cannot use the built-in features of IIS in this case.

Now you have come a few steps down the road of security. But there is a lot more you can do, as this book will show. One way to enhance security more would require you to dive into the world of Windows and network security, which is beyond the scope of this book. Application Center is based on the services provided by Windows and Internet Information Services. In Application Center, you find very few user-configurable security settings. You must therefore learn and understand Windows security to fully secure your network. It is also essential that you keep in close cooperation with the people who understand these things the best: the system architects and the administrators. But let us not forget the software developers. A lot also can be done to enhance security in the code.

These are a few different scenarios using Application Center. If we personally wanted to choose a solution for our own network, we would definitely choose Example 4, since the benefits are great with this setup. But in the end, it is up to each company and each Web site to set its own standards.