Synchronization and Deployment
When talking about replication, it's very easy to think only in terms of Web pages and applications. However, this line of thought deals with only one-half of the issue. What about the servers that actually host and deliver the content? Every aspect of a cluster's composition and configuration needs to be synchronized to the cluster controller.
Application Center deals with both aspects of the synchronization issue by replicating both controller settings and application settings. Partial or full synchronization of a cluster is achieved by replicating configuration and application settings. A replication engine that uses custom drivers makes the links to the various configuration stores and copies their settings to the target servers.
This holistic approach has an added benefit; in the event of a controller failure, you can make any member the new cluster controller. You can do this on the fly, with minor configuration changes to the member.
For detailed information about this feature, see Chapter 6, "Synchronization and Deployment."
Controller Configuration Settings
The controller configuration settings are vital to the existence and ongoing operation of a cluster. The controller is the one that's deemed to have the correct configuration and content at all times. Its role is analogous to the domain controller in the Microsoft Windows NT domain model. All other cluster members are synchronized to the controller, and all administrative actions are invoked on the controller. (We'll discuss controller operation in more detail in Chapter 4, "Cluster Services," examining its role, election, and change/failover.)
Cluster-related information, such as the cluster name, cluster-wide user accounts and passwords, IP addresses, and various flags (for example, whether or not NLB is in use), are stored. If integrated NLB is implemented, all the required settings—port rules and client affinity, for example—must also be saved and replicated. Finally, several network settings—such as load-balanced IP addresses bound to the NLB network adapter and default gateway settings—must be saved and replicated as well.
NOTE
Only network settings on the NLB-bound network adapter are replicated.
The replication of configuration settings is transparent to the user and done automatically. Most of these settings are copied to all the members, whether they're in the load-balancing loop (online) or not (offline). However, there are some settings that are copied to members that are online only.
Content Publishing and Application Deployment
During the many focus groups that preceded product development, content and application deployment was always identified as one of the top three Web site management issues.
System administrators are in a difficult position; they need to be able to ensure the integrity of operational systems, while at the same time accommodating developer needs. It's not uncommon for some sites to publish new or revised content several times during a day. (Fortunately, application deployment doesn't happen as frequently.) The easiest solution is to let developers put content and applications on the servers. However, this approach usually means that the developers need to be given some administrative privileges—something that most system administrators are reluctant to do.
Another issue is getting content replicated across the appropriate servers in a Web farm. This is perhaps one of the most labor-intensive activities for development and support staff, as well as one of the most error-prone. (Cluster synchronization and content replication is touched on later in this section, but is covered in detail later in the chapter.) It's clear that a robust tool is needed to automate the publishing (deployment) process as well as to manage content and applications after they are in production.
In order to create this tool, the product team first had to define an application. Once the application was defined, they could develop the code that would function in the context of this definition.
The result is support for user-defined, custom applications, a concept that is fundamental to Application Center's publishing and deployment features.
Applications
An application is defined as a collection of all the required software resources for a Web site or COM+ application. For example, an application can consist of Web site content, COM+ applications, certificates, and registry keys. This approach allows the administrator to think of sites as logical groupings. An application may contain more than one Web site, or no Web sites at all, and still be replicated across a cluster.
IMPORTANT
Because an Application Center application is a logical framework for handling anything hosted on a server, Web content is treated as an application.
By using the Applications view (Figure 2.5), you can create an application and identify all the resources that are associated with it. The result is an application definition, which provides the basis for deploying and replicating applications to a member or over the entire cluster.
NOTE
Application Center defines four applications by default: Administration Web Site, AllSites, Application Center 2000 Administrative Site, and Default Web Site. The required settings for any published Web site are automatically stored in AllSites, so a custom application definition is not mandatory for Web sites.
Figure 2.5 shows an application definition (ACPFApp), which was created by clicking the New icon on the toolbar. After naming the application, I chose File System Paths from the Resource Type list, and then clicked the Add button. The resulting dialog box (Add Resource — Web Page Dialog) allowed me to browse the registry and select the key to add. You can use the same technique for adding this and other resources in the Resource Type list.
Figure 2.5 The Applications view in the MMC details pane
The Resource Type list is used either to display existing resources for an application or to add resources. The following resource categories are available from this list:
- COM+ applications
- Data source names (DSN)
- File system paths
- Registry keys
- Web sites and virtual directories
After all the resources for an application are identified, you can deploy the application and its contents to a target server, and in this fashion easily set up a staging environment for deploying applications.
Application Deployment
Application deployment is handled by the New Deployment Wizard, which enables you to identify target servers—inside or outside the application source cluster—and applications to deploy. Figure 2.6 shows the start page for the New Deployment Wizard.
Figure 2.6 Pages in the New Deployment Wizard
Table 2.6 describes the steps used by the New Deployment Wizard when you use it to deploy an application to a target server.
Table 2.6 New Deployment Wizard Pages
| Wizard page | Description |
|---|---|
| Welcome to the New Deployment Wizard | Starts the process, explains what the wizard does, and warns that resources on the target(s) may be overwritten. |
| Deployment Target Options | Used to determine if the target is within the same cluster or outside the cluster. |
| Deployment Target Authentication | Used to submit valid credentials for the target. |
| Deployment Targets | Used to identify deployment targets. |
| Deployment Content | Used to select either the entire server image or specific applications for deployment. |
| Deployment Options | Used to select deployment options, such as whether or not to replicate all file and directory permissions. |
| Draining Options | Used to specify whether or not to allow default draining time on target or reset target immediately. |
| Completing the New Deployment Wizard | Triggers completion of the process. |
Additional Application Features
You can use icons on the toolbar in the Applications view to launch additional application-related tasks, summarized in Table 2.7.
Table 2.7 Application Tasks
| Icon | Description |
|---|---|
| Delete | Deletes the selected application. |
| Rename | Renames the selected application. |
| Synchronize | Replicates and then synchronizes the selected application across the cluster. |
Because synchronization through replication is a major aspect of deployment, we'll examine the synchronization feature next.
Cluster Synchronization
As explained in the preceding section on application manifest deployment, you can replicate a single application to cluster members, or replicate all the applications that are currently hosted on the controller. Site information contained in the AllSites category, or in custom definitions, may include any of the following information, which is replicated when you synchronize a cluster:
- Web Content and Active Server Pages (ASP) applications
- COM+ applications
- Virtual sites (and their associated ISAPI filters) and content
- Global ISAPI filters
- File system directories and files
- Metabase configuration settings
- Exportable CryptoAPI (CAPI) server certificates
- Registry keys
- System DSNs
- Microsoft Windows Management Instrumentation (WMI) settings that Application Center uses
By default, the cluster is synchronized whenever new content is added (only the new content is replicated) or fully synchronized every 60 minutes. The user interface lets you disable this feature completely or change the time frequency for the synchronization schedule.
NOTE
You can exclude specific members from being part of cluster synchronization.
As with application deployment, you can explicitly replicate a single application or all of the applications on the controller. This gives you flexibility in staging and deploying new applications, which you may want to test on part of a cluster before deploying the application to all of the members.
EAN: N/A
Pages: 183