In your day-to-day management of your MetaFrame XPe environment, Citrix Resource Manager will be one of your most valuable tools. Resource Manager (RM) serves three purposes:
- Real time monitoring of MetaFrame XPe servers.
- Historic reports containing information about MetaFrame XPe servers.
- A central repository of usage information and statistics across all servers in your farm.
Real time monitoring allows you to view the status of different components of the MetaFrame XP server. Each component (known to Resource Manager as a "metric") is viewed via the CMC, and has a green icon next to it if everything is okay. If there are problems, the icon will turn a different color, depending on what the problem is. You can configure the system to send alerts to SNMP traps, email addresses, or short message service pagers if problems occur. You can completely customize the types, behaviors and thresholds of each metric in your environment.
In addition to displaying the live status of MetaFrame XPe servers, Resource Manager can also be used to collect and store detailed data about individual servers. A system snapshot is taken every 15 seconds, and a report can be generated on any timeframe in the past 96 hours, allowing you to see exactly what the condition of the server was at a specific time.
Finally, if you are using Feature Release 2, MetaFrame XPe servers running Resource Manager can periodically send statistics and data to a centralized database. From there you can generate reports about overall farm usage. You can even set up pricing information and generate invoices based on which users accessed the systems.
The newest version of Citrix Resource Manager has evolved quite a bit in the past few years, even since MetaFrame XP was first released. For that reason, this section addresses the Resource Manager component of MetaFrame XPe with Service Pack 2 applied. Since Service Pack 2 is free, you can use it even if you don't plan on using Feature Release 2.
Even though Citrix Resource Manager is fairly straightforward, there are several components required to make it work. These components include:
- Citrix Resource Manager software.
- Farm metric server.
- IMA data store.
- Local resource manager database.
- Summary database.
- Database connection server.
Resource Manager Software. In order to use Resource Manager, you need to ensure that the Resource Manager components are enabled when you install MetaFrame XPe. If not, you can install them at any time by running the SP-2/FR-2 installation program. The Resource Manager software must be locally installed on each MetaFrame XPe server that you want to monitor. This software extends the functionality of the IMA service, allowing it to collect metrics on various server components.
Metrics. A metric is a component (and its associated parameters) that is monitored, including the thresholds for changing the status of the metric and sending alerts. Each metric has an icon that changes colors to indicate its current status. Metrics are configured in the server farm and applied to specific servers or published applications. Examples of the hundreds of metrics available include current user load, CPU utilization, and number of published applications in use.
Farm Metric Server. The Farm Metric Server (FMS) is responsible for monitoring the status of the metrics of all servers and published applications in the entire server farm. This server actually controls the metric icons, changing their status as conditions warrant. The FMS gets its information from the zone data collector, which is updated every 15 seconds by each MetaFrame XPe server.
IMA Data Store. All Resource Manager configuration information is stored in the IMA data store. This includes the metrics and their associated configurations and thresholds, as well as alert parameters and which metrics are applied to which servers and published applications. Just like the other information in the IMA data store, each MetaFrame XPe server's local host cache contains its local subset of the Resource Manager information from the IMA data store.
Local Resource Manager Database. While the Resource Manager configuration information is stored in the IMA data store, each MetaFrame XPe server is responsible for locally maintaining its own Resource Manager data. This data, stored in \Program Files\Citrix\Citrix Resource Manager\LocalDB\RMLocalDatabase.mdb on each server, is maintained for the previous 96 hours, with new data overwriting the oldest data.
Summary Database. In Feature Release 2 environments, the summary database is a SQL or Oracle database that stores long term information about server usage. You can configure this data to be whatever you want, but most people store only a small subset of the local resource manager data in the summary database. The difference is that the summary database is used to store the data for weeks or months.
Database Connection Server. This server is responsible for receiving summary data from all MetaFrame XPe servers and writing it to the summary database. This is the only server that directly connects to the summary database.
Figure 16.2 (next page) shows how the various Resource Manager components work together in the MetaFrame XPe environment.
Figure 16.2: The components of Citrix Resource Manager
Monitoring Servers and Applications
Everything in Resource Manager is monitored via the metrics that you configure. After installation, default server metrics are in place so you can begin monitoring a server immediately without any additional configuration.
How you view the current status of the metrics depends on which type of metric you are interested in viewing. There are essentially two types of metrics: published application metrics and server metrics. Obviously, the published application metrics show information relating to each specific published application. They can be viewed in the published application's area in the CMC (CMC | Published Applications | Your Application | Resource Manager Tab). The server metrics, which contain server-specific status and information, can also be viewed via the CMC (CMC | Servers | Your Server | Resource Manager Tab).
When viewing metrics, each specific metric has an icon whose color corresponds to the state of the metric. Each metric type, both for published applications and servers, has six possible states, as outlined below:
Green. The metric is operating within its acceptable limits as configured in its properties.
Yellow. The metric has exceeded the limits of the green state and switched to yellow, having exceeded the time and value limit threshold you configured.
Red. The metric has exceeded the time and limit thresholds of the yellow state and switched to red. Any configured SNMP, SMS or email alerts have been sent.
Blue. The metric has been added, but it has not yet been configured, so it can't change color. This blue status will not change until you edit the properties of the metric and configure it for use.
Gray (Paused). The metric has entered a "snooze" state, manually invoked by an administrator. During this snooze period the metric will not activate any red alarms, and yellow and red conditions will not cause the metric to appear in the watcher window. However, during this snooze state, the metric is still active and it is still collecting data. The metric will exit the snooze state and become green, yellow, or red, after a preconfigured amount of snooze time has passed, as configured in the metric's properties.
Black (Stopped). The metric has entered a "sleep" state, manually invoked by an administrator. During this sleep period, the metric will not activate any red alarms. Also, yellow or red conditions will not cause the metric to appear in the watcher window. However, during this sleep state, the metric is still active, and it is still collecting data. The metric will not exit the sleep state until it is manually "woken up" by an administrator.
In addition to the colored status indicators of a metric, you can configure the metric options by right-clicking on the metric's name. These options include:
- Snooze. This is where you set the metric to the "snooze" state, silencing any red or yellow conditions. The snooze state is temporary, and the snooze time is configurable in the metric properties. This is thought of as "pausing" a metric.
- Sleep. This is where you set the metric to the "sleep" state. Like the snooze state, the sleep state will silence red or yellow conditions. However, unlike the snooze metric which is temporary, the metric will remain in the sleep state indefinitely until you manually wake it up. This is thought of as "stopping" a metric.
- Real time graph. This option displays a real time graph of the metric's values, updated every 15 seconds. This graph is similar to the graphs available in Performance Monitor. You can also view this graph by double-clicking on a metric in the CMC.
- Properties. This is where you configure the specific behavior of a metric (such as the parameters for going red, yellow, or green). See the "Metric Properties" section of this chapter for more information.
- Add/Remove Metric. This option allows you to add additional metrics to the server to be monitored. There is no limit to the total number of metrics that can be added.
Watching for Critical Metrics
One of the downsides to watching the colored status of metrics for each server in the CMC is that you can only view the status of one server at a time. To address this, MetaFrame XPe includes a "metrics watcher." The metrics watcher is a window that will show all of the yellow or red metrics for the entire farm. If a metric's status becomes yellow or red while the watcher window is open, that metric and its status will appear in the watcher window. If any metric in the watcher windows turns green, or if it is set to snooze or sleep, the metric disappears out of the watch window.
You can access the watcher window in two ways:
- CMC | Resource Manager | Watcher Tab
- CMC | Resource Manager | Click on the "Watcher Window" icon in the toolbar
The watcher window is a small Java window that pops up independently of the CMC (although the CMC must be open in order to use it). Through this window, you can keep an eye on MetaFrame XP servers and published applications while performing other server tasks.
In addition to the watcher window, you can also get an overview of the colors of metrics for all the servers in the farm through the Resource Manager tab (CMC | Servers | Resource Manager Tab). This screen will show the six status icon colors and the number of metrics for each server of each color.
Working with Metrics
After Resource Manager is installed, you need to tell it what you would like to monitor. This is done by configuring the metrics. Each metric is a set of parameters that Resource Manager will watch. Metrics exist at the server farm level. After defining the parameters for a metric, you need to apply the metric to published applications or to servers. There are two types of metrics.
- Server Metrics.
- Application Metrics.
Server Metrics. Server metrics can be created for any object available within Performance Monitor, including any performance monitor object, counter, or instance combination. This is very cool.
Application Metrics. Published applications have only one metric available to them. This metric is the "count," metric-the current number of users connected to a published application.
Each metric has properties and parameters that can be configured for it. By default, these parameters are configured individually per metric, but you can copy configuration parameters from one metric to another.
All of the following parameters apply to both types of metrics. (The "count" metric for published applications and any performance monitor object, counter, and instance for the server metrics.)
The metric's configurable parameters are as follows:
- Yellow Limit. The level that the metric must hit to turn from "green" state to "yellow" state.
- Yellow Time. The time (HH:MM:SS) that the metric must exceed the yellow limit before the metric changes to a "yellow" state.
- Red Limit. The level that the metric must hit to turn from "yellow" state to "red" state.
- Red Time. The time (HH:MM:SS) that the metric must exceed the red limit before the metric changes to a "red" state.
- Incremental. This is a Yes / No option. Checking this box (yes) means that the metric is incremental and that lower is better (i.e. Processor Utilization). Leaving this box unchecked (no) means that the metric is decremental and that higher is better (i.e. Free Disk Space).
- Snooze Time. You can temporarily silence a red alarm by hitting a "snooze" button. This snooze time property configures the time (HH:MM:SS) that the metric remains in the snooze state before returning to an active color and state.
- Summary Data. When this box is checked, this metric will be included in the server farm's permanent summary database.
- Email, SNMP, or SMS on Red. This checkbox will cause the metric to send an alert when it enters the "red" state. The recipients of the alerts must be configured in the farm or on the server in order for these alerts work.
- Email, SNMP, or SMS on Green. This checkbox will cause the metric to send an alert when it enters the "green" state, from a yellow or red state. The recipients of the alerts must be configured in the farm or on the server in order for these alerts work.
- Script on Red. You can specify a script or program that is executed when the metric enters the "red" state. This script runs with the local system account privileges, and it runs every time the status changes to red. This script must be located on the local server. If this metric is copied and applied to multiple servers, the script must be in the same location on all of the servers.
After a metric has been added to the server you can enter metric values by viewing a real-time graph that displays the counter of the value of the metric that you are setting (CMC | Metric Properties | Advanced Threshold Configuration button).
Once you configure a metric the way you want it, you can copy it to other servers or applications. Remember that if you copy a metric that is configured to execute a script when its status changes to red, you must also manually copy the script to the same location on every server where that metric is applied.
Resource Manager "alerts" is the generic term applied to the external notification process that can occur when a metric's status changes to red or to green. These alerts can be in the form of an email, and SNMP trap, or a Short Message Service alert (such as an alphanumeric pager). The alerts are configured as part of the metric's properties as described previously.
An important aspect of alerts relates to how you configure the recipients of an alert. When you are configuring the metric, the only alert options you have are checkboxes that allow you to turn the different types of alerts on or off. So how do you specify the recipients of an alert if you turn it on?
There are two ways, depending on the scope of the alerts. You can configure alert recipients per farm or per server. Both types of recipients are configured via the CMC. If you configure alerts for the server farm (CMC | Resource Manager | SMS, SNMP, or E-mail tab), any time a metric needs to send an alert, the alert will be sent to the list of recipients configured for that type of alert for the server farm.
In addition to the farm-wide alert recipients, you can configure alerts that replace or are an addition to farm-wide alert recipients (CMC | Right click on server | Server Properties | Resource Manager Alerts Recipients tab). If you uncheck one of the alert recipient methods (either the SNMP, SMS, or Email) and leave the boxes blank, no alerts of that type will be sent for that server.
Any manual customization of the alert recipients that you configure for one server must be manually reproduced on other servers if you want them to have the same configuration. There is no way to copy the recipient properties from one server to the next.
Adding Metrics to be Monitored
Adding new metrics is fairly sinple (CMC | Server | Resource Manager tab). As you add a metric, its status light will remain blue until you configure it.
When you add a metric (which is based on Performance Monitor counters), you have the option of adding all instances of a particular counter. If you do this, Resource Manager will add each and every instance of that counter, not an aggregate. If you need an aggregate, most performance counter objects have specific instances that represent the total of all instances.
For example, the "% Processor Utilization" counter of the Processor performance monitor object has one instance for each processor, named 0, 1, 2, or 3. Additionally, there is an instance named "_Total" that is the aggregate of all the instances. If you want to create a Resource Manager metric for the aggregate, create a single metric that tracks the "_Total" instance, rather than separate metrics for each instance.
Real World Settings for Server Metrics
After Resource Manager installation, default server metrics are automatically created and configured. Before you configure the red alerts to be sent to your pager, it's probably a good idea to take a look at the default parameters and to see how accurately they fit your server. If you don't do this, you will probably have a conversation that goes something like this:
Your Pager: <beep beep beep>
You: I see that Server A has gone red.
Other Citrix Administrator: Really?
You: Yeah, the context switches have hit 14,000 per second.
Other Citrix Administrator: Really?
You: Yeah, they've been that way for over two minutes now.
Other Citrix Administrator: Really?
You: Yeah, really.
Other Citrix Administrator: Is that bad?
Other Citrix Administrator: ?
You: It's red.
Other Citrix Administrator: So that's bad?
The point of this dialog is that the default metric configurations are rather generic, so it's important that you configure them in a meaningful way for your servers and your situation before you set the system to start bothering people at home via their pagers.
Monitor some of the metrics in real time with various loads on the servers to establish baseline settings. These settings will to evolve over time. As you become more aware of your servers, you'll get a feel for what "looks right" and what you need to set your metrics for.
When configuring your metrics, remember that the only metric available for individual applications is the count of the current users. All of the other performance monitor metrics must be applied to a server, not an application.
You should also keep in mind that you can use Resource Manager to monitor folders of applications or servers together as a single unit, in case you have any parameters that you need to monitor across groups.
Metrics' Impact to Servers
The local IMA service processes and records data for the Resource Manager metrics. If you decide to create a lot of metrics on one single server, keep an eye on the IMAServe.exe in the task manager to make sure that it is not using too much memory or CPU time. Don't go overboard with the number of metrics you configure on one server because the IMA service must record the data for every single one.
Viewing Historic Metric States and Values
You can use Resource Manager to view the states and values of metrics from any time in the last 96 hours. This is useful if a server starts performing poorly because you can step backwards in time to see exactly what happened when the performance became poor.
You can use the CMC to view a log that indicates the date and time that the status of any metric changed (CMC | Right click on server | Resource Manager Server Log). You can also view a historic graph for each metric that shows the real time value and the recent history.
You can use the CMC to generate a system snapshot that will indicate the values of any of the metrics for a specific time in the last 96 hours (CMC | Resource Manager | Reports Tab). System snapshots are automatically generated every 15 seconds, so that at any given time you will be able to look at server status in 15 second intervals for the past 96 hours.
Lastly, you can run a process report that will show all the details of all processes, except for system related processes, the system account, and the Resource Manager tools themselves. If you like, you can configure additional processes to be ignored (CMC | right click on server | properties | ignored processes tab). You can even use the "Apply to other Servers…" button to copy the list to other servers in your farm.
How Resource Manager Works
Now that you understand the components of Resource Manager and how it is used, we should look at some of the behind-the-scenes technical components that make it all come together. These components include:
- The farm metric server.
- The local Resource Manager database.
- The summary database.
- The database connection server.
The Farm Metric Server
Every server farm that has at least one server that uses Resource Manager has a farm metric server. The farm metric server is responsible for interpreting the metrics, monitoring them, and sending the alerts. It provides the backend data that shows each metric's status in the CMC or the watcher windows.
By default, the farm metric server will be the first server that you installed Resource Manager on. However, as an administrator, you can specify which server is your Farm Metric Server. (CMC | Resource Manager | Farm Metric Server Tab) When you are choosing this server, you will be able to get a bit of a performance gain if you choose a zone data collector.
In addition to the farm metric server, each farm also has a backup farm metric server. If the farm metric server does not respond to a request, the backup server becomes the farm metric server. If the main farm metric server comes back online, it becomes the backup farm metric server.
Local Resource Manager Database
After you install Resource Manager, a Jet (MS Access) database is created on the local MetaFrame XP server in the following location: Program Files\Citrix\Citrix Resource Manager\LocalDB\ RMLocalDatabase.mdb. An ODBC DSN called RMLocalDatabase is also created that points to this local database.
As the server is used, Resource Manager writes performance information to the local database every 15 seconds. After 96 hours, the old information is continuously overwritten by the new information, meaning that at any given time, you will always have a record of the last 96 hours.
When you use the CMC to produce a Resource Manager report for a MetaFrame XPe server, the IMA service on that server reads the information needed for the report from its local Resource Manager database. It then sends that information to the server running the CMC. The only time any performance data is read or sent across the network is when a report or a graph is generated.
Resource Manager only saves information in the local database for the metrics that are configured for a server. Each entry only requires a few hundred bytes, which means that the 96 hour history of 15-second intervals requires about 7MB for each metric.
In addition to the server-based metrics, an entry is written to the local database whenever a published application is launched. This entry is updated every 20 seconds so long as the application is in use. This happens for all published applications, not just ones that have the "count" application metric applied. However, for applications that do have the "count" application metric applied, the farm metric server is also updated every 20 seconds so that it constantly knows how many instances of the application are running in the farm.
If you're using Feature Release 2, you can create a "summary database" that aggregates and stores (long-term) certain Resource Manager data from multiple servers in your farm. You can configure different types of data to be retained for different amounts of time (or even indefinitely) via the CMC (CMC | Resource Manager | Summary Database tab | Configure | Purge Settings).
Once the data is in the database, you can run reports against it via the CMC (CMC | Resource Manager | Reports tab). or with any tool that you choose (such as Crystal Reports). If you choose to use Crystal Reports, there are free Citrix-specific templates that you can download from www.citrix.com/download. (Click the "MetaFrame XPe" link.)
Database Connection Server
The database connection server (DCN) is the single MetaFrame XP server in your farm responsible for receiving summary data from farm servers and writing it to the database.
Each MetaFrame XP server stores its data for the summary database locally in a summary file. This file is updated whenever any user session ends, a process ends, or an event occurs. It is also updated once an hour with new metric data. After 24 hours, this data is sent to the DCN which adds it to the database.
You can configure the time of day that the summary data is sent (CMC | Resource Manager | Summary Database tab | Configure button). Unfortunately, the update time is not time-zone specific. For example, if you set your update time for "23:00" (11:00 PM), each server will send its updated information when its own clock reaches 11:00 PM.
In order to setup your DCN, you need to create a system DSN called "rmsummarydatabase." You can point this DSN to an Oracle or SQL database. Then, use the CMC to configure the farm to use this DSN (CMC | Resource Manager | Summary Database tab | Configure button).
It's important to note that the farm metric server and the database connection server are not the same thing, although you could run them both on the same server if you wanted to.
Using Resource Manager in the Real World
Citrix Resource Manager is useful in many situations. However, you should keep the following tips in mind when you decide how it will be used in your environment:
- Remember that Resource Manager is a "farm-wide" resource. For example, there is only one database connection server and one farm metric server per server farm. If you have a server farm that spans multiple WAN locations, you must consider the bandwidth that will be consumed by Resource Manager.
- The act of collecting metrics consumes server resources. In the real world, you should only choose to collect server metrics that are actually useful to you.
- Resource Manager works best when it monitors high-level usage information. It's not really designed to be used as an in-depth troubleshooting or server sizing tool.