• Spaces
  • Collections
  • Help
    • ×
     
     
    •  
    BMC TrueSight Infrastructure Management 10.0

    Page tree

    Unsupported content

     

    This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

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

    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 the decision and 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 BMC PATROL silent installation packages that have to be created and maintained.

    BMC 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, Central Monitoring Administration 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 Central Monitoring Administration policies that are applied through a staging Integration Service. Monitoring policies are not applied though a staging Integration Service. Additionally, staging Integration Service policies in Central Monitoring Administration are only applied through 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

    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 a 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.)
    • 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 Central Monitoring Administration through the staging Integration Service. Central Monitoring Administration 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 monitoring polices that match each monitoring policy’s agent selection criteria defined in Central Monitoring Administration

    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 Central Monitoring Administration

    A single staging Integration Service and a single Central Monitoring Administration 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 Central Monitoring Administration instance for the entire environment, and eliminates the need to recreate policies in production after they have been created in development and 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 process be managed 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 selection criteria, 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 criteria is not 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 to test, and finally from test to production.

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

    Staging policy configuration for multiple servers with multiple Central Monitoring Administration instances

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

    In a multiple Central Monitoring Administration deployment, 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 Central Monitoring Administration 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. The Integration Service running on an Infrastructure Management Server must also be configured as a staging Integration Service. BMC recommends the following best practices for staging Integration Services and Central Monitoring Administration:

    • Set up a single staging Integration Service for each environment; for example, one for development, one for test, and one for production. Or, if you have a single Central Monitoring Administration instance for all environments, set up a single staging Integration Service for the entire implementation when possible.
    • If firewall rules and security prevent you from using the Integration Service on the Infrastructure Management Server as a staging Integration Service, deploy a staging Integration Service into the managed zone or zones.
    • In large environments, designate at least one Integration Service node separate from the Infrastructure Management Server 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 Central Monitoring Administration 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 Central Monitoring Administration 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. The following are best practices for configuring staging Integration Services:

    • Configure the Integration Service on the Infrastructure Management Server as a staging Integration Service. Do not use it for data collection.
    • Do not attempt to configure agents so that performance data or events are sent to a staging Integration Service.

    Related topics

    Infrastructure Management single-server deployment architecture

    Global thresholds and policy application best practices

    Creating a staging policy

    Adding or editing an Integration Service through Central Monitoring Administration

    Infrastructure Management single-server deployment architecture

    © Copyright 2005-2024 BMC Software, Inc. Use of this site signifies your acceptance of BMC’s Terms of Use . BMC, the BMC logo, and other BMC marks are assets of BMC Software, Inc. These trademarks are registered and may be registered in the U.S. and in other countries.