Quelle version du firmware est la plus « correcte » et la plus « fonctionnelle » ? Si un système de stockage garantit une tolérance aux pannes de 99,9999 %, cela signifie-t-il qu'il fonctionnera sans interruption même sans mise à jour logicielle ? Ou au contraire, pour obtenir une tolérance maximale aux pannes, faut-il toujours installer le dernier firmware ? Nous essaierons de répondre à ces questions en nous basant sur notre expérience.
Une petite introduction
Nous comprenons tous que chaque version d'un logiciel, qu'il s'agisse d'un système d'exploitation ou d'un pilote pour un périphérique, contient souvent des défauts/bugs et autres « fonctionnalités » qui peuvent « n'apparaître » qu'à la fin de la durée de vie de l'équipement, ou « s'ouvrir ». seulement sous 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’usine » (le fameux « ça marche, alors ne plaisante pas avec ça ») ou installent toujours la dernière version (dans leur compréhension, la dernière signifie la plus fonctionnelle). Nous utilisons une approche différente : nous examinons les notes de version pour tout ce qui est utilisé. équipement et sélectionnez soigneusement le micrologiciel approprié pour chaque élément d'équipement.
Nous sommes arrivés à cette conclusion, comme on dit, avec l'expérience. À l'aide de notre exemple de fonctionnement, nous vous expliquerons pourquoi la fiabilité promise à 99,9999 % des systèmes de stockage ne signifie rien si vous ne surveillez pas rapidement les mises à jour et les descriptions des logiciels. Notre cas convient aux utilisateurs de systèmes de stockage de n'importe quel fournisseur, car une situation similaire peut se produire avec du matériel de n'importe quel fabricant.
Choisir un nouveau système de stockage
À la fin de l'année dernière, un système de stockage de données intéressant a été ajouté à notre infrastructure : un modèle junior de la gamme IBM FlashSystem 5000, qui au moment de l'achat s'appelait Storwize V5010e. Maintenant, il est vendu sous le nom de FlashSystem 5010, mais en fait il s'agit de 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 entre IBM FlashSystem. Pour les modèles des séries plus jeunes, ce n'est pratiquement pas différent des modèles plus productifs. Le choix d'un modèle spécifique ne fournit que la base matérielle appropriée, dont les caractéristiques permettent d'utiliser l'une ou l'autre fonctionnalité ou offrent un niveau d'évolutivité plus élevé. Le logiciel identifie le matériel et fournit les fonctionnalités nécessaires et suffisantes pour cette plateforme.
IBM FlashSystem 5010
En bref sur notre modèle 5010. Il s'agit d'un système de stockage par blocs à double contrôleur d'entrée de gamme. Il peut accueillir des disques NLSAS, SAS, SSD. Le placement NVMe n'y est pas disponible, car ce modèle de stockage est positionné pour résoudre des problèmes qui ne nécessitent pas les performances des disques NVMe.
Le système de stockage a été acheté pour accueillir des informations d'archives ou des données qui ne sont pas fréquemment consultées. Par conséquent, l'ensemble standard de ses fonctionnalités nous suffisait : Tiering (Easy Tier), Thin Provision. Les performances sur les disques NLSAS au niveau de 1000 2000 à XNUMX XNUMX IOPS nous ont également été tout à fait satisfaisantes.
Notre expérience - comment nous n'avons pas mis à jour le firmware à temps
Parlons maintenant de la mise à jour du logiciel elle-même. Au moment de l'achat, le système disposait déjà d'une version légèrement obsolète du logiciel Spectrum Virtualize, à savoir : 8.2.1.3.
Nous avons étudié les descriptions du firmware et prévu une mise à jour pour 8.2.1.9. Si nous avions été un peu plus efficaces, cet article n'aurait pas existé – le 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é reportée.
En conséquence, un léger retard de mise à jour a conduit à une image extrêmement désagréable, comme dans la description sur le lien : .
Oui, dans le firmware de cette version, le soi-disant APAR (Authorized Program Analysis Report) HU02104 était pertinent. Il apparaît comme suit. Sous charge, dans certaines circonstances, le cache commence à déborder, puis le système passe en mode de protection, dans lequel il désactive les E/S du pool. Dans notre cas, cela ressemblait à la déconnexion de 3 disques pour un groupe RAID en mode RAID 6. La déconnexion se produit pendant 6 minutes. Ensuite, l'accès aux volumes du pool est restauré.
Si quelqu'un n'est pas familier avec la structure et la dénomination des entités logiques dans le contexte d'IBM Spectrum Virtualize, je vais maintenant l'expliquer brièvement.
Structure des éléments logiques du système de stockage
Les disques sont collectés dans des groupes appelés MDisk (Managed Disk). Le disque géré peut être un RAID classique (0,1,10,5,6) ou un disque virtualisé - DRAID (Distributed RAID). L'utilisation de DRAID vous permet d'augmenter les performances de la baie, car... Tous les disques du groupe seront utilisés et le temps de reconstruction sera réduit, car seuls certains blocs devront être restaurés, et non toutes les données du disque défaillant.
Répartition des blocs de données sur les disques lors de l'utilisation du RAID distribué (DRAID) en mode RAID-5.
Et ce diagramme montre la logique du fonctionnement d'une reconstruction DRAID en cas de panne d'un disque :
Logique de la reconstruction DRAID lorsqu'un disque tombe en panne
Ensuite, un ou plusieurs disques gérés forment ce que l'on appelle un pool. Au sein d'un même pool, il n'est pas recommandé d'utiliser un disque géré avec différents niveaux RAID/DRAID sur des disques du même type. Nous n'entrerons pas dans les détails, car... nous prévoyons d’en parler dans l’un des articles suivants. Eh bien, en fait, le pool est divisé en volumes, qui sont présentés en utilisant l'un ou l'autre protocole d'accès en bloc aux hôtes.
Ainsi, nous, à la suite de la situation décrite dans APAR HU02104, en raison de la défaillance logique de trois disques, MDisk a cessé de fonctionner, ce qui a entraîné la défaillance du pool et des volumes correspondants.
Ces systèmes étant assez intelligents, ils peuvent être connectés au système de surveillance basé sur le cloud IBM Storage Insights, qui envoie automatiquement une demande de service au support IBM en cas de problème. Une application est créée et les spécialistes IBM effectuent des diagnostics à distance et contactent l'utilisateur du système.
Grâce à cela, le problème a été résolu assez rapidement et une recommandation rapide a été reçue du service d'assistance pour mettre à jour notre système vers le firmware 8.2.1.9 précédemment sélectionné, qui à ce moment-là avait déjà été corrigé. Cela confirme .
Résultats et nos recommandations
Comme le dit le proverbe : « tout est bien qui finit bien ». Le bug du firmware n'a pas causé de problèmes sérieux - les serveurs ont été restaurés dans les plus brefs délais et sans perte de données. Certains clients ont dû redémarrer des machines virtuelles, mais en général, nous étions préparés à des conséquences plus négatives, puisque nous effectuons des sauvegardes quotidiennes de tous les éléments de l'infrastructure et des machines client.
Nous avons reçu la confirmation que même les systèmes fiables avec une disponibilité promise de 99,9999 % nécessitent une attention et une maintenance en temps opportun. Sur la base de la situation, nous avons tiré un certain nombre de conclusions et partageons nos recommandations :
-
Il est impératif de surveiller la publication des mises à jour, d'étudier les notes de version pour corriger les problèmes potentiellement critiques et d'effectuer les mises à jour planifiées en temps opportun.
Il s’agit d’un point organisationnel et même assez évident sur lequel, semble-t-il, il ne vaut pas la peine de s’attarder. Cependant, sur ce « terrain plat », vous pouvez trébucher assez facilement. En fait, c'est ce moment qui a ajouté les problèmes décrits ci-dessus. Soyez très prudent lors de l'élaboration du règlement de mise à jour et veillez tout aussi attentivement à son respect. Ce point relève davantage de la notion de « discipline ».
-
Il est toujours préférable de conserver le système avec la dernière version du logiciel. De plus, l’actuel n’est pas celui qui a une désignation numérique plus grande, mais plutôt celui avec une date de sortie ultérieure.
Par exemple, IBM maintient à jour au moins deux versions logicielles pour ses systèmes de stockage. Au moment d’écrire ces lignes, il s’agit de 8.2 et 8.3. Les mises à jour pour la version 8.2 sont publiées plus tôt. Une mise à jour similaire pour la version 8.3 est généralement publiée avec un léger retard.
La version 8.3 présente un certain nombre d'avantages fonctionnels, par exemple la possibilité d'étendre le disque géré (en mode DRAID) en ajoutant un ou plusieurs nouveaux disques (cette fonctionnalité est apparue depuis la version 8.3.1). Il s'agit d'une fonctionnalité assez basique, mais dans la version 8.2, malheureusement, une telle fonctionnalité n'existe pas.
-
S'il n'est pas possible de mettre à jour pour une raison quelconque, alors pour les versions du logiciel Spectrum Virtualize antérieures aux versions 8.2.1.9 et 8.3.1.0 (pour lesquelles le bogue décrit ci-dessus est pertinent), afin de réduire le risque de son apparition, le support technique IBM recommande limiter les performances du système au niveau du pool, comme le montre la figure ci-dessous (la photo a été prise dans la version russifiée de l'interface graphique). La valeur de 10000 XNUMX IOPS est présentée à titre d'exemple et est sélectionnée en fonction des caractéristiques de votre système.
Limiter les performances de stockage IBM
-
Il est nécessaire de calculer correctement la charge sur les systèmes de stockage et d'éviter les surcharges. Pour ce faire, vous pouvez utiliser soit le sizer IBM (si vous y avez accès), soit l'aide de partenaires, soit de ressources tierces. Il est impératif de comprendre le profil de charge sur le système de stockage, car Les performances en Mo/s et IOPS varient considérablement en fonction au moins des paramètres suivants :
-
type d'opération : lecture ou écriture,
-
taille du bloc d'opération,
-
pourcentage d’opérations de lecture et d’écriture dans le flux total d’E/S.
De plus, la vitesse des opérations est affectée par la façon dont les blocs de données sont lus : séquentiellement ou dans un ordre aléatoire. Lors de l'exécution de plusieurs opérations d'accès aux données côté application, il existe le concept d'opérations dépendantes. Il est également conseillé d'en tenir compte. Tout cela peut aider à voir la totalité des données des compteurs de performances du système d'exploitation, du système de stockage, des serveurs/hyperviseurs, ainsi qu'à comprendre les fonctionnalités de fonctionnement des applications, des SGBD et autres « consommateurs » de ressources disque.
-
-
Et enfin, assurez-vous d'avoir des sauvegardes à jour et fonctionnelles. Le calendrier de sauvegarde doit être configuré en fonction de valeurs RPO acceptables pour l'entreprise, et des contrôles périodiques d'intégrité des sauvegardes doivent être vérifiés (de nombreux fournisseurs de logiciels de sauvegarde ont mis en œuvre une vérification automatisée dans leurs produits) pour garantir une valeur RTO acceptable.
Merci d'avoir lu jusqu'au bout.
Nous sommes prêts à répondre à vos questions et commentaires dans les commentaires. Aussi, dans lequel nous organisons des promotions régulières (réductions sur IaaS et cadeaux pour des codes promotionnels jusqu'à 100 % sur VPS), écrivons des nouvelles intéressantes et annonçons de nouveaux articles sur le blog Habr.
Source: habr.com