haute disponibilité
IBM Cloud® Messages for RabbitMQ est un service géré de messages de cloud, entièrement intégré dans les environnements IBM Cloud. Le courtier de messages, le stockage et l'infrastructure de support s'exécutent tous dans IBM Cloud.
Configuration de cluster RabbitMQ
Messages for RabbitMQ fournit des fonctions de réplication, de basculement et de haute disponibilité pour protéger vos bases de données et vos données en cas de maintenance, de mises à niveau et d'échecs de l'infrastructure. Les déploiements contiennent un cluster à trois noeuds, dans lesquels les utilisateurs, les hôtes virtuels, les files d'attente, les échanges, les liaisons, les paramètres d'exécution et autre état distribué sont partagés sur les trois noeuds. En cas d'échec d'un noeud, le noeud est supprimé ou redémarré, puis ce noeud (ou un nouveau noeud) est resynchronisé dans le cluster. Votre déploiement reste disponible pour traiter les messages pendant la resynchronisation, bien qu'il s'agisse d'un processus qui consommera beaucoup de mémoire. Pour plus d'informations, voir la page Performances .
RabbitMQ -Remarques sur les ressources
En tant que courtier de messages implémenté dans Erlang, RabbitMQ dépend entièrement des coeurs d'UC pour planifier ses processus. Si trop peu de coeurs sont disponibles pour exécuter ces processus, les performances peuvent en pâtir. Si trop peu de ressources d'UC sont disponibles pour les traiter, RabbitMQ ferme les connexions. Prenez en compte cpu-contention et choisissez une configuration de ressource qui fournit suffisamment de coeurs d'UC pour RabbitMQ exécuté en tant que système de production. Le fait d'avoir des ressources d'UC dédiées dans votre déploiement RabbitMQ empêche également l'impact des voisins bruyants sur les ressources, telles que l'UC et la mémoire.
Configuration de files d'attente à haute disponibilité
L'hôte virtuel par défaut est configuré pour mettre en miroir ses files d'attente sur tous les noeuds du cluster afin de fournir une haute disponibilité. La haute
disponibilité dans RabbitMQ est définie par la règle. Vous pouvez afficher la règle dans l'interface utilisateur RabbitMQ Management, l'API HTTPS ou rabbitmqadmin
lorsque vous vous connectez avec le compte administrateur.

