Service Continuity Solution Accelerator

On This Page

	Executive Summary
	Introduction
	MOM 2005 Service Continuity Overview
	Processes and Activities
	Appendices

Executive Summary

In the increasingly important and complex world of information technology (IT) operations, it is essential to implement a robust and reliable systems management infrastructure based on proven methods. Service Monitoring enables data center managers to increase operational efficiency and to achieve a higher state of availability for mission-critical applications and management of Microsoft® Windows® services. Increased levels of performance can be achieved on Windows platforms through the implementation of this solution accelerator, which incorporates best-practice guidance in planning, building, designing, and deploying Microsoft® Operations Manager (MOM) 2005 to monitor Windows applications and services.

MOM 2005 delivers open and scalable enterprise-class operational management by providing comprehensive event management, proactive monitoring and alerting, reporting and trend analysis, and knowledge and tasks that are specific to systems and applications. Companies have come to rely on MOM to provide overall visibility to the health of their complex computing environment. Like any other service, MOM is susceptible to failure, since it is affected by other service components. Because of its role, it is important that this critical operations management tool have high levels of availability and continuity.

MOM 2005 Service Continuity offers IT managers:

Top of page

Introduction

Document Purpose

This guide provides detailed information about how to achieve higher levels of MOM 2005 availability and service continuity for organizations that have deployed, or are considering deploying, a MOM 2005 infrastructure in a data center or other type of enterprise computing environment. It discusses the steps inherent to preparing for, implementing, and maintaining MOM 2005 Service Continuity and includes failover and restoration steps for databases and for the MOM Management Server.

Background

Service Continuity, as a practice, is aligned with the Service Monitoring and Control and IT Service Continuity Management SMFs. These SMFs are part of the 21 SMFs (shown in Figure 1) defined and described in the Microsoft Operations Framework (MOF) Process Model.

By adopting SMC processes, IT operations is better able to predict service failures and to increase their responsiveness to actual service incidents as they arise, thus minimizing business impact.

Figure 1. MOF Process Model and related SMFs

Statistics that should be reviewed to understand the performance of SMC as well as to identify opportunities for improvement are contained in Appendix B: Key Performance Indicators.

Intended Audience

The guide is intended for IT professionals in data centers and in large and enterprise organizations. In particular, MOM administrators, help-desk personnel, and others involved in service monitoring and control and in service continuity management should find this guide helpful. It assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF, MOM, and other Microsoft technologies discussed. (Links to further information are contained in Appendix A: Resources.) An overview of MOF and its companion, Microsoft Solutions Framework (MSF), is available at http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx.

Terminology

This guide uses terminology that is current for MOM 2005. Table 1 lists the changes in terminology between MOM 2000 Service Pack 1 (SP1) and MOM 2005.

Table 1. Terminology Changes Between MOM 2000 SP1 and MOM 2005

Feedback

Please direct questions and feedback about this guide to msmfeed@microsoft.com.

Top of page

MOM 2005 Service Continuity Overview

Goals and Objectives

This chapter provides reasons for implementing MOM 2005 Service Continuity. In addition, it supplies details about its key phases, scope, high-level requirements, and scenario configurations used throughout the document. The primary goal is to increase the continuity of MOM 2005—a key component in enterprise service monitoring and control—in the event of a critical failure.

The successful implementation of MOM 2005 Service Continuity achieves the following objectives:

Key Phases

MOM 2005 Service Continuity is accomplished in four steps:

These phases are discussed in Chapter 4, “Processes and Activities.”

Scope

MOM 2005 Service Continuity protects the MOM monitoring and control capability, at the application level, for Windows-based production environments. The guidance in this document focuses on new MOM 2005 installations, although most of the concepts also apply to scenarios involving upgrades. The specific MOM 2005 management scope is contained in the MOM 2005 documentation.

This guidance does not address the continuity of MOM integration with other applications. Continuity for that type of data exchange and workflow must be addressed on a case-by-case basis. Moreover, this guidance does not address the continuity of custom MOM extensions and customization through the use of the MOM Connector Framework (MCF) or the MOM Software Development Kit (SDK). Customizations and extensions will likely change the default MOM behavior and performance assumed in this document.

High-Level Requirements

Information about identifying specific service monitoring and control requirements for particular areas is contained in the following SMFs:

These SMFs are available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx.

