VNX MCx Multicore Everything - france.emc.com · Livre blanc Résumé Ce livre blanc explique la technologie EMC VNX MCx, ainsi que ses principaux composants : RAID multicœur, cache

Livre blanc

Résumé

Ce livre blanc explique la technologie EMC VNX MCx, ainsi que ses principaux composants : RAID multicœur, cache multicœur et FAST Cache multicœur. Leur association donne naissance aux nouvelles fonctions de la gamme VNX telles que l’évolutivité multicœur, l’accès actif/actif symétrique, le cache évolutif, le remplacement permanent et bien d’autres encore. Juillet 2014

VNX MCx™ Multicore Everything™

2 Livre blanc VNX MCx™

Copyright © 2014 EMC Corporation. Tous droits réservés. EMC estime que les informations figurant dans ce document sont exactes à la date de publication. Ces informations sont modifiables sans préavis. Les informations contenues dans cette publication sont fournies « en l’état ». EMC Corporation ne fournit aucune déclaration ou garantie d’aucune sorte concernant les informations contenues dans cette publication et rejette plus spécialement toute garantie implicite de qualité commerciale ou d’adéquation à une utilisation particulière. L’utilisation, la copie et la diffusion de tout logiciel EMC décrit dans cette publication nécessitent une licence logicielle en cours de validité. Pour obtenir la liste actualisée des noms de produits, consultez la rubrique des marques EMC via le lien Législation, sur france.emc.com. Référence H12090.5


Index

Commandes de CLI .................................................................................................. 5

Figures .................................................................................................................... 5

Introduction ............................................................................................................ 7

Audience ............................................................................................................................ 8

Objectifs de MCx ................................................................................................................ 8

Évolutivité du CPU ................................................................................................... 8

FLARE® .............................................................................................................................. 8

MCx .................................................................................................................................... 9

Affinité de cœur ............................................................................................................ 10

Composants du stack ....................................................................................................... 11

Cache multicœur ................................................................................................... 13

Cache évolutif .................................................................................................................. 13

Vidage .......................................................................................................................... 14

Seuils dynamiques ....................................................................................................... 15

Écriture immédiate ....................................................................................................... 17

Fusion des écritures ..................................................................................................... 17

Taille de page ............................................................................................................... 17

Mécanisme de préchargement ......................................................................................... 18

Lecture page entière ..................................................................................................... 20

Lecture page supplémentaire ....................................................................................... 20

Lecture en amont ......................................................................................................... 21

Stockage en chambre forte du cache multicœur ............................................................... 21

État désactivé ............................................................................................................... 21

Vidage vers la chambre forte ........................................................................................ 22

Alimentation CA sans panne ......................................................................................... 22

Exemple de synthèse du cache multicœur ........................................................................ 22

Pages de cache non synchronisées .............................................................................. 23

Débit de la LUN ............................................................................................................ 24

Actif/actif symétrique ............................................................................................ 25

Actif/actif et logiciel de multipathing ................................................................................ 25

Service de verrouillage ................................................................................................. 27

FAST Cache multicœur ........................................................................................... 29

Conception fonctionnelle ................................................................................................. 29

Préparation initiale de FAST Cache multicœur .............................................................. 29

Gestion des pages ........................................................................................................ 30

Écritures sur FAST Cache .............................................................................................. 33

Lectures FAST Cache ..................................................................................................... 33

Interactions avec le cache multicœur ........................................................................... 34

Options de configuration de FAST Cache multicœur .......................................................... 34


RAID multicœur ..................................................................................................... 37

Remplacement permanent ............................................................................................... 37

Mobilité des disques ........................................................................................................ 38

Recâblage du boîtier DAE ............................................................................................. 39

Disques de secours .......................................................................................................... 40

Reconstruction de disque ............................................................................................. 40

Règles de remplacement .............................................................................................. 43

Matrice de remplacement des disques ......................................................................... 44

Règle relative aux disques de secours .............................................................................. 46

Dimensionnement de disque ............................................................................................ 49

Reconstruction parallèle RAID6 ........................................................................................ 50

Remise à zéro d’un disque ............................................................................................... 50

Remise à zéro de LUN ................................................................................................... 52

Consignation des reconstructions .................................................................................... 52

Consignation des écritures ............................................................................................... 53

Disques système ................................................................................................... 55

Exemples de synthèse de RAID multicœur .............................................................. 56

Scénario A : le disque en panne se reconnecte ................................................................. 57

Scénario B : un autre disque tombe en panne .................................................................. 57

Scénario B1 .................................................................................................................. 58

Scénario B2 .................................................................................................................. 58

Scénario B3 .................................................................................................................. 58

Scénario C : expiration du délai de 5 minutes ................................................................... 59

Résumé ................................................................................................................. 60

Annexe A : Différences majeures entre MCx et FLARE .............................................. 61

Nouveaux disques ............................................................................................................ 61

Espace utile par disque ................................................................................................ 61

Remise à zéro des disques et des LUN .............................................................................. 61

Priorité SCSI ..................................................................................................................... 61

Reprise d’erreur d’E/S ...................................................................................................... 61

Vérification en arrière-plan ............................................................................................... 62

Remarques Getsniffer/Setsniffer .................................................................................. 62

Sniffer .............................................................................................................................. 62

Remplacement proactif .................................................................................................... 63

Fonctionnalités non disponibles dans la gamme VNX nouvelle génération ....................... 63

Annexe B : Unisphere Analyzer .............................................................................. 64

Notes de configuration du test ......................................................................................... 65

Annexe C : Gestion du cache multicœur ................................................................. 66

Gestion ............................................................................................................................ 66

Destruction de FAST Cache ........................................................................................... 66

Code d’activation FAST Cache ...................................................................................... 67

Traitement des pannes ..................................................................................................... 68


Panne d’un disque ....................................................................................................... 68

Tableau des pannes d’alimentation.............................................................................. 68

Références ............................................................................................................ 71

Commandes de CLI CLI 1. Show SP cache information ..................................................................................... 18 CLI 2. Power Path display ALUA state ................................................................................ 26 CLI 3. Copy back to a specific disk .................................................................................... 38 CLI 4. Drive percent rebuilt ............................................................................................... 41 CLI 5. Drive percent copied ............................................................................................... 42 CLI 6. Display disk zeroing log entries ............................................................................... 51 CLI 7. Enable sniffer on the array ...................................................................................... 63 CLI 8. Create FAST Cache .................................................................................................. 66 CLI 9. Destroy FAST Cache................................................................................................. 67 CLI 10. Show FAST Cache information ............................................................................... 67

Figures Figure 1. FLARE CPU with four cores .................................................................................... 9 Figure 2. FLARE on a 16-core CPU ........................................................................................ 9 Figure 3. MCx CPU utilization ............................................................................................ 10 Figure 4. Scaling power of MCx ......................................................................................... 11 Figure 5. VNX stack components ....................................................................................... 11 Figure 6. FLARE cache ....................................................................................................... 13 Figure 7. Adaptive cache .................................................................................................. 14 Figure 8. Multicore Cache write throttling .......................................................................... 16 Figure 9. Multicore Cache logical vs. physical page size ................................................... 18 Figure 10. Read miss ........................................................................................................ 19 Figure 11. Full page prefetch ............................................................................................ 20 Figure 12. Read more prefetch .......................................................................................... 20 Figure 13. Read ahead prefetch ........................................................................................ 21 Figure 14. Cache dirty pages ............................................................................................. 23 Figure 15. Throughput comparison ................................................................................... 24 Figure 16. Active/Active failover mode .............................................................................. 25 Figure 17. EMC Power Path and Asymmetric Active/Active ................................................ 26 Figure 18. EMC Power Path and Symmetric Active/Active .................................................. 26 Figure 19. Active/Active switches to Asymmetric Active/Active ......................................... 27 Figure 20. Stripe locking service ....................................................................................... 27 Figure 21. FLARE FAST Cache promotion ........................................................................... 29 Figure 22. Multicore FAST Cache initial warm up ............................................................... 30 Figure 23. FAST Cache proactive cleaner ........................................................................... 31 Figure 24. Clean before copy ............................................................................................ 31


Figure 25. Multicore FAST Cache minimal page count ....................................................... 32 Figure 26. FLARE vs. MCx FAST Cache write ....................................................................... 33 Figure 27. FLARE vs. MCx FAST Cache read ........................................................................ 34 Figure 28. Permanent sparing ........................................................................................... 37 Figure 29. Drive mobility ................................................................................................... 39 Figure 30. Drive rebuild .................................................................................................... 40 Figure 31. LUN percent rebuilt .......................................................................................... 41 Figure 32. Rebuilding disk ................................................................................................ 42 Figure 33. Disk properties ................................................................................................. 42 Figure 34. Sparing rules .................................................................................................... 44 Figure 35. Drive sparing matrix ......................................................................................... 45 Figure 36. Extreme Performance tier ................................................................................. 46 Figure 37. Hot spare policy ............................................................................................... 47 Figure 38. Create storage pool .......................................................................................... 48 Figure 39. Hot spare policy violation ................................................................................. 48 Figure 40. Multicore RAID drive map ................................................................................. 49 Figure 41. MCx vs. FLARE overhead ................................................................................... 49 Figure 42. RAID6 parallel rebuild ...................................................................................... 50 Figure 43. Drive zeroing .................................................................................................... 51 Figure 44. LUN zeroing ...................................................................................................... 52 Figure 45. Rebuild logging ................................................................................................ 53 Figure 46. Write journaling ................................................................................................ 54 Figure 47. The system drives ............................................................................................ 55 Figure 48. Rebuild logging and write journaling ................................................................ 57 Figure 49. Another drive fails ............................................................................................ 57 Figure 50. The new VNX actual NAR data ........................................................................... 64 Figure 51. VNX OE 32 actual NAR data .............................................................................. 64 Figure 52. Create MCx FAST Cache .................................................................................... 66 Figure 53. An installed FAST Cache enabler ...................................................................... 68


Introduction Les systèmes VNX milieu de gamme d’EMC s’imposent comme la norme de facto pour les déploiements de serveur virtuel. Un déploiement classique varie de quelques dizaines à plusieurs milliers de machines virtuelles. Dans tous les cas, le but est de limiter autant que possible le coût par machine virtuelle.

Un système de stockage moderne doit atteindre un nombre d’E/S par seconde plus élevé que jamais. Il s’agit là d’un besoin motivé par les architectures serveur multicœur/multisocket actuelles. Encore récemment, les baies de stockage milieu de gamme prenaient en charge entre 20 et 40 cœurs de CPU. Aujourd’hui, elles doivent en prendre en charge entre 200 et 400, si ce n’est plus. La loi de Moore, qui stipule que les futurs serveurs posséderont des puces 3D en silicium de plus forte granularité, confirme cette tendance. Une baie déployée de nos jours et conservée dans le datacenter pendant 5 ans doit pouvoir multiplier par 10 les transactions traitées durant sa durée de vie utile. Pour éviter les goulots d’étranglement au niveau du stockage, le nombre de cœurs côté stockage doit s’adapter au nombre de cœurs de CPU en constante augmentation côté hôte.

La capacité elle aussi ne cesse de croître. Il y a quelques années, une baie milieu de gamme standard devait stocker de 10 à 20 To de données seulement. Aujourd’hui, cette capacité atteint entre 100 et 200 To. C’est en augmentant la capacité par slot de disque que nous sommes parvenus à stocker un volume plus important de données. La volumétrie se développe en même temps que la densité surfacique des plateaux magnétiques utilisés dans les disques durs mécaniques. En réalité, la densité surfacique des disques durs ne cesse d’augmenter au fil des ans. Toutefois, la vitesse d’accès n’a pas connu la même progression, ce qui a généré une perte au niveau de la densité d’accès. En conséquence, les temps de reconstruction des disques sont désormais excessivement longs.

L’augmentation de la capacité impose de nouvelles exigences au cache de la baie. La mémoire cache du système doit suivre l’évolution des capacités de ce dernier. De manière générale, l’objectif en matière de cache est de 0,1 % de la capacité totale de stockage. Par exemple, pour une capacité de 20 To, le cache doit être de 0,1 %, soit 20 Go de DRAM. Les systèmes VNX de plus grande taille posent un problème : un système à 1 500 slots de disque peut héberger une capacité totale de 6 Po, ce qui correspond à un cache de 6 To. Actuellement, il n’existe aucune conception à double contrôleur capable de fournir une telle quantité de DRAM, laquelle représente en outre un lourd investissement, tant à l’achat qu’en matière de refroidissement. Heureusement, le cache utilisant la technologie Flash apparaît comme une excellente solution alternative à la DRAM et s’impose à la fois comme une option économique et rapide.

Pour tirer pleinement avantage des conceptions de CPU modernes et des développements en matière de stockage Flash NAND tout en renforçant les atouts offerts aux clients de sa gamme de stockage milieu de gamme, EMC a développé la plate-forme MCx™, sa toute dernière technologie de stockage moderne multicœur/multisocket. Après plusieurs années de développement, MCx s’impose dans le domaine de l’évolution horizontale du nombre de cœurs, ciblant ainsi les applications de gestion et de stockage des données. La nouvelle génération de systèmes EMC VNX équipés de MCx offre des performances et une efficacité de la


plate-forme sans précédent. Ce livre blanc traite de quelques-unes des innovations clés de MCx.

Audience

Ce livre blanc s’adresse à toutes les personnes souhaitant en savoir plus sur MCx et sur la façon dont ce noyau avancé de gestion des E/S fait évoluer les systèmes de stockage milieu de gamme de type VNX.

Des connaissances de base sur le stockage et les principes SAN sont requises.

Objectifs de MCx

De par sa conception, MCx vise un certain nombre d’objectifs, que nous abordons dans ce livre blanc :

s’adapter à des architectures multi-processeurs, fournir une fonctionnalité active/active, améliorer les performances et l’évolutivité, optimiser l’efficacité de la mémoire.

Évolutivité du CPU Le développement de MCx poursuit de nombreux objectifs, le plus important étant l’évolution des cœurs de CPU. MCx tire pleinement parti des multiples cœurs de CPU qu’offre la microarchitecture Intel (Sandy Bridge 8 cœurs et Ivy Bridge 10 cœurs en l’état actuel, et davantage de cœurs encore à l’avenir). L’évolution du CPU est devenue une exigence fondamentale pour assurer une croissance technologique soutenue. À mesure que le nombre de cœurs de CPU et la vitesse des processeurs augmenteront à l’avenir, la pile logicielle du système de stockage devra évoluer et proposer une puissance de traitement supplémentaire. La microarchitecture Haswell d’Intel illustre entièrement cette tendance [5].

FLARE®

Pour expliquer en quoi MCx est source d’innovation, il nous faut tout d’abord comprendre l’architecture de FLARE Operating Environment. FLARE, qui fonctionne sur le CLARiiON CX et la gamme originale de baies EMC VNX (VNX1), est conçu selon une approche monothread. Chaque thread s’exécute sur un cœur de CPU dédié. Certaines fonctions FLARE sont liées au premier cœur, également appelé cœur 0. Les E/S entrantes sont traitées sur le cœur 0, puis réparties sur les autres cœurs. Ce cœur exécutant les fonctions qui sollicitent le plus le CPU, il fait souvent office de volume système pour les autres processeurs.

Lorsque FLARE s’exécute sur un nombre de cœurs relativement modeste (deux, quatre ou même six), l’approche monothread est raisonnablement adaptée. Figure 1. CPU FLARE avec quatre cœurs illustre l’utilisation des cœurs dans FLARE :


Figure 1. CPU FLARE avec quatre cœurs

Le nombre de threads étant supérieur au nombre de cœurs de CPU disponibles, aucun cœur n’est gaspillé. Toutefois, si le nombre de cœurs de CPU augmente, le goulot d’étranglement susceptible d’apparaître au niveau du cœur 0 affecte le budget de l’ensemble des cœurs. Les ingénieurs VNX ont testé FLARE avec un nombre plus important de cœurs de CPU. Comme prévu, le cœur 0 reste occupé à 100 %, le cœur 1 à 90 %, le cœur 2 à 65 % et ainsi de suite. L’ajout d’autres cœurs de CPU n’a apporté aucune amélioration, les cœurs 6 à 15 restant inoccupés, comme illustré sur la Figure 2. FLARE sur CPU à 16 cœurs. Une nouvelle approche d’optimisation multicœur s’est donc révélée nécessaire.

