Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Options de déploiement pour Amazon MQ pour les courtiers RabbitMQ
Les agents RabbitMQ peuvent être créés en tant qu'agent à instance unique ou dans un déploiement en cluster. Pour les deux modes de déploiement, Amazon MQ offre une durabilité élevée en stockant ses données de manière redondante.
Vous pouvez accéder à vos courtiers RabbitMQ en utilisant n'importe quel langage de programmation pris en charge par RabbitMQ et en activant
Rubriques
Option 1 : courtier à instance unique Amazon MQ pour RabbitMQ
Un broker à instance unique est composé d'un courtier dans une zone de disponibilité derrière un Network Load Balancer NLB (). Le broker communique avec votre application et avec un volume EBS de stockage Amazon. Amazon EBS fournit un stockage par blocs optimisé pour une faible latence et un débit élevé.
L'utilisation d'un Network Load Balancer garantit que le point de terminaison de votre courtier Amazon MQ pour RabbitMQ reste inchangé si l'instance de courtier est remplacée pendant une période de maintenance ou en raison de défaillances matérielles Amazon sous-jacentes. EC2 Un dispositif d'équilibrage de charge de réseau permet à vos applications et utilisateurs de continuer à utiliser le même point de terminaison pour se connecter à l'agent.
Le diagramme suivant illustre un agent à instance unique Amazon MQ for RabbitMQ.
Option 2 : déploiement du cluster Amazon MQ pour RabbitMQ
Un déploiement en cluster est un regroupement logique de trois nœuds d'agent RabbitMQ derrière un dispositif d'équilibrage de charge de réseau, chacun partageant des utilisateurs, des files d'attente et un état distribué sur plusieurs zones de disponibilité (AZ).
Dans un déploiement en cluster, Amazon MQ gère automatiquement les politiques d'agent pour activer la mise en miroir classique sur tous les nœuds, garantissant ainsi une haute disponibilité (HA). Chaque file d'attente en miroir se compose d'un nœud principal et d’un ou plusieurs miroirs. Chaque file d'attente a son propre nœud principal. Toutes les opérations d'une file d'attente donnée sont d'abord appliquées sur le nœud principal de la file d'attente, puis propagées aux miroirs. Amazon MQ crée une politique système par défaut qui définit ha-mode sur all et ha-sync-mode sur automatic. Cela garantit que les données sont répliquées sur tous les nœuds du cluster dans différentes zones de disponibilité pour une meilleure durabilité.
Note
Lors d'une fenêtre de maintenance, toute la maintenance d'un cluster est effectuée un nœud à la fois, gardant au moins deux nœuds en cours d'exécution à tout moment. Chaque fois qu'un nœud est arrêté, les connexions client à ce nœud sont coupées et doivent être rétablies. Vous devez vous assurer que votre code client est conçu pour se reconnecter automatiquement à votre cluster. Pour plus d'informations sur la connectivité à distance, consultez Restauration automatique des défaillances du réseau.
Parce qu'Amazon MQ définit ha-sync-mode: automatic au cours d'une fenêtre de maintenance, les files d'attente se synchronisent lorsque chaque nœud rejoint le cluster. La synchronisation de la file d'attente bloque toutes les autres opérations de file Vous pouvez atténuer l'impact de la synchronisation des files d'attente pendant les fenêtres de maintenance en gardant les files d'attente courtes.
La politique par défaut ne doit pas être supprimée. Si vous supprimez cette politique, Amazon MQ la recréera automatiquement. Amazon MQ s'assure également que les propriétés de haute disponibilité sont appliquées à toutes les autres politiques que vous créez sur un agent en cluster. Si vous ajoutez une politique sans les propriétés de haute disponibilité, Amazon MQ les ajoutera pour vous. Si vous ajoutez une politique avec différentes propriétés de haute disponibilité, Amazon MQ les remplacera. Pour plus d'informations sur la mise en miroir classique, consultez Files d'attente classiques mises en miroir
Le schéma suivant illustre le déploiement d'un courtier de cluster RabbitMQ avec trois nœuds répartis dans trois zones de disponibilité (AZ), chacune ayant son propre EBS volume Amazon et un état partagé. Amazon EBS fournit un stockage par blocs optimisé pour une faible latence et un débit élevé.
