你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文介绍 Azure IoT 中心的可靠性支持。 它通过 可用性区域 和 多区域部署涵盖区域内部复原能力。
使用 Azure 时， 可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
评估可靠性选项时，还需要评估以下各项之间的权衡：
- 所需的复原能力级别
- 实施和维护的复杂性
- 实现不同选项的成本
有关详细信息，请参阅 可靠性权衡。
暂时性故障
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。
IoT 中心提供相当高的运行时间保证，但在任何分布式计算平台中都可能发生暂时性故障。 若要处理暂时性故障，请在与云应用程序交互的组件中构建适当的 重试模式 。
可用性区域支持
可用性区域 是每个 Azure 区域内物理上独立的数据中心群组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
IoT 中心支持两种不同的可用性区域支持：
数据的区域冗余，它会自动在多个可用性区域之间复制用于存储设备标识注册表和设备到云消息的基础存储组件的数据。
计算的区域冗余，在负责管理设备和路由消息的组件中提供复原能力。
区域支持
IoT 中心的可用性区域支持类型取决于其部署的区域。
| 区域 | 数据的区域冗余 | 计算的区域冗余 |
|---|---|---|
| 澳大利亚东部 |
|
|
| 巴西南部 |
|
|
| 加拿大中部 |
|
|
| 印度中部 |
|
|
| 美国中部 |
|
|
| 美国东部 |
|
|
| 法国中部 |
|
|
| 德国中西部 |
|
|
| 日本东部 |
|
|
| 韩国中部 |
|
|
| 北欧 |
|
|
| 挪威东部 |
|
|
| 卡塔尔中部 |
|
|
| 美国中南部 |
|
|
| 东南亚 |
|
|
| 英国南部 |
|
|
| 西欧 |
|
|
| 美国西部 2 |
|
|
| 美国西部 3 |
|
|
在不在此列表中的区域创建的 IoT 中心无法抵御区域性中断。
成本
使用 IoT 中心进行区域冗余无需额外付费。
配置可用性区域支持
IoT 中心资源在 受支持的区域中部署时自动支持区域冗余。 无需进一步配置。
常规操作
本部分介绍为 IoT 中心资源配置区域冗余，以及所有可用性区域正常运行时应发生的情况。
区域之间的数据复制： 当 IoT 中心部署在支持数据区域冗余的区域时，数据更改会自动在可用性区域之间复制。 复制同步进行。
区域之间的流量路由： 当 IoT 中心部署在支持计算组件区域冗余的区域时，请求将路由到其中一个可用性区域中服务的主实例。 Azure 会自动选择活动实例和区域。
区域关闭体验
本部分介绍为 IoT 中心资源配置区域冗余，以及可用性区域发生中断时应发生的情况。
- 检测和响应： IoT 中心服务负责检测可用性区域中的故障。 无需执行任何操作即可启动区域故障转移。
通知：Azure IoT 中心在区域关闭时不会通知你。 但是，可以使用 Azure 资源运行状况 监视 IoT 中心的运行状况。 还可以使用 Azure 服务运行状况 来了解 Azure IoT 中心服务的总体运行状况，包括任何区域故障。
针对这些服务设置警报，以接收区域级别问题的通知。 有关详细信息，请参阅 Azure 门户中的“创建服务运行状况警报 ”并 创建和配置资源运行状况警报。
活动请求： 在区域故障期间，可能会删除活动请求。 客户端和设备应有足够的 重试逻辑 来实现来处理暂时性故障。
预期数据丢失： 当 IoT 中心部署在支持数据区域冗余的区域时，区域故障不应导致任何数据丢失。
预期的停机时间： 当 IoT 中心部署在支持计算和数据组件的区域冗余的区域时，区域故障不应导致 IoT 中心资源的停机。
流量重新路由： 当 IoT 中心部署在支持计算组件的区域冗余的区域时，IoT 中心将检测区域丢失情况。 然后，任何新请求都会自动重定向到处于正常可用性区域之一的服务的新主实例。
区域恢复
当可用性区域恢复时，IoT 中心会自动还原可用性区域中的实例，并按正常方式重新路由实例之间的流量。
对区域故障进行测试
由于 IoT 中心完全管理区域故障的流量路由、故障转移和故障回复，因此无需验证可用性区域故障过程，也无需提供任何进一步的输入。
多区域支持
IoT 中心是单区域服务。 如果区域不可用，IoT 中心资源也不可用。
但是，如果资源位于 配对的区域，IoT 中心的数据将复制到配对区域。
在以下情况下，IoT 中心可能会故障转移到配对区域：
客户发起的故障转移： 可以自行触发对配对区域的手动故障转移，无论该区域是否遇到停机。 可以使用这种方法执行计划的故障切换和演练。
Microsoft发起的故障转移： 如果某个区域丢失，Microsoft可以启动 IoT 中心到配对区域的故障转移。 但是，Microsoft 不太可能发起故障转移，除非经过重大延迟和尽最大努力。 IoT 中心资源的故障转移可能与其他 Azure 服务的故障转移发生时间不同。 此过程是默认选项，无需你进行干预。
如果资源位于 非已修复区域中，Microsoft不会跨区域复制配置和数据，并且没有内置的跨区域故障转移。 但是，可以将单独的资源部署到多个区域。 在此方案中，你负责管理复制、流量分发和故障转移。
如果 IoT 中心位于非已修复区域中，或者默认复制和故障转移行为不符合需求，则可以使用 替代的多区域方法 来规划和启动故障转移。
区域支持
仅在配对的区域支持默认复制和故障转移。
要求
配对区域复制和故障转移选项适用于所有 IoT 中心层。
注意事项
不要使用客户发起的故障转移在 Azure 配对区域之间永久迁移中心。 通常，设备位于中心的主要区域附近。 如果将您的中心移动到次要区域，则次要位置中的设备和 IoT 中心之间的操作延迟会增加。
成本
对于配对区域中的中心，跨区域数据复制或故障转移无需额外付费。
如果 IoT 中心位于未经过验证的区域，请参阅 备用多区域方法 ，了解可能的成本信息。
配置复制并准备故障转移
默认情况下，在配对区域中创建 IoT 中心时，会自动配置跨区域数据复制。 此过程是默认选项，无需你进行干预。 在巴西南部和东南亚（新加坡）以外的区域，客户数据不会在部署服务实例的地理位置之外存储或处理。
如果您的 IoT 中心位于巴西南部或东南亚（新加坡）区域，则可以禁用数据复制并选择退出故障切换。 有关详细信息，请参阅“禁用灾难恢复”（DR）。
如果 IoT 中心位于非配对区域中，则你需要规划自己的跨区域复制和故障转移方法。 有关详细信息，请参阅 备用多区域方法。
常规操作
本部分介绍为 IoT 中心配置跨区域复制和故障转移，以及主要区域正常运行时会发生的情况。
区域之间的数据复制： 数据自动复制到配对区域。 复制以异步方式发生，这意味着如果发生故障转移，则预期会丢失某些数据。 未配对区域的 IoT 中心之间没有数据复制。
区域之间的流量路由： 在正常作中，流量仅流向主要区域。
区域故障体验
本节描述了在为 IoT 中心配置跨区域复制和故障转移时，以及在主区域发生中断时，可以期待的情况。
检测和响应： 对主要区域中断进行检测和响应的责任可能不同。
客户发起的故障转移： 你负责检测区域丢失，并确定何时进行故障转移。 有关如何在配对区域之间执行客户启动的故障转移的详细信息，请参阅 为 IoT 中心执行手动故障转移。
你可以执行的客户发起的故障转移或故障回复的频率有限制：
用户每天可以执行两次成功的故障转移操作和两次成功的故障回复操作。
不允许连续的故障转移或故障回复操作。 在这些操作之间，您必须等待一小时。
Microsoft发起的故障转移： 如果主要区域丢失，Microsoft可以决定执行故障转移。 在主要区域丢失后，此过程可能需要几个小时，在某些情况下甚至更长的时间。 IoT 中心资源的故障转移可能不会与其他 Azure 服务同时发生。
活动请求： 主要区域在故障转移期间正在处理的任何请求都可能会丢失。 故障转移完成后，客户端应重试请求。
预期数据丢失： 对于配对的区域，数据以异步方式复制到配对区域。 因此，故障转移后预期会出现一些数据丢失。 此过程适用于 Microsoft 托管的故障转移和客户管理的故障转移。 下表概述了 IoT 中心存储的每种类型的数据的 恢复点目标（RPO）或预期的数据丢失。
数据类型 RPO 标识注册表 0-5 分钟数据丢失 设备孪生数据 0-5 分钟数据丢失 云到设备的消息 1 0-5 分钟数据丢失 父 1 和设备作业 0-5 分钟数据丢失 发送到云端的设备消息 所有未读的消息都丢失 云到设备的反馈消息 所有未读的消息都丢失 1 客户发起的故障转移期间无法恢复云到设备的消息和父作业。
预期的停机时间： 区域故障转移期间的预期停机时间取决于故障转移类型。
客户发起的故障转移：预计大约 10 分钟到 2 小时的停机时间，从区域丢失起，到资源在配对区域中正常运行为止。 正在故障转移的 IoT 中心实例注册的设备数会影响恢复时间。 你预计托管大约 100,000 台设备的中心的恢复时间大约为 15 分钟。
Microsoft 发起的故障转移： 在区域丢失到配对区域中的资源可用之间，预计大约有 2 到 26 小时的停机时间。
较高的恢复时间是因为Microsoft必须代表该区域的所有受影响的客户执行故障转移作。 对于关键系统，应使用客户启动的故障转移来减少停机时间。 但是，如果运行一个不太关键的 IoT 解决方案，可以承受大约一天的停机时间，则可能可以依赖由微软提供的选项来满足 IoT 解决方案的总体灾难恢复目标。
对于这两种故障转移类型，IoT 中心实例的完全限定域名在故障转移后保持不变，这意味着连接字符串也保持不变。 但是，由于基础 IP 地址发生更改，客户端必须在故障转移后等待域名系统（DNS）记录更新才能访问 IoT 中心。
重要
IoT 中心 SDK 不会缓存 IoT 中心的 IP 地址。 与 SDK 交互的用户代码也不应缓存 IoT 中心的 IP 地址。
由于这些因素，可使用以下函数表示在故障转移过程之后针对 IoT 中心实例执行的运行时操作变为完全正常运行的时间：
恢复时间 = 恢复时间目标（RTO）[客户启动的故障转移：10 分钟到 2 小时；Microsoft 发起的故障转移：2 到 26 小时] + DNS 传播延迟 + 客户端应用程序用于刷新任何缓存的 IoT 中心 IP 地址所需的时间
流量重新路由： 在故障转移过程中，IoT 中心将更新 DNS 记录以指向配对区域。 所有后续请求都会发送到配对区域。
IoT 中心的故障转移操作完成后，预计设备和后端应用程序的所有操作可以继续正常工作，而无需手动干预。 这种连续性可确保设备到云的消息可继续工作，并且整个设备注册表保持不变。 如果通过 Azure 事件网格发出事件，则只要这些事件网格订阅继续可用，就可以通过之前配置的同一订阅使用这些事件。 自定义终结点无需进一步处理。
需要故障转移后配置
根据你将 IoT 中心消息路由到的位置，可能需要在故障转移事件完成后执行额外的步骤。
Azure 事件中心：故障转移后，IoT 中心内置事件终结点的事件中心兼容名称和终结点会发生变化。 发生此更改是因为事件中心客户端无法查看 IoT 中心事件。
使用事件中心客户端或事件处理器主机从内置终结点接收遥测消息时， 请使用 IoT 中心的连接字符串 建立连接。 此方法可确保后端应用程序继续工作，而无需在故障转移后进行手动干预。
如果直接在应用程序中使用与事件中心兼容的名称和终结点，那么在故障转移后，您需要 提取与事件中心兼容的新终结点 才能继续操作。 若要检索终结点和名称，可以使用 Azure 门户或 .NET SDK：
Azure Functions 和 Azure 流分析： 如果使用 Azure Functions 或流分析连接到内置事件终结点，则必须按照上述项目符号点中概述的相同过程更新函数或作业连接到的事件中心终结点。 然后执行重启操作，因为故障转移后任何事件流偏移量都无效。
Azure 存储： 路由到 Azure 存储时，请先列出 Blob 或文件。 然后循环访问它们，以确保读取所有 Blob 或文件，而无需假设分区。 在Microsoft发起的故障转移或客户发起的故障转移期间，分区范围可能会更改。 可以使用 List Blobs API 来枚举 Blob 列表，或使用 List Azure Data Lake Storage API 枚举文件列表。 有关详细信息，请参阅 Azure 存储作为路由终结点。
区域恢复
若要故障回复到主要区域，可以再次手动触发故障转移操作。 请务必记住对故障转移频率的限制。
如果执行原始故障转移操作是为了从原始主要区域中的长时间中断中恢复，请在主要区域从中断中恢复后执行到主要区域的故障回复。
测试区域故障
若要模拟区域中断期间的故障，可以触发 IoT 中心的手动故障转移。 但是，由于区域故障转移会导致停机和数据丢失，因此只能在非生产环境中执行测试故障转移。 有关详细信息，请参阅区域停机体验。 请考虑设置测试 IoT 中心实例以定期启动计划的故障转移选项。 定期测试有助于在发生实际灾难时，增强对恢复和使用端到端解决方案的信心与能力。
备选多区域方法
IoT 中心的跨区域故障转移功能不适用于以下方案：
你的 IoT 中心位于未配对的区域。
内置故障转移选项提供的恢复时间或数据丢失无法满足你的业务运行时间目标。
你需要故障转移到不是你的主要区域的配对的区域。
可以设计针对每个设备定制的跨区域故障转移解决方案。 IoT 解决方案中部署拓扑的完整处理超出了本文的范围，但可以考虑多区域部署模型。 在此模型中，主要 IoT 中心和解决方案后端主要在一个 Azure 区域中运行。 辅助 IoT 中心和后端部署在另一个 Azure 区域中。 如果主要区域中的 IoT 中心遇到中断或从设备到主要区域的网络连接中断，则设备使用辅助服务终结点。
预期的停机时间： 此方法的停机时间少于 1 分钟，但实施可能非常复杂。
预期数据丢失： 数据丢失量取决于你使用的特定数据存储以及配置异地复制的方式。
成本： 此方法要求预配至少一个额外的 IoT 中心，从而增加总体成本。
概括而言，若要使用 IoT 中心实现区域故障转移模型，需要采取以下措施：
辅助 IoT 中心和设备路由逻辑： 如果主要区域中的服务中断，设备必须开始连接到次要区域。 由于涉及大多数服务的状态感知性质，解决方案管理员通常会手动触发区域间故障转移过程。 要使新终结点与设备通信，同时保留过程控制权，最佳方式是让它们定期在监护服务中检查是否存在当前活动的终结点。 接待服务可以是使用 DNS 重定向技术（例如 Azure 流量管理器）复制并保持可访问的 Web 应用程序。
注释
流量管理器没有对 IoT 中心的内置支持。 可以为每个 IoT 中心配置自定义流量管理器终结点。 将流量管理器终结点的运行状况探测配置为使用 IoT 中心的终结点。
标识注册表复制： 若要使用，辅助 IoT 中心必须包含可连接到解决方案的所有设备标识。 解决方案应保留设备标识的异地复制备份，并将其上传到辅助 IoT 中心，然后再切换设备的活动终结点。 IoT 中心的设备标识导出功能在此背景下非常有用。 有关详细信息，请参阅了解 IoT 中心的标识注册表。
合并逻辑： 当主要区域再次可用时，必须在次要区域中创建的所有状态和数据迁移回主要区域。 此状态和数据主要与设备标识和应用程序元数据相关，必须与主要 IoT 中心以及主要区域中的任何其他应用程序特定存储合并。
若要简化此步骤，请使用 幂等 操作。 幂等操作可以将副作用降到最低，包括来自最终一致的事件分布的副作用，以及来自事件的重复项目或失序传送的副作用。 此外，应用程序逻辑应设计为容忍潜在的不一致或略微过时状态。 这种情况可能发生，因为系统根据 RPO 进行修复需要额外的时间。
备份
对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅 冗余、复制和备份。
IoT 中心服务支持批量导出作，从而允许导出 IoT 中心的整个标识注册表。 此数据使用共享访问签名传输到 Azure 存储 Blob 容器。 使用此方法，可在所控制的 blob 容器中创建可靠的设备信息备份。 有关详细信息，请参阅 批量导入和导出 IoT 中心设备标识。
还可以导出现有的 IoT 中心的 Azure 资源管理器模板（ARM 模板），以创建 IoT 中心配置的备份。 有关详细信息，请参阅 使用 ARM 模板手动迁移 IoT 中心。
服务级别协议
IoT 中心的服务级别协议（SLA）描述了服务的预期可用性，以及实现该可用性预期必须满足的条件。 若要了解这些条件，请务必查看 联机服务的 SLA。