Figure 2. FLARE sur CPU à 16 cœurs

MCx

MCx transforme la façon dont le VNX gère les threads, ainsi que leur distribution. La planification de cœurs de CPU en parallèle n’est pas sans générer des frais supplémentaires. La loi d’Amdahl [1] stipule que « l’accélération d’un programme utilisant plusieurs processeurs en traitement parallèle est limitée par le temps nécessaire à la fraction séquentielle du programme. »

Aucun système ne peut utiliser l’ensemble de ses cœurs de CPU de manière linéaire. Quatre cœurs de CPU n’exécutent pas un programme quatre fois plus vite


qu’un seul cœur. En conséquence, la répartition des threads sur plusieurs autres cœurs de CPU oblige le cœur en charge de la planification à consacrer du temps à la gestion de cette distribution. Cependant, la loi d’Amdahl n’interdit pas le chargement des cœurs selon d’autres critères. Par exemple, il est possible d’aligner les ports Fibre Channel (FC) front-end sur différents cœurs afin de répartir plus efficacement le travail.

Affinité de cœur

MCx utilise un concept de cœur préférentiel. Dans ses attributions, chaque port front-end et back-end a un cœur préférentiel qu’il différencie des autres cœurs. Les demandes de l’hôte front-end sont traitées sur le cœur dont elles sont issues, afin d’éviter tout impact négatif sur les performances qui résulterait d’une permutation du cache et du contexte entre des cœurs de CPU. Au niveau back-end, chaque cœur a accès à tous les disques, si bien que le traitement des demandes reçues par ces derniers ne nécessite aucune permutation avec un autre CPU. Lorsqu’un cœur préférentiel est occupé, un autre cœur prend le relais.

Les cœurs les moins occupés traitent les E/S non liées à l’hôte ou celles générées par la baie elle-même. Les opérations d’E/S back-end, telles que les reconstructions de disques, les copies proactives, la fonction Sniff Verify et la remise à zéro du disque, ne gênent pas les E/S de l’hôte.

MCx valorise les capacités de traitement du CPU plus efficacement que FLARE, en améliorant directement les performances. MCx permet également une évolution des performances bien plus importante qu’avec FLARE.

Figure 3. Taux d’utilisation du CPU MCx montre le résultat d’une nouvelle baie VNX (exécutant MCx) soumise à une charge de travail dans le cadre de l’évaluation des performances VNX standard. Notez que seuls huit ports front-end ont été utilisés pour cette évaluation.

Figure 3. Taux d’utilisation du CPU MCx

Si un grand nombre de cœurs sont moins utilisés que les autres, cela indique que la charge de travail n’est pas également répartie entre tous les ports front-end du système. La loi d’Amdahl stipule qu’il n’est pas toujours rentable d’occuper tous les cœurs au même niveau. Le graphique ci-dessus montre un système fonctionnel. La baie est occupée mais n’atteint pas son plafond de performances.


À mesure que l’utilisation du port et la charge d’E/S augmentent, MCx répartit automatiquement le traitement entre tous les cœurs disponibles. L’apport d’une charge de travail supplémentaire répartie sur tous les ports front-end du même système est une preuve de la puissance d’évolution de MCx, comme illustré dans Figure 4. Puissance d’évolution de MCx.

Figure 4. Puissance d’évolution de MCx

Composants du stack

D’un point de vue chronologique, VNX Block Operating Environment a été conçue avant l’arrivée de la technologie multicœur et n’était donc pas conçu pour valoriser l’évolution dynamique du CPU. FLARE a vu le jour lorsque les définitions RAID ont été développées et sont devenues un moteur de stockage milieu de gamme pour l’accès au disque physique, RAID et la mise en cache.

Au fil du temps, de nouvelles capacités et fonctionnalités sont venues compléter FLARE : les pools, la compression, la hiérarchisation automatique, les snapshots, etc. Dans ce document, l’ensemble des ces fonctionnalités sera appelé Services de données.

Figure 5. Composants du stack VNX

EMC a développé une mentalité « Multicore Everything », qui serait à la base de la conception de MCx. Cette nouvelle façon de penser garantit qu’une révolution technologique nécessite une nouvelle base logicielle. EMC a commencé par réinventer les composants principaux :


RAID multicœur, cache multicœur, FAST Cache multicœur, accès actif/actif symétrique, interface du gestionnaire de la communication multipathing.

L’ordre du stack lui-même constitue un changement architectural considérable. Avec le stack FLARE, toutes les E/S passent par le mappage mémoire de la couche FAST Cache avant d’atteindre la couche FLARE, où se situe le cache DRAM. Ce comportement est généralement dû à l’ajout de FAST Cache à un stack FLARE déjà arrivé à maturité. Par conséquent, le renvoi d’une confirmation d’écriture validée à l’hôte est retardée, ce qui limite les performances d’écriture.

Avec MCx, toutes les écritures vont directement dans le cache DRAM, ce qui réduit la latence des hôtes. En conséquence, les écritures des hôtes sont mises en miroir et protégées directement à partir de la couche de cache DRAM, ce qui améliore les performances. Reportez-vous à la section Actif/actif symétrique pour en savoir plus sur les effets de l’ordre du stack.

MCx introduit une nouvelle technologie d’accès actif/actif symétrique qui permet aux deux processeurs de stockage (SP) d’écrire directement les données sur la LUN, sans avoir à envoyer de mise à jour au SP principal comme cela était le cas avec FLARE.


Cache multicœur Le cache multicœur de la nouvelle baie VNX,aussi appelé cache SP, est un composant logiciel MCx qui optimise la mémoire vive dynamique du processeur de stockage VNX pour augmenter les performances d’écriture et de lecture de l’hôte.

À l’instar de RAID multicœur, le cache multicœur est conçu pour s’adapter à plusieurs cœurs de CPU. Dans le cas de FLARE, le cache fait partie du disque FLARE principal. Pour MCx, le cache multicœur est un composant distinct dans le stack MCx. Le cache relie tous les autres composants ensemble. Le cache multicœur permet la mise en cache des écritures pour toutes les couches logicielles VNX (voir Figure 5. Composants du stack VNX).

Fonctionnalités du cache multicœur :

évolution du CPU multicœur, Actif/actif symétrique pris en charge, réglage des performances automatique et évolutif.

Cache évolutif

Avant d’examiner les améliorations du cache multicœur, revoyons le principe de fonctionnement du cache FLARE. Le cache FLARE se compose de trois zones : cache de lecture, cache d’écriture et cache d’écriture miroir du SP homologue. Cette division n’inclut pas la surcharge du système d’exploitation.

Tel qu’il est illustré dans Figure 6. Cache FLARE, la fonction première du cache de lecture est le préchargement. Suite à un échec de lecture, les données sont chargées dans le cache de lecture (1). Le cache d’écriture ou de lecture peut répondre aux demandes d’écriture de l’hôte si les données nécessaires sont disponibles au moment où la demande est émise. Le cache de lecture (2) peut également y répondre si le chargement des données sur le disque est nécessaire.

Le cache d’écriture est similaire, à la différence que chaque E/S d’écriture entrante (3) est marquée comme « non synchronisée », puis mise en miroir sur le cache SP homologue (4). L’hôte peut remplacer une page non synchronisée quand elle est dans le cache. On appelle cela un Accès en écriture . Le cache d’écriture utilise un algorithme d’ancienneté (LRU) pour reclasser la plus ancienne page non utilisée sur le disque. L’action de reclassement est appelée Vidage. À un moment donné, la LRU entre en jeu : la page de cache est écrite sur le disque (5) et les deux copies sont supprimées de chaque SP (6).

Figure 6. Cache FLARE

Contrairement au cache FLARE, l’espace du cache multicœur n’est pas réparti entre les fonctions de lecture et d’écriture. Le cache est plutôt partagé entre les


écritures (1) et les lectures (2) tel qu’il est illustré dans Figure 7. Cache évolutif. De plus, au lieu d’être vidée sur le disque, les pages non synchronisées sont copiées sur le disque (3). Elles restent donc en mémoire et ne sont pas supprimées. Ainsi, l’hôte peut atteindre les pages (4) et (5), ce qui améliore les performances. Au final, les données sont retirées du cache (7), ce qui libère la page pour d’autres charges de travail.

Figure 7. Cache évolutif

La mise en miroir est importante : le VNX garantit la longévité des données au moment où les E/S d’écriture accèdent au cache. Une page non synchronisée est toujours copiée sur le cache SP homologue. Si un SP tombe en panne, le SP restant a une copie primitive des données. Pour le SP homologue, la page mise en miroir est la même que toute autre page non synchronisée en cache, sauf au niveau de la propriété. Les deux SP gardent une trace des pages dont ils sont propriétaires et de celles détenues par l’homologue. La propriété de la page change si l’un des SP devient indisponible (par exemple, s’il fonctionne de manière inattendue, se bloque, redémarre, etc.). Chaque SP est responsable du vidage de ses propres pages non synchronisées vers le back-end, effaçant la balise « non synchronisée » sur les deux caches.

Remarque : le cache multicœur met toujours en miroir toutes les écritures d’E/S validées sur le cache SP homologue, tant que le SP homologue est opérationnel.

Le cache multicœur garde des statistiques très détaillées sur chaque page de cache. Il utilise le concept de vieillissement (similaire à la température de secteur FAST VP) ou de croissance constante de la page. Chaque accès réussi réduit l’âge de la page et prolonge donc sa vie dans le cache. Ainsi, les événements récents sont considérés comme plus importants. Par exemple, si la baie est installée depuis un an, ce qui est arrivé dans les dernières heures est bien plus important que ce qui est arrivé le mois dernier.

Les pools bénéficient aussi entièrement de toutes les innovations du cache multicœur. Les pools sont développés depuis un ensemble de groupes RAID sous-jacents, appelés groupes RAID privés. Le système, et non l’utilisateur, gère chaque groupe RAID privé. Ce point est essentiel à la conception des pools. Le cache multicœur surveille et gère le trafic vers les groupes RAID sous-jacents dans les pools, exactement comme avec les groupes RAID gérés par l’utilisateur.

Vidage

FLARE possède une condition appelée Vidage forcé. Elle se produit lorsque le pourcentage de pages de cache non synchronisées dépasse le seuil supérieur et atteint 100 %. À ce stade, le cache force le vidage des données non sauvegardées


(non synchronisées) vers le disque et suspend toutes les E/S de l’hôte. Le vidage forcé continue jusqu’à ce que le pourcentage de pages non synchronisées passe en-dessous du seuil inférieur.

Le vidage forcé affecte la baie entière ainsi que toutes les charges de travail traitées par la baie. Il entraîne une augmentation considérable du temps de réponse de l’hôte jusqu’à ce que le nombre de pages non synchronisées passe en-deçà du seuil inférieur. Le processeur de stockage donne priorité à l’écriture de données non synchronisées sur le disque, plutôt qu’à l’allocation de nouvelles pages pour les E/S entrantes de l’hôte. L’idée de la fonctionnalité des seuils inférieur et supérieur est venue du besoin d’un mécanisme qui permettrait d’éviter le vidage forcé. Plus le seuil supérieur est bas, plus le tampon réservé dans le cache est grand et moins il y a de chance qu’un vidage forcé ne se produise.

Seuils dynamiques

Le cache multicœur change le modèle de nettoyage du cache. Aucun seuil de pages de cache non synchronisées n’est prédéfini. Plutôt que de garder uniquement une trace des pages de cache non synchronisées, le cache multicœur surveille également la LBA correspondant à la référence de ces pages, ainsi que la demande des hôtes vis à vis du cache multicœur et des groupes RAID sous-jacents.

Le système évalue constamment l’efficacité du cache pour des charges de travail données. La mise en mémoire tampon des E/S d’écriture dans le cache est efficace pour les brefs pics d’activité, mais s’avère contreproductive pour les charges de travail ayant tendance à occuper la totalité de l’espace du cache. Comme nous l’avons indiqué plus haut, le vidage excessif n’améliore pas les performances ; au contraire, elle affaiblit toutes les charges de travail du système.

Le cache multicœur mesure le taux d’E/S entrantes et surveille les groupes RAID sous-jacents pour prévoir son efficacité pour les charges de travail. Une charge de travail qui envoie des E/S d’écriture à un groupe RAID avec beaucoup de pages non synchronisées qui attendent d’être écrites sur le disque utilisera plus de ressources du cache. Le système évalue la différence entre le taux d’écritures entrantes et le taux de vidages de page de groupe RAID réussis.

L’évaluation permet au cache multicœur de réagir de façon dynamique aux variations de charge de travail : les charges de travail susceptibles de surcharger le cache peuvent être sujettes à la régulation en écriture ; les brefs pics temporaires peuvent être entièrement mis en mémoire tampon par le cache ; les écritures aléatoires de petit bloc peuvent fusionner pour améliorer le reclassement du disque ; etc.

Âge avant nettoyage

L’âge avant nettoyage est le temps maximal pendant lequel une page de cache peut rester non synchronisée. L’âge de la page de cache correspond à la durée pendant laquelle la page est restée non synchronisée. La valeur d’âge avant nettoyage est l’une des statistiques les plus importantes du cache multicœur.

Il s’agit d’une valeur dynamique générée par le cache multicœur à partir du groupe RAID. Il varie en fonction des éléments suivants :


le taux d’E/S entrantes adressées au groupe RAID ;

le taux de vidages de page vers le groupe RAID réussis ;

le nombre de pages de cache disponibles/libres ;

l’efficacité de la fusion des charges de travail.

Pour déterminer le temps adéquat pour vider une page de cache non synchronisée sur un lecteur, le cache multicœur compare l’âge de la page avec la valeur dynamique d’âge avant nettoyage. Si l’âge de la page de cache est inférieur à l’âge avant nettoyage, tout est normal. Si l’âge de la page de cache est égal à l’âge avant nettoyage, il est temps de procéder à un vidage. Si l’âge de la page de cache est supérieur à l’âge avant nettoyage, le cache multicœur peut augmenter les E/S en attente vers les disques ou activer la régulation en écriture.

Pour une gestion efficace du cache et des performances système optimales, il est primordial de bien définir l’âge avant nettoyage. Le cache multicœur évite que les ressources soient surconsommées par une seule charge de travail s’adressant à un groupe RAID surchargé.

Régulation en écriture

La nouvelle fonctionnalité de régulation en écriture du cache multicœur donne la possibilité de régler automatiquement les E/S entrantes et sortantes par groupe RAID. La régulation en écriture donne au cache le temps nécessaire pour régler l’âge avant nettoyage pour un groupe RAID donné. Lorsque l’âge de la page de cache non synchronisée la moins récente est supérieur à l’âge avant nettoyage actuellement défini, la probabilité que le cache soit en surcharge à cause d’une charge de travail à fort taux d’opérations d’écriture augmente.

Le cache multi-cœur donne au groupe RAID de destination le temps nécessaire pour traiter une augmentation de la charge de vidage en retardant les accusés de réception des E/S de l’hôte, permettant de ralentir les E/S d’écriture entrantes. Figure 8. Régulation en écriture du cache multicœur illustre ce processus.

Figure 8. Régulation en écriture du cache multicœur

La régulation est maintenue jusqu’à ce que le taux des données entrantes corresponde aux capacités du groupe RAID sous-jacent et la valeur d’âge avant nettoyage change pour correspondre à la charge de travail.


Les objectifs de la régulation en écriture sont les suivants :

éviter que les ressources du système soient monopolisées par une seule charge de travail ;

faire en sorte que les charges de travail à fort taux d’opérations d’écriture correspondent à la vitesse du lecteur ;

o éviter que les charges de travail à fort taux d’opérations d’écriture consomment les pages de cache nécessaires pour d’autres charges de travail en connaissant la valeur d’âge avant nettoyage adéquate.

La régulation en écriture ne dure pas indéfiniment. La régulation en écriture s’arrête lorsque le taux de vidage de page du groupe RAID est égal au taux d’opérations d’E/S entrantes, et que les pages non synchronisées associées restent dans le cache pour une durée égale ou inférieure au temps de régulation de la valeur d’âge avant nettoyage.

Comme il est indiqué dans la section précédente, la valeur de l’âge avant nettoyage est sans cesse ajustée. L’introduction de petites corrections dans le cache multicœur induit des variations de la charge de travail. Si l’activité d’écriture de la charge de travail diminue, l’âge avant nettoyage peut augmenter. Si l’activité augmente, la régulation en écriture peut être utilisée pour diminuer la valeur.

