Lecturer: So now let's talk about Placement Groups.
Placement groups are a little bit more advanced
and we wanna use them once we want to have control
over how our EC2 instances are going to be placed
within the AWS infrastructure.
So that strategy can be defined using
these placement groups.
So we don't get direct interaction with the hardware of AWS,
but we let AWS know how we would like our EC2 instance
to be placed compared to one another.
So when you create a placement group,
you have three strategies available for you.
You have the cluster placement group
in which your instances will be grouped together
in a low-latency hardware setup
within a single availability zone.
This is going to give you high performance, but high risk.
We'll see this in details in a second.
Spread, means that your instances
are going to be spread across different hardware.
And that is a restriction on this,
that means you can only have seven EC2 instance
per placement group that's spread per AZ.
So you would use a spread placement group
when you have critical applications.
Finally, the last one is a new kind of placement group
that is really helpful, it's called partition.
It's similar to the spread,
meaning that you want to spread your instances
but here they're spread across many different partitions.
And these partitions rely on different
sets of racks of hardware within an AZ.
What does that mean is that, they're still spread,
but they're not isolated one from another failure,
but a partition should be isolated
from another partition of failure.
The idea with this, is that you can scale
through hundreds of EC2 instances per group
and that allows you to run applications
such as Hadoop, Cassandra, or Kafka.
Now let's have a look into
each of these placement groups in details.
For cluster, that means that's all our EC2 instances
are on the same rack, which means same hardware
and it's in the same availability zone.
So as you can see, all these instances
are on the same hardware.
And so what would we do this?
Well basically, we would place them on the same rack
because we want to have a cluster,
we want to have super low latency,
and want to have maybe a 10 gigabytes speed network.
So that means that we have an amazing network, right?
But as a drawback of this great network that we get,
we get the con that if the rack fails,
if there's a failure on the hardware
then all the EC2 instances will fail at the same time.
So we have increased our risk
to have a failure that's gonna be propagated
across our entire stack.
So when would we even use this?
What's the benefit you're getting this increased risk.
Well, we get great network.
And so for this, that means that we can have
a big data job that will need to complete very fast.
Or maybe we have a requirement
to have an application that needs extremely low latency
and high network throughputs,
and we're willing to take on the risk to have this failure.
And so this is something you have to realize,
it's not for every kind of application
but if your application needs
super high bandwidth and low latency,
placement groups is kind of a nice
the cluster placement group
is kind of a nice way of doing it.
Now spread is the complete opposites.
In spread we want to minimize the failure risk.
And so in this case,
when we asked for a spread placement group,
all the EC2 instances are going to be located
on different hardware.
So as you can see here,
we have three AZ and we have six EC2
and each EC2 instance is on a different hardware.
So what does that mean?
Well what we get, is that's we can span across multiple AZ
and there is a reduced risk of simultaneous failure.
Why? Well because if my hardware one fails,
I'm pretty sure my hardware two will not fail.
And so we've separated the risk of my two instances
in the Us-east-1a, to fail at the same time.
And so that's the benefit from it.
The con is that from this configuration,
we're limited to seven instances per AZ,
per placement group.
So there's a limit to how big your placement group can be.
And so you need to have a application
that's gonna be of good size, but not too big.
The use case would be an application
that needs to maximize high availability
and reduce the risk.
And in general, for critical applications
where your instance failures
must be isolated from one another.
Remember here, we have a limitation of seven instances
per AZ per placement group.
Now for the partition placement group,
we can have instances spread across partitions
in multiple availability zones.
So we can have up to seven partitions per AZ.
So in this example, we have partition one
and partition two in us-east-1a,
and partitioner three in us-east-1b.
And on each partition, you could have many EC2 instances.
So in the first one, I have four
and the second one I have four
and the third one I have four as well.
So why do we use a partition placement group?
Well, each partition represents a rack in AWS.
And so by having many partitions
you're making sure that your instances
are distributed across many hardware racks,
and so therefore,
they're safe from a rack failure from one another.
So you can have up to seven partitions per AZ
and these partitions can span
across multiple availability zones in the same region.
You can get up to hundreds of EC2 instances with a setup.
So this is the difference
versus the spread type of placement group.
And as I said, the instances and the partition
do not share the same hardware physical rack
with the instances in the other partitions,
and therefore, each partition is isolated from failure.
So that means that's, yes if one goes down,
if partition goes down, the partition number two,
then partition number one should be fine.
And to know which partition these EC2 instances are on,
there is an option to access this information
with using the metadata service.
So when would you use a partition placement group?
Well, when you have an application
that it can be partition aware to distribute the data
and your servers across partitions.
And usually, the use cases are going to be
big data applications, which are partition aware,
such using HDFS, Hbase, Cassandra and Apache Kafka.