MOM 2005 Service Continuity requires additional MOM hardware, as specified in the MOM 2005 Supported Configurations document. It also requires additional MOM and Microsoft SQL Server™ licenses. Middleware requirements include Microsoft Data Access Components (MDAC) and the Microsoft .NET Framework. Individual MOM Service Continuity requirements are discussed in the “Analyze MOM Service Continuity Requirements” section, later in this document.

Scenario-Configuration Sample

The configuration discussed in this document is a multitiered, multiple management group that spans four separate geographic locations. The document assumes a fully native MOM 2005 installation with no MOM 2000 or MOM 2000 Service Pack 1 (SP1) interoperability. The installation can run on the infrastructure outlined in Table 2. This is only a sample configuration used for this document and is not intended as a requirement; your configuration may vary.

Table 2. Scenario Configuration for MOM Components

Top of page

Processes and Activities

This chapter shows what processes and activities must be completed to implement MOM Service Continuity.

When implementing MOM Service Continuity, organizations should adhere to the Microsoft Solutions Framework (MSF) life cycle and project-focused guidance. MSF provides a flexible and scalable framework for planning, building, and deploying business-driven solutions. More specifically, the MSF Process Model—with its Envisioning, Planning, Developing, Stabilizing, and Deploying Phases—should be applied to the implementation process.  

MOM Service Continuity also requires close coordination with other SMC activities. These activities include the six core processes that an IT organization follows to fully adopt SMC. These processes, as they relate to the MOM environment, are shown in Figure 2.

Figure 2. Six core processes as they relate to the MOM environment
See full-sized image

You should be familiar with the MOF Service Monitoring and Control SMF (which describes these six core processes) and with the guidance associated with it. Further information is available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsmc.mspx.

Analyze MOM Service Continuity Requirements

Overview

The objective of this step is to complete all required analysis in order to formalize the necessary operational components in MOM 2005 Service Continuity. This includes elements from the IT Service Continuity Management SMF and the Service Monitoring and Control SMF.

Collecting and Formalizing Requirements

This activity is focused on understanding the requirements for MOM Service Continuity in order to meet the desired continuity levels. It also provides a way to gather all necessary considerations so that an optimal design will be created. Further information about this activity is contained in the IT Service Continuity Management SMF, available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsrcmg.mspx.

Collecting and formalizing requirements involves:

Implement MOM Continuity Scheme

Overview

Once MOM 2005 Service Continuity requirements have been analyzed, the second phase entails implementing the continuity scheme into the production environment. One of the key benefits of this implementation is the ability to mitigate a geographical failure. To demonstrate how to successfully perform the implementation process, this section gives a thorough explanation of technology and considerations related to MOM 2005 Service Continuity. It focuses on three areas:

Continuity Architecture

This section provides a high-level overview of implementation and describes the overall continuity architecture, including design drivers.

Geographically-Separate Failover Site

The prescribed scenario involves a multitiered MOM configuration spanning four sites:

Figure 3 illustrates this configuration.

Figure 3. Multisite multitier configuration used in this guide

Most mission-critical enterprises have a similar failover-site design with a chosen hot-standby facility ready to take over operations as needed. This design is driven by the need to have a separate location that can resume a defined level of operations in the event of a failure anywhere within the enterprise. For example, if the Tokyo MOM site fails, the Silicon Valley site can take over.

The Silicon Valley site contains the full functional capability of MOM monitoring, so that visibility to the service components is maintained. Additionally, if a critical failure occurs, monitoring can be taken over by local staff assigned at Silicon Valley.

Multitiered Multiple Management Group Design

The failover solution includes three source management groups (all specifically created according to the size of the geography they serve) and one top tier (destination management group) that serves the enterprise, as shown in Figure 4.

Figure 4. Base configuration used in this guide

Details for the source management groups are as follows:

•

