You can also create service hierarchies by creating sub-services. The state of a sub-service contributes to the state of its parent service. This means you can model complex services with multiple contributing sub-services.
Service as a managed object
A service acts as a managed object, to which you can associate the components that deliver that service. A service definition determines e.g.:
- how the states of components in the service should be interpreted, in order to set the state of the service.
- whether a change in the state of the service would raise an event.
- the SLA goal, i.e. the minimum % of component availability for acceptable delivery of service.
Associating components to a service
The components you can associate to a service include:
- devices with associated components, e.g. ports.
- devices without associated components.
- servers as managed devices.
- IP SLA operations.
- components of devices, e.g. fans, PSUs and temperature sensors.
- other services which allows you to build a service hierarchy.
When populating a service with components, you can add components to the View and the service, or just the service alone. If a component is added to a service alone, it will become available to the user even if they do not have permission to see a View to which the component belongs.
Managing your services
Services can be managed through:
- Services dashboard and services dashlets.
- Services reports:
- CIO Perspective report includes a Services Summary and access to the Server Availability report.
To create a service within a View, you must have the appropriate permission to access the View, the View edit permission, and the Service Administration permission.
Administrators can create subservices (services that are created within a service). Administrators can also assign service ownership to non-administrators.
Users with the Service Administration tool permission can edit and delete services, including top-level services. When a non-administrator is the owner of a service, they can create subservices within it. Users with the appropriate permission can also:
- add components to a service (and therefore to the View).
- remove components from a service.
In both cases, this could amend the access scope of other user groups associated with the View, and so Administrators should be aware of this when assigning permissions for services.
Multi-server and remote objects in services
Services are defined against a selected View, or against the selected Entuity server (which is effectively against the All Objects View on that server). Services can only be defined against one View or one server, but can include sub-services from different servers. Therefore service hierarchies can be split across multiple servers, although Entuity discourages this because service updates will be more reliable and responsive if all the service's objects are on the same server.
If you access more than one Entuity server, Entuity does not consolidate services across those servers. E.g. if two services across two servers share the same name, they will remain separate services.
Services can contain components that are under management by another Entuity server. In this case, Entuity creates a local record of the remote object details, to identify the component and its state. Users with appropriate permissions can access more details through the remote server, but users without the appropriate permissions cannot.
Entuity has 2 methods of maintaining the state of remote objects:
- Every 10 minutes, the local server that is managing the service checks the remote server for the presence and state of the object. If the local server loses contact with the remote server, then the state of the remote object becomes unknown after 10 minutes.
- The remote server maintains a record of Entuity servers using objects under its management in their services. If one of these objects changes state, the remote server notifies the local server that is managing the service.
If remote object states are only updating every 10 minutes, this indicates a firewall is preventing incoming messages initiated by the remote server, but is allowing updates that were initiating by the local server managing the services.