Your application is using an ELB in front of an Auto Scaling group of web/application servers deployed across
two AZs and a Multi-AZ RDS Instance for data persistence.
The database CPU is often above 80% usage and 90% of I/O operations on the database are reads. To improve
performance you recently added a single-node Memcached ElastiCache Cluster to cache frequent DB query
results. In the next weeks the overall workload is expected to grow by 30%.
Do you need to change anything in the architecture to maintain the high availability or the application with the
anticipated additional load’* Why?
A.
Yes. you should deploy two Memcached ElastiCache Clusters in different AZs because the ROS Instance will
not Be able to handle the load It me cache node fails.
B.
No. if the cache node fails the automated ElastiCache node recovery feature will prevent any availability
impact.
C.
Yes you should deploy the Memcached ElastiCache Cluster with two nodes in the same AZ as the RDS DB
master instance to handle the load if one cache node fails.
D.
No if the cache node fails you can always get the same data from the DB without having any availability
impact.
I would go with A.
A single-node Memcached ElastiCache cluster failure is nothing but a total failure. (Even though AWS will automatically recover the failed node, there are no other nodes in the cluster)
http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html
Mitigating Node Failures
To mitigate the impact of a node failure, spread your cached data over more nodes. Because Memcached does not support replication, a node failure will always result in some data loss from your cluster.
When you create your Memcached cluster you can create it with 1 to 20 nodes, or more by special request. Partitioning your data across a greater number of nodes means you’ll lose less data if a node fails. For example, if you partition your data across 10 nodes, any single node stores approximately 10% of your cached data. In this case, a node failure loses approximately 10% of your cache which needs to be replaced when a replacement node is created and provisioned.
Mitigating Availability Zone Failures
To mitigate the impact of an availability zone failure, locate your nodes in as many availability zones as possible. In the unlikely event of an AZ failure, you will lose only the data cached in that AZ, not the data cached in the other AZs.
I would go with A as well. Coz if the AZ with the memcached goes down the other AZ will not be able to handle the load
A is the answer
https://aws.amazon.com/elasticache/faqs/
I would go with B, A is mentioning 2 clusters not 1 cluster (with 2 nodes)
if a node fails due to a hardware fault in an underlying physical server, ElastiCache will provision a new node on a different server.
totaly agree with Muhammad Soliman and my answer also B
A is the right answer.
Problem with B is that once cache node fails all the cached read load will go to the database which will not be able to handle the load with 30% increase to current levels. This means there will be availability impact.
A point to bear in mind – there is no loss of data when a node in the ElastiCache cluster fails because it’s just cached data.
A is the correct answer.
B- No, If the cache node fails the automated ElastiCache node recovery feature will prevent any availability impact.
Does not provide high availability, as data is lost if the node is lost.
C- Yes you should deploy the Memcached ElastiCache Cluster with two nodes in the same AZ as the RDS DB master instance to handle the load if one cache node fails.
Single AZ affects availability as DB is Multi AZ and would be overloaded is the AZ goes down.
D- No if the cache node fails you can always get the same data from the DB without having any availability impact.
Will overload the database affecting availability.
A.
The without typos should read:
Yes. You should deploy two Memcache Elasticache clusters in different AZs because the RDS instance will not be able to handle the load if the cache node fails.
Why can’t C be the right answer?
I see few arguments why it can. Because In a Multi-AZ setup of RDS instances the primary RDS instance is active while the secondary is passive (not doing anything except waiting for a failover).
That means that all traffic is being handled by the master instance in one AZ. So what is the purpose of the Elasticache in multiple AZs like mentioned in answer A?
In answer C, there are two nodes in the same AZ. And that is the AZ where the active RDS instance is. If one Elasticache node fails, until it recovers (because it will) there is no impact because the other can take the traffic.
I think C might be a better choice than A.
Why creating two clusters of single Elasticache instances?!
Actually, I’m sure that C is the correct answer because the request is not to enhance or improve high availability but to maintain it !!!
“…maintain the high availability or the application with the anticipated additional load”
C is doing exactly that!