共用方式為

設定 MQTT 代理程式持續性

資料持續性特性被設計為複製系統的補充機制。 雖然代理程式會跨多個節點複寫資料，但叢集範圍的關機仍可能導致資料遺失。

為了降低此風險，MQTT 代理程式支援持續儲存，可將關鍵資料寫入磁碟，並在重新啟動時保留。 此資料持續性功能與 磁碟支援的訊息緩衝區不同，後者使用磁碟作為記憶體的延伸模組，但是暫時性的，且不提供持久性保證。

將資料儲存在磁碟上會造成效能成本。 影響會因底層儲存媒體的類型和速度而異。

您可以使用 Azure 入口網站或 Azure CLI 在初始部署期間設定資料持續性。 您也可以在部署之後變更一些持續性選項。

設定方法

使用下列其中一種方法，配置 MQTT 分配管理系統的資料持續性：

  • Azure 入口網站：在 IoT 作業部署期間，透過圖形使用者介面設定持續性設定。
  • Azure CLI：當您使用 --broker-config-file 命令部署 IoT 作業時，請使用帶有 az iot ops create 旗標的 JSON 組態檔。

如需可用設定的完整清單，請參閱 Azure IoT 作業 API 檔。

部署時間組態選項

您必須在部署期間設定這些選項，而且稍後無法變更。

這很重要

您在部署期間設定持續性，之後無法將其關閉。 您可以在部署之後變更一些與持續性相關的選項。

磁碟區和磁碟區大小

MQTT 代理程式使用持續性磁碟區 （PV） 將資料儲存在磁碟上。 有兩個設定可控制此磁碟區的佈建方式：

  • maxSize （必要）：設定儲存代理程式資料的持續性磁碟區大小上限。 此欄位一律為必填欄位，即使您提供自訂磁碟區宣告也一樣。 此值必須大於 100 MB。

    範例：10GiB

  • persistentVolumeClaimSpec （選用）：可讓您定義自訂 PersistentVolumeClaim （PVC） 範本，以控制佈建持續性磁碟區的方式。 如果您未設定此選項，代理程式會使用指定的 maxSize 和預設儲存類別來建立預設 PVC，如果預設類別不受本機路徑佈建程式支援，可能會導致效能不佳。

這很重要

當您指定 persistentVolumeClaimSpec時，存取模式必須設為 ReadWriteOncePod。

若要在 Azure 入口網站中設定儲存體容量設定：

  1. 在 IoT 作業部署期間，導覽至 MQTT 代理程式 組態區段。

  2. 在 資料持續性 設定中：

    • 設定持續性磁碟區的 大小上限 （必要）。
    • 選擇性地設定 「持續磁碟區宣告規格」 設定、以符合自訂儲存類別需求。

    [在 Azure 入口網站中部署期間顯示資料持續性選項的螢幕擷取畫面]

Encryption

為了保護資料，MQTT 代理程式預設會使用強式 AES-256-GCM 加密來加密磁碟上的所有持續性資料。 這可確保即使攻擊者獲得對底層磁碟區的存取權限，敏感的代理程式狀態或會話資料仍受到保護。

加密是選用的，預設為開啟。 如有需要，您可以關閉加密。 加密僅保護靜態資料;記憶體中的資料未加密。 使用加密的效能成本最低，但尚不支援金鑰輪替。

使用 Azure 入口網站部署時，預設會啟用加密。 如果您使用 Azure CLI 進行部署，您可以在代理程式組態檔中停用加密。

執行階段配置選項

部署 Azure IoT 作業 MQTT 代理程式之後，即可更新這些選項。

保留訊息的持久性

保留訊息是代理程式在新訂閱者連線到主題時儲存並遞送給新訂閱者的 MQTT 訊息。 這些訊息有助於確保訂閱者收到最新的資料，即使他們在最初發佈訊息時未連線。 這對於新訂閱者在連線後立即需要的狀態更新、配置資料或最後已知值特別有用。

將保留的訊息保存到磁碟可確保這些重要訊息在代理程式重新啟動後繼續存在，並且不會在維護或非預期關機期間遺失。 如果沒有持續性，保留的訊息只會存在於記憶體中，並在分配管理系統重新啟動時遺失。 這可能會使新訂閱者沒有關鍵的初始數據。

