1.6 Developing a Management Site and Site Policies

As discussed in the Installation Guide for AppManager, available on the AppManager Documentation page, a key element successfully deploying AppManager is understanding the characteristics of your environment and the network you are going to monitor. Although you typically deploy and refine agents, jobs, and event- and data-handling policies over time, one of the first issues you must confront is how to configure the core AppManager components to best suit the current environment and anticipated changes.

To determine whether you need one management site with a single management server, one management site with multiple management servers, or multiple management sites with multiple QDBs and multiple management servers, consider several factors:

The network bandwidth, latency, and topology for the subnets you will be monitoring
The departmental or functional structure of the organization and the expectations and level of autonomy associated with different groups in the organization
The granularity of management that will best suit the organization

To help you determine how to configure one or more management sites to suit your environment, consider the most common deployment scenarios and evaluate how the specific characteristics of your organization might fit these scenarios. Keep in mind that these scenarios are only a few common examples of the many possible ways you can deploy and organize your site.

1.6.1 Managing a Small, Internal Network

In smaller organizations, it is common to monitor a networked domain or a simple trusted set of domains. An organization like this might be primarily interested in monitoring key application and file and print servers for internal users and a few key business critical services. For example, this organization might focus on basic monitoring of CPU, memory, and disk space for all servers and workstations and specific performance statistics, such as response time and system availability, for important services such as the messaging system and a customer database.

In a small environment like this, with relatively simple monitoring needs for 150 or so servers, a typical site configuration involves one QDB and one management server, installed together on the same computer. An environment like this might have a small administrative staff and need to deploy the core AppManager components on a single computer to simplify maintenance and console viewing. Also, as the focus is on basic performance and availability, the organization can expect fewer events and likely only requires a few charts or reports to show status or trends, and therefore will only collect a few key data streams.

Having the QDB and management server installed together on the same computer has the following advantages:

Eliminates network communication problems between the QDB, management server, and Control Center console
Eliminates the need for any special account permissions associated with accessing another computer over the network or through a firewall
Simplifies maintenance and troubleshooting because components are centrally located
Reduces the importance of developing carefully considered security-, data-, event-, and job-handling policies, database management and backup plans, and monitoring strategies

The diagram below illustrates this type of site configuration:

For small organizations or pilot deployments, these benefits can outweigh the disadvantage of burdening a single computer with the management server’s communication load and the QDB’s storage and communication requirements.

1.6.2 Managing a Mid-size Network with Local and Remote Facilities

A small- to mid-size organization might contain from 151 to 600 servers and involve monitoring a local network and remote facilities. As the number of servers increases, this organization might put strain on the management server, generate more frequent events, need more sophisticated reports, and need to collect and save more data, all of which require more database resources and more database management. In addition, a small- to mid-size organization might have a larger administrative staff and need multiple Control Center consoles.

For this environment, NetIQ Corporation recommends installing the QDB and management server on separate computers. In addition, because the organization is monitoring some computers remotely, you need to evaluate the reliability and bandwidth of the WAN connection and possibly plan for scheduled communication links between the remote computers and the management server.

Having the QDB and management server installed on different computers offers the following advantages:

Eases the workload on the QDB and management server computers by distributing the workload to two separate computers
Reduces system requirements for the computers where the components are installed and provides additional space for database growth
Provides more flexibility in configuring how and when agent computers communicate with the management server

This configuration is still relatively straightforward and easy to maintain. The following diagram illustrates this type of site configuration:

No inherent drawbacks are associated with this configuration for a small or mid-size organization, or even for larger organizations with basic monitoring needs. However, over time you might place stress on this environment if you:

Add a large number of servers.
Dramatically increase the monitoring you do or the data you collect.
Add widely distributed facilities to the management site.
Start to experience network bandwidth, latency, topology, or reliability issues.

If your organization is considering this type of configuration, consider the following potential site administration improvements:

More planning and testing to optimize communication channels, particularly for monitoring remote computers
Evaluating security and port requirements more carefully, particularly if the management server is inside a firewall and some number of monitored computers are outside a firewall (which is a common configuration if you are monitoring more than the organization’s internal network)
If your organization has a larger administrative staff or more console computers, more planning for AppManager security roles and profiles to restrict access to some views and activities
Setting up special domain accounts or trust relationships for certain types of monitoring and to allow remote installation of the AppManager agent

1.6.3 Monitoring Large Environments with Multiple Management Servers

