Hé Habr !
Après les vacances du Nouvel An, nous avons relancé un cloud à l'épreuve des sinistres basé sur deux sites. Aujourd'hui, nous allons vous expliquer comment cela fonctionne et montrer ce qui arrive aux machines virtuelles clientes lorsque des éléments individuels du cluster échouent et que l'ensemble du site plante (spoiler – tout va bien pour elles).
Système de stockage cloud résistant aux catastrophes sur le site OST.
Ce qui est à l'intérieur
Sous le capot, le cluster dispose de serveurs Cisco UCS avec un hyperviseur VMware ESXi, de deux systèmes de stockage INFINIDAT InfiniBox F2240, d'équipements réseau Cisco Nexus, ainsi que de commutateurs Brocade SAN. Le cluster est divisé en deux sites - OST et NORD, c'est-à-dire que chaque centre de données dispose d'un ensemble d'équipements identique. En fait, c’est ce qui le rend à l’épreuve des catastrophes.
Au sein d'un même site, les principaux éléments sont également dupliqués (hôtes, commutateurs SAN, mise en réseau).
Les deux sites sont reliés par des routes dédiées à la fibre optique, également réservées.
Quelques mots sur les systèmes de stockage. Nous avons créé la première version d'un cloud à l'épreuve des sinistres sur NetApp. Ici nous avons choisi INFINIDAT, et voici pourquoi :
- Option de réplication actif-actif. Il permet à la machine virtuelle de rester opérationnelle même en cas de panne complète de l'un des systèmes de stockage. Je vous en dirai plus sur la réplication plus tard.
- Trois contrôleurs de disque pour augmenter la tolérance aux pannes du système. Habituellement, il y en a deux.
- Solution prête. Nous avons reçu un rack pré-assemblé qu'il suffit de connecter au réseau et de configurer.
- Support technique attentif. Les ingénieurs d'INFINIDAT analysent en permanence les journaux et les événements du système de stockage, installent de nouvelles versions du micrologiciel et aident à la configuration.
Voici quelques photos du déballage :
Comment ça marche
Le cloud est déjà tolérant aux pannes en lui-même. Il protège le client contre les pannes matérielles et logicielles uniques. La résistance aux catastrophes aidera à se protéger contre les pannes massives au sein d'un site : par exemple, panne d'un système de stockage (ou d'un cluster SDS, ce qui arrive assez souvent 🙂), erreurs massives dans un réseau de stockage, etc. Eh bien, et le plus important : un tel cloud sauve lorsqu'un site entier devient inaccessible en raison d'un incendie, d'une panne de courant, d'une prise de contrôle par un raider ou d'un atterrissage extraterrestre.
Dans tous ces cas, les machines virtuelles clientes continuent de fonctionner, et voici pourquoi.
La conception du cluster est conçue de manière à ce que tout hôte ESXi doté de machines virtuelles client puisse accéder à l'un des deux systèmes de stockage. Si le système de stockage sur le site OST tombe en panne, les machines virtuelles continueront à fonctionner : les hôtes sur lesquels elles s'exécutent accéderont au système de stockage sur NORD pour les données.
Voici à quoi ressemble le schéma de connexion dans un cluster.
Ceci est possible grâce au fait qu'un lien inter-switch est configuré entre les structures SAN des deux sites : le commutateur SAN Fabric A OST est connecté au commutateur SAN Fabric A NORD, et de même pour les commutateurs SAN Fabric B.
Eh bien, pour que toutes ces subtilités des usines SAN aient un sens, la réplication Active-Active est configurée entre les deux systèmes de stockage : les informations sont écrites presque simultanément sur les systèmes de stockage local et distant, RPO = 0. Il s'avère que les données originales sont stockées sur un système de stockage et leur réplique est stockée sur un autre. Les données sont répliquées au niveau des volumes de stockage, et les données de la VM (ses disques, son fichier de configuration, son fichier d'échange, etc.) y sont stockées.
L'hôte ESXi considère le volume principal et sa réplique comme un seul périphérique de disque (périphérique de stockage). Il existe 24 chemins depuis l'hôte ESXi vers chaque périphérique de disque :
12 chemins le connectent au système de stockage local (chemins optimaux) et les 12 chemins restants au système de stockage distant (chemins non optimaux). Dans une situation normale, ESXi accède aux données sur le système de stockage local en utilisant des chemins « optimaux ». Lorsque ce système de stockage tombe en panne, ESXi perd les chemins optimaux et passe à des chemins « non optimaux ». Voilà à quoi cela ressemble sur le schéma.
Schéma d'un cluster à l'épreuve des catastrophes.
Tous les réseaux clients sont connectés aux deux sites via une structure réseau commune. Chaque site exécute un Provider Edge (PE), sur lequel les réseaux du client se terminent. Les PE sont réunis en un cluster commun. Si un PE échoue sur un site, tout le trafic est redirigé vers le deuxième site. Grâce à cela, les machines virtuelles du site laissé sans PE restent accessibles via le réseau au client.
Voyons maintenant ce qu'il adviendra des machines virtuelles clientes lors de diverses pannes. Commençons par les options les plus légères et terminons par la plus grave : l'échec de l'ensemble du site. Dans les exemples, la plateforme principale sera OST, et la plateforme de sauvegarde, avec les réplicas de données, sera NORD.
Qu'arrive-t-il à la machine virtuelle client si...
Le lien de réplication échoue. La réplication entre les systèmes de stockage des deux sites s'arrête.
ESXi ne fonctionnera qu'avec des périphériques de disque locaux (via des chemins optimaux).
Les machines virtuelles continuent de fonctionner.
L'ISL (Inter-Switch Link) se rompt. Le cas est peu probable. À moins qu'une excavatrice folle ne creuse simultanément plusieurs routes optiques, qui empruntent des routes indépendantes et sont amenées sur les sites par différentes entrées. Mais peu importe. Dans ce cas, les hôtes ESXi perdent la moitié des chemins et ne peuvent accéder qu'à leurs systèmes de stockage locaux. Les répliques sont collectées, mais les hôtes ne pourront pas y accéder.
Les machines virtuelles fonctionnent normalement.
Le commutateur SAN échoue sur l'un des sites. Les hôtes ESXi perdent certains chemins d'accès au système de stockage. Dans ce cas, les hôtes du site où le commutateur a échoué ne fonctionneront que via l'un de leurs HBA.
Les machines virtuelles continuent de fonctionner normalement.
Tous les commutateurs SAN sur l'un des sites échouent. Disons qu'un tel désastre s'est produit sur le site OST. Dans ce cas, les hôtes ESXi de ce site perdront tous les chemins d'accès à leurs périphériques de disque. Le mécanisme standard VMware vSphere HA entre en jeu : il redémarrera toutes les machines virtuelles du site OST dans NORD en 140 secondes maximum.
Les machines virtuelles exécutées sur les hôtes du site NORD fonctionnent normalement.
L'hôte ESXi échoue sur un site. Ici, le mécanisme vSphere HA fonctionne à nouveau : les machines virtuelles de l'hôte défaillant sont redémarrées sur d'autres hôtes - sur le même site ou sur un site distant. Le temps de redémarrage de la machine virtuelle peut aller jusqu'à 1 minute.
Si tous les hôtes ESXi du site OST échouent, il n'y a aucune option : les VM sont redémarrées sur un autre. L'heure de redémarrage est la même.
Le système de stockage tombe en panne sur un site. Disons que le système de stockage tombe en panne sur le site OST. Ensuite, les hôtes ESXi du site OST passent à l'utilisation de réplicas de stockage dans NORD. Une fois le système de stockage défaillant remis en service, une réplication forcée se produira et les hôtes ESXi OST recommenceront à accéder au système de stockage local.
Les machines virtuelles ont fonctionné normalement pendant tout ce temps.
L'un des sites échoue. Dans ce cas, toutes les machines virtuelles seront redémarrées sur le site de sauvegarde via le mécanisme vSphere HA. Le temps de redémarrage de la VM est de 140 secondes. Dans ce cas, tous les paramètres réseau de la machine virtuelle seront enregistrés et celle-ci restera accessible au client via le réseau.
Pour garantir le bon déroulement du redémarrage des machines du site de sauvegarde, chaque site n'est qu'à moitié plein. La seconde moitié est une réserve au cas où toutes les machines virtuelles quitteraient le deuxième site endommagé.
Un cloud résistant aux catastrophes, basé sur deux centres de données, protège contre de telles pannes.
Ce plaisir n'est pas bon marché, puisque, en plus des ressources principales, une réserve est nécessaire sur le deuxième site. Par conséquent, les services critiques pour l'entreprise sont placés dans un tel cloud, dont les temps d'arrêt à long terme entraînent d'importantes pertes financières et de réputation, ou si le système d'information est soumis aux exigences de résilience aux catastrophes des régulateurs ou des réglementations internes de l'entreprise.
Sources:
Source: habr.com