Staging Integration Service host deployment and policy management for development, test, and production best practices

The staging Integration Service provides a single point in the environment where all newly deployed PATROL Agents can register into the solution stack. The following topics describe how the staging Integration Service functions and best practices for deployment and configuration of a staging Integration Service.

Defining a staging policy

Managing Integration Services

Infrastructure Management single-server deployment architecture

Staging Integration Service functions

A staging Integration Service supports a smoother process for deploying PATROL Agents into Infrastructure Management environments in three major ways:

It eliminates the need to manage thedecisionand assignment of PATROL Agents to production Integration Services that are separate from the deployment process. (This assumes an environment that includes multiple production Integration Service instances.) When you leverage a staging Integration Service, this decision and the assignment are automated as part of the deployment process.
It supports a smoother process for managing policies across development, QA, test, and production environments.
It reduces the number of PATROL silent installation packages that have to be created and maintained.

PATROL Agent silent installation packages are created so that the staging Integration Service is defined in the package. No other Integration Service is defined in the installation packages. Although technically possible, BMC recommends as a best practice that other Integration Service instances not be defined in the installation packages. When a package is deployed and installed, the PATROL Agent checks in through the staging Integration Service. When the PATROL Agent checks in, the Presentation Server evaluates the agent selection criteria in a staging policy and uses that data to automatically assign a data collection Integration Service (or Integration Service cluster) to the PATROL Agent. The agent selection criteria can include any one or a combination of the following:

Tag defined in the agent configuration
Host name that the agent is running on
Operating System that the agent is running on
IP address or IP address range that the agent is running on
Agent port
Agent version
Integration Service that the agent is already assigned to (assuming it is already assigned)
Infrastructure Management Server that the agent is already assigned to (in this case it is through a staging Integration Service)

Integration Service policies are the only Infrastructure Management policies that are applied through a staging Integration Service. Monitoring policies are not applied through a staging Integration Service. Additionally, staging Integration Service policies are only appliedthrough a staging Integration Service instance.

The architecture of network connections (communication protocol, ports, and so on) among the staging Integration Service, PATROL Agents, and the Infrastructure Management Server is technically the same as with other Integration Service instances.

Staging process for PATROL Agents

The diagrams in the following steps illustrate the process of utilizing a staging Integration Service:

Step 1 - Initial agent deployment
Step 2 - Applying the Integration Service policy
Step 3 - Production monitoring

Step 1 - Initial agent deployment

The following diagram illustrates three different Integration Service nodes and how they are used:

Roles of the Integration Services

The purpose of each Integration Service is as follows:

The staging Integration Service is used strictly for introducing new agents to the Infrastructure Management Server. (An Integration Service has to be configured to work as a staging Integration Service.)
Note

The Integration Service running on an Infrastructure Management Server cannot be configured as a staging Integration Service.
The general Integration Service is used to collect data from various PATROL Agent deployments that are installed locally on the managed nodes. The term “general” is a description of how the Integration Service is used and does not denote a configuration.
The domain Integration Service is used to collect data from PATROL Agents that provide large volumes of data from a single source; for example, VMware vCenter, PATROL Remote Operating System Monitoring, NetApp, and so on. The term domain is a description of how the Integration Service is used and does not denote a configuration.

How does the PATROL Agent introduction process work?

A newly deployed PATROL Agent silent installation package is installed as shown in the preceding diagram. The installation package for the PATROL Agent contains configuration data that informs PATROL Agent on how to connect to the staging Integration Service. When the new Agent starts for the first time, it registers with the Presentation Server through the staging Integration Service. Presentation Server then applies a staging policy to the agent based on agent selection criteria in the policy. Agent selection criteria define the agents that the policy must be applied to. The staging policy only contains agent selection criteria and information that defines connectivity for a data collection Integration Service node (or Integration Service cluster). No other agent or KM configuration data can be defined in a staging policy.

Step 2 - Applying the Integration Service policy

After receiving the staging policy, the newly deployed PATROL Agent switches to the data collection Integration Service node (or Integration Service cluster) defined in the staging policy. (The switch is represented by the blue arrow in the diagram.) The agent then receives monitoringpolicesthat match each monitoring policy’s agent selection criteria.

Step 3 - Production monitoring

The PATROL Agent starts monitoring and continues to receive any updates to existing monitoring policies and new monitoring policies that match the monitoring policy’s agent selection criteria.

Note

Agents do not move from development to test, and then to production. All agents must first check in with the appropriate staging Integration Service, and then move to their data collection Integration Service. This supports the concept of creating installation packages for development and test only, separate from production.

Staging policy configuration for multiple servers with a single Presentation Server

A single staging Integration Service and a single Presentation Server instance can be used to support multiple Infrastructure Management Servers. The following diagram illustrates how this is designed for Infrastructure Management development, test, production environments.

Multiple Infrastructure Management Server deployment with a staging Integration Service host

All policies include agent selection criteria that allow you to completely control the policies that are applied to any and all PATROL Agents across the entire environment spanning development, test, and production. This allows you to install a single Presentation Server instance for the entireenvironment,and eliminates the need to recreate policies in production after they have been created indevelopmentand tested.

Staging policy configuration to support development, test, and production