MG1 (Dublin). This management group (MG1) has two MOM servers: a primary middle-tier server local in Dublin, and one middle-tier server in the Silicon Valley failover site, as shown in Figure 5. The primarymiddle tier contains a: • Primary MOM Management Server. • Secondary MOM database. The middle tier in Silicon Valley contains a: • Secondary MOM Management Server. • Primary MOM database. Figure 5. MG1 (Dublin) management group This design is driven by resource and performance constraints. It is a MOM best practice to put the database on a different host from the Management Server on middle-tier servers. With MG1, it is better to have the Management Server closer to the agents; thus it is placed locally. Since this is a small site, the impact on network traffic should be minimal. If your organization is constrained because of bandwidth—rather than because of resources or performance, as with this scenario—it might be more appropriate to place the primary database and the primary Management Server on the same local machine. • MG2 (Redmond). This management group serves the main corporate headquarters. It has three servers running MOM: a primary middle-tier server local in Redmond, a secondary middle-tier server local in Redmond, and one middle-tier server in the Silicon Valley failover site, as shown in Figure 6. The primary middle-tier contains a: • Primary MOM Management Server. The secondary middle tier in Redmond contains a: • Secondary MOM Management Server. • Primary MOM database. The middle tier in Silicon Valley contains a: • Tertiary MOM Management Server. • Secondary MOM database. Figure 6. MG2 (Redmond) management group This design is considered to be the large-site geographic implementation that is driven by agent volume. Similar to MG1, the primary database and Management Server are kept on separate hosts for performance. A failover Management Server is present locally on the same host as the operational database to serve as a degraded-state, first-level failover. The Silicon Valley MG2 middle-tier host then has full geographic failover capability with a tertiary Management Server and secondary operational database. • MG3 (Tokyo). This management group also has three servers running MOM: a primary middle-tier server local in Tokyo, a primary database server local in Tokyo, and one middle-tier server in the Silicon Valley failover site, as shown in Figure 7. The primary middle tier contains a: • Primary MOM Management Server. The primary database in Tokyo contains a: • Primary MOM database. The middle tier in Silicon Valley contains a: • Second MOM Management Server. • Secondary MOM database. Figure 7. MG3 (Tokyo) management group This design serves medium to larger-sized geographic implementations. MG3 (Tokyo ) contains the primary Management Server and primary database server local in Tokyo to accommodate the agent population, which is larger than Dublin’s. The Management Server and database are installed on separate hosts for performance; these two servers need not have the capability or capacity (processor, memory, input/output) of the servers in MG2 (Redmond). The Silicon Valley middle-tier host has full geographic failover capability with a secondary Management Server and secondary operational database. Additionally, in this scenario, Tokyo is in a separate forest and different domain; however, all appropriate trust relationships have been established with the headquarters (HQ). • Top tier (destination management group). This destination management group serves as the alert forwarding target for all management groups in this scenario. The top tier has two servers running MOM: a primary in Redmond, and a secondary in Silicon Valley, as shown in Figure 8. The primary top-tier server contains a: • Primary MOM Management Server. • Primary MOM database server. The secondary top-tier server in Silicon Valley contains a: • Secondary MOM Management Server. • Secondary MOM database server. Figure 8. Top-tier destination management group Although it is a MOM best practice to separate the database from the Management Server, the top tier combines the two components onto one host because the design is driven by alert volume. Despite the fact that MOM 2005 can be configured to forward alert and discovery data, in this configuration it is assumed that the source management group only forwards alerts to the top tier.

Protective Layers

In addition to continuity architecture, a second area to consider in order to successfully implement Service Continuity is protective layers. This section describes the actions taken by each server in the event of a failure. The protection is grouped in two layers:

Within all the configurations, the relationship sequence is always preserved even after failover has occurred for a protected component. For example, when the primary Management Server has failed over to the secondary Management Server, the secondary Management Server should still try to connect to the primary database even though the secondary database may be local.

Database Protection

The first type of protective action taken by each server in the event of a failure is Database protection.

DTS to Enable Database Failover

MOM 2005 currently does not provide optimized out-of-the-box, cross-geographical failover capabilities for the database. To obtain these capabilities, consider the following options:

•

The Service Continuity Solution Accelerator includes a sample custom DTS package. This package can be scheduled to synchronize—at regular intervals—the primary database and the failover database of the same management group in a different location, as shown in Figure 9. Figure 9. Scheduled DTS for synchronization The DTS package also includes a failover script that can be used to switch the Management Server to a failover database. The DTS package uses a push model and needs to be installed and run on the primary MOM database. Further information is contained in the “Continuity Configuration,” later in this document. The performance and network impact that this DTS package introduces varies enormously, depending on the server configuration, network bandwidth, and MOM database size (especially in terms of the number of Sampled Numeric Data, events, and alerts). The sample DTS package has only been tested in a limited number of MOM configuration environments. Because of this, make sure that you fully test the DTS package in your lab to make sure that it will work for your specific MOM environment. Further information about the DTS package and failover script is contained in “DTS Package” and “Supporting Scripts,” later in this document.

