Azure IoT 操作部署規劃

許多 Azure IoT 操作設定在部署時是固定的，且只能透過重新部署來更改。在部署前，先規劃叢集拓撲、代理基數、記憶體配置檔，以及你需要的可選代理設定。本文將總結您應該做出的決定。

了解架構

Azure IoT 操作是一組可部署於已啟用 Azure Arc 的叢集上的模組化 Kubernetes 原生服務。關鍵組件包括：

組件	Purpose
MQTT 代理伺服器	適用於邊緣訊息傳遞的高效能 MQTT 3.1.1 與 5 版代理伺服器
OPC UA 連接器	從 OPC UA 伺服器收集資料並發佈至 MQTT
資料流	路由、轉換並將資料推送到雲端端點
Azure 裝置登錄	基於雲端的裝置、資產與結構登錄
阿克里服務	裝置發現與協定轉接器
州商店	MQTT 代理中的鍵值持久層

文件中使用了兩個術語：

部署 — 實例、Arc 擴充功能、自訂位置，以及所有可配置的資源（資產、裝置、資料流）。
實例 — 將服務打包的母資源。

選擇你的叢集拓撲

在部署前，先決定你需要單節點還是多節點叢集。此決策決定硬體需求及經紀商基數設定。

Topology	應用案例	最低硬體
單節點	較小的部署，不需要高可用性	4 顆 vCPU，16 GB 記憶體，30 GB 儲存空間
多節點（3-5 節點）	高可用性與高吞吐量需求	8 顆 vCPU，每個節點 32 GB RAM

Important

基數只能在部署時設定。如果需要變更基數設定，則需要新的部署。

了解代理程式基數

基數是指代理程式部署中前端副本、前端背景工作、後端分區及後端背景工作的數量。基數會控制代理程式如何進行水平擴展，以及在面對 Pod 或節點失敗時具有多大的復原力。

MQTT 代理採用兩層架構：前端 pod 負責客戶端連接與協定處理，後端 Pod 則負責訊息儲存與傳遞。了解每個層級的擴展方式對容量規劃非常重要。

Frontend

前端 Pod 接受 MQTT 用戶端連線並將訊息轉發到後端。前端 Pods 本身不會儲存訊息。前端層級有兩個主要設定：

副本數：要部署的前端 Pod 數量。新增更多前端複本可提升 Broker 可同時處理的用戶端連線數，並在其中一個前端 Pod 發生故障時提供高可用性。
工人：每個前端 pod 的邏輯工作者數量。增加更多工作者讓前端 Pod 能使用更多 CPU 核心。每個工作者最多可消耗一個 CPU 核心。

後端鏈結

後端 Pod 負責訊息儲存與傳遞。後端層主要有三個設定：

分割區：要部署的分割區數目。分割區是用於訊息吞吐量的水平縮放單位。透過一種稱為分片的過程，每個分割區會處理部分訊息，並依主題與會話分片。前端 Pod 會將訊息流量散佈到分割區之間。增加更多分割區可提升經紀人可處理的總訊息吞吐量。
冗餘因子：每個分割區需部署的後端 Pod 數量。增加備援因數會增加資料複本數目，以針對叢集中的節點失敗提供復原能力。
背景工作：每個後端 Pod 的背景工作數量。工作者是分割區內垂直擴展的單位——增加更多工作者讓後端 Pod 在同一節點上使用更多 CPU 核心。每個工作者最多可消耗兩個 CPU 核心，因此在增加每個副本工作者數量時，務必小心不要超過叢集中的 CPU 核心數。

Note

分割縮放的效果取決於主題空間在分割間分布的均勻程度。高度偏斜的分布可能會在單一分割區上產生熱點。

Important

後端冗餘因子必須是 2 或以上。代理商要求每個分割區至少有兩個後端副本，以維持高可用性及滾動更新支援。

吞吐量估計

單一分割區的效能很大程度上取決於所運行節點的 CPU 特性。一般來說，經驗法則是在 2 GHz CPU (約 4-GHz Turbo) 與 8 KB 酬載量下，預期每個分區每秒約可傳送 5,000 到 6,000 則 QoS 1 訊息。實際效能取決於許多因素，因此此數字僅作為容量規劃的起點。

詳細的基準測試數據請參見 MQTT Broker效能基準測試。

單節點建議

前端複製品：設定為 1。
前端工作程序：設定為每個節點 CPU 核心數的一半。
後端副本（冗餘因子）：設定至少 2 ，讓中介能執行滾動更新。

範例：單節點，4 CPU 核心

前端設定	價值觀	後端設定	價值觀
Replicas	1	冗餘因子	2
工人	2	工人	1
		Partitions	1

多節點推薦

以下數值建議以達到最佳效能。對於流量較低的大型叢集，這些數值可以設定得比建議值低，不會造成問題。更多考量，如記憶體（RAM）及效能特性，將在以下章節討論。一定要用預期的工作負載測試你的設定以確認效能。

