Redshift容灾：集群重定位与多可用区部署的高可用对比分析
1 分钟阅读
内容级别：中级
0
灾难恢复规划对于任何企业来说都是至关重要的组成部分，确保组织能够有效地应对影响其信息系统的灾难或其他紧急情况。 Amazon Redshift 在发生可用区故障时提供两种主要的灾难恢复选项：集群重定位和多可用区部署。本文将详细比较这两个选项，帮助您确定适合您的灾难恢复策略的正确方法。
恢复时间目标 (RTO) - 定义组织在发生破坏性事件或灾难后必须恢复并运行关键系统、应用程序或数据之前可以承受的最大停机时间或中断时间
Amazon Redshift 中的集群重定位功能允许您在当前可用区中存在妨碍集群最佳运行的问题时将 Redshift 集群移至不同的可用区。执行此过程不会丢失任何数据或更改您的应用程序
Amazon Redshift 数据仓库的多可用区部署可确保在可用区内发生意外故障时操作不间断。这种冗余有助于维持 Redshift 集群的可用性。
当可用区遇到意外中断或事件时，这两个选项都可以为您的 Amazon Redshift 集群提供高可用性。根据您的 RTO，这些选项中的任何一个都适合。
现在，让我们比较这两个选项。
| 序号 | 集群重定位 | 多可用区部署 |
|---|---|---|
| 1 | 这是主动-被动配置：当前可用区出现问题时，Redshift 将自动将 Redshift 集群故障转移到另一个可用区 (AZ) | 这是主动-主动配置：在此设置中，Amazon Redshift 计算资源部署在两个独立的可用区中。所有这些计算节点都可以通过单个端点访问。这意味着，如果一个可用区发生完全故障，第二个可用区中的剩余计算资源仍可用于继续处理工作负载而不会中断 |
| 2 | 集群重定位是一项目前仅适用于部署在单个可用区配置中的 Redshift 集群的功能 | Amazon Redshift 允许您使用 AWS 管理控制台或 CLI 创建具有多可用区部署配置的集群。此外，您可以使用控制台或 CLI 将现有的多可用区 Redshift 集群转换为单可用区部署，反之亦然。这种灵活性使您能够调整集群的配置以满足您的特定性能和可用性要求 |
| 3 | 重定位功能不收取额外费用 | 在多可用区设置中部署 Redshift 会产生额外成本，具体成本取决于特定的集群配置 |
| 4 | 如果发生故障转移，不会丢失数据 | 如果发生可用区中断，数据不会丢失 |
| 5 | 集群端点与原始集群保持不变，因此无需更改应用程序 | 集群端点与原始集群保持不变，因此无需更改应用程序 |
| 6 | 仅在 Ra3（预置）节点上可用 | 仅在 Ra3（预置）节点上可用 |
| 7 | 当恢复时间目标较长时，集群重定位是一个合适的选择 | 多可用区部署适用于需要秒级恢复时间目标的关键业务工作负载 |
| 8 | 通过单个可用区部署，Redshift SLA为 99.9%。 | 通过多可用区部署，Redshift 服务级别协议为 99.99%。 |
| 9 | 监控单个可用区部署 - https://docs.aws.amazon.com/redshift/latest/dg/c_intro_system_views.html。它还支持 Sys_* 视图 | 多可用区部署中的监控 - 仅 SYS_* 视图可用于 Redshift 监控，现有的 STL/SVC 视图不可用。 https://docs.aws.amazon.com/redshift/latest/dg/serverless_views-monitoring.html |
| 10 | 集群重定位注意事项 - https://docs.aws.amazon.com/redshift/latest/mgmt/managing-cluster-recovery.html#limitations-recovery | 多可用区注意事项 - https://docs.aws.amazon.com/redshift/latest/mgmt/overview-multi-az.html#limitations-multi-az |
其他详细信息 https://aws.amazon.com/blogs/big-data/implement-disaster-recovery-with-amazon-redshift/
没有评论
相关内容
AWS 官方已更新 2 年前- AWS 官方已更新 10 个月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 1 年前
