VNX MCx Multicore Everything

Transcription

Livre blanc
VNX MCx™
Multicore Everything™
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
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
Livre blanc VNX MCx™
2
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
3
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
4
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
5
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
6
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
7
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 :
8
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
9
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.
10
À 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 :
11





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.
12
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
13
é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 sousjacents, 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
14
(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 sousjacents.
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 :
15

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.
16
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 :
17
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’à
18
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).
19
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 :
1

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 ?
Ici, petit signifie plus petit que la taille d’une page entière, soit 64 Ko.
20
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.
21
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.
22
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.
23
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.
4
La 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.
24
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
25
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
26
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.
27
é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é.
28
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
29
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
30
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.
31
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.
32
É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.
33
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
34
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.
35
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
De 2 à 42
VNX7600
De 2 à 42
VNX5800
De 2 à 30
VNX5600
De 2 à 20
VNX5400
Disques 100 Go : 500 Go
De 2 à 10
VNX5200
De 2 à 6
** Utilisez un nombre équivalent de disques
* N’utilisez pas des disques de tailles différentes
36
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
37
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.
38
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 backend. 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
39
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.
40
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
Prct Rebuilt:
Disk 11
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.
41
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
42
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
43
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 :
44
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 :
45
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
46
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.
47
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
48
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.
49
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].
50
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.
51
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.
52
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.
53
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é
54
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
55
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).
56
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
57
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.
58
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.
59
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 %.
60
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.
61
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èreplan 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,
62
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
63
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
64
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.
65
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é).
66
–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:
Bus 0 Enclosure 0 Disk 21
Mode: Read/Write
Raid Type: r_1
Size (GB): 183
State: Disabling
Current Operation: Destroying
Current Operation Status: Running
Current Operation Percent Completed:
Percentage Dirty SPA: 0
MBs Flushed SPA: 1585
Percentage Dirty SPB: 70
MBs Flushed SPB: 93345
0
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.
67
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.
68
Tableau 1. Gestion des pannes du cache multicœur
Exemple
d’utilisation
Description
Panne d’alimentation CA
simple, SP homologue
continue de fonctionner
L’alimentation CA est retirée Activé
d’une alimentation
auxiliaire dans un système à
plusieurs alimentations
auxiliaires (1 ou 2 par SP)
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.
L’alimentation CA a été
retirée de toutes les
alimentations auxiliaires.
Ce SP ou la source
d’alimentation de ce SP
signale une condition de
surchauffe
Une condition de surchauffe
est signalée par tous les SP
et sources d’alimentation.
Une condition de surchauffe
a été signalée par au moins
une source d’alimentation
dans le premier boîtier
Une seule source
d’alimentation est signalée
comme en panne dans le
boîtier SPE.
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
Plusieurs sources
d’alimentation sont
signalées comme étant
en panne.
Un seul ventilateur est
en panne.
pour toutes les
alimentations auxiliaires
Un SP unique en
surchauffe
Deux SP en surchauffe
Boîtier DAE 0 (0_0) en
surchauffe
simple sur un boîtier
DPE/SPE
unique dans un boîtier
DAE à 60 disques
multiple
Panne de ventilation
unique
État du cache
multicœur
Vidage vers la
chambre forte
Vidage vers la
chambre forte
Activé
Vidage vers la
chambre forte
Vidage vers la
chambre forte
Activé
Vidage vers la
chambre forte
Activé
Activé
69
Exemple
d’utilisation
Description
État du cache
multicœur
Panne de ventilation
multiple
Plusieurs ventilateurs sont
signalés comme étant en
panne.
Un seul disque de système
est déconnecté ou a été
retiré.
Plusieurs disques de
système sont déconnectés
ou ont été retirés.
Le logiciel de la baie est en
train d’être modifié
Activé
Le logiciel de la baie et le
microprogramme de
l’alimentation sont en train
d’être changés
Désactivé
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
Un SP ne peut communiquer
avec une alimentation
auxiliaire. Les autres
alimentations auxiliaires
fonctionnent normalement.
Aucun SP ne peut
communiquer avec les
alimentations auxiliaires qui
y sont connectées.
Une alimentation auxiliaire
n’est pas branchée
correctement
Plusieurs alimentations
auxiliaires ne sont pas
correctement branchées sur
les deux SP
Activé
Chambre forte dégradée
Chambre forte en panne
Mise à niveau sans
perturbation sans mise
à niveau de
microprogramme de
l’alimentation
Mise à niveau sans
perturbation avec mise
à niveau de
microprogramme de
l’alimentation
Panne de SP simple
Panne simple de
communication
d’alimentation auxiliaire
Panne multiple de
communication
Panne simple de câblage
Panne multiple de
câblage d’alimentation
auxiliaire
Activé
Désactivé
Activé
Activé
Désactivé
Activé
Désactivé
70
Références
[1] Loi d’Amdahl, “Validity of the single processor approach to achieving large scale
computing capabilities”, 1967, http://wwwinst.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/intelligentsystems/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_VN
X.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
71

VNX MCx Multicore Everything

Transcription

Similar documents

TD9 : CohÃ©rence mÃ©moire par espionnage - Ensiwiki

hard drive dockduplicator duplicator

hard drive dock pro

Prévention des maux de dos dans le secteur de la petite enfance

068/84.15.32 Love Kitchen : 0486/83.95.07

toughbook cf-52 modele haute definition

FrançaisTélécharger

Hernie postérieure d`un disque calcifié chez I`enfant