Vous pouvez modifier la haute disponibilité en ajoutant une règle et en la définissant avec une priorité plus élevée. Cependant, la règle par défaut ne peut pas être retirée. Tout hôte virtuel supplémentaire n'a pas de règle de haute disponibilité définie par défaut. Vous devez ajouter une règle de haute disponibilité à tous vos hôtes virtuels.
Files d'attente quorum
La haute disponibilité peut être gérée avec des files d'attente quorum. L'utilisation de files d'attente quorum peut améliorer considérablement la haute disponibilité d'un déploiement, en particulier dans les cas où les files d'attente existent à long terme et où leur durabilité est plus importante que les autres fonctions. Les files d'attente quorum gèrent la haute disponibilité en conservant un quorum utilisant l'algorithme de consensus Raft, et le noeud principal en cours et la plupart des répliques s'entendent sur le contenu de la file d'attente. En cas de problème sur le noeud principal, les répliques élisent le noeud principal suivant.
La documentation RabbitMQ Documentation couvre les cas d'utilisationet explique comment implémenter des files d'attente de quorum dans votre cluster.
Files d'attente en miroir
Bien que les files d'attente quorum soient préférées, la configuration par défaut dans RabbitMQ 4 et les versions précédentes utilise des files d'attente miroir. Les files d'attente en miroir sont configurées avec chaque file d'attente contenant un élément principal sur un membre du cluster, et des miroirs des files d'attente existent sur les autres membres du cluster. Les messages publiés dans la file d'attente vont d'abord sur la version principale puis sont répliqués sur les versions en miroir. En cas de problème sur le noeud principal, la version en miroir synchronisée la plus ancienne est promue au rang de version principale.
Haute disponibilité pour votre application
Les applications qui communiquent par le biais de réseaux et de services cloud sont sujettes à des pannes de connexion transitoires. De plus, comme Messages for RabbitMQ est un service géré, des mises à jour régulières et des opérations de maintenance de base de données sont effectuées dans le cadre de son fonctionnement normal. Ces opérations peuvent provoquer des petits problèmes de connectivité, voire une interruption de connexion passagère.
Vous souhaitez concevoir vos applications de telle manière qu'elles gèrent les pertes temporaires de connectivité avec votre déploiement ou avec IBM Cloud.
La documentation RabbitMQ offre une vue d'ensemble de ce que vous pouvez faire pour rendre vos applications robustes et stables dans la liste de contrôle de production, sous la section Applications. Elle comprend des conseils généraux sur la gestion et le rétablissement des connexions.
RabbitMQ et les pilotes RabbitMQ prennent en charge plusieurs fonctions pour vous aider à concevoir une application résiliente.
- Consumer Acknowledgments and Publisher Concabinets -pour s'assurer que les messages sont envoyés et reçus, et pour intercepter et récupérer les situations où ils ne le sont pas.
- Heartbeats et TCP Keepalives -Utilisation des paramètres de signal de présence et de signal de présence lorsque votre application se connecte peut détecter et empêcher les connexions zombies.
- Notifications d'annulation de consommateur -détecte et gère les instances où un consommateur cesse de consommer à partir d'une file d'attente.
Messages for RabbitMQ est également fourni avec le plug-in Shovel. Ce plug-in peut traiter les messages de connexion, de lecture et d'écriture, ainsi que les échecs de connexion et la rediffusion.
Une interruption de connexion ou une non-disponibilité de la base de données pendant plusieurs minutes n'est pas censée se produire. Ouvrez un ticket de demande de service en fournissant des détails si vous constatez des pertes de connectivité de plus d'une minute.
Limites de connexion Messages for RabbitMQ
À disposition, Messages for RabbitMQ a quatre nœuds finaux différents et définit le nombre maximal de connexions par nœud et pour chaque nœud final comme suit :
- HTTPS : 1024 x 3 noeuds = 3072
- AMQPS : 20000 x 3 noeuds = 60000
- MQTTS : 20000 x 3 noeuds = 60000
- STOMPS : 20000 x 3 noeuds = 60000
Si le nombre de connexions à la base de données est supérieur à la limite du nombre de connexions fixé, les nouvelles connexions échouent et renvoient une erreur.
Surveillance de la haute disponibilité
Messages for RabbitMQ dispose d'une intégration à IBM Log Analysis pour vous permettre de consulter des journaux en direct ou des historiques.
Vérifier les journaux de votre déploiement vous aide à surveiller l'état de la haute disponibilité et de la réplication pour votre déploiement. Si vous rencontrez des problèmes persistants avec vos applications, les journaux peuvent également vous aider à comprendre ce qu'il se passe sur vos bases de données lorsque vous rencontrez des incidents de connexion ou d'autres interruptions.
Guide de fiabilité de RabbitMQ
La documentation RabbitMQ fournit un excellent Guide de fiabilité qui couvre un large éventail de sujets liés à l'amélioration du fonctionnement de votre cluster et à la résilience de vos données. Elle couvre également les fonctions dont vous disposez en tant qu'utilisateur pour surveiller le déploiement, les connexions, les files d'attente et les messages pour assurer le bon déroulement des opérations.
Haute disponibilité, reprise après incident et accord sur les niveaux de service
Les déploiements Messages for RabbitMQ sont conformes aux conditions d'utilisation relatives à la haute disponibilité, la reprise après incident et l'accord sur les niveaux de service pour IBM Cloud Databases.