此設定可控制哪些保留的訊息會保存至磁碟。

  • mode （如果已設定，則 retain 為必要）：選項為 None、 All或 Custom。

    • None：不會保存任何保留的訊息。
    • All：所有被保留的訊息都會被持久化保存。
    • Custom：只有在 retainSettings.topics 列出的主題會被持久化。

  • 如果您選取：Custom

    • retainSettings.topics （選擇性）：要保存的主題模式清單。 支援萬用字元 # 和 +。

    • retainSettings.dynamic.mode （選用，預設值： Enabled）：允許 MQTT 用戶端使用 MQTT v5 使用者內容來要求保留訊息的磁碟持續性。

若要在 Azure 入口網站中設定保留的訊息持續性：

  1. 導航至您的 IoT Operations 實例。

  2. 移至 MQTT 代理程式>資料持續性。

  3. 在「 保留訊息」 區段中：

    • 選取 模式：無、全部或自訂。
    • 如果選取自訂，請指定主題型樣和動態模式設定。

    [變更資料持續性及保留訊息選項的截圖：Azure 入口網站]

訂閱者佇列持續性

訂閱者佇列會保留等待傳遞至具有服務品質 (QoS) 1 訂用帳戶的 MQTT 用戶端的訊息。 當用戶端訂閱 QoS 1 時，代理程式會透過將訊息排入佇列來保證訊息傳遞，直到用戶端確認收到為止。 這些佇列對於可能暫時中斷連線或處理訊息緩慢的用戶端特別重要。

將訂閱者佇列保存至磁碟可確保在代理程式重新啟動期間，等待傳遞的訊息不會遺失。 此功能對於 IoT 案例至關重要，其中裝置可能會有間歇性連線、緩慢的處理或持續性會話，這些會話需要在代理程式重新啟動時保持訊息傳遞保證。 如果沒有持久性，佇列訊息就會遺失，這可能會導致重要裝置通訊的資料遺失。

如需訂閱者佇列和訊息傳遞的詳細資訊，請參閱 設定代理程式 MQTT 用戶端選項。

此設定可控制哪些訂閱者訊息佇列要保存至磁碟。 無論這些設定如何，工作階段狀態中繼資料總是會被保存。

  • mode （如果已設定，則 subscriberQueue 為必要）：選項為 None、 All或 Custom。

  • 如果您選取：Custom

    • subscriberQueueSettings.subscriberClientIds （選擇性）：要保存的訂閱者用戶端ID清單。 支援萬用字元 *。

    • subscriberQueueSettings.dynamic.mode （選用，預設值： Enabled）：使MQTT客戶端能夠動態請求持久性。

若要在 Azure 入口網站中設定訂閱者佇列持續性：

  1. 導航至您的 IoT Operations 實例。

  2. 移至 MQTT 代理程式>資料持續性。

  3. 在 Subscriber Queue 區段中：

    • 選取 模式：無、全部或自訂。
    • 如果選取自訂，請指定訂閱者用戶端識別碼和動態模式設定。

    [Azure 入口網站中更改資料持續性訂閱選項的螢幕擷取畫面]

這很重要

尚未持續保存的用戶端隨時可能變得持續保存。 不過，只有針對該特定用戶端啟用持續性之後收到的已發佈訊息才會儲存在磁碟上。 如果日後停用用戶端的持續性設定，該變更將不會生效，直到用戶端使用「MQTT clean start = true」旗標重新連線。

工作階段到期和訂閱者佇列持續性

若要將訂閱者訊息佇列保存至磁碟，會話期限間隔和代理程式的持續性配置都必須對齊。 具體而言：

  • MQTTv5 用戶端：可以使用 CONNECT 或 DISCONNECT 封包的「連線過期間隔」屬性來指定連線的有效期間。 他們也可以要求具有指定使用者屬性的磁碟持續性行為。

  • MQTTv3 用戶端：如果「Clean Session」標誌為 true，則連線過期區間會設為 0。 否則，會使用代理程式中的組態值 maxSessionExpirySeconds 。

代理會根據配置模式和會話到期時間間隔，以不同的方式處理訂閱者佇列持久性：

當模式設定為 None：

  • 所有訂閱者佇列都僅保留在記憶體中，無論工作階段到期時間間隔為何

當模式設定為 All：

  • 如果會話過期間隔 = 0：佇列將保留在記憶體中。
  • 如果階段作業到期間隔 > 為 0：佇列會在間隔期間持續保存至磁碟

