共用方式為


設定高可用性、調整和記憶體使用量的訊息代理程式設定

訊息代理程式資源是定義 MQTT 訊息代理程式整體設定的主要資源。 它也會決定執行訊息代理程式組態的 Pod 數目和類型,例如前端和後端。 您也可以使用訊息代理程式資源來設定其記憶體設定檔。 自我修復機制內建於訊息代理程式,而且通常可以從元件失敗中自動復原。 例如,針對高可用性設定的 Kubernetes 叢集中,節點會失敗。

您可以藉由新增更多前端復本和後端分割區,水平調整 MQTT 訊息代理程式。 前端復本負責接受來自用戶端的 MQTT 連線,並將其轉送至後端分割區。 後端分割區負責儲存和傳遞訊息給用戶端。 前端 Pod 會將訊息流量分散到後端 Pod,而後端備援因素會決定資料複本數目,以針對叢集中的節點失敗提供復原能力。

如需可用設定的清單,請參閱 Broker API 參考。

設定縮放設定

重要

此設定需要修改 Broker 資源,且只能在初始部署階段使用 Azure CLI 或 Azure 入口網站進行設定。 如果需要訊息代理程式設定變更,則需要新的部署。 若要深入瞭解,請參閱 自定義預設 Broker

若要設定 MQTT 訊息代理程式的規模設定, 請在 Azure IoT 作業部署期間指定 Broker 資源的規格中的基數 字段。

自動部署基數

若要在部署期間自動判斷初始基數,請省略 Broker 資源中的基數位段。

透過 Azure 入口網站 部署 Azure IoT 作業時,尚不支援自動基數。 不過,您可以手動將叢集部署模式指定為 單一節點多節點。 若要深入了解,請參閱部署 Azure IoT 作業

螢幕快照,顯示 Azure 入口網站 要選取單一或多節點設定的位置。

MQTT 訊息代理程式操作員會根據部署時可用的節點數目,自動部署適當的 Pod 數目。 這適用於您不需要高可用性或調整的非生產案例。

不過,這不是自動調整。 運算子不會根據負載自動調整 Pod 數目。 操作員只會根據叢集硬體決定要部署的初始Pod數目。 如先前所述,基數只能在初始部署時間設定,而且如果需要變更基數設定,則需要新的部署。

直接設定基數

若要直接設定基數設定,請指定每個基數位段。

遵循部署 Azure IoT 作業指南時,請在 [ 組態 ] 區段中查看 MQTT 訊息代理程序設定。 您可以在這裏指定前端復本、後端分割區和後端背景工作角色的數目。

顯示 Azure 入口網站 直接設定訊息代理程式基數位置的螢幕快照。

瞭解基數

基數表示集合中特定實體的實例數目。 在 MQTT 訊息代理程式的內容中,基數是指要部署的前端復本、後端分割區和後端背景工作角色的數目。 基數設定可用來水平調整訊息代理程式,並在發生Pod或節點失敗時改善高可用性。

基數位段是巢狀字段,具有前端和 backendChain 的子字段。 每個子欄位都有自己的設定。

前端

前端子欄位會定義前端 Pod 的設定。 這兩個主要設定如下:

  • 復本:要部署的前端復本 (Pods) 數目。 增加前端復本數目可提供高可用性,以防其中一個前端 Pod 失敗。

  • 背景工作角色:每個復本的邏輯前端背景工作角色數目。 每個背景工作角色最多可以取用一個CPU核心。

後端鏈結

後端鏈結子欄位會定義後端分割區的設定。 三個主要設定如下:

  • 數據分割:要部署的數據分割數目。 透過稱為 分區化的程式,每個分割區都會負責部分訊息,除以主題標識碼和會話標識碼。 前端 Pod 會將訊息流量分散到分割區。 增加分割區數目會增加訊息代理程式可以處理的訊息數目。

  • 備援因素:每個分割區要部署的後端復本(Pods)數目。 增加備援因素會增加數據復本數目,以提供叢集中節點失敗的復原能力。

  • 背景工作角色:每個後端復本要部署的背景工作角色數目。 增加每個後端復本的背景工作角色數目可能會增加後端 Pod 可以處理的訊息數目。 每個背景工作角色最多可以取用兩個 CPU 核心,因此在增加每個複本的背景工作角色數目時,不要超過叢集中的 CPU 核心數目時,請小心。

考量

當您增加基數值時,訊息代理程序處理更多連線和訊息的能力通常會改善,如果 Pod 或節點失敗,則會增強高可用性。 不過,這也會導致資源耗用量較高。 因此,調整基數值時,請考慮 記憶體配置檔設定 和訊息代理程式 CPU 資源要求。 如果您發現前端 CPU 使用率是瓶頸,增加每個前端復本的背景工作角色數目,有助於增加 CPU 核心使用率。 如果後端 CPU 是瓶頸,增加後端背景工作角色數目有助於訊息輸送量。

