OpenStack est une plateforme de calcul cloud open source dont l'architecture inclut des services de calcul, de stockage et de réseau, offrant ainsi des capacités puissantes de virtualisation et des fonctions de gestion automatisée. Afin d'assurer une haute disponibilité de la plateforme OpenStack, il est nécessaire d'adopter certaines solutions architecturales et mesures techniques. Cet article présentera quelques solutions courantes d'architecture haute disponibilité d'OpenStack.
Haute disponibilité d'OpenStack
Pour comprendre comment atteindre une haute disponibilité, il est essentiel d'identifier les services qui sont sujets à des indisponibilités. Tout d'abord, familiarisons-nous avec la structure de base d'OpenStack.
OpenStack se compose de cinq composants majeurs : Compute (Nova), Gestion des identités (Keystone), Gestion des images (Glance), Gestion de l'interface (Dashboard) et Stockage d'objets (Swift).
Nova est le composant central chargé du calcul et du contrôle. Il comprend des services tels que nova-compute, nova-scheduler, nova-volume, nova-network et nova-api. Comme la plupart des autres systèmes distribués, OpenStack est divisé en deux types de nœuds : les nœuds de contrôle et les nœuds de calcul. Les nœuds de contrôle fournissent tous les services à l'exception de nova-compute. Ces composants et services peuvent être installés indépendamment, et différentes combinaisons peuvent être choisies selon les besoins.
Nova-compute s'exécute sur chaque nœud de calcul. Pour l'instant, supposons qu'il soit digne de confiance ; sinon, une machine de secours peut être utilisée pour la reprise après sinistre (bien que configurer une sauvegarde pour chaque nœud de calcul puisse s'avérer trop coûteuse par rapport aux avantages obtenus).
Haute disponibilité du nœud de contrôle
Garantir la haute disponibilité du nœud de contrôle constitue le défi principal, et différents composants ont leurs propres exigences et solutions spécifiques en matière de disponibilité.
(1) Que se passe-t-il si le nœud de contrôle tombe en panne, sachant qu'il n'y a qu'un seul nœud de contrôle qui gère et contrôle l'ensemble du système ?
Il s'agit d'un problème courant de point unique de défaillance (SPoF). La haute disponibilité ne peut pas être assurée uniquement avec une seule machine. Le plus souvent, une solution est conçue pour garantir une reprise rapide de la machine défaillante en cas de problème, bien que cela entraîne un coût plus élevé.
Pour résoudre le problème du point unique de défaillance, la solution typique consiste à utiliser des équipements redondants ou un système de secours actif. Étant donné que les pannes matérielles ou les erreurs humaines peuvent toujours provoquer la panne d'un ou plusieurs nœuds, et que la maintenance ou les mises à jour nécessitent parfois l'arrêt temporaire de certains nœuds, un système fiable doit être capable de supporter l'arrêt d'un ou plusieurs nœuds.
Les modes de déploiement courants incluent : le mode actif-passif, le mode actif-actif et le mode cluster
(2) Comment créer des nœuds de contrôle redondants ? Ou quelles autres méthodes permettent d'assurer une fiabilité élevée du contrôle ?
Beaucoup peuvent envisager la mise en œuvre d'un mode actif-passif, utilisant un mécanisme de heartbeat ou des méthodes similaires pour la sauvegarde, et atteindre une haute disponibilité grâce au basculement. OpenStack ne prend pas en charge nativement plusieurs nœuds de contrôle, donc Pacemaker exige que divers services implémentent eux-mêmes leurs propres mécanismes de sauvegarde, de surveillance et de basculement.
Une analyse plus approfondie des services fournis par le nœud de contrôle montre qu'ils comprennent principalement nova-api, nova-network, nova-scheduler, nova-volume, ainsi que Glance, Keystone et la base de données MySQL. Ces services sont fournis séparément. Nova-api, nova-network et Glance peuvent s'exécuter sur chaque nœud de calcul, RabbitMQ peut fonctionner en mode principal-secondaire, et MySQL peut utiliser un cluster redondant à haute disponibilité.
Les sections suivantes détaillent ces composants.
Solutions à haute disponibilité pour les composants clés
1) Haute disponibilité de nova-api et de nova-scheduler
Chaque nœud de calcul peut exécuter sa propre instance de nova-api et de nova-scheduler, assurant ainsi l'équilibrage de charge pour un fonctionnement correct. De cette manière, lorsque le nœud de contrôle tombe en panne, le nova-api et les services associés sur les nœuds de calcul continuent de fonctionner normalement.
2) Haute disponibilité de nova-volume
Actuellement, il n’existe pas de solution HA parfaite pour nova-volume, et davantage de travail est nécessaire. Toutefois, puisque nova-volume repose sur iSCSI, son intégration avec DRBD ou l’utilisation d’une solution matérielle hautement disponible basée sur iSCSI peuvent permettre d’atteindre une haute disponibilité.
3) Haute disponibilité des services réseau (nova-network)
OpenStack fournit déjà plusieurs solutions réseau haute disponibilité. Une approche couramment utilisée consiste à activer le mode haute disponibilité en utilisant l'option « Multi-hôte ». D'autres solutions courantes incluent le basculement (Failover), Multi-nic, la passerelle matérielle (Hardware Gateway) et Quantum.
4) Haute disponibilité de Glance et de Keystone
Les images OpenStack peuvent être stockées à l'aide de Swift, et Glance peut s'exécuter sur plusieurs hôtes. Pacemaker est une solution puissante de haute disponibilité pour la gestion des clusters multi-nœuds, permettant la commutation de service et la reprise après sinistre, et peut être utilisée avec Corosync et Heartbeat. Pacemaker prend en charge de manière flexible plusieurs modes tels que actif-passif, N+1 et N-N. En installant l'agent OCF sur chaque nœud, il peut déterminer si un autre nœud exécute correctement les services Glance et Keystone, aidant ainsi Pacemaker à démarrer, arrêter et surveiller ces services.
5) Grande disponibilité du stockage d'objets Swift
En général, le système de stockage d'objets distribué d'OpenStack, Swift, ne nécessite pas de configurations HA supplémentaires. Cela est dû au fait que Swift est conçu avec une architecture distribuée (sans nœud maître), des mécanismes de tolérance aux pannes, de redondance, de récupération des données, d'évolutivité et une haute disponibilité.
6) Haute disponibilité du service de file d'attente des messages (RabbitMQ)
En cas de défaillance de RabbitMQ, des messages peuvent être perdus. Plusieurs mécanismes de haute disponibilité peuvent être utilisés :
L'éditeur confirme que la méthode signale lorsque des données sont écrites sur le disque en cas d'échec.
Le mécanisme de cluster multi-nœuds peut être utilisé, mais les pannes de nœuds peuvent encore entraîner des pannes de file d'attente.
Le mode actif-passif garantit le basculement en cas de défaillance, mais le démarrage du nœud de secours peut entraîner des retards ou même des échecs.
Pour la reprise après sinistre et la disponibilité, RabbitMQ fournit des files d'attente persistantes qui stockent les messages non traités sur le disque en cas de panne du service de file d'attente. Afin d'éviter la perte de messages due aux retards entre l'envoi et l'écriture des messages, RabbitMQ introduit le mécanisme de confirmation de l'éditeur pour garantir que les messages soient effectivement écrits sur le disque.
Pour la prise en charge des clusters, RabbitMQ propose des modes Actif/Passif et Actif/Actif. Par exemple, en mode Actif/Passif, lorsque nœud échoue, le nœud passif est immédiatement activé et remplace rapidement le nœud actif défaillant afin de poursuivre la livraison des messages.
Construire un OpenStack hautement disponible
En général, la haute disponibilité est obtenue en établissant des redondances et des sauvegardes. Les stratégies courantes incluent :
Mode cluster. Sauvegarde mutuelle multi-machine, où chaque instance est sauvegardée plusieurs fois sans nœud central. Des exemples incluent le système de stockage d'objets distribué Swift et le mode multi-hôte de nova-network.
Mode autonome. Dans certains cas, le SPoF peut être résolu en permettant à chaque nœud de fonctionner indépendamment, éliminant ainsi les relations maître-esclave pour réduire l'impact d'un nœud de contrôle défaillant. Par exemple, nova-api n'est responsable que de son propre nœud.
Mode actif-passif. Ce modèle courant implique un nœud passif qui reste en état de veille et de secours, et prend le relais en cas de défaillance. Des exemples incluent les clusters MySQL haute disponibilité, ainsi que des services tels que Glance et Keystone, qui assurent la redondance via Pacemaker et Heartbeat.
Mode actif-actif. Dans ce mode, les nœuds se sauvegardent et se soutiennent mutuellement. Par exemple, RabbitMQ utilise un cluster haute disponibilité en mode actif-actif, dans lequel les nœuds du cluster peuvent répliquer des files d'attente. Sur le plan architectural, cette approche élimine les préoccupations liées à l'impossibilité de démarrage des nœuds passifs ou à des retards excessifs.
En résumé, l'optimisation et les améliorations d'OpenStack évoluent en permanence, et son déploiement ainsi que ses applications sont davantage explorés et développés. Le réglage pratique est essentiel : de bonnes conceptions et idées doivent être validées par des tests dans des conditions réelles.
Protection renforcée d'OpenStack
Bien qu'OpenStack réduise le risque de défaillance unique dans le système grâce à une architecture redondante et hautement disponible, la protection des données reste essentielle. Afin d'assurer la continuité des activités, il est nécessaire d'adopter une solution de sauvegarde professionnelle permettant d'éviter la perte de données et les conséquences des défaillances catastrophiques.
Vinchin Backup & Recovery est une solution de sauvegarde OpenStack robuste offrant des fonctionnalités sans agent et efficaces, telles que la déduplication des données, la compression, les sauvegardes incrémentielles, la récupération au niveau des fichiers et l'archivage dans le cloud, etc. Elle garantit une restauration rapide, une intégration transparente avec OpenStack et une solide sécurité des données, en faisant un choix idéal pour la gestion et la protection des environnements cloud.
En outre, le chiffrement des données et la protection contre les logiciels rançongéniques vous offrent une double sécurité pour protéger vos sauvegardes de machines virtuelles OpenStack. Vous pouvez également simplement migrer des données d'un hôte OpenStack vers une autre plateforme virtuelle (comme VMware, Hyper-V, Proxmox, XenServer, oVirt, AWS EC2...) et vice-versa.
La sauvegarde d'une machine virtuelle OpenStack avec Vinchin Backup & Recovery ne nécessite que les 4 étapes suivantes :
1. Sélectionner l'objet de sauvegarde.
2. Sélectionnez la destination de la sauvegarde.
3. Configurer les stratégies de sauvegarde.
4. Passer en revue et soumettre le travail.
Vinchin Backup & Recovery est utilisé par des milliers d'entreprises. Commencez dès aujourd'hui votre essai gratuit de 60 jours !
Foire aux questions sur la haute disponibilité d'OpenStack
1. Qu'est-ce qu'une zone de disponibilité dans OpenStack ?
Dans OpenStack, une zone de disponibilité (AZ) est une partition logique au sein d'un environnement cloud qui aide à répartir les charges de travail pour une meilleure tolérance aux pannes et une gestion optimale des ressources. Chaque AZ constitue un domaine de panne isolé, ce qui signifie que les instances situées dans différentes AZ sont moins susceptibles d'être affectées par les mêmes défaillances matérielles ou réseau. Les AZ sont généralement utilisées pour regrouper des nœuds de calcul, tandis que les services de stockage et de réseau peuvent également disposer de leurs propres zones afin d'assurer une résilience et une redondance accrues. Les utilisateurs peuvent spécifier une AZ lors du lancement d'instances pour optimiser les performances et la fiabilité.
2. OpenStack est-il un logiciel en tant que service (SaaS) ou une plate-forme en tant que service (PaaS) ?
OpenStack est principalement une plateforme IaaS. Elle fournit des ressources de calcul, de stockage et de réseau virtualisées, permettant aux utilisateurs de déployer et de gérer une infrastructure cloud. Bien qu'OpenStack puisse prendre en charge des solutions PaaS en exécutant des services tels que Kubernetes ou Cloud Foundry par-dessus, sa fonction principale est de fournir de l'IaaS plutôt que du SaaS ou du PaaS.
Conclusion
L'assurance d'une haute disponibilité dans OpenStack nécessite une combinaison de stratégies architecturales et de solutions techniques permettant d'éliminer les points uniques de défaillance et d'améliorer la résilience du système. En mettant en œuvre des modes actif-passif et actif-actif, en exploitant des techniques de clustering et en optimisant les composants clés tels que Nova, Glance, Keystone et RabbitMQ, OpenStack peut atteindre une infrastructure cloud tolérante aux pannes et hautement fiable. De plus, les solutions de stockage distribuées telles que Swift fournissent naturellement de la redondance et de la résilience.