For organizations that need to monitor more than 600 servers, including remote facilities, it is often helpful to install additional management servers to distribute the communication workload. Using two or more management servers in a management site provides the following advantages:

Reduces the chances of the management server becoming a bottleneck for event and data handling
Provides you with a way to balance the communication load between the management servers to ensure optimum efficiency for your specific network configuration
Allows you to establish a primary management server and a secondary management server for each of your agent computers to provide failover support
Provides better scalability for organizations that need to grow quickly or are expanding their monitoring requirements

Using more than one management server allows more control and flexibility in managing site communication but it requires far more planning to implement effectively. For example, you must decide if a second management server is strictly a backup for a primary management server or if each management server is responsible for a specific set of agent computers.

You must also decide how many management servers you can reasonably manage within a single site. Although there is no specific restriction on the number of management servers you can use, most organizations can handle four management servers before the site becomes too complex to manage.

The following diagram represents a simple two-management server site configuration:

Each management server has been designated as a primary management server for several agent computers.

All of the agent computers that send information to the management server ONYX are also configured to use the management server ENCORE as their secondary, or backup, management server. In this scenario, the computer ENCORE is a powerful, high-speed computer that can handle the extra load from the agent computers that the computer ONYX typically manages. If communication with ONYX is interrupted, its agent computers automatically begin communicating with their secondary management server, ENCORE.

You could also designate ONYX as a secondary management server for the computers managed by the computer ENCORE, so that both computers have a secondary management server, or you could designate a separate management server that does not have any agent computers to be a secondary management server. In this second scenario, the secondary management server is normally “idle” and only takes over the communication with agent computers when either of the primary management servers fails. If you decide to configure a primary management server as a secondary for another management server, it is good practice to configure this management server so that it can accommodate its own agents plus the full complement of agents from the management server it is backing up.

As this example illustrates, installing multiple management servers provides flexibility but can increase the complexity of site management and requires planning.

1.6.4 Monitoring a Widely Distributed Enterprise

A single management site with one QDB and a small number of management servers is sufficient to meet the monitoring needs of most organizations. For large-scale, distributed networks, however, a single site might not be possible, manageable, or desirable. For an enterprise with computer resources widely distributed across a national or international network, multiple management sites might be the most practical solution.

Because so many key elements of a monitoring strategy and communication control are defined at a site level, keeping multiple QDBs synchronized can be difficult. For example, you can establish consistent monitoring policies for all of the computers in your network. With AppManager Control Center, you define these policies once, and they are automatically replicated to each management site. In addition, Control Center lets you assign permissions so that each administrative team manages its own site.

In a decentralized environment with multiple administrative teams that operate independently, consistency across multiple QDBs might not present an issue. If your organization is decentralized or requires only minimal standardization (for example, by establishing a common set of reports for all sites to use but letting each site define its own event-handling policies), multiple management sites might best suit your needs.

The following diagram illustrates this type of site configuration:

1.6.5 Defining a Management Site

You define the configuration of an AppManager management site when you install AppManager components. You start by creating the QDB, then install the management server and identify the QDB to which the management server connects, and install the Task Scheduler service and add QDBs and the CCDB to the service.

After you install the core components, you install AppManager agents on the computers you want to monitor and specify the management server with which each agent computer can communicate. After you install and discover agents, you can use the UNIX Agent Manager or the AMAdmin_SetPrimaryMS and AMAdminUNIX_SetPrimaryMS Knowledge Scripts to set or change the primary and secondary management server for each agent computer.

1.6.6 Planning and Staging a Deployment

In general, the more planning you do before deploying AppManager in a production environment, the more successful your implementation will be, particularly if your organization is very large with complex network and security issues. In practice, most of the characteristics of your installation can be modified after installation, so many organizations deploy a basic monitoring environment and refine policies and procedures over time. For suggestions about how to stage a deployment of AppManager components over time, see the Installation Guide for AppManager, available on the AppManager Documentation page.

1.6.7 Defining Site-Level Policies

In addition to decisions about the basic configuration of your AppManager management site, you will need to make other policy decisions, from defining security roles for AppManager users to establishing a database management and backup strategy. The remainder of this guide focuses on the key issues that you typically need to address.

Some topics, such as setting up security roles and identifying AppManager users, apply for all environments, regardless of size. Other topics, such as adjusting the flow of data from agent computers to the management server, only apply to organizations that need to control and customize the communication to suit their network topology or bandwidth constraints.