Azure SQL Database标准异地备援(Standard Geo-Replication)功能

感谢刘建昌同学翻译微软公司 Azure SQL Database 团队主管 Tony Petrossian 于 2014 年 9 月 3 日所发表的文章 https://azure.microsoft.com/blog/2014/09/03/azure-sql-database-standard-geo-replication/

在这篇文章中，我们将继续针对 Azure SQL Database 各种业务连续性( Business Continuity )方案作介绍，以及讨论最近 Azure SQL Database 新释出的标准异地备援( Standard Geo-Replication )功能。标准异地备援功能允许您从主数据库以异步 ( asynchronously ) 的方式将已认可的交易 ( committed transactions ) 复制到预先设定妥的备援数据中心 ( Azure Regions )。

在深入讨论之前，我们先整理 Azure SQL Database 所有确保业务连续性之解决方案，并且讨论它们在各 Azure SQL Database 服务层级下的状况。您可以在此篇文章中找到所有关于 Azure SQL Database 各服务层的详细信息。

业务连续性 ( Business continuity )

在先前关于 主动异地备援( Active Geo-Replication ) 的文章中，已经先行定义了业务连续性的挑战目标，而在这里我们来快速复习一下几个重要的概念 :

• 灾难回复 Disaster recovery ( DR ) : 恢复应用程序至正常运作功能的过程。
• 时间点回复 Point in time restore : 将数据库从人为错误或是数据错误的状态下回复至过去的某个时间点 ( 需要在备份期间内 )
• 目标恢复时间 Recovery Time Objective (RTO) : 当错误发生后，系统要在多少时间内回复正常
• 目标恢复点 Recovery Point Objective (RPO) : 当错误发生时，可忍受的数据遗失的时间长度

下表显示了不同服务层之间的业务连续性差异 :

选择哪一种业务连续性与灾难恢复( Business Continuity/Disaster Recovery ，BCDR )解决方案的关键因素往往与应用程序效能有关，如果您的应用程序的数据更新率( rate of updates )较低，处理的数据量也较少时，Azure SQL Database所提供最基本异理还原( Geo-Restore )将是适合您的方案。若应用程序需要处理较大的数据量，并且对于 RPO 以及应用程序效能要求较高时，就需要使用标准异地备援 ( Standard Geo-Replication ) 来符合您的需求。至于最高阶的主动异地备援 ( Active Geo-Replication ) 则是针对需要最低 RPO 以及处理大量数据异动量之需求所提供的解决方案。

当您从Azure SQL Database Basic服务层升级到Premium服务层时，您能够选择的业务连续性与灾难恢复( BCDR )解决方案也就越多。 Azure SQL Database 高阶版本包含了所有入门版本服务层级的全部 BCDR 功能。

标准异地备援与主动异地备援的不同处

现在让我们进一步了解标准异地备援的用户验经验，以及它不同于主动异地备援之处。

首先，标准异地备援与主动异地备援是建立在相同的技术上，但是标准异地备援较适合数据密集写入( write-intensive )量较少的应用情境。一般而言以下几点考虑会让用户决定该采用标准异地备援 :

• 目标应用程序的数据更新速率( update rate )不需要用很高之灾难备援SLA。
• 应用程序只需要简单的恢复作业流程，而不需要太复杂的逻辑来做故障转移的决定。
• 这些应用程序通常有成本上的考虑( cost sensitive )。

标准异地备援( Standard Geo-Replication )相较于主动异地备援( Active Geo-Replication )简化如下:

