IoT 中樞高可用性和災害復原
要實作具有恢復能力的 IoT 解決方案，架構設計人員、開發人員和企業主首先必須為其建置的解決方案定義運作時間目標。 這些目標主要可根據各種案例的特定營運目標來定義。 在此內容中，Azure 商務持續性技術指引 一文會說明有助於您思考商務持續性和災害復原的一般架構。 Azure 應用程式的災害復原與高可用性文件針對 Azure 應用程式要達到高可用性 (HA) 和災害復原 (DR) 能力的策略，提供了相關架構指引。
本文將討論由 IoT 中樞服務提供的特定 HA 和 DR 功能。 本文討論的廣泛領域如下：
- 內部區域 HA
- 跨區域 DR
- 達成跨區域 HA
根據您為 IoT 解決方案定義的運作時間目標，您應判斷本文所述的哪一個選項最符合您的營運目標。 若要將其中任何 HA/DR 替代方案納入您的 IoT 解決方案中，必須先謹慎評估下列事項的取捨：
- 您需要的復原層級
- 實作和維護的複雜度
- COGS 影響
內部區域 HA
IoT 中樞服務可在絕大多數的服務層級中實作備援功能，以提供內部區域 HA。 利用這些備援功能，即可達成 IoT 中樞服務所發佈的 SLA。 IoT 解決方案的開發人員無須執行額外的工作，即可利用這些高可用性功能。 雖然 IoT 中樞提供了相當高的運作時間保證，但分散式運算平台仍可能發生暫時性的失敗。 如果您剛開始著手將解決方案從內部部署解決方案移轉至雲端，則應將焦點從「平均失敗時間」的最佳化，轉移至「平均復原時間」的最佳化。 換句話說，在混合環境中使用雲端時，應將暫時性失敗視為正常現象。 您必須在與雲端應用程式互動的元件中內建適當的重試模式，才能處理暫時性失敗。
可用性區域
IoT 中樞支援 Azure 可用性區域。 可用性區域是高可用性供應項目，可保護您的應用程式和資料不受資料中心失敗所影響。 具有可用性區域 (Zone) 支援的區域 (Region) 是由支援該區域 (Region) 的三個區域 (Zone) 所組成。 每個區域都會在具有獨立電源、冷卻和網路的唯一實體位置中提供一或多個資料中心。 此設定會在區域內提供複寫和備援。
可用性區域提供兩個優點：資料復原和更順暢的部署。
「資料復原」來自將底層儲存體服務取代為可用性區域支援的儲存體。 資料復原對於 IoT 解決方案很重要，因為這些解決方案通常會在複雜、動態且不確定的環境中運作，若在其中發生失敗或中斷，很可能就會產生嚴重的後果。 無論 IoT 解決方案是否支援製造現場、零售或餐廳環境、醫療保健系統或基礎設施，都需要資料的可用性和品質，才能從失敗中復原，並提供可靠且一致的服務。
「更順暢的部署」來自將底層資料中心硬體取代為支援可用性區域的較新硬體。 這些硬體改善可讓客戶因裝置中斷連線並重新連線，以及其他部署相關停機時間所受到的影響降到最低。 基於安全性考量並提供功能改善，IoT 中樞工程小組每月都會對每個 IoT 中樞部署多個更新。 可用性區域支援的硬體會分割成 15 個更新網域，如此可讓每個更新進行得更順暢，並將對工作流程產生的影響降到最低。 如需更新網域的詳細資訊，請參閱可用性設定組。
對 IoT 中樞的可用性區域 (Zone) 支援會針對下列 Azure 區域 (Region) 中建立的新 IoT 中樞資源自動啟用：
| 區域 | 資料復原 | 更順暢的部署 |
|---|---|---|
| 澳大利亞東部 | 
|
|
| 巴西南部 |
|
|
| 加拿大中部 |
|
|
| 印度中部 | 
|
|
| 美國中部 |
|
|
| 美國東部 |
|
|
| 法國中部 |
|
|
| 德國中西部 |
|
|
| 日本東部 |
|
|
| 南韓中部 |
|
|
| 北歐 |
|
|
| 挪威東部 |
|
|
| 卡達中部 |
|
|
| 美國中南部 |
|
|
| 東南亞 |
|
|
| 英國南部 |
|
|
| 西歐 |
|
|
| 美國西部 2 |
|
|
| 美國西部 3 |
|
|
跨區域 DR
在某些罕見的情況下，資料中心有可能因為停電或其他有關於實體資產的失效，而長時間中斷運作。 這類事件很罕見，一旦發生，前述的內部區域高可用性功能不一定能發揮效用。 IoT 中樞提供了多種可從這類長時間中斷運作復原的解決方案。
在這種情況下，客戶可用的復原選項包括 Microsoft 起始的容錯移轉和手動容錯移轉。 兩者的基本差異在於，前者由 Microsoft 所起始，後者則由使用者起始。 此外，相較於 Microsoft 起始的容錯移轉選項，手動容錯移轉所提供的復原時間目標 (RTO) 較低。 下列各節將討論每個選項所提供的特定 RTO。 從 IoT 中樞的主要區域執行中樞容錯移轉的其中一個選項在施行時，該中樞在對應的 Azure 地理配對區域中將會完整運作。
這兩個容錯移轉選項分別提供下列復原點目標 (RPO)：
| 資料類型 | 復原點目標 (RPO) |
|---|---|
| 身分識別登錄 | 0 到 5 分鐘的資料遺失 |
| 裝置對應項資料 | 0 到 5 分鐘的資料遺失 |
| 雲端到裝置的訊息1 | 0 到 5 分鐘的資料遺失 |
| 父系1和裝置作業 | 0 到 5 分鐘的資料遺失 |
| 裝置到雲端的訊息 | 所有未讀取的訊息都會遺失 |
| 雲端到裝置的意見反應訊息 | 所有未讀取的訊息都會遺失 |
1雲端到裝置的訊息和父代作業均不會在手動容錯移轉的過程中復原。
IoT 中樞的容錯移轉作業完成後，從裝置和後端應用程式執行的所有作業都應會繼續運作，而不需要手動介入。 這表示您的裝置到雲端訊息應該會繼續運作，而且整個裝置登錄會維持不變。 透過 Event Grid 發出的事件可透過先前設定的相同訂用帳戶來取用，只要這些 Event Grid 訂用帳戶仍然可用即可。 自訂端點不需要其他處理。
警告
- 在容錯移轉之後，IoT 中樞內建事件端點的事件中樞相容名稱和端點都會變更。 在使用事件中樞用戶端或事件處理器主機接收來自內建端點的遙測訊息時，您應使用 IoT 中樞連接字串來建立連線。 這可以確保您的後端應用程式在容錯移轉後可繼續運作，而無需手動介入。 如果您直接在應用程式中使用事件中樞相容名稱和端點，則必須在容錯移轉之後擷取新的事件中樞相容端點，以繼續作業。 如需詳細資訊，請參閱手動容錯移轉和事件中樞。
- 如果您使用 Azure Functions 或 Azure 串流分析來連線內建的事件端點，您可能需要執行 [重新啟動]。 這是因為容錯移轉期間先前的位移不再有效。
- 路由傳送至儲存體時，我們建議列出 Blob 或檔案，然後加以逐一查看，以確保會讀取所有 Blob 或檔案，而不需進行任何分割假設。 分割範圍可能會在 Microsoft 起始的容錯移轉或手動容錯移轉期間變更。 您可使用列出 Blob API 來列舉 Blob 清單，或使用列出 ADLS Gen2 API 來列舉檔案清單。 若要深入瞭解，請參閱 Azure 儲存體作為路由端點。
Microsoft 起始的容錯移轉
Microsoft 起始的容錯移轉會由 Microsoft 在少數的情況下施行，以將所有 IoT 中樞從受影響的區域容錯移轉至對應的地理配對區域。 此程序是預設選項，且使用者無須介入。 Microsoft 有權決定施行此選項的時機。 施行此機制時，無須在使用者的中樞容錯移轉之前取得使用者的同意。 Microsoft 起始的容錯移轉具有 2 到 26 小時的復原時間目標 (RTO)。
RTO 之所以偏高，是因為 Microsoft 必須代表該區域中所有受影響的客戶執行容錯移轉作業。 如果您執行的 IoT 解決方案較不重要，而且可承受大約一天的停機時間，則可依賴此選項來滿足您 IoT 解決方案的整體災害復原目標。 執行階段作業在此程序觸發後進入完整運作狀態所需的總時間，詳述於「復原時間 」一節。
只有將 IoT 中樞部署到巴西南部和東南亞 (新加坡) 區域的使用者能夠退出此功能。 如需詳細資訊，請參閱停用災害復原。
注意
Azure IoT 中樞不會在部署服務執行個體的地理位置之外儲存或處理客戶資料。 如需詳細資訊，請參閱 Azure 中的跨區域複寫。
手動容錯移轉
如果 Microsoft 起始的容錯移轉所提供的 RTO 不符合您的業務運作時間目標，請考慮使用手動容錯移轉，以自行觸發容錯移轉程序。 使用此選項的 RTO 可能介於 10 分鐘到數小時之間。 此 RTO 目前取決於已對要進行容錯移轉的 IoT 中樞執行個體註冊的裝置數目。 對於大約裝載了 100,000 個裝置的中樞，預期的 RTO 將是 15 分鐘左右。 執行階段作業在此程序觸發後進入完整運作狀態所需的總時間，詳述於「復原時間 」一節。
無論主要區域是否發生停機狀況，手動容錯移轉選項都一律可供使用。 因此，此選項有可能用來執行計劃性容錯移轉。 計劃性容錯移轉的使用範例之一，是執行定期的容錯移轉演練。 但要提醒您，計劃性容錯移轉作業會在此選項的 RTO 所定義的期間對中樞造成停機時間，同時也會導致前述 RPO 資料表所定義的資料遺失。 您可以考慮設定測試 IoT 中樞執行個體，以定期執行計劃性容錯移轉選項，以利確保您的端對端解決方案在真正的災害發生時能夠啟動並運作。
針對 2017 年 5 月 18 日之後建立的 IoT 中樞，使用手動容錯移轉無需額外費用
如需逐步指示，請參閱教學課程：執行 IoT 中樞的手動容錯移轉
手動容錯移轉和事件中樞
在手動容錯移轉之後，IoT 中樞內建事件端點的事件中樞相容名稱和端點都會變更。 這是因為事件中樞用戶端無法看見 IoT 中樞事件。 其他雲端式用戶端也是如此，例如 Functions 和 Azure 串流分析。 若要擷取端點和名稱，您可以使用 Azure 入口網站或 .NET SDK。
使用入口網站
如需使用入口網站來擷取事件中樞相容端點和事件中樞相容名稱的詳細資訊，請參閱連線到內建端點。
使用 .NET SDK
若要使用 IoT 中樞連接字串來重新擷取事件中樞相容端點，請使用位於 https://github.com/Azure/azure-sdk-for-net/tree/main/samples/iothub-connect-to-eventhubs 的範例。 此程式碼範例會使用連接字串來取得新的事件中樞端點，並重新建立連線。 您必須已安裝 Visual Studio。
執行測試演練
您不應對正在實際執行環境中使用的 IoT 中樞執行測試演練。
請勿使用手動容錯移轉將 IoT 中樞移轉至不同的區域
手動容錯移轉「不」應作為在 Azure 地理配對區域之間永久遷移中樞的機制。 假設裝置所在地最接近中樞的主要區域，則在將中樞容錯移轉到次要區域時，針對 IoT 中樞執行的作業延遲將會增加。
容錯回復
您可以藉由再次觸發容錯移轉動作，容錯回復到舊的主要區域。 如果執行原始容錯移轉作業的目的是為了從原始主要區域的長時間運作中斷復原，我們建議您，當原始位置從中斷的狀況復原後，中樞即應容錯回復至該位置。
重要
- 使用者每天最多只能執行 2 次成功的容錯移轉和 2 次成功的容錯回復作業。
- 不允許連續執行容錯移轉/容錯回復作業。 在這些作業之間，您必須等候 1 小時。
復原時間
雖然 IoT 中樞執行個體的 FQDN (以及連接字串) 在容錯移轉後仍維持不變，但底層 IP 位址確實會變更。 在容錯移轉結束之後，對您 IoT 中樞執行個體執行之執行階段作業要進入完整運作狀態所需的時間，可使用下列函式來表示：
復原時間 = RTO [10 分鐘 - 2 小時 (手動容錯移轉) | 2 - 26 小時 (Microsoft 起始的容錯移轉)] + DNS 傳播延遲 + 用戶端應用程式重新整理任何快取的 IoT 中樞 IP 位址所花費的時間。
重要
IoT SDK 不會快取 IoT 中樞的 IP 位址。 我們建議，使用 SDK 的使用者程式碼不應快取的 IoT 中樞的 IP 位址。
停用災害復原
IoT 中樞可將資料複寫至每個 IoT 中樞的配對區域，藉此提供 Microsoft 起始的容錯移轉和手動容錯移轉。 對於某些區域，您可在建立 IoT 中樞時停用災害復原，以避免複寫超出區域的資料。 支援此功能的區域如下：
- 巴西南部；配對區域：美國中南部。
- 東南亞 (新加坡)；配對區域：東亞 (香港特別行政區)。
若要停用支援區域中的災害復原，請確定在建立 IoT 中樞時未選取 [已啟用災害復原]：
您也可以在使用 ARM 範本建立 IoT 中樞時停用災害復原。
如果您停用 IoT 中樞的災害復原，將無法使用容錯移轉功能。
當您建立 IoT 中樞時，您只能停用災害復原，以避免複寫巴西南部或東南亞配對區域以外的資料。 如果您想要設定現有的 IoT 中樞以停用災害復原，您需要建立已停用災害復原的新 IoT 中樞，並手動移轉現有的 IoT 中樞。 如需指引，請參閱如何移轉 IoT 中樞。
達成跨區域 HA
如果 Microsoft 起始的容錯移轉或手動容錯移轉選項所提供的 RTO 皆不符合您的業務運作時間目標，您應考慮實作個別裝置的自動跨區域容錯移轉機制。 IoT 解決方案中部署拓撲的完整處理方式不在本文討論範圍內。 本文討論適用於高可用性和災害復原的區域容錯移轉部署模型。
在區域容錯移轉模式中，解決方案後端主要是在單一的資料中心位置執行。 次要 IoT 中樞與後端會部署於其他資料中心位置。 若主要區域的 IoT 中樞發生運作中斷狀況，或是從裝置到主要區域的網路連線中斷，則裝置會使用次要服務端點。 可以藉由跨區域容錯移轉模式來改善解決方案，而無須停留在單一區域。
在較高層級上，為了使用 IoT 中樞實作區域容錯移轉模型，您必須執行下列步驟：
次要 IoT 中樞和裝置路由邏輯：萬一主要區域的服務中斷，裝置必須開始連線至您的次要區域。 由於大部分服務狀態感知的本質，解決方案的系統管理員通常會觸發區域間的容錯移轉程序。 要讓新端點與裝置通訊，同時保有程序的控制權，最佳方式是讓它們定期檢查「指引」服務是否有目前作用中的端點。 指引服務可以是 Web 應用程式，其可藉由使用 DNS 重新導向技術複寫並保持連接 (例如使用 Azure 流量管理員)。
注意
IoT 中樞服務在 Azure 流量管理員中不是支援的端點類型。 建議您讓 Azure 流量管理員實作端點健康情況探查 API，而將其與建議的指引服務整合。
身分識別登錄複寫：為了成為可用狀態，次要 IoT 中樞必須包含能夠連線到解決方案的所有裝置身分識別。 解決方案應該保留裝置身分識別的異地複寫備份，並在切換裝置的作用中端點之前將其上傳至次要 IoT 中樞。 IoT 中樞的裝置身分識別匯出功能在此內容中很有用。 如需詳細資訊，請參閱 IoT 中樞開發人員指南 - 身分識別登錄。
合併邏輯：當主要區域再次可供使用時，所有在次要網站中建立的狀態和資料都必須移轉回主要區域。 此狀態和資料大多與裝置身分識別和應用程式中繼資料相關，必須與主要 IoT 中樞合併，也可能要與主要區域中的其他所有應用程式特定存放區合併。
若要簡化此步驟，您應該使用等冪作業。 等冪作業可以將副作用降到最低，不只包括來自最終一致的事件分佈的副作用，也包括來自事件的重複項目或失序傳遞的副作用。 此外，應用程式邏輯應該設計為能夠容忍潛在的不一致或稍微過期的狀態。 發生此狀況可能是因為系統需要額外的時間，根據復原點目標 (RPO) 進行修復。
選擇適合的 HA/DR 選項
以下彙整了本文說明的 HA/DR 選項，可讓您在選擇適用於解決方案的選項時作為參考依據。
| HA/DR 選項 | 復原時間目標 (RTO) | 復原點目標 (RPO) | 需要手動操作？ | 實作複雜度 | 成本影響 |
|---|---|---|---|---|---|
| Microsoft 起始的容錯移轉 | 2 - 26 小時 | 參考前述 RPO 表格 | No | 無 | 無 |
| 手動容錯移轉 | 10 分鐘 - 2 小時 | 參考前述 RPO 表格 | Yes | 非常低。 您只需從入口網站觸發這項作業。 | 無 |
| 跨區域 HA | < 1 分鐘 | 取決於自訂 HA 解決方案的複寫頻率 | No | 高 | > 1 個 IoT 中樞的成本 |