Advanced MOM Concepts

MOM's simple installation and relative ease of use often betray the potential complexity of its underlying components. This complexity can be managed, however, with the right amount of knowledge of some of the advanced concepts of MOM design and implementation.

DCAM Versus D-DCAM Servers

As previously mentioned, MOM components can be divided across multiple servers to distribute load and ensure balanced functionality. This separation allows MOM servers to come in three potential "flavors," depending on the MOM components held by those servers. The three MOM server types are as follows:

• Database server A MOM database server is simply a member server with SQL Server 2000/2005 installed for the MOM database. No other MOM components are installed on this server. The SQL Server 2000/2005 component must be installed with default options and with a SQL service account. The service account, in addition to any other service accounts utilized by DAS and the consolidator, require the use of a client access license.

• DCAM server Also known as simply a DCAM, this type of server is named after the MOM components used by the server. The DAS, consolidator, and agent manager components all reside on a DCAM. In addition, the console and user interfaces are also held by this server. Effectively, a DCAM is a MOM server without a database and is often used in large MOM implementations that have a dedicated database server. Often, in these configurations, multiple DCAMs are used in a single configuration group to provide for scalability and to address multiple managed nodes.

• D-DCAM server A D-DCAM server is effectively a MOM server that holds all MOM roles, including that of the database. Subsequently, single-server MOM configurations use one D-DCAM for all MOM operations, excluding reporting.

Multiple Configuration Groups

As previously defined, a MOM configuration group is a logical grouping of monitored servers that are managed by a single MOM SQL database, one or more DCAMs, and a unique configuration group name. Each configuration group established operates completely separately from other configuration groups, although they can be configured to forward alerts between each other.

The concept of alert forwarding between configuration groups allows MOM to scale beyond artificial boundaries and also gives a great deal of flexibility when combining MOM environments. However, certain caveats must be taken into account. Because each configuration group is an island in itself, each must subsequently be manually configured with individual settings. In environments with a large number of customized rules, for example, such manual configuration would create a great deal of redundant work in the creation, administration, and troubleshooting of multiple configuration groups.

Deploying Geographic-Based Configuration Groups

Based on the factors outlined in the preceding section, it is preferable to deploy MOM in a single configuration group. However, in some situations it is preferable not to divide a MOM environment into multiple configuration groups, or dividing it this way is unavoidable.

The most common reason for division of MOM configuration groups is division along geographic lines. In situations in which WAN links are saturated or unreliable, it may be wise to separate large "islands" of WAN connectivity into separate configuration groups.

Simply being separated across slow WAN links is not enough reason to warrant a separate configuration group, however. For example, small sites with few servers would not warrant the creation of a separate MOM configuration group, with the associated hardware, software, and administrative costs. However, if many servers exist in a distributed, generally well-connected geographical area, that may be a case for the creation of a configuration group. For example, an organization could be divided into several sites across the U.S. but decide to divide the MOM environment into separate configuration groups for east coast and west coast, to roughly approximate their WAN infrastructure.

Smaller sites that are not well connected but are not large enough to warrant their own configuration group should have their event monitoring throttled to avoid being sent across the WAN during peak usage times. The downside to this approach, however, is that the reaction time to critical event response is increased.

Deploying Political or Security-Based Configuration Groups

The less common method of dividing MOM configuration groups is by political or security lines. For example, it may become necessary to separate financial servers into a separate configuration group to maintain the security of the finance environment and allow for a separate set of administrators.

Politically, if administration is not centralized within an organization, configuration groups can be established to separate MOM management into separate spheres of control. This would keep each MOM management zone under separate security models, and alert forwarding could be set up to exchange information between different configuration groups.

As previously mentioned, a single configuration group is the most efficient MOM environment and provides for the least amount of redundant setup, administration, and troubleshooting work. Consequently, artificial MOM division along political or security lines should be avoided, if possible.

Sizing the MOM Database

All new technologies seem to consume tremendous amounts of disk space, and MOM is no exception to this trend. Depending on several factors, such as the type of data collected, the length of time that collected data will be kept, or the amount of database grooming that is scheduled, a MOM database can grow by leaps and bounds, if left unchecked. Microsoft recommends a database volume of 5GB, although it is highly recommended to consider leaving more than enough space for the database to grow. An organization might want, for example, to keep event information for longer periods of time, which would drive up the size of the database exponentially.

Estimating the Size of a MOM Database

