您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

Azure 复原技术指南:在发生区域范围的服务中断后进行恢复Azure resiliency technical guidance: recovery from a region-wide service disruption

Azure 在物理上和逻辑上划分为称为区域的单位。Azure is divided physically and logically into units called regions. 一个区域由一个或多个邻近的数据中心组成。A region consists of one or more datacenters in close proximity.

在极少数情况下,整个区域的设施可能都无法访问,例如,由于出现网络故障。Under rare circumstances, it is possible that facilities in an entire region can become inaccessible, for example due to network failures. 或自然灾害等原因造成的完全失去联系。Or facilities can be lost entirely, for example due to a natural disaster. 本部分说明可用于创建在各区域间分布的应用程序的 Azure 功能。This section explains the capabilities of Azure for creating applications that are distributed across regions. 这种分布有助于最大程度地减少一个区域的故障影响到其他区域的可能性。Such distribution helps to minimize the possibility that a failure in one region could affect other regions.

云服务Cloud services

资源管理Resource management

要将计算实例分布在多个区域上,可在每个目标区域中创建单独的云服务,然后将部署包发布到每个云服务上。You can distribute compute instances across regions by creating a separate cloud service in each target region, and then publishing the deployment package to each cloud service. 但请注意,必须由应用程序开发人员或使用流量管理服务在不同区域的云服务间分布流量。However, note that distributing traffic across cloud services in different regions must be implemented by the application developer or with a traffic management service.

在容量规则方面,事先确定为实现灾难恢复而部署的备用角色实例数目是其中的重要一环。Determining the number of spare role instances to deploy in advance for disaster recovery is an important aspect of capacity planning. 具有规模完整的辅助部署可确保容量在需要时始终可用,但是,这实际上也会使成本加倍。Having a full-scale secondary deployment ensures that capacity is already available when needed; however, this effectively doubles the cost. 常见的模式是准备小型的辅助部署,规模足以满足运行关键服务即可。A common pattern is to have a small, secondary deployment, just large enough to run critical services. 建议建立一个小型辅助部署用于保留容量和测试辅助环境的配置。This small secondary deployment is a good idea, both to reserve capacity, and for testing the configuration of the secondary environment.

备注

订阅配额并非容量保证。The subscription quota is not a capacity guarantee. 配额只是信用限制。The quota is simply a credit limit. 若要保证容量,必须在服务模型中定义所需数量的角色,且必须部署这些角色。To guarantee capacity, the required number of roles must be defined in the service model, and the roles must be deployed.

负载均衡Load Balancing

若要实现各区域流量的负载均衡,需要使用流量管理解决方案。To load balance traffic across regions requires a traffic management solution. Azure 提供 Azure 流量管理器Azure provides Azure Traffic Manager. 也可以利用提供类似流理管理功能的第三方服务。You can also take advantage of third-party services that provide similar traffic management capabilities.

策略Strategies

可以使用多种备用策略在区域间实现分布式计算。Many alternative strategies are available for implementing distributed compute across regions. 这些策略必须根据特定业务要求和应用程序的情况量身定制。These must be tailored to the specific business requirements and circumstances of the application. 大体而言,方法可分为以下几类:At a high level, the approaches can be divided into the following categories:

  • 发生灾难时重新部署:如果采用这种方法,则会在灾难发生时从头开始重新部署应用程序。Redeploy on disaster: In this approach the application is redeployed from scratch at the time of disaster. 这种方法适合不需要保证恢复时间的非关键应用程序。This is appropriate for non-critical applications that don’t require a guaranteed recovery time.
  • 暖备份(主动/被动):在备用区域创建辅助托管服务,并部署角色以保证最低容量;但是,角色不会接收生产流量。Warm Spare (Active/Passive): A secondary hosted service is created in an alternate region, and roles are deployed to guarantee minimal capacity; however, the roles don’t receive production traffic. 对于未设计为在区域间分布流量的应用程序来说,这种方法很有用。This approach is useful for applications that have not been designed to distribute traffic across regions.
  • 热备份(主动/主动):应用程序设计为接收多个区域的生产负载。Hot Spare (Active/Active): The application is designed to receive production load in multiple regions. 为每个区域中云服务所配置的容量可能高于灾难恢复用途所需的容量。The cloud services in each region might be configured for higher capacity than required for disaster recovery purposes. 或者,云服务可在灾难或故障转移时进行扩展。Alternatively, the cloud services might scale out as necessary at the time of a disaster and failover. 这种方法需要在应用程序设计中进行大量的投资,但是也具有明显的好处。This approach requires substantial investment in application design, but it has significant benefits. 这些好处包括恢复时间更短且更有保证、连续测试所有恢复位置和对容量的有效使用。These include low and guaranteed recovery time, continuous testing of all recovery locations, and efficient usage of capacity.

