共用方式為


IoT 工作負載的可靠性

IoT 工作負載就像所有工作負載一樣,可能會發生問題。 妥善架構 IoT 解決方案的主要可靠性考慮是偵測變更的速度,以及您可以繼續作業的速度。

IoT 應用程式通常會大規模散發,而且可能會透過不可靠的網路運作,而不需要持續存取或查看端對端資料流程。 由於這些因素,您應該考慮可用性和復原能力來設計 IoT 架構。

建置可靠的 IoT 解決方案需要仔細考慮裝置、雲端服務,以及其互動方式。 您為裝置硬體、連線和通訊協定和雲端服務所做的選擇會影響解決方案的可靠性需求和功能。

評估 IoT 工作負載的可靠性

若要透過 Well-Architected 架構可靠性要素的鏡頭來評估 IoT 工作負載,請在 Azure Well-Architected 檢閱中完成 IoT 工作負載的可靠性問題。 評估識別 IoT 解決方案的重要可靠性建議之後,請使用下列內容來協助實作建議。

設計原則

架構卓越五大要素可支援 IoT 工作負載設計方法。 這些要素可作為跨 重要 IoT 設計領域的後續設計決策指南針。 下列設計原則可擴充 Azure Well-Architected Framework - 可靠性的品質要素。

設計原則 考量事項
設計可復原的裝置 設計您的裝置,以滿足端對端解決方案的執行時間和可用性需求。 請確定您的 IoT 裝置可以透過間歇性連線至雲端有效率地運作。
針對業務需求設計 引進架構修改以符合服務等級協定 (SLA) 時,成本影響是不可避免的。 例如,若要擁有更高的可靠性和高可用性,您可以實作跨區域備援和自動化系統來自動調整。 應謹慎考量此取捨。
安全、簡單的更新程式 企業 IoT 解決方案應提供操作員如何管理裝置的策略。 IoT 操作員需要簡單且可靠的更新工具和做法。
觀察應用程式健康狀態 根據可觀察性,定義 SLO (SLI) ) 和服務等級目標 (SLA 的服務等級指標。 新增稽核、監視和警示的程式,超過雲端服務所提供的功能。
重要元件的高可用性和災害復原 (HA/DR) 。 在備援中建置的復原硬體和軟體元件,包括跨區域備援。
規劃容量 規劃服務配額和節流、偵測動作之間的延遲,以及在生產規模建立基準,以支援未中斷的資料流程。

IoT 架構層

可靠性設計原則有助於厘清考慮,以確保 IoT 工作負載符合 基礎 IoT 架構層的需求。 為了達到整體解決方案可靠性,每個層級都應該具有可接受的可靠性層級。

此圖顯示 IoT 架構中的圖層和跨領域活動。

裝置和閘道層

在整體 IoT 解決方案中,設計您的裝置以滿足解決方案的端對端執行時間和可用性需求。 裝置和閘道有許多形式。 IoT 裝置和閘道可以進行資料收集、監督控制和邊緣分析。

  • 資料收集會將裝置連線到感應器,或訂閱來自下游系統的遙測,並將收集的資料推送至雲端。 IoT 解決方案設計應確保從裝置到雲端的可靠裝置管理和可靠通訊。

  • 提供監督控制的裝置不僅會收集資料以傳送至雲端,也會根據該資料採取動作。 裝置會將資料傳送回電腦或環境,以採取監督動作。 監督控制應用程式的可靠性非常重要。

裝置設計

設計和選取 IoT 裝置,以在預期的存留期內可靠地運作。 可靠的裝置應該根據其硬體和軟體規格執行,而且應該透過風險降低、修復或更換來偵測及管理任何失敗。 設計裝置的可靠性,但也規劃失敗。

裝置的生命週期

有限的服務存留期會影響解決方案可靠性。 評估解決方案上裝置失敗的結果,並根據解決方案需求定義裝置生命週期策略。

裝置失敗影響評估包括:

  • 嚴重性,例如單一失敗點。
  • 機率,例如失敗之間的平均時間。
  • 可偵測性,例如失敗模式和效果分析。
  • 可接受的停機時間。

可接受的作業停機時間決定裝置維護的速度和範圍。 裝置和部分供應專案的可用性或可用性是裝置生命週期的重要考慮。

設計更模組化,交換系統的元件會比較容易,特別是當某些元件早于其他元件過時時。 元件和模組供應鏈的替代或多重來源對於可靠解決方案而言非常重要。

環境需求

裝置運作的條件會影響其可靠性。 定義您的環境需求,並使用具有適當功能規格的裝置。 這些規格包括作業溫度範圍、濕度、輸入保護 (IP) 評等參數、干擾 (EMI) 防護,以及震動和震動防護。

操作設定檔

效能壓力會影響裝置的操作行為,因此其可靠性。 定義作業設定檔,以估計裝置存留期的行為,並據以評估裝置可靠性。 這類設定檔包括作業模式,例如無線傳輸或低電源模式,以及裝置存留期的溫度等環境條件。

在正常作業情況下,裝置和軟體應該在指定的作業設定檔內安全地執行。 裝置必須能夠服務及處理解決方案所需的所有外部感應器和資料處理。 避免在裝置功能限制下執行。

法規與標準

特定產業的裝置受限於適用的法規和標準。 定義法規和標準,並確定裝置符合合規性和合規性需求。 法規包括認證和標記,例如,RMS 或 CE。 標準包括產業或機構應用程式,例如 ATEX 和 MIL-SPEC,以及安全一致性,例如 IEC 61508。

裝置管理和模型化層

雲端服務會提供每個裝置的身分識別,並大規模管理裝置。 雲端通常是來自裝置之所有訊息的最終資料輸入點。 在 IoT 解決方案中,雲端服務必須提供 IoT 裝置的可靠性,才能整合和傳輸資料。

裝置連線條件,包括雲端的上游,以及區域網路的下游,應該是 IoT 解決方案可靠性設計的一部分。 評估連線中斷或干擾的潛在影響,並據以定義連線策略。

連線策略應包含健全性,例如後援功能和中斷連線管理,以及緩衝備份,以減輕重要或安全性功能的雲端相依性。

下列設計、錯誤處理和監視做法與連線能力有關。

連線設計

IoT 解決方案應該啟用間歇性連線裝置與雲端式服務之間的資訊流程。 請確定您的 IoT 裝置可以有效率地與雲端的間歇性連線運作。

最佳做法包括下列建議:

  • 在裝置軟體中實作重試和輪詢邏輯。
  • 同步處理裝置狀態與雲端。
  • 如果您的解決方案無法容忍資料遺失,請確定您可以將資料儲存在裝置上。
  • 使用資料取樣和模擬來測量網路容量和儲存體需求基準。

連線實作

Azure IoT 裝置 SDK 提供可在裝置或閘道上使用的用戶端程式庫,以簡化與 Azure IoT 服務的連線。 您可以使用 SDK 來檢測下列 IoT 裝置用戶端:

  • 連線到雲端。
  • 在不同平臺上提供一致的用戶端開發體驗。
  • 藉由擷取基礎通訊協定和訊息處理模式的詳細資料,例如具有抖動和重試邏輯的指數輪詢,以簡化常見的連線工作。

連線能力監視

IoT 裝置的連線問題可能會因為許多可能的失敗點而難以進行疑難排解。 應用程式邏輯、實體網路、通訊協定、硬體、Azure IoT 中樞和其他雲端服務可能會發生問題。

必須有能力偵測和查明問題的來源。 不過,大規模 IoT 解決方案可能會有數千個裝置,因此手動檢查個別裝置並不實用。 Azure 監視器和Azure 事件方格可協助您診斷IoT 中樞中的連線問題。

連線資源

擷取和通訊層

IoT 擷取和通訊層涵蓋服務配額和限制、容量、節流和自動調整。

備援容量設計

規劃閾值和警示時,請考慮偵測與採取動作之間的延遲。 請確定系統和操作員有足夠的時間回應變更要求。 例如,您可能會偵測到需要增加單位數目,但系統可能會在增加生效之前遺失訊息而失敗。

服務配額規劃

如同所有平臺服務,IoT 中樞和IoT 中樞裝置布建服務 (DPS) 在特定作業上強制執行配額和節流,因此 Azure 可以為服務提供可預測的服務等級和成本。 配額和節流會系結至您部署的服務層級和單位數目,因此您可以使用正確的資源數目來設計解決方案。 事先檢閱配額和節流,並據以設計您的IoT 中樞和 DPS 資源。

生產規模基準測試

隨著裝置或資料量增加,雲端閘道必須調整以支援不中斷的資料流程。 由於 IoT 解決方案的分散式本質、裝置數目和資料量,因此請務必為整體解決方案建立規模基準。 這些基準測試有助於規劃容量風險。 使用 Azure IoT 裝置遙測模擬器 來模擬生產規模磁片區。

自動調整以動態調整配額

使用平臺即服務 (PaaS) 元件的優點是能夠根據您的需求相應增加和減少。 若要提供最低的成本和營運工作,請考慮實作自動化系統,以隨著解決方案的不同需求來相應增加和減少資源。

配額和節流管理

為了確保解決方案可靠性,請針對配額和節流持續監視資源使用量,以偵測使用量增加,以指出需要調整。 根據您的業務需求,您可以持續監視資源使用量,並在符合閾值時警示操作員,或實作自動化系統以自動調整。

容量和調整資源

傳輸層

若要連線到雲端服務以進行資料、控制和管理,裝置需要存取網路。 根據 IoT 解決方案的類型,連線可靠性可能是您的責任或網路服務提供者的責任。 網路可能有間歇性連線問題,且裝置需要據以管理其行為。

DevOps 層

企業 IoT 解決方案應該為操作員提供管理系統的策略。 為了解決可靠性,IoT 管理和作業應該使用 DevOps 程式來處理更新、可觀察性和監視,以及 HA/DR 實作。

更新

相較于雲端式解決方案,IoT 解決方案的裝置層面會面臨挑戰。 例如,必須有一種方式可以持續更新裝置以解決弱點和應用程式變更。

由於 IoT 解決方案的分散式本質,請務必採用安全且安全的原則來部署更新。 IoT 操作員需要簡單且可靠的更新工具和做法。

裝置更新解決方案必須支援:

  • 透過裝置群組和排程式控制件逐步更新推出。
  • 支援彈性 A/B 裝置更新以進行無縫復原。
  • 詳細的更新管理和報告工具。
  • 根據可用頻寬的網路優化。

IoT 中樞裝置更新是一項服務,可啟用安全、安全且可靠的無線 (OTA) IoT 裝置更新。 IoT 中樞的裝置更新可以群組裝置,並指定哪些裝置應該接收更新。 操作員可以檢視更新部署的狀態,以及每個裝置是否成功套用必要的更新。

如果更新失敗,裝置更新可協助操作員識別失敗的裝置,並查看失敗詳細資料。 識別哪些裝置失敗的能力可以消除嘗試手動找出失敗來源的時數。

裝置更新會監視裝置部署和更新的狀態,並報告有多少裝置符合最高版本可用的相容更新。

可檢視性和監視

若要管理整體解決方案可靠性並定義警示程式,您應該監視 IoT 解決方案的每個元件。 所有 Azure IoT 服務都會發佈描述服務健康情況和可用性的計量。 若要建立端對端可觀察性,也請考慮您在裝置端所需的計量。 使用這些計量作為整體解決方案可靠性監視的一部分。

IoT 應用程式監視和診斷對於可用性和復原至關重要。 如果某個專案失敗,您必須知道失敗、失敗時,以及原因。 藉由監視 IoT 應用程式和裝置的作業狀況良好,您可以偵測並修正可靠性問題。

若要減輕影響 IoT 應用程式可靠性的問題,您必須能夠擷取記錄和訊號,以協助您在端對端作業中偵測問題。 使用記錄和監視來判斷 IoT 解決方案是否如預期般運作,並協助針對解決方案元件的問題進行疑難排解。

下列動作支援 IoT 解決方案的可觀察性:

  • 建立機制來收集和分析效能計量和警示。
  • 設定裝置、雲端服務和應用程式,以收集和與 Azure 監視器連線。
  • 使用即時儀表板和警示來監視 Azure 後端服務。
  • 定義監視和處理事件和警示的角色和責任。 如需詳細資訊,請參閱 角色、責任和許可權
  • 實作持續監視。

Azure 監視器

Azure 監視器 是 Azure IoT 解決方案的建議監視和視覺效果平臺。 不論部署位置為何,您都可以設定裝置、雲端服務和應用程式,直接或透過內建連接器將記錄訊息推送至 Azure 監視器。

  • 使用 Azure 監視器內建計量整合來遠端監視IoT Edge裝置。 若要在您的裝置上啟用這項功能,請將IoT Edge計量收集器模組新增至您的部署,並將其設定為收集及傳輸模組計量至 Azure 監視器。

  • 使用 Azure 監視器,您可以監視IoT 中樞環境的狀態、確定其正常執行,並確認您的裝置未受到節流或發生連線問題。 IoT 中樞提供使用計量,例如使用的訊息數目和連線的裝置數目。 您可以將此資料轉寄至 Azure 監視器,以進行分析和警示其他服務。

  • 如果您的解決方案使用 Azure IoT Central,您可以使用 IoT Central 提供的計量來評估連線裝置和作用中資料匯出的健康情況。 IoT Central 應用程式預設會啟用計量,您可以從Azure 入口網站存取計量。 Azure 監視器會公開並提供數種方式來與這些計量互動。

  • Azure 監視器提供自訂記錄剖析,以協助將事件和記錄分解成個別欄位,以便編制索引和搜尋。

  • 實作即時儀表板和 Azure 監視器警示,以監視 Azure 後端服務。 警示會主動通知您監視資料中的特定條件,因此您可以在客戶遇到問題之前識別並解決問題。 可在 [計量]、[記錄]、[活動記錄] 中設定警示。

Application Insights 是 Azure 監視器的一項功能,可為即時 Web 應用程式提供可延伸的應用程式效能管理和監視。 如果您的 IoT 解決方案使用自訂Azure App 服務、Azure Kubernetes Service或Azure Functions應用程式,您可以使用 Application Insights 進行應用程式監視和分析。

Application Insights 可以:

  • 自動偵測效能異常。
  • 使用功能強大的分析工具協助診斷問題。
  • 顯示使用者實際對您的應用程式執行的動作。
  • 協助您持續改善應用程式效能和可用性。

連續監視

持續整合和持續部署 (CI/CD) 是 DevOps 做法,可提供更快速且可靠的軟體,為使用者提供持續的價值。 持續監視 (CM) 是類似的概念,其中包含 DevOps 迴圈的所有階段和元件之間的監視。

CM 會持續確保應用程式與基礎結構的健康情況、效能和可靠性,因為它們會流經開發、生產及發行給客戶。 如需詳細資訊,請參閱:

監視資源

重要元件的 HA/DR

當您設計和建置 IoT 解決方案時,必須符合解決方案堆疊上失敗復原的 SLA。 您的 SLA 應引導您瞭解哪些重要系統元件需要 HA/DR。 有許多方法,從跨 IoT 解決方案堆疊的備援到特定層的備援。 成本也是考慮符合 SLA 重要性的主要考慮。

  • Azure IoT 服務已定義執行時間和可用性目標。 檢閱屬於解決方案一部分的 Azure IoT 服務的 SLA,以查看它們是否符合您的執行時間目標。 例如,Azure IoT 中樞 SLA 為 99.9%,這表示您應該規劃每天 1 分鐘和 36 秒的潛在停機時間。 Azure IoT 中樞 SDK 提供內建、可設定的邏輯來處理重試和輪詢。

  • 請考慮將您的執行時間目標分成兩種類別:裝置管理和資料擷取作業。 例如,即使裝置管理服務無法使用,裝置也可能會成功將資料傳送至 IoT 中樞。 如需詳細資訊,請參閱Azure IoT 中樞 SDK 可靠性功能

  • 請考慮針對感應器、電源和儲存體使用備援硬體。 備援硬體可讓裝置在重要元件無法使用時運作。 硬體也可協助解決連線問題。 例如,當無法使用連線時,您可以針對資料使用儲存和轉寄方法。 Azure IoT Edge已內建這項功能。

  • 裝置也必須能夠處理雲端中斷。 Azure 區域配對可為符合許多 SLA 需求的IoT 中樞提供 HA/DR 策略。 如果區域配對不足,請考慮實作次要 IoT 中樞。 您也可以使用 DPS 來避免裝置上的硬式編碼IoT 中樞設定。 如果您的主要 IoT 中樞關閉,DPS 可以將裝置指派給不同的中樞。

  • 請考慮針對您預期大部分時間在線上的裝置實作活動訊號訊息模式。 此模式會使用自訂IoT 中樞路由搭配 Azure 串流分析、Azure Logic Apps 或Azure Functions來判斷活動訊號是否失敗。 您可以使用活動訊號來定義 Azure 監視器警示,以視需要採取動作。

HA/DR 資源

下一步