前端副本：設定為叢集中的 節點數量 。
前端工作程序：設定為每個節點 CPU 核心數的一半。
後端副本（冗餘因子）：設 為 2 以支援冗餘及持續更新。
後端分割區：設定為叢集中 節點數量 。
後端工作者：每個節點的 CPU 核心數設為一半 。

範例：3節點叢集，每個節點8核心

前端設定	價值觀	後端設定	價值觀
Replicas	3	冗餘因子	2
工人	4	工人	4
		Partitions	3

範例：5 節點叢集，每個節點 16 個 CPU 核心

前端設定	價值觀	後端設定	價值觀
Replicas	5	冗餘因子	2
工人	8	工人	8
		Partitions	5

Important

每個節點的前端與後端工作者總數不應超過該節點可用的 CPU 核心數。將工作者數量配置得超過可用核心數，可能會造成 CPU 爭用並降低效能。

CPU 資源限制

為了防止叢集資源短缺，代理程式可以根據基數設定，配置請求 Kubernetes 的 CPU 資源限制。啟用時，縮放副本或工作者數量會成比例增加所需的 CPU 資源。

Important

預設 generateResourceLimits.cpu 值取決於部署方法：

Azure CLI （）：預設為，以避免在資源受限的叢集（如單節點叢集）上部署失敗，因為 CPU 請求可能超過可用資源。
REST API、Bicep 和 ARM 模板：預設為 Enabled。如果你用這些方法部署但沒有明確設定 generateResourceLimits.cpu，CPU 資源限制會自動套用。

如果你啟用了 CPU 資源限制，請確保你的叢集有足夠的 CPU 資源，能根據你的基數設定滿足經紀人的請求。

REST API、Bicep 和 ARM 範本的預設標準定義於 Broker API 規範。

MQTT 代理伺服器根據配置的工作者數量，為每個 pod 請求 CPU 資源。

前端 Pod：每個工作者 1.0 CPU
後端 Pod：每個工作者 2.0 CPU

請使用以下公式計算總 CPU 需求：

組件	Formula
前端 CPU	`replicas` × `frontend.workers` × 1.0 CPU
後端 CPU	`partitions` × `redundancyFactor` × `backend.workers` × 2.0 處理器
代理程式總 CPU	前端 CPU + 後端 CPU

注意事項

Broker 並不是叢集上唯一消耗 CPU 的元件。其他 Azure IoT 操作元件（例如資料流引擎、OPC UA 連接器和系統 Pod）也會保留 CPU 資源，合計通常約為 200 到 300m。規劃叢集容量時，務必將這些額外開銷納入經紀商的 CPU 需求之外。如果所有 Pod 要求的總 CPU 超過叢集可用 CPU，代理程式 Pod 會卡在 Pending 狀態。

範例：小型叢集

考慮一個 2 節點叢集，每個節點有 4 個 CPU 核心（共 8 個核心），其基數如下：