The formula Microsoft uses for MOM database sizing shows the approximate amount of disk space a database will consume. Bear in mind that 40% should be added to the numbers that are produced by this formula as MOM indexing requires 40% free space on the database volume.

(((e*s)1400)g) 

where:

e = Total number of events, security events, performance counters, and unsuppressed alerts per minute

s = Average kilobyte size of each event, counter, and alert

1400 = Number of minutes in a day

g = Grooming interval, expressed in number of days

It is important to monitor the size of the database to ensure that it does not increase well beyond the bounds of acceptable size. As previously mentioned, MOM requires a minimum of 40% free space on the database volume to properly index, and it is imperative that a database not grow too large to affect this performance. The following actions can be taken to reduce the size of a MOM database:

• Archive collected data The more often old data is archived, the smaller a database will become, for obvious reasons. When a MOM database becomes too large, for example, it may become necessary to archive old data to alternate storage mediums. The downside to this approach, however, is the fact that reporting can generate historical reports only up to the point of the last archival. Finding the right tradeoff between an aggressive archiving schedule and an expansive database is recommended.

• Modify the grooming interval As evident from the formula just presented, increasing the database grooming interval decreases the size of a database significantly. Setting the grooming interval to once every few days, for example, can aggressively address space limitations and keep the database consistent. Setting a regular grooming interval is subsequently key to an effective database maintenance strategy.

MOM can be configured to monitor itself, supplying advance notice of database problems and capacity thresholds. This type of strategy is highly recommended because MOM could easily collect event information faster than it could get rid of it.

Capacity Limits

As with any system, MOM includes some hard limits that should be taken into account before deployment begins. Surpassing these limits could be cause for the creation of new configuration groups and should subsequently be included in a design plan. These limits are as follows:

• Single database per configuration group MOM operates through a principle of centralized, rather than distributed, collection of data. All event logs, performance counters, and alerts are sent to a single centralized database, and there can subsequently be only a single SQL database per configuration group. Considering the use of a backup and high-availability strategy for the MOM database is therefore highly recommended, to protect it from outage.

• Six DCAMs per configuration group MOM is hard-coded to be limited to six DCAM servers per configuration group. If the pool of monitored servers increases beyond the capabilities of six DCAMs, adding an additional configuration group will become necessary, to handle all monitoring in the environment. Any configuration group with six DCAMs would be more likely limited by the size and throughput of the database, which by that point would most likely be enormous.

• 700 agents per DCAM Each DCAM can theoretically support up to 700 monitored agents for every DCAM server. In most configurations, however, it is wise to limit the number of agents per DCAM to 200, although the levels can be scaled upward with more robust hardware, if necessary.

• 30 console instances per DCAM MOM limits the number of instances of the Web and MMC Admin consoles to 30 per DCAM.

Scaling MOM Environments

MOM is scalable in the sense that multiple configuration groups can be configured to forward alerts between themselves. Within the configuration groups, multiple DCAM servers can be established as well to allow for a finer degree of scalability within each configuration group. These factors enable MOM to scale to organizations of all shapes and sizes.

MOM builds upon its multiple layers of scalability. In small deployments, a single DDCAM server will suffice. As the number of monitored servers increases, the database can be separated and additional DCAM servers can be added, roughly one per every 100 agents deployed. This can be continued until a total of six DCAM servers are deployed in a configuration group, as illustrated in Figure 25.6.

Figure 25.6. Multiple DCAMs.

When the physical limits of a configuration group have been reached, or when additional factors such as security, geographic, or political considerations move an organization to choose an additional configuration group, the final level of MOM scalability is reached. Division into multiple configuration groups allows an organization to scale a MOM deployment beyond the physical limitations of the configuration group itself.

System Redundancy

In addition to the scalability built into MOM, redundancy is built into the components of the environment. Proper knowledge of how to deploy MOM redundancy and place MOM components correctly is important to the understanding of MOM redundancy.

Having multiple DCAM servers deployed across a configuration group allows an environment to achieve a certain level of redundancy. If a single DCAM server experiences down-time, another DCAM server within the configuration group will take over the consolidator, DAS, and agent manager components for the monitored servers in the environment. For this reason, it may be wise to include multiple DCAM servers in an environment to achieve a certain level of redundancy if high uptime is a priority, as illustrated in Figure 25.7.

Figure 25.7. MOM failover.

Because there can be only a single MOM database per configuration group, the database is subsequently a single point of failure and should be protected from downtime. Utilizing Windows Server 2003 clustering or third-party fault-tolerance solutions for SQL databases helps to mitigate the risk involved with the MOM database.