Écriture immédiate

Le cache de lecture du cache multicœur est toujours activé. Le cache d’écriture du cache multicœur a deux modes de fonctionnement :

cache d’écriture activé, cache d’écriture désactivé.

Lorsque le cache d’écriture est désactivé, il fonctionne en mode d’Écriture immédiate. Les opérations d’E/S d’écriture ne sont pas confirmées avant d’être écrites sur le disque avec succès. Elles ne sont pas non plus mises en miroir sur le SP homologue. L’hôte reçoit la confirmation des opérations d’E/S seulement lorsque le vidage a été effectué avec succès

Fusion des écritures

Pour les disques à rotation, le cache multicœur présente des gains de performances conséquents lors de l’écriture des E/S sur les LBA adjacentes. C’est pourquoi le cache multicœur utilise la fusion des écritures, qui regroupe les pages voisines et contiguës à la LBA. Les pages sont organisées de manière séquentielle afin de faciliter l’écriture rapide du lecteur.

Taille de page

Le cache multicœur a deux tailles de page distinctes. La page physique, ou page de cache,a une taille de 8 Ko. La baie indique la taille de la page physique dans la CLI sous Cache page size :


C:>naviseccli -h VNX-SPA –User user –Password password –Scope 0 cache

–sp -info

SP Read Cache State: Enabled

SP Write Cache State: Enabled

Cache Page size (KB): 8

Read Hit Ratio: 67

Write Hit Ratio: 15

Dirty Cache Pages (MB): 4

SPA Read Cache State: Enabled

SPB Read Cache State: Enabled

SPA Write Cache State: Enabled

SPB Write Cache State: Enabled

SPS Test Day: Samedi

SPS Test Time: 21:00

SPA Physical Memory Size (MB): 65536

SPB Physical Memory Size (MB): 65536

CLI 1. Affichage des informations du cache SP

Le deuxième type de page est la page logique. Sa taille est de 64 Ko. Une page logique contient entre une et huit pages physiques. Le cache multicœur utilise des pages logiques dans ses algorithmes, tel qu’il est illustré dans Figure 9. Différence de taille d’une page logique et d’une page physique d’un cache multicœur.

Figure 9. Différence de taille d’une page logique et d’une page physique d’un

cache multicœur

Lorsque l’on travaille avec Unisphere Analyzer, il est très important de connaître les différents types de page. Le cache multicœur garde une statistique indiquant le nombre de pages logiques allouées et le nombre de pages logiques non synchronisées. Généralement, seules certaines pages physiques restent non synchronisées dans un ensemble de pages logiques. Pour obtenir la statistique de page de cache non synchronisée du SP (affichée par Unisphere Analyzer), le cache multicœur établit une approximation à partir de la moyenne du chargement des E/S d’écriture. Chaque processeur de stockage effectue son propre calcul. C’est pourquoi le graphique affiché dans Analyzer peut afficher des nombres différents pour chaque SP.

Mécanisme de préchargement

Le préchargement est un mécanisme qui charge les données adjacentes dans le cache de manière proactive en fonction des données demandées par l’hôte. Il anticipe les futures demandes de lecture afin de réduire la latence.

Les disques à rotation utilisent le concept de distance de recherche, qui correspond à la distance que la tête de lecture magnétique doit parcourir jusqu’à


la zone de disque dont il a besoin. Il est plus rapide de lire des données contiguës supplémentaires que de repositionner la tête de lecture sur une autre partie du disque. Si le taux de transfert d’un lecteur est de 80 Mo/s et que le temps d’accès moyen pour 8 Ko est de 3 ms, alors il est possible d’accéder à 240 Ko et de les transférer en 6 ms au lieu de 90 ms en 8 000 unités. Si les données préchargées sont utilisées, alors le transfert de données supplémentaires sur le lecteur d’origine est rentable jusqu’à ce que le temps de transfert dépasse le temps d’E/S total.

Pour que le mécanisme de préchargement reste rentable, le cache multicœur prend en compte certains critères relatifs à la lecture :

si un préchargement a été utile, si la page a été chargée suffisamment vite,

o signe d’une attente des E/S du disque non expliquée, nombre moyen actuel d’échecs de lecture et de lectures réussies en déclin.

Le cache multicœur consulte les échecs passés du cache avec la page précédente dans le cache. Cette analyse aide le cache multicœur à déterminer s’il aurait été bénéfique d’exécuter un mécanisme de préchargement pour la page précédente, tel qu’illustré dans Figure 10. Échec de lecture.

Figure 10. Échec de lecture

L’image montre un cas classique d’une situation dans laquelle un préchargement aurait été bénéfique. Même si l’hôte ne demande pas la totalité d’une page logique de données, l’aspect séquentiel de la demande de lecture de l’hôte suggère qu’il demandera le reste de la page plus tard. Les données que l’hôte a lu plus tôt (non illustré dans le graphique) peuvent indiquer si un préchargement plus agressif aurait été préférable. Le cache multicœur recherche une charge de travail séquentielle et essaie de l’identifier plus rapidement.

Après avoir identifié la charge de travail de lecture séquentielle et utilisé les statistiques habituelles (tailles des E/S, longueur de file d’attente, etc.), le cache multicœur déclenche différentes vitesses de préchargement :

lecture page entière, lecture page supplémentaire (E/S plus volumineuses), lecture en amont (chargement avant demande).


Lecture page entière

Avec le mode de préchargement Lecture page entière, la totalité d’une page logique de 64 Ko est lue dans le cache même si seule une portion a été demandée par les E/S de l’hôte, tel qu’illustré dans Figure 11. Préchargement de page entière. Si un hôte demande des zones qui vont au-delà des limites d’une page logique, les deux pages sont chargées (non illustré).

Figure 11. Préchargement de page entière

Le cache multicœur utilise la moyenne des réussites en lecture en déclin pour calculer si le temps de réponse de lecture pourrait être amélioré par la lecture de la page entière. L’objectif est d’éviter les lectures de page entière sur les charges de travail de lecture aléatoire de petite1 taille.

Lecture page supplémentaire

Selon la charge de travail, le cache multicœur peut décider de marquer une page logique avec un déclencheur de préchargement Lecture page supplémentaire. Lorsque l’hôte lit une page avec un déclencheur lecture page supplémentaire, le cache multicœur en lira une autre.

Figure 12. Préchargement Lecture page supplémentaire

Le cache multicœur suit de près les données préchargées avec le déclencheur Lecture page supplémentaire. Au final, ces statistiques répondent aux questions suivantes :

L’hôte a-t-il utilisé la page préchargée ?

Quelle était la taille de la demande de l’hôte ayant déclenché un échec de lecture ?

1 Ici, petit signifie plus petit que la taille d’une page entière, soit 64 Ko.


L’historique des statistiques de la LUN est utilisé pour déterminer l’agressivité de la lecture page supplémentaire lors du prochain échec de lecture.

Lecture en amont

La lecture en amont va plus loin que la lecture page supplémentaire avec un mécanisme de préchargement plus agressif. La lecture en amont est déclenchée lorsque le cache multicœur s’attend, sur des bases raisonnables, à ce que l’hôte demande plus de données situées de la LUN.

Figure 13. Préchargement lecture en amont

Généralement, le mécanisme de préchargement lecture en amont se produit sur des E/S séquentielles plus importantes, celles d’une taille de 256 Ko par exemple. Notez que la taille des E/S de l’hôte ne doit pas nécessairement correspondre aux E/S du disque. Le cache multicœur charge 64 Ko de données mais il peut décider d’utiliser une autre taille d’E/S sur le disque.

Stockage en chambre forte du cache multicœur

Le nouveau VNX protège les pages non synchronisées du cache multicœur avec des batteries de secours. D’autres modèles utilisent d’autres configurations de batterie mais leur fonctionnalité est cohérente sur la ligne de produit VNX. Dans le cas de panne d’alimentation CA2, les batteries garderont les SP et le premier boîtier DAE (emplacement des disques du système) alimentés suffisamment longtemps pour pouvoir reclasser le cache non synchronisé dans la chambre forte.

En cas de défaillance matérielle, le cache multicœur prend un des trois états suivants :

reste Activé :entièrement fonctionnel, passe à Désactivé : toutes les écritures de données sont directement

transférées sur le disque, passe à Vidage en rafale : le système s’arrête, toutes les pages non

synchronisées doivent être reclassées vers la chambre forte.

Reportez-vous à la section Traitement des pannes pour obtenir la liste complète des défaillances matérielles.

État désactivé

Si le cache multicœur détermine qu’il a besoin de passer à l’état Désactivé, il vide toutes les pages non synchronisées sur le disque. Les vidages sont agressifs mais

2 Le CA est utilisé comme un exemple générique. Le scénario sera le même en cas de panne de courant extérieure.


pas au détriment des E/S de l’hôte. Les règles de mise en file d’attente améliorée de priorité SCSI du RAID multicœur s’appliquent toujours (voir la section Priorité SCSI pour plus de détails).

Une fois le vidage terminé, le cache multicœur reste à l’état désactivé jusqu’à correction de la condition de défaillance. En état désactivé, le cache multicœur fonctionne comme un cache de lecture, tandis que les demandes d’écriture sont traitées en mode Écriture immédiate.

Vidage vers la chambre forte

Si le cache multicœur détermine qu’un vidage vers la chambre forte est nécessaire, il entame immédiatement une mise en veille de 5 secondes qui donne aux hôtes le temps de terminer toutes les opérations d’E/S en cours (par exemple, une E/S de 256 Ko est envoyée de manière active). Si possible, cette E/S est mise en miroir sur le SP homologue. Entre temps, aucune nouvelle E/S n’est acceptée par le cache. Le cache multicœur envoie également un message pour arrêter tous les traitements en arrière-plan (comme les reconstructions de disque, remises à zéro de LUN et de disque, vérifications en arrière-plan, fonction Sniff Verify, etc.).

Ensuite, le cache multicœur réalise un vidage de toutes les pages non synchronisées vers la chambre forte. Une fois le vidage terminé, le SP poursuit son arrêt normal. Lorsque le cache multicœur commence son vidage vers la chambre forte, les LED « Ne pas retirer » sur les deux SP s’allument, indiquant visuellement que le SP ne peut pas être retiré. Les LED « Ne pas retirer » s’éteignent lorsque le vidage vers la chambre forte est terminé.

Suite à un vidage vers la chambre forte, un redémarrage complet du système est nécessaire pour restaurer la baie.

Alimentation CA sans panne

La nouvelle plate-forme VNX introduit un délai de récupération de 15 secondes, durant lequel la baie utilise ses batteries intégrées. Aucune coupure d’alimentation n’est signalée et le cache multicœur n’entame pas un vidage vers la chambre forte.

Cette fonctionnalité est particulièrement utile durant la transition d’une alimentation par le réseau électrique vers une alimentation par générateur qui occasionne parfois un tressautement électrique.

Exemple de synthèse du cache multicœur

Pour résumer les fonctionnalités du cache multicœur, une simple expérience a été réalisée avec les deux baies :

baie VNX7600, exécutant VNX OE 33 (version beta 687)

baie VNX5500, exécutant VNX OE 32 (correctif 201)

La même charge de travail a été exécutée sur des disques de même taille. Reportez-vous à la description de la charge de travail et aux notes de configuration dans Annexe B : Unisphere Analyzer.


Pages de cache non synchronisées

Figure 14. Pages de cache non synchronisées compare 3 les statistiques des pages de cache non synchronisées FLARE et MCx.

Les différences suivantes sont à noter :

Le cache FLARE a rapidement atteint son maximum et a entamé un vidage forcé.

Le cache multicœur s’est également rempli très vite mais n’a pas laissé cette charge de travail occuper 100 % du cache.

o Aucun vidage forcé n’a été réalisé.

o La régulation en écriture a contrôlé les pages non synchronisées, jusqu’à ce que la baie connaisse la bonne valeur de l’âge avant nettoyage.

Figure 14. Pages de cache non synchronisées

Avant que les pages non synchronisées n’utilisent la totalité de l’espace, le cache multicœur a commencé à réguler la charge de travail, réduisant le nombre de pages de cache non synchronisées. La nouvelle baie VNX utilisait les deux processeurs de stockage (actif/actif) et pas uniquement un seul SP comme avec le système FLARE (actif/actif asymétrique).

Les processeurs de stockage de la nouvelle baie VNX signalent les pages non synchronisées séparément. De plus, le nombre de pages non synchronisées est une estimation. À tout moment, le nombre de pages non synchronisées doit être le même sur les deux SP. Les éventuelles variations sont dues au fait que les deux calculs sont de simples estimations. Lorsque le cache multicœur en a suffisamment appris sur la charge de travail, la quantité de pages non synchronisées s’est stabilisé à environ 25 %. Au même moment, le cache multicœur a cessé la régulation. D’autres charges de travail, tailles de groupe RAID ou tailles de LUN se seraient stabilisées à un autre niveau, 25 % n’est pas une référence.

3 Le nouveau Unisphere Analyzer VNX n’affiche pas les pages de cache non synchronisées en pourcentage de la totalité du cache. Le cache multicœur affiche le nombre de Mo utilisé, mais dans ce document, les données seront indiquées sous forme de pourcentage. Reportez-vous au vrais graphiques d’Analyser dans Annexe B : Unisphere Analyzer.


Débit de la LUN

Examinons les E/S par seconde. Comme il est illustré dans Figure 15. Comparaison du débit, MCx est plus performant que FLARE. Pour faciliter la comparaison, les deux graphiques ont la même échelle en ordonnées. Toutefois, le débit initial de la LUN MCx était de 27 000 E/S par seconde ; et ce car toutes les écritures entrantes ont accédé au cache de la DRAM.

Figure 15. Comparaison du débit

FLARE a également connu un bref instant où toutes les écritures entrantes ont accédé à la DRAM, mais il existait une différence de taille du cache d’écriture disponible significative entre les deux systèmes. Malheureusement, le débit élevé de FLARE a été trop bref (pour ce test, la période définie était de 60 secondes) et Analyzer ne l’a pas répercuté. Pour pouvoir comparer les deux tests, nous avons choisi la LUN 100 Go pour exclure la différence de taille de DRAM physique entre les deux baies. 4La différence de débit moyen est considérable, même si l’on ignore le pic initial. MCx présente une moyenne d’environ 900 E/S par seconde, tandis que la moyenne de FLARE est d’environ 513 E/S par seconde ; ce qui représente une amélioration de 150 %. Notez que les disques utilisés pour ce test étaient identiques : disques SAS 300 Go 10 000 tr/min.

4 Les disques ont des niveaux de microprogrammes différents. VNX OE version 33 utilise un microprogramme plus récent que les disques pris en charge par VNX OE version 32 et antérieur.


Actif/actif symétrique Un avantage majeur de MCx est la prise en charge de la technologie Actif/actif symétrique, qui permet aux hôtes d’accéder aux LUN en utilisant les deux processeurs de stockage simultanément. Avec l’accès actif/actif symétrique, le VNX délaisse graduellement le modèle de propriété de la LUN et ses performances fondamentalement asymétriques.

Toutes les baies VNX (y compris les baies CLARiiON exécutant FLARE version 26 et ultérieures) prennent en charge l’accès Actif/actif asymétrique, communément appelé à tort « ALUA ».

Asymmetric LUN Access ou ALUA est une interface SCSI [2] qui permet une description des chemins Optimisés et Non optimisés. Le mot « asymétrique » dans le terme ALUA prête à confusion. Le mode ALUA est simplement le mécanisme que le protocole SCSI utilise pour indiquer quels chemins utiliser. L’accès actif/actif symétrique utilise ALUA pour indiquer que tous les chemins sont optimisés. L’accès actif/actif asymétrique utilise ALUA pour indiquer que certains chemins sont optimisés et d’autres non.

MCx prend en charge l’accès actif/actif symétrique ainsi que l’accès actif/actif asymétrique. Le mode actif/actif symétrique est pris en charge pour les LUN classiques. Une LUN classique est une LUN qui n’est pas créée dans un pool.

Remarque : dans ce document, nous utiliserons le terme « Actif/actif » pour faire référence à Actif/actif symétrique et le terme « Actif/actif asymétrique » pour faire référence aux autres accès basés sur ALUA.

Actuellement, le nouveau VNX ne prend pas en charge l’accès actif/actif pour les LUN de pool (thick et thin). Par défaut, ils sont en mode actif/actif asymétrique. MCx prend en charge l’accès actif/actif pour les LUN de pool privées.

