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 vos données sont votre entreprise, comme c'est le cas pour toutes les entreprises, toute perte peut avoir des conséquences désastreuses. Vous devez faire tout ce que vous pouvez pour minimiser ce risque. Naturellement, les fournisseurs de stockage, qu'ils soient sur site ou dans le cloud, se concentrent sur le HA, mais tous les fournisseurs n'adoptent pas la même approche. Comprendre les différences et leur importance est essentiel pour faire le bon choix pour vos données et votre entreprise.

Sur place, HA 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 n'appartenant pas uniquement à un périphérique, mais partagées entre un cluster de périphériques. Les clients utilisent ces adresses IP flottantes pour accéder au contenu servi par les périphériques en cluster. En cas de défaillance du périphérique, la connexion du client peut ainsi basculer de manière transparente d'un périphérique à un autre. Différents mécanismes peuvent être utilisés pour écarter 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 toutes deux une technique appelée ARP gratuite 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, de sorte que seul un périphérique actif reçoit du trafic. Dans les deux cas, c'est le réseau lui-même qui active les fonctionnalités permettant un basculement transparent d'un nœud présentant des problèmes vers un nœud opérationnel.

Dans les environnements de cloud public, vous ne possédez ni ne contrôle le réseau. Ici, c'est Amazon, Microsoft ou Google qui dicte les fonctionnalités à activer. Pour Amazon Web Services (AWS), ces choix incluent la désactivation de l'ARP afin d'éviter le risque d'abus tels que l'empoisonnement du cache ARP (également appelé usurpation ARP ou routage du poison ARP). Cela signifie que toutes les appliances sur site que vous utilisez et qui reposent sur les ARPs pour HA ne fonctionnent pas. Par conséquent, les fournisseurs d'infrastructure doivent trouver une approche différente pour le cloud HA.

Essayez Qumulo for AWS pour expérimenter le stockage de fichiers dans le cloud.

Les options pour HA dans le cloud se déclinent en deux approches de base: vous pouvez soit trouver une solution de contournement essentiellement similaire à celle que vous avez effectuée sur site, soit écrire une nouvelle méthode spécifique au cloud pour le basculement IP.

La méthode utilisée par NetApp ONTAP pour le basculement IP dans AWS est un exemple de solution de contournement. 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 conservez efficacement deux copies de votre magasin de données, entraînant 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 le premier. Ces déploiements peuvent être exécutés dans des configurations actives / de secours ou actives / actives; les deux nécessitent que les données soient répliquées intégralement. Maintenant, ce déploiement lui-même ne fournit pas le basculement IP; pour cela, vous devez déployer un troisième système de calcul appelé NetApp Cloud Manager.

cloud haute disponibilité

Cloud Manager est une instance de t2.micro (présentée comme le «médiateur» ci-dessus) dédiée à la gestion de la configuration des systèmes ONTAP et au basculement. Cloud Manager recherche un incident, puis active le routage IP du serveur actif vers le serveur de secours, selon les besoins. Cela semble bien aller jusqu'à ce que nous examinions de plus près le t2.micro, un type d'instance AWS EC2 avec juste 1 vCPU et 1 Go de RAM. Faire en sorte que le pivot 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.

cloud haute disponibilité

En tant que société de logiciels agile, Qumulo est en mesure de réfléchir à la solution adaptée à chaque problème, quel que soit son niveau de complexité, et de le développer pour nos clients. Compte tenu de la complexité et du risque de l’approche ONTAP en matière de haute disponibilité dans le cloud, nous sommes partis de rien et avons trouvé une méthode plus simple et plus fiable.

Au lieu d'essayer de forcer un modèle sur site dans un environnement de cloud public, nous avons conçu un basculement IP spécifiquement conçu pour le cloud. La clé est d'utiliser les fonctionnalités disponibles dans chacune des plates-formes de cloud public. Par exemple, nous utilisons des API AWS provenant de n'importe quel membre actif du cluster pour basculer une adresse IP flottante d'un membre de cluster défaillant vers un membre opérationnel. De cette manière, nous avons évité d’ajouter un autre niveau de complexité et nous avons é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, ce qui réduit considérablement le coût de la haute disponibilité.

Maintenant, vous vous demandez peut-être pourquoi vous devriez vous préoccuper de HA dans le cloud public, avec des garanties comme celles-ci d'Amazon:

«Les volumes Amazon EBS sont conçus pour un taux de défaillance annuel (AFR) compris entre 0.1% - 0.2%, où la défaillance fait référence à une perte complète ou partielle du volume, en fonction de la taille et des performances du volume. … Par exemple, si vous avez des volumes 1,000 EBS en cours d'exécution pour l'année 1, vous devriez vous attendre à ce que 1 à 2 échoue.

La vraie question est de savoir pourquoi, en évitant que la perte de données soit 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 le divertissement, 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. Qu'est-ce qui pourrait être dans 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 constitue une mise en garde sur le transfert de la technologie héritée vers le cloud public sans prendre en compte les différences inhérentes à ces environnements. L'approche native de Qumulo permet de survivre aux pannes de disques et de nœuds sans ajouter de complexité et sans coûts excessifs. En prenant le temps de faire les choses de la manière qui convient à chaque type d'infrastructure (sur site et dans le cloud public), nous pouvons vous proposer le HA simple et fiable dont vous avez besoin pour les données dont votre entreprise dépend.

aws-cloud-trial

Partager avec votre réseau