关于分布式设计的完整讨论不属于本文档的范畴。A complete discussion of distributed design is outside the scope of this document. 有关更多信息,请参阅 Azure 应用程序的灾难恢复和高可用性For further information, see Disaster Recovery and High Availability for Azure Applications.

虚拟机Virtual Machines

基础结构即服务 (IaaS) 虚拟机 (VM) 的恢复在许多方面与平台即服务 (PaaS) 计算恢复相似。Recovery of infrastructure as a service (IaaS) virtual machines (VMs) is similar to platform as a service (PaaS) compute recovery in many respects. 但是,由于 IaaS VM 包含 VM 和 VM 磁盘,因此两者之间也存在一些重要的差异。There are important differences, however, due to the fact that an IaaS VM consists of both the VM and the VM disk.

  • 使用 Azure 备份创建应用程序一致的跨区域备份Use Azure Backup to create cross region backups that are application consistent. Azure 备份可让客户跨多个 VM 磁盘创建应用程序一致的备份,并支持跨区域的备份复制。Azure Backup enables customers to create application consistent backups across multiple VM disks, and support replication of backups across regions. 为此,可在创建时选择异地复制备份保管库。You can do this by choosing to geo-replicate the backup vault at the time of creation. 请注意,必须在创建时配置备份保管库的复制,Note that replication of the backup vault must be configured at the time of creation. 而不能在以后设置。It can't be set later. 如果某个区域发生服务中断,Microsoft 将向客户提供备份。If a region is lost, Microsoft will make the backups available to customers. 客户将可以还原到其配置的任何还原点。Customers will be able to restore to any of their configured restore points.
  • 将数据磁盘与操作系统磁盘分开Separate the data disk from the operating system disk. 有关 IaaS VM 的一项重要注意事项就是,如果不重新创建 VM 就不能更改操作系统磁盘。An important consideration for IaaS VMs is that you cannot change the operating system disk without re-creating the VM. 如果恢复策略是在灾难后部署的,这便不是问题。This is not a problem if your recovery strategy is to redeploy after disaster. 但是,如果使用暖备份方法来保留容量,则它可能会成为问题。However, it might be a problem if you are using the Warm Spare approach to reserve capacity. 要正确实现这一点,必须将正确的操作系统磁盘部署到主要位置和辅助位置,而将应用程序数据存储在单独的驱动器上。To implement this properly, you must have the correct operating system disk deployed to both the primary and secondary locations, and the application data must be stored on a separate drive. 如果可能,请使用这两个位置均可以提供标准的操作系统配置。If possible, use a standard operating system configuration that can be provided on both locations. 在故障转移后,必须将数据驱动器连接到辅助 DC 中的现有 IaaS VM。After a failover, you must then attach the data drive to your existing IaaS VMs in the secondary DC. 可以使用 AzCopy 将数据磁盘的快照复制到远程站点。Use AzCopy to copy snapshots of the data disk(s) to a remote site.
  • 注意异地故障转移多个 VM 磁盘后的潜在一致性问题Be aware of potential consistency issues after a geo-failover of multiple VM Disks. VM 磁盘是作为 Azure 存储 Blob 实现的,具有相同的异地复制特征。VM Disks are implemented as Azure Storage blobs, and have the same geo-replication characteristic. 除非使用 Azure 备份,否则不能保证磁盘间的一致性,因为异地复制是异步进行的,并且是独立复制的。Unless Azure Backup is used, there are no guarantees of consistency across disks, because geo-replication is asynchronous and replicates independently. 可以保证 VM 磁盘在异地故障转移后处于崩溃一致状态,但不能保证磁盘间的一致性。Individual VM disks are guaranteed to be in a crash consistent state after a geo-failover, but not consistent across disks. 在某些情况下(例如使用磁盘条带化时)可能会产生问题。This could cause problems in some cases (for example, in the case of disk striping).

存储Storage

使用 blob、表、队列和 VM 磁盘存储的异地冗余存储进行恢复Recovery by using Geo-Redundant Storage of blob, table, queue and VM disk storage

