Service Attributes and Relationships

When creating a service, specify a number of attributes and associate the service to its resources and other service management models. This section explains the attributes that can be configured and the potential relationships that you can create for each service model.
When creating a service, specify a number of attributes and associate the service to its resources and other service management models. This section explains the attributes that can be configured and the potential relationships that you can create for each service model.
  • Name and Description
    The service name and description identify the service model. You can define multiple services with the same name, provided they have unique descriptions.
    You do not have rules for defining service names. However, you are recommended to use some naming scheme or convention that lets you identify a service model, if you encounter it outside of the service management hierarchy. Some naming schemes include multiple parts that let you categorize the service geographically or organizationally. Other naming schemes associate the service to a particular customer or function.
    It is a useful practice to state the service role in the service description. The service role is determined in the planning phase, and states the capability and purpose of the service model.
  • Criticality
    Service criticality is an enumerated value ranging from a Low value of 10 to a High value of 30. All or a portion of a services criticality can be added to the Impact value of any resource alarms effecting the service.
    If a service is down, the entire value is factored into the calculation. If a service is degraded as a result of the resource alarm, one half of the service criticality value is factored into the impact calculation for the alarm. If a service is slightly degraded, one fifth of the value is factored into the calculation.
    Verify the following Criticality values:
    • Low (default) = 10
    • Medium Low = 15
    • Medium = 20
    • Medium High = 25
    • High = 30
    For example, a Degraded High criticality service has an impact of (50percent) * 30 = 15, and a Down Low criticality service has an impact of (100percent) * 10 = 10. The alarm that caused the Degraded High criticality service has a comparatively greater impact than the alarm the caused the Down Low criticality service. If alarms are sorted and prioritized by impact value, the alarms impacting the most critical services are given the highest priority.
  • Landscape
    The landscape field specifies the landscape where the service model resides. The landscape option appears only when multiple SpectroSERVERs are deployed in a distributed environment.
    To optimize performance, the service can be created on the landscape where all or most of its resources reside. If the service has resources spanning multiple landscapes review Service Models in a DSS environment.
  • Security String
    The security string secures access to the service model in CA Spectrum. For more information, see the OneClick Administration section
    Security in the service dashboard differs from the OneClick Console. If a user does not have access to a service model, all icons and list entries for that service are absent from the service dashboard. This dashboard differs from the OneClick console where icons are exposed, but no model data is available.
  • Maintenance Mode
    Service models support maintenance mode as do many other models in CA Spectrum. When a service is "in maintenance", it is not actively monitoring any of it resources.
    You can create a service in maintenance to avoid the generation of any service outages while you are still building your service hierarchy and identifying resources. In this capacity maintenance, model is used to show that the service is under construction.
    Service models also support scheduled maintenance. Schedule maintenance defines preconfigured periods of time where the service stops actively monitoring its resources. Commonly service level agreements specify periods of time which are reserved for service maintenance.
  • Generate Service Alarms
    Each service can be configured to generate alarms which correspond to changes in service health.
    Disabling the generation of alarms for the service means that an alarm cannot be generated, the service health is still modified based on policy evaluation. All icons within the OneClick Console and Service Dashboard shows the appropriate color for service health regardless of whether an alarm is generated. Regardless of the generate service alarms setting, all or a portion of the services criticality are added to any resource alarms impacting the health of the service. The service is shown in the service impact table of such resource alarms, even if no alarm is generated for the service model itself. Any guarantee models associated to the service tracks outage time regardless of whether an alarm is generated for the outage.
    There are several reasons to disable the generation of service alarms. First is to reduce the number of alarms that are produced in CA Spectrum. If you are sure that all resource alarms indicate the service impact, then the service alarm can be unnecessary.
    Another reason to disable service alarms is when the alarm is redundant. Often multiple services are created which monitor many of the same resources, but with a different role. For example, you can create a service model which focuses on the real-time status of a service and can have it generate alarms. Other services models monitor specific aspects or resources of the service model for SLA purposes and can be configured such that they do not produce an alarm.
  • Containers
    The containers setting specifies how a service monitors its resources, if the specified resource is a type of container model. This setting applies only to those resources which are containers and is not used for non-container resources.
    You can add different types of containers to a service. Depending on the type of container, you can configure the service to monitor container model itself or the contents of the container. When set to Monitor Contents (default), the service applies the policy to the models within the container. When using Monitor Container, the service applies the policy to the container itself.
    When Monitor Contents is specified the service monitors the containment relations of the container model, and updates its resources as models are added or removed from the container.
    Consider, for example, the effect of physically removing a router and replacing it with a new router during a network upgrade. If the original router model was placed in a container model that is monitored by Service Manager, it automatically removes from the service. If you place the new router in the same container, it automatically monitors as part of the service.
    Many environments tend to be dynamic (the service resources can periodically change). Consider the addition of new infrastructure components that increase capacity and mitigate the risk of failure. As these resources are added services, you can take them into account. Structured containers and services can adapt easily to these types of changes.
    You can view a list of containers in a service under Containers Providing Resources in the OneClick Console or Service Dashboard Information view. Verify the following image:
SPEC--Service Attributes and Relationships (9.1.2) (1)
The Containers Providing Resources subview indicates the container condition, name, type, and child count (the number of resources in the container).
The Containers setting applies to all resources which are derived from the Container model type. If you want different behavior for different containers within the same service, consider the use of multiple resource monitors, which each has their own container monitoring setting.
  • Service Policy
    During the planning phase, you identified the resource attribute to monitor and the rule set by which to determine service health. You can select an existing policy that matches this behavior or can create a new one.
    The policy should reflect the behavior of the resources that the service monitors. You can select the policy first by which resource attribute can be monitored, and next by which policy best reflects the behavior of the resources collectively. For example, if the service monitors a pair of redundant servers, a redundancy type policy would be appropriate. If you find no single policy accurately reflects the behavior of the resource, you can create multiple resource monitors to organize resources that are based on their specific monitoring requirements.
    Service Manager provides a set of standard policies that represent common service monitoring requirements. It also lets you create custom policies to meet your particular requirements.
If the service uses resource monitors, or have other services as its resources only Service Health based policies can be used.