This document explains the behavior, restrictions, and billing of placement policies.
By default, you manage the location of your Compute Engine instances only by specifying their zones. Placement policies let you further specify the relative placement of your instances in a zone. Based on the policy that you apply to your instances, you can reduce network latency across instances (compact policy) or improve resiliency against location-specific disruptions (spread policy).
To learn how to create and apply placement policies, see the documentation for using compact placement policies and using spread placement policies.
To learn about other ways of controlling instance placement, see the documentation for sole-tenancy and regional managed instance groups (MIGs).
About placement policies
Each compute instance runs on a physical server—a host—that is on a server rack. Each server rack is part of a cluster that is located in a data center for a zone. When you have multiple instances in the same zone, Compute Engine places these instances in different hosts by default. This placement minimizes the impact of potential power failures. However, when you apply a placement policy to instances in the same zone, you can further control the relative locations of those instances in the zone based on the needs of your workload.
You can create the following types of placement policies:
Compact placement policy. This policy places instances close to each other in a zone, which reduces network latency among the instances. A compact placement policy is helpful when your instances need to communicate often with each other—for example, when running high performance computing (HPC), machine learning (ML), or database server workloads.
To learn more, see About compact placement policies in this document.
Spread placement policy. This policy places instances on separate, distinct hardware, which you can use to increase your workload's reliability. Specifically, spreading instances helps to reduce the number of instances that are simultaneously impacted by location-specific disruptions, such as hardware errors. Additionally, if you use a spread placement policy to overprovision capacity in multiple locations, you can help ensure that you still have sufficient capacity even when one location is disrupted. For this reason, spread placement policies can also be helpful for large-scale, distributed, and replicated workloads, such as Hadoop Distributed File System (HDFS), Cassandra, or Kafka.
To learn more, see About spread placement policies in this document.
About compact placement policies
When you apply a compact placement policy to compute instances, Compute Engine tries to place the instances as close to each other as possible. This placement is subject to the machine type and zone availability of the instances, and instance compactness is achieved only on a best-effort basis. If your application is latency-sensitive and requires instances to be as close together as possible (maximum compactness) in a zone, then specify a maximum distance value (Preview). Lower maximum distance values ensure closer instance placement, but can result in fewer available machines for instance placement.
The following table outlines the supported machine series, maximum number of instances, and host maintenance policy for each maximum distance value:
| Maximum distance value | Description | Supported machine series | Maximum number of instances | Supported host maintenance policy |
|---|---|---|---|---|
| Unspecified (Not recommended) | Compute Engine makes best-effort attempts to place the instances as close to each other as possible, but with no maximum distance between instances in the zone. | A41, A3 Ultra1, A3 Mega2, A3 High2, A3 Edge2, A2, C4D, C4, C3D, C3, C2D, C2, G2, H3, N2, N2D, and Z3-metal3 | 1,500 | Migrate or Terminate |
3 |
The instances are placed in adjacent clusters for low latency. | A41, A3 Mega2, A3 High2, A3 Edge2, A2, C4D, C4, C3D, C3, C2D, C2, G2, H3, and Z3-metal3 | 1,500 | Migrate or Terminate |
2 |
The instances are placed in adjacent racks and experience lower network latency than instances placed in adjacent clusters. | A41, A3 Ultra1, A3 Mega2, A3 High2, A3 Edge2, A2, C4D, C4, C3D, C3, C2D, C2, G2, H3, and Z3-metal |
|
Terminate |
1 |
The instances are placed in the same rack and minimize network latency as much as possible. | A3 Mega2, A3 High2, A3 Edge2, A2, C4D, C4, C3D, C3, C2D, C2, G2, H3, and Z3-metal | 22 | Terminate |
1 You can only apply compact placement policies to A4 or A3
Ultra instances that are deployed using the features provided by
Cluster Director. For more information, see
Cluster Director
in the AI Hypercomputer documentation.
2 By default, you can't apply compact placement policies with a
maximum distance value to A3 Mega, A3 High, or A3 Edge instances. To request
access to this feature, contact your assigned
Technical Account Manager (TAM) or the
Sales team.
3 Bare metal instances only support the Terminate
host maintenance policy.
After you create a compact placement policy and apply it to compute instances, you can verify the physical location of the instances in relation to other instances that specify the same compact placement policy. For more information, see Verify the physical location of an instance.
About spread placement policies
When creating a spread placement policy, you can specify the number of availability domains—up to eight—to spread its compute instances across. Availability domains provide isolated, distinct hardware to minimize the impact of localized disruptions. However, they're still impacted by shared infrastructure failures, such as data center power outages.
To reduce the proportion of your instances that are impacted whenever an availability domain is disrupted, spread your instances across at least two availability domains—each additional availability domain further reduces the proportion of your instances that are impacted. Alternatively, you might spread your instances across a small number of availability domains to try to limit network latency between those instances or due to zonal restrictions.
When you apply a spread placement policy to an instance, Compute Engine places the instance in a specific availability domain based on one of the following:
Automatic placement. By default, Compute Engine automatically places the instance in a domain based on the number of instances the placement policy is already applied to:
Eight instances or less: If a spread placement policy is already applied to eight instances or less, then Compute Engine places your instance in the domain with the fewest instances.
More than eight instances: If a spread placement policy is already applied to more than eight instances, then Compute Engine places your instance in a random domain.
Specific placement. When creating an instance, updating the properties of an instance, or creating an instance template, you can optionally specify the availability domain in which to place your instances. Distributing instances across domains is helpful to increase the resiliency of your workload. Placing instances in the same domain might help reduce network latency among those instances.
When you apply a spread placement policy to an existing instance, the instance might need to be relocated to a different availability domain. During this process, Compute Engine stops or live migrates the instance based on its host maintenance policy.
Restrictions
The following sections outline the restrictions for placement policies.
Restrictions for all placement policies
For all placement policies, the following restrictions apply:
Placement policies are regional resources, and they only work in the region where they are located. For example, if you create a placement policy in region
us-central1, then you can only apply it to Compute Engine resources located inus-central1or in a zone inus-central1.You can only apply one placement policy per Compute Engine resource.
You can replace or remove placement policies only from compute instances. Replacing or removing placement policies from other Compute Engine resources isn't supported.
You can only delete a placement policy if it's not applied to any Compute Engine resource.
You can't apply placement policies to future reservation requests or to on-demand reservations that Compute Engine creates to fulfill an approved future reservation.
You can't apply placement policies to instances that specify sole-tenant nodes.
Restrictions for compact placement policies
In addition to the restrictions for all placement policies, compact placement policies have the following restrictions:
If a compact placement policy specifies a maximum distance value, then this value affects the maximum number of compute instances that you can apply the placement policy to, as well as the machine series and host maintenance policy that the instances can use.
If you want to apply a compact placement policy to on-demand reservations, then make sure of the following:
You can only apply compact placement policies to on-demand, single-project, standalone reservations. Shared reservations and reservations attached to commitments aren't supported.
You can't apply compact placement policies that specify a maximum distance value of
1.You can only apply a compact placement policy to one reservation at a time.
Restrictions for spread placement policies
In addition to the restrictions for all placement policies, spread placement policies have the following restrictions:
You can apply a spread placement policy to 256 instances maximum.
You can't apply spread placement policies to reservations.
Billing
There are no additional costs associated with creating, deleting, or applying placement policies to a compute instance.
What's next
Learn how to create and apply placement policies to compute instances: