Your applications can reconnect to the endpoint and continue operations without modifications or loss of data. When Amazon Redshift relocates a cluster to a new AZ, the new cluster has the same endpoint as the original cluster.
Aws backup and disaster recovery how to#
Parts II and III of this series will show you how to implement this service in a multi-Region DR deployment.Ĭluster relocation enables Amazon Redshift to move a cluster to another AZ with no loss of data or changes to your applications. Although there are ways to work around this, we are focusing on cluster relocation. Amazon RedshiftĬurrently, Amazon Redshift only supports single-AZ deployments. The primary endpoint is a DNS name that always resolves to the primary node in the cluster. This is to ensure high availability of the service and application.Īn ElastiCache for Redis (cluster mode disabled) cluster with multiple nodes has three types of endpoints: the primary endpoint, the reader endpoint and the node endpoints. A replacement read replica is then created and provisioned in the same AZ as the failed primary.
If the primary node fails, it will promote the read replica with the least replication lag to primary. Amazon ElastiCacheĪmazon ElastiCache continually monitors the state of the primary node. This ensures that the cluster can always run your workload. Join the group to a cluster, and the group will automatically replace any terminated or failed nodes if an AZ fails. Instead of creating individual Amazon Elastic Compute Cloud (Amazon EC2) instances, create worker nodes using an Amazon EC2 Auto Scaling group. This means that if your infrastructure or AZ fails, it will automatically scale control plane nodes based on load, automatically detect and replace unhealthy control plane instances, and restart them across the AZs within the Region as needed. Amazon EKS control planeĪmazon Elastic Kubernetes Service (Amazon EKS) runs the Kubernetes management infrastructure across multiple AZs to eliminate a single point of failure. Single Region/multi-AZ with secondary Region for backups 1. We’ll show you which AWS services it uses and how they work to maintain the single Region/multi-AZ strategy.įigure 1.
This example architecture refers to an application that processes payment transactions that has been modernized with AWS managed services. The following sections list the components of the example application presented in Figure 1, which illustrates a multi-AZ environment with a secondary Region that is strictly utilized for backups.
Implementing the single Region/multi-AZ strategy This strategy replicates workloads across multiple AZs and continuously backs up your data to another Region with point-in-time recovery, so your application is safe even if all AZs within your source Region fail. This will minimize maintenance and operational overhead, create fault-tolerant systems, ensure high availability, and protect your data with robust backup/recovery processes. The strategy outlined in this blog post addresses how to integrate AWS managed services into a single-Region DR strategy. In Part I, we’ll discuss the single AWS Region/multi-Availability Zone (AZ) DR strategy. This 3-part blog series discusses disaster recovery (DR) strategies that you can implement to ensure your data is safe and that your workload stays available during a disaster.
0 kommentar(er)