在 Azure 中,默认情况下,Blob、表、队列和 VM 磁盘都会进行异地复制。In Azure, blobs, tables, queues, and VM disks are all geo-replicated by default. 这称为异地冗余存储 (GRS)。This is referred to as Geo-Redundant Storage (GRS). GRS 会将存储数据复制到几百英里以外特定地理区域中的配对数据中心中。GRS replicates storage data to a paired datacenter hundreds of miles apart within a specific geographic region. GRS 旨在提供额外的持久性,以防出现重大的数据中心灾难。GRS is designed to provide additional durability in case there is a major datacenter disaster. Microsoft 控制故障转移发生的时间且故障转移限于重大灾难,也就是原始主要位置被视为无法在合理时间内恢复。Microsoft controls when failover occurs, and failover is limited to major disasters in which the original primary location is deemed unrecoverable in a reasonable amount of time. 在某些情况下,这可能需要几天时间。Under some scenarios, this can be several days. 尽管同步间隔在服务级别协议中并未提及,但是数据通常在几分钟内完成复制。Data is typically replicated within a few minutes, although synchronization interval is not yet covered by a service level agreement.

在异地故障转移时,不会对访问帐户的方式进行更改(URL 和帐户密钥不会更改)。In the event of a geo-failover, there will be no change to how the account is accessed (the URL and account key will not change). 但是,在故障转移后存储帐户将位于另一个区域。The storage account will, however, be in a different region after failover. 这可能会影响需要与存储帐户保持区域关系的应用程序。This could impact applications that require regional affinity with their storage account. 即使服务和应用程序不要求存储帐户位于相同的数据中心,跨数据中心的延迟性和带宽费用也使暂时会流量移到故障转移区域成为一种明智之举。Even for services and applications that do not require a storage account in the same datacenter, the cross-datacenter latency and bandwidth charges might be compelling reasons to move traffic to the failover region temporarily. 整体的灾难恢复策略可以考虑此项因素。This could factor into an overall disaster recovery strategy.

除了 GRS 提供的自动故障转移之外,Azure 还引入了一种服务,让你能够对位于辅助存储位置的数据副本进行读取访问。In addition to automatic failover provided by GRS, Azure has introduced a service that gives you read access to the copy of your data in the secondary storage location. 这称为读取访问异地冗余存储 (RA-GRS)。This is called Read-Access Geo-Redundant Storage (RA-GRS).

有关 GRS 和 RA-GRS 存储的详细信息,请参阅 Azure 存储复制For more information about both GRS and RA-GRS storage, see Azure Storage replication.

异地复制区域映射:Geo-Replication region mappings:

必须了解异地复制会将数据复制到哪里,这样才能知道,对于要求与存储保持区域关系的数据,应将其实例部署到哪里。It is important to know where your data is geo-replicated, in order to know where to deploy the other instances of your data that require regional affinity with your storage. 有关详细信息,请参阅 Azure 配对区域For more information see Azure Paired Regions.

异地复制定价:Geo-Replication pricing:

异地复制包括在 Azure 存储的当前定价中。Geo-replication is included in current pricing for Azure Storage. 这称为异地冗余存储 (GRS)。This is called Geo-Redundant Storage (GRS). 如果不想对数据进行异地复制,可以为帐户禁用异地复制。If you do not want your data geo-replicated you can disable geo-replication for your account. 这称为本地冗余存储,将按照 GRS 的折扣价格收费。This is called Locally Redundant Storage, and it is charged at a discounted price compared to GRS.

确定是否发生了异地故障转移Determining if a geo-failover has occurred

如果发生了异地故障转移,信息会发布到 Azure 服务运行状况仪表板If a geo-failover occurs, this will be posted to the Azure Service Health Dashboard. 但是,应用程序可以通过监视其存储帐户的地理区域,来实施自动的检测方法。Applications can implement an automated means of detecting this, however, by monitoring the geo-region for their storage account. 这可以用来触发其他恢复操作,如激活存储移往的地理区域中的计算资源。This can be used to trigger other recovery operations, such as activation of compute resources in the geo-region where their storage moved to. 可使用获取存储帐户属性从服务管理 API 来进行查询。You can perform a query for this from the service management API, by using Get Storage Account Properties. 相关的属性包括:The relevant properties are:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime>
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion>
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

VM 磁盘和异地故障转移VM disks and geo-failover

如有关 VM 磁盘的部分中所述,故障转移后无法保证 VM 磁盘之间的数据一致性。As discussed in the section on VM disks, there are no guarantees for data consistency across VM disks after a failover. 为确保备份正确,应使用 Data Protection Manager 等备份产品来备份和还原应用程序数据。To ensure correctness of backups, a backup product such as Data Protection Manager should be used to back up and restore application data.