Le mode actif/actif étant basé sur ALUA, il utilise le même mode de basculement sur incident 4 qui est défini au niveau de l’initiateur durant l’enregistrement de l’initiateur, tel qu’il est illustré dans Figure 16. Mode de basculement sur incident Actif/actif.

Figure 16. Mode de basculement sur incident Actif/actif

Actif/actif et logiciel de multipathing

L’hôte client et le logiciel de multipathing de son SAN doivent reconnaître si le mode actif/actif symétrique ou actif/actif asymétrique est utilisé. EMC Power


Path 5.7 et versions ultérieures prennent en charge l’accès actif/actif avec VNX. Reportez-vous aux Figure 17. EMC Power Path et Actif/actif asymétrique et Figure 18. EMC Power Path et Actif/actif symétrique pour voir comment Power Path 5.7 présente les deux cas.

Figure 17. EMC Power Path et Actif/actif asymétrique

Figure 18. EMC Power Path et Actif/actif symétrique

Notez que l’ordre des champs dans les figures ci-dessus a été réorganisé par rapport à l’affichage par défaut. Dans l’affichage par défaut, le champ « ALUA state » (état ALUA) est le champ le plus à droite dans la console.

Power Path reconnaît l’accès actif/actif par périphérique. Ainsi, le même hôte peut disposer d’une LUN classique et d’une LUN de pool.

C:\>powermt display alua dev=all

Pseudo name=harddisk??

VNX ID=FNM00123456789 [Win2012]

Logical device ID=60060160098032002A012AC7E0F3E211 []

state=dead; policy=CLAROpt; queued-IOs=0

Owner: default=SP A, current=SP A Array failover mode: 4

======================================================================

- Host -- - Stor - ------------ I/O Path ----------- - Stats

### I/O Paths Interf. ALUA State Mode State Errors

======================================================================

5 c5t5d1 SP A8 Active/optimized active active 0

4 c4t5d1 SP B8 Active/non-optimized active active 0

Pseudo name=harddisk??

VNX ID=FNM00123456789 [Win2012]

Logical device ID=60060160098032002C012AC7E0F3E211 []

state=dead; policy=CLAROpt; queued-IOs=0

Owner: default=SP B, current=SP B Array failover mode: 4

======================================================================

- Host -- - Stor - ------------ I/O Path ----------- - Stats

### I/O Paths Interf. ALUA State Mode State Errors

======================================================================

5 c4t4d0 SP A2 Active/optimized active active 0

4 c4t4d0 SP B2 Active/optimized active active 0

CLI 2. Affichage de l’état ALUA dans Power Path


Les LUN classiques prennent en charge le mode Actif/actif, à moins qu’ils utilisent des services de données.

Remarque : le séparateur RecoverPoint prend en charge le mode Actif/actif.

Lorsqu’un snapshot d’une LUN classique est créé, la baie VNX fait immédiatement passer les groupes du port cible SCSI pour cette LUN au mode Actif/actif asymétrique. D’autres opérations comme le clonage ou l’utilisation de MirrorView auront le même effet. Avec EMC Power Path 5.7 et versions ultérieures, le changement ne nécessite pas de nouvelle analyse du bus SCSI5, comme on peut l’observer dans Figure 19. Passage du mode Actif/actif au mode Actif/actif asymétrique.

Figure 19. Passage du mode Actif/actif au mode Actif/actif asymétrique

En raison de la compatibilité en amont du mode Actif/actif asymétrique, toutes les LUN classiques gardent leur attribut propriétaire du SP par défaut. L’attribut est pertinent uniquement si une LUN classique utilise l’un des services de données avancés (comme SnapView) ; dans quel cas, la baie doit passer au mode Actif/actif asymétrique.

Service de verrouillage

Le mode Actif/actif a été rendu possible grâce à l’introduction d’une technologie de verrouillage pour les accès en lecture et en écriture des LUN. Les SP communiquent entre eux grâce au service de verrouillage des bandes avec l’interface du gestionnaire de la communication(CMI). Le nouveau matériel VNX dispose d’un bus PCI Gen3 qui connecte les SP et sur lequel fonctionne la CMI entre les deux SP.

Figure 20. Service de verrouillage des bandes

Un SP doit demander un verrouillage exclusif pour une plage LBA sur une LUN avant de procéder à l’écriture à partir d’un service de verrouillage. Les SP

5 Veuillez consulter EMC E-LAB Interoperability Navigator [3] pour la compatibilité du mode Actif/actif avec d’autres solutions logicielles de multipathing, telles que Windows MPIO ou Linux MPIO.


établissent donc une communication via le bus de la CMI pour le service de verrouillage. Une fois le verrou obtenu, le SP procède à l’écriture.

De la même manière, un verrou de lecture partagé peut être retirer pour plusieurs lectures. Le SP doit savoir s’il faut lire à partir du disque ou à partir du cache d’un SP homologue. Il se peut que les données présentes sur le SP homologue soient plus récentes que celles du disque si les pages de cache non synchronisées n’ont pas encore été transférées du SP homologue vers le disque.

Une fois les opérations d’E/S terminées, le verrou est retiré.


FAST Cache multicœur FAST Cache multicœur (ou simplement FAST Cache) identifie régulièrement les blocs atteints et les copie à partir des disques à rotation vers les disques Flash. Les données sont copiées dans FAST Cache lorsqu’elles ont été atteintes plusieurs fois. Tout comme avec le cache multicœur, les données sont vidées du cache lorsqu’elles ne sont plus utilisées aussi souvent que les autres données, selon l’algorithme d’ancienneté.

FAST Cache multicœur fait partie de la famille MCx et est conçu pour :

s’adapter au nombre de cœurs de CPU disponibles ; éviter le trafic inter-cœurs ; prendre en charge le modèle d’accès Actif/actif symétrique.

Conception fonctionnelle

FAST Cache multicœur fonctionne avec les LUN classiques et les LUN de pool. Pour plus d’informations à propos de la structures du pool VNX, consultez le livre blanc EMC FAST VP [8].

Le mappage mémoire(un composant de FAST Cache) maintient l’état des pages FAST Cache et leur contenu. Il s’agit d’une carte des bits qui coordonne les adresses physiques pour les disques de données et les fragments FAST Cache correspondants. Le mappage mémoire est présent en deux endroits : le cache multicœur et, à des fins de persistance, sur les disques Flash utilisés avec FAST Cache.

Préparation initiale de FAST Cache multicœur

La première implémentation de FLARE FAST Cache a été introduite dans la version 30 de Block. Le temps de préparation pour FAST Cache nécessite d’accéder trois fois à un bloc 64 Ko avant qu’il soit admissible pour la copie sur le média Flash, tel qu’il est illustré dans Figure 21. Promotion vers FLARE FAST Cache.

Figure 21. Promotion vers FLARE FAST Cache

Le temps de préparation dépend entièrement de l’intensité des E/S et de la taille de la zone de travail. La zone de travail est la plage d’adresses LBA sur la LUN qui va être sollicitée par une charge de travail. Par exemple, la lecture/écriture sur un


fichier unique dans une petite base de données MS Access aura une zone de travail réduite. L’accès à la totalité d’une LUN de 2 To correspond à une zone de travail importante. Plus la zone de travail est importante, plus les chances d’accéder au même bloc 64 Ko plusieurs fois durant une charge de travail aléatoire seront faibles.

FAST Cache multicœur exploite le même modèle de promotion à 3 accès, illustré dans Figure 22. Préparation initiale de FAST Cache multicœur. La différence entre FLARE et MCx réside dans le placement de FAST Cache multicœur dans l’ordre du stack du système. Notez que FAST Cache multicœur est situé sous le cache multicœur, tandis que FLARE FAST Cache était situé au-dessus de FLARE Cache. Avec MCx, les frais supplémentaires pour passer de FLARE FAST Cache à FLARE Cache ont été supprimés.

Figure 22. Préparation initiale de FAST Cache multicœur

Gestion des pages

FAST Cache multicœur fonctionne avec une taille de page de 64 Ko. Lorsqu’une page est copiée pour la première fois sur FAST Cache, elle est marquée comme « propre ». Si elle est modifiée par une E/S d’écriture entrante, elle devient « non synchronisée ». Les pages non synchronisées sont copiées de nouveau sur le disque de données et redeviennent propres. La copie vers le disque est un processus asynchrone et se produit quelques temps après la confirmation de l’hôte. Lorsque c’est nécessaire, les pages propres les moins récemment utilisées sont remplacées par une nouvelle promotion FAST Cache à partir de toute LUN équipée de FAST Cache.

Le nettoyeur proactif est une amélioration de FAST qui copie les pages non synchronisées vers leurs disques de données respectifs et les nettoie dans FAST Cache. Le processus se produit lorsque l’activité de FAST Cache est relativement basse, tel qu’il est illustré dans Figure 23. Nettoyeur proactif de FAST Cache. Si les taux de promotion de nouvelle page et d’activité d’E/S de FAST Cache sont élevés, le nettoyeur a moins de chance de fonctionner. Par conséquent, le nombre de pages non synchronisées augmente ou stagne. Si l’activité est basse, le nettoyeur fonctionne plus souvent, réduisant progressivement le nombre de pages de données non synchronisées dans FAST Cache.

Le nettoyeur proactif utilise l’algorithme d’ancienneté pour sélectionner les pages non synchronisées à nettoyer. Tout comme le cache multicœur ; FAST Cache


multicœur ne supprime pas le contenu de la page après un vidage : une page propre peut être réutilisée par une autre copie.

Figure 23. Nettoyeur proactif de FAST Cache

Le maintien d’un faible nombre de pages non synchronisées est bénéfique à FAST Cache. Si la baie de stockage reçoit une nouvelle charge de travail, FAST Cache peut alors promouvoir les données plus rapidement puisqu’il n’a pas besoin de vider les pages non synchronisées vers les disques de données avant de libérer les anciennes pages à réutiliser.

Lorsque FAST Cache identifie que de nouvelles promotions requièrent de l’espace, il recherche d’abord des pages libres ou propres. S’il n’en trouve aucune, FAST Cache sélectionne le bon montant de pages non synchronisées avec l’algorithme d’ancienneté, les copie sur les disques de données (opération de vidage) avant de les réutiliser pour de nouvelles promotions, tel qu’illustré dans Figure 24. Nettoyage avant copie.

Figure 24. Nettoyage avant copie

Nombre minimal de pages

FAST Cache multicœur empêche chaque LUN d’utiliser toutes les pages disponibles au détriment des autres LUN. On utilise la mesure nombre minimal de pages pour garantir que les LUN se partagent équitablement l’espace de FAST Cache.


Le minimum est calculé en partageant équitablement 50 % de la totalité des pages de FAST Cache multicœur utilisées par toutes les LUN classiques ou privées du système. Tous les LUN peuvent disposer librement des 50 % restants. Si une LUN n’utilise pas le nombre minimal de pages, les autres LUN peuvent disposer librement des pages restantes. Le nombre minimal est ensuite ajusté pour être inférieur ou égal à la moitié de la taille de la LUN. Il s’agit d’un nombre dynamique qui est ajusté chaque fois qu’une LUN est liée ou détruite.

Lorsque FAST Cache est entièrement utilisé, ce qui est prévu pour un cache fonctionnant correctement, toute nouvelle promotion nécessite une page propre ou libre. FAST Cache choisit les pages afin que chaque LUN conserve son nombre minimal de pages pour ses données les plus utilisées.

Imaginez l’exemple illustré par la Figure 25. Nombre minimal de pages de FAST Cache multicœur :

FAST Cache a huit pages au total et le système comporte deux LUN. Le nombre minimal de pages de chaque LUN est défini sur 2 (la moitié des 8 pages fait 4 pages, divisées par deux LUN, qui en fait 2). Les promotions de la LUN A occupent six pages de FAST Cache, laissant deux pages disponibles. Quatre des six pages de LUN A sont très utilisées. Les deux autres le sont moins.

Figure 25. Nombre minimal de pages de FAST Cache multicœur

Ensuite FAST Cache commence à promouvoir les données de la LUN B. D’abord, les deux blocs de données de la LUN B obtiennent les deux pages disponibles. Une troisième promotion de la LUN B contraint FAST Cache à réaliser un vidage de la page la moins récemment utilisée sur le pool flottant vers la LUN A et à réutiliser la page pour les données de la LUN B.

Si d’autres données sont promues depuis la LUN B, elles occuperont jusqu’à trois pages supplémentaires sur le pool flottant, garantissant ainsi à la LUN A son nombre minimal de pages. Si deux LUN étaient ajoutées au système, le nombre minimal de pages passerait à une page par LUN.


Écritures sur FAST Cache

Une des améliorations de taille de cette version est la légère réorganisation du stack d’E/S : le mappage mémoire de FAST Cache est placé sous le cache multicœur, plutôt qu’au-dessus du cache dans FLARE, tel qu’illustré par la Figure 26. Comparaison des caches d’écriture FLARE et MCx. L’avantage est que MCx est plus rapide pour confirmer une écriture de l’hôte que la précédente implémentation de FAST Cache.

Figure 26. Comparaison des caches d’écriture FLARE et MCx

Avec FLARE, les E/S d’écriture (1) sont d’abord vérifiées dans le mappage mémoire FAST Cache (2) puis elles arrivent dans le cache (3). L’écriture est confirmée (4). Lorsque le cache est prêt à vider la page, il envoie les données soit à FAST Cache (5a) si le mappage mémoire a un pointeur FAST Cache, soit au disque de données (5b) s’il n’y a pas d’enregistrement FAST Cache.

Avec MCx, les E/S d’écriture (1) arrivent d’abord dans le cache multicœur (2). Une confirmation est immédiatement envoyée à l’hôte (3). Lorsque le cache multicœur est prêt à copier les données sur les disques, il envoie la page à FAST Cache, qui consultera le mappage mémoire (4), et selon que les données appartiennent à FAST Cache ou non les envoie à l’emplacement approprié : FAST Cache (5a) ou disques de données (5b).

MCx confirme l’écriture des E/S plus rapidement, il a un cache multicœur plus important et les données restent plus longtemps dans la RAM. Ces avantages combinés améliorent les performances globales du système par rapport à une implémentation basée sur FLARE.

Si la fonction d’écriture du cache multicœur est désactivée, la confirmation d’écriture entrante est retardée jusqu’à ce que l’E/S soit sauvegardée sur le disque Flash de FAST Cache multicœur ou sur le disque de données.

Lectures FAST Cache

Les opérations de lecture ont également changé avec MCx. Toutefois, l’effet global de ces modifications est moins évident pour les hôtes. Avec le nouveau VNX, le nombre des étapes pour une E/S de lecture reste le même qu’avec le VNX, tel qu’il est illustré dans Figure 27. Comparaison des caches de lecture FLARE et MCx.


Dans un VNX exécutant FLARE, l’E/S de lecture (1) est d’abord recherchée sur le mappage mémoire de FAST Cache (2). S’il existe un pointeur FAST Cache, les données sont lues depuis FAST Cache (3a), qui lit la ou les pages depuis les disques FAST Cache (4a). Si les données n’ont pas d’enregistrement dans le mappage mémoire de FAST Cache, la demande de lecture passe au cache (3b), qui y répond à partir des données déjà dans le cache s’il y a un succès de lecture ou à partir du disque de données (4b) s’il y a un échec de lecture. Les données sont chargées sur le cache et l’hôte reçoit une réponse (5).

Avec le nouveau VNX exécutant le package MCx, l’E/S de lecture (1) arrive d’abord dans le cache multicœur (2). En cas de succès de lecture, une réponse est immédiatement envoyée à l’hôte. En cas d’échec de lecture, le mappage mémoire de FAST Cache sera consulté (3). S’il existe un enregistrement FAST Cache, les données seront lues depuis le disques FAST Cache (4a). Dans le cas contraire, elles seront lues depuis le disque de données (4b). Les données sont chargées sur le cache multicœur et une réponse est envoyée à l’hôte (5).

Figure 27. Comparaison des caches de lecture FLARE et MCx

Interactions avec le cache multicœur

FAST Cache multicœur et le cache multicœur sont étroitement intégrés l’un dans l’autre. Les deux pilotes servent des fonctions spécifiques et se complètent l’un l’autre. Le cache multicœur protège FAST Cache multicœur contre les modèles d’accès à haute fréquence : la DRAM est plus rapide que le stockage Flash et convient donc mieux aux accès haute fréquence.