例如,如果您的叢集有三個節點,每個節點都有八個 CPU 核心,則設定前端復本數目以符合節點數目 (3),並將背景工作角色數目設定為 1。 將後端分割區的數目設定為符合節點數目 (3),並將後端背景工作角色數目設定為 1。 視需要設定備援因數 (2 或 3)。 如果您發現前端 CPU 是瓶頸,請增加前端背景工作角色的數目。 請記住,後端和前端背景工作角色可能會彼此和其他 Pod 競爭 CPU 資源。

設定記憶體設定檔

重要

此設定需要修改 Broker 資源,且只能在初始部署階段使用 Azure CLI 或 Azure 入口網站進行設定。 如果需要訊息代理程式設定變更,則需要新的部署。 若要深入瞭解,請參閱 自定義預設 Broker

若要設定記憶體設定檔設定 MQTT 訊息代理程式,請在 Azure IoT 作業部署期間指定 Broker 資源的規格中的記憶體設定檔欄位。

遵循部署 Azure IoT 作業的指南時,請在 [組態] 區段中查看 MQTT 訊息代理程式設定,並尋找 [記憶體配置檔] 設定。 在這裡,您可以從下拉式清單中選取可用的記憶體配置檔。

螢幕快照,顯示 Azure 入口網站 設定記憶體配置檔的位置。

有幾個記憶體配置檔可供選擇,每個配置檔都有不同的記憶體使用量特性。

微小

使用此設定檔時:

  • 每個前端複本的記憶體使用量上限約為 99 MiB,但實際的記憶體使用量上限可能較高。
  • 每個後端復本的記憶體使用量上限大約是 102 MiB 乘以後端背景工作角色的數目,但實際的記憶體使用量上限可能較高。

使用此設定檔時的建議:

  • 應該只使用一個前端。
  • 用戶端不應該傳送大型封包。 您應該只傳送小於 4 MiB 的封包。

使用此設定檔時:

  • 每個前端複本的記憶體使用量上限約為 387 MiB,但實際的記憶體使用量上限可能較高。
  • 每個後端複本的記憶體使用量上限約為 390 MiB 乘以後端背景工作角色的數目,但實際的記憶體使用量上限可能較高。

使用此設定檔時的建議:

  • 應該只使用一或兩個前端。
  • 用戶端不應該傳送大型封包。 您應該只傳送小於 10 MiB 的封包。

中是預設設定檔。

  • 每個前端複本的記憶體使用量上限約為 1.9 GiB,但實際的記憶體使用量上限可能較高。
  • 每個後端複本的記憶體使用量上限約為 1.5 GiB 乘以後端背景工作角色的數目,但實際的記憶體使用量上限可能較高。

  • 每個前端複本的記憶體使用量上限約為 4.9 GiB,但實際的記憶體使用量上限可能較高。
  • 每個後端複本的記憶體使用量上限約為 5.8 GiB 乘以後端背景工作角色的數目,但實際的記憶體使用量上限可能較高。

基數和 Kubernetes 資源限制

若要防止叢集中的資源耗盡,代理程式預設會設定為 要求 Kubernetes CPU 資源限制。 相應增加複本或背景工作角色的數目,會增加所需的CPU資源。 如果叢集中沒有足夠的 CPU 資源,就會發出部署錯誤。 這有助於避免要求代理程式基數沒有足夠的資源以最佳方式執行的情況。 它也有助於避免潛在的CPU爭用和Pod收回。

MQTT 訊息代理程式目前要求每個前端背景工作角色一個 (1.0) 個 CPU 單位,每個後端背景工作角色要求兩個 (2.0) 個 CPU 單位。 如需詳細資訊,請參閱 Kubernetes CPU 資源單位

例如,下列基數會要求下列 CPU 資源:

  • 針對前端:每個前端 Pod 2 個 CPU 單位,總計 6 個 CPU 單位。
  • 針對後端:每個後端 Pod 4 個 CPU 單位(適用於兩個後端背景工作角色)、2 次(備援因數)、3 次(分割區數目),總計 24 個 CPU 單位。
{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

若要停用此設定,請將 generateResourceLimits.cpu Broker 資源中的欄位設定為 Disabled

Azure 入口網站 不支援變更generateResourceLimits欄位。 若要停用此設定,請使用 Azure CLI。

多節點部署

為了確保具有多節點部署的高可用性和復原能力,Azure IoT Operations MQTT 訊息代理程式會自動設定 後端 Pod 的反親和性規則

這些規則是預先定義的,而且無法修改。

反親和性規則的目的

反親和性規則可確保來自相同分割區的後端 Pod 不會在相同的節點上執行。 這有助於分散負載,並針對節點失敗提供復原能力。 具體而言,來自相同分割區的後端Pod彼此具有反親和性。

驗證反親和性設定

若要驗證後端 Pod 的反親和性設定,請使用下列命令:

kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15

輸出會顯示反親和性組態,如下所示:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: chain-number
            operator: In
            values:
            - "1"
        topologyKey: kubernetes.io/hostname
      weight: 100

這些是訊息代理程式唯一設定的反親和性規則。

下一步