Databases Reference
In-Depth Information
The Agent must be installed onto each target server that will be monitored, and communication
must be enabled with its gateway. If the target server and gateway are not in the same security zone
(i.e., not in the same domain or in a workgroup), then certii cates must be used to provide authen-
tication between the target server and gateway. Each server can report to up to six management
groups.
The Gateway role is both a security boundary and an architectural scalability point. Given that the
SCOM platform is designed to scale to monitor many thousands of devices, the RMS may become
a point of contention if all devices were set up to report directly to this host. Instead, the Gateway
servers provide a point of scale-out for the monitoring infrastructure. Additionally, in scenarios in
which organizations operate from multiple locations or use different security zones, gateway serv-
ers can be used as a security boundary and as a point of aggregation for data l owing to the RMS.
Agents are “homed” to a given Gateway, and a PowerShell script can be used to provide a failover
Gateway, providing a fault-tolerant solution.
The top tier in the hierarchy is the Root Management Server (RMS), which is the central point for
coni guration and changes (new agents and rules or monitors). The RMS server must be able to
communicate with all Gateway servers; and if no Active Directory trust exists, certii cate authenti-
cation must be coni gured.
Rules and Monitors
Two types of checks are carried out by SCOM: rules and monitors. Both collect data, and under-
standing the difference between them is crucial for determining which should be used.
A monitor is a near real-time operation, and the only way to alter the health state of a managed
object. Additionally, the health state changes automatically once the condition is resolved. An exam-
ple is low disk space; once space is released, the monitor will resolve automatically. Collected data is
not stored.
A rule is typically used to collect data about a specii c object (e.g., Avg Disk Transfer/sec for a stor-
age performance baseline). Rules may also be useful to create an alert without affecting health state.
These alerts must be resolved manually. Collected data is stored in the data warehouse.
Alerts
The i nal fundamental SCOM concept to understand is alerts. An alert is not an e-mail or page noti-
i cation, but an event that can be triggered by a monitor or rule. Alerts are displayed in the SCOM
Console, under the Alerts tab where they are sorted in order of priority by default. A notii cation is
a method of communication — such as e-mail, SMS, or pager — i red on an alert.
Calibration is the process of tuning alerts to ensure the correct level of sensitivity. An environment
can contain vastly different database workloads, Windows and SQL Server coni guration settings,
and optimization, so the concept of a healthy server can also vary. Alert calibration rei nes thresh-
olds on a per-server basis to ensure that alerts are meaningful.
Alert tuning takes the form of overrides, which modify thresholds from the standard to customize
the values of a given rule or monitor for a specii c server or group (e.g., All Windows 2008 Logical
Disks or All SQL Server 2008 databases).
Search WWH ::
Custom Search