Certaines entreprises ne peuvent pas autoriser l'interruption de leurs services. En cas de panne de serveur, un opérateur de téléphonie mobile peut subir une indisponibilité du système de facturation entraînant une perte de connexion pour tous ses clients. L'admission de l'impact potentiel de telles situations conduit à l'idée de toujours avoir un plan B.
Dans cet article, nous mettons en lumière différents moyens de protection contre les pannes de serveur, ainsi que les architectures utilisées pour le déploiement de VMmanager Cloud, un panneau de contrôle pour la construction d'un cluster haute disponibilité.
Préface
La terminologie dans le domaine de la tolérance aux clusters diffère d'un site Web à l'autre. Afin d'éviter de mélanger différents termes et définitions, décrivons ceux qui seront utilisés dans l'article en question :
- La tolérance aux pannes (FT) est la capacité d'un système à poursuivre son fonctionnement après la défaillance de l'un de ses composants.
- Cluster est un groupe de serveurs (nœuds de cluster) connectés via des canaux de communication.
- Fault Tolerant Cluster (FTC) est un cluster où la panne d'un serveur n'entraîne pas l'indisponibilité complète de l'ensemble du cluster. Les fonctions du nœud défaillant sont automatiquement réaffectées entre les nœuds restants.
- La disponibilité continue (CA) signifie qu'un utilisateur peut utiliser le service sans rencontrer de délai d'attente. Peu importe depuis combien de temps le nœud a échoué.
- La haute disponibilité (HA) signifie qu'un utilisateur peut rencontrer des délais d'attente de service en cas de panne de l'un des nœuds ; cependant, le système sera récupéré automatiquement avec un minimum de temps d'arrêt.
- Le cluster CA est un cluster à disponibilité continue.
- Le cluster HA est un cluster haute disponibilité.
Supposons qu'il soit nécessaire de déployer un cluster composé de 10 nœuds avec des machines virtuelles en cours d'exécution sur chaque nœud. L'objectif est de protéger les machines virtuelles après la panne du serveur. Les serveurs à double CPU sont utilisés pour maximiser la densité de calcul des racks.
À première vue, l'option la plus attrayante pour une entreprise consiste à déployer un cluster de disponibilité continue lorsqu'un service est encore provisionné après la panne de l'équipement. En effet, la disponibilité continue est indispensable si vous avez besoin de maintenir le fonctionnement d'un système de facturation ou d'automatiser un processus de production continu. Cependant, cette approche a aussi ses pièges et ses pièges qui sont couverts ci-dessous.
Disponibilité continue
La continuité d'un service n'est possible que si une copie exacte d'une machine physique ou virtuelle avec ce service est construite, qui est disponible à tout moment. Un tel modèle de redondance est appelé 2N. La création d'une copie du serveur après la panne de l'équipement prendrait du temps, ce qui entraînerait une expiration du service. De plus dans ce cas, il ne serait pas possible de récupérer le dump RAM du serveur défaillant, ce qui signifie que toutes les informations qu'il contient auraient disparu.
Deux méthodes sont utilisées pour fournir une autorité de certification :sur une couche matérielle et une couche logicielle. Concentrons-nous sur chacun d'eux plus en détail.
La méthode matérielle représente un double serveur où tous les composants sont dupliqués et les calculs sont exécutés simultanément et indépendamment. La synchronisation est réalisée en utilisant un nœud dédié qui vérifie les résultats provenant des deux parties. Si le nœud détecte une anomalie, il essaie de définir le problème et de corriger les erreurs. Si l'erreur ne peut pas être corrigée, le système éteint le module défaillant.
Stratus, un fabricant de serveurs CA, garantit que le temps d'arrêt global du système ne dépasse pas 32 secondes par an. De tels résultats peuvent être obtenus en utilisant l'équipement spécial. Selon les représentants de Stratus, le coût d'un serveur CA avec deux processeurs pour chaque module synchronisé est d'environ 160 000 $ selon les spécifications. Le prix étendu pour l'ensemble du cluster CA dans ce cas serait de 1 600 000 USD.
La méthode logicielle
L'outil logiciel le plus populaire pour le déploiement d'un cluster de disponibilité continue au moment de l'article est VMware vSphere. La technologie de disponibilité continue de ce produit est appelée Fault Tolerance.
Contrairement à la méthode matérielle, cette technologie a certaines exigences, telles que les suivantes :
- CPU sur l'hôte physique :
- Intel avec architecture Sandy Bridge (ou plus récente). Avoton n'est pas pris en charge.
- Bulldozer AMD (ou plus récent).
- Les machines avec tolérance aux pannes doivent être connectées à un réseau de 10 Go à faible latence. VMware recommande vivement d'utiliser un réseau dédié.
- Pas plus de 4 processeurs virtuels par machine virtuelle.
- Pas plus de 8 processeurs virtuels par hôte physique.
- Pas plus de 4 machines virtuelles par hôte physique.
- Les instantanés de la machine virtuelle ne sont pas disponibles.
- Storage vMotion n'est pas disponible.
La liste complète des limitations et des incompatibilités se trouve dans la documentation officielle.
La licence vSphere est basée sur des processeurs physiques. Le prix commence à 1750 $ par licence + 550 $ pour l'abonnement annuel et le support. L'automatisation de la gestion des clusters nécessite également VMware vCenter Server qui coûte plus de 8 000 $. Le modèle 2N est utilisé pour fournir une disponibilité continue, il est donc nécessaire d'acheter 10 serveurs répliqués avec des licences pour chacun d'eux afin de créer un cluster de 10 nœuds avec des machines virtuelles.
Le coût global du logiciel serait de 2[Nombre de CPU par serveur]*(10[Nombre de nœuds avec machines virtuelles]+10[Nombre de nœuds répliqués])*(1750+550)[Coût de la licence par chaque CPU]+8000 [Coût de VMware vCenter Server]=100 000 $. Tous les prix sont arrondis.
Les configurations de nœuds spécifiques ne sont pas décrites dans cet article car les composants du serveur diffèrent toujours en fonction de l'objectif du cluster. L'équipement du réseau n'est pas non plus décrit puisqu'il doit être identique dans tous les cas. Cet article se concentre sur les composants qui varieraient certainement, à savoir le coût de la licence.
Il est également important de mentionner les produits qui ne sont plus développés et pris en charge.
Le produit appelé Remus est basé sur la virtualisation Xen. Il s'agit d'une solution open source gratuite qui utilise la technologie micro snapshot. Malheureusement, sa documentation n'a pas été mise à jour depuis longtemps :le guide d'installation fournit des instructions pour Ubuntu 12.10 dont la fin de vie a été annoncée en 2014. Même la recherche Google n'a trouvé aucune entreprise qui utilisait Remus pour ses opérations.
Des tentatives ont été faites pour modifier QEMU afin de construire des clusters de disponibilité continue sur cette technologie. Il y a deux projets qui ont annoncé leur travail dans cette direction.
Le premier est Kemari, un produit open source dirigé par Yoshiaki Tamura. Ce projet visait à utiliser la migration QEMU en direct. Le dernier commit date de février 2011, ce qui suggère que le développement a atteint une impasse et ne se poursuivra pas.
Le deuxième produit est Micro Checkpointing, un projet open source fondé par Michael Hines. Aucune activité n'a été trouvée dans son journal des modifications au cours de l'année dernière, ce qui ressemble au projet Kemari.
Ces faits nous permettent de conclure qu'il n'y a tout simplement aucune possibilité de disponibilité continue sur la virtualisation KVM à ce jour.
Malgré tous les avantages des systèmes de disponibilité continue, il existe de nombreux obstacles au déploiement et à l'exploitation de telles solutions. Néanmoins, dans certains cas, la tolérance aux pannes peut être requise mais sans la nécessité d'être disponible en permanence. De tels scénarios permettent d'utiliser des clusters à haute disponibilité.
Haute disponibilité
Un cluster haute disponibilité offre une tolérance aux pannes en détectant automatiquement si le matériel est en panne et en lançant ensuite le service sur le nœud disponible.
La haute disponibilité ne prend pas en charge la synchronisation des processeurs lancés sur les nœuds et ne permet pas toujours de synchroniser les disques locaux. Dans cet esprit, il est recommandé de placer les lecteurs utilisés par les nœuds dans un stockage indépendant séparé, tel que le stockage réseau.
La raison est claire :le nœud est injoignable après sa panne et les informations de son périphérique de stockage ne peuvent pas être récupérées. Le système de stockage de données doit également être tolérant aux pannes, sinon il n'y a aucune possibilité de haute disponibilité. Par conséquent, le cluster Haute Disponibilité se compose de deux sous-clusters :
- Cluster informatique composé de nœuds avec des machines virtuelles
- Cluster de stockage avec disques utilisés par les nœuds de calcul.
À l'heure actuelle, les solutions suivantes sont utilisées pour implémenter des clusters à haute disponibilité avec des machines virtuelles sur des nœuds de cluster :
- Heartbeat, version 1. ? avec DRBD ;
- stimulateur cardiaque ;
- VMware vSphere ;
- Proxmox VE ;
- XenServer ;
- OpenStack ;
- oVirt ;
- Virtualisation d'entreprise Red Hat ;
- Cluster de basculement Windows Server avec rôle de serveur Hyper-V ;
- VMmanager Cloud.
Regardons de plus près VMmanager Cloud.
VMmanager Cloud
VMmanager Cloud est un produit qui permet de déployer des clusters à haute disponibilité et utilise la virtualisation QEMU-KVM. Cette technologie a été sélectionnée car elle est activement développée et supportée et permet d'installer n'importe quel système d'exploitation sur une machine virtuelle. Le produit utilise Corosync pour détecter la disponibilité du cluster. Si l'un des serveurs est en panne, VMmanager distribue ses machines virtuelles entre les nœuds restants un par un.
Dans sa forme simplifiée, ce mécanisme fonctionne comme suit :
- Le système identifie le nœud de cluster avec le plus petit nombre de machines virtuelles.
- Il vérifie s'il y a suffisamment de RAM pour localiser la machine.
- S'il y a suffisamment de mémoire sur un nœud pour la machine concernée, VMmanager crée une nouvelle machine virtuelle sur ce nœud.
- S'il n'y a pas assez de mémoire, le système vérifie les autres nœuds avec plus de machines virtuelles.
Le test de quelques configurations matérielles et l'enquête de nombreux utilisateurs actuels de VMmanager Cloud ont identifié qu'il faut normalement 45 à 90 secondes pour distribuer et restaurer le fonctionnement de toutes les machines virtuelles à partir du nœud défaillant, en fonction des performances de l'équipement.
Il est recommandé de dédier un ou quelques nœuds comme protection contre les situations d'urgence et de ne pas déployer de machines virtuelles sur ces nœuds pendant le fonctionnement de routine. Cela minimise les risques de manque de ressources sur les nœuds de cluster actifs pour l'ajout de machines virtuelles à partir du nœud défaillant. Dans le cas où un seul nœud de secours est utilisé, ce modèle de sécurité est appelé N+1.
VMmanager Cloud prend en charge les types de stockage suivants :système de fichiers, LVM, réseau LVM, iSCSI et Ceph [en particulier RBD (RADOS Block Device), l'une des implémentations de Ceph]. Les trois derniers sont utilisés pour la haute disponibilité.
Une licence à vie pour dix nœuds opérationnels et un nœud de sauvegarde coûte 3 520 €, soit 3 865 $ à ce jour (une licence coûte 320 € par nœud, quel que soit le nombre de CPU). La licence comprend un an de mises à jour gratuites; à partir de la deuxième année, des mises à jour sont fournies par modèle d'abonnement au prix de 880 € par an pour l'ensemble du cluster.
Voyons comment VMmanager Cloud a déjà été utilisé pour le déploiement de clusters à haute disponibilité.
Premieroctet
FirstByte a commencé à fournir l'hébergement cloud en février 2016. Initialement, leur cluster était construit sur OpenStack ; cependant, le manque de spécialistes de ce système en termes de disponibilité et de coût les a poussés à rechercher une solution alternative. Le nouveau système de construction d'un cluster Haute Disponibilité devait répondre aux exigences suivantes :
- Capacité à déployer des machines virtuelles KVM.
- Intégration avec Ceph.
- Intégration avec un système de facturation pour offrir les services existants.
- Coût de licence abordable.
- Assistance du développeur du logiciel.
VMmanager Cloud répond à toutes les exigences.
Caractéristiques distinctives du cluster FirstByte :
- Le transfert de données est basé sur la technologie Ethernet et l'équipement Cisco.
- Le routage est effectué à l'aide de Cisco ASR9001. Le cluster utilise environ 50 000 adresses IPv6.
- La vitesse de liaison entre les nœuds de calcul et les commutateurs est de 10 Gbit/s.
- La vitesse de transfert des données entre les commutateurs et les nœuds de stockage est de 20 Gbit/s, avec deux canaux combinés à 10 Gbit/s chacun.
- Une liaison distincte de 20 Gbit/s est utilisée entre les racks avec des nœuds de stockage pour la réplication.
- Des disques SAS en combinaison avec des SSD sont installés sur tous les nœuds de stockage.
- Le type de stockage est RBD.
La disposition du système est présentée ci-dessous :
Une telle configuration fonctionne pour l'hébergement de sites Web populaires, de serveurs de jeux et de bases de données avec une charge supérieure à la moyenne.
Premier VDS
FirstVDS fournit les services d'un cluster tolérant aux pannes qui a été lancé en septembre 2015.
VMmanager Cloud a été choisi pour ce cluster en raison des facteurs suivants :
- Expérience solide de l'utilisation des panneaux de contrôle ISPsystem.
- Intégration avec BILLmanager par défaut.
- Support technique de haute qualité.
- Intégration avec Ceph.
Leur cluster a les fonctionnalités suivantes :
- Le transfert de données est basé sur le réseau Infiniband avec une vitesse de connexion de 56 Gbit/s ;
- Le réseau Infiniband est construit sur des équipements Mellanox ;
- Les nœuds de stockage ont des disques SSD ;
- Le type de stockage est RBD.
Le système peut être agencé de la manière suivante :
En cas de panne du réseau Infiniband, la connexion entre le stockage sur disque VM et les serveurs informatiques est établie via le réseau Ethernet déployé sur l'équipement Juniper. La nouvelle connexion est établie automatiquement.
En raison de la vitesse de communication élevée avec le stockage, ce cluster fonctionne parfaitement pour l'hébergement de sites Web à très haut trafic, de streaming vidéo et de contenu, ainsi que de mégadonnées.
Conclusion
Résumons les principales conclusions de l'article.
Le cluster de disponibilité continue est indispensable lorsque chaque seconde d'indisponibilité entraîne des pertes substantielles. S'il est permis d'avoir une interruption de 5 minutes pendant le déploiement des machines virtuelles sur un nœud de sauvegarde, le cluster haute disponibilité peut être une bonne option pour réduire les coûts matériels et logiciels.
Il est également important de rappeler que la seule façon d'atteindre la tolérance aux pannes est la démesure. Assurez-vous de répliquer vos serveurs, vos équipements et liaisons de communication de données, vos canaux d'accès à Internet et votre alimentation. Répliquez tout ce que vous pouvez. De telles mesures permettent d'éliminer les goulots d'étranglement et les points de défaillance potentiels qui peuvent entraîner des temps d'arrêt de l'ensemble du système. En prenant les mesures ci-dessus, vous pouvez être sûr que vous disposez d'un cluster tolérant aux pannes et résistant aux pannes.
Si vous pensez que le modèle de haute disponibilité correspond à vos besoins et que VMmanager Cloud est un bon outil pour le réaliser, veuillez vous référer au manuel d'installation et à la documentation pour en savoir plus sur le système. Je vous souhaite des opérations continues et sans échec !