當模式設定為 Custom：

  • 如果會話過期間隔 = 0：佇列將保留在記憶體中。
  • 如果階段作業到期間隔 > 為 0：佇列會在間隔期間持續保存至磁碟的情況僅限於：
    • 用戶端識別碼符合 subscriberQueueSettings.subscriberClientIds 中設定的清單，「或」
    • 已啟用動態模式，且 MQTTv5 用戶端在其 CONNECT 封包中提供相符的使用者內容

若要確保訂閱者佇列保存到磁碟，請記住以下要點：

  • 當工作階段過期時間間隔大於 0 時，訂閱者佇列才會被保留。
  • 在 Custom 模式下，必須明確列出用戶端識別碼，或啟用具有正確使用者屬性的動態持續性
  • MQTTv5 用戶端可以透過在其 CONNECT 封包中包含已配置的使用者屬性（預設值：aio-persistence=true）來使用動態持續性。

狀態儲存的持久性

狀態存放區是 MQTT 代理程式的內部元件，可維護標準 MQTT 訊息以外的各種類型的作業資料和中繼資料。 這包括代理程式組態狀態、會話資訊、訂閱詳細資料，以及代理程式用來有效管理用戶端連線和訊息路由的其他內部資料結構。

將狀態存放區資料保存至磁碟可確保代理程式可以在重新啟動時保持作業連續性。 這對於複雜的物聯網部署尤其重要，因為代理從頭開始重建其內部資料結構時，失去內部狀態可能會導致連線問題、訂閱遺失或效能下降。

狀態存放區持續性在生產環境中特別有價值，因為在生產環境中，將復原時間降至最低並維護服務一致性至關重要。 如果沒有持續性，代理程式必須在重新啟動時重建所有內部狀態，這可能會導致暫時服務中斷和效能影響。

如需狀態存放區的詳細資訊，請參閱 瞭解 MQTT 代理程式狀態存放區通訊協定。

此設定會控制內部狀態存放區中的哪些索引鍵要保存。

  • mode （如果設定了 stateStore，則為必要）：選項為 None、 All或 Custom。

  • 如果您選取：Custom

    • stateStoreSettings.stateStoreResources （選擇性）：要保存的索引鍵類型和索引鍵清單。

      • keyType：模式、字串或二進位

      • keys：要保持的鍵/模式清單。

    • stateStoreSettings.dynamic.mode （選用，預設值： Enabled）：使MQTT客戶端能夠動態請求持久性。

若要在 Azure 入口網站中設定狀態存放區持續性：

  1. 導航至您的 IoT Operations 實例。
  2. 移至 MQTT 代理程式>資料持續性。
  3. 在 [狀態存放區 ] 區段中：
    • 選取 模式：無、全部或自訂。
    • 如果選取自訂，請使用索引鍵類型、索引鍵和動態模式設定來指定狀態存放區資源。 [變更 Azure 入口網站資料持續性狀態存放區選項的螢幕擷取畫面]

使用動態持續性設定向用戶端請求持續性

用戶端可以透過在其訊息中傳送 MQTT v5 使用者屬性來要求其資料的持續性。 這可讓用戶端動態啟用其訊息、訂閱者佇列或狀態存放區項目的持續性，而不需要變更代理程式組態。

當用戶端要求持續性時，代理程式會檢查其目前的持續性設定並套用它們。 如果已啟用所要求的持續性模式，並設為允許動態要求，則代理程式會依組態中指定的方式保存用戶端的資料。

您可以在個別組態區段中設定 dynamic.mode 為 ， Enabled 以啟用或停用每個資料類型 （保留訊息、訂閱者佇列和狀態存放區項目） 的動態持續性設定。 用於動態持久性請求的 MQTT 使用者屬性索引鍵及值是在代理層次上個別配置。

若要在 Azure 入口網站中設定動態持續性設定：

  1. 導航至您的 IoT Operations 實例。

  2. 移至 MQTT 代理程式>資料持續性。

  3. 配置全域 MQTT 使用者屬性設定：

    • 設定 使用者屬性索引鍵 （預設值： aio-persistence）
    • 設定 使用者屬性值 （預設值： true）

  4. 在每個持久化區段（保留訊息、訂閱者佇列、狀態存放區）中：

    • 將 動態持續性設定 為已啟用，以允許用戶端要求該資料類型的持續性。

    [Azure 入口網站中變更資料持續性動態選項的截圖]

相關內容

若要深入瞭解進階 MQTT 代理程式設定的 Azure CLI 支援，請參閱進 階 MQTT 代理程式設定的 Azure CLI 支援。

  • Last updated on