Le cache multicœur a des optimisations natives pour les E/S séquentielles de petit bloc : préchargement, fusion, régulation en écriture, etc. FAST Cache multicœur bénéficie directement de cette intelligence pour se concentrer sur sa propre charge de travail idéale : E/S aléatoire.

Ces deux fonctionnalités (Cache et FAST Cache) ont leurs propres points forts et s’aident mutuellement pour traiter les E/S correspondantes, améliorant ainsi les performances globales du système et simplifiant la gestion.

Options de configuration de FAST Cache multicœur

Les nouvelles baies de stockage de la gamme VNX disposent de FAST Cache multicœur d’une valeur maximale de 4,2 To (modèles VNX7600 et VNX8000), soit


deux fois plus que le modèle précédent VNX7500. MCx FAST Cache ne prend en charge que les paires RAID1 (mises en miroir). FAST Cache multicœur doit être configuré avec un nombre équivalent de disques. FAST Cache forme les paires RAID1 à partir du nombre de disques disponibles.


Le tableau ci-dessous décrit les capacités maximales de FAST Cache :

Modèle Capacité maximale de FAST Cache (arrondie)

Nombre* de disques Flash** 100/200 Go

VNX8000 Disques 100 Go : 2 100 Go

Disques 200 Go : 4 200 Go

De 2 à 42



De 2 à 42



De 2 à 30



De 2 à 20

VNX5400 Disques 100 Go : 500 Go


De 2 à 10

VNX5200 Disques 100 Go : 300 Go

Disques 200 Go : 600 Go

De 2 à 6

** Utilisez un nombre équivalent de disques

* N’utilisez pas des disques de tailles différentes


RAID multicœur RAID multicœur est le composant MCx qui définit, gère, crée et maintient la protection RAID de la gamme VNX. Il remplace le moteur FLARE RAID.

Multicore RAID s’adapte à plusieurs cœurs de CPU. Plus le processeur de stockage physique dispose de cœurs, plus le moteur RAID dispose de puissance de traitement. Les opérations de RAID MCx ne se limitent pas au CPU0.

RAID multicœur présente des améliorations considérables, telles que le remplacement permanent, la mobilité des disques, les règles de disques de secours et une plus grande longévité de RAID. Ces améliorations seront abordées dans les sections suivantes.

Remplacement permanent

Le remplacement ou remplacement par un disque de secours est le processus de reconstruction des données d’un disque défaillant sur un disque compatible sélectionné par le système. Le RAID multicœur autorise le remplacement permanent des disques défaillants par des disques de secours. Lorsqu’un disque tombe en panne, RAID multicœur le remplace par un disque non lié adapté. Ce nouveau disque fait alors partie du groupe RAID. Lorsque le disque défaillant est remplacé, le nouveau disque devient simplement non lié et disponible pour un futur remplacement.

Dans un cas similaire, FLARE aurait égalisé le disque de secours avec un disque de remplacement, ce qui signifie qu’il aurait recopié les données du disque de secours sur le nouveau disque. L’équalisation est nécessaire pour FLARE car elle permet de garder la structure du groupe RAID liée aux nombres de slots de disque. Lorsqu’un disque de secours est appelé, un nouveau slot temporaire est introduit dans la structure RAID.

RAID multicœur révolutionne le concept d’identification des disques. Au lieu d’utiliser l’emplacement physique comme identifiant du disque (comme FLARE), chaque disque est défini comme un disque virtuel et possède son propre numéro de série.

Comme il est illustré dans Figure 28. Remplacement permanent, un disque appartenant à un groupe RAID donné (rouge, par exemple) est tombé en panne (ou est remplacé par un mécanisme de copie proactive) et va être remplacé par un disque de secours. Le disque de remplacement devient alors membre du groupe RAID et le moteur RAID multicœur reconstruit le disque. Après la reconstruction, le groupe RAID fonctionnera normalement.

Figure 28. Remplacement permanent


Dans certains environnements, les clients peuvent encore avoir besoin de positions physiques fixes pour les groupes RAID. Par exemple, certains disques et/ou boîtiers DAE peuvent être liés pour des centres de coûts et applications spécifiques. C’est pourquoi un disque en panne devra être remplacé au même emplacement pour maintenir l’association. Le positionnement rigide peut aussi être dû à des réglementations gouvernementales exigeant un mappage matériel très spécifique. En cas de faille de sécurité potentielle, tous les disques contenant des données sensibles peuvent être rapidement et facilement retirés par n’importe qui selon un mappage du groupe RAID pré-établi apposé sur le panneau avant de la baie de stockage ou de l’armoire.

Dans ces cas-là, la CLI6 peut encore initier une copie manuelle (aussi appelée Copie sur disque). La copie est très semblable à une opération d’équalisation mais doit être initiée de façon manuelle. La commande ci-dessous permet d’initier une opération de copie à partir du disque situé dans le slot 2_0_14 vers le disque situé dans le slot 2_0_8.

C:>naviseccli -h VNX-SPA –User user –Password password –Scope 0

copytodisk 2_0_14 2_0_8

WARNING: The data from disk 2_0_14 will be copied to disk 2_0_8. This

process cannot be aborted and may take a long time to complete.

Do you wish to continue (y/n)? y

CLI 3. Copie vers un disque donné

Mobilité des disques

La mobilité des disques, également désignée par l’expression « disques portables », permet aux utilisateurs de déplacer les disques du VNX au sein de la baie. La mobilité des disques est étroitement liée au remplacement permanent.

La fonction RAID multicœur permet quant à elle de déplacer des disques et des boîtiers DAE entiers dans la même trame, depuis leur emplacement existant vers d’autres slots ou bus.

Remarque : lorsqu’ils sont déplacés entre des baies VNX, les disques ne conservent pas leurs données. Chaque baie conserve la trace de ses propres disques. Tous les disques nouveaux et inconnus sont automatiquement formatés et remis à zéro.

Les disques peuvent être déplacés vers n’importe quel slot de la baie, à condition d’être adaptés à l’espace disponible. Figure 29. Mobilité des disques illustre un groupe RAID rouge dont deux disques sont déplacés vers d’autres emplacements, voire vers un autre boîtier.

6 Unisphere permet d’initier une opération de copie sur le disque assez similaire mais sans l’option de choisir le disque de destination. Une fois démarré, Unisphere choisit un disque non lié adapté pour copier les données. L’algorithme décidant du disque est exactement le même que celui décidant du remplacement d’un disque en panne.


Figure 29. Mobilité des disques

FLARE identifie les disques grâce à leur adresse physique, par exemple, Bus 1 Boîtier 0 Disque 11 ou en version abrégé 1_0_11. Lorsqu’un disque est déplacé de 1_0_11 à 2_1_13, FLARE ne reconnaît pas le déplacement, il remarque simplement qu’un disque de l’emplacement 1_0_11 a été retiré et qu’un nouveau disque a été détecté sur l’emplacement 2_1_13. Par conséquent, toutes les données se trouvant sur le disque 1_0_11 ne sont pas reconnues par FLARE dans 2_1_13. RAID multicœur mémorise les disques grâce à leur numéro de série et comprend rapidement lorsqu’un disque a été déplacé.

RAID multicœur permet le déplacement des disques en ligne. Les données du groupe RAID restent disponibles après le retrait du disque Lorsqu’un disque devient indisponible (par exemple, en cas de panne, de retrait du slot, d’erreur de microprogramme, etc.), MCx entame un compte à rebours de 5 minutes. Après l’intervalle de 5 minutes, le remplacement du disque est invoqué. Pour plus d’informations, reportez-vous à la section Disques de secours.

Le retrait d’un disque actif dégrade son groupe RAID. Si un groupe RAID est créé avec une protection N+1 et qu’un disque est retiré, la protection +1 n’est plus disponible lorsque le disque est retiré. Si un autre disque tombe en panne alors que le disque est retiré de la baie, le groupe RAID connaît un événement « Données indisponibles » et devient défaillant.

Remarque : soyez vigilant lors du déplacement des disques dans la baie VNX.

Une fois le disque réinséré dans la baie, le groupe RAID retourne à un état opérationnel et sain sans aucune perte de données.

Recâblage du boîtier DAE

La mobilité des disques RAID multicœur optimise la disponibilité des bus back-end. Lors du recâblage du boîtier DAE, il est nécessaire de couper le courant mais avec la mobilité des disques, le recâblage peut se faire sans perte de données. Les utilisateurs peuvent simplement éteindre la baie de stockage, câbler les boîtiers DAE au besoin (généralement en utilisant plus de bus back-end, le spécialiste EMC à la manœuvre de cette procédure vous fera part de ses conseils et de son savoir-faire) et rallumer la baie. Dès le redémarrage, la baie localisera facilement les disques en sondant les numéros de série et en validant les membres du groupe RAID, puis il poursuivra les opérations.

Certains clients aiment réorganiser la totalité de leurs pools ou plusieurs groupes RAID pour diverses raisons telles que l’ajout de boîtiers DAE et de bus back-end. Même s’il est possible de réorganiser l’ensemble des disques alors que la baie est allumée et en fonctionnement, il est plus sûr et rapide d’éteindre la baie lors de


réorganisations importantes. Au redémarrage, les nouveaux emplacements des disques sont notés et aucune autre reconfiguration n’est nécessaire.

Disques de secours

RAID multicœur change l’approche classique concernant les disques de secours VNX. En effet, il n’est pas nécessaire de définir des disques de secours sur la baie. En fait, avec MCx il n’est plus possible de définir des disques de secours. MCx remplace les disques en panne par des disques non liés compatibles7.

Lors d’une panne de disque (sauf les disques système), RAID multicœur agira comme suit :

Il attendra 5 minutes o Le délai donne une chance au disque en panne de se restaurer

Une fois les 5 minutes écoulées, il recherchera un remplaçant adapté parmi les disques non liés de la baie

Une fois le disque trouvé : o il ajoutera le nouveau disque au groupe RAID o il démarrera le processus de reconstruction du disque

Le délai de 5 minutes évite d’inutiles reconstructions complètes de disque qui pourraient durer plusieurs jours. La nouvelle baie VNX résiste facilement aux erreurs humaines, lorsque le mauvais disque est retiré durant une procédure habituelle de remplacement de disque en panne. Si le disque est réinséré dans un délai de 5 minutes, la reconstruction sera évitée. Les conditions d’erreur légères récupérables peuvent désormais être réparées sans besoin d’invoquer une reconstruction complète du disque.

Reconstruction de disque

RAID multicœur reconstruit uniquement les sections utilisées des disques, une LUN à la fois, de haut en bas. Tout espace non utilisé n’est pas reconstruit, puisque rien n’y est à reconstruire.

Par exemple, dans Figure 30. Reconstruction de disque, le groupe RAID possède deux LUN : 0 et 1. Donc, chaque disque d’un groupe RAID héberge une partie de chaque LUN. Après la reconstruction, la zone LUN0 du nouveau disque sera reconstruite en premier lieu, puis viendra le tour de la zone LUN1.

Figure 30. Reconstruction de disque

7 Avec FLARE, il arrive qu’un disque en panne soit remplacé par un disque plus petit. Cela est possible uniquement lorsque le disque d’origine n’est pas entièrement utilisé, par exemple, son espace utilisé est assez petit pour être hébergé sur le disque plus petit. RAID multicœur ne prend pas en charge cette option. La taille du disque de secours est déterminé par les limites du groupe RAID.


Pour vérifier la progression (en pourcentage) de la reconstruction du disque 1_1_11à partir de la CLI, utilisez la commande suivante :


getdisk 1_1_11 -rb

Bus 1 Enclosure 1 Disk 11

Prct Rebuilt: 0: 10 1: 0

CLI 4. Progression de la reconstruction du disque

L’exemple ci-dessus montre que la zone LUN0 vient d’entamer sa reconstruction (10 % terminé) et que la LUN1 attend son tour (0 % terminé). Le processus de reconstruction de la LUN1 commencera lorsque celui de la LUN0 sera terminé à 100 %.

Si le second disque (par exemple, dans un groupe RAID6) tombe en panne, la statistique de progression de reconstruction (Prct rebuilt) de la LUN sera ajustée en fonction de l’espace de la LUN sur le second disque. L’espace combiné nécessaire à la reconstruction d’une LUN doublera (équivalent de deux disques), donc la progression de la reconstruction réduira de moitié.

Unisphere affiche la progression de la reconstruction d’une LUN individuelle dans les propriétés de la LUN, comme illustré dans Figure 31. Progression de la reconstruction d’une LUN.

Figure 31. Progression de la reconstruction d’une LUN

Unisphere affiche également l’état du disque comme Rebuilding (En reconstruction). Accédez à System >Hardware >Disks et dans la moitié inférieure de la fenêtre, vous trouverez une liste de tous les disques présents dans la baie, tel qu’il est illustré dans Figure 32. Reconstruction du disque ci-dessous.


Figure 32. Reconstruction du disque

Pour obtenir plus d’informations sur le processus, consultez les propriétés du disque (en faisant un clic droit sur le disque et en sélectionnant Properties (propriétés)). Lisez la statistiques « Copy to Disk % Complete » (progression de la copie sur le disque). Regardez la Figure 33. Propriétés du disque ci-dessous :

Figure 33. Propriétés du disque

Le calcul « Copy to Disk % Complete » concerne la volumétrie totale. L’illustration montre que 2 % de la volumétrie a été reconstruite, ce qui représente environ 55 Go d’espace pour un disque de 3 To (2 751 Go d’espace utilisable).

La CLI indique la même information :


getdisk 1_1_11 –all

<--- several lines abridged --- >

Prct Copied: 2

CLI 5. Progression de la copie sur disque

La progression de la LUN n’est pas calculée de la même manière. Le nombre « Percent rebuild » (progression de la reconstruction) pour la LUN est calculé du point de vue de la LUN. Le résultat getdisk obtenu avec la CLI a indiqué que la


LUN0 était reconstruite à 10 %, donc 55 Go correspondait à 10 % de la zone LUN0 à reconstruire sur le nouveau disque.

Explication mathématique de la reconstruction

Dans un système test, le disque 1_1_11 faisait partie d’un groupe RAID RAID6 4+2. Par conséquent, chaque LUN de ce groupe RAID était divisée sur quatre disques (deux8 disques avaient la parité).

Les étapes suivantes décrivent le calcul complet (reportez-vous à Figure 30. Reconstruction de disque) :

La reconstruction de 2 % du disque total correspond à 2 751 Go* 2 % = 55 Go.

La LUN0 occupe environ 550 Go (10 % LUN0 * 55 Go) sur le disque 1_1_11.

Le volume total de la LUN0 est de 4*550 Go = 2 200 Go (le nombre de disques de données dans le groupe RAID multiplié par la zone LUN0 sur un seul disque).

Règles de remplacement

RAID multicœur inclut également une modification de petite ampleur mais très utile aux règles de remplacement de VNX. Les règles de remplacement définissent l’ordre et la logique de recherche pour localiser le disque le mieux adapté pour remplacer un disque en panne. RAID multicœur y ajoute une règle qui préfère utiliser un disque du même boîtier à un autre situé dans un autre boîtier.

Pour sélectionner un disque de remplacement adapté, la baie de stockage utilise la logique suivante illustrée dans Figure 34. Règles de remplacement :

1. Type : la baie recherche tous les disques disponibles du même type (SAS, FLASH, NL-SAS, etc.) que le disque en panne.

2. Bus : parmi les disques trouvés, la baie sélectionne les disques situés sur le même bus.

3. Taille : parmi les disques trouvés, elle sélectionne ensuite les disques d’une capacité de groupe RAID égale (ou supérieure).

4. Boîtier : enfin, le système vérifie si un des disques trouvés se situe dans le même boîtier que le disque en panne.

S’il existe plusieurs disques répondant aux critères, la baie sélectionne l’un d’entre eux.

Remarque : les critères de la logique décrite ci-dessus sont classés de la priorité la plus haute à la plus basse, le type de disque étant le critère le plus important. Cette logique est spécialement conçue pour sélectionner le disque de remplacement le plus proche du disque en panne. Par exemple, un disque de remplacement de même type et situé sur le même bus qu’un disque en panne sera toujours préféré à un disque situé sur un autre bus.

8 La vraie distribution est un peu plus compliquée pour RAID6 car la parité est aussi distribuée mais cette approche simplifiée suffit à illustrer nos propos


