Home > Articles > Software Development & Management

How Does Microsoft Operations Manager Work?

  • Print
  • + Share This
  • 💬 Discuss
MOM 2005 is a powerful tool, but that power comes at the expense of a certain amount of complexity. This sample chapter introduces MOM 2005 with an architectural overview and discussion of some of its major components, discussing several MOM components including agents, the MOM Service, and the Data Access Service.

In this Chapter

  • Architectural Overview
  • Communications
  • How Does MOM Do It?
  • Data Layer
  • Business Logic Layer
  • Presentation Layer

Successfully deploying Microsoft Operations Manager (MOM) 2005 requires understanding how it works and how to implement it. MOM 2005 is a powerful tool, but that power comes at the expense of a certain amount of complexity. In this chapter, we continue our introduction to MOM 2005 with an architectural overview and discussion of some of its major components. We discuss several MOM components including agents, the MOM Service, and the Data Access Service.

You'll become familiar with terms such as management group, management server, managed computer, and management packs. If you have already read Chapter 2, "What's New," you may notice that some of these components were previously introduced as new functionality with MOM 2005. This chapter provides the groundwork for understanding MOM, which will assist in planning your installation and deployment of MOM.

Architectural Overview

MOM obtains raw event and performance data to translate into system health information. Using rules, which are MOM's basic unit of instruction, you can define the characteristics of a properly running application and have MOM warn you when these capabilities are not being met. MOM collects event and performance data on monitored systems, looking for specific events that indicate poor performance, errors, or other factors specified in its rules.

MOM not only collects data, it filters that information so that you see only what is important. MOM also consolidates multiple occurrences of events into a single representation—minimizing superfluous "noise" and data. Alerts occur when specific events or performance conditions occur.

Monitoring begins after installing one or several management groups, importing management packs, enabling rules, and identifying computers to monitor. The monitored computers send event and performance data to a management server, which stores that data in the MOM database. Operational data is viewed using the MOM Operator console or a web-based console. Data can also be maintained in a reporting database for long-term analysis and study.

What Is a Management Group?

The basic management unit of MOM is the MOM management group, illustrated in Figure 3.1. A management group is a MOM installation that includes one MOM database, one or more MOM management servers, and MOM agents installed on monitored systems. You can optionally install a Report server, Reporting database server, and/or additional management console(s). MOM can also manage a limited number of computers using an agentless monitoring technique.

Figure 3.1

Figure 3.1 The MOM management group.

The management group provides the features and benefits discussed in Chapter 1, "Operations Management Basics," namely:

  • Event-based monitoring
  • Easily deployed and scalable infrastructure
  • Effective system availability and performance tracking

There are quite a few MOM components, all of which are ultimately bound into a management group. A functional management group contains the following components:

  • Operations database
  • Management Server
  • Data Access Service (DAS)
  • Agents
  • Administrator console
  • Operator console

There are optional components, including:

  • Reporting database
  • Reporting console
  • Web console

In the next section we look at these components and how they interoperate.

Server Roles

The MOM components can be grouped into server roles (shown in Figure 3.2), which is ultimately what is built during your MOM implementation. The standard component groupings are

  • Database server role—The database server normally contains the operations database and is a platform optimized for data collection—that is, to rapidly process a large amount of incoming data from the management servers. In classic client server architecture, this is known as the backend tier. In the MOM architecture, the database server is a big portion of the data layer or tier.
  • Management server role—The management server typically contains the MOM service, the DAS, an agent, the Administrator console, the Operations console, and the Web console. The management server handles most of the centralized business logic and presentation layer functions, with the important exception of the reporting functions.
  • Report server role—The report server typically contains the reporting database and the Reporting console. The reporting database is frequently located on a separate server for performance reasons. Using a separate server allows large volumes of data to be retained and mined with the reporting function, without affecting the operation's function on the database and management servers.
Figure 3.2

Figure 3.2 Management group roles.

In any given MOM installation, you can combine these roles in a variety of ways. In smaller installations, the server roles might all be on the same physical server with the net effect that there is only one "MOM Server." In a medium-sized organization, there might be two physical management servers for fault tolerance and a single database server with both the operations and reporting functions. In a large enterprise organization, there would likely be separate physical servers for the database server and the reporting database server, as well as multiple management servers for both load balancing and fault tolerance (and possibly also clustering the databases). Chapter 4, "Planning Your MOM Deployment," covers the rationale for splitting or combining the roles, as well as how to create a MOM 2005 design that meets the needs of your organization.

A management group can have multiple management servers as shown in Figure 3.3. Reasons for having multiple management servers include:

  • Scalability
  • Fault tolerance
  • Security
  • Crossing geographic or network boundaries
Figure 3.3

Figure 3.3 Management group with four management servers.

Agents within the management group have a primary management server assigned to them, and then each of the remaining management servers are backup management servers for the agent. Figure 3.3 shows four management servers with each assigned 25% of the agents, represented by the solid lines. The mesh of dotted lines represents the redundant failover connections the agents are automatically configured to use. Agent configurations are dynamically adjusted as new management servers are brought online or decommissioned. In the event that an agent fails over to one of its backup management servers, it periodically checks to see whether its primary management server is back online and fails back automatically when that occurs. More information on failover processing is available in Appendix A, "MOM Internals."

  • + Share This
  • 🔖 Save To Your Account

Discussions

comments powered by Disqus