You define and edit one or more of the following agent assignment configurations in a policy so it can support multiple Infrastructure Management Servers:

Infrastructure Management Server that the agent is assigned to (this is a best practice)
Integration Service that the agent is assigned to
A “tag” defined in the agent configuration
Host name that the agent is running on
IP address that the agent is running on

The easiest method is to include the appropriate Infrastructure Management Servers in the agent selection criteria at the proper time for the policy as shown in the following figure:

Simply add the test and production Infrastructure Management Servers to the policy agent selection criteria when you are ready to apply the policy to those environments. This simplifies the process of moving configuration from QA to test, and finally to production. It also ensures that a policy is not applied to any agents in production until it has been tested and validated.

Example policy configuration for development, test, and production

The following outlines the process shown in the preceding illustration.

Part 1 – Only the Infrastructure Management Server named “BPPMRHEL62-HM-QA” is included in the agent selection criteria when the policy is first created.

Part 2 – The Infrastructure Management Server named “BPPMRHEL62-HM-TEST” is added to the agent selection criteria with an OR after the policy has been validated in the QA environment.

Part 3 – The Infrastructure Management Server named “BPPMRHEL62-HM-PROD” is added to the agent selection criteria with an OR after the policy has been tested and validated in the BPPMRHEL62-HM-TEST environment and is ready to be applied in the production environment.

Warnings

It is extremely important that this processbemanaged carefully. Utilizing Infrastructure Management Servers in the agent selection criteria is powerful and has far reaching, global implications. If you add a production Infrastructure Management Server to the agent selection criteria for a policy by mistake, the policy might be unintentionally applied to hundreds or thousands of agents in production.
At least one Infrastructure Management Server must be included in the agent selection criteria to enable you to control to which Infrastructure Management environments the policy is applied. If you do not include at least one Infrastructure Management Server, the policy is applied to all agents, across all Infrastructure Management Servers that match the agent selection criteria of the policy. Additionally, multiple Infrastructure Management Server values must be grouped () and related with a boolean “OR” as in the preceding screen shot. If you use a boolean “AND” to relate the agent selection criterion, the policy is not applied because an agent cannot register with multiple Infrastructure Management Servers.

Important

The policy’s agent selection criteria updates and deletes existing policies on all PATROL Agents that match the criteria. Consequently, it is not possible to test policy edits that currently apply to production without impacting production using the process outlined in the example. Separate policies must be created to test edits in the development and test environments by using the export/import utility.

Leveraging tags and precedence in policies

Policy tags can be used to further control to which PATROL Agents policies are applied. Tags must be used to provide a second level of protection to prevent policies still in development or test from being applied to production accidentally. Leveraging tags this requires you to not only add the appropriate Infrastructure Management Server to the policy selectioncriteria,but also add the appropriate tag. This helps prevent accidentally picking the production Infrastructure Management Server and saving the policy. Additionally, tags can be used to provide greater granularity for policy assignment when the other agent selection criteriaisnot enough.

BMC recommends leveraging precedence in policies so that production policies have the highest precedence and are not superseded by development or test policies. If you follow this recommendation, you will also have to adjust the policy precedence when you want to move it from development totest,and finally from test to production.

For information about PATROL Agent tagging methods, see Creating and editing component installation packages .

Staging policy configuration for multiple servers with multiple Presentation Server instances

You must use the policy export/import utility to move policies between environments that have multiple Presentation Server instances. The following diagram illustrates how this is designed in the Infrastructure Management Server development, test, and production environments.

In a multiple Presentation Serverdeployment, you do not have to specify Infrastructure Management Servers in the agent selection criteria in the development and test environments. This is not needed because the environments are completely separated and do not share a common Presentation Server instance with the production environment.

Best practices for deploying the Integration Service with respect to staging and policy management

Integration Service nodes can be connected to any Infrastructure Management Server across the environment.

BMC recommends the following best practices for staging Integration Services and Presentation Servers:

Set up a single staging Integration Service for each environment; for example, one for development, one fortest, and one for production. Or, if you have a single Presentation Server instance for all environments, set up a single staging Integration Service for the entire implementation when possible.
In large environments, designate at least one remote Integration Service node as a staging Integration service node.
Set up high availability for staging Integration Service nodes. This is especially important in environments where deployment of managed nodes and PATROL Agents is rapid and often; for example, in a cloud services provider environment. Setting up high availability for the staging Integration Services ensures limited or no disruption of the monitoring deployment process.
Limit the number of staging Integration Service nodes deployed in each environment. Limit this number to one or a single high availability pair per environment if possible. This reduces the number of components that must be maintained. It also eases administration and assignment of monitoring policies across each environment.
Limit Presentation Server to one instance in one Infrastructure Management Server (Infrastructure Management Server cluster) for each environment where development, QA, test, and production are each separate environments. This helps control the application of policies within the different environments. You can facilitate this by using the export/import capability of policy content and by assigning the appropriate Infrastructure Management Server to the agent selection criteria.
Do not move agents from development to test and then to the production environment. Only configuration policies must be moved among environments.

Best practices for configuring and using staging Integration Services

Staging Integration Services must not be mixed with data collection Integration Services; they must be configured, used, and managed separately. Do not attempt to configure Agents so that performance data or events are sent to a staging Integration Service.