1. 在Microsoft定义的灾难备援配对数据中心( DR paired )中建立一个备援数据库( secondary database )。灾难备援配对数据中心的列表可以在此查阅。
2. 可以在主要( master )数据库上可以看到备援的数据库，但是除非故障转移完成，否则是不能够直接联机使用备援的数据库。
3. 由于备援的数据库平时是不能够直接读取的，也因此收费较便宜。
4. 当Azure数据中心长时间停摆时才会启用故障转移动作，每当Azure入口网站会显示Azure SQL Database服务为"degraded"时，很可能需要花费长达一个小时的时间才会恢复正常，。
5. 在Azure数据中心长时间停摆的状况下，如果微软认为复原时间会超过24小时，或是Azure SQL Database发生问题而用户超过24小时没有主动启动故障转移程序，微软会将所有使用标准异地备援的用户数据库自动切换到备援的数据中心。

图一 : 为标准异地备援的典型配置。一个数据库可以在配对的备援数据中心 ( DR paired ) 内拥有一个脱机状态的备援数据库

如您所见，标准异地备援的重点就是让Azure SQL Database数据库从大规模的故障区域中尽速恢复，并且维持正常的运作。但是有时候要做到这点，可能还是需要更强而有力的主动异地备援 ( Active Geo-Replication ) 来完成。以下表格总结了两者使用的差异 :

为什么要使用标准异地备援，而不是使用 Azure SQL Database Premium 的主动异地备援 ?

既然Azure SQL Database Premium版能够同时支持标准异地备援和主动异地备援。那在甚么情况下您要选择的是标准异地备援，而不是更为强大的主动异地备援呢 ?

标准异地备援被设计为一个较为简单且便宜的灾害还原解决方案( DR solution )，特别适合用来处理数据更新率较低的应用程序。如果 Azure SQL Database Premium 版数据库是被用来处理大批读取导向 ( read-oriented ) 的工作负载时，就相当适合使用标准异地备援。

当使用标准异地备援时，您无法选择备援数据库的数据中心位置，也不会如同主动异地备援般拥有四个具备读取权限的备援数据库，也无法完全控制在何时何地进行故障转移。但是相对的，使用标准异地备援让您得到一个由 Microsoft 控制，较为简单的监测方式以及故障转移流程。对于 Azure SQL Database Premium 用户而言，标准异地备援和主动异地备援是可以交互搭配使用的，例如您可以使用 Azure SQL Database Premium 版数据库去建立一个脱机的标准异地备援数据库，同时您仍可以利用主动异地备援功能，建立多个可读取的备援数据库用于读取负载平衡，以应付高密集读取的应用情境。

数据库故障转移 ( failover )

标准异地备援是专门为数据库提供从灾害停机中恢复的解决方案。除非有一个 Azure SQL Database 在主要的托管区域停止运作，否则您将无法启动故障转移到配对数据中心内的备援 ( secondary ) 数据库。也就是说若您使用标准异地备援，倘若发生用户应用层级的数据库停止运作，用户是无法自行手动进行的故障转移，若有这类需求，用户应该选择使用主动异地备援。

若有一个Azure数据中心发生长时间停机的状况时，微软会针对使用Azure SQL Database标准异地备援的数据库进行容错转移。这项措施的目标，就是要在 Azure SQL Database 停机发生后的一小时之内启动故障转移，一旦启动这项措施，用户您开始进行容错转移动作，将数据库移转至备援数据中心的数据库，并停止主数据库与备援数据库之间的数据复制动作。

这种方法使得故障转移变得相当简单，应用程序只需要判断是否启用故障转移的旗标( flag )，再来决定要进行故障转移还是等待目前数据库复原。这两种选择会依据应用程序需求而有所不同。若您的应用程序比较注重不停机的高可用性 ( higher availability ) 并能容忍漏失过去一个小时已经储存于主数据库内的数据，当为微软启用允许容错转移后，用户应尽速启用故障转移。倘若您的应用程序比较注重数据的完整性，已经储的数据遗失是非常敏感 ( sensitive ) 的，虽然微软已经允许标准异地备援用户开始进行容错转移，用户能可能愿意继续等待 Azure SQL Database 恢复正常，以避免数据库内的数据漏失。然而，若是主数据库所在之 Azure 数据中心若是在发生停机后 24 小时之内都没法复原，则标准异地备援的数据库都会自动执行故障转移动作。在这种最坏状况下，应用程序将会有 24 小时的停机时间并且会有部分数据遗失。无论是用户自己启动故障转移或是等待 24 小时让它自行发生，用户都需重新配置与设定您的应用程序的数据库联机，连接到容错转移后的备援数据库。

