Salut tout le monde! Avec cet article, AERODISK ouvre un blog sur Habré. Hourra, camarades!
Les articles précédents sur Habré traitaient de questions sur l'architecture et la configuration de base des systèmes de stockage. Dans cet article, nous examinerons une question qui n'a pas été abordée auparavant, mais qui est souvent posée : la tolérance aux pannes des systèmes de stockage AERODISK ENGINE. Notre équipe fera tout pour que le système de stockage AERODISK cesse de fonctionner, c'est à dire. casse le.
Il se trouve que des articles sur l'histoire de notre entreprise, sur nos produits, ainsi qu'un exemple de mise en œuvre réussie sont déjà accrochés sur Habré, pour lesquels Un grand merci à nos partenaires - les sociétés TS Solution et Softline.
Par conséquent, je n'entraînerai pas ici les compétences en gestion du copier-coller, mais je fournirai simplement des liens vers les originaux de ces articles :
Je veux aussi partager une bonne nouvelle. Mais je commencerai bien sûr par le problème. En tant que jeune fournisseur, nous sommes, entre autres coûts, constamment confrontés au fait que de nombreux ingénieurs et administrateurs ne savent tout simplement pas comment faire fonctionner correctement notre système de stockage.
Il est clair que la gestion de la plupart des systèmes de stockage est à peu près la même du point de vue de l’administrateur, mais chaque fabricant a ses propres caractéristiques. Et nous ne faisons pas exception ici.
Ainsi, afin de simplifier la tâche de formation des informaticiens, nous avons décidé de consacrer cette année à l'enseignement gratuit. Pour ce faire, nous ouvrons dans de nombreuses grandes villes de Russie un réseau de centres de compétence AERODISK, dans lesquels tout spécialiste technique intéressé peut suivre un cours tout à fait gratuitement et recevoir un certificat dans l'administration des systèmes de stockage AERODISK ENGINE.
Dans chaque centre de compétences, nous installerons un stand de démonstration à part entière du système de stockage AERODISK et un serveur physique, sur lequel notre professeur dispensera une formation en face-à-face. Nous publierons le calendrier de travail des Centres de compétences dès leur apparition, mais nous avons déjà ouvert un centre à Nijni Novgorod et la ville de Krasnodar suivra. Vous pouvez vous inscrire à la formation en utilisant les liens ci-dessous. Voici les informations actuellement connues sur les villes et les dates :
- Nizhny Novgorod (DÉJÀ OUVERT – vous pouvez vous inscrire ici );
Jusqu'au 16 avril 2019, vous pourrez visiter le centre à tout moment de travail, et le 16 avril 2019, une grande formation sera organisée. - Krasnodar (BIENTÔT OUVERTURE - vous pouvez vous inscrire ici );
Du 9 avril au 25 avril 2019, vous pourrez visiter le centre à toute heure de travail, et le 25 avril 2019, une grande formation sera organisée. - Yekaterinburg (BIENTÔT OUVERTURE, suivez les informations sur notre site internet ou sur Habré) ;
Mai-juin 2019. - Novosibirsk (suivre les informations sur notre site internet ou sur Habré) ;
Octobre 2019 - Krasnoyarsk (suivre les informations sur notre site internet ou sur Habré) ;
Novembre 2019.
Et bien sûr, si Moscou n'est pas loin de vous, vous pouvez à tout moment visiter notre bureau à Moscou et suivre une formation similaire.
Tous. Fini le marketing, passons à la technologie !
Sur Habré, nous publierons régulièrement des articles techniques sur nos produits, des tests de charge, des comparaisons, des fonctionnalités d'utilisation et des implémentations intéressantes.
Crash tests du système de stockage AERODISK ENGINE N2, test de résistance
ATTENTION! Après avoir lu l'article, vous pouvez dire : eh bien, bien sûr, le vendeur vérifiera lui-même pour que tout fonctionne « en trombe », les conditions de serre, etc. Je répondrai : rien de tel ! Contrairement à nos concurrents étrangers, nous sommes situés ici, près de chez vous, et vous pouvez toujours venir chez nous (à Moscou ou dans n'importe quel Comité central) et tester notre système de stockage de quelque manière que ce soit. Cela n’a donc pas beaucoup de sens d’ajuster les résultats à une image idéale du monde, car Nous sommes très faciles à vérifier. Pour ceux qui ont la flemme d’y aller et qui n’ont pas le temps, nous pouvons organiser des tests à distance. Nous avons un laboratoire spécial pour cela. Contactez-nous.
ACHTUNG-2! Ce test n'est pas un test de charge, car ici, nous ne nous soucions que de la tolérance aux pannes. Dans quelques semaines, nous préparerons un support plus puissant et effectuerons des tests de charge du système de stockage, en publiant les résultats ici (d'ailleurs, les demandes de tests sont acceptées).
Alors, allons le casser.
banc d'essai
Notre stand est composé du matériel suivant :
- 1 x système de stockage Aerodisk Engine N2 (2 contrôleurs, 64 Go de cache, 8 ports FC 8 Gb/s, 4 ports Ethernet 10 Gb/s SFP+, 4 ports Ethernet 1 Gb/s) ; Les disques suivants sont installés dans le système de stockage :
- 4 x disques SAS SSD 900 Go ;
- 12 disques SAS 10k 1,2 To ;
- 1 x serveur physique avec Windows Server 2016 (2xXeon E5 2667 v3, 96 Go de RAM, 2x ports FC 8 Gb/s, 2x ports Ethernet 10 Gb/s SFP+) ;
- 2 commutateurs SAN 8G ;
- 2 commutateurs LAN 10G ;
Nous avons connecté le serveur au système de stockage via des commutateurs via FC et Ethernet 10G. Le schéma du stand est ci-dessous.
Les composants dont nous avons besoin, tels que MPIO et l'initiateur iSCSI, sont installés sur Windows Server.
Les zones sont configurées sur les commutateurs FC, les VLAN correspondants sont configurés sur les commutateurs LAN et MTU 9000 est installé sur les ports de stockage, les commutateurs et l'hôte (comment faire tout cela est décrit dans notre documentation, nous ne décrirons donc pas ce processus ici).
Méthodologie des tests
Le plan des crash tests est le suivant :
- Vérification de la panne des ports FC et Ethernet.
- Vérification de panne de courant.
- Vérification des pannes du contrôleur.
- Vérification des pannes de disque dans un groupe/pool.
Tous les tests seront effectués dans des conditions de charge synthétique, que nous générerons par le programme IOMETER. En parallèle, nous réaliserons les mêmes tests, mais dans des conditions de copie de fichiers volumineux sur le système de stockage.
La configuration d'IOmeter est la suivante :
- Lecture/écriture – 70/30
- Bloc – 128k (nous avons décidé de laver les systèmes de stockage en gros blocs)
- Nombre de threads – 128 (ce qui est très similaire à la charge productive)
- Aléatoire complet
- Nombre de travailleurs – 4 (2 pour FC, 2 pour iSCSI)
Le test a les objectifs suivants :
- Assurez-vous que le processus de chargement et de copie synthétique n'interrompra pas ou ne provoquera pas d'erreurs dans divers scénarios d'échec.
- Assurez-vous que le processus de changement de port, de contrôleur, etc. est suffisamment automatisé et ne nécessite pas d'actions de l'administrateur en cas de panne (c'est-à-dire que lors des basculements, nous ne parlons pas de restaurations, bien sûr).
- Assurez-vous que les informations contenues dans les journaux s'affichent correctement.
Préparation de l'hôte et du système de stockage
Nous avons configuré l'accès en bloc sur le système de stockage à l'aide des ports FC et Ethernet (FC et iSCSI, respectivement). Les gars de TS Solution ont décrit en détail comment procéder dans un article précédent (). Et bien sûr, personne n’a annulé les manuels et les cours.
Nous avons constitué un groupe hybride en utilisant tous les moyens dont nous disposions. 2 disques SSD ont été ajoutés au cache, 2 disques SSD ont été ajoutés en tant que niveau de stockage supplémentaire (niveau en ligne). Nous avons regroupé 12 disques SAS10k en RAID-60P (triple parité) afin de vérifier la panne de trois disques d'un groupe à la fois. Il restait un disque pour le remplacement automatique.
Nous avons connecté deux LUN (un via FC, un via iSCSI).
Le propriétaire des deux LUN est le contrôleur Engine-0
Commençons le test
Nous activons IOMETER avec la configuration ci-dessus.
Nous enregistrons un débit de 1.8 Go/s et une latence de 3 millisecondes. Il n’y a aucune erreur (nombre total d’erreurs).
Dans le même temps, à partir du disque local « C » de notre hôte, nous commençons en parallèle à copier deux gros fichiers de 100 Go vers des LUN de stockage FC et iSCSI (lecteurs E et G sous Windows), en utilisant d'autres interfaces.
Ci-dessus se trouve le processus de copie vers LUN FC, ci-dessous vers iSCSI.
Test n°1 : Désactivation des ports d'E/S
Nous nous approchons du système de stockage par derrière))) et d'un léger mouvement de la main nous retirons tous les câbles FC et Ethernet 10G du contrôleur Engine-0. C'est comme si une femme de ménage avec une vadrouille passait par là et décidait de laver le sol là où se trouvaient la morve et les câbles (c'est-à-dire que le contrôleur fonctionne toujours, mais les ports d'E/S sont morts).
Regardons IOMETER et la copie de fichiers. Le débit est tombé à 0,5 Go/s, mais est rapidement revenu à son niveau précédent (en 4 à 5 secondes environ). Il n'y a aucune erreur.
La copie des fichiers ne s'est pas arrêtée, il y a une baisse de vitesse, mais ce n'est pas du tout critique (de 840 Mo/s elle est tombée à 720 Mo/s). La copie ne s'est pas arrêtée.
Nous examinons les journaux du système de stockage et voyons un message sur l'indisponibilité des ports et la relocalisation automatique du groupe.
Le panneau d'information nous indique également que tout ne va pas très bien avec les ports FC.
Le système de stockage a survécu à une panne des ports d'E/S avec succès.
Test n°2. Désactivation du contrôleur de stockage
Presque immédiatement (après avoir rebranché les câbles dans le système de stockage), nous avons décidé de terminer le système de stockage en retirant le contrôleur du châssis.
Encore une fois, nous approchons du système de stockage par derrière (nous l'avons aimé))) et cette fois nous retirons le contrôleur Engine-1, qui est actuellement le propriétaire du RDG (vers lequel le groupe a déménagé).
La situation dans IOmeter est la suivante. Les E/S se sont arrêtées pendant environ 5 secondes. Les erreurs ne s'accumulent pas.
Après 5 secondes, les E/S ont repris avec à peu près le même débit, mais avec des latences de 35 millisecondes (latences corrigées après environ quelques minutes). Comme le montrent les captures d'écran, la valeur du nombre total d'erreurs est de 0, c'est-à-dire qu'il n'y a eu aucune erreur d'écriture ou de lecture.
Voyons comment copier nos fichiers. Comme vous pouvez le voir, cela n'a pas été interrompu, il y a eu une légère baisse des performances, mais dans l'ensemble, tout est revenu au même ~ 800 Mo/s.
Nous allons au système de stockage et voyons une malédiction dans le panneau d'information indiquant que le contrôleur Engine-1 n'est pas disponible (bien sûr, nous l'avons tué).
Nous voyons également une entrée similaire dans les journaux.
Le contrôleur de stockage a également survécu à une panne avec succès.
Test n°3 : Coupure de l’alimentation.
Juste au cas où, nous avons recommencé à copier des fichiers, mais n'avons pas arrêté IOMETER.
Nous retirons le bloc d'alimentation.
Une autre alerte a été ajoutée au système de stockage dans le panneau d'information.
Également dans le menu des capteurs, nous voyons que les capteurs associés à l'alimentation débranchée sont devenus rouges.
Le système de stockage continue de fonctionner. La panne du bloc d'alimentation n'affecte en rien le fonctionnement du système de stockage ; du point de vue de l'hôte, la vitesse de copie et les indicateurs IOMETER sont restés inchangés.
Test de panne de courant réussi avec succès.
Avant le test final, nous avons décidé de redonner vie un peu au système de stockage, de remettre le contrôleur et le bloc d'alimentation, et également de remettre les câbles en ordre, ce dont le système de stockage nous a volontiers informé avec des icônes vertes dans son panneau de santé. .
Test n°4. Panne de trois disques dans un groupe
Avant ce test, nous avons effectué une étape de préparation supplémentaire. Le fait est que le système de stockage ENGINE fournit une chose très utile : différentes politiques de reconstruction. TS Solution a parlé de cette fonctionnalité plus tôt, mais rappelons son essence. L'administrateur de stockage peut spécifier la priorité d'allocation des ressources lors de la reconstruction. Soit dans le sens des performances d’E/S, c’est-à-dire que la reconstruction prend plus de temps, mais il n’y a pas de baisse des performances. Ou dans le sens d'une vitesse de reconstruction, mais la productivité sera réduite. Ou une option équilibrée. Étant donné que les performances de stockage lors de la reconstruction d’un groupe de disques sont toujours un casse-tête pour l’administrateur, nous testerons une politique privilégiant les performances d’E/S et au détriment de la vitesse de reconstruction.
Vérifions maintenant la panne de disque. Nous permettons également l'enregistrement sur les LUN (fichiers et IOMETER). Puisque nous avons un groupe à triple parité (RAID-60P), cela signifie que le système doit résister à la panne de trois disques, et après la panne, le remplacement automatique doit fonctionner, un disque doit remplacer l'un des disques défaillants. dans le RDG, et la reconstruction doit commencer là-dessus.
Commencer. Tout d'abord, via l'interface de stockage, soulignons les disques que nous souhaitons retirer (afin de ne pas manquer et retirer le disque de changement automatique).
Nous vérifions l'indication sur le matériel. Tout va bien, nous voyons trois disques en surbrillance.
Et on sort ces trois disques.
Regardons ce qu'il y a sur l'hôte. Et là… il ne s’est rien passé de spécial.
Les indicateurs de copie (ils sont plus élevés qu'au début, car le cache s'est réchauffé) et IOMETER ne changent pas beaucoup lors du retrait des disques et du démarrage de la reconstruction (dans les 5 à 10 %).
Regardons ce qu'il y a sur le système de stockage.
Dans l'état du groupe, on voit que le processus de restructuration a commencé et qu'il est en voie d'achèvement.
Dans le squelette RDG, vous pouvez voir que 2 disques sont en rouge et qu'un a déjà été remplacé. Le disque de remplacement automatique n'est plus là ; il a remplacé le 3ème disque défaillant. La reconstruction a pris plusieurs minutes, l'écriture des fichiers en cas de panne de 3 disques n'a pas été interrompue et les performances d'E/S n'ont pas beaucoup changé.
Le test de panne de disque a définitivement réussi avec succès.
Conclusion
À ce stade, nous avons décidé de mettre fin à la violence contre les systèmes de stockage. Résumons :
- Vérification d'échec du port FC - réussie
- Vérification de défaillance du port Ethernet - réussie
- Vérification de panne du contrôleur - réussie
- Test de panne de courant - réussi
- Vérification de la panne de disque dans le pool de groupe - réussie
Aucun des échecs n'a arrêté l'enregistrement ou n'a provoqué d'erreurs dans la charge synthétique ; bien sûr, il y a eu une baisse de performances (et nous savons comment la surmonter, ce que nous ferons bientôt), mais étant donné qu'il s'agit de quelques secondes, c'est tout à fait acceptable. Conclusion : la tolérance aux pannes de tous les composants du système de stockage AERODISK a fonctionné au niveau, il n'y a eu aucun point de défaillance.
Évidemment, dans un seul article, nous ne pouvons pas tester tous les scénarios d’échec, mais nous avons essayé de couvrir les plus courants. Par conséquent, n'hésitez pas à envoyer vos commentaires, suggestions pour de futures publications et, bien sûr, des critiques adéquates. Nous serons ravis d'en discuter (ou mieux encore, de venir à la formation, je duplique le planning au cas où) ! En attendant de nouveaux tests !
- Nizhny Novgorod (DÉJÀ OUVERT – vous pouvez vous inscrire ici );
Jusqu'au 16 avril 2019, vous pourrez visiter le centre à tout moment de travail, et le 16 avril 2019, une grande formation sera organisée. - Krasnodar (BIENTÔT OUVERTURE - vous pouvez vous inscrire ici );
Du 9 avril au 25 avril 2019, vous pourrez visiter le centre à toute heure de travail, et le 25 avril 2019, une grande formation sera organisée. - Yekaterinburg (BIENTÔT OUVERTURE, suivez les informations sur notre site internet ou sur Habré) ;
Mai-juin 2019. - Novosibirsk (suivre les informations sur notre site internet ou sur Habré) ;
Octobre 2019 - Krasnoyarsk (suivre les informations sur notre site internet ou sur Habré) ;
Novembre 2019.
Source: habr.com