数据库Database

SQL 数据库SQL Database

Azure SQL 数据库提供两种类型的恢复:异地还原和活动异地复制。Azure SQL Database provides two types of recovery: Geo-Restore and Active Geo-Replication.

异地还原Geo-Restore

异地还原也适用于基本、标准和高级数据库。Geo-Restore is also available with Basic, Standard, and Premium databases. 当数据库由于它所在的区域发生事故而不可用时,异地还原会提供默认的恢复选项。It provides the default recovery option when the database is unavailable because of an incident in the region where your database is hosted. 与时间点还原一样,异地还原依赖于异地冗余的 Azure 存储中的数据库备份。Similar to Point-In-Time Restore, Geo-Restore relies on database backups in geo-redundant Azure storage. 它会从异地复制的备份副本中还原,因此可以灵活应对主要区域中的存储中断。It restores from the geo-replicated backup copy, and therefore is resilient to the storage outages in the primary region. 有关详细信息,请参阅还原 Azure SQL 数据库或故障转移到辅助数据库For more details, see Restore an Azure SQL Database or failover to a secondary.

活动异地复制Active Geo-Replication

活动异地复制适用于所有数据库层。Active Geo-Replication is available for all database tiers. 它专为恢复要求超出了异地还原的能力的应用程序而设计。It’s designed for applications that have more aggressive recovery requirements than Geo-Restore can offer. 使用活动异地复制,最多可以在不同区域中的服务器上创建四个可读辅助数据库。Using Active Geo-Replication, you can create up to four readable secondaries on servers in different regions. 可以启动到任何辅助数据库的故障转移。You can initiate failover to any of the secondaries. 此外,活动异地复制可用于支持应用程序升级或重定位方案,以及只读工作负荷的负载均衡。In addition, Active Geo-Replication can be used to support the application upgrade or relocation scenarios, as well as load balancing for read-only workloads. 有关详细信息,请参阅配置异地复制故障转移到辅助数据库For details, see configure Geo-Replication and to fail over to the secondary database. 有关如何设计和实现应用程序和应用程序升级而无需停机的详细信息,请参阅使用 SQL 数据库中的活动异地复制功能为云灾难恢复设计应用程序使用 SQL 数据库活动异地复制管理云应用程序的滚动升级Refer to Design an application for cloud disaster recovery using Active Geo-Replication in SQL Database and Managing rolling upgrades of cloud applications using SQL Database Active Geo-Replication for details on how to design and implement applications and applications upgrade without downtime.

虚拟机上的 SQL ServerSQL Server on Virtual Machines

可以使用各种选项对 Azure 虚拟机中运行的 SQL Server 2012(和更高版本)实现恢复和高可用性目的。A variety of options are available for recovery and high availability for SQL Server 2012 (and later) running in Azure Virtual Machines. 有关详细信息,请参阅 Azure 虚拟机中 SQL Server 的高可用性和灾难恢复For more information, see High availability and disaster recovery for SQL Server in Azure Virtual Machines.

其他 Azure 平台服务Other Azure platform services

在尝试于多个 Azure 区域运行云服务时,必须考虑每个依赖项的含义。When attempting to run your cloud service in multiple Azure regions, you must consider the implications for each of your dependencies. 在以下部分中,该服务特定的指南假设你在备用 Azure 数据中心中一定使用相同的 Azure 服务。In the following sections, the service-specific guidance assumes that you must use the same Azure service in an alternate Azure datacenter. 这同时涉及到配置和数据复制任务。This involves both configuration and data-replication tasks.

备注

在某些情况下,这些步骤有助于缓解服务特定的中断,而不是整个数据中心的中断事件。In some cases, these steps can help to mitigate a service-specific outage rather than an entire datacenter event. 从应用程序的角度而言,服务特定的中断可能只是受到限制,需要临时会服务迁移到备用 Azure 区域。From the application perspective, a service-specific outage might be just as limiting and would require temporarily migrating the service to an alternate Azure region.

服务总线Service Bus