Figure 34. Règles de remplacement

Comme il a été indiqué plus tôt, le remplacement commence après un délai de 5 minutes suivant la déconnexion d’un disque. La technologie de remplacement proactif, qui évacue les données hors du disque sur le point de tomber en panne, n’observe pas ce délai de 5 minutes. La capacité de l’administrateur du bus de copie d’utilisateur manuelle permettant d’entamer une copie manuelle vers un nouveau disque n’observe pas non plus ce délai.

Disque de remplacement adapté

Lors de la sélection d’un disque adapté, RAID multicœur n’utilise pas toujours la taille et le type du disque en panne. Il utilisera un disque qui convient mieux à la taille du groupe RAID d’origine.

Par exemple, un disque utilisé dans le groupe RAID créé sur des disques SAS 300 Go tombe en panne. Le seul remplacement adapté présent est un disque SAS 900 Go, qui reconstruit les données et gaspille environ 600 Go de capacité utile. Lorsqu’un nouveau disque de 300 Go remplace le disque en panne, il devient non lié.

Pour amener le nouveau disque de 300 Go dans le groupe RAID et libérer le disque de 900 Go sous-exploité, il peut être judicieux d’effectuer une copie vers le disque manuelle par le biais de la commande CLI. Sinon, si (à un moment donné) le disque de 900 Go tombe aussi en panne, RAID multicœur cherchera un disque de 300 Go adapté et pas un disque de 900 Go.

Matrice de remplacement des disques

Les baies de stockage de la gamme VNX prennent en charge beaucoup de types de disque différents pour répondre aux exigences de nos clients professionnels. Cette large sélection nécessite l’implémentation de nombreuses règles de compatibilité.

Par exemple, il existe deux familles parmi les derniers disques Flash : les disques Flash SAS et VP Flash SAS. Même s’ils paraissent quasiment identiques, ils diffèrent beaucoup à un niveau de technologie sous-jacent. Ces deux types de disque ne peuvent pas se remplacer l’un l’autre. Toutefois, un disque SAS 3,5 pouces 600 Go 15 000 t/min peut servir de disque de secours pour un disque SAS 2,5 pouces 300 Go 10 000 t/min.

Pour simplifier le choix et pour plus de commodité, reportez-vous à la matrice suivante :


Figure 35. Matrice de remplacement des disques

Compatibilité des disques de groupes RAID et de pools

Figure 35. Matrice de remplacement des disques affiche les groupes de disques organisés en ensembles de quatre groupes RAID. La compatibilité entre chaque ensemble est utilisée pour le remplacement et la création de groupe RAID. Avec le système VNX, les groupes RAID ne peuvent contenir des disques issus de différents ensembles. Par exemple, des disques SAS et NL SAS ne peuvent pas être utilisés dans le même groupe RAID. Il en va de même pour des disques VP Flash SAS et Flash SAS. Toutefois, les disques Flash SAS et Flash SATA sont compatibles à 100 % et peuvent composer un même groupe RAID.

Pour les niveaux de pools, l’approche est différente. Les pools VNX prennent en charge jusqu’à trois niveaux [8] et chacun d’entre eux nécessite un ensemble de groupe RAID bien précis, à l’exception du niveau Performances extrêmes qui a besoin de deux ensembles. Bien qu’il soit impossible de configurer des disques VP Flash SAS dans le même groupe RAID que des disques Flash SAS/SATA, les groupes RAID privés créés à partir de chaque ensemble peuvent faire partie du niveau Performances extrêmes dans le même pool.

Dans Unisphere, en présence de disques provenant d’ensembles Flash et VP Flash, la section Performances extrêmes de la création du pool contient deux listes déroulantes, une pour chaque ensemble :


Figure 36. Niveau Performances extrêmes

Règle relative aux disques de secours

RAID multicœur introduit un nouveau concept pour la baie de stockage VNX. Il s’agit de la capacité à prévenir l’administrateur concernant l’état de disques de remplacement utilisables dans le système.

Pour cela, RAID multicœur dispose désormais de règles relatives aux disques de secours. Une règle relative aux disques de secours surveille un nombre de disques non liés (disques de remplacement potentiels) d’un certain type dans le système et envoie un avertissement lorsque ce nombre est bas.

Il existe trois règles relatives aux disques de secours :

Recommended (Recommandé) : 1 disque de secours pour 30 disques de chaque type.

Custom (Personnalisé) : l’administrateur est autorisé à définir le ratio. No Hot Spares (Aucun disque de secours) : la surveillance exercée par la

règle est désactivée.

Remarque : la règle Aucun disque de secours n’empêche en rien le remplacement. Un disque en panne sera toujours remplacé, s’il existe un disque non lié adapté.

Remarque : dans les cas où la règle Recommandé ne correspond pas aux bonnes pratiques d’un disque de secours pour 30 disques, utilisez la règle Personnalisé.

RAID multicœur définit une règle pour chaque type et taille de disque pris en charge mais ne distingue pas les vitesses de disque ou les encombrements. Par exemple, RAID multicœur ne différencie pas un disque SAS 2,5 pouces 600 Go


avec une vitesse de 10 000 t/min d’un disque SAS 3,5 pouces 600 Go avec une vitesse de 15 000 t/min lors d’un remplacement. Ces deux disques sont considérés comme semblables et donc compatibles pour un remplacement.

Les règles relatives aux disques de secours sont spécifiquement définies par le type et la volumétrie des disques. Par exemple, des disques SAS 300 Go et des disques SAS 600 Go ont des règles relatives aux disques de secours différentes, comme il est illustré dans Figure 37. Règle des disques de secours. La nouvelle baie de stockage VNX, représentée ci-dessous, compte 10 disques SAS 300 Go déjà utilisés. Le système n’affiche pourtant aucun avertissement, car la règle Aucun disque de secours est définie. Cependant, si l’un des disques SAS 300 Go tombe en panne, RAID multicœur le remplacera par son disque le plus adapté. Dans ce cas, il s’agira d’un des 40 disques SAS 600 Go non liés (reportez-vous à la rubrique Figure 35. Matrice de remplacement des disques pour une liste complète des disques compatibles).

Figure 37. Règle des disques de secours

Lorsque vous créez un pool de stockage composé de disques SAS de 600 Go (reportez-vous à la rubrique Figure 38. Création d’un pool de stockage), l’assistant Unisphere Create Storage Pool (Créer le pool de stockage) n’affiche que 38 disques disponibles, car si 40 disques non liés sont effectivement disponibles, 2 d’entre eux sont réservés comme disques de secours par la règle.

Remarque : EMC recommande d’utiliser 35 disques pour un niveau de performances fonctionnel et non 38.


Figure 38. Création d’un pool de stockage

Si un utilisateur passe à la sélection manuelle des disques, il pourra sélectionner les 40 disques. Cependant, une violation de la règle relative aux disques de secours surviendra et une alerte s’affichera, tel qu’il est illustré dans Figure 39. Violation d’une règle relative aux disques de secours.

Figure 39. Violation d’une règle relative aux disques de secours


Dimensionnement de disque

Tout comme FLARE, RAID multicœur formate les disques avant de les utiliser. Le formatage alloue de l’espace utile pour l’utilisateur et certaines métadonnées de disque virtuel. Si les disques sont placés dans un pool ou un groupe RAID; il est également possible qu’un peu de capacité soit réservé aux métadonnées RAID. Les LUN ont des métadonnées supplémentaires. Reportez-vous à la rubrique Figure 40. Carte du disque RAID multicœur).

Figure 40. Carte du disque RAID multicœur

Les tailles de disque brutes sont les mêmes pour les baies de la gamme VNX et ceux de la nouvelle gamme VNX. La charge supplémentaire de RAID (y compris celle liée aux métadonnées de disque virtuel) est plus petite dans RAID multicœur que dans FLARE.

Figure 41. Comparaison de la surcharge MCX et FLARE

La différence est minime mais elle existe. Par exemple, un groupe RAID5 4+1 MCx avec des disques SAS 2,5 pouces 600 Go dispose de 5,6 Go de capacité utile de plus qu’un groupe RAID FLARE équipé des mêmes disques. Ainsi, les données transférées des anciens systèmes VNX vers la nouvelle baie de stockage VNX tiendront dans des groupes RAID ou pools à la configuration semblable. Ce n’est pas le cas dans le sens inverse : les limites de l’espace de disque doivent être prises en compte lors de la planification d’une migration d’une nouvelle baie VNX vers des modèles plus anciens.

On peut également parler de la compatibilité de disque entre les nouveaux systèmes VNX et leurs prédécesseurs. MCx ne reconnaît pas les disques qui utilisent les microprogrammes des anciens modèles VNX. Contactez un responsable de compte EMC local pour en savoir plus sur la compatibilité de disque.

Avertissement : ne déplacez pas un disque d’une baie FLARE vers une nouvelle baie VNX. Le disque ne sera pas reconnu, le slot continuera à être marqué comme vide et le voyant de défaillance du disque s’allumera.


Reconstruction parallèle RAID6

RAID multicœur introduit une autre technologie : la reconstruction parallèle. Lorsqu’il manque deux membres à un groupe RAID6, ce dernier reconstruit les disques de secours en parallèle, contrairement à FLARE qui les reconstruit de façon séquentielle.

Voici un exemple de processus de reconstruction parallèle, tel qu’illustré dans Figure 42. Reconstruction parallèle RAID6 :

1. Le premier disque de RAID6 tombe en panne. La baie entame un compte à rebours de 5 minutes. À la fin de ce dernier, un disque de secours adapté est trouvé et le processus de reconstruction commence. Le disque de secours est construit à partir du haut.

2. Une fois le disque de secours construit à 30 %, un second disque tombe en panne. La baie attend 5 minutes supplémentaires. Le premier disque de secours continue sa reconstruction et atteint les 50 %.

3. Au bout de 5 minutes, un disque de secours adapté est trouvé et le processus de reconstruction du second disque commence, dans ce cas au niveau du dernier bloc reconstruit sur le premier disque de secours, par exemple, en commençant par un repère à 50 %. La reconstruction des deux disques de secours se poursuit en parallèle.

4. Le premier disque de secours est terminé à 100 % et est désormais un membre RAID à part entière. Le second disque de secours recommence sa reconstruction depuis le début, jusqu’à ce qu’il atteigne le repère à 50 %, où a commencé la reconstruction.

Figure 42. Reconstruction parallèle RAID6

Remise à zéro d’un disque

MCx a changé la façon dont les baies VNX traitent les nouveaux disques. RAID multicœur remet toujours à zéro les disques nouveaux et inconnus insérés dans le système avant de les utiliser. Si un disque est déplacé entre des baies compatibles9, il est toujours remis à zéro en premier lieu. La remise à zéro d’un disque est une opération qui s’effectue en arrière-plan, elle peut toutefois nuire aux performances. La remise à zéro des données ne peut pas être désactivée.

9 Veuillez vérifier la compatibilité entre la baie et le disque avec EMC E-LAB Interoperability Navigator [3].


Remarque : les performances des nouvelles baies peuvent sembler plus lentes en raison de la remise à zéro des disques, consultez les logs pour déterminer si une remise à zéro de disque est en cours.

La commande CLI suivante montre les messages indiquant qu’une mise à zéro de disque est terminée :


getlog | find "0_1_7"

06/20/2013 XX:YY:ZZ N/A (71680108)Zeroing of disk 0_1_7 (obj 121)

started 00 00 04 00 09 00 2c 00 d3 04 00 00 08 01 68 61 08 01 68

61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 71 68

01 08 sep

06/21/2013 XX:YY:ZZ N/A (71680109)Zeroing of disk 0_1_7 (obj 121)

finished 00 00 04 00 09 00 2c 00 d3 04 00 00 09 01 68 61 09 01 68

61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 71 68

01 09 sep

CLI 6. Affichage des entrées de log d’une remise à zéro de disque

À la différence de FLARE, MCx permet l’utilisation des disques durant une remise à zéro. Ils peuvent être placés dans un pool, un groupe RAID. Des LUN peuvent y être liées et des données y être écrites.

RAID multicœur garde des traces des zones du disque remises à zéro. Lorsqu’une E/S de l’hôte est demandée (lecture ou écriture), RAID multicœur commence par consulter la carte de remise à zéro. Figure 43. Remise à zéro d’un disque représente les zones déjà remises à zéro en vert foncé et les zones ayant besoin d’une remise à zéro en vert clair, orange clair et bleu clair. Si l’E/S de l’hôte s’adresse à une zone déjà remise à zéro, l’E/S est autorisée. Si l’E/S de l’hôte s’adresse à une zone pas encore remise à zéro, RAID multicœur remet d’abord cette zone à zéro, puis autorise l’E/S.

Figure 43. Remise à zéro d’un disque

Remarque : la technologie de remise à zéro de disque VNX n’est pas conforme aux régulations ou normes de suppression sécurisée. Utilisez d’autres moyens approuvés de nettoyage des données si la conformité est requise.


Remise à zéro de LUN

Dans certaines instances, RAID multicœur remet à zéro les LUN. C’est le cas lorsqu’une nouvelle LUN chevauche une zone qui appartient à une LUN déjà non liée.

L’illustration ci-dessus montre que le disque hébergeait deux LUN qui étaient déjà non liés. Lorsqu’une nouvelle LUN est liée, RAID multicœur la remet à zéro avec les mêmes règles qui s’appliquent pour la remise à zéro de disque : du haut vers le bas, remet à zéro tous les blocs, ne laisse pas les E/S de l’hôte atteindre un bloc non remis à zéro.

Les remises à zéro de LUN et de disque sont exécutées par le même processus. Si la remise à zéro de disque est en cours et que la baie veut remettre la LUN à zéro, la demande est envoyée au même pilote qui continue avec la remise à niveau du disque.

Le processus de remise à zéro de la LUN a connaissance des blocs remis à zéro préexistants. Si une nouvelle LUN est créée et qu’elle chevauche une LUN non liée plus ancienne (tel qu’il est illustré dans Figure 44. Remise à zéro de LUN), mais que les zones non liées ne sont pas utilisées et toujours à zéro, le processus de remise à zéro de la LUN fonctionne simplement plus rapidement. La baie n’a pas besoin de remettre à zéro les mêmes blocs deux fois.

Figure 44. Remise à zéro de LUN

Consignation des reconstructions

Lorsqu’un disque VNX utilisé activement se déconnecte (par exemple, en cas de panne, de retrait du slot ou de non-réponse temporaire pour une autre raison), RAID multicœur active un mécanisme de protection RAID appelé Consignation des reconstructions. Le groupe RAID lui-même montre un état dégradé lorsqu’un des disques manque. Cela est vrai pour tous les types RAID redondants10.

La consignation des reconstructions marque tous les blocs de données qui ont été mis à jour sur un membre RAID manquant. Le marquage est stocké en tant que carte de bloc faisant partie des métadonnées du groupe RAID. Les métadonnées RAID sont stockées dans les disques du groupe RAID. Imaginez les métadonnées RAID comme une petite LUN cachée dans la dernière rangée du groupe RAID.

Figure 45. Consignation des reconstructions affiche une bande RAID entière en cours de construction dans le cache (y compris la parité). Toutefois, étant donné

10 Les types RAID redondants pris en charge par le système VNX sont : RAID6, RAID5, RAID3, RAID1 et RAID10.


que le groupe RAID est dégradé (il manque le membre 3), les données destinées au membre 3 sont supprimées du processus d’écriture de la bande entière vers les disques (communément appelé vidage du cache multicœur). Les métadonnées du groupe RAID (appelées log RAID dans le graphique) seront mises à jour avec un enregistrement des blocs du membre 3 qui auraient dû être mises à jour dans le cadre de l’écriture complète de bande.

Figure 45. Consignation des reconstructions

Pour une écriture partielle de bande, la logique reste la même. La parité est calculée à partir des informations de bande complète (les blocs manquants sont lus depuis les disques). Toutefois, comme il manque le membre 3, la parité ne sera pas valide après la reconnexion du disque. Par conséquent, le log est mis à jour dans l’emplacement des blocs de parité. Une fois le disque reconnecté, RAID multicœur reconstruit simplement les blocs marqués dans le log et éteint la consignation des reconstructions.