•

SQL backup and restore operations. Further information about how to perform these operations is contained in SQL Server 2000 Books Online, available at http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp.

Additional Considerations

SQL Server clustering was considered for MOM 2005 Service Continuity, but was not used for the following reasons:

Log shipping was also considered for MOM 2005 Service Continuity, but was not used for the following reasons:

Database Failure from Primary Middle-Tier Management Server

Redmond (Large Site/Main IT Operations)

With sites managing a larger infrastructure, the primary MOM database is local. In Redmond, there is a standalone primary database and two Management Servers. MOM 2005 prescribes a best practice to keep the database on a dedicated host during normal run-time operations. Because of this, the database is kept separate from the primary Management Server, and only a secondary Management Server —MG2 Secondary—runs on the same machine as the primary database, as shown in Figure 10. The process is as follows:

Dublin (Small Site/Branch Office)

With sites managing a smaller infrastructure, the primary MOM database is located in the failover site. The process is as follows:

Tokyo (Medium Site/Branch Office)

With sites managing a medium infrastructure, the primary MOM database is local. The process is as follows:

Top Tier (Destination Management Group)

In normal run-time operations, the primary top-tier MOM database resides on the same host as the primary Management Server, as shown in Figure 10. The process is as follows:

1.	The primary top-tier Management Server is normally connected to the primary MOM database, which is located on the same host. When a failure of the database is detected, a manual repoint can be initiated using the failover script included in this guide.
2.	This primary top-tier Management Server now uses the secondary MOM database, which is located in the failover site. Figure 10. Database failover from primary middle-tier Management Server

Database Failover from Secondary Middle-Tier Management Server

The secondary middle-tier Management Server only applies to large infrastructure sites, which in this scenario is Redmond, as shown in Figure 11. The process is as follows:

The secondary middle-tier Management Server in Redmond is connected to the primary MOM database, which is located on the same host. When a failure of the database is detected, a manual repoint can be initiated using the failover script included in “Supporting Scripts,” later in this document.

Figure 11. Database failover from secondary middle-tier Management Server

Database Failover from Failover Management Server

This scenario demonstrates the failover for the MOM database if all Management Server capability has been shifted to the failover site. Keep in mind that the primary MOM database for the small site/branch office configuration is already located in the failover site. Additionally, the primary MOM database for the medium, large site, and top tier are installed locally to their original locations, as shown in Figure 12. The process is as follows:

1.	The failover middle-tier and top-tier Management Servers are connected to the primary MOM database, with: • A secondary host for Redmond’s management group. • A primary host for the top tier and Tokyo. • The same host (primary) for the Dublin management group. MOM detects a failure in the database, and a manual repoint is initiated.
2.	The failover middle-tier and top-tier Management Servers now use the alternate MOM database, which is located on the failover site for Tokyo’s management group, Redmond’s management group, and the top tier. For the Dublin management group, this is located on the same host as the primary Management Server. Figure 12. Database failover from failover site Management Server

Management Server Protection

The second type of protective action taken by each server in the event of a failure is Management Server protection. Again, this is categorized by role—middle tier and top tier.

Middle-Tier Failure Mitigation

If a Management Server fails within the middle tier, there are multiple layers of protection that are automatically available if configured. In MOM 2005, the agent is now capable of automatically attempting to deliver the alert to each of the Management Servers in a preconfigured sequence until it has a working reception. The following steps illustrate middle-tier Management Server protection, as shown in Figure 13.

Figure 13. Middle-tier Management Server protection

Redmond (Large Site/Main IT Operations)

The following steps apply to middle-tier Management Server protection for Redmond:

Dublin (Small Site/Branch Office) and Tokyo (Medium Site/Branch Office)

The following steps apply to middle-tier Management Server protection for Dublin:

Top-Tier Failure Mitigation

In the event of a failure of the primary destination management group (top tier), there is a layer of protection that is automatically available if enabled. The middle-tier Management Servers (source management group) must have their alert forwarding configured for the primary destination management group (top-tier Management Server) and the failover remote secondary destination management group (top-tier Management Server). In MOM 2005, alert forwarding, which is made available through the MOM Connector Framework (MCF), is now capable of automatically attempting to forward alerts to each of the configured targets until it is able to achieve a working reception.