{
  "cardinality": {
    "frontend": {
      "replicas": 2,
      "workers": 2
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

經紀人要求：

前端 CPU：2 個複本 × 2 個工作者 × 1.0 = 4.0 CPU
後端 CPU：1 分割區 × 2 個 RF × 1 個工作者 × 2.0 = 4.0 CPU
總中介 CPU： 8.0 CPU

此組態會在只有 8 個核心的叢集上要求 8.0 個 CPU，沒留下任何資源給其他 Azure IoT 操作元件 (200–300m) 或 Kubernetes 系統 Pod。代理 Pod 停留在Pending狀態，並出現Insufficient cpu錯誤。

要解決這個問題，要麼增加更多節點、增加每個節點的核心數，或降低經紀人基數。

範例：大規模部署

以下基數要求顯著增加的 CPU 資源：

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

前端 CPU：3 個副本× 2 個工作者 × 1.0 = 6.0 CPU
後端 CPU：3 個分割區× 2 個 RF × 2 個工作者 × 2.0 = 24.0 CPU
代理程式總 CPU：30.0 CPU

叢集單對於代理 Pod 就至少需要 30 個可用的 CPU 核心，另外還需預留資源給其他 Azure IoT 操作元件和 Kubernetes 系統 Pod。

CPU 資源限制配置

CPU 資源限制由 generateResourceLimits.cpu Broker 資源中的欄位控制。此組態僅在您使用 --broker-config-file 命令部署 Azure IoT 操作時搭配 az iot ops create 旗標的情況下才受支援。欲了解更多資訊，請參閱 Azure CLI 對進階 MQTT 代理配置的支援。

請依照 GenerateResourceLimits API 參考準備 Broker 設定檔。以下範例展示了兩種可能的值：

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

或

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

選擇您的記憶體設定檔

記憶體配置檔控制經紀人接受的最大 MQTT 訊息大小、閒置記憶體使用量，以及每個 Pod 的最大記憶體使用量。在部署前，根據預期的訊息大小與吞吐量，決定合適的記憶體配置。

記憶體配置檔	郵件大小上限	閒置前端記憶體 (每個 Pod)	每個 pod 的最大前端記憶體	閒置後端記憶體（每個 pod）	每個 Pod 的最大後端記憶體	應用案例
小	4 MB	~29 MiB	~99 MiB	~41 MiB	~102 MiB	流量低，封包小
Low	16 MB	~33 MiB	~387 MiB	~66 MiB	~390 MiB	記憶體有限，封包小
中等（預設）	64 MB	~169 MiB	~1.9 GiB	~211 MiB	~1.5 GiB	中等流量與訊息大小
高	256 MB	~4.9 GiB	~4.9 GiB	~5.8 GiB	~5.8 GiB	高吞吐量，大型訊息

Note

表中的記憶體值是按 pod 計算的。 Pod 內的所有工人共享相同的記憶體配置——增加工人不會增加 pod 的記憶體限制。

警告

當記憶體使用量達到 75% 容量時，代理者會拒絕訊息。選擇具備足夠運作餘裕的設定檔，以因應您預期的訊息大小與輸送量。

入射緩衝器與背壓

每個記憶體設定檔都會為每個後端工作者定義 PUBLISH 資料的最大傳入緩衝區大小。當緩衝區容量達到75% 時，經紀人會啟動背壓機制並開始拒絕收到的訊息。被拒絕的封包會收到 PUBACK 回應，錯誤代碼 已超過配額 。

下表顯示各個設定檔中每個背景工作的傳入緩衝區大小：

記憶體配置檔	傳入緩衝區上限 (每個背景工作)	有效緩衝區（在 75% 背壓下）
小	~16 MiB	~12 MiB
Low	~64 MiB	~48 MiB
Medium	~576 MiB	~432 MiB
高	~2 GiB	~1.5 GiB

選擇記憶體配置檔時，請考慮：

Tiny：只應該使用一個前端。只傳送小於 4 MiB 的封包。
低端：只應該使用一到兩個前端。只傳送小於 16 MiB 的封包。
中等格式：適用於大多數中等訊息大小的生產工作負載。
高：當您需要處理大型訊息，或需要以大型緩衝區達到高吞吐量時使用。

總代理記憶體取決於記憶體配置檔與基數（前端副本數量、後端分割區數及冗餘因子）。更多 pod 代表更多總記憶體。關於不同配置下的基線資源消耗量，請參見基線資源配置。

計算記憶體使用量總計

你可以用這個公式計算總記憶體使用量：

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Where:

Variable	Description
M_total	記憶體使用量總計
R_fe	前端復本的數目
M_fe	每個前端復本的記憶體使用量
P_be	後端分割區的數目
RF_be	後端備援因素
M_be	每個後端復本的記憶體使用量
W_be	每個後端複本的背景工作角色數目

例如，如果你選擇中型記憶體配置檔，該配置檔前端記憶體使用量為 1.9 GiB，後端記憶體使用量為 1.5 GiB。假設訊息代理程式組態是 2 個前端復本、2 個後端分割區，以及後端備援因數 2。記憶體使用量總計為：

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

相比之下， Tiny 記憶體配置檔前端記憶體使用量為 99 MiB，後端記憶體使用量為 102 MiB。使用相同的代理配置，總記憶體使用量為：

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

記憶體設定檔設定

當你使用指令 az iot ops create 部署物聯網操作時，參數 --broker-mem-profile 會指定記憶體設定檔的設定。

例如，以下指令將記憶體配置設定為 Tiny （其他參數為簡潔起略省略）：

az iot ops create ... --broker-mem-profile Tiny

若要深入了解，請參閱 az iot ops create 選用參數。

可選的經紀人設定

以下代理設定也會在部署時設定，之後無法更改。如果這些符合你的情況，請先檢視：

磁碟支援的訊息緩衝區 — 當訂閱者佇列超出可用記憶體容量時，將訊息緩衝到磁碟。對於持續性會話和連線挑戰很有用。
持久性 — 將關鍵經紀人資料寫入磁碟，以便在重啟後保持資料。
診斷 — 為 MQTT 經紀人配置指標、日誌及自我檢查探針。
進階 MQTT 選項 — 自訂會話到期、訊息到期、訂閱者佇列限制及保持活著設定。
內部流量加密 — 設定經紀人前端與後端 Pod 之間的內部流量加密（預設開啟）。

下一步

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-06-11

Azure IoT 操作 部署規劃

了解架構

選擇你的叢集拓撲

了解代理程式基數

Frontend

後端鏈結

吞吐量估計

單節點建議

多節點推薦

CPU 資源限制

範例：小型叢集

範例：大規模部署

CPU 資源限制配置

選擇您的記憶體設定檔

入射緩衝器與背壓

計算記憶體使用量總計

記憶體設定檔設定

可選的經紀人設定

下一步

意見反應

其他資源

Azure IoT 操作部署規劃