L'infrastructure de cloud public a transformé de nombreux aspects de la stratégie informatique, mais une chose reste constante: l'importance vitale de haute disponibilité (HA). Lorsque les données sont votre affaire, comme c'est le cas pour toutes les entreprises 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 d'intérêt 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.
Sur site, la haute disponibilité s'appuie 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, de sorte qu'en cas de panne de l'appareil, la connexion du client peut basculer de manière transparente d'un appareil à l'autre. Il existe quelques mécanismes différents qui peuvent être utilisés pour éloigner les adresses IP flottantes des périphériques défaillants. Par exemple, la plate-forme BIG-IP de F5 Networks et Qumulo File Fabric utilisent 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 le routage asynchrone afin que seul un appareil actif 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.
Dans les 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 le risque d'abus tels que l'empoisonnement du cache ARP (également connu sous le nom d'usurpation d'ARP ou routage empoisonné ARP). Cela signifie que toutes les appliances sur site que vous utilisiez et qui s'appuyaient sur les 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é dans le cloud.
Essayez Qumulo for AWS pour expérimenter le stockage de fichiers 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 utilisée par NetApp ONTAP pour le basculement IP dans AWS. En tant qu'architecture de stockage évolutive classique, NetApp s'appuie sur des nœuds jumelés où les données sont constamment mises en miroir d'un nœud à l'autre. Dans ce cas, vous maintenez 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 où, au lieu de payer des frais mensuels relativement bas, vous couvrez votre risque en achetant une deuxième voiture entière en cas de problème avec la première. Ces déploiements peuvent être exécutés dans des configurations actives/en veille ou actives/actives ; les deux exigent que les données soient entièrement répliquées. Maintenant, 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 Cloud Manager 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 au basculement. Le gestionnaire de cloud surveille les échecs, puis fait basculer le routage IP de l'actif à l'état de 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. En faire la clé de voûte de votre stratégie HA 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 agile, Qumulo est en mesure de vraiment réfléchir à la bonne solution à chaque problème, aussi difficile soit-il, et de la construire pour nos clients. Compte tenu de la complexité et des risques 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 le basculement IP conçu spécifiquement pour le cloud. La clé est d'utiliser les fonctionnalités disponibles dans chacune des plates-formes de cloud public. Par exemple, nous utilisons les API AWS de n'importe quel membre fonctionnel du cluster pour basculer une adresse IP flottante d'un membre du cluster en panne vers un membre fonctionnel. De cette façon, nous avons évité d'ajouter une autre couche de complexité et d'éviter d'introduire un point de défaillance unique qui peut facilement devenir un goulot d'étranglement. Comme avantage supplémentaire, notre approche élimine le besoin d'un cluster de secours redondant, ce qui réduit considérablement le coût de la haute disponibilité.
Maintenant, vous vous demandez peut-être pourquoi vous devriez vous soucier de la haute disponibilité dans le cloud public étant donné les assurances comme celles-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.
NetApp ONTAP sert de récit édifiant sur le déplacement de la technologie héritée 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 bien faire les choses 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.
