Bonjour, lecteurs Habr ! Dans le dernier article, nous avons parlé d'un moyen simple de reprise après sinistre dans les systèmes de stockage AERODISK ENGINE : la réplication. Dans cet article, nous aborderons un sujet plus complexe et intéressant : le metrocluster, c'est-à-dire un moyen de protection automatisée contre les catastrophes pour deux centres de données, permettant aux centres de données de fonctionner en mode actif-actif. Nous allons vous le dire, vous le montrer, le casser et le réparer.
Comme d'habitude, la théorie d'abord
Un métrocluster est un cluster réparti sur plusieurs sites au sein d’une ville ou d’une région. Le mot « cluster » nous laisse clairement entendre que le complexe est automatisé, c'est-à-dire que la commutation des nœuds du cluster en cas de panne se produit automatiquement.
C’est là que réside la principale différence entre un métrocluster et une réplication régulière. Automatisation des opérations. Autrement dit, en cas de certains incidents (panne du centre de données, canaux cassés, etc.), le système de stockage effectuera de manière indépendante les actions nécessaires afin de maintenir la disponibilité des données. Lors de l'utilisation de répliques standards, ces actions sont effectuées entièrement ou partiellement manuellement par l'administrateur.
Quel est-il?
L'objectif principal poursuivi par les clients lorsqu'ils utilisent certaines implémentations de metrocluster est de minimiser le RTO (Recovery Time Objective). Autrement dit, minimiser le temps de récupération des services informatiques après une panne. Si vous utilisez une réplication régulière, le temps de récupération sera toujours plus long que le temps de récupération avec un metrocluster. Pourquoi? Très simple. L'administrateur doit être à son bureau et changer de réplication manuellement, et le metrocluster le fait automatiquement.
Si vous n'avez pas d'administrateur dédié en service qui ne dort pas, ne mange pas, ne fume pas, ne tombe pas malade et surveille l'état du système de stockage 24 heures sur XNUMX, il n'y a aucun moyen de garantir que l'administrateur le fera. être disponible pour une commutation manuelle en cas de panne.
En conséquence, le RTO en l'absence d'un metrocluster ou d'un administrateur immortel du 99ème niveau du service de service d'administrateur sera égal à la somme du temps de commutation de tous les systèmes et de la période maximale après laquelle l'administrateur est assuré de commencer à travailler. avec les systèmes de stockage et les systèmes associés.
Ainsi, nous arrivons à la conclusion évidente que le metrocluster doit être utilisé si le RTO requis est de quelques minutes, et non d'heures ou de jours. Autrement dit, lorsqu'en cas de panne de centre de données la plus grave, le service informatique doit fournir à l'entreprise du temps. pour restaurer l'accès aux services informatiques en quelques minutes, voire quelques secondes.
Comment ça marche?
Au niveau inférieur, le metrocluster utilise un mécanisme de réplication synchrone des données, que nous avons décrit dans l'article précédent (voir. ). La réplication étant synchrone, les exigences correspondantes correspondent, ou plutôt :
- fibre optique comme physique, Ethernet 10 gigabits (ou supérieur) ;
- la distance entre les centres de données ne dépasse pas 40 kilomètres ;
- le délai du canal optique entre les centres de données (entre les systèmes de stockage) peut atteindre 5 millisecondes (idéalement 2).
Toutes ces exigences sont de nature consultative, c'est-à-dire que le metrocluster fonctionnera même si ces exigences ne sont pas remplies, mais il faut comprendre que les conséquences du non-respect de ces exigences sont égales à un ralentissement du fonctionnement des deux systèmes de stockage en le métrocluster.
Ainsi, une réplique synchrone est utilisée pour transférer des données entre les systèmes de stockage, et comment les répliques basculent-elles automatiquement et, plus important encore, comment éviter le split-brain ? Pour ce faire, à un niveau supérieur, une entité supplémentaire est utilisée : un arbitre.
Comment fonctionne un arbitre et quelle est sa mission ?
L'arbitre est une petite machine virtuelle ou un cluster matériel qui doit être lancé sur un site tiers (par exemple, dans un bureau) et donner accès au système de stockage via ICMP et SSH. Après le lancement, l'arbitre doit définir l'adresse IP, puis, du côté du stockage, indiquer son adresse, ainsi que les adresses des contrôleurs distants qui participent au metrocluster. Après cela, l'arbitre est prêt à travailler.
L'arbitre surveille en permanence tous les systèmes de stockage du metrocluster et si un système de stockage particulier est indisponible, après avoir confirmé l'indisponibilité d'un autre membre du cluster (l'un des systèmes de stockage « live »), il décide de lancer la procédure de changement de règles de réplication. et la cartographie.
Un point très important. L'arbitre doit toujours être situé sur un site différent de ceux sur lesquels se trouvent les systèmes de stockage, c'est-à-dire ni dans le data center 1, où le système de stockage 1 est installé, ni dans le data center 2, où le système de stockage 2 est installé.
Pourquoi? Car c’est la seule façon pour un arbitre, avec l’aide de l’un des systèmes de stockage survivants, de déterminer sans ambiguïté et avec précision la chute de l’un des deux sites où sont installés les systèmes de stockage. Toute autre méthode de placement d'un arbitre peut entraîner une division du cerveau.
Passons maintenant aux détails du travail de l'arbitre.
L'arbitre exécute plusieurs services qui interrogent constamment tous les contrôleurs de stockage. Si le résultat du sondage diffère du précédent (disponible/indisponible), alors il est enregistré dans une petite base de données, qui fonctionne également sur l'arbitre.
Examinons plus en détail la logique du travail de l'arbitre.
Étape 1 : Déterminez l’indisponibilité. Un événement de défaillance du système de stockage est l’absence de ping de la part des deux contrôleurs du même système de stockage dans un délai de 5 secondes.
Étape 2. Démarrez la procédure de commutation. Une fois que l'arbitre s'est rendu compte que l'un des systèmes de stockage n'est pas disponible, il envoie une requête au système de stockage « actif » afin de s'assurer que le système de stockage « mort » est bien mort.
Après avoir reçu une telle commande de l'arbitre, le deuxième système de stockage (en direct) vérifie en outre la disponibilité du premier système de stockage tombé et, s'il n'y est pas, envoie une confirmation à l'arbitre de sa supposition. Le système de stockage est en effet indisponible.
Après avoir reçu cette confirmation, l'arbitre lance une procédure à distance pour changer de réplication et augmenter le mappage sur les répliques qui étaient actives (primaires) sur le système de stockage tombé en panne, et envoie une commande au deuxième système de stockage pour faire passer ces répliques de secondaire à primaire et augmenter la cartographie. Eh bien, le deuxième système de stockage exécute donc ces procédures, puis donne accès aux LUN perdus depuis lui-même.
Pourquoi une vérification supplémentaire est-elle nécessaire ? Pour le quorum. Autrement dit, la majorité du nombre total impair (3) de membres du cluster doit confirmer la chute de l'un des nœuds du cluster. Ce n’est qu’à ce moment-là que cette décision sera définitivement correcte. Ceci est nécessaire pour éviter une commutation erronée et, par conséquent, un cerveau divisé.
L'étape de temps 2 prend environ 5 à 10 secondes. Ainsi, en tenant compte du temps nécessaire pour déterminer l'indisponibilité (5 secondes), dans les 10 à 15 secondes suivant l'accident, les LUN du système de stockage tombé seront automatiquement disponibles pour travailler avec le système sous tension. système de stockage.
Il est clair que pour éviter de perdre les connexions avec les hôtes, il faut également veiller à configurer correctement les timeouts sur les hôtes. Le délai d'attente recommandé est d'au moins 30 secondes. Cela empêchera l'hôte de rompre la connexion au système de stockage lors d'une commutation de charge en cas de sinistre et garantira qu'il n'y aura pas d'interruptions d'E/S.
Attendez une seconde, il s'avère que si tout va si bien avec le metrocluster, pourquoi avons-nous besoin d'une réplication régulière ?
En réalité, tout n’est pas si simple.
Considérons les avantages et les inconvénients du metrocluster
Ainsi, nous avons réalisé que les avantages évidents du metrocluster par rapport à la réplication conventionnelle sont :
- Automatisation complète, garantissant un temps de récupération minimal en cas de sinistre ;
- C'est tout :-).
Et maintenant, attention, les inconvénients :
- Coût de la solution. Bien que le metrocluster dans les systèmes Aerodisk ne nécessite pas de licence supplémentaire (la même licence est utilisée que pour la réplique), le coût de la solution sera toujours encore plus élevé que celui de la réplication synchrone. Vous devrez mettre en œuvre toutes les exigences pour une réplique synchrone, ainsi que les exigences pour le métrocluster associé à une commutation supplémentaire et à un site supplémentaire (voir planification du métrocluster) ;
- Complexité de la solution. Le metrocluster est beaucoup plus complexe qu'une réplique classique et nécessite beaucoup plus d'attention et d'efforts pour la planification, la configuration et la documentation.
En fin de compte. Metrocluster est certainement une bonne solution très avancée sur le plan technologique lorsque vous avez vraiment besoin de fournir un RTO en quelques secondes ou minutes. Mais s'il n'y a pas de telle tâche et que le RTO en heures est acceptable pour les affaires, alors cela n'a aucun sens de tirer sur des moineaux avec un canon. La réplication habituelle entre ouvriers et paysans est suffisante, car un cluster métropolitain entraînera des coûts supplémentaires et une complication de l'infrastructure informatique.
Planification du métrocluster
Cette section ne prétend pas être un guide complet pour la conception d'un métrocluster, mais montre uniquement les principales orientations qui devraient être élaborées si vous décidez de construire un tel système. Par conséquent, lors de la mise en œuvre effective d'un métrocluster, veillez à impliquer le fabricant du système de stockage (c'est-à-dire nous) et d'autres systèmes associés pour les consultations.
Plateformes
Comme indiqué ci-dessus, un métrocluster nécessite un minimum de trois sites. Deux centres de données où fonctionneront les systèmes de stockage et les systèmes associés, ainsi qu'un troisième site où travaillera l'arbitre.
La distance recommandée entre les centres de données ne dépasse pas 40 kilomètres. Une distance plus grande est très susceptible d'entraîner des retards supplémentaires, ce qui est extrêmement indésirable dans le cas d'un metrocluster. Rappelons que les délais doivent aller jusqu'à 5 millisecondes, bien qu'il soit conseillé de les maintenir dans la limite de 2.
Il est recommandé de vérifier également les retards pendant le processus de planification. Tout fournisseur plus ou moins mature qui fournit de la fibre optique entre les centres de données peut organiser un contrôle qualité assez rapidement.
Quant aux délais avant l'arbitre (c'est-à-dire entre le troisième site et les deux premiers), le seuil de délai recommandé peut aller jusqu'à 200 millisecondes, c'est-à-dire qu'une connexion VPN d'entreprise classique sur Internet convient.
Commutation et mise en réseau
Contrairement au schéma de réplication, où il suffit de connecter des systèmes de stockage provenant de différents sites, le schéma metrocluster nécessite de connecter des hôtes aux deux systèmes de stockage situés sur des sites différents. Pour que la différence soit plus claire, les deux schémas sont présentés ci-dessous.
Comme le montre le diagramme, les hôtes de notre site 1 examinent à la fois le système de stockage 1 et le système de stockage 2. De plus, au contraire, les hôtes du site 2 examinent à la fois le système de stockage 2 et le système de stockage 1. Autrement dit, chaque hôte voit les deux systèmes de stockage. C’est une condition préalable au fonctionnement du métrocluster.
Bien entendu, il n’est pas nécessaire de connecter chaque hôte avec un cordon optique à un autre centre de données ; aucun port ni cordon ne suffira. Toutes ces connexions doivent être effectuées via des commutateurs Ethernet 10G+ ou FibreChannel 8G+ (FC sert uniquement à connecter des hôtes et des systèmes de stockage pour les IO, le canal de réplication n'est actuellement disponible que via IP (Ethernet 10G+).
Quelques mots maintenant sur la topologie du réseau. Un point important est la configuration correcte des sous-réseaux. Il est nécessaire de définir immédiatement plusieurs sous-réseaux pour les types de trafic suivants :
- Sous-réseau de réplication sur lequel les données seront synchronisées entre les systèmes de stockage. Il peut y en avoir plusieurs, dans ce cas ce n'est pas grave, tout dépend de la topologie actuelle du réseau (déjà implémentée). S’il y en a deux, alors évidemment le routage doit être configuré entre eux ;
- Sous-réseaux de stockage via lesquels les hôtes accéderont aux ressources de stockage (s'il s'agit d'iSCSI). Il devrait y avoir un tel sous-réseau dans chaque centre de données ;
- Contrôlez les sous-réseaux, c'est-à-dire trois sous-réseaux routables sur trois sites à partir desquels les systèmes de stockage sont gérés, et l'arbitre s'y trouve également.
Nous ne considérons pas ici les sous-réseaux pour accéder aux ressources de l'hôte, car ils dépendent fortement des tâches.
Séparer les différents trafics en différents sous-réseaux est extrêmement important (il est particulièrement important de séparer la réplique des E/S), car si vous mélangez tout le trafic dans un sous-réseau « épais », alors ce trafic sera impossible à gérer, et dans les conditions de deux centres de données peuvent toujours entraîner différentes options de collision de réseau. Nous n'approfondirons pas cette question dans le cadre de cet article, puisque vous pouvez lire sur la planification d'un réseau étendu entre les centres de données sur les ressources des fabricants d'équipements de réseau, où cela est décrit de manière très détaillée.
Configuration de l'arbitre
L'arbitre doit donner accès à toutes les interfaces de gestion du système de stockage via les protocoles ICMP et SSH. Vous devriez également penser à la sécurité de l'arbitre. Il y a ici une nuance.
Le basculement par l’arbitre est hautement souhaitable, mais pas obligatoire. Que se passe-t-il si l'arbitre tombe au mauvais moment ?
- Le fonctionnement du metrocluster en mode normal ne changera pas, car arbtir n'a absolument aucun effet sur le fonctionnement du metrocluster en mode normal (sa tâche est de basculer la charge entre les centres de données en temps opportun)
- De plus, si l'arbitre, pour une raison ou une autre, tombe et « dort » lors d'un accident dans le centre de données, aucun changement ne se produira, car il n'y aura personne pour donner les commandes de commutation nécessaires et organiser le quorum. Dans ce cas, le metrocluster se transformera en un schéma régulier avec réplication, qui devra être basculé manuellement lors d'un sinistre, ce qui affectera le RTO.
Qu’est-ce qui en découle ? Si vous avez vraiment besoin de garantir un RTO minimum, vous devez vous assurer que l'arbitre est tolérant aux pannes. Il existe deux options pour cela :
- Lancez une machine virtuelle avec un arbitre sur un hyperviseur tolérant aux pannes, heureusement tous les hyperviseurs adultes supportent la tolérance aux pannes ;
- Si sur le troisième site (dans un bureau conventionnel) vous êtes trop paresseux pour installer un cluster normal et qu'il n'y a pas de cluster hypervozor existant, alors nous avons fourni une version matérielle de l'arbitre, qui est réalisée dans un boîtier 2U dans lequel deux ordinaires Les serveurs x-86 fonctionnent et peuvent survivre à une panne locale.
Nous recommandons fortement de garantir la tolérance aux pannes de l'arbitre, malgré le fait que le metrocluster n'en a pas besoin en mode normal. Mais comme le montrent la théorie et la pratique, si vous construisez une infrastructure véritablement fiable et à l’épreuve des catastrophes, il est préférable de jouer la sécurité. Il est préférable de vous protéger, vous et votre entreprise, de la « loi de la méchanceté », c'est-à-dire de la défaillance à la fois de l'arbitre et de l'un des sites où se trouve le système de stockage.
Architecture des solutions
Compte tenu des exigences ci-dessus, nous obtenons l’architecture de solution générale suivante.
Les LUN doivent être répartis uniformément sur deux sites pour éviter une surcharge importante. Dans le même temps, lors du dimensionnement des deux centres de données, vous devez inclure non seulement le double du volume (ce qui est nécessaire pour stocker les données simultanément sur deux systèmes de stockage), mais également le double des performances en IOPS et en Mo/s afin d'éviter la dégradation des applications dans en cas de panne d'un des centres de données.
Par ailleurs, nous notons qu'avec une approche appropriée en matière de dimensionnement (c'est-à-dire à condition que nous ayons fourni les limites supérieures appropriées d'IOPS et de Mo/s, ainsi que les ressources CPU et RAM nécessaires), si l'un des systèmes de stockage du le cluster métropolitain échoue, il n'y aura pas de baisse sérieuse des performances dans des conditions travail temporaire sur un système de stockage.
Cela s'explique par le fait que lorsque deux sites fonctionnent simultanément, la réplication synchrone « consomme » la moitié des performances d'écriture, puisque chaque transaction doit être écrite sur deux systèmes de stockage (similaire au RAID-1/10). Ainsi, si l'un des systèmes de stockage tombe en panne, l'influence de la réplication disparaît temporairement (jusqu'à ce que le système de stockage défaillant soit restauré) et nous obtenons une multiplication par deux des performances d'écriture. Après le redémarrage des LUN du système de stockage défaillant sur le système de stockage en fonctionnement, cette double augmentation disparaît du fait que la charge apparaît des LUN de l'autre système de stockage, et nous revenons au même niveau de performances qu'avant le « tomber », mais seulement dans le cadre d'un seul chantier.
Avec l'aide d'un dimensionnement compétent, vous pouvez garantir des conditions dans lesquelles les utilisateurs ne ressentiront pas du tout la défaillance de l'ensemble d'un système de stockage. Mais nous le répétons encore une fois, cela nécessite un dimensionnement très soigné, pour lequel d'ailleurs vous pouvez nous contacter gratuitement :-).
Mettre en place un métrocluster
La configuration d'un metrocluster est très similaire à la configuration d'une réplication régulière, que nous avons décrite dans . Par conséquent, concentrons-nous uniquement sur les différences. Nous avons installé un banc en laboratoire basé sur l'architecture ci-dessus, uniquement dans une version minimale : deux systèmes de stockage connectés via Ethernet 10G, deux commutateurs 10G et un hôte qui regarde à travers les commutateurs les deux systèmes de stockage dotés de ports 10G. L'arbitre s'exécute sur une machine virtuelle.
Lors de la configuration des adresses IP virtuelles (VIP) pour une réplique, vous devez sélectionner le type VIP - pour metrocluster.
Nous avons créé deux liens de réplication pour deux LUN et les avons distribués sur deux systèmes de stockage : LUN TEST Primaire sur le système de stockage 1 (lien METRO), LUN TEST2 Primaire pour le système de stockage 2 (lien METRO2).
Pour eux, nous avons configuré deux cibles identiques (dans notre cas iSCSI, mais FC est également supporté, la logique de configuration est la même).
Système de stockage1 :
Système de stockage2 :
Pour les connexions de réplication, des mappages ont été effectués sur chaque système de stockage.
Système de stockage1 :
Système de stockage2 :
Nous avons configuré le multipath et l'avons présenté à l'hôte.
Mise en place d'un arbitre
Vous n'avez rien à faire de spécial avec l'arbitre lui-même, il vous suffit de l'activer sur le troisième site, de lui donner une IP et de configurer l'accès via ICMP et SSH. La configuration elle-même est effectuée à partir des systèmes de stockage eux-mêmes. Dans ce cas, il suffit de configurer l'arbitre une fois sur l'un des contrôleurs de stockage du metrocluster ; ces paramètres seront automatiquement distribués à tous les contrôleurs.
Dans la section Réplication à distance>> Metrocluster (sur n'importe quel contrôleur)>> le bouton « Configurer ».
Nous entrons l'IP de l'arbitre, ainsi que les interfaces de contrôle de deux contrôleurs de stockage distants.
Après cela, vous devez activer tous les services (le bouton « Tout redémarrer »). En cas de reconfiguration ultérieure, les services doivent être redémarrés pour que les paramètres prennent effet.
Nous vérifions que tous les services fonctionnent.
Ceci termine la configuration du metrocluster.
Essai de collision
Le crash test dans notre cas sera assez simple et rapide, puisque la fonctionnalité de réplication (commutation, cohérence, etc.) a été abordée dans . Ainsi, pour tester la fiabilité du metrocluster, il suffit de vérifier l'automatisation de la détection des pannes, de la commutation et l'absence de pertes d'enregistrement (arrêts d'E/S).
Pour ce faire, nous imitons une panne complète de l'un des systèmes de stockage en éteignant physiquement ses deux contrôleurs, après avoir d'abord commencé à copier un fichier volumineux sur le LUN, qui doit être activé sur l'autre système de stockage.
Désactivez un système de stockage. Sur le deuxième système de stockage, nous voyons des alertes et des messages dans les journaux indiquant que la connexion avec le système voisin a été perdue. Si des notifications via SMTP ou surveillance SNMP sont configurées, l'administrateur recevra les notifications correspondantes.
Exactement 10 secondes plus tard (visible sur les deux captures d'écran), la connexion de réplication METRO (celle qui était principale sur le système de stockage défaillant) est automatiquement devenue principale sur le système de stockage en fonctionnement. En utilisant le mappage existant, LUN TEST est resté disponible pour l'hôte, l'enregistrement a légèrement baissé (dans les 10 pour cent promis), mais n'a pas été interrompu.
Le test s'est terminé avec succès.
Résumer
La mise en œuvre actuelle du metrocluster dans les systèmes de stockage AERODISK Engine N-series permet de résoudre pleinement les problèmes où il est nécessaire d'éliminer ou de minimiser les temps d'arrêt des services informatiques et d'assurer leur fonctionnement 24/7/365 avec des coûts de main-d'œuvre minimes.
Nous pouvons bien sûr dire que tout cela n'est que théorie, conditions de laboratoire idéales, etc. MAIS nous avons un certain nombre de projets mis en œuvre dans lesquels nous avons implémenté des fonctionnalités de résilience aux catastrophes, et les systèmes fonctionnent parfaitement. L'un de nos clients assez connus, qui n'utilise que deux systèmes de stockage dans une configuration à l'épreuve des catastrophes, a déjà accepté de publier des informations sur le projet. Dans la prochaine partie, nous parlerons donc de la mise en œuvre au combat.
Merci, nous attendons avec impatience une discussion productive.
Source: habr.com