你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
配置有关高可用性、缩放和内存使用情况的代理设置
Broker 资源是定义 MQTT 代理的总体设置的主要资源。 它还确定运行 Broker 配置的 Pod 的数量和类型，例如前端和后端。 还可以使用 Broker 资源配置其内存配置文件。 自我修复机制内置于中转站中，它通常可以从组件故障中自动恢复。 例如，在配置为高可用性的 Kubernetes 群集中，节点会失败。
可以通过添加更多前端副本和后端分区来水平缩放 MQTT 代理。 前端副本负责接受来自客户端的 MQTT 连接并将其转发到后端分区。 后端分区负责存储消息并将消息传送到客户端。 前端 Pod 跨后端 Pod 分配消息流量，后端冗余因素确定数据副本数，以针对群集中的节点故障提供复原能力。
有关可用设置的列表，请参阅代理 API 参考。
配置缩放设置
重要
此设置要求修改代理资源，并且只能在初始部署时使用 Azure CLI 或 Azure 门户进行配置。 如果需要 Broker 配置更改，则需要新的部署。 若要了解详细信息，请参阅自定义默认代理。
若要配置 MQTT 代理的缩放设置，需要在 Azure IoT 操作部署期间指定代理资源时指定基数字段。
自动部署基数
若要在部署期间自动确定初始基数，请省略代理资源中的基数字段。
通过 Azure 门户部署 Azure IoT 操作时，尚不支持自动基数。 但是，可以手动将群集部署模式指定为“单节点”或“多节点”。 若要了解详细信息，请参阅部署 Azure IoT 操作。
MQTT 代理运营商将根据部署时可用的节点数自动部署适当的 Pod 数。 这对于不需要高可用性或缩放的非生产场景非常有用。
但是，这无法实现自动缩放。 运营商不会根据负载自动缩放 Pod 数。 运营商仅会根据群集硬件确定要部署的初始 Pod 数。 如前所述，基数只能在初始部署时设置，如果需要更改基数设置，则需要使用新的部署。
直接配置基数
若要直接配置基数设置，请指定每一个基数字段。
按照以下指南部署 Azure IoT 操作时，请在“配置”部分的“MQTT 代理配置”下进行查看。 在这里，可以指定前端副本、后端分区和后端工作线程的数量。
了解基数
基数表示一个集中特定实体的实例数。 在 MQTT 代理的上下文中，基数是指要部署的前端副本、后端分区和后端工作线程的数量。 基数设置用于横向缩放代理，并在出现 Pod 或节点故障时提升高可用性。
基数字段为嵌套字段，具有前端和后端链子字段。 每个子字段都有自己的设置。
前端
前端子字段定义前端 Pod 的设置。 两个主要设置包括：
副本：要部署的前端副本 (Pod) 数。 增加前端副本的数量可提供高可用性，以防某个前端 Pod 发生故障。
工作线程：每个副本的逻辑前端工作线程数。 每个工作线程最多可以使用一个 CPU 核心。
后端链
后端链子字段定义后端分区的设置。 三个主要设置包括：
分区：：要部署的分区数。 通过一个名为“分片”的过程，每个分区将负责一部分消息（按主题 ID 和会话 ID 划分）。 前端 Pod 会跨分区分配消息流量。 增加分区数会增加代理可以处理的消息数。
冗余因数：每个分区要部署的后端副本 (Pod) 数。 提高冗余系数会增加数据副本的数量，从而针对集群中的节点故障提供弹性。
工作线程：每个后端副本要部署的工作线程数。 增加每个后端副本的工作线程数会增加后端 Pod 可以处理的消息数。 每个工作线程最多可以使用 2 个 CPU 核心，因此在增加每个副本的工作线程数时要小心，一定不要超过群集中的 CPU 核心数。
注意事项
增加基数值后，代理处理更多连接和消息的能力通常会提高，并且可在发生 Pod 或节点故障时增强高可用性。 但是，这也会导致资源消耗量升高。 因此，在调整基数值时，请考虑内存配置文件设置和代理的 CPU 资源请求。 如果发现前端 CPU 使用率是瓶颈，则增加每个前端副本的工作线程数有助于提高 CPU 核心利用率。 如果后端 CPU 是瓶颈，则增加后端工作线程的数量有助于提高消息吞吐量。
例如，如果群集有 3 个节点，每个节点有 8 个 CPU 核心，请将前端副本数设置为与节点数 (3) 相匹配，并将工作线程数设置为 1。 将后端分区数设置为与节点数 (3) 相匹配，并将后端工作线程数设置为 1。 根据需要设置冗余因数（2 或 3）。 如果发现前端 CPU 是瓶颈，请增加前端工作线程的数量。 请记住，后端和前端工作线程可能会相互以及与其他 Pod 争用 CPU 资源。
配置内存配置文件
重要
此设置要求修改代理资源，并且只能在初始部署时使用 Azure CLI 或 Azure 门户进行配置。 如果需要 Broker 配置更改，则需要新的部署。 若要了解详细信息，请参阅自定义默认代理。
若要配置 MQTT 代理的内存配置文件设置，需要在 Azure IoT 操作部署期间指定代理资源时指定内存配置文件字段。
按照以下指南部署 Azure IoT 操作时，请在“配置”部分的“MQTT 代理配置”下进行查看，找到“内存配置文件”字段。 在这里，可以从下拉列表中选择可用的内存配置文件。
有几个内存配置文件可供选择，每个配置文件都有不同的内存使用特征。
小型
使用此配置文件时：
- 每个前端副本的最大内存使用量约为 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 字段设置为 Disabled。
多节点部署
为了确保使用多节点部署实现高可用性和复原能力，Azure IoT 操作 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
这些是为代理设置的唯一反相关性规则。