L'infrastructure de cloud public a transformé de nombreux aspects de la stratégie informatique, mais une chose reste constante: l'importance vitale de la haute disponibilité dans le nuage. Lorsque les données sont votre affaire, comme c'est le cas pour toute entreprise aujourd'hui, toute perte peut avoir des conséquences désastreuses. Vous devez faire tout votre possible pour minimiser ce risque. Naturellement, la haute disponibilité est un domaine clé pour les fournisseurs de stockage à la fois sur site et dans le cloud, mais tous les fournisseurs n'adoptent pas la même approche. Comprendre quelles sont les différences et pourquoi elles sont importantes est essentiel pour faire le bon choix pour vos données et votre entreprise.
La haute disponibilité repose sur des astuces réseau intelligentes
Sur site, la haute disponibilité repose généralement sur quelques astuces réseau intelligentes. L'un d'eux est le concept d'adresses IP flottantes : une ou plusieurs adresses IP qui n'appartiennent pas uniquement à un appareil, mais sont partagées entre un groupe d'appareils. Les clients utilisent ces adresses IP flottantes pour accéder au contenu servi par les appareils en cluster. Ainsi, en cas de panne de l'appareil, la connexion du client peut basculer en toute transparence d'un appareil à un autre. Il existe quelques mécanismes différents qui peuvent être utilisés pour écarter les adresses IP flottantes des appareils défaillants. Par exemple, la plate-forme BIG-IP de F5 Networks et le Qumulo Tissu de fichiers utilisez une technique appelée ARP gratuit pour prendre en charge une adresse IP flottante qui était auparavant desservie par un autre nœud. D'autres systèmes utilisent un routage asynchrone afin que seul un appareil en direct reçoive le trafic. Dans les deux cas, c'est le réseau lui-même qui active la fonctionnalité de basculement transparent d'un nœud présentant des problèmes vers un nœud qui fonctionne.
In environnements de cloud public, vous ne possédez ni ne contrôlez le réseau. Ici, c'est Amazon, Microsoft ou Google qui décident des fonctionnalités à activer. Pour Amazon Web Services (AWS), ces choix incluent la désactivation d'ARP afin d'éviter les risques d'abus tels que l'empoisonnement du cache ARP (également connu sous le nom d'usurpation d'identité ARP ou de routage ARP poison). Cela signifie que toutes les appliances sur site que vous avez utilisées et qui reposent sur des ARP pour la haute disponibilité ne fonctionneront pas. Par conséquent, les fournisseurs d'infrastructure doivent trouver une approche différente pour la haute disponibilité du cloud.
Essayez Qumulo for AWS pour expérimenter le stockage de fichiers dans le cloud.
Options de haute disponibilité dans le cloud
Les options de haute disponibilité dans le cloud se résument à deux approches de base : vous pouvez soit trouver une solution de contournement essentiellement similaire à ce que vous avez fait sur site, soit écrire une nouvelle méthode spécifique au cloud pour le basculement IP.
Un exemple de solution de contournement est la méthode NetApp ONTAP utilise pour le basculement IP dans AWS. En tant qu'architecture de stockage évolutive classique, NetApp s'appuie sur des nœuds appariés où les données sont constamment mises en miroir d'un nœud à l'autre. Dans ce cas, vous conservez effectivement deux copies de votre magasin de données, ce qui entraîne des coûts de calcul, de stockage et de logiciel pour le nœud utilisé et le nœud inutilisé. Considérez-le comme une forme d'assurance automobile dans laquelle, au lieu de payer des frais mensuels relativement bas, vous couvrez vos risques en achetant une deuxième voiture entière au cas où quelque chose se passerait mal avec la première. Ces déploiements peuvent être exécutés dans des configurations active/en veille ou active/active ; les deux exigent que les données soient entièrement répliquées. Désormais, ce déploiement lui-même ne fournit pas de basculement IP ; pour cela, vous devez déployer un troisième système de calcul appelé NetApp Cloud Manager.
Le gestionnaire de cloud est une instance t2.micro (indiquée comme le « médiateur » ci-dessus) dédiée à la gestion de la configuration des systèmes ONTAP et à la fourniture de basculement. Le gestionnaire de cloud surveille une défaillance, puis bascule le routage IP de l'actif vers le mode veille selon les besoins. Cela semble très bien jusqu'à ce que nous examinions de plus près le t2.micro, un type d'instance AWS EC2 avec seulement 1 vCPU et 1 Go de RAM. Faire de cela le pivot de votre stratégie de haute disponibilité signifie passer d'un point de défaillance unique du nœud actif à un point de défaillance unique encore plus petit dans le mécanisme de basculement lui-même.
En tant qu'éditeur de logiciels agiles, Qumulo est en mesure de réfléchir à la bonne solution à chaque problème, quelle que soit sa difficulté, et de la créer pour nos clients. Compte tenu de la complexité et du risque de l'approche ONTAP de la haute disponibilité dans le cloud, nous sommes partis de zéro et avons trouvé une méthode plus simple et plus fiable.
Au lieu d'essayer d'intégrer de force un modèle sur site dans un environnement de cloud public, nous avons spécialement conçu un basculement IP conçu pour le cloud. La clé est d'utiliser les fonctionnalités disponibles dans chacune des plateformes de cloud public. Par exemple, nous utilisons les API AWS de n'importe quel membre actif du cluster pour transférer une adresse IP flottante d'un membre du cluster en panne à un membre fonctionnel. De cette façon, nous avons évité d'ajouter une autre couche de complexité, et également évité d'introduire un point de défaillance unique qui peut facilement devenir un goulot d'étranglement. En tant qu'avantage supplémentaire, notre approche élimine le besoin d'un cluster de secours redondant, réduisant considérablement le coût de la haute disponibilité.
Pourquoi vous devez vous soucier de la haute disponibilité dans le cloud
Maintenant, vous vous demandez peut-être pourquoi vous devriez vous soucier de la haute disponibilité dans le cloud public étant donné les assurances comme ceux-ci d'Amazon:
«Les volumes Amazon EBS sont conçus pour un taux de défaillance annuel (AFR) compris entre 0.1% et 0.2%, où l'échec fait référence à une perte totale ou partielle du volume, en fonction de la taille et des performances du volume. … Par exemple, si vous avez 1,000 1 volumes EBS en cours d'exécution pendant 1 an, vous devez vous attendre à ce que 2 à XNUMX échoue. »
La vraie question est de savoir pourquoi, quand éviter la perte de données est un problème résolu sur site, vous accepteriez même un ou deux volumes EBS perdus par an dans le cloud. Quelle que soit votre activité, que ce soit dans les médias et les divertissements, la recherche en génomique, la conduite autonome ou même quelque chose d'aussi simple que les dossiers personnels, vos données sont précieuses. Que pourrait contenir ces volumes EBS que vous perdez chaque année? Comment leur perte affectera-t-elle votre entreprise? Il n'y a aucun moyen de savoir - et c'est un risque qu'aucune entreprise ne peut se permettre de prendre avec désinvolture.
Et les assurances d'Amazon ne tiennent même pas compte des taux de défaillance des nœuds de calcul, qui peuvent être plus élevés que vous ne le pensez. Les instances EC2 peuvent échouer pour diverses raisons intéressantes. Un cas commun résulte du fait que AWS est, à la base, un centre de données de matériel partagé. Si une pièce de matériel subit une maintenance ou est mise hors service, votre instance EC2 devra être déplacée, ce qui entraînera un redémarrage. Un exemple encore plus simple est le cas où le composant matériel sous-jacent comporte une défaillance qui entraîne le déplacement de toutes les instances qu'il héberge vers un autre matériel, ce qui entraîne le redémarrage de ces instances. Tout redémarrage entraînera une défaillance temporaire du nœud. Le trafic devra donc basculer sur un nœud actif.
Si un nœud de calcul tombe en panne, ONTAP basculera du nœud actif vers le nœud restant. À moins, bien sûr, que le gestionnaire de nuage NetApp t2.micro échoue. Si cela se produit, vous avez perdu le contrôle du trafic aérien pour tout votre trafic de stockage dans le cloud public, et rien ne permet de déplacer les clients d'un nœud défaillant vers le nœud restant. Maintenant, vous avez un vrai problème. NetApp Cloud Manager ajoute une nouvelle condition d’échec à l’éventail des risques liés à un nœud défaillant. Nous pouvons certainement nous attendre à mieux pour nos architectures d'entreprise de prochaine génération.
Un récit édifiant…
NetApp ONTAP sert de mise en garde sur le transfert des technologies héritées vers le cloud public sans tenir compte des différences inhérentes à ces environnements. L'approche cloud native de Qumulo permet de survivre aux pannes de disque et de nœud sans introduire de complexité supplémentaire et sans coût excessif. En prenant le temps de faire les choses de la bonne manière pour chaque type d'infrastructure (sur site et cloud public), nous pouvons fournir la haute disponibilité simple et fiable dont vous avez besoin pour les données dont dépend votre entreprise.
