Strategies for Monitoring Failover Clusters (Part 6)

by [Published on 21 Feb. 2012 / Last Updated on 21 Feb. 2012]

This article concludes the series on failover clustering by discussing event notifications.

If you would like to read the other parts in this article series please go to:

Introduction

In my previous article in this series, I showed you the types of information that System Center Operations Manager (SCOM) could provide you with regard to your failover cluster. While it’s great to have so much information at your fingertips, I have not yet addressed the main point that I mentioned at the very beginning of this article series.

My initial point was that server clusters are great for providing high availability. They are so good in fact that it can be difficult to tell when a failure has occurred. Suppose for instance that a cluster node goes down, but your clustered application keeps running without a hitch. How would you even know about the failure unless you happen to walk into the datacenter and glance at the server console?

SCOM offers various alerting capabilities that can help with the situation that I just described. Rather than a cluster node failure potentially going unnoticed, SCOM can be configured to alert us to the failure.

Notification Basics

There are three main elements used in SCOM notifications. These include:

Channels – Channels are essentially a notification path. A channel can send notifications through E-mail, instant messages, or SMS text messages.

Subscribers – Subscribers are a group of people who receive notifications.

Subscriptions – Subscriptions are the events for which subscribers want to be notified.

Channels

The first step in creating notifications is to define one or more channels. To do so, open the System Center Operations Manager 2007 R2 management console, and go to the Administration tab. Next, locate and right click on the Channels container in the console tree and then choose the New Channel command from the shortcut menu. As you can see in Figure A, you must pick the type of channel that you want to create.


Figure A: Choose the type of channel that you want to create.

When you make your selection, SCOM will launch a wizard that will walk you through the steps involved in creating the channel. The actual prompts that you will see vary depending on the type of channel that you are creating. All of the channel types require you to provide a channel name and an optional description, but things vary from there. For example, if you create an E-mail notification channel you will be prompted to enter the address of your SMTP server as well as a return E-mail address.

When you create a channel you are also given the opportunity to customize the notification. For example, if you look at Figure B, you can see the E-mail message that SCOM allows you to fully customize the default E-mail notification.


Figure B:
SCOM allows you to customize the default E-mail message.

Subscribers

A subscriber list allows you to control who will receive the notifications that SCOM generates. Even so, the subscriber list is more than just a list of recipients. When you define a subscriber, you must also tell SCOM when and how to reach them. For example, suppose that you wanted to set up a particular user as a subscriber. You could tell SCOM to contact them by E-mail between 9:00 and 5:00 when they are at work, but to send them a SMS text message during off hours. Of course you always have the option of leaving subscribers alone during non-business hours as well.

To create a subscriber, right click on the Subscribers container in the console tree and choose the New Subscriber command from the shortcut menu. When you do, the Notification Subscriber Wizard will prompt you to enter a name for the subscriber.

Click Next and you will be taken to the Schedule page. This is where you define the times of the day when the subscriber should be notified and the notification method. If you look at Figure C, you can see that you can base a schedule around a date range, a time of day, and / or a day of the week. You can even define the subscriber’s time zone.


Figure C: Subscribers can receive notifications according to a schedule.

Subscriptions

Once you have defined at least one channel and at least one subscriber, it is time to create a subscription. Subscriptions are really the heart and soul of the notification process because they control the types of information that subscribers receive. In a large enterprise SCOM collects thousands of events every hour related to virtually all aspects of the network. You obviously wouldn’t want to send a notification for every one of these events. If you did then the notifications would become as useless as they would be annoying. Important events would blend in with all of the unimportant events.

That being the case, you should think of a subscription like a type of filter. You can use it to make sure that subscribers are alerted to the most relevant events. Notice the way that I worded that. I said that subscribers should be alerted to the most relevant events, not the most important events. The reason for my wording is that in a large organization different IT staff members handle different parts of the network. For example one administrator might be responsible for the Active Directory while another  is responsible for Exchange Server. There is no rule that says that all notifications have to be sent to all subscribers. Each notification should target the most relevant subscribers.

With that said, you can create a subscription by right clicking on the Subscriptions container and choosing the New Subscription command from the shortcut menu. When you do, SCOM will launch the Notification Subscription Wizard.

The first thing that you must do when you create a new subscription is to provide the wizard with a name for the subscription. There is also a Description field that you can optionally use to document what the subscription is used for,

The next step is to define the criteria for the subscription. You can do this by selecting the check boxes that correspond to the conditions that you want the subscription to watch for. For example, in Figure D the subscription is watching for critical alerts.


Figure D: Subscriptions are based on conditions.

After you finish specifying the criteria for the notification, the next step is to attach one or more subscribers to the subscription. By doing so, you can control who is notified when the specified conditions are detected.

The last step in creating a notification is to add a channel to the subscription. SCOM will use the channel as a route for sending the notification to the subscribers. Specifying a channel is simple, but there is one thing that I want to point out. If you look at Figure E, you will notice that you have the option of sending a notification without delay or of sending the notification only if the condition persists. This is handy because some conditions are harmless if they are brief, but can be serious if they last. For example, it is normal for the CPU to occasionally spike to 100%, but if it stays at 100% for several minutes then you have got a problem.


Figure E: You have the option of delaying notifications.

Conclusion

As you can see, SCOM makes it easy to set up notifications. You can use the basic principles that I have discussed here to configure SCOM to alert you when problems occur with your failover clusters.

If you would like to read the other parts in this article series please go to:

Advertisement

Featured Links