Service affinity

Service affinity allows users to define an affinity or anti-affinity relationship to another service. The affinity requirements for a service are initially defined in the application template.

In the Service Profile, you can configure the Affinity Requirement under the service definition, which specifies to start the service’s service instances on the same host or different hosts as the other service.

For example, ServiceA can be allocated with ServiceB, which means that ServiceA’s service instances should only start on the host or hosts where there is at least one service instance of ServiceB running.

Service groups can be used in affinity and anti-affinity conditions in the place of a service. Using service groups is functionally equivalent to using the same affinity or anti-affinity for each service in the service group.

Service affinity can be constructed with a combination of the following properties:

  • Hard affinity: Every service instance must run on the same host as the list of service(s) or service group(s).

  • Hard anti-affinity: Every service instance must run on a different host than the list of service(s) or service group(s).

  • Soft affinity: Every service instance is preferred to run on the same host as the list of service(s) or service group(s).

  • Soft anti-affinity: Every service instance is preferred to run on a different host than the list of service(s) or service group(s).

To understand service affinity, see the following scenarios.

Scenario 1: A service is configured with multiple hard affinities. For example:
  • Hard affinity with another service, for example, ServiceB.
  • Hard affinity with another service, for example, ServiceC.

In this scenario, only the host or hosts with service instances from both ServiceB and ServiceC are candidates for service instances of ServiceA.

Scenario 2: A service is configured with the multiple soft affinities. For example:
  • Soft affinity with another service, for example ServiceB.
  • Soft affinity with another service, for example ServiceC.

In this scenario, all of the host or hosts are candidates; however, the host or hosts with service instances from ServiceB and ServiceC are preferred, followed by the host or hosts with either service instances from ServiceB or ServiceC.

Scenario 3: A service is configured with hard affinity and soft affinity. For example:
  • Hard affinity with another service, for example ServiceB
  • Soft affinity with another service, for example ServiceC

In this scenario, only the host or hosts with both service instances from ServiceB are candidates, and among the host or hosts would prefer the subset with service instances from ServiceC.