Share via

Edge 工作負載組態模式

  • 文章

店面上各種系統和裝置都可能會使工作負載設定成為一個難題。 本文提供解決問題的方法。

內容和問題

製造公司作為數字轉型旅程的一部分，越來越專注於建置可重複使用為共用功能的軟體解決方案。 由於店面上的各種裝置和系統，模組化工作負載會設定為支援不同的通訊協定、驅動程式和數據格式。 有時候，工作負載的多個實例也會以相同邊緣位置的不同組態來執行。 對於某些工作負載，設定會每天更新一次以上。 因此，組態管理對於相應放大邊緣解決方案越來越重要。

解決方案

邊緣工作負載的組態管理有一些常見的特性：

  • 有數個組態點可以分組為不同的層，例如軟體來源、CI/CD 管線、雲端租用戶和邊緣位置： 描述工作負載組態的圖層圖表：軟體來源、C I/C D 管線、雲端租用戶和邊緣位置。
  • 不同的人員可以更新各種層級。
  • 無論設定如何更新，都必須仔細追蹤和稽核。
  • 若要讓商務持續性，必須在邊緣脫機存取組態。
  • 此外，雲端上也有可用的組態全局檢視。

問題和考量

當您決定如何實作此模式時，請考慮下列幾點：

  • 當邊緣未連線到雲端時允許編輯，會大幅增加組態管理的複雜性。 您可以變更復寫至雲端，但有下列挑戰：
    • 使用者驗證，因為它依賴雲端服務，例如 Microsoft Entra ID。
    • 重新連線後發生衝突解決，如果工作負載收到需要手動介入的未預期設定。
  • 如果拓撲符合 ISA-95 需求，邊緣環境可能會有網路相關條件約束。 您可以藉由選取在 Azure IoT Edge 中提供連線能力的技術，例如 Azure IoT Edge 中的裝置階層，來克服這類限制。
  • 如果運行時間設定與軟體版本分離，則必須個別處理組態變更。 若要提供歷程記錄和復原功能，您必須將過去的設定儲存在雲端中的數據存放區中。
  • 設定中的錯誤，例如設定為不存在端點的聯機組件，可能會中斷工作負載。 因此，請務必將設定變更視為在可觀察性解決方案中處理其他部署生命週期事件，讓可觀察性儀錶板有助於將系統錯誤與設定變更相互關聯。 如需可檢視性的詳細資訊，請參閱 雲端監視指南：可檢視性。
  • 了解雲端和邊緣數據存放區在商務持續性中扮演的角色。 如果雲端數據存放區是單一事實來源，則邊緣工作負載應該能夠使用自動化程式來還原預定的狀態。
  • 為了恢復復原，邊緣數據存放區應該做為離線快取。 這會優先於延遲考慮。

使用此模式的時機

當下列情況時，請使用此模式：

  • 需要設定軟體發行週期以外的工作負載。
  • 不同的人員必須能夠讀取和更新組態。
  • 即使沒有雲端連線，仍需要提供設定。

範例工作負載：

  • 連線到商店資產以進行數據擷取的解決方案，例如 OPC 發行者，以及命令和控制
  • 預測性維護的機器學習工作負載
  • 在生產線上即時檢查品質的機器學習工作負載

範例

在運行時間設定邊緣工作負載的解決方案可以根據外部組態控制器或內部組態提供者。

外部設定控制器變化

外部組態控制器變化架構的圖表。

此變化具有工作負載外部的組態控制器。 雲端設定控制器元件的角色是透過邊緣設定控制器，將編輯從雲端資料存放區推送至工作負載。 邊緣也包含數據存放區，讓系統即使在與雲端中斷連線時也能運作。

使用IoT Edge時，邊緣設定控制器可以實作為模組，而且可以使用模組對應項來套用設定。 模組對應項的大小限制;如果設定超過限制，則可以使用 Azure Blob 儲存體 擴充解決方案，或透過直接方法將較大的承載區塊化。

此變化的優點如下：

  • 工作負載本身不需要注意組態系統。 如果工作負載的原始程式碼無法編輯，則這項功能是必要條件，例如，使用來自 Azure IoT Edge Marketplace 的模組時。
  • 透過雲端設定控制器協調變更，可以同時變更多個工作負載的設定。
  • 額外的驗證可以實作為推送管線的一部分，例如，在將組態推送至工作負載之前，先驗證邊緣端點是否存在。

內部設定提供者變化

內部設定提供者變化架構的圖表。

在內部組態提供者變化中，工作負載會從組態提供者提取組態。 如需實作範例，請參閱 在 .NET 中實作自定義組態提供者。 該範例使用 C#，但可以使用其他語言。

在此變化中，工作負載具有唯一標識符，因此在不同環境中執行的相同原始程式碼可以有不同的組態。 建構標識碼的其中一種方式是將工作負載的階層式關聯性串連至租使用者等最上層群組。 針對IoT Edge，它可以是 Azure 資源群組、IoT 中樞名稱、IoT Edge 裝置名稱和模組識別碼的組合。 這些值一起形成作為數據存放區中索引鍵的唯一標識符。

雖然模組版本可以新增至唯一標識符，但它是跨軟體更新保存組態的常見需求。 如果版本是標識碼的一部分，則應該使用其他實作來轉送舊版的組態。

此變化的優點如下：

  • 除了數據存放區之外，解決方案不需要元件，可降低複雜性。
  • 從不相容的舊版移轉邏輯可以在工作負載實作內處理。

以IoT Edge為基礎的解決方案

I o T Edge 型變化架構的圖表。

IoT Edge 參考實作的雲端元件是由作為雲端設定控制器的 IoT 中樞所組成。 Azure IoT 中樞 模組對應項功能會使用模組對應項所需和報告屬性，傳播目前套用設定的設定變更和相關信息。 組態管理服務可作為組態的來源。 它也可以是用來管理組態、建置系統，以及用來撰寫工作負載組態的其他工具的使用者介面。

Azure Cosmos DB 資料庫會儲存所有組態。 它可以與多個IoT中樞互動，並提供設定歷程記錄。

在邊緣裝置透過回報的屬性指出已套用組態之後，組態狀態服務會記下資料庫實例中的事件。

在組態管理服務中建立新的組態時，它會儲存在 Azure Cosmos DB 中，邊緣模組所需的屬性會在裝置所在的 IoT 中樞變更。 設定接著會透過 IoT 中樞 傳送至邊緣裝置。 邊緣模組預期會透過模組對應項套用組態並報告設定的狀態。 設定狀態服務接著會接聽對應項變更事件，並在偵測到模塊報告設定狀態變更時，記錄 Azure Cosmos DB 資料庫中的對應變更。

邊緣元件可以使用外部元件控制器或內部元件提供者。 在任一實作中，組態都會在模組對應項所需屬性中傳輸，或者，如果需要傳輸大型組態，模組對應項所需屬性會包含 URL 來 Azure Blob 儲存體，或是另一個可用來擷取組態的服務。 模組接著會在模組對應項中發出訊號，指出是否已成功套用新組態，以及目前套用的組態。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主體作者：

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

下一步