azure - 如何为 Azure Synapse Analytics 实现 "High Availability"？

Question

Azure Synapse Analytics 是否支持存储帐户和 key 保管库等异地冗余？如果不是，为什么要为 Azure Synapse Analytics 实现高可用性？我将以下组件作为 Azure Synapse 分析解决方案的一部分

• SQL 专用池
• SQL Serverless 池
• Spark 池
• 存储帐户(ADLS)
• Azure DevOps Git 存储库

Answer 1

首先，设计和记录灾难恢复计划本身就是一个项目。我已经用 Synapse 兼职为我的一位客户开发了几个月。

第一项任务是定义您的恢复时间目标(RTO，意味着在发生灾难时您的解决方案需要多长时间才能备份)和恢复点目标(RPO，意味着您可以恢复多少分钟或几小时的数据)承受得起损失……并且借助分析解决方案，您通常可以从源重新加载以 catch )。如果分析解决方案的 RTO 和 RPO 较低(例如 2 小时)，那么您可能需要在另一个区域启动并行环境，并将数据并行加载到两个环境。如果您的 RTO 和 RPO 是典型的分析解决方案(24-48 小时)，那么您可能可以通过确保备份具有异地冗余并在发生中断时进行恢复来生存。我建议您在中断之前预先配置 Synapse 工作区和其他基础设施，除非您信任基础设施即代码解决方案。如果您的 RPO 和 RTO 很长(例如 7 天)，则 Azure 服务或区域不太可能停机这么长时间。

ADLS 支持RA-GRS冗余，因此您可以从辅助端点读取 pair region 中的所有文件。并将文件复制到次要区域中的另一个 ADLS。不幸的是，ADLS 帐户尚不支持用户启动 failover .

内置专用 SQL 池支持 geo redundant backups每天一次，但您无法控制何时服用。如果这是 Not Acceptable ，那么您需要主动创建 user-defined restore point并主动跨区域恢复并暂停SQL池。

Synapse Serverless SQL 池没有存储空间，因此请确保您在源代码管理或其他地方有架构( View 、权限、外部数据源、外部表等)的备份。数据将通过 ADLS 进行故障转移。

对于 Spark 池，请确保您的笔记本工件位于源代码管理中，并且您始终可以在需要时在另一个区域的不同 Synapse 工作区中运行它们。记录您的集群配置。

编写灾难恢复手册并定期进行灾难恢复演习(每季度一次或每年一次)。

这是另一位作者对DR plan for Synapse的描述.