Guides - Work with Placement Groups

When you deploy several compute instances in an Akamai data center (“region”), they’re allocated to physical machines. This allocation varies based on several factors, including the compute instance plan and availability for that plan sizes. However, you may want your compute instances in specific physical locations, to best support your need. You may want them close together, even on the same host to speed up performance. Or, you may want to disperse them across several hosts to support high availability. Placement groups let you determine this physical location to meet either of these models.

Overview

The Placement Groups service gives you a convenient way to set up groups of your compute instances, using Cloud Manager, API operations, or our CLI. Create a new placement group in a supported region and add new or existing compute instances from that region to your group. With the new group created, we physically move your compute instances into it, based on your desired model.

Availability

The Placement Groups service is available in select regions. Currently, this includes:

• Miami, FL (us-mia)

• Chicago, IL (us-ord)

Affinity, enforcement, and compliance

To distribute your compute instances in a placement group, we use the industry-recognized affinity standard. Pick from one of two types to serve as your “preferred container” type for your placement group:

• Affinity. Your compute instances are physically close together, possibly on the same host. Set this as your preferred container if your application requirements value performance over availability.

• Anti-affinity. Your compute instances are placed in separate fault domains, but they’re still in the same region. Use this preferred container to better support a high-availability model.

In addition to selecting the Affinity Type, you select how it’s enforced when you add more Compute Instances to the placement group.

• Strict (Best practice). You can’t add more compute instances to your placement group if your preferred container lacks capacity or is unavailable. For example, let’s assume you’ve set Anti-affinity as your affinity type. If you try to add a compute instance that’s on the same host, or there’s no capacity outside that host in the region, you get an error and can’t add the compute instance. This helps you keep your placement group compliant, because you can only pick compute instances that fit your desired model.

• Flexible. You can add more compute instances to your placement group even if they’re outside your affinity type’s preferred container. However, if you add one and it violates your affinity type, the placement group becomes non-compliant. Once the necessary capacity is available in the data center, we physically move the compute instance for you to fit your affinity type’s preferred container and make it compliant again. This can work for you if you know you need to add more compute instances to your group in the future.

Fix Non-compliance

If a placement group becomes non-compliant, we’re alerted and we’ll bring it back into compliance as soon as possible. Non-compliance can only be fixed by Akamai staff. You can’t fix it yourself.

By design, a Strict placement group can’t be made non-compliant when simply creating it or managing its Compute Instances. In rare cases, non-compliance can occur if we need to fail-over or migrate your Compute Instances for maintenance. Because of this, fixing non-compliance for Strict placement groups is prioritized over Flexible groups.

Create a placement group

curl -H "Authorization: Bearer $TOKEN" \
    https://api.linode.com/v4/regions

curl -H "Authorization: Bearer $TOKEN" \
    https://api.linode.com/v4/regions/us-east

curl -H "Authorization: Bearer $TOKEN"
    -H 'X-Filter: { "region": "us-east" }'
    https://api.linode.com/v4/networking/ips

curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer $TOKEN" \
    -X POST -d '{
      "label": "new-placement-group",
      "region": "us-iad",
      "affinity-type": "anti_affinity:local",
      "is_strict": "true"
    }' \
    https://api.linode.com/v4/placement/groups

curl -H "Content-Type: application/json" \
    -H "Authorization: Bearer $TOKEN" \
    -X POST -d '{
      "linodes": [
        123, 456, 789
      ]
    }' \
    https://api.linode.com/v4/placement/groups/12/assign

Technical Specifications

• Placement groups support dedicated and shared compute instance plans. Plan types can be mixed in a placement group. However, specialty hardware, such as GPUs aren’t supported.

• A compute instance can only exist in one placement group.

• The Affinity Type and Region you select determine the maximum number of compute instances per placement group. This quantity is reflected in Cloud Manager when reviewing your placement group. With the API, the GET /v4/regions/{regionid} operation contains the maximum_linodes_per_pg element that displays this maximum.

• Placement groups can be renamed or deleted. To delete a placement group, you need to remove all compute instances from it.

• When you remove a compute instance from a placement group, it continues to function as-is, but the placement decisions are no longer guided by the group’s Affinity Type.

• Entry points to create a placement group are also available when creating a new compute instance or editing an existing one.