Redshift Disaster Recovery : A Comparative Analysis of Cluster Relocation and Multi-AZ Deployment for high Availability

4 minute read
Content level: Intermediate
0

Disaster recovery planning is a crucial component for any business, ensuring that an organization can effectively respond to a disaster or other emergency that affects its information system. Amazon Redshift offers two primary options for disaster recovery in the event of an Availability Zone failure: Cluster Relocation and Multi-AZ deployment. This article will provide a detailed comparison of these two options, helping you determine the right approach for your DR strategy.

Recovery time objective (RTO) - defines the maximum amount of downtime or interruption that the organization can withstand before its critical systems, applications, or data must be restored and operational following a disruptive event or disaster

Cluster Relocation in Amazon Redshift is a feature that allows you to move your Redshift cluster to a different Availability Zone when there are issues in the current AZ that prevent optimal cluster operation. This process can be carried out without any loss of data or changes to your applications

Multi-AZ deployments of Amazon Redshift data warehouse ensure uninterrupted operations in the event of an unexpected failure within an Availability Zone. This redundancy helps maintain the availability of your Redshift cluster.

Both options offer high availability for your Amazon Redshift cluster, when current Availability Zone experiences an unexpected outage or incident. Depending on your RTO, either of these options will be suitable.

Now, let's compare these two options.

Sr noCluster relocationMulti AZ deployment
1This is Active-Passive configuration : Redshift will automatically fail over to a Redshift cluster to another Availability Zone (AZ) when current Availability Zone has issuesThis is a Active-Active Configuration: In this setup, the Amazon Redshift compute resources are deployed across two separate Availability Zones. All of these compute nodes are accessible through a single endpoint. This means that in the event of a complete failure of one Availability Zone, the remaining compute resources in the second Availability Zone will still be available to continue processing workloads without interruption
2Redshift Cluster Relocation is a feature that is currently only available for Redshift clusters deployed in a single AZ configurationAmazon Redshift allows you to create a cluster with a Multi AZ deployment configuration using the AWS Management Console or the CLI. Additionally, you can convert an existing Multi AZ Redshift cluster to a Single AZ deployment, or vice versa, using the Console or CLI. This flexibility enables you to adjust your cluster's configuration to suit your specific performance and availability requirements
3There is no additional charge for Cross-Relocation FeatureThere will be an additional cost to deploy Redshift in a Multi-AZ setup, Exact cost is based on the specific cluster configuration
4In the event of a failover, there is no loss of dataIn the event of a AZ outage,there is no loss of data
5The cluster endpoint remains the same as the original cluster, so no application changes are requiredThe cluster endpoint remains the same as the original cluster, so no application changes are required
6Available only on Ra3 (provisioned) nodesAvailable only on Ra3 (provisioned) nodes
7Cluster relocation is a suitable option when the Recovery Time Objective is longerA Multi AZ deployment is suitable for business-critical workloads that require a Recovery Time Objective in the range of seconds
8With a single AZ deployment, the Redshift Service Level Agreement is 99.9%.With a Multi AZ deployment, the Redshift Service Level Agreement is 99.99%.
9Monitoring Single AZ deployment - https://docs.aws.amazon.com/redshift/latest/dg/c_intro_system_views.html. It also supports Sys_* viewsMonitoring in a Multi-AZ deployment - Only SYS_* views can be utilized for Redshift monitoring and existing STL/SVC views are unavailable. https://docs.aws.amazon.com/redshift/latest/dg/serverless_views-monitoring.html
10Cluster relocation consideration - https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-recovery.html#limitations-recoveryMulti AZ consideration - https://docs.aws.amazon.com/redshift/latest/mgmt/overview-multi-az.html#limitations-multi-az

Additional details https://aws.amazon.com/blogs/big-data/implement-disaster-recovery-with-amazon-redshift/

AWS
EXPERT
published a month ago142 views