Service Models in a DSS Environment

Contents
casp1031
Contents
When creating service models in a distributed SpectroSERVER (DSS) environment there are some important factors to consider. Service models can be associated to resource models from other landscapes. The supported behaviors are as follows:
  • A service model that is created on the MLS can monitor resources from the MLS or any second tier landscape.
  • A service model that is created on a second tier landscape can monitor resources models on its own landscape or the MLS, but not other second tier landscapes.
The following behaviors apply to services which use global collections to define their resources:
  • A service model that is created on the MLS using a global collection can monitor all resources that are contained by the global collection.
  • A service model that is created on a second tier landscape using a global collection can monitor only those resources in the collection which reside on its own landscape or the MLS.
In CA Spectrum r9.2, the performance heavy cross landscape watches is replaces with asynchronous action notifications, relieving some of the burden from the SpectroSERVERs. In addition, a relay mechanism allowing the MLS to forward second tier notifications from one landscape to another allows second tier services to monitor resources from other second tier landscapes.
This lets you construct services with less concern over performance impact. In addition, it lets you create services on landscapes where the service should logically reside without concern over what landscape required remote resources reside upon. This does not eliminate the need for an efficiently designed service hierarchy, but it provides flexibility which makes it easier to design the service hierarchy. All resources from all landscapes are visible, regardless of where the service mode is being created.
Example: Supported Service to Remote Resource Configurations
The following image depicts the supported service to remote resource configurations:
SPEC--example_supported_service_oth
In addition to understanding which configurations are supported it is also important to consider the efficiency of the service model, and resource distribution impact. Monitoring a resource which resides in the same landscape is more efficient than monitoring a resource which resides in another landscape. When creating service models, strive to minimize the number of service resources which reside on remote landscapes. Consider the following example. Service XYZ has five resources, 1 of these resource models resides on the MLS while the other 4 reside on SpectroSERVER 1 (SS1). The following image depicts two potential designs for service XYZ:
Service Model Example: Resource Distribution Impact
Because of the reduced number of resources residing on a remote landscape, Solution B is a more efficient design. If the service can reside on either landscape, select the landscape where most resources exist. You can summarize this statement by saying ‘build the service closest to the bulk of its resources’.
There are some circumstances where the service has resources on multiple second tier landscapes and must reside on the MLS. In these scenarios, a more efficient service design can be created by consolidating the remote resources into a sub-service which is monitored by the parent service on the MLS.
The following image depicts two solutions which can be created when the service must reside on the MLS:
SPEC--example_service_model_distribution_impact_oth
 
Service Model Example: Service Resides on the MLS
Solution B represents a more efficient design by minimizing the number of resources which are monitored remotely. In Solution B, the service models that are created on SS1 and SS2 become resources of the service that is created on the MLS. When creating service hierarchies, such as the one depicted in Solution B, it is important to verify the policies that are used for each service, reflects the behavior of the resources from each landscape.
When creating services which use global collection consider the number of remote resources that result from the use of the global collection. When any type of container is used to specify service resources by default, the service monitors the contents of the container. A global collection can contain models from multiple landscapes.
The following image illustrates the use of a global collection that can potentially create an inefficient service design.
SPEC--example_service_model_oth
Again Solution B, represents a more efficient design by minimizing the number of resources which are monitored remotely. In Solution B, the service models that are created on SS1 and SS2 become resources of the service that is created on the MLS. When creating service hierarchies, such as the one depicted in Solution B, it is important to verify the policies that are used for each service, correctly reflects the behavior of the resources from each landscape.
When creating services which use Global Collection consider the number of remote resources that result from the use of the Global Collection. When any type of container is used to specify service resources by default, the service monitors the contents of the container. A Global Collection can contain models from multiple landscapes. Consider the following images, and how the use of a Global Collection could potentially create an inefficient service design.
Example: Global Collection
In the following scenario, if the service is created on the MLS it would be monitoring five remote resources. If the service was created on SS2, it only has to maintain one remote resource.
However, improving efficiency on this scenario cannot be as simple as moving the service to SS2. The service is using a global collection to specify its resources to support a set of potentially dynamic resources. Consider if two more models are created on SS1 which participate in the global collection.
SPEC--example_global_collection_oth
 
Global Collection Example: Add Two Additional Models
If the global collection contained resources from all landscapes, the service has to reside on the MLS. An alternative to consider is the use of multiple services which monitor the local copy of the global collection, residing on the same landscape. Although, logically a global collection is a single model, it is implemented as a set of duplicate models with a model residing on each landscape for which the global collection is specified.
SPEC--example_global_collection_additional_models_oth
 
Example: Multiple Services Monitoring the Local Copy of the Global Collection
Although this approach does produce a more efficient service, it can be complex to maintain and may require the use of CA Spectrum Command Line Interface (CLI) to implement.
An alternate technique would be to create multiple global collections which are bound to a single landscape. Services can then be created on each landscape, with a parent service to monitor them.
SPEC--example_multiple_services_oth
 
Example: Multiple Global Collections Bound to a Single Landscape
This design allows for the benefits of a dynamic collection, but also provides an efficient service design. It may not be ideal to maintain multiple Global Collections in this way so you must weigh the costs and benefits of this solution.
SPEC--example_multiple_global_collections_oth