Merge pull request #290335 from jlian/release-aio-ga

Multi-node deployment + why use EVC/PVC

Author: prmerger-automator[bot]

articles/iot-operations/manage-mqtt-broker/howto-configure-availability-scale.md

@@ -7,7 +7,7 @@ ms.topic: how-to
 ms.subservice: azure-mqtt-broker
 ms.custom:
   - ignite-2023
-ms.date: 11/04/2024
+ms.date: 11/11/2024
 
 #CustomerIntent: As an operator, I want to understand the settings for the MQTT broker so that I can configure it for high availability and scale.
 ms.service: azure-iot-operations
@@ -121,6 +121,7 @@ The frontend subfield defines the settings for the frontend pods. The two main s
 - **Replicas**: The number of frontend replicas (pods) to deploy. Increasing the number of frontend replicas provides high availability in case one of the frontend pods fails.
 
 - **Workers**: The number of logical frontend workers per replica. Each worker can consume up to one CPU core at most.
+
 #### Backend chain
 
 The backend chain subfield defines the settings for the backend partitions. The three main settings are:
@@ -256,15 +257,42 @@ To learn more, see [Azure CLI support for advanced MQTT broker configuration](ht
 
 ---
 
-<!-- TODO -->
+## Multi-node deployment
+
+To ensure high availability and resilience with multi-node deployments, the Azure IoT Operations MQTT broker automatically sets [anti-affinity rules](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) for backend pods. 
+
+These rules are predefined and cannot be modified.
+
+### Purpose of anti-affinity rules
 
-<!-- ## Best practices
+The anti-affinity rules ensure that backend pods from the same partition don't run on the same node. This helps to distribute the load and provides resilience against node failures. Specifically, backend pods from the same partition have anti-affinity with each other.
 
-### Configuration required to ensure the backends and dataflow instances are scheduled on separate nodes/node-pools
+### Verifying anti-affinity settings
 
-### Load balancers required in front of the frontends
+To verify the anti-affinity settings for a backend pod, use the following command:
+
+```sh
+kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15
+```
+
+The output will show the anti-affinity configuration, similar to the following:
+
+```yaml
+affinity:
+  podAntiAffinity:
+    preferredDuringSchedulingIgnoredDuringExecution:
+    - podAffinityTerm:
+        labelSelector:
+          matchExpressions:
+          - key: chain-number
+            operator: In
+            values:
+            - "1"
+        topologyKey: kubernetes.io/hostname
+      weight: 100
+```
 
-### Self-healing and resilience -->
+These are the only anti-affinity rules set for the broker.
 
 ## Next steps
 

articles/iot-operations/manage-mqtt-broker/howto-disk-backed-message-buffer.md

@@ -6,7 +6,7 @@ ms.author: patricka
 ms.topic: how-to
 ms.service: azure-iot-operations
 ms.subservice: azure-mqtt-broker
-ms.date: 11/04/2024
+ms.date: 11/11/2024
 
 #CustomerIntent: As an operator, I want to configure MQTT broker so that I can modify the message queue behavior.
 ---
@@ -79,24 +79,33 @@ Tailor the broker message buffer options by adjusting the following settings:
 
 - **Configure the volume**: Specify a volume claim template to mount a dedicated storage volume for your message buffer.
 
-  - **Select a storage class**: Define the desired *StorageClass* using the `storageClassName` property.
+- **Select a storage class**: Define the desired *StorageClass* using the `storageClassName` property.
 
-  - **Define access modes**: Determine the access modes you need for your volume. For more information, see [persistent volume access modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1).
+- **Define access modes**: Determine the access modes you need for your volume. For more information, see [persistent volume access modes](https://kubernetes.io/docs/concepts/storage/persistent-volumes#access-modes-1).
 
 Use the following sections to understand the different volume modes: 
 
 - [Ephemeral volume](#ephemeral-volume) is the preferred option,
 - [Persistent volume](#persistent-volume) is preferred next, and 
 - [*`emptyDir`* volume](#emptydir-volume) least preferred.
 
-Both persistent volume and ephemeral volume are generally provided by the same storage classes. If you have both options, choose ephemeral. However, ephemeral requires Kubernetes 1.23 or higher.
+Both persistent and ephemeral volumes are generally provided by the same storage classes. If both options are available, choose ephemeral. Note that ephemeral volumes require Kubernetes 1.23 or higher.
 
-Finally, deploy the Azure IoT Operations using the `az iot ops create` command with the `--broker-config-file` flag. See the following command (other parameters omitted for brevity):
+> [!TIP]
+> Specifying a Ephemeral Volume Claim (EVC) or Persistent Volume Claim (PVC) template lets you to use a storage class of your choice, increasing flexibility for some deployment scenarios. For example, Persistent Volumes (PVs) provisioned using a PVC template appear in commands like `kubectl get pv`, which can be useful for inspecting the cluster state.
+> 
+> If your Kubernetes nodes lack sufficient local disk space for the message buffer, use a storage class that provides network storage like Azure Blobs. However, it's generally better to use local disk with a smaller `maxSize` value, as the message buffer benefits from fast access and doesn't require durability.
+
+### Deploy Azure IoT Operations with disk-backed message buffer
+
+To use disk-backed message buffer, deploy Azure IoT Operations using the `az iot ops create` command with the `--broker-config-file` flag. See the following command (other parameters omitted for brevity):
 
 ```azurecli
 az iot ops create ... --broker-config-file <FILE>.json
 ```
 
+This setting cannot be changed after deployment. To change the disk-backed message buffer configuration, redeploy the Azure IoT Operations instance.
+
 ## Ephemeral volume
 
 [Ephemeral volume](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes#generic-ephemeral-volumes) is the preferred option for your message buffer.