Primary Middle-Tier Management Server

The following steps illustrate top-tier Management Server protection, as shown in Figure 14:

1.	The primary Management Server (source management group) first tries to send a forwarded alert to the primary top-tier Management Server (destination management group). If the forwarding attempt fails, the Management Server will automatically attempt to send the alert to the alternate top-tier Management Server (destination management group) in the failover site.
2.	This alternate top-tier Management Server (destination management group) is located in the failover site, which is geographically separate from the rest of the infrastructure. Figure 14. Top-tier failover from primary middle-tier Management Server

Secondary Middle-Tier Management Server

The scenario in Figure 15 applies to the large configuration for the Redmond (main IT operations), which has a secondary middle tier. In this scenario, the primary middle-tier Management Server has failed, and the infrastructure relies on the secondary. The process is as follows:

1.

The secondary Management Server (source management group) first tries to send the forwarded alert to the primary top-tier Management Server (destination management group). If the sending Management Server is unable to forward the alert, the Management Server will automatically attempt to send the alert to the alternate top-tier Management Server (destination management group) in the failover site.

2.

This alternate top-tier Management Server (destination management group) is located in the failover site, which is geographically separate from the rest of the infrastructure. Figure 15. Top-tier failover from secondary middle-tier Management Server

Middle Tier Management Servers in Failover Site

This continuity measure applies to the scenario in Figure 16, where the primary and secondary middle-tier Management Servers have failed and all events are being collected by the middle-tier Management Servers in the failover site. The process is as follows:

1.	The failover Management Server (source management group) first tries to send the forwarded alert to the primary top-tier Management Server (destination management group). If the sending Management Server is unable to forward the alert, the Management Server will automatically attempt to send the alert to the alternate top-tier Management Server (destination management group) in the failover site.
2.	This alternate top-tier Management Server (destination management group) is located in the failover site, which is geographically separate from the rest of the infrastructure. Figure 16. Top-tier failover from middle-tier Management Servers

Continuity Configuration

The third area to consider in order to successfully perform the implementation process—in addition to continuity architecture and protective layers—is continuity configuration. This section describes specific steps on how to implement the protective layers and architecture described in previous sections.

Continuity Management

Identify a failover site, ideally a business and IT operations location that is geographically separate from both the main IT operations and other business operations. The key requirements for MOM 2005 Service Continuity within this site are computing facilities that are sufficient for a data center. This includes:

MOM Server 2005 Configuration

The Management Server should have a larger queue size to increase the failover window during a database failover scenario. Further information about database failover is contained in “Database Failover Process,” later in this document.

To increase the queue size

Agent to Management Server Failover Configuration

The Management Server that is used to target and install the agent for a managed computer is by default its primary Management Server. Ideally, the complete Management Server infrastructure and relationships should be in place prior to adding agents, so that failover configuration is automatically adopted when the agents are installed.

To manually configure an automatic failover for the agents

Middle to Top-Tier Failover Configuration

Information about configuring the multitiered layers of the MOM infrastructure is contained in the MOM 2005 documentation.  

To configure the failover portion

DTS Package

The sample Data Transformation Services (DTS) package that is part of the Service Continuity Solution Accelerator can be installed on the primary MOM database. The sample DTS package is responsible for keeping the primary MOM database and failover MOM database in synchronization. This is accomplished by periodically transferring the data via DTS from the primary MOM database to the secondary MOM database. This section outlines the steps for installing, configuring, and executing the DTS package.

Important As mentioned in the previous sections, this sample DTS package has only been tested on limited MOM 2005 configurations. Since MOM 2005 configurations in different environments can vary, it is strongly recommended that you fully test the sample DTS package in your lab to make sure that it works well in your environment before running it in production. Depending on your environment and test results, you might find that a regularly scheduled and automated backup and restore operation might be more favorable.

Prerequisites

The following requirements must be met before installing, configuring, and executing the DTS package:

Security Requirements

The only security requirement required for installing, configuring, and running the DTS package is that the user should be an administrator on both the primary MOM database and the failover MOM database.

Installation

To install the .msi package

Configuration Steps to Be Done Before First Run of DTS Package

A few SQL scripts need to be executed for configuring the DTS package before the first execution. These scripts can be found at C:\Program Files\Microsoft\ServiceContinuity\Scripts.

