Quelle est la version du firmware la plus "correcte" et "fonctionnelle" ? Si le système de stockage garantit une disponibilité de 99,9999 %, cela signifie-t-il qu'il fonctionnera sans interruption même sans mise à jour logicielle ? Ou faut-il au contraire installer la toute dernière version pour obtenir une disponibilité maximale ? Essayons de répondre à ces questions en nous basant sur notre expérience.
Introduction rapide
Nous comprenons tous que chaque version de logiciel, qu'il s'agisse d'un système d'exploitation ou d'un pilote pour un appareil, contient souvent des défauts et d'autres "particularités" qui peuvent soit ne pas se "manifester" jusqu'à la fin de la durée de vie de l'équipement, soit "apparaître" uniquement dans certaines conditions. Le nombre et l'importance de ces nuances dépendent de la complexité (fonctionnalité) du logiciel et de la qualité des tests effectués lors de son développement.
Souvent, les utilisateurs restent sur le "firmware d'origine" (la célèbre phrase — "ça fonctionne, alors ne touche pas") ou installent toujours la dernière version (dans leur esprit, la dernière version est la plus fonctionnelle). Nous adoptons une autre approche — nous consultons les notes de version pour tout ce que nous utilisons et choisissons soigneusement le firmware approprié pour chaque équipement.
Nous en sommes arrivés à cette conclusion, disons, par l'expérience. En nous basant sur notre propre utilisation, nous allons expliquer pourquoi les 99,9999 % de fiabilité promis par le système de stockage ne signifient rien si vous ne veillez pas à mettre à jour et à consulter la description du logiciel en temps opportun. Notre cas s'applique aux utilisateurs de systèmes de stockage de tout fournisseur, car une telle situation peut survenir avec le matériel de n'importe quel fabricant.
Choix d'un nouveau système de stockage de données
À la fin de l'année dernière, notre infrastructure a été complétée par un système de stockage de données intéressant : le modèle d'entrée de gamme de la série IBM FlashSystem 5000, qui, au moment de l'acquisition, était appelé Storwize V5010e. Il est maintenant vendu sous le nom de FlashSystem 5010, mais en fait, c'est la même base matérielle avec le même Spectrum Virtualize à l'intérieur.
La présence d'un système de gestion unifié est d'ailleurs la principale différence de l'IBM FlashSystem. Pour les modèles de la série inférieure, il ne diffère pratiquement pas des modèles plus performants. Le choix d'un modèle spécifique ne fait qu'offrir une base matérielle correspondante, dont les caractéristiques permettent d'utiliser certaines fonctionnalités ou d'assurer un niveau de scalabilité plus élevé. Le logiciel identifie par ailleurs le matériel et fournit les fonctionnalités nécessaires et suffisantes pour cette plateforme.
IBM FlashSystem 5010
Un aperçu de notre modèle 5010. Il s'agit d'un système de stockage de données de niveau d'entrée avec deux contrôleurs. Il peut accueillir des disques NLSAS, SAS, SSD. L'hébergement de NVMe n'est pas disponible car ce modèle de système de stockage est positionné pour des tâches qui ne nécessitent pas la performance des disques NVMe.
Le système de stockage a été acquis pour le stockage d'informations archivée ou de données qui ne sont pas souvent consultées. Par conséquent, il nous suffisait de l'ensemble standard de ses fonctionnalités : tiering (Easy Tier), Thin Provision. La performance sur les disques NLSAS, au niveau de 1000-2000 IOPS, nous convenait également parfaitement.
Notre expérience - comment nous n'avons pas mis à jour le firmware à temps
Passons maintenant à la mise à jour du logiciel. Au moment de l'acquisition, le système avait déjà une version un peu obsolète du logiciel Spectrum Virtualize, à savoir 8.2.1.3.
Nous avons étudié la description des firmwares et planifié la mise à jour vers 8.2.1.9. Si nous avions été un peu plus réactifs, cet article n'existerait pas - un bug ne se serait pas produit sur un firmware plus récent. Cependant, pour certaines raisons, la mise à jour de ce système a été retardée.
En conséquence, un léger retard dans la mise à jour a conduit à une situation très désagréable, comme le décrit le lien : .
Oui, dans le firmware de cette version, un APAR (Authorized Program Analysis Report) HU02104 était en effet pertinent. Il se manifeste de la manière suivante. Sous charge, dans certaines circonstances, le cache commence à déborder, ensuite le système entre en mode de protection, où il désactive les entrées-sorties pour le pool. Dans notre cas, ça s'est traduit par la désactivation de 3 disques pour le groupe RAID en mode RAID 6. La désactivation dure 6 minutes. Par la suite, l'accès aux volumes du pool est rétabli.
Pour ceux qui ne sont pas familiers avec la structure et la nomenclature des entités logiques dans le contexte d'IBM Spectrum Virtualize, je vais maintenant expliquer brièvement.
Structure des éléments logiques de stockage
Les disques sont regroupés en ensembles appelés MDisk (Managed Disk). Un MDisk peut représenter un RAID classique (0,1,10,5,6) ou un RAID virtualisé – DRAID (Distributed RAID). L'utilisation de DRAID permet d'augmenter la performance du tableau car tous les disques de l'ensemble seront utilisés, et de réduire le temps de reconstruction en ne devant restaurer que certains blocs plutôt que toutes les données du disque défaillant.
Répartition des blocs de données sur les disques lors de l'utilisation de Distributed RAID (DRAID) en mode RAID-5.
Cette schématique montre la logique de reconstruction de DRAID en cas de défaillance d'un disque :
Logique de reconstruction de DRAID lors de la défaillance d'un disque
Ensuite, un ou plusieurs MDisk forment ce qu'on appelle un Pool. Il n'est pas recommandé d'utiliser des MDisk avec différents niveaux de RAID/DRAID au sein d'un même type de disque dans un même pool. Nous ne nous attarderons pas trop sur ce point, car nous prévoyons d'en faire le sujet d'un des prochains articles. De plus, le Pool est divisé en Volumes, qui sont présentés selon un protocole d'accès bloc aux hôtes.
Ainsi, dans le résultat décrit dans APAR HU02104, à cause de la défaillance logique de trois disques, un MDisk a cessé de fonctionner, entraînant l'inaccessibilité du Pool et des Volumes associés.
Comme ces systèmes sont assez « intelligents », ils peuvent être connectés au système de surveillance cloud IBM Storage Insights, qui envoie automatiquement une demande de service au support IBM en cas de défaillance. Une demande est créée et les spécialistes d'IBM effectuent un diagnostic à distance et contactent l'utilisateur du système.
Grâce à cela, la question a été résolue rapidement et le support a fourni une recommandation immédiate pour mettre à jour notre système vers le firmware 8.2.1.9 que nous avions précédemment choisi, où ce problème avait déjà été corrigé. Cela confirme .
Conclusions et nos recommandations
Comme on dit : « tout est bien qui finit bien ». Le bogue dans le firmware ne s'est pas traduit par de graves problèmes — le fonctionnement des serveurs a été rétabli en un rien de temps et sans perte de données. Certains clients ont dû redémarrer leurs machines virtuelles, mais dans l'ensemble, nous étions prêts à des conséquences plus négatives, car nous faisons quotidiennement des sauvegardes de tous les éléments de l'infrastructure et des machines des clients.
Nous avons reçu la confirmation que même des systèmes fiables avec 99,9999 % de disponibilité garantie nécessitent une attention et un entretien réguliers. En fonction de la situation, nous avons tiré quelques conclusions et partageons nos recommandations :
Il est impératif de suivre la parution des mises à jour, d’étudier les notes de version concernant les corrections de problèmes potentiellement critiques et de réaliser les mises à jour programmées en temps utile.
C'est un point organisationnel et même relativement évident, qui, à première vue, ne mérite pas d'être souligné. Cependant, sur ce « terrain plat », il est assez facile de trébucher. En fait, ce point est précisément celui qui a engendré les problèmes mentionnés ci-dessus. Accordez une attention particulière à l'élaboration du règlement sur les mises à jour et suivez-le également avec la même rigueur. Ce point relève davantage du concept de « discipline ».
Il est toujours préférable de maintenir le système avec une version actualisée du logiciel. D'ailleurs, actuelle ne se réfère pas à celle qui a une désignation numérique plus élevée, mais bien à celle qui a une date de sortie plus récente.
Par exemple, IBM maintient au moins deux versions du logiciel à jour pour ses systèmes de stockage de données. Au moment de l'écriture de cet article, il s’agit des versions 8.2 et 8.3. Les mises à jour pour 8.2 sortent plus tôt. Suivi, avec un léger retard, la mise à jour similaire pour 8.3 sort généralement.
La version 8.3 présente plusieurs avantages fonctionnels, tels que la possibilité d'étendre MDisk (en mode DRAID) en ajoutant un ou plusieurs nouveaux disques (cette possibilité est apparue à partir de la version 8.3.1). C'est une fonctionnalité plutôt basique, mais malheureusement, cette option n'est pas disponible dans la version 8.2.
Si une mise à jour n'est pas possible pour une raison quelconque, pour les versions du logiciel Spectrum Virtualize antérieures aux versions 8.2.1.9 et 8.3.1.0 (où le bug mentionné ci-dessus est applicable), pour réduire le risque de son apparition, le support technique d'IBM recommande de limiter les performances du système au niveau du pool, comme indiqué sur l'image ci-dessous (capture d'écran prise dans la version francisée de l'interface utilisateur). La valeur de 10000 IOPS est indiquée à titre d'exemple et doit être adaptée en fonction des caractéristiques de votre système.
Limitation des performances du Système de Stockage IBM
Il est nécessaire de calculer correctement la charge sur les systèmes de stockage et d'éviter les surcharges. Pour cela, vous pouvez utiliser soit le calculateurs d'IBM (si vous y avez accès), soit l'aide de partenaires, soit des ressources tierces. Il est impératif de comprendre le profil de charge du système de stockage, car la performance en Mo/s et en IOPS varie considérablement en fonction au moins des paramètres suivants :
type d'opération : lecture ou écriture,
taille de bloc d'opération,
pourcentage des opérations de lecture et d'écriture dans le flux global d'E/S.
De plus, la vitesse d'exécution des opérations dépend de la manière dont les blocs de données sont lus : de manière séquentielle ou aléatoire. Lors de l'exécution de plusieurs opérations d'accès aux données côté application, il existe des opérations dépendantes. Il est également souhaitable de prendre cela en compte. Tout cela peut aider à voir l'ensemble des données des compteurs de performance du système d'exploitation, du système de stockage, des serveurs/hyperviseurs, ainsi qu'à comprendre les caractéristiques de fonctionnement des applications, des SGBD et d'autres « consommateurs » de ressources disque.
Enfin, il est essentiel d'avoir des sauvegardes à jour et en état de fonctionnement. Le programme de sauvegarde doit être configuré en fonction des valeurs RPO acceptables pour l'entreprise et il est impératif de vérifier périodiquement l'intégrité des sauvegardes (beaucoup de logiciels de sauvegarde ont intégré dans leurs produits un contrôle automatisé) pour garantir une valeur RTO acceptable.
Merci d'avoir lu jusqu'à la fin.
Nous sommes prêts à répondre à vos questions et remarques dans les commentaires. Nous vous invitons également, où nous organisons régulièrement des promotions (remises sur l'IaaS et des tirages au sort de codes promotionnels allant jusqu'à 100% sur VPS), publions des nouvelles intéressantes et annonçons de nouveaux articles sur le blog de Habr.
Source : habr.com