La consignation des reconstructions est active tant que le groupe RAID est en mode dégradé. Si une baie n’invoque pas un disque de secours après un délai de 5 minutes (par exemple, lorsqu’aucun disque non lié compatible n’est présent dans le système), la consignation des reconstructions continue à fonctionner jusqu’à ce que le groupe RAID se déconnecte ou qu’un disque adapté soit trouvé.

Le log est une carte des bits créée durant la création du groupe RAID dans la zone des métadonnées. Ce log définit la taille de la surcharge du groupe RAID. Par conséquent, il ne peut pas manquer d’espace. Le log est persistant ; c’est-à-dire qu’un processus de reconstruction interrompu par un redémarrage continuera après la restauration de l’alimentation.

La consignation des reconstructions permet au VNX d’éviter les reconstructions complètes du groupe RAID. Ainsi, le VNX peut réutiliser les bonnes données issues d’un disque ayant été temporairement inactif, ce qui réduit significativement le besoin de reconstruire des disques entiers.

Consignation des écritures

Les données écrites sur un disque dur VNX sont de deux natures : les données utilisateur et le contrôle de redondance cyclique (CRC) [6]. Le checksum est une protection de base contre les erreurs de média. Durant la lecture, le VNX calcule un nouveau CRC et le compare avec celui du disque. Si les deux correspondent, les données sont correctes. Dans le cas contraire, le bloc est marqué comme « Mauvais » et une condition erreur de checksum est consignée.


Un processus VNX interne appelé vérification en arrière-plan examine le fonctionnement des données stockées sur le disque. Il lit les checksums sur les données existantes et les compare aux données calculées. Lorsqu’une incohérence est détectée, la vérification en arrière-plan tente de la réparer avec la protection RAID. Un autre processus appelé Sniffer vérifie l’état physique du disque. Il marque les mauvais blocs média comme erreur de médias. Pour plus d’informations, reportez-vous aux sectionsVérification en arrière-plan et Sniffer.

Les incohérences et erreurs médias sur chaque disque sont enregistrées et comptées. Lorsqu’un nombre suffisant d’erreurs est enregistré, le disque est déclaré comme étant non fonctionnel et un processus de remplacement proactif démarre.

Même si la vérification en arrière-plan et Sniffer peuvent détecter des erreurs, ils ne peuvent pas restaurer les données sur des groupes RAID de parité dégradés. Les erreurs de médias surviennent pour des raisons naturelles comme une mauvaise condition magnétique de la plaque, une décroissance de l’activité des données Flash ou un mouvement trop important du disque à rotation.

Une nouvelle technologie du RAID multicœur appelée Consignation des écritures écrit une entrée de journal sur le même disque avant de procéder à une écriture réelle, comme il est illustré dans la rubrique Figure 46. Consignation des écritures. Si l’écriture de journal est validée sans problème, le système du RAID multicœur procède à la validation de l’écriture vers son adresse de destination sur le disque. Une fois l’écriture correctement validée sur le disque, l’entrée de journal est invalidée et l’écriture est marquée comme propre dans le cache (cache multicœur).

Figure 46. Consignation des écritures

Les pages de cache multicœur non synchronisées et non validées sont protégées par le mécanisme de chambre forte (qui est abordé dans la section Disques système). Une fois qu’un groupe RAID refonctionne après une condition de défaillance (par exemple, redémarrage après un arrêt imprévu, restauration après la déconnexion de plusieurs disques), les entrées de journal actives sont recherchées dans la zone du journal. Si l’on en trouve, elles sont reproduites aux emplacements adéquats.

La consignation des écritures est active uniquement lorsqu’un groupe RAID est à l’état dégradé, tout comme la consignation des reconstructions. Ces deux technologies coexistent. La consignation des écritures écrit le journal dans la zone des métadonnées du groupe RAID dans le disque de destination comme il est illustré dans la rubrique Figure 40. Carte du disque RAID multicœur. Le journal contient l’écriture réelle ainsi que les métadonnées. Son espace est limité et géré


par un tampon circulaire. Lorsqu’il est plein, les écritures entrantes sont retardées jusqu’à ce que les premières entrées soient invalidées.

La consignation des écritures entraîne une dégradation des performances : chaque écriture de disque est désormais doublée. Toutefois, la perte de performance est acceptable au regard des avantages. De plus, la consignation des écritures remplace une ancienne technologie FLARE appelée suspension de la parité [7], qui minimisait la perte de données lorsque le groupe RAID était à l’état dégradé. La suspension de la parité n’est plus utilisée car la consignation des écritures constitue une meilleure solution globale.

Disques système MCx modifie la configuration des disques du système VNX. Tout comme FLARE, l’espace du système VNX occupe les quatre premiers disques du premier boîtier DAE ou boîtier du processeur de disques, selon le modèle de la baie VNX. Toutefois, avec MCx, la taille de la zone du système a augmenté de près de 300 Go par disque.

Remarque : par simplicité, utilisez des disques 300 Go pour vos disques système.

Le système VNX inclut :

le secteur de démarrage VNX et des LUN de système d’exploitation internes ;

la chambre forte du cache multicœur : une LUN spéciale utilisée par le cache multicœur pour stocker les pages de cache non synchronisées en cas de coupure de courant ;

des LUN de contrôle NAS : un ensemble de six LUN utilisé pour les données de fichier.

La totalité du contenu de l’espace du système ne peut pas être visualisé par l’utilisateur.

Lorsque la chambre forte est construite avec des disques SAS 300 Go, il ne reste plus d’espace utilisateur libre sur le VNX. Des disques plus importants laissent un peu d’espace disponible, comme il est illustré dans Figure 47. Les disques système.

Figure 47. Les disques système


L’espace du système ne nécessite pas de remplacement car le VNX utilise une protection interne spéciale pour les données.

Remarque : un disque système en panne doit être remplacé physiquement.

Les disques système avec de l’espace utilisable par l’utilisateur fonctionnent comme des disques classiques, avec un espace utile ajusté. Ils peuvent être placés dans des groupes RAID standard mais pas dans des pools. Lorsque le disque de chambre forte tombe en panne, les données de l’espace d’utilisateur sont transférées sur un disque de secours adapté.

Si un disque système est déplacé sur un autre slot, le VNX :

1. marque le disque système comme étant « retiré » ;

2. formate et remet à zéro l’ancien disque système dans le nouveau slot :

a. toutes les données (y compris les espaces de l’utilisateur et du système privé de chambre forte) sur l’ancien disque de système seront supprimées (remise à zéro).

b. Si le disque système déplacé faisait partie d’un groupe RAID, la portion de l’espace dédiée à l’utilisateur sera transférée selon les procédures de reconstruction RAID classique, après un délai de 5 minutes.

Si un disque est déplacée vers un slot système (0_0_0 à 0_0_3), le comportement est presque le même, à quelques exceptions près notées en italique. La nouvelle baie VNX :

1. marque le disque comme étant « retiré » :

a. entame un compte à rebours de 5 minutes avant le remplacement du disque déplacé par un disque de remplacement adapté.

2. formate et remet à zéro le disque dans le nouveau slot :

a. réserve 300 Go d’espace de système ;

b. laisse l’espace restant inutilisé (le cas échéant).

Exemples de synthèse de RAID multicœur Afin de suivre les exemples suivants, consultez l’exemple RAID5 3+1 dans Figure 48. Consignation des reconstructions et des écritures. Lorsque le disque membre 3 tombe en panne, le groupe RAID devient dégradé et les consignations des reconstructions et des écritures démarrent. Un compte à rebours de 5 minutes démarre retardant le processus de remplacement. Les performances du groupe RAID sont ralenties (surcharge de la consignation des écritures).


Figure 48. Consignation des reconstructions et des écritures

Un hôte écrit 8 Ko sur la LUN1, adresse 0x400. Dans cette exemple, 0x400 est situé sur le disque membre 0 de ce groupe RAID. L’écriture est validée dans le cache VNX (cache multicœur) et marquée comme non synchronisée. À un moment donné, le cache multicœur réalisera un vidage de cette écriture sur le disque. Cela entraîne une lecture du disque membre 2 pour calculer la parité. À présent, les écritures des E/S de l’hôte et de parité sont écrites sur le groupe RAID, les E/S de l’hôte d’origine sur le membre 0 du RAID et la parité sur le membre 1 du RAID.

Comme le groupe RAID est dégradé, les entrées du journal sont d’abord écrites sur les deux disques. Une fois les entrées du journal validées, les deux écritures sont traitées à leur emplacement normal. Une fois correctement validées, la consignation des reconstructions marque les blocs comme étant mis à jour et la consignation des écritures invalide les journaux.

Scénario A : le disque en panne se reconnecte

Lorsqu’un disque en panne se reconnecte (il a été déplacé sur un autre slot, par exemple), le log des reconstructions est examiné et les blocs marqués comme étant modifiés sont reconstruits sur le membre 3. La consignation des écritures et des reconstructions s’arrête et le mode du groupe RAID revient à la normale.

Scénario B : un autre disque tombe en panne

Si un autre disque tombe en panne (le membre 0 par exemple), le groupe RAID devient défaillant. Un groupe RAID5 dégradé ne peut pas supporter deux pannes de disque. RAID6 reste toutefois en mode dégradé, sauf si trois membres tombent en panne. Lorsque vous déplacez des disques actifs d’un slot à un autre, sachez que le risque de panne augmente.

Figure 49. un autre disque tombe en panne


Pour savoir si des données seront perdues dans le cas d’une seconde panne de disque, lisez les scénarios suivants. La réponse dépend de la cause de la panne. Veuillez consulter Figure 49. un autre disque tombe en panne ci-dessus.

B1. Le disque du membre 0 est retiré :

a. il reviendra à un moment donné avec toutes ses données intactes.

B2. Le disque du membre 0 est irrécupérable :

a. il ne reviendra pas

B3. Le boîtier DAE est éteint :

a. le boîtier DAE se rallumera ou ;

b. les disques qu’il contient seront déplacés vers d’autres slots.

Pour chacun de ces scénarios, nous supposons que le reste la baie fonctionne normalement.

Scénario B1

Le disque du membre 0 est retiré, le groupe RAID passe à l’état défaillant et arrête d’accepter les E/S.

Les données écrites sur les autres disques restent intactes. Les données écrites sur le disque membre 0 sont protégées par la consignation des écritures, même s’il existe un trou d’écriture, le journal peut le restituer. Les données n’ayant pas été vidées du cache multicœur sont toujours dans le cache. L’accusé de réception du vidage n’a pas été renvoyé et les données sont toujours marquées comme non synchronisées. Le cache multicœur publiera un avertissement concernant les données non synchronisées ne pouvant pas être sauvegardées sur le disque à cause d’une panne de disque. Toutes les activités d’E/S vers le RAID sont suspendues. Les hôtes recevront des réponses d’erreur d’E/S.

Dans le cas où le membre 0 revient, la consignation des écritures est observée et les entrées de log valides sont reproduites. La cohérence du groupe RAID est examinée (similaire à un processus FSCK, si les LUN étaient des systèmes de fichiers). Si aucune incohérence n’est trouvée, le groupe RAID est reconnecté. Les consignations des reconstructions et des écritures sont redémarrées. Le cache non synchronisé est vidé.

Dans ce sous-scénario, les données sont indisponibles jusqu’à ce que le disque 0 soit restauré mais aucune donnée n’est perdue.

Scénario B2

Si le disque 0 est en panne et irrécupérable, les données s’y trouvant ne sont plus disponibles. Il n’existe aucun moyen de récupérer les données. Toutes les données du groupe RAID sont perdues.

Scénario B3

Ce scénario est similaire au scénario B1. Tous les disques deviennent indisponibles en même temps, le journal des écritures et le log des reconstructions ont donc des entrées cohérentes. Lors de la connexion du boîtier DAE, ou du déplacement des disques vers de nouveaux sites, la baie peut redémarrer ce groupe RAID.


Scénario C : expiration du délai de 5 minutes

Quand le délai de 5 minutes a expiré, la baie recherche un disque de secours adapté. Une fois trouvé, le processus de reconstruction du groupe RAID commence. Les LUN sont reconstruites de façon séquentielle, du haut du disque vers le bas. Les processus de consignation des reconstructions et des écritures continuent jusqu’à ce que le disque soit reconstruit à 100 %.

Si le disque membre 3 se reconnecte au cours du processus de reconstruction, il sera considéré comme un nouveau disque et remis à zéro. En effet, l’ancien disque membre 3 ne fait plus partie du groupe RAID et son contenu n’est plus pertinent. Le VNX n’interrompt pas une reconstruction de groupe RAID en cours.


Résumé MCx est l’un des stacks de systèmes de stockage les plus avancés disponibles sur le marché. Comme il est expliqué dans ce document, il apporte beaucoup d’innovation dans une évolution de système multicœur horizontale très efficace.

En plus d’une plate-forme plus efficace, le stack optimisé multicœur offre une gestion des médias et une protection des données solide. Avec MCx, FAST Cache multicœur occupe la place qu’il faut dans la hiérarchie de stockage, permettant des écritures sur la DRAM plus rapides tout en offrant jusqu’à 4,2 To de cache de données.

MCx élève l’expérience de stockage milieu de gamme VNX d’EMC à un niveau inexploré. Avec une vitesse d’un million d’E/S par seconde, jusqu’à 600 To de mémoire Flash et jusqu’à 6 Po de stockage sur disque, MCx assure une performance régulière, efficace et fiable. Cette solution permet aux clients EMC de réduire les coûts de stockage par machine virtuelle de 300 %.


Annexe A : Différences majeures entre MCx et FLARE Cette section résume les changements de MCx par rapport à FLARE.

Nouveaux disques

Tous les disques non reconnus avec des numéros de série n’ayant pas été déjà rencontrés par la baie sont remis à zéro. Tous les disques sont remis à zéro en parallèle. La remise à zéro commence au moment où la baie découvre le nouveau disque ou au premier démarrage du système. Les disques sont disponibles durant leur remise à zéro.

Espace utile par disque

Des disques de taille équivalente ont le même espace utile sur tous les systèmes VNX (y compris sur du matériel moins récent). La surcharge de groupe RAID est presque la même pour RAID multicœur qu’avec FLARE. La surcharge RAID avec MCx est un peu moins importante.

Lors du dimensionnement des nouvelles implémentations VNX, il est plus sûr d’utiliser des numéros de capacité de groupe RAID VNX plus anciens. La capacité utile reste la même pour les disques de taille identique.

Remise à zéro des disques et des LUN

La baie remet à zéro les disques. Elle peut en faire de même avec les LUN. La remise à zéro des LUN est une mise à jour des métadonnées, si la LUN est liée à un disque déjà remis à zéro. Si une LUN est liée à un disque qui a ÉTÉ utilisé avec une LUN non liée ou dans un pool détruit, la zone de la LUN est remise à zéro après la création de la LUN.

Priorité SCSI

MCx inclut une technologie qui définit la priorité pour les commandes SCSI pour les disques back-end. La présence de la priorité SCSI garantit le nouveau microprogramme du disque et le formatage. EMC utilisait déjà cette technologie sur les baies VMAX et l’utilise désormais sur les VNX.

La première implémentation n’implique que des vidages d’écritures du cache multicœur.

Reprise d’erreur d’E/S

Contrairement à FLARE qui jugeait du bon fonctionnement d’un disque en comptant le nombre d’échecs d’E/S, la reprise d’erreur d’E/S d’un disque MCx est basée sur le temps. Avec RAID multicœur, si une E/S envoyée au disque est plus longue que prévu, le disque peut être marqué comme étant hors ligne. Le groupe RAID passe à l’état dégradé, jusqu’à ce que le disque réponde de nouveau ou qu’il soit remplacé (après 5 minutes).

RAID multicœur garde une trace permanente de toutes les erreurs de disque. Un disque instable devient rapidement candidat pour un remplacement proactif. MCx suit les disques par leur numéro de série. Le suivi de fonctionnement est maintenu même si le disque est déplacé vers un nouveau slot.


Vérification en arrière-plan

La vérification en arrière-plan est un processus interne à la baie qui inspecte et valide les données et la parité des LUN liées. Son but est de détecter et corriger les erreurs de RAID.

La vérification en arrière-plan peut démarrer pour différentes raisons :

l’utilisateur initie manuellement une opération de vérification en arrière-plan pour détecter et corriger les erreurs :

o utilisez la commande setsniffer pour démarrer et la commande getsniffer pour suivre la progression ;

le système démarre une opération de vérification en arrière-plan automatiquement dans le cas d’erreur d’écriture incomplète ;