This path is based on the default location. If the user specifies a different location, the path would be <install path>\Scripts.

To configure the DTS package

Execution of the DTS Package

After the preceding configuration steps are performed, the DTS package is ready to be run. Further information about ways to execute the DTS package is contained in Appendix C: Working with the Service Continuity DTS Package.

The schedule for the DTS package will vary from organization to organization, since the DTS execution time is directly dependent on the rate of growth and the size of the MOM database. To schedule the DTS package, the recommended practice is to manually execute it the first time it is run and note the execution time. It will then be possible to schedule subsequent runs of the DTS package, so that they do not overlap.

In addition, make sure that the run time of this DTS package does not overlap with the MOMX - Partitioning and Grooming job, which is scheduled to run by default at the server’s local time of 12:00:00 A.M. (midnight). This job makes the Event, EventParam, and EventConsolidated views on the OnePoint database repoint to a new partitioned table corresponding to each respective table. If you run the DTS package during the partitioning job, there might be race conditions, and the DTS package execution might fail. If this happens, the only way to reset the DTS package is to uninstall the package and restart the whole installation process. Once you ensure that the partitioning job is completed, you can safely run the Service Continuity DTS package. Further issues are contained in “Known Issues,” later in this document.

If the DTS package is manually interrupted (say, by clicking Cancel), the DTS package will need to be reset prior to being rerun.

To reset the DTS package

Execute the SQL script ResetIsRunningBit.sql in the primary MOM database.

Configuration Steps to Be Done in Case of Failover of the MOM Database

If the primary database is down and you have to repoint in order to use the backup database, a few SQL scripts need to be executed on the failover database server prior to the failover of a MOM database. It is essential to perform these configuration steps before the failover MOM database becomes active.

To prepare the failover MOM database prior to failover

Uninstallation

The Service Continuity DTS package can be uninstalled in one of the following manners:

DTS Details

Data that is transferred by the DTS package from the MOM database can be grouped into the following three types of tables:

For partitioned tables, an incremental update is done in the failover MOM database. The incremental data to be transferred for each partition is determined by taking into account the previous run time of the specific partitioned table (first checkpoint) and the start-time execution of the current DTS package. In addition to the four partitioned tables, there is another table called EventParamName that is incrementally updated.

For nonreferenced tables, there is a complete transfer of the data from the source to the destination.

Note Data from the audit and grooming tables will not be transported as part of the DTS package. There are also no schema changes required for the MOM database as part of MOM 2005 Service Continuity.

Further information and a complete list of tables that come under each category are contained in Appendix C: Working with the Service Continuity DTS Package.

DTS Impact

The schedule for the DTS package will need to be determined based on the package’s execution time, which varies depending on the size of the MOM database.

The rate of growth of the MOM database also needs to be factored in when setting the schedule to ensure that there is no overlapping of consecutive DTS tasks.

Supporting Scripts

All supporting scripts are located at C:\Program Files\Microsoft\ServiceContinuity\Scripts. This is based on the default location. If a different location is specified, the path is <install path>\Scripts.

There are two categories of supported scripts:

Automated Script for Database Failover

During failover, a script (PointToServer.vbs) is provided to automate the repointing of the Management Server from the primary MOM database to the failover MOM database.

To repoint a Management Server during failover

SQL Scripts

These scripts include:

Known Issues

The following items are known issues to be aware of:

Follow Failover and Restoration Guidelines

After implementing the continuity scheme, the third phase in implementing Service Continuity is to follow failover and restoration guidelines. The detection of failure on a Management Server is quickly observed by the monitoring operators from the MOM Operator console, and in the extreme case of full failover, the MOM Administrator console or Web console must be connected to the failover top tier. The process is as follows:

Failover Steps

The following guidelines apply to database and management server failovers.

Database Failover Process

The database failover should not be triggered unless absolutely necessary. This is because there is a potential data loss of up to the length of the DTS execution interval. (That is, if the DTS is scheduled to be run every one hour, there could be data loss of up to one hour.)

The database failover process involves a three-step process:

Management Server Failover

Management Server failover is automated with no manual intervention required. However, when this failover has occurred, verify that all services have been accurately repointed, that databases are functioning normally, and that alert forwarding is also taking place.

Restoration Steps

