The tool(s) you use to create and edit the service model depend on the products you have installed and integrated with Infrastructure Management.
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.
After you know the computer systems that support the application, you can create a simple service model by:
This produces a simple application service model as depicted in the figure below:
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.
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.
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.
Some other examples of shared infrastructure are databases on a database server, applications on an application server, and VMs on an ESX server.
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.
Some examples of other types of resources that need a cluster CI are Web farms, database clusters, clustered operating systems.