完成容错转移之后，您也会想要确定新的主要数据中心( Primary region )是否也受到相同的保护，因此在进行故障转移的过程中，Azure会更新它的灾难恢复配对数据中心( DR pair )，这将允许您从新的主要数据中心( Primary region )来启动新的地理数据复制来保护它自己。由于建立新的备援区域需要花费一些时间 ( 取决于数据库数据量大小 )，您必须承担在建立新的备援区域的这段期间，Azure SQL Database 暂时无高可用性备援能力，并且接受在没有保护状态下执行应用程序的风险。最妥当的办法就是等待故障转移数据库已经有完整备援数据中心保护之后，再启动应用程序。

建立完备原数据中心后，新的灾害复原( DR )的配置如下图所示 :

图二 : 在故障转移更新完新的灾难备援配对资中心之后，应用程序可以建立一个新的备援数据库并开始数据复制动作

灾害复原演练 ( Disaster Recovery Drills )

由于数据库的故障转移与数据是相互关联并且是一个具破坏性的回复方式，因此故障转移的整个流程应该要定期经过测试来确保应用程序能够应付灾难发生时的突发状况。这个测试的过程叫做灾坏复原演练 ( Disaster Recovery Drills )。许多国际信息安全相关认证也要求应用程序备妥与进行灾坏复原演练。虽然平时在 Azure SQL Database 正常运行的情况下，在备援数据中心内脱机 ( offline ) 的备援数据库无法真的进行故障转移，但是在灾害复原演练时，用户还是可以透过停止主数据库 ( primary database ) 的地理复写的方式，让被援数据中心的数据库可以被用户启用。来测试整体的灾害复原流程。

在经过故障转移之后，备援数据库将可以完全地被存取，就像主数据库般的让应用程序使用。在演练的过程中，数据有可能会遗失而且在这段时间主要数据中心内的数据库并没有受到保护，因此我们不建议客户在实际生产用的数据库上进行灾害复原演练。我们建议您在主数据库所在的数据中心内建立一个数据库副本，并且使用这个副本和它的辅助区域来测试容错转移流程演练。

管理工具

标准异地备援提供了在主动异地备援上启用的REST API子集。要管理标准异地备援，您可以使用这个API并且提供PowerShell指令或是使用Azure管理网站。由于这项功能还在预览阶段，因此您需要先登入到Azure SQL Database的新服务层。启用标准异地备援最简单的方式就是使用Azure管理网站中的"异地备援"选项。

图三 : 使用 Azure 管理网站建立和监控脱机地理辅助区的状态

要注意的是，您可以在任何时候选择取消地理复制。有两种方式可以达到此效果，您可以在主数据库上终止地理复制或是直接删除备援的辅助数据库。

第一种方式是当您复制到错误的数据库时，可以有效的终止这个动作。若您在备援数据库建立好之前就取消这项动作，您将不会被收取任何费用，但若在备援数据库已经建立好之后才取消，则您需要按照您使用的额度来支付费用。使用第二种方式，将会自动停止地理数据复制并且删除备援数据库，并且从停止的那一刻开始停止收费。

结论

标准异地备援针对拥有适度数据更新速率的应用程序，提供了一个强大的灾难恢复解决方法，虽然它不如主动异地备援来的灵活，但是我们认为它还是符合大多数应用程序的需求。请告知我们您的想法，我们会认真听取您在新的Azure SQL Database服务层中使用地理复制地回复意见，您能够在以下文章 中得到更多信息。