The following guidelines apply to the restoration of databases and management servers.

Database Restoration

If a primary database has failed and MOM is using a secondary database, the primary should be restored to its original healthy state and services transferred back.

To restore the primary database

Management Server Restoration

Restoring Management Servers is a much simpler process than restoring databases, since all components continue to the source or attempt to connect to the primary Management Servers.

To restore the Management Server

Maintain Continuity Readiness

Overview

The objective of this fourth and final phase in implementing Service Continuity is to execute checks and maintenance activities in order to keep the automated continuity capability tuned and ready.

Readiness Activities

DTS Package Check

Every time the DTS job fails, the amount of data that the DTS must process and then transport to the alternate MOM database gets much bigger. If the DTS job fails to run for several consecutive cycles, the DTS should be stopped; a full database backup on the source and a restoration on the failover site should be performed to synchronize the databases. In this failure condition, the DTS job will start to overrun, overlap, and potentially hit its maximum capability. When this happens, the failover capability will not be available.

Audit of the Continuity/Failover Plan

Review and refresh the continuity plans for MOM 2005. Make sure that the service level agreements (SLAs) are up to date and accurate, the roles and responsibilities are well communicated, the appropriate staff resources are prepared, and the supporting technical infrastructure is in place and has been reflected in the plan.

Top of page

Appendices

Appendix A: Resources

Availability Management SMF, available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfavamg.mspx

IT Service Continuity Management SMF, available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsrcmg.mspx

Service Level Management SMF, available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfslamg.mspx

Service Monitoring and Control SMF, available at http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfsmc.mspx

Overview of MOF and MSF, available at http://www.microsoft.com/technet/itsolutions/cits/mo/mof/default.mspx

Appendix B: Key Performance Indicators

The following statistics should be reviewed to understand the performance of Service Monitoring and Control as well as to identify opportunities for improvement. Each value is mapped over predefined time frames (such as daily, weekly, or monthly).

Appendix C: Working with the Service Continuity DTS Package

After the ServiceContinuity package is successfully installed on the local SQL Server, its existence on that server must be verified.

After the scripts are successfully executed, the ServiceContinuity package can be executed either through the graphical user interface (GUI) or through the command prompt.

To execute the DTS package through the GUI

1.	Navigate to the package in the SQL Server at Data Transformation Services\Local Packages as shown here. Figure 17. Navigating to the DTS package
2.	Double-click ServiceContinuity, and the following screen appears. Figure 18. Screen for the Service Continuity DTS package
3.	From the Package menu, click Execute. Figure 19. Executing the package

To execute the DTS package through the command prompt

1.	Open the command prompt, and type the following command: dtsrun \E \S (local) \N ServiceContinuity \G <package GUID>
2.	To obtain <package GUID> from the package properties, open the ServiceContinuity package. On the Package menu, click Properties. Figure 20. Obtaining the package GUID A window appears, showing the properties where the package GUID can be obtained. Figure 21. Location of package GUID is shown

Note If the execution of the ServiceContinuity DTS package is cancelled, the ResetIsRunningBit.sql script must be run in the primary MOM database before the next execution.

Tables Transported

The ServiceContinuity DTS package transports referenced, nonreferenced, and partitioned tables from the primary MOM database to the failover MOM database.

Referenced Tables

Referenced tables that the sample DTS package will transfer have been separated into different groups based on the foreign key–primary key constraints between them.
See full-sized image

Nonreferenced Tables

The following are the nonreferenced tables the sample DTS package will transfer.

Partitioned Tables

The DTS package will transport incremental data from the MOM database for the following tables:

Service Continuity Logs

During the time the ServiceContinuity package is being executed, the package stores the success and failure of the tasks in a log file, which is stored in C:\ServiceContinuity_logs. This log file, which is named ServiceContinuity DTS <Data and time of its creation>log, contains:

If all the tasks have succeeded, their success and the end time of execution of the package are recorded. If a particular task fails, its failure and the end time of execution of the package are recorded; the tasks following it are not recorded.

The logs are also made on the local server in the package logs.

To view the package logs

1.	From the SQL Server Enterprise Manager, go to Console Root\Microsoft SQL Servers\SQL Server Group\CHNSHL13423 (Windows NT)\Data Transformation Services\Local Packages.
2.	Right-click the package name, and then click Package Logs. Figure 22. Viewing the package logs

Top of page