What are services?

Service as a managed object

Service state

Associating components to a service

Managing your services

Multi-server and remote objects in services

Entuity allows you to create services to model network resources on the business services that those resources deliver. You can create and manage services via the Services dashboard.

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.

Service state

Services have a state to denote their current condition. The state of a service depends on its service logic.

 Up - when the number of components required by the service logic for the service to be up are in an up state.

 Degraded - when the service logic is set to 'At Least', and the number of components is in an up state are as few as the 'Degraded Threshold' number but less than the 'At Least' number required for the service to be up.

 Down - this depends on the logic used for the service, generally when one or more of the components that contributes to the service's overall state are down that are required by the service's logic to be up for the service to be operating normally.

 Unknown - when Entuity cannot determine the status of one or more of the components in the service that contribute to the service's overall state, and therefore the overall service state is unknown.

  None - when the service does not return a state - in the service logic, there is an option to specify 'None', which is the equivalent of turning off the 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.
• ports.
• servers as managed devices.
• applications.
• 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:
  • Service Availability report.
  • Service Delivery Summary report.
  • Service Event History report.
  • Service Inventory report.
  • Service Delivery Perspective report.
• 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

Multi-server

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.

Remote objects

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.