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.

Skip to end of metadata
Go to start of metadata

This topic discusses BMC recommendations to be followed when creating discrete and distributed service models and details about how to set up a model for optimal performance. This topic also provides guidelines on how events must be managed in a multiple BMC ProactiveNet Server environment, so as to gain maximum business value without impacting performance.

Using the recommendations in this topic, you can create a service model in a way that presents a correct picture of your business services and also presents an accurate estimate of optimal performance.

For details about discrete and distributed service models, see the BMC ProactiveNet Service Modeling and Publishing Guide.

For reasons of scalability or modularity, there is a need to distribute different configuration items (CIs) of a service model across various BMC ProactiveNet Servers. However, at the same time, operators must be allowed to view the complete service model and its status from a single view (called the central view).

Recommended hardware and software configurations

To create discrete and distributed service models, BMC recommends the same hardware and software configuration as that required by the BMC ProactiveNet Central Server and BMC ProactiveNet Child Server. For information about the configuration, see BMC ProactiveNet Server installation requirements.

Centralized service models

You can create two types of service models:

  • Discrete service model
  • Distributed service model

Discrete service model

A service model that is present entirely on a single BMC ProactiveNet Server is referred to as a discrete service model. BMC recommends that you deploy discrete service models for optimized performance and scalability. The number of CIs in a discrete service model is limited to the maximum number of CIs supported by BMC ProactiveNet version 9.0. If the number of CIs in a service model is within the limit of a single server, then the service model must be present on a single BMC ProactiveNet Server.

Distributed service model

A service model that is distributed across two or more BMC ProactiveNet Servers is referred to as a distributed service model. When the number of CIs in a service model exceeds the maximum limit of CIs allowed for a single BMC ProactiveNet Server, then you can distribute the service model across multiple BMC ProactiveNet Servers.

When creating a distributed service model, ensure that the relationships do not criss-cross frequently across multiple BMC ProactiveNet Servers (BMC ProactiveNet Cells). Otherwise, the service model might deteriorate the performance of impact computation. For optimal performance of the BMC ProactiveNet Server, a distributed service model must cross the boundaries of impact management (BMC ProactiveNet Server Cell) minimally (ideally, only once or twice).

Note

BMC recommends using discrete service models over distributed service models. Distributed service models must be created only in scenarios where it is not possible to have the complete service model on a single BMC ProactiveNet Server.

Example of a Distributed Service Model:

   Central Server --No Cis

   Child Server1 – vm-w28-rds829 – 4 Cis for Distributed Service model

-          Banking_Service_SSI1

-          Online_Banking_SSI1

-          Online_Server_SSI1

-          Customer_DB_SSI1

   Child Server2 – vw-pun-sms-qa05 – 2 Cis for Distributed Service model

-          Phone_Banking_SSI2

-          IVR_System_SSI2

 

CI class definitions

It is mandatory that the metadata of the BMC ProactiveNet Cell be consistent across all the BMC ProactiveNet Servers. If you are using BMC Atrium CMDB, you can export the class definitions from BMC Atrium CMDB, using the pclassinfo CLI command. Place the BAROC file that contains the class definitions at installationDirectory/pw/server/etc/cellName/kb/classes.

For example, - pclassinfo -x -o mc_sm_object.baroc

For more information about pclassinfo, see the BMC ProactiveNet Command Line Interface Reference Guide.

If the metadata of the BMC ProactiveNet Cell is not the same across all BMC ProactiveNet Servers, it might result in undetermined behavior in the BMC ProactiveNet UI. For example, not all classes may be populated in the search drop-down list, icons may not be displayed for the various CIs, and so on.

Configuring CIs

BMC recommends adhering to the following guidelines when configuring the CI settings:

  • When creating a distributed service model, the BMC ProactiveNet Servers on which the model is to be distributed must contain the cell details of one another in their respective installationDirectory/pw/server/etc/mcell.dir files.
  • Select the settings for the cell alias as shown in the figure below. The CI and its providers must be published to the BMC ProactiveNet Cell whose alias has been selected in Impact Model Designer.
  • When creating a service model using Impact Model Designer, in the Edit Component Properties dialog box, Publish to BMC ProactiveNet Performance Manager area, ensure that you select the Yes and Propagate option for the cell of the top-level CI. Also, set Enterprise=T in the pserver.conf file in BMC ProactiveNet Server. These two settings are mandatory to set up discrete or distributed service models.

For detailed information about these settings, see the BMC ProactiveNet Service Modeling and Publishing Guide.

Recommended setup

This section contains BMC recommendations for setting up the environment to create discrete and distributed service models.

  • No CIs on the BMC ProactiveNet Central Server
    In a multiple server setup that contains one Central Server and one or more BMC ProactiveNet Child Servers, the Central Server must not host any service model.
    BMC does not recommend having an CIs locally on the Central Server. The Central Server has additional responsibilities compared to the Child Server. Therefore, addition of CIs and their monitoring data on the Central Server multiplies the load on that server, thus deteriorating its performance.
  • No event propagation from the Child Server to the Central Server
    Do not propagate events from the Child Server to the Central Server. You can monitor remote CIs or service models from the Central Server. To perform any event related operation, cross-launch to the Child Server and perform the operation on that Child Server. For information about cross-launching, see the BMC ProactiveNet Administrator Guide.
  • Monitor to CI mapping
    Map the CI to the appropriate monitors for association of alarms or abnormalities with the CI. You can do the mapping manually or use the BMC ProactiveNet Administration Console to do the mapping.
  • Event association with CIs
    • If the BMC PATROL Agent or Adapter is collecting data for the CIs, it must send data to the BMC ProactiveNet Server to which the CI is published. This ensures that that the alarms or abnormalities that are generated are associated with the appropriate CIs (assuming that the monitor to CI mapping has been made).
    • In scenarios where third party event sources are sending events directly to the BMC ProactiveNet Server Cell, the event sources must point to the appropriate BMC ProactiveNet Server Cell in which the CIs are created.
  • Do not duplicate CIs across service models
    Do not duplicate CIs across multiple BMC ProactiveNet Servers. CIs that are common to service models residing on different servers, must be shared among the various servers.
    BMC does not recommend the creation of duplicate CIs. If a CI is involved in more than one service model across multiple BMC ProactiveNet Servers, then BMC recommends that you create a distributed service model rather than creating duplicate CIs.
    For example, in the figure below, the Distributed_Database CI is a CI that is a provider to two CIs that reside on different BMC ProactiveNet Servers. The Distributed_Database CI is shared between two Child Servers instead of creating a duplicate of the Distributed_Database CI.
    As far as possible, service models that share a CI must reside together on a single BMC ProactiveNet Server. If the service models are shared across different BMC ProactiveNet Servers, BMC recommends creating a distributed service model instead of creating duplicate CIs across BMC ProactiveNet Servers.
  • No labels