Azure 服务总线使用不跨越 Azure 区域的唯一命名空间。Azure Service Bus uses a unique namespace that does not span Azure regions. 因此,首要要求是在备用区域中设置必要的服务总线命名空间。So the first requirement is to setup the necessary service bus namespaces in the alternate region. 但是,对于排队消息的持久性,也有一些注意事项。However, there are also considerations for the durability of the queued messages. 有几种在 Azure 区域间复制消息的策略。There are several strategies for replicating messages across Azure regions. 有关这些复制策略和其他灾难恢复策略的详细信息,请参阅使应用程序免受服务总线中断和灾难影响的最佳实践For the details on these replication strategies and other disaster recovery strategies, see Best practices for insulating applications against Service Bus outages and disasters. 有关其他可用性注意事项,请参阅服务总线(可用性)For other availability considerations, see Service Bus (Availability).

应用服务App Service

要将 Azure 应用服务应用程序(如 Web 应用或移动应用)迁移到辅助 Azure 区域,必须有该网站可供发布的备份。To migrate an Azure App Service application, such as Web Apps or Mobile Apps, to a secondary Azure region, you must have a backup of the website available for publishing. 如果中断不涉及整个 Azure 数据中心,则也许可以使用 FTP 下载站点内容的最新备份。If the outage does not involve the entire Azure datacenter, it might be possible to use FTP to download a recent backup of the site content. 然后,在备用区域创建新的应用,除非之前已执行此操作来保留容量。Then create a new app in the alternate region, unless you have previously done this to reserve capacity. 将站点发布到新区域,然后进行必要的配置更改。Publish the site to the new region, and make any necessary configuration changes. 这些更改可能包括数据库连接字符串或其他区域特定的设置。These changes could include database connection strings or other region-specific settings. 如有必要,请添加站点的 SSL 证书,并更改 DNS CNAME 记录,以使自定义域名指向重新部署的 Azure Web 应用 URL。If necessary, add the site’s SSL certificate and change the DNS CNAME record so that the custom domain name points to the redeployed Azure Web App URL.

HDInsightHDInsight

与 HDInsight 关联的数据默认存储在 Azure Blob 存储中。The data associated with HDInsight is stored by default in Azure Blob Storage. HDInsight 要求 Hadoop 群集处理 MapReduce 作业必须与包含所分析数据的存储帐户位于同一区域中。HDInsight requires that a Hadoop cluster processing MapReduce jobs must be co-located in the same region as the storage account that contains the data being analyzed. 假如你使用可用于 Azure 存储的区域异地复制功能,则如果主要区域因为某些原因而无法使用,可以访问复制到次要区域的数据。Provided you use the geo-replication feature available to Azure Storage, you can access your data in the secondary region where the data was replicated if for some reason the primary region is no longer available. 可以在数据复制到的区域中创建新的 Hadoop 群集并继续处理这些数据。You can create a new Hadoop cluster in the region where the data has been replicated and continue processing it. 有关其他可用性注意事项,请参阅 HDInsight(可用性)For other availability considerations, see HDInsight (Availability).

SQL 报告SQL Reporting

目前,要从 Azure 区域的损失中恢复,需要有多个位于其他 Azure 区域的 SQL 报告实例。At this time, recovering from the loss of an Azure region requires multiple SQL Reporting instances in different Azure regions. 这些 SQL 报告实例应当访问相同的数据,且该数据应当有自己的恢复计划,来处理灾难情况。These SQL Reporting instances should access the same data, and that data should have its own recovery plan in the event of a disaster. 还可以为每个报表维护 RDL 文件的外部备份副本。You can also maintain external backup copies of the RDL file for each report.

媒体服务Media Services

Azure 媒体服务对于编码和流有不同的恢复方法。Azure Media Services has a different recovery approach for encoding and streaming. 通常,在区域中断期间,流更为重要。Typically, streaming is more critical during a regional outage. 为对此做好准备,应在两个不同的 Azure 区域中各有一个媒体服务帐户。To prepare for this, you should have a Media Services account in two different Azure regions. 这两个区域都应有编码的内容。The encoded content should be located in both regions. 在故障期间,可以将流式流量重定向到备用区域。During a failure, you can redirect the streaming traffic to the alternate region. 编码可在任意 Azure 区域执行。Encoding can be performed in any Azure region. 如果编码对时间敏感,如在现场活动处理期间,必须准备好如何在故障期间向备用数据中心提交代码。If encoding is time-sensitive, for example during live event processing, you must be prepared to submit jobs to an alternate datacenter during failures.

虚拟网络Virtual network

