你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure IoT 中心是云中托管的托管服务，充当 IoT 应用程序与其附加设备之间的通信的中心消息中心。
使用 Azure 时，可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
本文介绍如何使IoT 中心能够灵活应对各种潜在的中断和问题，包括暂时性故障、可用性区域中断和区域中断。 它还介绍了如何使用备份从其他类型的问题中恢复，并突出显示有关IoT 中心服务级别协议（SLA）的一些关键信息。
提高可靠性的生产部署建议
对于生产工作负荷，建议遵循以下建议：
- 在支持计算和数据组件的区域冗余的区域中部署 IoT 中心。 有关详细信息，请参阅 要求。
- 在所有与IoT 中心通信的设备和应用程序中实现适当的重试模式。
- 设计设备重新连接逻辑，以处理瞬时故障和服务切换。 有关详细信息，请参阅 管理设备重新连接以创建可复原的应用程序。
- 对于更大的规模部署，请遵循以下建议：
- 实施指数退避和基于抖动的重试模式，以帮助在设备和应用程序重新连接到IoT 中心时，避免因服务端故障转移或网络中断而引发的重新连接风暴。
- 了解IoT 中心服务配额和限制，并规划解决方案如何处理它们。 通过尽早考虑服务端限制行为、连接限制和吞吐量单元注意事项，可以设计解决方案，以实现可预测的可伸缩性，并避免随着车队的增长而进行体系结构重构。 有关其他指南，请参阅 IoT 中心 缩放和配额。
- 将Azure IoT 中心与 Azure IoT 中心 设备预配服务（DPS）结合使用。 DPS 支持跨一个或多个中心进行安全、零接触载入和设备分配。 即使你预计不会有大型机队，通过从一开始就整合 DPS，你的设备制造和入门操作流程可以扩展，而无需在以后进行固件或基础设施的更改。 有关详细信息，请参阅 使用 DPS 大规模部署 IoT 解决方案。
- 请考虑使用 DPS 分配策略跨多个IoT 中心实例分配设备，以提高可用性和区域复原能力。 此方法可实现引入容量的水平缩放，并支持将来的机群增长，而无需重新预配设备。
可靠性体系结构概述
创建 IoT 中心时，部署 IoT 中心 资源，其中包括管理和与设备通信所需的所有功能。 IoT 中心的主要组件包括：
设备标识注册表： 一个数据库，用于存储可连接到 IoT 中心的设备和模块的相关信息。 每个设备必须在标识注册表中具有一个条目，然后才能进行连接。 有关详细信息，请参阅了解 IoT 中心的标识注册表。
Messaging components： IoT 中心处理设备和后端应用程序之间的双向消息传送，包括设备到云遥测、云到设备命令和直接方法调用。
设备孪生： 存储设备状态信息的 JSON 文档，包括元数据、配置和条件。 设备和后端应用程序可以读取和更新设备孪生。
出于可靠性目的，IoT 中心组件分为两个组：
计算组件： 管理设备连接、对请求进行身份验证、路由消息和处理直接方法调用。 这些组件决定了IoT 中心接受和处理请求的能力。
数据组件： 存储设备标识注册表、设备孪生和设备到云的消息。 这些组件确定数据可用性和持久性。
这一区别很重要，因为 不同的区域支持这些组件的不同类型的冗余 。
与其他服务集成
可以将IoT 中心与Azure设备注册表集成。 如果使用此方法，请查看 Azure Device Registry 中的 Reliability以了解这两个服务的可靠性。
如果使用 IoT 中心 设备预配服务（DPS）进行设备预配，则解决方案的可靠性也取决于 DPS。 有关详细信息，请参阅IoT 中心设备预配服务高可用性和灾难恢复。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅有关处理暂时性故障的建议。
IoT 中心提供相当高的运行时间保证，但暂时性故障可能发生在任何分布式计算平台中。 若要处理暂时性故障，请在与云应用程序交互的组件中构建适当的 重试模式 。
对于大规模部署，最好使用随机重试抖动。 抖动有助于在中心分区之间分配负载，并降低在大规模重新连接事件期间出现限流的可能性。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上分开的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
IoT 中心支持两种不同的可用性区域支持：
数据的区域冗余，它会自动在多个可用性区域之间复制用于存储设备标识注册表和设备到云消息的基础存储组件的数据。
计算的区域冗余，在负责管理设备和路由消息的组件中提供复原能力。
当某个区域支持这两种类型的区域冗余时，关键服务数据（包括设备标识注册表）在区域内的可用性区域中同步复制。 因此，在发生单区域故障时，不会丢失任何数据，服务会自动将设备连接和消息流量重新路由到正常区域。 尽管在故障转移事件期间，处理中的请求可能会暂时受到影响，但服务的连续性得以维护，通常设备重试逻辑可以确保恢复。
要求
区域支持： IoT 中心的可用性区域支持类型取决于其部署的区域。
| 区域 | 数据的区域冗余 | 计算的区域冗余 |
|---|---|---|
| Australia East |
|
|
| Brazil South |
|
|
| 加拿大中部 |
|
|
| 印度中部 |
|
|
| 美国中部 |
|
|
| 美国东部 |
|
|
| 法国中部 |
|
|
| 德国中西部 |
|
|
| 日本东部 |
|
|
| 韩国中部 |
|
|
| 北欧 |
|
|
| 挪威东部 |
|
|
| 卡塔尔中部 |
|
|
| 美国中南部 |
|
|
| 东南亚 |
|
|
| 英国南部 |
|
|
| 西欧 |
|
|
| 西部美国 2 |
|
|
| 美国西部 3 |
|
|
在不在此列表中的区域创建的 IoT 中心无法抵御区域性中断。
成本
使用 IoT 中心 的区域冗余无需额外费用。
配置可用性区域支持
IoT 中心资源在 supported regions 中部署时自动支持区域冗余。 无需进一步配置。
所有区域正常时的行为
配置 IoT 中心 资源实现区域冗余时，本部分将介绍所预期的情况，并且所有可用区都正常运行。
区域之间的数据复制： 当 IoT 中心部署在支持数据区域冗余的区域时，数据更改会自动在可用性区域之间复制。 复制同步进行。
区域之间的流量路由： 当 IoT 中心部署在支持计算组件区域冗余的区域时，请求将路由到其中一个可用性区域中服务的主实例。 Azure自动选择活动实例和区域。
区域故障期间的行为
本节描述当为区域冗余配置IoT 中心资源时，以及在发生可用性区域中断时，可能会遇到的情况。
- 检测和响应： IoT 中心 服务负责检测可用区中的故障。 无需执行任何操作即可启动区域故障转移。
- Notification：当区域关闭时，Microsoft不会自动通知你。 但是，可以使用 Azure 资源运行状况 监视单个资源的运行状况，并且可以设置 资源运行状况 警报来通知问题。 还可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。
活动请求： 在区域故障期间，可能会删除活动请求。 客户端和设备应有足够的 重试逻辑 来实现来处理暂时性故障。
预期数据丢失： 当 IoT 中心部署在支持数据区域冗余的区域时，区域故障不应导致任何数据丢失。
预期停机时间： 当您的 IoT 中心 部署在支持计算和数据组件区域冗余的区域时，区域故障不应导致 IoT 中心 资源停机。
流量重路由： 当您的 IoT 中心 部署在支持计算组件区域冗余的地区时，IoT 中心 可以检测到可用性区的丢失。 然后，任何新请求都会自动重定向到处于正常可用性区域之一的服务的新主实例。
区域恢复
当可用性区域恢复时，IoT 中心自动还原可用性区域中的实例，并按正常方式重新路由实例之间的流量。
测试区域故障
由于 IoT 中心 完全管理可用区故障的流量路由、故障转移和故障恢复，因此无需验证可用区故障过程或提供任何进一步的输入。
对区域范围的故障的复原能力
IoT 中心是单区域服务。 如果区域不可用，则IoT 中心资源也不可用。 出于灾难恢复目的，虽然 IoT 中心 支持将数据异步复制到配对的 Azure 区域，但并未为设备连接内置跨区域故障转移。
如果资源位于未配对区域，则 Microsoft 不会跨区域复制配置和数据，并且没有内置的跨区域故障转移。 但是，可以将单独的资源部署到多个区域。 在此方案中，你负责管理复制、流量分发和故障转移。
如果您的 IoT 中心位于非配对区域，或者默认的复制和故障转移行为无法满足您的需求，请设计并实施自定义多区域故障转移策略，包括以下步骤：
- 在不同的Azure区域中预配辅助IoT 中心。
- 实现终结点重定向机制，以在需要时将设备定向到备用区域。 例如，可以提前在这两个中心预配每个设备，并在设备上配置两个连接字符串，以便他们可以在需要时在中心之间切换。
由Microsoft管理的故障转移至配对区域
如果资源位于 配对的区域，IoT 中心的数据将复制到配对区域。 此方法旨在支持灾难恢复。 如果 IoT 中心的主要区域中出现区域故障，则无需采取任何操作即可使设备连接在配对区域中继续。
故障转移类型
在以下情况下，IoT 中心可能会故障转移到配对区域：
客户发起的故障转移： 可以自行触发对配对区域的手动故障转移，无论该区域是否遇到停机。 可以使用这种方法执行计划的故障切换和演练。
Microsoft发起的故障转移：如果区域丢失，Microsoft可以启动 IoT 中心到配对区域的故障转移。 但是，Microsoft不太可能启动故障转移，除非经过较长时间的延迟，并在尽力而为的基础上进行。 IoT 中心资源的故障转移可能发生在与其他 Azure 服务的故障转移不同的时间。 此过程是默认选项，无需你进行干预。
要求
- 区域支持： 仅在配对的区域支持默认复制和故障转移。
- Tier：配对区域复制和故障转移选项适用于所有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 解决方案的整体灾难恢复（DR）目标可能是可行的。
对于这两种故障转移类型，IoT 中心实例的完全限定域名在故障转移后保持不变，这意味着连接字符串也保持不变。 但是，由于基础 IP 地址发生更改，客户端必须在故障转移后等待域名系统（DNS）记录更新才能访问 IoT 中心。
重要
IoT 中心 SDK 不会缓存IoT hub的 IP 地址。 与 SDK 交互的用户代码也不应缓存 IoT 中心的 IP 地址。
由于这些因素，可使用以下函数表示在故障转移过程之后针对 IoT 中心实例执行的运行时操作变为完全正常运行的时间：
恢复所需时间 = RTO [客户启动的故障转移为 10 分钟到 2 小时，Microsoft 发起的故障转移为 2 到 26 小时] + DNS传播时间的延迟 + 客户端应用刷新任何缓存的 IoT 中心 IP 地址所需的时间
流量重路由：在故障转移过程中，IoT 中心 会更新 DNS 记录以指向成对的区域。 所有后续请求都会发送到配对区域。
IoT 中心的故障转移操作完成后，预计设备和后端应用程序的所有操作可以继续正常工作，而无需手动干预。 这种连续性可确保设备到云的消息可继续工作，并且整个设备注册表保持不变。 如果通过Azure 事件网格发出事件，则只要这些事件网格订阅继续可用，就可以通过之前配置的同一订阅使用这些事件。 自定义终结点无需进一步处理。
需要故障转移后配置
根据你将 IoT 中心消息路由到的位置，可能需要在故障转移事件完成后执行额外的步骤。
Azure 事件中心：故障转移后，IoT 中心内置事件终结点的 Event Hubs 兼容名称和终结点会发生更改。 发生此更改是因为事件中心客户端无法查看IoT 中心事件。
使用事件中心客户端或事件处理程序主机从内置终结点接收遥测消息时，使用 IoT 中心的连接字符串来建立连接。 此方法可确保后端应用程序继续工作，而无需在故障转移后进行手动干预。
如果直接在应用程序中使用与事件中心兼容的名称和终结点，那么在故障转移后，您需要 提取与事件中心兼容的新终结点 才能继续操作。 若要检索终结点和名称，可以使用Azure门户或 .NET SDK：
Azure Functions 和 Azure 流分析： 如果使用 Azure Functions 或 Azure 流分析 连接到内置事件终结点，则必须按照上述项目符号中概述的相同过程更新函数或作业连接到的事件中心 Event Hubs 终结点。 然后执行重启操作，因为故障转移后任何事件流偏移量都无效。
Azure 存储：路由到Azure 存储时，请先列出 blob 或文件。 然后循环访问它们，以确保读取所有 Blob 或文件，而无需假设分区。 在Microsoft发起的故障转移或客户发起的故障转移期间，分区范围可能会更改。 可以使用 List Blobs API枚举 blob 的列表或使用 List Azure Data Lake Storage API获取文件列表。 有关详细信息，请参阅Azure 存储作为路由终结点。
区域恢复
若要故障回复到主要区域，可以再次手动触发故障转移操作。 请务必记住对故障转移频率的限制。
如果执行原始故障转移操作是为了从原始主要区域中的长时间中断中恢复，请在主要区域从中断中恢复后执行到主要区域的故障回复。
针对区域故障进行测试
若要模拟区域中断期间的故障，可以触发 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 hub的整个标识注册表。 此数据使用共享访问签名传输到 Azure 存储 blob 容器。 使用此方法可在所控制的 Blob 容器中创建可靠的设备信息备份。 有关详细信息，请参阅批量导入和导出 IoT 中心 设备标识。
还可以导出现有 IoT 中心的 Azure 资源管理器 模板（ARM 模板），用于创建 IoT 中心配置的备份。 有关详细信息，请参阅 使用 ARM 模板手动迁移 IoT 中心。
对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。
服务维护期间的系统弹性能力
Microsoft定期应用服务更新并执行其他维护。 Azure平台会自动处理这些活动，确保维护是无缝且透明的。 除非通过Azure 服务运行状况 计划内维护通知，否则在维护事件期间不会造成停机。
服务级别协议
Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for 联机服务。