OpsMgr is primarily composed of
five basic components: the operations database, reporting database, Root
Management Server, management agents, and Operations Console. These
components make up a basic deployment scenario. Several optional
components are also described in the
following bulleted list; these components provide functionality for
advanced deployment scenarios.
OpsMgr was specifically
designed to be scalable and can subsequently be configured to meet the
needs of any size company. This flexibility stems from the fact that all
OpsMgr components can either reside on one server or can be distributed
across multiple servers.
Each of these
various components provides specific OpsMgr functionality. OpsMgr design
scenarios often involve the separation of parts of these components
onto multiple servers. For example, the database components can be
delegated to a dedicated server, and the management server can reside on
a second server.
The following list
describes the different OpsMgr components:
Operations
database— The operations database stores
the monitoring rules and the active data collected from monitored
systems. This database has a 7-day default retention period.
Reporting database— The reporting database stores archived data
for reporting purposes. This database has a 400-day default retention
period.
Root
Management Server— This is the
first management server in the management group. This server runs the
software development kit (SDK) and Configuration service and is
responsible for handling console communication, calculating the health
of the environment, and determining what rules should be applied to each
agent.
Management
server— Optionally, an additional management server can be
added for redundancy and scalability. Agents communicate with the
management server to deliver operational data and pull down new
monitoring rules.
Management agents—
Agents are installed on each managed system to provide efficient
monitoring of local components. Almost all communication is initiated
from the agent with the exception of the actual agent installation and
specific tasks run from the Operations Console. Agentless monitoring is
also available with a reduction of functionality and environmental
scalability.
Operations Console— The Operations Console is used to monitor systems, run tasks,
configure environmental settings, set author rules, subscribe to
alerts, and generate and subscribe to reports.
Web console— The Web console is an optional component used to
monitor systems, run tasks, and manage Maintenance mode from a web
browser.
Audit
Collection Services— This is an
optional component used to collect security events from managed systems;
this component is composed of a forwarder on the agent that sends all
security events, a collector on the management server that receives
events from managed systems, and a special database used to store the
collected security data for auditing, reporting, and forensic analysis.
Gateway server— This optional component provides
mutual authentication through certificates for nontrusted systems in
remote domains or workgroups.
Command shell—
This optional component is built on PowerShell and provides full
command-line management of the OpsMgr environment.
Agentless Exception
Monitoring— This component can be
used to monitor Windows and application crash data throughout the
environment and provides insight into the health of the productivity
applications across workstations and servers.
Connector Framework— This optional component provides a bidirectional
web service for communicating, extending, and integrating the
environment with third-party or custom systems.
The Operations Manager 2007
architecture is shown in Figure 1, with all the major components and their data paths.
Understanding How
OpsMgr Stores Captured Data
OpsMgr itself utilizes
two Microsoft SQL Server databases for all collected data. Both
databases are automatically maintained through OpsMgr-specific scheduled
maintenance tasks.
The operations database
stores all the monitoring rules and is imported by management packs and
operational data collected from each monitored system. Data in this
database is retained for 7 days by default. Data retention for the
operations database is lower than the reporting database to improve
efficiency of the environment. This database must be installed
as a separate component from OpsMgr but can physically reside on the
same server, if needed.
The reporting database stores
data for long-term trend analysis and is designed to grow much larger
than the operations database. Data in the reporting database is stored
in three states: raw data, hourly summary, and daily summary. The raw
data is only stored for 14 days, whereas both daily and hourly data are
stored for 400 days. This automatic summarization of data allows for
reports that span days or months to be generated very quickly.
Determining the Role of
Agents in System Monitoring
The agents are the
monitoring components installed on each managed computer. They monitor
the system based on the rules and business logic defined in each of the
management packs. Management packs are dynamically applied to agents
based on the different discovery rules included with each management
pack.
Defining Management
Groups
OpsMgr utilizes the concept
of management groups to logically separate geographical and
organizational boundaries. Management groups allow you to scale the size
of OpsMgr architecture or politically organize the administration of
OpsMgr.
At a minimum, each
management group consists of the following components:
OpsMgr can be scaled to meet
the needs of different sized organizations. For small organizations, all
the OpsMgr components can be installed on one server with a single
management group. In large organizations, on the other hand, the
distribution of OpsMgr components to separate servers allows the
organizations to customize and scale their OpsMgr architecture. Multiple
management groups provide load balancing and fault tolerance within the
OpsMgr infrastructure. Organizations can set up multiple management
servers at strategic locations, to distribute the workload among them.
Note
The general rule of thumb
with management groups is to start with a single management group and
add on more management groups only if they are absolutely necessary.
Administrative overhead is reduced, and there is less need to re-create
rules and perform other redundant tasks with fewer management groups.