配置文件是在备用 Azure 区域设置虚拟网络的最快速方式。Configuration files provide the quickest way to set up a virtual network in an alternate Azure region. 在主要 Azure 区域配置虚拟网络之后,将当前网络的虚拟网络设置导出到网络配置文件。After configuring the virtual network in the primary Azure region, export the virtual network settings for the current network to a network configuration file. 如果主要区域发生中断,则从存储的配置文件还原虚拟网络In the event of an outage in the primary region, restore the virtual network from the stored configuration file. 然后,配置其他云服务、虚拟机或跨界设置以使用新的虚拟网络。Then configure other cloud services, virtual machines, or cross-premises settings to work with the new virtual network.

灾难恢复清单Checklists for disaster recovery

云服务清单Cloud Services checklist

  1. 查看本文档的“云服务”部分。Review the Cloud Services section of this document.
  2. 创建跨区域的灾难恢复策略。Create a cross-region disaster recovery strategy.
  3. 了解在备用区域保留容量的利弊。Understand trade-offs in reserving capacity in alternate regions.
  4. 使用流量路由工具,如 Azure 流量管理器。Use traffic routing tools, such as Azure Traffic Manager.

虚拟机清单Virtual Machines checklist

  1. 查看本文档的“虚拟机”部分。Review the Virtual Machines section of this document.
  2. 使用 Azure 备份创建应用程序一致的跨区域备份。Use Azure Backup to create application consistent backups across regions.

存储清单Storage checklist

  1. 查看本文档的“存储”部分。Review the Storage section of this document.
  2. 不要禁用存储资源的异地复制。Do not disable geo-replication of storage resources.
  3. 了解故障转移时用于异地复制的备用区域。Understand alternate region for geo-replication in the event of failover.
  4. 为用户控制的故障转移策略创建自定义备份策略。Create custom backup strategies for user-controlled failover strategies.

SQL 数据库清单SQL Database checklist

  1. 查看本文档的“SQL 数据库”部分。Review the SQL Database section of this document.
  2. 根据情况使用异地还原异地复制Use Geo-Restore or Geo-Replication as appropriate.

虚拟机上的 SQL Server 清单SQL Server on Virtual Machines checklist

  1. 查看本文档的“虚拟机上的 SQL Server”部分。Review the SQL Server on Virtual Machines section of this document.
  2. 使用跨区域 AlwaysOn 可用性组或数据库镜像。Use cross-region AlwaysOn Availability Groups or database mirroring.
  3. 也可以使用备份和还原到 Blob 存储。Alternately use backup and restore to blob storage.

服务总线清单Service Bus checklist

  1. 查看本文档的“服务总线”部分。Review the Service Bus section of this document.
  2. 在备用区域中配置服务总线命名空间。Configure a Service Bus namespace in an alternate region.
  3. 考虑自定义跨区域消息的复制策略。Consider custom replication strategies for messages across regions.

应用服务清单App Service checklist

  1. 查看本文档的“应用服务”部分。Review the App Service section of this document.
  2. 在主要区域外部维护站点备份。Maintain site backups outside of the primary region.
  3. 如果发生局部中断,则尝试使用 FTP 检索当前站点。If outage is partial, attempt to retrieve current site with FTP.
  4. 计划将站点部署到备用区域中的新站点或现有站点。Plan to deploy the site to new or existing site in an alternate region.
  5. 计划对应用程序和 DNS CNAME 记录的配置更改。Plan configuration changes for both application and DNS CNAME records.

HDInsight 清单HDInsight checklist

  1. 查看本文档的“HDInsight”部分。Review the HDInsight section of this document.
  2. 使用复制的数据在区域中创建新的 Hadoop 群集。Create a new Hadoop cluster in the region with replicated data.

SQL 报告清单SQL Reporting checklist

  1. 查看本文档的“SQL 报告”部分。Review the SQL Reporting section of this document.
  2. 在另一个区域维护备用 SQL 报告实例。Maintain an alternate SQL Reporting instance in a different region.
  3. 维护单独的计划以将目标复制到该区域。Maintain a separate plan to replicate the target to that region.

媒体服务清单Media Services checklist

  1. 查看本文档的“媒体服务”部分。Review the Media Services section of this document.
  2. 在备用区域创建媒体服务帐户。Create a Media Services account in an alternate region.
  3. 在两个区域对相同的内容进行编码,以支持流式故障转移。Encode the same content in both regions to support streaming failover.
  4. 在发生服务中断时,将编码作业提交到备用区域。Submit encoding jobs to an alternate region in the event of a service disruption.

虚拟网络清单Virtual Network checklist

  1. 查看本文档的“虚拟网络”部分。Review the Virtual Network section of this document.
  2. 使用导出的虚拟网络设置,在另一个区域重新创建该虚拟网络。Use exported virtual network settings to re-create it in another region.