EC2 Placement Groups
- When you launch a new EC2 instance, the EC2 service attempts to place the instance in such a way that all your instances are spread out across underlying hardware to minimize correlated failures. You can use placement groups to influence the placement of a group of interdependent instances to meet the needs of your workload. Depending on the type of workload, you can create a placement group using one of the following placement strategies:
\
Cluster- packs instances close together inside an Availability Zone for better latency and higher n/w throughput. This strategy enables workloads to achieve the low-latency network performance necessary for tightly coupled node-to-node communication that is typical of HPC applications.
§ Cannot use placement groups across AZ's
§ Recommended to use enhanced networking
§ For best performance choose instances
supporting enhanced networking
§ Best to use same singe instance
type in a cluster.
Spread
- strictly places a small group of instances across distinct underlying hardware to reduce correlated failures.
§ Can be spread across multiple AZ
§ Instances on distinct underlying hardware
§ Recommended for small number of critical instances (primary/standby)
§ Max 7 EC2s per group per AZ
- strictly places a small group of instances across distinct underlying hardware to reduce correlated failures.
§ Can be spread across multiple AZ
§ Instances on distinct underlying hardware
§ Recommended for small number of critical instances (primary/standby)
§ Max 7 EC2s per group per AZ
§ Best to launch all instances at
same time – to guarantee availability
§ If you try to launch a spread
group and there isn’t sufficient h/w, the request fails. Try again later.
§ Can do over VPC peering
Partition
- spreads your instances across logical partitions such that groups of instances in one partition do not share the underlying hardware with groups of instances in different partitions. This strategy is typically used by large distributed and replicated workloads, such as Hadoop, Cassandra, and Kafka.
- There is no charge for creating a placement group
- Group name need to be unique per account
- Cannot merge 2 placement groups – but can use VPC peering
- EC2 can’t be part of multiple groups
- Can move (ADD) an instance into a group
- Can move from group to group
- Can remove form group
§ To do these 3 CANs – need to Stop instance, i.e. this can't be instance store, only EBS
- spreads your instances across logical partitions such that groups of instances in one partition do not share the underlying hardware with groups of instances in different partitions. This strategy is typically used by large distributed and replicated workloads, such as Hadoop, Cassandra, and Kafka.
- There is no charge for creating a placement group
- Group name need to be unique per account
- Cannot merge 2 placement groups – but can use VPC peering
- EC2 can’t be part of multiple groups
- Can move (ADD) an instance into a group
- Can move from group to group
- Can remove form group
§ To do these 3 CANs – need to Stop instance, i.e. this can't be instance store, only EBS
- Recommendation is to keep EC2
instance type monogamous across groups
-
No comments:
Post a Comment