le système démarre une opération de vérification en arrière-plan automatiquement lorsqu’une remise à zéro d’une LUN en arrière-plan est terminée.

Avec MCx, la vérification en arrière-plan a la possibilité de s’arrêter en cas de charge importante sur le groupe RAID.

Remarque : la vérification en arrière-plan fonctionne uniquement pour les LUN classiques et les LUN de pool privées.

Remarques Getsniffer/Setsniffer

Les arguments –bvtime(temps de vérification en arrière-plan), -snrate(taux sniffer) et l’option [0|1]ne sont plus pris en charge par RAID multicœur.

[0|1]n’est pas pris en charge avec cette commande car elle servait à activer une vérification Sniff, qui n’est plus pris en charge par la commande setsniffverify.

Les champs dans le rapport de vérification en arrière-plan ont été modifiés. Les lignes Sniffing state(état Sniffer), Sniffing rate(taux Sniffer) et Background verify priority(priorité de vérification en arrière-plan) ont été retirées. Ces propriétés ne sont plus applicables avec cette commande lorsqu’elle est exécutée sur RAID multicœur.

L’argument -nonvol n’est pas pris en charge sur la commande getsniffer car le rapport de vérification de restauration non volatile n’est plus applicable.

Lors de l’utilisation de la commande setsniffer, l’argument -bv doit être spécifié pour initier une vérification en arrière-plan. La commande accepte également l’argument facultatif -cr pour effacer les rapports.

Sniffer

La vérification Sniff ou Sniffer est un processus interne qui détecte et corrige les erreurs de médias de disque potentielles avant qu’elles ne deviennent irrécupérables. Dans RAID multicœur, la vérification Sniff fonctionne sur la totalité de la capacité du disque y compris les zones liées et non liées.

Avec FLARE, elle ne sonde que les zones liées du disque et délaisse les zones inutilisées. Des erreurs médias ne sont donc pas détectées. Dans FLARE,


l’opération de vérification Sniff peut être planifiée par LUN et seules les zones liées du disque sont analysées.

RAID multicœur ne permet pas de planification de cette vérification. RAID multicœur a ajouté la possibilité d’activer/désactiver la vérification Sniff au niveau du système. L’activation de la vérification Sniff sur un seul disque n’est pas prise en charge. La vérification Sniff est activée/désactivée pour l’ensemble des disques de la baie. Elle est activée par défaut.


setsniffverify

sniffverify is ENABLED

CLI 7. Activation de la vérification Sniff sur la baie

Remplacement proactif

Le nouveau système VNX surveille le fonctionnement des disques en comptant le nombre d’erreurs trouvées. Les erreurs sont découvertes à l’aide des processus de vérification Sniff ou de vérification en arrière-plan ou lors de lectures normales de l’hôte.

Lorsque le nombre d’erreurs atteint 60, le disque est déclaré comme étant non fonctionnel et est invalidé. Le moteur RAID multicœur entame un processus de remplacement sans période d’attente de 5 minutes. Les disques n’accumulent pas le compte d’erreurs indéfiniment. Une erreur est retirée du compte toutes les 18 000 bonnes opérations d’E/S sur le disque.

Fonctionnalités non disponibles dans la gamme VNX nouvelle génération

La défragmentation du groupe RAID

L’expansion du groupe RAID


Annexe B : Unisphere Analyzer Lors de la comparaison entre FLARE et MCx, une statistique du cache multicœur de Pages de cache non synchronisées a été utilisée. Dans le cache multicœur, cette statistique est comptée en Mo.

Ci-dessous se trouvent de vrais graphiques générés avec des données issues d’Unisphere Analyzer :

Figure 50. Données NAR réelles du nouveau système VNX

Figure 51. Données NAR réelles de VNX OE 32


Notes de configuration du test

Le test a été mené sur les baies suivantes :

baie VNX7600, exécutant VNX OE 33 (version beta 687)

baie VNX5500, exécutant VNX OE 32 (correctif 201)

o Les seuils de cache étaient définis à 80 %/60 % (par défaut dans le système)

o Le cache d’écriture était défini sur 3 915 Mo

o Le cache de lecture était défini sur 435 Mo

Un seul groupe RAID RAID5 4+1 a été créé sur cinq disques SAS 300 Go 10 000 t/min. Puis, une seule LUN classique de 100 Go a été définie et présentée à l’hôte Windows. Un seul switch SAN a été utilisé et seuls deux chemins ont été zonés, un chemin par SP VNX. La taille de la LUN a été spécifiquement choisie pour être suffisamment grande pour que la charge de travail sur chaque système surcharge le cache. PowerPath 5.7 a été installé sur l’hôte Windows.

Le programme de génération de charge de travail d’E/S (indicateur d’E/S) a été utilisé pour générer la charge. L’indicateur d’E/S a été configuré avec un seul opérateur et 16 E/S en attente par cible. La spécification d’accès a été configurée pour être une écriture non alignée de 8 Ko aléatoire à 100 %.

Le test FLARE était plus court que celui pour MCx afin de permettre aux pages non synchronisées du cache multicœur de stagner.


Annexe C : Gestion du cache multicœur

Gestion

Pour activer MCx FAST Cache dans Unisphere, accédez à l’onglet System, puis cliquez sur le lien System Management >Manage cache situé à la droite de l’écran. Cliquez sur l’onglet FAST Cache dans la fenêtre Storage System Properties.

Si FAST Cache n’est pas créé, le bouton Create est activé. Après avoir cliqué dessus, la fenêtre Create FAST Cache s’ouvre, affichant un formulaire pour sélectionner les disques Flash pour FAST Cache, comme il est illustré dans Figure 52. Création de MCx FAST Cache ci-dessous.

Figure 52. Création de MCx FAST Cache

Dans la CLI, vous pouvez effectuer le même processus en utilisant la commande suivante :


–fast -create 0_0_23 0_0_24

Configuring FAST Cache may take up to several hours to complete. It

will also reduce the amount of Storage System memory available for

use by SP Cache. Do you want to continue? (y/n) y

CLI 8. Création de FAST Cache

Destruction de FAST Cache

MCx FAST Cache peut être détruit en ligne. Lorsque vous demandez sa destruction, FAST Cache passe immédiatement à l’état Disabling (désactivation en cours), comme il est illustré dans CLI 10. Affichage des informations FAST Cache. Cela arrête toutes les copies de nouvelles données et entame le processus de vidage, qui efface toutes les pages du stockage Flash FAST Cache. Durant le processus de vidage, FAST Cache multicœur continue de traiter les E/S des hôtes pour les pages qui restent dans le cache.

Le processus de vidage n’est pas immédiat. Il peut durer plusieurs minutes. Plus FAST Cache est important, plus le temps nécessaire pour vider toutes les données qui s’y trouvent est long. Une fois toutes les pages effacées du stockage Flash, les paires mises en miroir sont détruites et les disques Flash FAST Cache passent à l’état unbound (non lié).



–fast -destroy

To destroy FAST Cache, the Storage System may flush all data to disk.

This operation may be time consuming and may impact system

performance. You can monitor the progress of this operation by using

the following command: cache -fast -info. Do you want to continue?

(y/n) y

CLI 9. Destruction de FAST Cache


–fast –info

Disks:





Mode: Read/Write

Raid Type: r_1

Size (GB): 183

State: Disabling

Current Operation: Destroying

Current Operation Status: Running

Current Operation Percent Completed: 0

Percentage Dirty SPA: 0

MBs Flushed SPA: 1585

Percentage Dirty SPB: 70

MBs Flushed SPB: 93345

CLI 10. Affichage des informations FAST Cache

Code d’activation FAST Cache

FAST Cache multicœur est un membre facultatif du stack MCx. Un code d’activation FAST Cache spécial doit être installé sur le système pour permettre le fonctionnement de FAST Cache. L’installation du code d’activation FAST Cache ne requiert pas le redémarrage du processeur de stockage. L’octroi de licence n’est pas abordé dans ce document. Veuillez contacter un responsable de compte EMC pour les questions à ce sujet.

Plusieurs disques Flash SAS doivent être groupés dans des paires mises en miroir pour activer FAST Cache. Le nombre maximal de paires mises en miroir varie en fonction du modèle de la baie VNX et des disques Flash disponibles. Pour plus d’informations, consultez la section Options de configuration de FAST Cache multicœur.

La présence d’un code d’activation FAST Cache modifie les valeurs par défaut pour la création de nouvelles LUN. Si le code d’activation est installé, l’option FAST Cache est activée par défaut pour les nouveaux pools et LUN classiques11. Pour vérifier si le code d’activation est activé, dans Unisphere accédez à l’onglet System, puis cliquez sur le lien System Management >System Properties à la droite de l’écran, comme il est illustré dans Figure 53. Un code d’activation FAST Cache activé.

11 Les LUN de pool n’ont pas d’option FAST Cache, car elle est définie au niveau du Pool.


Figure 53. Un code d’activation FAST Cache activé

Toutes les LUN créées avant l’installation du code d’activation ont l’option FAST Cache désactivée, même si Unisphere n’affiche pas l’option en l’absence du code d’activation. Pour activer l’utilisation de FAST Cache pour les LUN et/ou pools créés avant l’installation du code d’activation FAST Cache, vérifiez l’option manuellement.

Traitement des pannes

Le stockage Flash FAST Cache multicœur est basé sur un groupe RAID commun et est soumis à tous les processus de restauration de RAID multicœur, comme la consignation des reconstructions et des écritures.

Panne d’un disque

Si l’un des disques Flash de FAST Cache multicœur tombe en panne, le groupe RAID1 correspondant passe à l’état dégradé. Les pages appartenant à ce groupe RAID1 sont vidées : les pages propres sont supprimées, les pages non synchronisées sont reproduites sur les LUN d’utilisateur. Les nouvelles pages utilisées issues d’une LUN d’utilisateur seront promues vers les autres périphériques RAID Flash FAST Cache multicœur restants12.

RAID multicœur essaie de remplacer le disque en panne. Une fois la réparation terminée, la paire RAID est remise en service, c’est-à-dire que de nouvelles promotions sont stockées sur ce périphérique par exemple.

Si toutes les paires RAID de FAST Cache sont dégradées, le système entame un processus de nettoyage et désactive FAST Cache.

Tableau des pannes d’alimentation

Toutes les pannes d’alimentation figurant dans le Tableau 1 suivant sont plus longues qu’une alimentation sans panne de 15 secondes.

12 Cela ne s’applique pas si seule une paire de disques Flash est attribuée à FAST Cache ou si toutes les paires sont dégradées.


Tableau 1. Gestion des pannes du cache multicœur

Exemple d’utilisation

Description État du cache multicœur

Panne d’alimentation CA simple, SP homologue continue de fonctionner

L’alimentation CA est retirée d’une alimentation auxiliaire dans un système à plusieurs alimentations auxiliaires (1 ou 2 par SP)

Activé

Panne d’alimentation auxiliaire simple, SP homologue ne fonctionne pas

L’alimentation CA est retirée d’une alimentation auxiliaire dans un système à plusieurs alimentations auxiliaires (1 ou 2 par SP) et le SP homologue n’est pas présent.


Panne d’alimentation pour toutes les alimentations auxiliaires

L’alimentation CA a été retirée de toutes les alimentations auxiliaires.


Un SP unique en surchauffe

Ce SP ou la source d’alimentation de ce SP signale une condition de surchauffe

Activé

Deux SP en surchauffe Une condition de surchauffe est signalée par tous les SP et sources d’alimentation.


Boîtier DAE 0 (0_0) en surchauffe

Une condition de surchauffe a été signalée par au moins une source d’alimentation dans le premier boîtier


Panne d’alimentation simple sur un boîtier DPE/SPE

Une seule source d’alimentation est signalée comme en panne dans le boîtier SPE.

Activé

Panne d’alimentation unique dans un boîtier DAE à 60 disques

Une seule source d’alimentation dans le premier boîtier DAE a été signalée en panne et le premier boîtier est un boîtier à 60 disques


Panne d’alimentation multiple

Plusieurs sources d’alimentation sont signalées comme étant en panne.

Activé

Panne de ventilation unique

Un seul ventilateur est en panne.

Activé


Exemple d’utilisation

Description État du cache multicœur

Panne de ventilation multiple

Plusieurs ventilateurs sont signalés comme étant en panne.

Activé

Chambre forte dégradée Un seul disque de système est déconnecté ou a été retiré.

Activé

Chambre forte en panne Plusieurs disques de système sont déconnectés ou ont été retirés.

Désactivé

Mise à niveau sans perturbation sans mise à niveau de microprogramme de l’alimentation

Le logiciel de la baie est en train d’être modifié

Activé

Mise à niveau sans perturbation avec mise à niveau de microprogramme de l’alimentation

Le logiciel de la baie et le microprogramme de l’alimentation sont en train d’être changés

Désactivé

Panne de SP simple Un SP dans un système à SP double a été retiré, redémarre, fonctionne de manière inattendue ou connaît une panne matérielle

Activé

Panne simple de communication d’alimentation auxiliaire

Un SP ne peut communiquer avec une alimentation auxiliaire. Les autres alimentations auxiliaires fonctionnent normalement.

Activé

Panne multiple de communication d’alimentation auxiliaire

Aucun SP ne peut communiquer avec les alimentations auxiliaires qui y sont connectées.

Désactivé

Panne simple de câblage d’alimentation auxiliaire

Une alimentation auxiliaire n’est pas branchée correctement

Activé

Panne multiple de câblage d’alimentation auxiliaire

Plusieurs alimentations auxiliaires ne sont pas correctement branchées sur les deux SP

Désactivé


Références [1] Loi d’Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities”, 1967, http://www-inst.eecs.berkeley.edu/~n252/paper/Amdahl.pdf

[2] SCSI Block Commands - 3 (SBC-3), T10 working draft specification, http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r32.pdf

[3] EMC E-Lab Interoperability Navigator, un site Web EMC, https://elabnavigator.emc.com/do/navigator.jsp

[4] Applied Best Practices Guide: EMC VNX Unified Best Practices for Performance, site Web de support d’EMC, https://support.emc.com/docu42660_Applied_Best_Practices_Guide:_EMC_VNX_Unified_Best_Practices_for_Performance.pdf?language=en_US

[5] Haswell chip, Intel Corporation, http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/core-qm87-hm86-chipsets-is-guide.html?wapkw=haswell

[6] Cyclic Redundancy Check, “Applications of Matrix Algebra to Network Theory,” Circuit Theory, IRE Transactions on, vol.6, no.5, pp.127, 137, May 1959. http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1086603&isnumber=23613

[7] VNX Data Integrity white paper, site Web de support d’EMC, https://support.emc.com/docu44054_White_Paper:_EMC_Data_Integrity_on_VNX.pdf?language=en_US

[8] EMC FAST VP white paper, site Web de support d’EMC, https://support.emc.com/docu32691_White_Paper:_EMC_FAST_VP.pdf?language=en_US

http://www-inst.eecs.berkeley.edu/~n252/paper/Amdahl.pdf

http://www-inst.eecs.berkeley.edu/~n252/paper/Amdahl.pdf

http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r32.pdf

https://elabnavigator.emc.com/do/navigator.jsp

https://support.emc.com/docu42660_Applied_Best_Practices_Guide:_EMC_VNX_Unified_Best_Practices_for_Performance.pdf?language=en_US

https://support.emc.com/docu42660_Applied_Best_Practices_Guide:_EMC_VNX_Unified_Best_Practices_for_Performance.pdf?language=en_US

http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/core-qm87-hm86-chipsets-is-guide.html?wapkw=haswell

http://www.intel.com/content/www/us/en/secure/intelligent-systems/privileged/core-qm87-hm86-chipsets-is-guide.html?wapkw=haswell

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1086603&isnumber=23613

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1086603&isnumber=23613

https://support.emc.com/docu44054_White_Paper:_EMC_Data_Integrity_on_VNX.pdf?language=en_US

https://support.emc.com/docu44054_White_Paper:_EMC_Data_Integrity_on_VNX.pdf?language=en_US

https://support.emc.com/docu32691_White_Paper:_EMC_FAST_VP.pdf?language=en_US

https://support.emc.com/docu32691_White_Paper:_EMC_FAST_VP.pdf?language=en_US

Documents

VNX MCx Multicore Everything - france.emc.com · Livre blanc Résumé Ce livre blanc explique la technologie EMC VNX MCx, ainsi que ses principaux composants : RAID multicœur, cache