• 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.

    This section presents the simplest approach to service modeling. You can use simple service models as a starting point to build more granular or complex service models.

    Before you start modeling

    Before you start creating an impact service model, you must find out which components support the entity you are going to model. This section describes modeling a simple application. Therefore, before starting to create the model, you need to know which computer systems provide the infrastructure that supports the application.

    The computer systems must be defined in the Infrastructure Management Server by either adding them as devices in the administrator console or by publishing them from BMC Atrium CMDB.

    In addition to the computer systems, you must also identify the application infrastructure (such as application servers, databases, Web servers, clusters, and so on) running on the computer systems that support your application.

    BMC recommends that you design your impact service models using a tool such as Microsoft Visio, or even on paper, before actually creating them in Infrastructure Management or BMC Atrium CMDB. BMC also recommends that you use BMC Atrium CMDB along with BMC Atrium Discovery and Dependency Mapping or another discovery tool to create and maintain your impact service models.

    You can create and maintain service models using standalone Infrastructure Management; however, manually maintained models can quickly get out of control. Service models created directly in Infrastructure Management are good for a proof of concept.

    Learning resources for service modeling

    Impact Management and service models

    Use cases for centralized service models

    Using the administrator console for service viewing and managing

    Where to edit the model

    The tool(s) you use to create and edit the service model depend on the products you have installed and integrated with Infrastructure Management.

    Integrated products

    Tools to use

    BMC Atrium CMDB with BMC Atrium Discovery and Dependency Mapping

    Use BMC Atrium Discovery and Dependency Mapping to discover the infrastructure components and their relationships. Use Impact Model Designer in Atrium Core Console to refine the submodels and relate them to the higher-level configuration items (CIs).

    BMC Atrium CMDB

    Use Impact Model Designer to create and maintain the service models.

    Standalone Infrastructure Management

    Use the Services Editor in the administrator console.

    BMC recommends that you use BMC Atrium CMDB along with a discovery tool such as BMC Atrium Discovery and Dependency Mapping unless you have a relatively low number of models to create and maintain.

    You can also import service models from other sources, but this requires customized processes that are outside the scope of this documentation.

    Creating a simple model

    After you know the computer systems that support the application, you can create a simple service model by:

    1. Using the the Administrator Console to create an application CI
    2. Creating impact relationships from each of the supporting computer system CIs to the newly created application CI

    This produces a simple application service model as depicted in the figure below: 

    Tip:

    You can also create an equivalent service model in BMC Atrium CMDB using Impact Model Designer. For more information about using Impact Model Designer, see BMC Impact Model Designer user interface.

    Dealing with shared infrastructure

    The model above may suffice in many situations, but you might have infrastructure that is shared between multiple applications with only a portion of the infrastructure supporting each application. In this case, you need to create CIs that represent the portions of the infrastructure that support each application. The new level of CI must be inserted in the model between the underlying infrastructure and the supported higher-level CI.

    Note:

    Only insert CIs for those portions of the infrastructure that are being monitored or for which events are being generated. See the Associate monitors with CIs through the administrator console section for more information.

    For example, if the file server in the service model above provided multiple file systems, but only one of them supported that application (with other file systems supporting other applications), then you create a set of file system CIs for the file systems that support the various applications and replace the relationship between the file server and the application with relationships between the file server and the appropriate file system and between the file system and the application. In this case, your service model will look like the figure below.

    Tip:

    Some other examples of shared infrastructure are databases on a database server, applications on an application server, and VMs on an ESX server.

    Dealing with clustered infrastructure resources

    Like you deal with shared infrastructure, you may have to deal with infrastructure resources that are clustered. When dealing with clustered resources, you may not want to show the higher-level application CI being directly impacted by only one instance of a group of clustered resources having a problem. In this case, you need to create a cluster CI representing the group of clustered resources and set the computation model so that the cluster state is set by a quorum of the members of the cluster.

    For example, if the Red Hat Enterprise Linux servers in the model above supported a clustered application server, then you would create a cluster CI for the application server cluster, set its computation model to "Cluster", and replace the relationships between the Red Hat servers and the application with relationships between the Red Hat servers and the new cluster CI and between the cluster CI and the application. The figure below represents this service model.

    Tip:

    Some examples of other types of resources that need a cluster CI are Web farms, database clusters, clustered operating systems.

    Where to go next

    Defining service models

    Related topics

    Building a service model

    © Copyright 2005-2023 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.