Dell metro node storage enterprise Manuel utilisateur

Systèmes de stockage Dell EMC
Guide d’administration de la fonctionnalité de
Metro Node PowerStore et UnityXT
Version 7.0
January 2021
Remarques, précautions et avertissements
REMARQUE : Une REMARQUE indique des informations importantes qui peuvent vous aider à mieux utiliser votre produit.
PRÉCAUTION : ATTENTION vous avertit d’un risque de dommage matériel ou de perte de données et vous indique
comment éviter le problème.
AVERTISSEMENT : un AVERTISSEMENT signale un risque d’endommagement du matériel, de blessure corporelle, voire
de décès.
© 2020 2021 Dell Inc. ou ses filiales. Tous droits réservés. Dell, EMC et les autres marques citées sont des marques commerciales de Dell Inc. ou de ses
filiales. D’autres marques commerciales éventuellement citées sont la propriété de leurs détenteurs respectifs.
Table des matières
Chapitre 1: Espace de travail et comptes d’utilisateur de l’interface CLI...............................................7
Configuration de l’espace de travail de l’interface CLI......................................................................................................7
Définir le seuil pour la journalisation de console............................................................................................................7
Définition de la largeur de la fenêtre sur 100................................................................................................................ 8
Recherche dans l’arborescence de contextes............................................................................................................. 8
Chapitre 2: Métavolumes.................................................................................................................9
À propos des métavolumes.................................................................................................................................................. 9
Exigences en matière de performances et de disponibilité des métavolumes......................................................... 9
Déplacement d’un métavolume..........................................................................................................................................10
Attribution d’un nouveau nom à un métavolume............................................................................................................. 10
Suppression d’un métavolume............................................................................................................................................ 11
Affichage d’un metavolume................................................................................................................................................ 12
Vérification de la cohérence d’un métavolume................................................................................................................ 14
Chapitre 3: Gestion du système...................................................................................................... 15
Notifications Call Home.......................................................................................................................................................15
À propos des notifications Call Home.......................................................................................................................... 15
Documentation supplémentaire....................................................................................................................................16
Emplacement du journal des événements........................................................................................................................ 16
Accélération matérielle avec VAAI......................................................................................................................................17
CompareAndWrite..........................................................................................................................................................17
Opérations CompareAndWrite (16)............................................................................................................................. 19
Activation/désactivation des paramètres WriteSame (16).......................................................................................19
Surcharge de la copie de déchargement avec XCOPY...................................................................................................21
Activation et désactivation des commandes XCOPY avec l’interface CLI............................................................. 21
Affichage des statistiques XCOPY.............................................................................................................................. 22
Changement de nom d’un cluster Metro Node...............................................................................................................22
Paramètres du panneau avant LCD.................................................................................................................................. 23
Chapitre 4: Support dynamique de Metro Node............................................................................... 24
Support dynamique de Metro Node..................................................................................................................................24
Provisionnement dynamique.............................................................................................................................................. 25
Création de volumes virtuels à provisionnement dynamique................................................................................... 25
Modification du caractère dynamique d’un volume virtuel.......................................................................................27
Gestion du stockage dynamique........................................................................................................................................28
Mise en miroir et migration dynamiques........................................................................................................................... 29
Exécution de la mise en miroir léger............................................................................................................................ 29
À propos des migrations dynamiques..........................................................................................................................30
Chapitre 5: Provisionnement du stockage........................................................................................31
Présentation du provisionnement...................................................................................................................................... 31
Provisionnement de stockage avec le provisionnement EZ........................................................................................... 31
Modification du caractère dynamique d’un volume virtuel............................................................................................. 31
Table des matières
3
Chapitre 6: Extension de volume.................................................................................................... 33
Présentation......................................................................................................................................................................... 33
Documentation supplémentaire................................................................................................................................... 33
Méthode d’extension de volume....................................................................................................................................... 33
Affichage de l’attribut de méthode d’extension avec l’interface CLI......................................................................33
Affichage de l’attribut de méthode d’extension avec Unisphere............................................................................ 34
Extension d’un volume en mode bloc............................................................................................................................... 35
Méthode d’extension de volume de stockage........................................................................................................... 35
Limitations...................................................................................................................................................................... 38
Chapitre 7: Migration des données................................................................................................. 39
À propos de la migration des données.............................................................................................................................. 39
Migrations ponctuelles.................................................................................................................................................. 39
Limitations...................................................................................................................................................................... 39
Migrations par lot...........................................................................................................................................................39
Procédure générale de migration des données..........................................................................................................40
Migration de stockage compatible avec le provisionnement dynamique..................................................................... 40
À propos des reconstructions............................................................................................................................................ 44
Reconstructions pour le stockage à provisionnement dynamique.......................................................................... 44
Considérations relatives aux performances............................................................................................................... 45
Migration ponctuelle des données.....................................................................................................................................45
Démarrage d’une migration de périphériques ponctuelle......................................................................................... 45
Surveillance de la progression de la migration........................................................................................................... 46
Pause/reprise d’une migration (en option)................................................................................................................ 47
Annulation d’une migration (en option).......................................................................................................................47
Validation d’une migration terminée............................................................................................................................ 48
Nettoyage d’une migration...........................................................................................................................................48
Suppression des enregistrements de migration.........................................................................................................48
Migrations par lot.................................................................................................................................................................49
Conditions préalables.................................................................................................................................................... 49
Création d’un plan de migration par lot.......................................................................................................................49
Vérification d’un plan de migration par lot..................................................................................................................50
Modification d’un fichier de migration par lot............................................................................................................ 50
Démarrage d’une migration par lot..............................................................................................................................50
Pause/reprise d’une migration par lot (en option).....................................................................................................51
Annulation d’une migration par lot (en option)...........................................................................................................51
Surveillance de la progression de la migration par lot................................................................................................ 51
Affichage de l’état d’une migration par lot................................................................................................................. 52
Validation d’une migration par lot................................................................................................................................ 53
Nettoyage d’une migration par lot...............................................................................................................................53
Suppression des enregistrements de migration par lot............................................................................................ 54
Chapitre 8: Configuration du réseau WAN....................................................................................... 55
Matériel et ports WAN Metro Node................................................................................................................................. 55
Règles de configuration des ports WAN Metro over IP.................................................................................................55
Groupes de ports...........................................................................................................................................................55
Contextes de l’interface CLI.............................................................................................................................................. 55
Contexte port-groups................................................................................................................................................... 56
4
Table des matières
contexte de sous-réseaux............................................................................................................................................ 57
/connectivity/back-end/............................................................................................................................................. 58
/connectivity/front-end/.............................................................................................................................................58
/connectivity/local-com/.............................................................................................................................................59
Gestion et surveillance du réseau back-end.................................................................................................................... 59
Mise hors service d’un nexus IT back-end avec une latence élevé........................................................................ 59
Marquage d’un nexus IT back-end comme isolé du fait de performances instables............................................ 59
LDAP..................................................................................................................................................................................... 59
Structure des répertoires............................................................................................................................................. 60
Exemples (commande ldapsearch)............................................................................................................................. 60
Chapitre 9: Consistency Groups..................................................................................................... 62
À propos des groupes de cohérence Metro Node.......................................................................................................... 62
Groupes de cohérence synchrones.............................................................................................................................62
Propriétés des groupes de cohérence..............................................................................................................................65
Visibilité........................................................................................................................................................................... 65
Storage-at-clusters....................................................................................................................................................... 66
detach-rule..................................................................................................................................................................... 67
auto-resume-at-loser.................................................................................................................................................... 68
virtual-volumes...............................................................................................................................................................68
Gérer les groupes de cohérence....................................................................................................................................... 69
Création d’un groupe de cohérence............................................................................................................................69
Ajout de volumes à un groupe de cohérence............................................................................................................. 70
Suppression de volumes d’un groupe de cohérence..................................................................................................71
Modification des propriétés d’un groupe de cohérence........................................................................................... 72
exemple de modification : définition de visibility........................................................................................................ 73
exemple de modification : application d’une règle de déconnexion.........................................................................73
Suppression d’un groupe de cohérence......................................................................................................................74
Affichage des propriétés d’un groupe de cohérence................................................................................................ 75
Utilisation d’un groupe de cohérence................................................................................................................................79
Reprise des E/S après restauration............................................................................................................................. 81
Reprise des E/S sur le cluster perdant....................................................................................................................... 82
Définition de l’attribut en lecture seule....................................................................................................................... 83
Chapitre 10: Performances et surveillance.......................................................................................84
À propos des performances............................................................................................................................................... 84
RPO et RTO................................................................................................................................................................... 84
À propos de la surveillance des performances.................................................................................................................84
Surveillance des performances avec Unisphere for Metro Node........................................................................... 85
Surveillance des performances avec l’interface CLI Metro Node........................................................................... 87
Surveillance des performances avec l’interface CLI....................................................................................................... 87
À propos de la rotation et de l’horodatage des fichiers............................................................................................ 87
Présentation de la procédure : créer un analyseur à l’aide de l’interface CLI........................................................ 88
Création d’un analyseur................................................................................................................................................ 88
Ajout/suppression de récepteurs d’analyseur............................................................................................................89
Suppression d’un analyseur.......................................................................................................................................... 90
Activation/désactivation/modification d’une interrogation..................................................................................... 93
Activation/désactivation des récepteurs................................................................................................................... 93
Exécution forcée d’une interrogation immédiate.......................................................................................................94
Table des matières
5
Surveillance des ports......................................................................................................................................................... 94
Mise en route................................................................................................................................................................. 94
Configuration du script pour l’envoi des rapports par e-mail...................................................................................94
Vérification de l’état du script......................................................................................................................................95
Ajout de seuils (si nécessaire)...................................................................................................................................... 95
Informations sur l’utilisation de port-stats-monitor...................................................................................................96
Exemple de sortie.......................................................................................................................................................... 97
Éléments à prendre en compte....................................................................................................................................98
Statistiques...........................................................................................................................................................................98
Affichage des statistiques disponibles........................................................................................................................ 99
Statistiques sur les performances frontales............................................................................................................. 100
Tableaux de statistiques....................................................................................................................................................100
Annexe A : Metro Node avec baies de stockage en mode actif-passif................................................. 111
Baie en mode actif-passif................................................................................................................................................... 111
Baie activée en mode ALUA...............................................................................................................................................111
Exécution d’un basculement de l’unité logique................................................................................................................ 111
Restauration automatique d’une unité logique................................................................................................................112
Index...........................................................................................................................................113
6
Table des matières
1
Espace de travail et comptes d’utilisateur de
l’interface CLI
Ce chapitre décrit comment utiliser l’interface de ligne de commande (CLI) Metro Node pour configurer l’espace de travail de
l’interface CLI et gérer les comptes d’utilisateur.
Sujets :
•
Configuration de l’espace de travail de l’interface CLI
Configuration de l’espace de travail de l’interface CLI
L’espace de travail a la même apparence et le même comportement que ceux d’une session de l’interface CLI. Utilisez les procédures
décrites dans cette section pour contrôler la sortie des commandes et le niveau des messages de journalisation envoyés à la console, et
pour effectuer une recherche dans l’historique des commandes de la session de l’interface CLI en cours.
REMARQUE : Le démarrage de l’interface CLI Metro Node ne nécessite plus de nom d’utilisateur ni de mot de passe. Veuillez vérifier
qu’aucun script automatisé ne fournit de noms d’utilisateur ou de mots de passe.
Définir le seuil pour la journalisation de console.
L’enregistreur de console affiche les messages reçus des directeurs sur la console.
Par défaut, la console affiche uniquement les messages d’urgence (niveau 0).
Les messages sont classés en 8 niveaux de gravité (0-7), 0 étant le plus grave :
7 - débogage (messages de niveau de débogage)
6 - info (messages d’information)
5 - avis (messages normaux, mais significatifs)
4 - avertissement (messages d’avertissement)
3 - err (messages d’erreur)
2 - crit (messages critiques)
1 - alerte (messages devant être gérés immédiatement)
0 - urg (messages signalant que le système est inutilisable)
Pour activer l’affichage des messages dont le niveau de gravité est inférieur sur la console, modifiez le seuil du filtre de journalisation de la
console.
1. Utilisez la commande de liste de filtres de journal pour afficher les filtres de journal existants.
VPlexcli:/> log filter list
1. Component='logserver' Destination='null' Consume='true'
2. [Threshold='>0'] Destination='null' Consume='true'
2. Déterminez l’identifiant du filtre contrôlant l’affichage des messages sur la console. Le filtre de console possède les attributs suivants :
Seuil = « >=0 »
Destination = « null »
Utilisation = « true »
3. Utilisez la commande de suppression de filtre de journal pour supprimer le filtre de journalisation de la console existant.
VPlexcli:> log filter destroy 1
Espace de travail et comptes d’utilisateur de l’interface CLI
7
4. Utilisez la commande de création de filtre de journal pour créer un nouveau filtre pour la console avec le seuil requis :
VPlexcli:> log filter create --threshold <n> --component “logserver”
où n correspond à 0-7.
REMARQUE : La valeur de seuil filtre tous les messages dont la gravité est supérieure ou égale.
Pour voir les messages critiques (2) et d’une valeur supérieure (0 et 1), définissez le seuil sur 3.
Pour afficher les erreurs (3) et les messages avec une gravité supérieure (0, 1 et 2), définissez le seuil sur 4.
Définition de la largeur de la fenêtre sur 100
La largeur de la sortie de nombreuses commandes est supérieure à 80 colonnes. Développez la fenêtre de commande dans laquelle
l’interface CLI Metro Node s’exécute jusqu’à une largeur d’au moins 100 colonnes.
Recherche dans l’arborescence de contextes
Recherchez des noms de contexte et des données associées à des modèles spécifiques dans l’arborescence de contextes.
Utilisation de la commande Find pour effectuer une recherche dans l’arborescence de
contextes
Utilisez cette commande pour trouver tous les contextes associés à un modèle. En cas d’invocation interactive, la commande imprime les
contextes à l’écran.
Les modèles peuvent être des chaînes de caractères littéraux ou des chaînes qui contiennent des caractères génériques. Pour obtenir une
liste exhaustive des caractères génériques de l’interface CLI supportés, reportez-vous à la rubrique « Caractères génériques » dans le
document CLI Reference Guide (Guide de référence de l’interface CLI).
8
Espace de travail et comptes d’utilisateur de l’interface CLI
2
Métavolumes
Ce chapitre décrit les procédures de gestion des métadonnées et des métavolumes avec l’interface CLI Metro Node.
Sujets :
•
•
•
•
•
•
À propos des métavolumes
Déplacement d’un métavolume
Attribution d’un nouveau nom à un métavolume
Suppression d’un métavolume
Affichage d’un metavolume
Vérification de la cohérence d’un métavolume
À propos des métavolumes
Les métadonnées Metro Node incluent les mappages virtuel-vers-physique, les données concernant les périphériques, les volumes virtuels
et les paramètres de configuration système.
Les métadonnées sont stockées dans le cache et sauvegardées sur des volumes externes conçus spécifiquement, appelés métavolumes.
Les métavolumes sont créés lors de la configuration du système.
Lors de la configuration initiale d’un cluster, le métavolume doit être le premier stockage présenté à Metro Node. Cela empêche
l’écrasement accidentel du métavolume.
Une fois le métavolume configuré, les mises à jour des métadonnées sont écrites à la fois dans le cache et dans le métavolume lorsque la
configuration Metro Node est modifiée.
Les volumes de métadonnées des sauvegardes sont des snapshots ponctuels des métadonnées actuelles et assurent une protection
supplémentaire avant les modifications de configuration, les actualisations ou les migrations les plus importantes.
Les métadonnées sont lues à partir du métavolume uniquement au démarrage de chaque directeur.
Les sauvegardes de métavolume sont créées :
● Avant une migration vers une nouvelle baie.
● Avant une mise à jour majeure.
Les métavolumes diffèrent des volumes de stockage standard, comme indiqué ci-dessous :
● Un métavolume est créé sans avoir être revendiqué.
● Les métavolumes sont créés directement sur les volumes de stockage.
Consultez le document Configuration Guide for metro node (Guide de configuration de Metro Node) pour plus d’informations sur les
critères de sélection du stockage utilisé pour les métavolumes.
PRÉCAUTION : Ne configurez pas le métavolume sur les disques Vault d’une baie de stockage. Par exemple, le
métavolume ne doit pas être configuré sur les disques Vault d’une baie VNX ou CLARiiON.
Exigences en matière de performances et de disponibilité des
métavolumes
Les performances ne sont pas essentielles aux métavolumes. Les performances minimales autorisées sont de 40 Mo/s et de 100 E/S par
seconde, multiple de 4 Ko.
Les axes physiques des métavolumes doivent être isolés des charges applicatives.
Dell EMC recommande les éléments suivants pour les métavolumes :
● La fonction de cache de lecture doit être activée.
● Un metavolume de secours doit être préconfiguré en cas de défaillance catastrophique du metavolume actif.
Métavolumes
9
● Si possible, n’utilisez pas de périphériques sur le LUN0. Les chemins des LUN0 sont supprimés et ajoutés dès que la baie effectue une
détection. Ce comportement est dû au fait que le LUN0 peut être un LUN par défaut ou un LUN réel sauvegardé par le stockage réel.
La disponibilité est essentielle aux métavolumes. Le metavolume est essentiel à la récupération du système. La pratique d’excellence
consiste à mettre en miroir le métavolume sur deux ou plusieurs baies back-end afin d’éliminer le risque de perte de données. Choisissez les
baies en miroir du metavolume de sorte à ne pas devoir les migrer simultanément.
AVERTISSEMENT : Ne créez pas de metavolume avec les volumes d’une seule et même baie de stockage. Les
métavolumes d’une seule et même baie ne constituent pas une configuration à haute disponibilité et représentent un
point de défaillance unique.
Si Metro Node perd temporairement l’accès à tous les métavolumes, les métadonnées en cours du cache sont automatiquement écrites
sur les métavolumes lorsque l’accès est rétabli.
Si Metro Node perd durablement l’accès aux deux métavolumes, il continue à fonctionner sur la base des métadonnées en mémoire. Les
modifications de configuration sont suspendues jusqu’à la création d’un nouveau metavolume.
REMARQUE : Si Metro Node perd l’accès à tous les métavolumes, et que tous les directeurs échouent ou redémarrent, les
modifications apportées aux métadonnées (configuration Metro Node) après la perte de l’accès ne peuvent pas être restaurées. Les
volumes système sont supportés sur les LUN à provisionnement dynamique, mais ces volumes doivent disposer de ressources de pool
de stockage dynamique disponibles, à la capacité maximale. Les volumes système ne doivent pas se disputer cet espace avec des
volumes de données utilisateur du même pool.
Déplacement d’un métavolume
Étapes
1. Utilisez la commande ll pour afficher la liste des volumes de stockage sur le cluster :
VPlexcli:/> ll /clusters/cluster-1/storage-elements/storage-volumes
2. Identifiez 2 volumes de stockage qui sont :
● Non revendiqués
● De 78 Go ou plus
● Sur différentes baies
3. Utilisez la commande meta-volume create pour créer un metavolume.
Spécifiez les volumes de stockage identifiés à l’étape 2.
VPlexcli:/engines/engine-1-1/directors> meta-volume create --name meta_dmx --storagevolumes VPD83T3:6006016037202200966da1373865de11,
VPD83T3:6006016037202200966da1373865de12
4. Utilisez la commande meta-volume move pour déplacer les métadonnées en mémoire existantes vers le nouveau métavolume :
VPlexcli:/engines/engine-1-1/directors> meta-volume move --target-volume meta_dmx
Attribution d’un nouveau nom à un métavolume
Par défaut, les noms de métavolumes sont basés sur un horodatage. Pour modifier le nom, procédez comme suit :
10
Métavolumes
Étapes
1. Accédez au contexte /clusters/cluster/system-volumes/ :
VPlexcli:/> cd clusters/cluster-2/system-volumes/
VPlexcli:/clusters/cluster-2/system-volumes>
2. Utilisez la commande ll pour afficher les noms des métavolumes :
3. Accédez au contexte /clusters/cluster/system-volumes/target-meta-volume.
Par exemple :
VPlexcli:/clusters/cluster-2/system-volumes> cd new_meta1_backup_2010May24_163810
4. Utilisez la commande set name nouveau_nom_métavolume pour modifier le nom.
Par exemple :
VPlexcli:/clusters/cluster-2/system-volumes/new_meta1_backup_2010May24_163810> set name
backup_May24_pre_refresh
Suppression d’un métavolume
À propos de cette tâche
REMARQUE : Un métavolume doit être inactif pour être supprimé. Les tentatives de suppression d’un métavolume actif échouent
avec un message d’erreur.
Étapes
1. Accédez au contexte du volume cible.
Par exemple :
VPlexcli:> cd clusters/cluster-1/system-volumes/metadata_1/
2. Utilisez la commande ll pour vérifier que le volume n’est pas actif.
Par exemple :
VPlexcli:/clusters/cluster-1/system-volumes/metadata_1> ll
Attributes:
Name
Value
---------------------- ----------active
false
application-consistent false
block-count
23592704
block-size
4K
.
.
.
3. Utilisez la commande meta-volume destroy --meta-volume métavolume pour supprimer le métavolume spécifié.
Par exemple :
VPlexcli:/clusters/cluster-1/system-volumes/metadata_1> meta-volume destroy --meta-volume
metadata_1
Un message d’avertissement s’affiche :
Meta-volume 'metadata_1' will be destroyed. Do you wish to continue? (Yes/No)
4. Saisissez y.
Métavolumes
11
REMARQUE : Après la suppression d’un volume de métadonnées, supprimez les données sur le volume de stockage par des
moyens externes afin d’éviter toute confusion future.
Affichage d’un metavolume
Utilisez la commande ll pour afficher l’état d’un metavolume :
VPlexcli:/clusters/cluster-1/system-volumes/svtmeta> ll
/clusters/cluster-1/system-volumes/svtmeta:
Attributes:
Name
Value
---------------------- ----------active
true
application-consistent false
block-count
20971264
block-size
4K
capacity
80G
component-count
2
free-slots
63997
geometry
raid-1
health-indications
[]
health-state
ok
locality
local
operational-status
ok
ready
true
rebuild-allowed
true
rebuild-eta
rebuild-progress
rebuild-status
done
rebuild-type
full
slots
64000
stripe-depth
system-id
svtmeta
thin-capable
transfer-size
128K
volume-type
meta-volume
Contexts:
Name
---------components
Description
------------------------------------------------------------------The list of components that support this device or system virtual
volume.
Utilisez la commande ll components/ pour afficher les volumes composants du metavolume :
VPlexcli:/clusters/cluster-2/system-volumes/ICO_META_1_1_Metadata> ll components/
/clusters/cluster-2/system-volumes/clus2_MetaVol/components:
Name
Slot
Type
Operational Health
Capacity
---------------------------------------- Number -------------- Status
State
----------------------------------------------- ------ -------------- ----------- ------------VPD83T3:60000970000192601707533031333136 0
storage-volume ok
ok
VPD83T3:60060480000190300487533030343445 1
storage-volume ok
ok
78G
78G
Tableau 1. Champs de métavolume affichés
Champ
Description
active
Indique si le volume est le volume de métadonnées actuellement actif. Le système ne dispose que
d’un seul volume de métadonnées actif à la fois.
application-consistent
Indique si le volume de stockage est cohérent avec l’application.
block-count
Nombre de blocs du volume.
12
Métavolumes
Tableau 1. Champs de métavolume affichés (suite)
Champ
Description
capacity
Taille du métavolume.
component-count
Nombre de miroirs dans le volume de métadonnées RAID 1.
free-slots
Nombre de logements libres pour les en-têtes de volume de stockage dans le metavolume.
geometry
Indique la géométrie ou la redondance du périphérique. Toujours RAID 1.
health-indications
Si health-state n’est pas ok, fournit des informations supplémentaires.
health-state
● ok – Le volume de stockage fonctionne normalement.
● degraded – Il se peut que le volume de stockage soit obsolète par rapport à sa copie
miroir. (Cet état s’applique uniquement à un volume de stockage faisant partie d’un volume de
métadonnées RAID 1.)
● unknown – Metro Node ne parvient pas à déterminer l’état d’intégrité du volume de
stockage, ou l’état n’est pas valide.
● non-recoverable error – Il se peut que le volume de stockage soit obsolète par rapport
à sa copie miroir (applicable uniquement à un volume de stockage faisant partie d’un volume
de métadonnées RAID 1) et/ou Metro Node ne peut pas déterminer l’état d’intégrité.
● critical failure – Metro Node a marqué le volume de stockage comme étant inactif
sur le plan matériel.
locality
Localité du périphérique de support.
● local – Le volume est local par rapport au cluster dont il fait partie.
● remote – Le volume est mis à disposition pour un autre cluster que le cluster dont il fait
partie et les utilisateurs y accèdent à distance.
● distributed – Le volume virtuel dispose (ou peut disposer) de tronçons au niveau de plus
d’un cluster.
operational status
● ok – Le volume de stockage fonctionne normalement.
● degraded – Il se peut que le volume de stockage soit obsolète par rapport à sa copie
miroir. (Cet état s’applique uniquement à un volume de stockage faisant partie d’un volume de
métadonnées RAID 1.)
● unknown – Metro Node ne parvient pas à déterminer l’état d’intégrité du volume de
stockage, ou l’état n’est pas valide.
● error – Metro Node a marqué le volume de stockage comme étant inactif sur le plan
matériel.
● starting – Le volume de stockage n’est pas encore prêt.
● lost-communication – Le volume de stockage est inaccessible.
ready
Indique si le volume de métadonnées est prêt ou non.
rebuild-allowed
Indique si le périphérique est autorisé à effectuer une reconstruction.
rebuild-eta
Si une reconstruction est en cours, temps restant estimé pour que la reconstruction en cours se
termine.
rebuild-progress
Si une reconstruction est en cours, pourcentage du périphérique qui a été reconstruit.
rebuild-status
Indique l’état d’intégrité du périphérique. done – La reconstruction est terminée.
rebuild-type
Indique le type de reconstruction.
● full – Copie intégrale de tous les blocs. Une reconstruction de metavolume est toujours full.
● incremental – Copie incrémentielle qui utilise un algorithme de différenciation de somme
de contrôle pour transférer uniquement les blocs qui sont différents.
● comparison – Copie de comparaison.
● resync – Resynchronisation qui réécrit les blocs affectés par la défaillance d’un directeur, ce
qui garantit que les tronçons de miroir sont identiques.
slots
Nombre total de logements pour les en-têtes de volume de stockage dans le metavolume.
stripe-depth
Profondeur d’une bande en octets lorsque geometry est RAID-0.
Métavolumes
13
Tableau 1. Champs de métavolume affichés (suite)
Champ
Description
system-id
Nom attribué au metavolume.
thin-capable
Indique si le volume est compatible avec le provisionnement dynamique. Yes indique que le volume
est compatible avec le provisionnement dynamique. - indique qu’il n’est pas compatible avec le
provisionnement dynamique.
transfer-size
Taille du transfert lors de la reconstruction en octets.
volume-type
Pour les métavolumes, il s’agit toujours de meta-volume.
Vérification de la cohérence d’un métavolume
Pour vérifier la cohérence de disque d’un métavolume, utilisez la commande suivante :
VPlexcli:/>
meta-volume verify-on-disk-consistency -c cluster
REMARQUE : Effectuez une vérification de cohérence sur le serveur de gestion local du cluster que vous vérifiez.
14
Métavolumes
3
Gestion du système
Ce chapitre décrit comment utiliser les notifications Call Home, les emplacements des journaux des événements et l’accélération matérielle
avec VAAI.
Sujets :
•
•
•
•
•
•
Notifications Call Home
Emplacement du journal des événements
Accélération matérielle avec VAAI
Surcharge de la copie de déchargement avec XCOPY
Changement de nom d’un cluster Metro Node
Paramètres du panneau avant LCD
Notifications Call Home
À propos des notifications Call Home
Les notifications Call Home sont des messages automatiquement envoyés au service client Dell EMC et/ou à un représentant du support
client en cas de problème grave. Les notifications Call Home permettent à Dell EMC d’engager de manière proactive du personnel qualifié,
ou d’utiliser une passerelle ESRS configurée pour résoudre le problème.
Il existe quatre niveaux d’événements système. Les notifications Call Home sont envoyées uniquement pour trois niveaux :
Tableau 2. Gravité des événements et notifications Call Home
Gravité
Définition
Impact sur les performances ou la
disponibilité
Call-home
Critique : (1)
Une DU ou une DL est hautement probable ou ● Système indisponible.
s’est produite.
● Grave dégradation des performances.
Yes
Erreur : (2)
DU ou DL possible. Nécessite une intervention ● Impact limité sur les performances.
du service.
● Perte de redondance.
● Risque modéré de DU/DL.
Yes
Avertissement :
(3)
Nécessite d’être signalé au service. Aucune
urgence.
Yes
Info : (4)
Événement d’information. Aucune action n’est Aucun.
requise.
● Aucun impact sur les performances.
● Perte de redondance.
● Aucun risque de perte ou d’indisponibilité des
données.
No
Reportez-vous aux procédures de dépannage sur SolVe Desktop pour obtenir la liste de tous les événements.
De nombreuses activités de maintenance (remplacements de matériel, par exemple) génèrent une multitude d’événements Call Home. La
plupart de ces procédures comprennent des étapes pour désactiver temporairement les notifications Call Home pendant l’opération.
Modification des notifications Call Home et des paramètres SYR
Les notifications Call Home et les paramètres SYR sont généralement configurés lors de la configuration du système.
Utilisez la commande de l’interface de ligne de commande configuration event-notices-reports-config pour configurer les
paramètres des notifications Call Home et/ou SYR s’ils n’ont pas été configurés lors de l’installation initiale.
Gestion du système
15
La commande exécute un script d’interrogation qui vous invite à saisir les informations requises. Si vous ne configurez pas les notifications
Call Home ou SYR, les questions d’interrogation pour configurer le service non configuré s’affichent.
Si les paramètres des notifications Call Home et SYR sont déjà configurés, les informations de configuration actuelles s’affichent.
Avant de commencer
Vous avez besoin des informations suivantes pour terminer la configuration de la notification Call Home :
● Adresse IP de la passerelle ESRS utilisée pour transférer les notifications Call Home à Dell EMC. Dell EMC recommande d’utiliser la
passerelle ESRS comme adresse de connexion primaire.
● Une ou plusieurs adresses IP du ou des serveurs de passerelle ESRS secondaires utilisés pour transférer les notifications Call Home
à Dell EMC en cas de défaillance du serveur primaire (en option). Ces adresses doivent être différentes de l’adresse du serveur de
passerelle SESRS primaire.
● Une ou plusieurs adresses e-mail des personnes qui doivent recevoir un message e-mail en cas de notifications Call Home (en option).
Documentation supplémentaire
Reportez-vous au générateur Metro Node pour connaître la procédure de configuration de SupportAssist.
Consultez le document Installation Guide for metro node (Guide d’installation de Metro Node) pour plus d’informations sur les commandes
de configuration SupportAssist :
●
●
●
●
●
vplex_system_config -support_enable – Active SupportAssist.
vplex_system_config -support_disable – Désactive SupportAssist.
vplex_system_config -interview --update-supportassist-gateway – Met à jour les nouvelles informations sur la passerelle.
vplex_system_config -reset_supportassist – Supprime la configuration de SupportAssist.
vplex_system_config --show-supportassist – Affiche la configuration SupportAssist existante.
Emplacement du journal des événements
Metro Node inclut des services, des processus, des composants et des systèmes d’exploitation qui écrivent des entrées dans différents
journaux.
Le système collecte des journaux pour :
● Les événements d’appel à distance
Les emplacements de divers journaux sur le serveur de gestion Metro Node sont répertoriés dans le tableau suivant :
Tableau 3. Emplacement des fichiers journaux Metro Node
Nom du journal
Description et emplacement
Call home log
Sur un serveur de gestion en cours d’exécution :
● /opt/dell/vplex/ese/var/log/ESE.log
● /var/log/VPlex/cli/dreamcatcher.log
NSFW log
Journal GeoSynchrony. NSFW envoie les événements à un service de journaux sur le directeur. Le service de
journaux écrit les entrées NSFW dans le journal sous /var/log/journal/.
● Sur un directeur en cours d’exécution : sudo journalctl -u nsfw
● Dans la sortie collect-diagnostics : le journal est trouvé – voyager-diagnostics/journal/
diagnostic-collection_journal.export. Cela nécessite de convertir systemd-journalremote en journal.
1. systemd-journal-remote --output=<name>.journal /path/to/journal.export
a. Il convertit le fichier. export en fichier lisible par journalctl.
b. Il est obligatoire de disposer d’un suffixe .journal dans le nom du fichier de sortie.
2. journalctl --file=<name>.journal <other-flags>
a. Il possède toutes les mêmes options disponibles avec une autre commande journalctl .
3. journalctl --file=<name>.journal -u nsfw
a. La sortie du journal est limitée à l’unité NSFW. Il s’agit de l’un des exemples des nombreuses balises de
journal qui peuvent être utilisées.
16
Gestion du système
Accélération matérielle avec VAAI
L’API VAAI (VMware for Array Integration) permet d’effectuer les opérations suivantes :
●
●
●
●
Déchargement des opérations de stockage du côté calcul vers le matériel de stockage.
Basculement des opérations de provisionnement gourmandes en E/S et création d’un snapshot de l’hyperviseur vers Metro Node.
Affectation de la mémoire de l’hyperviseur et du traitement des ressources à d’autres fonctions.
Suppression des mappages des blocs de stockage inutilisés des volumes à provisionnement dynamique. Support dynamique de
Metro Node , page 24 Fourniture d’informations complémentaire sur le provisionnement dynamique.
L’API VAAI est mise en œuvre dans Metro Node à l’aide de quatre commandes SCSI :
● « CompareAndWrite » décharge la coordination de la mise sous/hors tension des machines virtuelles (VM) et de leur déplacement
entre hyperviseurs.
● « WriteSame (16) » décharge l’écriture d’un même modèle de données, par exemple la mise à zéro des blocs pour initialisation de
disque.
● XCOPY décharge la copie des données vers et depuis la baie via l’hyperviseur.
La section Activation et désactivation de XCOPY avec l’interface CLI fournit plus d’informations sur l’activation et la désactivation de
XCOPY.
● La suppression de mappages permet à l’hyperviseur de revendiquer un stockage supprimé sur un stockage virtuel Metro Node à
provisionnement dynamique. Reportez-vous à la section « Comprendre le provisionnement dynamique » pour plus d’informations sur
les fonctionnalités de volume à provisionnement dynamique et de suppression de mappages.
CompareAndWrite
La commande SCSI CompareAndWrite (CAW) est utilisée pour coordonner les opérations VMware, telles que la mise sous/hors tension
des machines virtuelles, le déplacement des machines virtuelles d’un ESX vers un autre sans interrompre les applications (VMotion) et les
opérations DRS (Distributed Resource Scheduler, système de planification des ressources distribuées).
CAW est utilisé par les serveurs VMware ESX pour alléger les conflits d’accès au stockage, ce qui peut être dû à une RÉSERVATION SCSI
dans des environnements de machines virtuelles distribuées. CAW aide à l’accélération matérielle du stockage en autorisant les serveurs
ESX à verrouiller une région de disque au lieu d’un disque entier.
Les serveurs ESX 5.0 utilisent cette stratégie pour augmenter le nombre de machines virtuelles que les serveurs ESX peuvent héberger, et
pour augmenter les performances de ces machines virtuelles.
La prise en charge de CAW est activée par défaut.
Activation ou désactivation de CAW
PRÉCAUTION : La commande CAW peut être activée/désactivée sur Metro Node uniquement par un représentant du
support client Dell EMC.
Les serveurs VMware détectent si la commande SCSI CAW est supportée :
● Lors de l’analyse de stockage initiale
● Lorsque la valeur VMFS3.HardwareAcceleratedLocking sur l’hôte ESX est activée (ou basculée si elle est activée)
REMARQUE : Pour faire basculer la valeur : dans vSphere Client, basculez la valeur host > Configuration > Software > Advanced
Settings > VMFS3.HardwareAcceleratedLocking sur 0, puis sur 1.
Si CAW n’est pas supportée ou que le support est désactivé, Metro Node renvoie CHECK CONDITION, ILLEGAL REQUEST et INVALID
OP-CODE. Le serveur ESX réutilise la commande SCSI RESERVE et l’opération de machine virtuelle se poursuit.
Les opérations de machine virtuelle peuvent subir une dégradation significative des performances si CAW n’est pas activée.
Metro Node permet d’activer/désactiver CAW pour l’ensemble du stockage associé à Metro Node, à l’aide d’une seule et même
commande. Lorsque CAW est désactivée sur Metro Node, les volumes de stockage n’incluent pas les informations de support CAW dans
leurs réponses aux requêtes des hôtes.
Pour marquer le stockage CAW comme désactivé :
● VMFS3.HardwareAcceleratedLocking doit être basculé. Ou
● Il se peut que les hôtes doivent relancer une analyse de leur stockage.
Gestion du système
17
PRÉCAUTION : L’activation ou la désactivation de la fonctionnalité CAW supporte des situations exceptionnelles,
comme l’assistance d’un membre du support technique Dell EMC pour diagnostiquer un problème. CAW est activée
par défaut et peut uniquement être désactivée par un membre du support technique Dell EMC.
Le support de CAW peut être activé ou désactivé à deux niveaux :
● Storage view – Activé ou désactivé pour toutes les vues de stockage existantes. Une vue de stockage créée après activation/
désactivation de CAW au niveau storage view hérite du paramètre system default. Dell EMC recommande de maintenir le paramètre
CAW uniforme sur toutes les vues de stockage. Si CAW doit être désactivé pour une vue de stockage donnée, il doit être désactivé
sur toutes les vues de stockage existantes et futures. Pour vous assurer que les vues de stockage futures correspondent à la nouvelle
configuration, modifiez la valeur system default (décrite ci-dessous).
● System default – Activé ou désactivé en tant que valeur système par défaut. Une vue de stockage créée après activation/
désactivation de CAW au niveau system default hérite du paramètre system default. Si la valeur system default est activée, le
support par CAW support de la nouvelle vue de stockage est également activé.
Affichage des paramètres CAW
Utilisez la commande ls dans le contexte /clusters/cluster/exports/storage-views pour afficher si CAW est activé au
niveau de la vue de stockage. Par exemple :
VPlexcli:/> ll /clusters/cluster-2/exports/storage-views/*
/clusters/cluster-2/exports/storage-views/FE-Logout-test:
Name
Value
------------------------ -----------------------------------------------------caw-enabled
false
.
.
.
/clusters/cluster-2/exports/storage-views/default_quirk_view:
Name
Value
------------------------ -----------------------------------------caw-enabled
false
.
.
.
Utilisez la commande ls dans le contexte /clusters/cluster pour afficher le paramètre par défaut du système CAW :
VPlexcli:/> ls /clusters/cluster-1
/clusters/cluster-1:
Attributes:
Name
Value
---------------------- -------------------------------------------allow-auto-join
true
auto-expel-count
0
auto-expel-period
0
auto-join-delay
0
cluster-id
1
connected
true
default-cache-mode
synchronous
default-caw-template
true
.
.
.
Activation/désactivation des paramètres CAW pour une vue de stockage
Utilisez la commande set dans le contexte /clusters/cluster/exports/storage-views/storage-view pour activer ou
désactiver CAW pour la vue de stockage.
Pour activer CAW pour une vue de stockage :
VPlexcli:/clusters/cluster-1/exports/storage-views/recoverpoint_vols> set caw-enabled true
18
Gestion du système
Pour désactiver CAW pour une vue de stockage :
VPlexcli:/clusters/cluster-1/exports/storage-views/recoverpoint_vols> set caw-enabled false
Activation/désactivation des paramètres CAW en tant que système par défaut
Utilisez la commande set dans le contexte /clusters/cluster pour activer ou désactiver CAW pour l’ensemble du cluster.
Pour activer CAW en tant que système de cluster par défaut :
VPlexcli:/clusters/cluster-1> set default-caw-template true
Pour désactiver CAW en tant que système de cluster par défaut :
VPlexcli:/clusters/cluster-1> set default-caw-template false
Statistiques sur les paramètres CAW
Les statistiques de performances CAW sont incluses pour les cibles de volume frontal (fe-lu), de port frontal (fe-prt) et de directeur
frontal (fe-director).
Voir Tableaux de statistiques , page 100 pour obtenir la liste des statistiques disponibles. Les statistiques des cibles fe-director sont
collectées dans le cadre de l’analyseur perpétuel créé automatiquement.
Vous pouvez créer un analyseur pour collecter des statistiques CAW, qui peuvent être particulièrement utiles pour les cibles fe-lu (parce
qu’il peut y avoir un très grand nombre de volumes concernés, ces statistiques ne sont pas toujours collectées).
Opérations CompareAndWrite (16)
La commande SCSI WriteSame (16) fournit un mécanisme de déchargement de l’initialisation des disques virtuels sur Metro Node.
WriteSame (16) demande au serveur d’écrire les blocs de données transférés par le client d’application vers des blocs logiques consécutifs
à plusieurs reprises.
WriteSame (16) est utilisé pour décharger le provisionnement et la prise de snapshots des machines virtuelles de vSphere vers
Metro Node.
WriteSame (16) permet à la baie d’effectuer des opérations de copie indépendamment, sans utiliser les cycles de l’hôte. La baie peut
planifier et exécuter la fonction de copie beaucoup plus efficacement.
Le support de la commande WriteSame (16) par Metro Node est activé par défaut.
Activation/désactivation des paramètres WriteSame (16)
PRÉCAUTION : La commande WriteSame (16) peut être activée/désactivée sur Metro Node uniquement par un membre
du support technique Dell EMC.
Les serveurs VMware détectent si la commande SCSI WriteSame (16) est supportée :
● Lors de l’analyse de stockage initiale
● Lorsque la valeur DataMover.HardwareAcceleratedInit sur l’hôte ESX est activée (ou basculée si elle est activée)
REMARQUE : Pour faire basculer la valeur : dans vSphere Client, basculez la valeur host > Configuration > Software > Advanced
Settings > DataMover.HardwareAcceleratedInit sur 0, puis sur 1.
Les opérations de machine virtuelle peuvent subir une dégradation significative des performances si WriteSame (16) n’est pas activée.
Metro Node permet d’activer/désactiver WriteSame (16) pour l’ensemble du stockage associé à Metro Node, à l’aide d’une seule et même
commande. Lorsque WriteSame (16) est désactivée sur Metro Node, les volumes de stockage n’incluent pas les informations de support
de WriteSame (16) dans leurs réponses aux requêtes des hôtes.
Le support de WriteSame (16) peut être activé ou désactivé à deux niveaux :
Gestion du système
19
● Storage view – Activé ou désactivé pour toutes les vues de stockage existantes. Une vue de stockage créée après activation/
désactivation de WriteSame (16) au niveau storage view hérite du paramètre system default. Dell EMC recommande de maintenir le
paramètre WriteSame (16) uniforme sur toutes les vues de stockage Metro Node.
Si WriteSame (16) doit être désactivé pour une vue de stockage donnée, il doit être désactivé sur toutes les vues de stockage
existantes et futures. Pour que les vues de stockage futures correspondent à la nouvelle configuration, modifiez la valeur system
default.
● System default – Activé ou désactivé en tant que valeur système par défaut. Une vue de stockage créée après activation/
désactivation de WriteSame (16) au niveau system default hérite du paramètre system default. Si la valeur system default est activée,
le support par WriteSame (16) de la nouvelle vue de stockage est également activé.
PRÉCAUTION : Pour désactiver le modèle WriteSame (16) par défaut, vous devez désactiver WriteSame (16)
pour toutes les vues existantes, puis désactiver le modèle WriteSame (16) afin que toutes les vues futures aient
WriteSame (16) désactivé. Pour activer le modèle WriteSame (16) par défaut, vous devez activer WriteSame (16)
pour toutes les vues existantes, puis activer le modèle WriteSame (16) afin que toutes les vues futures aient
WriteSame (16) activé.
Affichage des paramètres WriteSame (16)
Utilisez la commande ls dans le contexte /clusters/cluster/exports/storage-views pour afficher si WriteSame (16) est
activé au niveau de la vue de stockage. Par exemple :
VPlexcli:/> ll /clusters/cluster-2/exports/storage-views/*
/clusters/cluster-2/exports/storage-views/FE-Logout-test:
Name
Value
------------------------ -----------------------------------------caw-enabled
false
.
.
.
/clusters/cluster-2/exports/storage-views/default_quirk_view:
Name
Value
------------------------ -----------------------------------------.
.
.
write-same-16-enabled
false
Utilisez la commande ls dans le contexte /clusters/cluster pour afficher le paramètre par défaut du système WriteSame (16) :
VPlexcli:/> ls /clusters/cluster-1
/clusters/cluster-1:
VPlexcli:/clusters/cluster-1> ls
Attributes:
Name
Value
------------------------------ ----------------------------------allow-auto-join
true
auto-expel-count
0
auto-expel-period
0
auto-join-delay
0
cluster-id
1
connected
true
default-cache-mode
synchronous
default-caw-template
true
default-write-same-16-template false
.
.
.
Activation/désactivation des paramètres WriteSame (16) pour une vue de
stockage
Utilisez la commande set dans le contexte /clusters/cluster/exports/storage-views/storage-view pour activer ou
désactiver WriteSame (16) pour la vue de stockage.
20
Gestion du système
Pour activer WriteSame (16) pour une vue de stockage :
VPlexcli:/clusters/cluster-1/exports/storage-views/recoverpoint_vols> set write-same-16enabled true
Pour désactiver WriteSame (16) pour une vue de stockage :
VPlexcli:/clusters/cluster-1/exports/storage-views/recoverpoint_vols> set write-same-16enabled false
Activation/désactivation des paramètres WriteSame (16) en tant que système
par défaut
Utilisez la commande set dans le contexte /clusters/cluster pour activer ou désactiver WriteSame (16) pour l’ensemble du
cluster.
Pour activer WriteSame (16) comme système de cluster par défaut :
VPlexcli:/clusters/cluster-1> set default-write-same-16-template true
Pour désactiver WriteSame (16) comme système de cluster par défaut :
VPlexcli:/clusters/cluster-1> set default-write-same-16-template false
Surcharge de la copie de déchargement avec XCOPY
Pour réduire la surcharge des E/S et optimiser les performances des opérations de copie, le déplacement des données doit se faire au plus
proche de la couche de stockage physique, et non de la couche serveur (comme avec les copies de données basées sur l’hôte).
En utilisant la fonctionnalité XCOPY de VMware, Metro Node gère l’allocation et le positionnement des données à l’aide de machines
virtuelles, et copie les données avec un impact minime sur l’hôte en matière de performances. Lorsque la fonctionnalité XCOPY est
activée, les opérations de copie et de déplacement des données sur disque se produisent sur la baie de stockage, et non sur l’hôte.
Activation et désactivation des commandes XCOPY avec
l’interface CLI
Vous pouvez activer ou désactiver la fonction XCOPY au niveau du cluster ou de la vue de stockage.
XCOPY peut être activée et désactivée pour toutes les vues de stockage. Bien qu’il soit possible d’activer ou de désactiver XCOPY pour
chaque vue, cette option n’est pas recommandée, sauf après consultation du support Dell EMC. La bonne pratique consiste à toujours
utiliser des paramètres uniformes dans Metro Node pour toutes les vues de stockage.
1. Pour activer XCOPY, définissez l’attribut xcopy-enabled sur true. Pour désactiver XCOPY, définissez l’attribut xcopy-enabled
sur false.
Par exemple, pour activer XCOPY pour toutes les vues de stockage, saisissez la commande CLI suivante :
VPlexcli:/> set /clusters/**/storage-views/*::xcopy-enabled true
2. Vérifiez l’état de l’attribut xcopy-enabled en répertoriant tous les attributs de toutes les vues de stockage comme suit :
VPlexcli:/> ll /clusters/cluster-1/exports/storage-views/*
Activation et désactivation des commandes XCOPY par défaut
XCOPY est activée par défaut dans Metro Node, car l’attribut xcopy-enabled est défini sur true, au moment de la production, dans le
contexte du cluster.
Pour modifier ce comportement, vous devez modifier la valeur par défaut de XCOPY.
Gestion du système
21
PRÉCAUTION : La modification de la valeur par défaut du modèle pour l’attribut XCOPY modifie la valeur de l’attribut
XCOPY dans toutes les vues de stockage nouvellement créées. Cette opération ne doit s’effectuer que dans de rares
cas, généralement après consultation du support Dell EMC. La modification de la valeur par défaut du modèle peut avoir
un effet négatif sur les performances d’E/S de l’hôte VMware.
1. Pour activer XCOPY par défaut, définissez l’attribut default-xcopy-template sur true comme suit :
VPlexcli:/> set /clusters/*::default-xcopy-template true
2. Vérifiez l’état de l’attribut default-xcopy-template en répertoriant tous les attributs du contexte du cluster
comme suit :
VPlexcli:/clusters/cluster-1> ls
Affichage des statistiques XCOPY
Metro Node fournit des statistiques qui suivent les performances et la fréquence des opérations XCOPY. Ces statistiques sont collectées
côté frontal.
Voir Statistiques , page 98.
Configuration d’un analyseur XCOPY
Pour toutes les statistiques qui ne sont pas automatiquement collectées dans le cadre d’une surveillance perpétuelle, vous pouvez créer
manuellement un analyseur pour collecter les statistiques de la latence XCOPY sur un volume virtuel Metro Node particulier.
Créez un analyseur et configurez un récepteur de fichiers afin que les statistiques du volume frontal (fe-lu, volume virtuel Metro Node)
spécifique soient collectées dans le fichier configuré.
L’exemple suivant représente la procédure de création d’un analyseur pour collecter les statistiques fe-lu.xcopy-avg-lat pour un volume
donné (VAAI_Vol1_Device_vol) dans un fichier (/tmp/monitors/director-1-1-A-fe-lu-avg-lat) :
VPlexcli:/monitoring/directors/director-1-1-A/monitors> monitor create --name fe-lu-xcopy-avglat
--director /engines/engine-1-1/directors/director-1-1-A --stats fe-lu.xcopy-avg-lat
--targets /clusters/cluster-1/virtual-volumes/VAAI_Vol1_Device_vol
VPlexcli:/monitoring/directors/director-1-1-A/monitors/fe-lu-ws-avg-lat> monitor add-file-sink
/tmp/monitors/director-1-1-A-fe-lu-avg-lat
Changement de nom d’un cluster Metro Node
Metro Node automatiquement des noms à ses clusters. Par défaut, les clusters sont nommés cluster-1 et cluster-2. Vous pouvez modifier
ces noms avec l’interface CLI Metro Node.
Après avoir renommé un cluster Metro Node :
● L’exécution d’une tâche de migration ou d’une tâche planifiée peut échouer. Pour éviter ce problème, renommez le cluster une fois les
tâches terminées.
● La connectivité VPN peut être perdue après une mise à niveau système. Reconfigurez le VPN après la mise à niveau.
REMARQUE : Le nouveau nom du cluster peut contenir jusqu’à 63 caractères, y compris des lettres majuscules et minuscules, des
chiffres et des traits de soulignement. Le nom ne doit pas commencer par un chiffre ou le préfixe cluster-. Le nom ne doit pas
comporter d’espaces.
Pour renommer un cluster Metro Node :
1. Connectez-vous à l’interface CLI.
2. Accédez au contexte du cluster.
3. Entrez la commande suivante :
set name nom
Où nom est le nouveau nom du cluster.
22
Gestion du système
Voici un exemple :
vplexcli:/clusters/cluster-1>set name clusterone
vplexcli:/clusters/clusterone>
Paramètres du panneau avant LCD
PRÉCAUTION : N’utilisez pas le panneau pour modifier l’un des paramètres de l’iDRAC ou du R640. La modification des
paramètres peut interférer avec la configuration Metro Node et entraîner une défaillance de la fonctionnalité.
Gestion du système
23
4
Support dynamique de Metro Node
Ce chapitre décrit comment Metro Node supporte les fonctionnalités compatibles avec le provisionnement dynamique.
Sujets :
•
•
•
•
Support dynamique de Metro Node
Provisionnement dynamique
Gestion du stockage dynamique
Mise en miroir et migration dynamiques
Support dynamique de Metro Node
La compatibilité avec le provisionnement dynamique est la fonctionnalité qui annonce les volumes virtuels Metro Node en tant que volumes
dynamiques aux hôtes. Les volumes dynamiques offrent une plus grande efficacité, car le nombre de ressources utilisées est bien inférieur
à celui alloué. Cet avantage qui consiste à fournir uniquement les ressources nécessaires dépasse le coût de la technologie de virtualisation
utilisée. Il permet la libération dynamique de blocs de stockage sur des volumes de stockage qui offrent un support dynamique. Le support
dynamique permet le mappage d’un ou plusieurs blocs logiques vers des blocs physiques, si nécessaire. Les blocs logiques fournissent
l’espace d’adressage de stockage (capacité de l’unité logique) aux hôtes. Le stockage physique est alloué à l’unité logique uniquement
lorsqu’elle est utilisée. Cela garantit que le stockage physique alloué à l’unité logique est inférieur à la capacité qu’elle indique. Les blocs
physiques peuvent être mappés aux blocs logiques si nécessaire (en cas d’écriture). Metro Node étend plusieurs fonctions dynamiques qui
sont fournies par les baies connectées au back-end.
Gestion du stockage dynamique
Metro Node utilise certaines fonctionnalités de gestion des baies compatibles avec le provisionnement dynamique côté back-end pour
détecter et résoudre les problèmes d’épuisement du stockage. Lorsqu’un hôte cesse d’utiliser les blocs de stockage dynamique alloués à
partir de la baie, les blocs inutilisés ne sont pas libérés ni renvoyés aux baies. Par exemple, dans un environnement virtuel où les datastores
d’une machine virtuelle sont stockés sur un volume dynamique, et où ces datastores sont supprimés ou déplacés, l’espace de stockage
n’est pas libéré. Ce comportement peut entraîner un problème d’espace insuffisant sur les volumes dynamiques. Lorsque la capacité de
stockage dynamique atteint un seuil spécifique, les baies de stockage envoient des événements aux hôtes qui indiquent que l’espace de
stockage diminue. Dans ce cas, les hôtes peuvent envoyer la commande SCSI UNMAP aux volumes virtuels Metro Node pour libérer
l’espace inutilisé.
REMARQUE : La fonctionnalité de suppression de mappages est uniquement supportée sur les volumes virtuels Metro Node à
provisionnement dynamique qui répondent aux exigences de provisionnement dynamique. La section Création de volumes virtuels à
provisionnement dynamique répertorie les exigences de provisionnement dynamique pour un volume virtuel.
Reconstruction dynamique
Metro Node fournit une disponibilité continue et des fonctions haute disponibilité grâce à sa fonctionnalité de mise en miroir. Au cours du
processus de mise en miroir, Metro Node garantit qu’un tronçon de miroir dynamique ne devient pas un tronçon statique. Metro Node
utilise sa fonctionnalité de reconstruction dynamique pour synchroniser les données entre les miroirs d’un périphérique RAID 1 construit
sur des volumes dynamiques. Si la baie supporte la fonctionnalité de suppression de mappages, Metro Node utilise la commande SCSI
UNMAP pour libérer de l’espace sur les tronçons obsolètes, le cas échéant. Si la baie ne supporte pas la fonction de suppression de
mappages, Metro Node écrit des zéros dans les blocs qui doivent être mis à zéro pour préserver le dynamisme. Ce comportement
permet de préserver le dynamisme du périphérique. Avant même le support de la suppression de mappages, Metro Node permettait à
un administrateur Metro Node de revendiquer un volume de stockage dynamique en définissant la balise thin-rebuild. Elle oriente
Metro Node pour utiliser efficacement l’espace à l’aide des reconstructions dynamiques.
La section Reconstructions du stockage à provisionnement dynamique fournit des informations supplémentaires sur les reconstructions du
stockage à provisionnement dynamique.
24
Support dynamique de Metro Node
Migrations dynamiques
Metro Node prend en charge les fonctionnalités de mobilité des données sur les périphériques dynamiques. Lorsque la source ou la cible
de la migration n’est pas dynamique, ou lorsque la source et les cibles proviennent de différentes gammes de baies de stockage, le volume
virtuel Metro Node perd ses propriétés dynamiques. Dans ce cas, le volume virtuel ne supporte pas les opérations de gestion du stockage
dynamique. Une fois la migration terminée et validée, le volume virtuel hérite des capacités dynamiques du périphérique cible. La section
Migration de stockage compatible avec le provisionnement dynamique fournit des informations supplémentaires sur les migrations de
stockage à provisionnement dynamique.
Le tableau suivant décrit comment Metro Node supporte les fonctionnalités compatibles avec le provisionnement dynamique (en fonction
de l’interprétation, par Metro Node, de la compatibilité des baies avec le provisionnement dynamique).
Tableau 4. Fonctionnalité de provisionnement dynamique des baies lors d’une migration
Ressource
Baies compatibles avec le provisionnement
dynamique
Baies non compatibles avec le
provisionnement dynamique
Provisionnement
dynamique
● Détecte les volumes dynamiques côté back-end
● Définit automatiquement la balise thin-rebuild
dans le cadre du processus de revendication des
volumes de stockage
● Supporte le provisionnement des volumes
dynamiques sur la baie via le provisionnement des
trous d’interconnexion
● Crée les volumes virtuels compatibles avec le
provisionnement dynamique
● Supporte le balisage manuel des volumes
dynamiques avec la balise thin-rebuild
dans le cadre du processus de
revendication des volumes de stockage
Gestion du stockage
dynamique
● Supporte la commande SCSI UNMAP à partir de
l’hôte
● Supporte les notifications d’espace insuffisant sur
l’hôte à partir du dernier tronçon qui traite les E/S
Non pris en charge
Reconstruction dynamique
● Définit automatiquement la balise thin-rebuild
dans le cadre du processus de revendication des
volumes de stockage
● Utilise la commande SCSI UNMAP pour libérer les
blocs de stockage sur le tronçon obsolète
● Supporte le balisage manuel des volumes
dynamiques avec la balise thin-rebuild
dans le cadre du processus de
revendication des volumes de stockage
● Écrit des zéros dans le cadre de la
synchronisation des miroirs des blocs
inutilisés.
Migration dynamique
Comportement de migration normal avec
● Conserve les fonctionnalités de gestion du stockage
optimisation de la zone inutilisée.
dynamique du volume virtuel uniquement lors de
la migration entre volumes compatibles avec le
provisionnement dynamique d’une même famille de
baies de stockage.
● Dans les autres cas, le volume virtuel perd les
fonctionnalités de gestion du stockage dynamique lors
de la migration et les restaure lors de la validation de
la migration.
Provisionnement dynamique
Dans Metro Node, le provisionnement dynamique s’exécute via une méthode existante (méthodes de provisionnement EZ ou de
provisionnement avancé) et via des trous d’interconnexion.
Le provisionnement dynamique fournit plus d’informations sur ces méthodes.
Création de volumes virtuels à provisionnement dynamique
Metro Node supporte la création de volumes virtuels qui présentent des capacités dynamiques aux hôtes. Pour présenter ces
fonctionnalités, certaines exigences doivent être respectées. Les exigences sont les suivantes :
Support dynamique de Metro Node
25
● Les volumes de stockage sont provisionnés à partir de baies de stockage supportées par Metro Node comme compatibles avec le
provisionnement dynamique (propriétés dynamiques affichées). Les volumes de stockage doivent également provenir d’une famille
de baies de stockage supportée par Metro Node (Dell EMC PowerStore, Dell EMC UnityXT). La valeur correspondant à la propriété
storage-array-family doit être XTREMIO, CLARiiON ou SYMMETRIX, et ne doit pas être other ou -.
● Le volume de stockage affiche des propriétés dynamiques.
● Tous les miroirs sont créés à partir d’une même famille de baies de stockage supportée par Metro Node (configuration RAID 1). La
valeur correspondant à la propriété storage-array-family ne doit pas être mixed, other ou -. Dans les scénarios suivants,
l’attribut thin capable peut afficher false même si les miroirs sont créés à partir d’une même famille de baies de stockage
supportée par Metro Node :
○ Le logiciel de la baie ne supporte pas la fonctionnalité de suppression de mappages.
○ La fonctionnalité de suppression de mappages n’est pas activée sur les baies.
Création de volumes virtuels à provisionnement dynamique avec la méthode de
provisionnement existante
Avec la méthode existante, vous pouvez créer un volume virtuel à provisionnement dynamique de deux façons :
● Provisionnement EZ : utilisez la commande storage-tool compose --thin pour créer un volume virtuel sur les volumes de
stockage spécifiés, en construisant toutes les extensions intermédiaires, les périphériques locaux et les périphériques distribués, si
nécessaire.
● Provisionnement avancé : effectuez les tâches suivantes :
○ Revendiquez manuellement les volumes de stockage dynamique détectés par Metro Node.
○ Créez des extensions sur le volume de stockage compatible avec le provisionnement dynamique avec la commande extent
create.
○ Créez des périphériques locaux compatibles avec le provisionnement dynamique avec la commande local-device create.
○ Créez des volumes virtuels à provisionnement dynamique avec la commande virtual-volume create --thin.
REMARQUE : Si vous créez un volume virtuel sans l’attribut --thin, un volume statique est créé par défaut. Le volume
virtuel doit être construit sur un périphérique RAID 0 local ou un périphérique RAID 1. Si vous tentez de créer un périphérique
RAID C local avec plusieurs enfants ou un périphérique qui intègre plusieurs extensions, le périphérique local créé n’est pas
compatible avec le provisionnement dynamique.
L’exemple suivant décrit comment créer deux extensions sur un volume de stockage compatible avec le provisionnement dynamique (avec
la restriction suivante : création d’une extension statique) :
VPlexcli:/clusters/cluster-1/storage-elements/storage-volumes> extent create myVolume --numextents 2
You are creating 2 extents on top of 1 thin-capable storage-volume 'myVolume'. The resulting
extents will not be thin-capable.
L’exemple suivant décrit comment créer une extension plus petite que le volume de stockage de support (avec la restriction suivante :
création d’une extension statique) :
VPlexcli:/clusters/cluster-1/storage-elements/storage-volumes> extent create myVolume --size
1MB
The new extent will not completely encompass the following thin-capable storage-volume:
myVolume. The resulting extent will not be thin-capable.
Utilisez les commandes suivantes pour répertorier les volumes virtuels compatibles avec le provisionnement dynamique ou pour définir des
volumes virtuels comme étant à provisionnement dynamique :
virtual-volume list-thin --enabled false
--capable true --clusters Cluster
Répertoriez tous les volumes virtuels compatibles avec le
provisionnement dynamique qui ne sont actuellement pas à
provisionnement dynamique.
virtual-volume list-thin --capable true -clusters Cluster
Répertorie tous les volumes compatibles avec le provisionnement
dynamique (qu’ils soient ou non à provisionnement dynamique).
virtual-volume set-thin-enabled [true|
false] --virtual-volumes volumes-virtuels
Définissez les volumes virtuels sur thin-enabled.
Par exemple, pour définir tous les volumes virtuels du cluster-1 sur thin-enabled, saisissez la commande suivante :
virtual-volume set-thin-enabled true --virtual-volumes /clusters/cluster-1/virtual-volumes/*
26
Support dynamique de Metro Node
Le document CLI Guide for metro node (Guide de l’interface CLI pour Metro Node) fournit plus d’informations sur les commandes et leur
utilisation.
Modification du caractère dynamique d’un volume virtuel
Metro Node ne signale pas la propriété dynamique d’un volume aux initiateurs hôtes tant que l’option thin-enabled correspondante n’a
pas été définie sur true. Cette valeur peut être définie sur true dans le cadre du processus de création, comme décrit à la section Création
de volumes virtuels à provisionnement dynamique. Vous pouvez définir la valeur thin-enabled d’un volume virtuel sur true uniquement
s’il est compatible avec le provisionnement dynamique. Utilisez la commande set pour remplacer la valeur de l’attribut thin-enabled
par true ou false. La valeur true permet de configurer l’attribut thin-enabled sur enabled ; la valeur false permet de configurer l’attribut
thin-enabled sur disabled. Une fois le comportement du volume virtuel modifié, les hôtes doivent effectuer certaines actions (nouvelle
analyse, par exemple) pour détecter le comportement modifié.
VPlexcli:/clusters/cluster-2/virtual-volumes/XtremIO_LUN_1_vol> set thin-enabled true
VPlexcli:/clusters/cluster-2/virtual-volumes/XtremIO_LUN_1_vol> ls
Name
Value
-------------------------- ---------------------------------------block-count
5242880
block-size
4K
cache-mode
synchronous
capacity
20G
consistency-group
expandable
true
expandable-capacity
0B
expansion-method
storage-volume
expansion-status
health-indications
[]
health-state
ok
locality
local
operational-status
ok
scsi-release-delay
0
service-status
running
storage-tier
supporting-device
XtremIO_LUN_1
system-id
XtremIO_LUN_1_vol
thin-capable
true
thin-enabled
enabled
volume-type
virtual-volume
vpd-id
VPD83T3:6000144000000010e03e55ee4c98c41f
REMARQUE : Vous pouvez utiliser des caractères génériques pour configurer plusieurs volumes virtuels Metro Node pour le
provisionnement dynamique, après une mise à niveau logicielle Metro Node.
/clusters/cluster-1/virtual-volumes/thick_1:
Name
Value
-------------------------- ---------------------------------------block-count
block-size
4K
cache-mode
synchronous
capacity
200G
consistency-group
expandable
true
expandable-capacity
0B
expansion-method
storage-volume
expansion-status
health-indications
[]
health-state
ok
locality
local
operational-status
ok
scsi-release-delay
0
service-status
unexported
storage-tier
supporting-device
device_thick_1_c1
system-id
thick_1
thin-capable
false
thin-enabled
unavailable
52428800
Support dynamique de Metro Node
27
volume-type
vpd-id
virtual-volume
VPD83T3:6000144000000010e025d83c86ace201
Gestion du stockage dynamique
Metro Node utilise certaines fonctionnalités de gestion des baies compatibles avec le provisionnement dynamique côté back-end pour
détecter et résoudre les problèmes d’épuisement du stockage. Cela n’est pas obligatoire avec les baies qui supportent les volumes
dynamiques pour prendre en charge les fonctionnalités de gestion du stockage dynamique. Metro Node peut identifier si une baie supporte
les fonctionnalités de gestion du stockage dynamique. En fonction de la détection, Metro Node définit l’attribut thin capable du
volume virtuel.
Gestion de l’épuisement du stockage sur les volumes dynamiques
Une baie de stockage peut répondre à Metro Node avec une erreur d’épuisement du stockage pour une écriture sur un volume dynamique.
Les administrateurs de stockage qui surveillent en continu la capacité des pools de stockage prennent les mesures nécessaires pour éviter
l’épuisement des blocs de stockage de leurs datacenters.
Une baie de stockage peut notifier principalement deux types d’erreurs d’épuisement des blocs de stockage. En voici la liste :
● Épuisement temporaire : se produit lorsqu’une baie de stockage est en train de libérer de l’espace et ne peut pas répondre
immédiatement par une réussite de l’écriture. Dans ce cas, Metro Node renouvelle les E/S pendant un court laps de temps avant
de mettre l’écriture en échec et de marquer le matériel du volume de stockage hors service. Dans ce cas, un événement Call Home est
émis et Metro Node tente de restaurer automatiquement le volume de stockage lorsqu’il répond avec succès aux tests d’intégrité. Si
le volume de stockage est protégé par un miroir fonctionnel, l’hôte n’identifie aucune interruption des services, car le tronçon de miroir
sain continue de traiter les E/S sur l’hôte.
● Épuisement permanent : se produit lorsqu’il ne reste plus de blocs de stockage disponibles à mapper vers l’adresse vers laquelle l’hôte a
émis une commande d’écriture. Metro Node gère cette erreur différemment pour les périphériques avec et sans mise en miroir.
Pour l’épuisement permanent des ressources en mode bloc sur un volume de stockage sans mise en miroir, la réponse à la demande
d’écriture indique au Metro Node que le volume de stockage est protégé en écriture, car l’allocation d’espace a échoué. Les volumes
virtuels Metro Node renvoient également la même erreur pour la commande d’écriture à l’hôte. Lorsque les hôtes VMware reçoivent cette
erreur pour une demande d’écriture, ils arrêtent la machine virtuelle qui a effectué la demande d’écriture et autorisent les autres machines
virtuelles à poursuivre leur opération. Les autres machines virtuelles peuvent réaliser avec succès les opérations de lecture et d’écriture
sur les blocs qui sont déjà mappés. Mais, si elles font une demande d’écriture sur un bloc de stockage non mappé, et que l’écriture fait
également l’objet d’une erreur d’épuisement des ressources, celles-ci sont également arrêtées.
Avec un volume sans mise en miroir, les administrateurs de stockage peuvent tenter de récupérer du stockage à l’aide de la commande
UNMAP et d’effectuer une restauration à partir de la condition d’erreur d’espace insuffisant. Si le stockage récupéré n’est pas suffisant,
ajoutez un stockage en mode bloc libre aux baies de stockage pour résoudre les conditions d’erreur d’échec d’allocation d’espace, puis
redémarrez les machines virtuelles qui sont suspendues ou arrêtées.
Pour les volumes avec mise en miroir, Metro Node masque l’erreur qui s’est produite sur un tronçon de miroir pour l’écriture d’un
hôte, comme pour toute autre erreur d’E/S. Metro Node termine la demande de l’hôte avec succès lorsque les E/S réussissent sur au
moins un tronçon de miroir. Metro Node marque le tronçon de miroir comme obsolète (OOD) et n’essaie pas de le recréer (rétablir)
automatiquement. Un administrateur de stockage doit allouer de l’espace sur la baie et le rendre disponible pour ce volume de stockage,
puis restaurer manuellement le tronçon de miroir en suivant les procédures décrites dans Solve Desktop. Une fois le miroir restauré,
Metro Node reconstruit le tronçon.
Si l’épuisement du stockage permanent se produit sur le dernier tronçon d’un volume avec mise en miroir, Metro Node propage cette
erreur à l’hôte qui demande l’écriture comme pour un volume sans mise en miroir.
Définition des seuils pour l’utilisation du stockage dynamique
Un administrateur peut définir une limite souple ou un seuil pour un stockage à provisionnement dynamique donné, ce qui indique que
l’espace de stockage du périphérique à provisionnement dynamique diminue. Ce seuil est configuré sur l’hôte ou sur les baies, et non sur
Metro Node. Le message indique que le périphérique a atteint le seuil défini. Actuellement, en cas de réception d’une telle notification en
provenance d’un périphérique de stockage, Metro Node renouvelle les E/S après envoi d’un événement Call Home. Ces notifications ne
peuvent être reçues qu’une seule fois sur une E/S, et les E/S doivent aboutir, sauf si le périphérique dynamique manque d’espace. En cas
de réception d’une telle notification Call Home, l’administrateur Metro Node peut informer l’administrateur de l’hôte qu’il peut libérer de
l’espace ou demander à l’administrateur de stockage d’ajouter plus de capacité.
28
Support dynamique de Metro Node
Mise en miroir et migration dynamiques
Metro Node supporte la mise en miroir et la migration des volumes dynamiques vers différentes baies.
Lors de la reconstruction d’un tronçon dynamique, Metro Node conserve la nature dynamique du tronçon. Pour ce faire, Metro Node
envoie la commande SCSI UNMAP aux baies qui supportent cette commande et écrit des zéros dans les blocs sur les baies qui ne
supportent pas la fonction de suppression de mappages. La section Reconstructions pour le stockage à provisionnement dynamique
fournit des informations supplémentaires sur les reconstructions dynamiques.
Exécution de la mise en miroir léger
Si vous fixez un miroir à un appareil compatible avec la mise en miroir léger et que le miroir n’est pas léger, l’appareil RAID 1 qui en résulte
perd sa fonctionnalité de mise en miroir léger.
Lorsque vous exécutez la commande device attach-mirror -d pour fixer un tronçon de miroir lourd à un appareil compatible
avec la mise en miroir léger, un avertissement s’affiche et indique que l’appareil n’est pas compatible avec la mise en miroir léger. Vous
êtes également invité à confirmer que vous souhaitez continuer. Vous pouvez utiliser l’option --force pour ignorer la confirmation, mais
l’appareil qui en résulte n’est pas léger.
VPlexcli:/clusters/cluster-1/storage-elements/extents> device attach-mirror -d myDevice
-m extent_TOP_101_1
The top-level device 'myDevice' is thin-capable. After attaching the mirror, the new
top-level device will not be thin-capable. Do you wish to proceed? (Yes/No) no
device attach-mirror: Evaluation of <<device attach-mirror -d myDevice -m extent_TOP_101_1>>
failed.
cause:
Failed to attach mirror.
cause:
Operation was halted by the user
VPlexcli:/clusters/cluster-1/storage-elements/extents>
Vous pouvez fixer un miroir à un appareil qui prend déjà en charge un volume virtuel compatible avec la mise en miroir léger à l’aide de la
commande device attach-mirror.
Pour ajouter un tronçon de miroir lourd à un volume virtuel compatible avec la mise en miroir léger, vous pouvez poursuivre en :
● Définissant la propriété de compatibilité avec la mise en miroir léger pour le volume virtuel sur false à l’aide de la commande set. Le
nouveau volume virtuel n’offre pas de compatibilité ou de fonctionnalité de mise en miroir léger.
VPlexcli:/clusters/cluster-1/devices> set ../virtual-volumes/myVolume::thin-enabled false
VPlexcli:/clusters/cluster-1/devices> device attach-mirror --device myDevice --mirror
myMirror
VPlexcli:/clusters/cluster-1/devices>
● Utilisant l’option --force avec la commande device attach-mirror. Le nouveau volume virtuel n’offre pas de compatibilité ou
de fonctionnalité de mise en miroir léger.
VPlexcli:/clusters/cluster-1/devices> device attach-mirror --device myDevice --mirror
myMirror
VPlexcli:/clusters/cluster-1/devices>
Dans une configuration avec mise en miroir léger, tous les tronçons doivent provenir de la même famille de baies de stockage. Si vous
tentez de créer des tronçons légers à partir des baies qui appartiennent à une famille de baies de stockage différente, l’aspect léger des
tronçons est perdu et les fonctionnalités de gestion du stockage léger ne sont plus prises en charge. Voici un exemple de ce type de
scénario :
VPlexcli:/> device attach-mirror --device xio_device --mirror vnx_device
Thin-capability is only supported with homogeneous storage-array types. The top-level device
'xio_device' is supported by XtremIO but the mirror 'vnx_device' is supported by CLARiiON.
Since XtremIO and CLARiiON are not homogeneous, the top-level device will lose thin-capability
after the new mirror is attached. Do you wish to proceed? (Yes/No) No
device attach-mirror:
vnx_device>>
cause:
cause:
Evaluation of <<device attach-mirror --device xio_device --mirror
failed.
Unable to attach mirror 'vnx_device' to device 'xio_device'.
Operation was halted by the user
Support dynamique de Metro Node
29
VPlexcli:/>
À propos des migrations dynamiques
Metro Node supporte la migration d’un volume dynamique vers une autre baie de stockage.
Pour qu’un volume dynamique prenne en charge les fonctions de gestion du stockage dynamique après une migration, les volumes source
et cible doivent être créés à partir de la même famille de baies de stockage. S’ils sont créés à partir de baies appartenant à une autre
famille de baies de stockage, l’attribut thin-enabled est conservé comme true, l’attribut thin-capable est défini sur false et la
commande de suppression de mappages est rejetée.
La section Migration de stockage compatible avec le provisionnement dynamique fournit des informations supplémentaires sur les
migrations de stockage à provisionnement dynamique.
30
Support dynamique de Metro Node
5
Provisionnement du stockage
Ce chapitre explique comment provisionner le stockage avec le provisionnement de stockage intégré à Metro Node.
Sujets :
•
•
•
Présentation du provisionnement
Provisionnement de stockage avec le provisionnement EZ
Modification du caractère dynamique d’un volume virtuel
Présentation du provisionnement
Pour commencer à utiliser Metro Node, vous devez provisionner le stockage afin que les hôtes puissent y accéder. Il existe trois méthodes
permettant d’allouer du stockage dans Metro Node :
● le provisionnement des EZ
● provisionnement avancé
REMARQUE : Dell EMC recommande d’utiliser l’interface GUI Unisphere for Metro Node pour provisionner le stockage.
Provisionnement de stockage avec le
provisionnement EZ
Le provisionnement EZ est une méthode simple de provisionnement uniquement disponible sous Unisphere for Metro Node. Le
provisionnement EZ permet de créer un volume virtuel avec un mappage un à un vers un volume de stockage sélectionné. Utilisez le
provisionnement EZ pour créer un volume virtuel qui utilise toute la capacité du volume de stockage.
Avec le provisionnement EZ, vous sélectionnez des baies de stockage et définissez la manière dont les utiliser, les protéger et les présenter
aux hôtes. Pour provisionner un stockage avec le provisionnement EZ, procédez comme suit :
1. Enregistrez les initiateurs qui accèdent au stockage Metro Node.
2. Créez des vues de stockage qui incluent des volumes virtuels, des initiateurs et des ports Metro Node pour contrôler l’accès de l’hôte
aux volumes virtuels.
3. Sélectionnez la baie de stockage et les volumes de stockage pour créer des volumes virtuels.
Pour plus d’informations sur le provisionnement de stockage avec le provisionnement EZ, utilisez l’aide en ligne
d’Unisphere for Metro Node.
REMARQUE : Dans l’interface CLI Metro Node, vous pouvez utiliser la commande storage-tool compose pour créer un
volume virtuel sur les volumes de stockage spécifiés, en construisant toutes les extensions intermédiaires, les périphériques locaux et
les périphériques distribués, si nécessaire. Le document CLI Reference Guide for metro node (Guide de référence de l’interface CLI
pour Metro Node) fournit plus d’informations sur l’utilisation de cette commande.
Modification du caractère dynamique d’un volume
virtuel
Metro Node ne signale pas la propriété dynamique d’un volume aux initiateurs hôtes tant que l’option thin-enabled correspondante n’a
pas été définie sur true. Cette valeur peut être définie sur true dans le cadre du processus de création, comme décrit à la section Création
de volumes virtuels à provisionnement dynamique. Vous pouvez définir la valeur thin-enabled d’un volume virtuel sur true uniquement
s’il est compatible avec le provisionnement dynamique. Utilisez la commande set pour remplacer la valeur de l’attribut thin-enabled
par true ou false. La valeur true permet de configurer l’attribut thin-enabled sur enabled ; la valeur false permet de configurer l’attribut
Provisionnement du stockage
31
thin-enabled sur disabled. Une fois le comportement du volume virtuel modifié, les hôtes doivent effectuer certaines actions (nouvelle
analyse, par exemple) pour détecter le comportement modifié.
VPlexcli:/clusters/cluster-2/virtual-volumes/XtremIO_LUN_1_vol> set thin-enabled true
VPlexcli:/clusters/cluster-2/virtual-volumes/XtremIO_LUN_1_vol> ls
Name
Value
-------------------------- ---------------------------------------block-count
5242880
block-size
4K
cache-mode
synchronous
capacity
20G
consistency-group
expandable
true
expandable-capacity
0B
expansion-method
storage-volume
expansion-status
health-indications
[]
health-state
ok
locality
local
operational-status
ok
scsi-release-delay
0
service-status
running
storage-tier
supporting-device
XtremIO_LUN_1
system-id
XtremIO_LUN_1_vol
thin-capable
true
thin-enabled
enabled
volume-type
virtual-volume
vpd-id
VPD83T3:6000144000000010e03e55ee4c98c41f
REMARQUE : Vous pouvez utiliser des caractères génériques pour configurer plusieurs volumes virtuels Metro Node pour le
provisionnement dynamique, après une mise à niveau logicielle Metro Node.
/clusters/cluster-1/virtual-volumes/thick_1:
Name
Value
-------------------------- ---------------------------------------block-count
block-size
4K
cache-mode
synchronous
capacity
200G
consistency-group
expandable
true
expandable-capacity
0B
expansion-method
storage-volume
expansion-status
health-indications
[]
health-state
ok
locality
local
operational-status
ok
scsi-release-delay
0
service-status
unexported
storage-tier
supporting-device
device_thick_1_c1
system-id
thick_1
thin-capable
false
thin-enabled
unavailable
volume-type
virtual-volume
vpd-id
VPD83T3:6000144000000010e025d83c86ace201
32
Provisionnement du stockage
52428800
6
Extension de volume
Ce chapitre décrit comment étendre les volumes virtuels.
Sujets :
•
•
•
Présentation
Méthode d’extension de volume
Extension d’un volume en mode bloc
Présentation
Un volume virtuel Metro Node est créé sur un périphérique, distribué ou non, et est présenté à un hôte par le biais d’une vue de stockage.
Vous pouvez souhaiter étendre la capacité d’un volume virtuel pour diverses raisons.
Si le volume supporte l’extension, Metro Node détecte la capacité acquise par extension. Déterminez alors la méthode d’extension
disponible : storage-volume. Metro Node peut également détecter la méthode d’extension disponible.
Certains volumes virtuels ne peuvent pas être étendus. Reportez-vous à la section Détermination de la méthode d’extension de volume
pour plus d’informations.
Effectuez une extension de volume à l’aide d’une procédure simple, sans interruption :
1. Étendez le volume de stockage associé au volume virtuel sur la baie de stockage sous-jacente.
2. Autorisez Metro Node à détecter de nouveau la baie de stockage sous-jacente.
3. Étendez le volume virtuel à l’aide de la CLI ou d’Unisphere.
Documentation supplémentaire
● Guide de l’interface CLI pour Metro Node : exécutez la commande virtual-volume expand .
● Aide en ligne d’Unisphere for Metro Node : utilisez Unisphere pour étendre le volume virtuel.
● SolVe Desktop : « Étendre un volume virtuel distribué avec GeoSynchrony » et « Configurer des baies de stockage pour
Metro Node ».
Méthode d’extension de volume
Metro Node recommande la méthode d’extension la plus appropriée au regard de la géométrie du périphérique sous-jacent, à l’aide de
l’attribut expansion-method.
Les valeurs possibles pour l’attribut expansion-method sont les suivantes :
● storage-volume – Metro Node étend le volume de stockage sous-jacent (LUN correspondants sur la baie back-end).
● not supported – Metro Node ne peut pas étendre le volume virtuel, car le volume n’a pas répondu à une ou plusieurs conditions
préalables. Pour plus d’informations, consultez la section Limitations.
Vous pouvez répertorier l’attribut expansion-method à l’aide de l’interface CLI ou d’Unisphere.
Affichage de l’attribut de méthode d’extension avec l’interface CLI
Dans cet exemple, l’attribut de méthode d’extension pour le volume test s’affiche en répertoriant le contexte virtual-volumes avec
l’interface CLI.
VPlexcli:> ll /clusters/cluster-1/virtual-volumes/ Test_volume
Name
Value
Extension de volume
33
------------------.
.
.
capacity
consistency-group
expandable
expandable-capacity
expansion-method
expansion-status
--------------
0.5G
true
0.0G
storage-volume
-
Notez que la valeur de l’attribut de méthode d’extension storage-volume indique que Metro Node utilise par défaut la méthode de
volume de stockage pour étendre le volume virtuel.
Affichage de l’attribut de méthode d’extension avec Unisphere
Lorsque vous utilisez Unisphere, cliquez sur le nom du volume virtuel pour afficher les propriétés du volume virtuel que vous souhaitez
étendre.
Dans l’exemple ci-dessous, les propriétés pour device_BASIC_vnx-1912_LUN146_1_vol indiquent que la méthode d’extension
recommandée est storage-volume. Metro Node utilise la méthode de volume de stockage pour étendre le volume virtuel par défaut.
Pour plus d’informations sur l’utilisation d’Unisphere pour étendre un volume, reportez-vous à l’aide disponible sur le serveur de gestion
Metro Node.
34
Extension de volume
Figure 1. Propriétés d’extension de volume virtuel (pour HTML5)
Extension d’un volume en mode bloc
Méthode d’extension de volume de stockage
Utilisez les instructions suivantes pour étendre le volume virtuel avec la méthode storage-volume.
Présentation
La méthode d’extension du volume de stockage prend en charge l’extension simple et rapide sur plusieurs géométries d’appareil. Trois des
géométries d’appareil les plus courantes sont décrites ici.
Extension de volume
35
1-à-1, volume virtuel vers volume de stockage
Figure 2. Géométries courantes : volume virtuel 1:1 vers volume de stockage
RAID 1 à deux branches
Figure 3. Géométries courantes : RAID 1 à deux branches
Conditions préalables liées à la méthode d’extension de volume de stockage
Afin d’étendre un périphérique ou d’ajouter une cible pour l’extension avec la méthode d’extension de volume de stockage, la géométrie du
volume virtuel Metro Node doit répondre à l’un des critères suivants :
● Le volume virtuel est mappé 1-à-1 vers le volume de stockage sous-jacent.
● Le volume virtuel est un volume RAID 1 multitronçon et chacune de ses extensions les plus petites est mappée 1-à-1 vers un volume de
stockage back-end.
● La géométrie du volume est une combinaison de l’une des géométries répertoriées précédemment.
36
Extension de volume
Planification de l’extension de volume
Répertoriez l’attribut expandable-capacity (dans l’interface CLI) ou le champ Expandable By (sous Unisphere) pour planifier la
capacité de vos périphériques de stockage back-end.
● expandable-capacity/ Expandable By – Pour les volumes virtuels qui peuvent être étendus avec la méthode d’extension de
volume de stockage, cette valeur correspond à la capacité qui est ajoutée au volume de stockage back-end, mais pas encore exposée
à l’hôte par le volume virtuel.
Cette capacité est disponible pour l’extension de volume virtuel Metro Node avec la méthode d’extension de volume de stockage.
○ 0 (zero) : une valeur zéro indique qu’il n’existe pas de capacité extensible pour le volume. Reportez-vous à l’attribut expansionmethod pour déterminer si l’extension basée sur le volume de stockage est supportée.
○ Non-zero value : une valeur différente de zéro indique la capacité disponible pour étendre le volume virtuel Metro Node. Examinez
l’attribut expansion-method pour déterminer si l’extension basée sur le volume de stockage est supportée.
Extension de volume
Réalisez une extension de volume en utilisant l’une des techniques suivantes :
● Exécutez la commande CLI virtual-volume expand. Reportez-vous au document Dell EMC CLI Guide for metro node (Guide de
l’interface CLI Dell EMC pour Metro Node) pour obtenir des informations détaillées sur cette commande.
● Étendez un volume virtuel avec Unisphere. Pour connaître la procédure détaillée, reportez-vous à l’aide en ligne
d’Unisphere for Metro Node.
● Pour connaître la procédure d’extension d’un volume virtuel distribué avec GeoSynchrony, reportez-vous à SolVe Desktop.
Lors d’une extension de volume avec la méthode par volume de stockage, assurez-vous que :
PRÉCAUTION : L’exécution d’une opération majeure de l’hôte (réinitialisation LIP, par exemple) afin de détecter une
modification de la taille d’un volume présente un risque pour les volumes accessibles par l’hôte. Il est recommandé
d’éviter ce type d’opérations gourmandes en ressources lors de l’extension de volume.
● Le trafic d’initialisation de l’extension se produit sur les zones de disque qui n’exécutent pas d’E/S de l’hôte. En
outre, le temps nécessaire pour initialiser la capacité nouvellement ajoutée dépend des performances de la baie
d’hébergement des volumes de stockage. Toutefois, les performances attendues sont toujours plus rapides que le
temps nécessaire à la reconstruction d’un volume.
● Sur les périphériques RAID 1 distribués, le processus d’initialisation ne consomme pas la bande passante des données
du WAN, car chaque cluster exécute son initialisation en local.
● Sur les périphériques RAID 1, distribués ou non, Metro Node s’assure que tous les tronçons RAID 1 ont des
informations cohérentes sur l’espace étendu.
● Le niveau de redondance sur les géométries des périphériques RAID 1, distribués ou non, est maintenu par le
processus d’extension et d’initialisation.
● La capacité du volume virtuel nouvellement étendu sera disponible pour utilisation par les hôtes lorsque le processus
d’initialisation sera terminé.
● Si Metro Node a réclamé les volumes de stockage avec provisionnement dynamique, le processus d’initialisation
n’affecte pas le provisionnement sous-jacent de la capacité supplémentaire signalée à Metro Node.
Vérifier l’état de l’extension de volume
Interrogez l’état de votre extension de volume en répertoriant la valeur des attributs suivants dans le contexte virtual-volumes.
● expansion-status - État de l’extension du volume virtuel. Indique si l’extension d’un volume virtuel est en cours ou a échoué.
L’attribut aura l’une des valeurs suivantes :
○ in-progress - L’extension est en cours.
○ failed - L’extension en cours la plus récente a échoué et l’extension doit être retentée. Si l’extension n’est pas retentée, cet état
persiste jusqu’à deux jours. Si le problème n’est pas résolu après deux jours, l’état d’échec disparaît et le volume est supposé résolu.
○ inconnu : l’état ne peut pas être déterminé. Cela peut être dû à une erreur de communication ou à une erreur de programmation
interne.
○ - (tiret) : aucun des états ci-dessus n’est applicable.
Extension de volume
37
● expansion-summary - S’il n’y a pas d’extensions en cours ou en échec, et aucun volume virtuel avec une capacité d’extension non
nulle, la commande de récapitulatif de volume virtuel affiche No expansion activity dans le récapitulatif d’extension.
Limitations
Les éléments suivants constituent des limitations générales à l’extension de volumes virtuels.
Certains volumes virtuels ne peuvent être étendus dans des circonstances spécifiques. Les volumes ne peuvent être étendus si l’une des
conditions suivantes est vraie :
● Une migration ou une reconstruction est en cours : l’extension est bloquée lors des migrations et des reconstructions.
○ Si vous reconstruisez des volumes, attendez que la reconstruction soit terminée avant de tenter une extension.
○ Si vous migrez des données, attendez que la migration se termine. Vous pouvez également annuler ou valider la migration, puis
effectuer l’extension.
● Mise à niveau en cours : l’extension de volume est bloquée lors de la mise à niveau sans perturbation (NDU).
● health-check La commande signale des problèmes : la commande health-check renvoie des problèmes concernant le cluster,
les volumes de stockage ou le volume virtuel en cours d’extension.
● Le volume est un volume de métadonnées : les volumes de métadonnées ne peuvent pas être étendus.
Restrictions relatives à l’extension de volume de stockage
Les restrictions suivantes s’appliquent à la méthode d’extension du volume de stockage :
● Pour les volumes virtuels basés sur des appareils RAID 1 ou RAID 1 distribués, jusqu’à 1 000 processus d’initialisation peuvent s’exécuter
simultanément par cluster. Si cette limite est atteinte sur un cluster, aucune nouvelle extension ne peut être démarrée sur les volumes
virtuels avec ces géométries tant que certains des processus d’initialisation précédemment démarrés n’ont pas été terminés sur ce
cluster.
Les volumes virtuels qui ne contiennent pas d’appareils RAID 1 ou RAID 1 distribués ne sont pas concernés par cette limite.
Dépannage et indication d’intégrité
Lorsqu’une extension de volume échoue, les informations sur les causes de l’échec sont ajoutées à l’attribut health indications.
Lorsqu’une extension échoue, elle ne dégrade pas l’intégrité globale, l’état opérationnel ou l’état des services d’un volume virtuel.
La section de Dépannage Metro Node de SolVe Desktop contient les procédures de récupération suite à une erreur avec les extensions de
volume.
Nouvelle détection de la baie
Vous devrez peut-être détecter de nouveau la baie après l’extension. En fonction du type et de la configuration de la baie back-end, la baie
de stockage peut ne pas supporter la détection automatique par Metro Node.
Bonnes pratiques
Si Metro Node ne détecte pas automatiquement la modification du volume de stockage, utilisez la commande array-rediscover pour
forcer Metro Node à reconnaître l’extension back-end.
Si vous effectuez plusieurs extensions de volume de stockage sur la baie, terminez toutes les extensions de volume de stockage et
détectez de nouveau la baie une seule fois pour forcer Metro Node à détecter toutes les extensions.
Certaines baies nécessitent des paramètres système spécifiques pour permettre le support de la détection automatique.
Pour connaître les procédures de configuration des baies de stockage pour Metro Node, reportez-vous à SolVe Desktop.
REMARQUE : Passez en revue les pratiques d’excellence applicables en matière de connectivité et de configuration des hôtes et des
baies sur SolVe Desktop. Certaines baies nécessitent des paramètres de détection automatique spécifiques.
PRÉCAUTION : Les nouvelles détections de baies peuvent consommer un nombre excessif de ressources et entraîner la
perturbation des E/S. Lancez une nouvelle détection des baies uniquement lorsque cela est nécessaire.
38
Extension de volume
7
Migration des données
Ce chapitre décrit les migrations et les reconstructions de données.
Sujets :
•
•
•
•
•
À propos de la migration des données
Migration de stockage compatible avec le provisionnement dynamique
À propos des reconstructions
Migration ponctuelle des données
Migrations par lot
À propos de la migration des données
Il existe deux types de migrations des données :
● Les migrations ponctuelles : vous pouvez lancer immédiatement une migration de périphériques en utilisant la commandedm
migration start.
● Les migrations par lot : elles s’exécutent en tant que tâches par lot via des fichiers de plan de migration réutilisables. Vous pouvez
exécuter plusieurs migrations de périphériques ou d’extensions à l’aide d’une seule commande.
Migrations ponctuelles
Les migrations ponctuelles comprennent ce qui suit :
● Migrations de périphériques : les périphériques sont mappés 1-à-1, sont de type RAID 1, ou sont créés sur des extensions ou sur
d’autres périphériques.
Les migrations de périphériques permettent de déplacer les données entre les périphériques d’un même cluster ou entre les
périphériques de clusters différents. Utilisez les migrations de périphériques pour :
○ migrer des données entre baies dissemblables.
○ réaffecter un volume à chaud sur une baie plus rapide.
○ réaffecter des périphériques sur de nouvelles baies dans un cluster différent.
Limitations
● Les migrations de périphériques entre périphériques distribués ne sont pas supportées.
● Les périphériques doivent être supprimés des groupes de cohérence pour pouvoir être migrés entre des clusters.
Migrations par lot
Les migrations par lot permettent de migrer plusieurs périphériques. Créez des migrations par lot pour automatiser les tâches de routine :
● Utilisez les migrations de périphériques par lot pour effectuer une migration vers des baies dissemblables (vous devez configurer les
capacités de la destination de sorte à correspondre à la capacité et au niveau de la baie source) et pour migrer les périphériques entre
les clusters d’un Metro Node Metro.
jusqu’à 25 migrations locales et 25 migrations distribuées peuvent être effectuées simultanément. Toute migration dépassant ces limites
est mise en file d’attente jusqu’à ce qu’une migration se termine.
REMARQUE : Les périphériques doivent être supprimés des groupes de cohérence pour pouvoir être migrés entre des clusters.
Migration des données
39
Procédure générale de migration des données
Pour effectuer des migrations de périphériques, suivez les étapes générales ci-dessous :
1. Créez et vérifiez un plan de migration (migrations par lot uniquement).
2. Démarrez une migration.
3. Surveillez le processus de migration des données.
4. Interrompez, reprenez ou annulez la migration (facultatif).
5. Validez la migration. L’opération de validation transfère le volume virtuel source du périphérique vers la cible.
Si le volume virtuel d’un périphérique possède un nom par défaut attribué par le système, la validation d’une migration de périphériques
renomme le volume virtuel après le périphérique cible.
6. Supprimez l’enregistrement de la migration.
Conditions préalables pour les périphériques cibles
Le périphérique cible doit :
● être de taille égale ou supérieure à celle du périphérique source.
Si la taille de la cible est supérieure à celle de la source, vous pouvez utiliser l’espace supplémentaire avec l’extension de volume de
stockage, lorsque toutes les conditions préalables à l’extension de volume de stockage sont remplies.
Par exemple, si la source dispose d’une capacité de 200 Go et la cible de 500 Go, seuls 200 Go de la cible peuvent être utilisés après
une migration. Les 300 Go restants peuvent être revendiqués en effectuant une extension de volume de stockage, lorsque celle-ci est
supportée par le volume virtuel.
● ne comporter aucun volume existant.
AVERTISSEMENT : Les migrations de périphériques ne sont pas recommandées entre clusters. Toutes les migrations
de périphériques sont synchrones. S’il existe des E/S vers les périphériques en cours de migration et que la latence
vers le cluster cible est supérieure ou égale à 5 ms, une dégradation importante des performances peut se produire.
Migration de stockage compatible avec le
provisionnement dynamique
Le tableau suivant décrit les scénarios de migration supportés et l’état des volumes virtuels avant, pendant et après la migration.
Tableau 5. Scénarios de migration
Migration
État du volume virtuel avant
la migration
État du volume virtuel lors de État du volume virtuel après
la migration
la migration
Statique-vers-dynamique
Thin-capable = false
Thin-capable = false
Thin-capable = true
Thin-enabled = unavailable
Thin-enabled = unavailable
Thin-enabled = disabled
UNMAP rejetée
UNMAP rejetée
UNMAP rejetée
REMARQUE : Vous devez
définir la valeur thin-enabled
sur true avant le traitement
de la commande UNMAP.
Thin-capable = true
Thin-capable = true
Thin-capable = true
Thin-enabled = enabled
Thin-enabled = enabled
Thin-enabled = enabled
UNMAP traitée
UNMAP traitée
UNMAP traitée
Thin-capable = true
Thin-capable = false
UNMAP rejetée
Thin-enabled = enabled
Thin-enabled = enabled
UNMAP rejetée
Dynamique-vers-dynamique
(volume virtuel à
provisionnement dynamique)
Dynamique-vers-dynamique
(famille de baies de stockage
mixtes)
40
Migration des données
Tableau 5. Scénarios de migration (suite)
Migration
État du volume virtuel avant
la migration
État du volume virtuel lors de État du volume virtuel après
la migration
la migration
Dynamique-vers-dynamique
(volume virtuel sans
provisionnement dynamique)
Thin-capable = true
Thin-capable = true
Thin-capable = true
Thin-enabled = disabled
Thin-enabled = disabled
Thin-enabled = disabled
UNMAP rejetée
UNMAP rejetée
UNMAP rejetée
REMARQUE : Dans ce
cas, la commande UNMAP
est intentionnellement
désactivée.
Thin-capable = true
Thin-capable = false
Thin-capable = false
Thin-enabled = enabled
Thin-enabled = enabled
Thin-enabled = unavailable
UNMAP traitée
UNMAP rejetée
UNMAP rejetée
Thin-capable = true
Thin-capable = false
Thin-capable = false
Thin-enabled = disabled
Thin-enabled = unavailable
Thin-enabled = unavailable
UNMAP rejetée
UNMAP rejetée
UNMAP rejetée
Dynamique-vers-statique
(volume virtuel à
provisionnement dynamique)
Dynamique-vers-statique
(volume virtuel sans
provisionnement dynamique)
REMARQUE :
● Lors de la migration, un miroir temporaire est créé pour déplacer les données de la source vers la cible de la migration. Metro Node
traite les commandes UNMAP uniquement lorsque les attributs thin-capablethin-enabled sont définis sur true sur le
volume virtuel.
● Si la cible de la migration est un périphérique compatible avec le provisionnement dynamique d’une capacité supérieure à celle
du périphérique source, les volumes virtuels Metro Node continuent d’être compatibles avec le provisionnement dynamique et
conservent la propriété thin-enabled précédemment provisionnée une fois la migration terminée. Pour utiliser la capacité inutilisée,
utilisez la commande virtual-volume expand.
Lors de la migration d’un périphérique à provisionnement dynamique vers un périphérique sans provisionnement dynamique
(périphérique statique, par exemple), l’attribut thin-enabled du volume reste enabled, même si la commande UNMAP est rejetée
lors de la migration. Une fois la migration réussie, l’attribut thin-enabled devient unavailable, car le périphérique cible est statique.
Ce comportement est ainsi prévu, car le volume redevient un volume dynamique lorsque la migration est abandonnée ou échoue.
Lors de l’exécution de migrations ponctuelles, tenez compte des points suivants :
● Pour une extension ou une migration de périphériques (avec volume virtuel supporté) dynamique-vers-statique, si la source est
compatible avec le provisionnement dynamique et que la cible ne l’est pas, les volumes virtuels supportés ne sont ni à provisionnement
dynamique, ni compatibles avec le provisionnement dynamique après la migration.
VPlexcli:/clusters/cluster-1/devices> dm migration start --paused --name my_migration -from thin_source
--to device_thick_1
The source 'thin_source' is thin-capable but the target 'device_thick_1' is not thincapable. The
virtual-volume 'thin_source_vol' will not be thin-enabled or thin-capable after migration.
Do you wish to proceed? (Yes/No) no
dm migration start: Evaluation of <<dm migration start --paused --name my_migration -from thin_source/
--to device_thick_1_c1/>> failed.
cause:
Failed to create a new data-migration.
cause:
Operation was halted by the user
VPlexcli:/clusters/cluster-1/devices>
VPlexcli:/clusters/cluster-1/storage-elements/extents> dm migration start --paused --name
my_migration
--from thin_extent_1 --to thick_extent_1
The source 'thin_extent_1' is thin-capable but the target 'thick_extent_1' is not thincapable.
The virtual-volume 'thin_source_vol' will not be thin-enabled or thin-capable after
Migration des données
41
migration.
Do you wish to proceed? (Yes/No) no
dm migration start: Evaluation of <<dm migration start --paused --name my_migration -from extent_20
--to extent_31>> failed.
cause:
Failed to create a new data-migration.
cause:
Operation was halted by the user
VPlexcli:/clusters/cluster-1/storage-elements/extents>
● Pour une migration d’extension dynamique-vers-statique (sans volume virtuel supporté), si la source est compatible avec le
provisionnement dynamique et que la cible ne l’est pas, la source perd sa fonctionnalité dynamique après la migration.
VPlexcli:/clusters/cluster-1/storage-elements/extents> dm migration start --paused --name
my_migration
--from thin_extent_2 --to thick_extent_1
The source 'thin_extent_2' is thin-capable but the target 'thick_extent_1' is not thincapable.
Thin-capability will be lost after migration. Do you wish to proceed? (Yes/No) no
dm migration start: Evaluation of <<dm migration start --paused --name my_migration -from extent_21
--to extent_31>> failed.
cause:
Failed to create a new data-migration.
cause:
Operation was halted by the user
VPlexcli:/clusters/cluster-1/storage-elements/extents>
Lors de la validation de migrations ponctuelles, tenez compte des points suivants :
● Pour une migration de périphériques dynamique-vers-statique, l’interface CLI Metro Node affiche un message qui indique que les
propriétés dynamiques du volume virtuel sont désactivées.
VPlexcli:/data-migrations/extent-migrations> dm migration commit my_migration --force
The virtual-volume 'my_vol' is no longer thin-capable and will not be thin-enabled after
migration 'my_migration' is committed.
Committed 1 data migration(s) out of 1 requested migration(s).
VPlexcli:/data-migrations/extent-migrations>
● Pour une extension ou une migration de périphériques (avec volume virtuel supporté) dynamique-vers-dynamique, si la valeur thinenabled est définie sur false, il n’y a aucun changement après la validation de la migration.
VPlexcli:/data-migrations/extent-migrations> dm migration commit my_migration2 --force
Committed 1 data migration(s) out of 1 requested migration(s).
VPlexcli:/data-migrations/extent-migrations>
● Pour une migration de périphériques dynamique-vers-dynamique (avec volume virtuel supporté), si la valeur thin-enabled est définie
sur true, le volume virtuel reste à provisionnement dynamique après la validation de la migration.
Lors de l’exécution et de la validation de migrations par lot, tenez compte des points suivants :
● Pour une extension ou une migration de périphériques dynamique-vers-statique dans le cadre de la phase du plan de vérification,
l’interface CLI Metro Node affiche un avertissement qui indique que les volumes virtuels ne sont ni à provisionnement dynamique, ni
compatibles avec le provisionnement dynamique après la migration.
VPlexcli:/> batch-migrate create-plan --file migration.txt --sources device_thin_1,
device_thin_2
--targets device_thick_1, device_thick_2
Extents matching source pattern: device_thin_1, device_thin_2
Extents matching target pattern: device_thick_2, device_thick_1
Creating file /var/log/VPlex/cli/migration.txt as migration plan file.
Wrote file /var/log/VPlex/cli/migration.txt. Please review and edit this file, and run
this command
in the check-plan phase afterward.
VPlexcli:/> batch-migrate check-plan --file /var/log/VPlex/cli/migration.txt
Checking migration plan file /var/log/VPlex/cli/migration.txt.
WARNING: The source 'device_thin_1' is thin-capable but the target 'device_thick_1' is not
thin-capable.
The virtual-volume 'thin_1' will not be thin-enabled or thin-capable after migration.
42
Migration des données
WARNING: The source 'device_thin_2' is thin-capable but the target 'device_thick_2' is not
thin-capable.
The virtual-volume 'thin_2' will not be thin-enabled or thin-capable after migration.
Plan-check passed with 2 warnings.
VPlexcli:/>
● Pour une migration d’extension dynamique-vers-statique (sans volume virtuel supporté), l’interface CLI Metro Node affiche un
avertissement qui indique que la source perd sa fonctionnalité dynamique après la migration.
VPlexcli:/> batch-migrate create-plan --file migration.txt --sources extent_thin_1,
extent_thin_2
--targets extent_thick_1, extent_thick_2
Extents matching source pattern: extent_thin_1, extent_thin_2
Extents matching target pattern: extent_thick_2, extent_thick_1
Creating file /var/log/VPlex/cli/migration.txt as migration plan file.
Wrote file /var/log/VPlex/cli/migration.txt. Please review and edit this file, and run
this command
in the check-plan phase afterward.
VPlexcli:/> batch-migrate check-plan --file /var/log/VPlex/cli/migration.txt
Checking migration plan file /var/log/VPlex/cli/migration.txt.
WARNING: The source 'device_thin_1' is thin-capable but the target 'device_thick_1' is not
thin-capable.
Thin-capability will be lost after migration.
WARNING: The source 'device_thin_2' is thin-capable but the target 'device_thick_2' is not
thin-capable.
Thin-capability will be lost after migration.
Plan-check passed with 2 warnings.
VPlexcli:/>
● Dans le cas de plusieurs migrations dynamique-vers-statique, l’interface CLI Metro Node crée un rapport signalant les problèmes de
migration au travers de plusieurs avertissements. L’exemple suivant représente deux migrations dynamique-vers-statique, dont une
migration ne comporte pas de volumes virtuels.
VPlexcli:/> batch-migrate check-plan --file /var/log/VPlex/cli/migration.txt
Checking migration plan file /var/log/VPlex/cli/migration.txt.
WARNING: The source 'device_thin_1' is thin-capable but the target 'device_thick_1' is not
thin-capable.
The virtual-volume 'thin_1' will not be thin-enabled or thin-capable after migration.
PROBLEM: Source device '/clusters/cluster-1/devices/device_thin_2' does not have a volume.
WARNING: The source 'device_thin_2' is thin-capable but the target 'device_thick_2' is not
thin-capable.
Thin-capability will be lost after migration.
Plan-check failed with 1 problem and 2 warnings.
● Pour une migration de périphériques dynamique-vers-statique et statique-vers-dynamique simultanée, le volume virtuel n’est ni à
provisionnement dynamique, ni compatible avec le provisionnement dynamique après la validation de la migration par lot.
Tableau 6. Migration dynamique-vers-statique et statique-vers-dynamique simultanée
Migration
Source
Cible
Volume
BR0_0
device_thick_4
device_thin_4
source_thick
BR0_1
device_thin_5
device_thick_3
source_thin
VPlexcli:/> batch-migrate commit --file /var/log/VPlex/cli/migrate.txt
The virtual-volume 'source_thin' is no longer thin-capable and will not be thin-enabled
after
migration 'BR0_1' is committed.
Migration des données
43
Committed 2 of 2 migrations
VPlexcli:/>
À propos des reconstructions
La reconstruction permet de synchroniser les données d’un disque source vers un disque cible. Lorsque des différences surviennent entre
les tronçons d’un RAID, la reconstruction permet de mettre à jour le tronçon obsolète.
Il existe deux types de comportements de reconstruction :
● Une reconstruction complète copie l’intégralité du contenu de la source vers la cible.
● Une reconstruction de journalisation copie uniquement les blocs modifiés de la source vers la cible.
Les miroirs locaux sont mis avec une reconstruction complète (les périphériques locaux n’utilisent pas les volumes de journalisation).
Dans les configurations Metro Node, tous les périphériques distribués disposent d’un volume de journalisation associé. Les volumes de
journalisation gardent une trace des blocs écrits lors d’une panne de liaison intercluster. Après la restauration d’une liaison ou d’un tronçon,
le système Metro Node utilise les informations des volumes de journalisation pour synchroniser les miroirs en envoyant uniquement les
blocs modifiés sur la liaison.
Les reconstructions de volume de journalisation se produisent également lorsqu’un tronçon d’un RAID 1 distribué devient inaccessible, mais
se restaure rapidement.
Si un volume de journalisation n’est pas disponible au moment où un tronçon est planifié pour être marqué comme obsolète, le tronçon est
marqué comme entièrement obsolète, ce qui provoque une reconstruction complète.
L’indisponibilité d’un volume de journalisation est importante au moment de la récupération (lorsque le système lit le volume de
journalisation) et au moment où une écriture échoue sur un tronçon et aboutit sur un autre (lorsque le système commence à écrire
sur le volume de journalisation).
PRÉCAUTION : Si aucun volume de journalisation n’est disponible, une restauration de liaison intercluster entraîne une
reconstruction complète de tous les périphériques distribués sur lesquels il y a eu des écritures alors que la liaison a été
interrompue.
Reportez-vous à la section Journalisation.
Reconstructions pour le stockage à provisionnement dynamique
Le provisionnement dynamique permet au stockage de migrer vers un volume de stockage à provisionnement dynamique, et d’allouer une
capacité de pool de stockage dynamique minimale.
Les volumes de stockage à provisionnement dynamique peuvent être intégrés à des miroirs RAID 1 avec une consommation similaire à la
capacité du pool de stockage dynamique.
Metro Node conserve l’espace du thin pool non alloué du volume de stockage cible de différentes manières, en fonction de la compatibilité
ou non du volume cible avec le provisionnement dynamique. Pour les volumes compatibles avec le provisionnement dynamique, si le
tronçon source indique des données mises à zéro, Metro Node émet une commande UNMAP pour ces blocs sur les volumes cibles.
Pour les tronçons cibles non compatibles avec le provisionnement dynamique, Metro Node vérifie le contenu des données mises à
zéro avant écriture, puis supprime l’écriture à l’endroit où elle risque de causer un provisionnement inutile. Pour que cet algorithme de
reconstruction dynamique soit sélectionné, Metro Node définit automatiquement la balise thin-rebuild sur les volumes compatibles
avec le provisionnement dynamique dans le cadre du processus de revendication. Si les volumes de stockage ne sont pas supportés
comme étant compatibles avec le provisionnement dynamique, l’administrateur Metro Node définit une troisième propriété, l’attribut
thin-rebuild défini sur true, pendant ou après la revendication de stockage.
REMARQUE : Lors de la revendication d’un volume de stockage, Metro Node définit automatiquement la balise thin-rebuild sur
true pour les baies compatibles avec le provisionnement dynamique. Metro Node ne réalise pas cette opération sur les volumes de
stockage dynamique qui sont déjà revendiqués avec la balise définie sur false.
Metro Node permet de modifier la valeur thin-rebuild des volumes de stockage, que ceux-ci soient compatibles avec le provisionnement
dynamique ou non. Pour les volumes de stockage compatibles avec le provisionnement dynamique, si vous tentez de définir la propriété
thin-rebuild sur false, l’interface CLI Metro Node affiche un avertissement. Dans un scénario où l’ensemble du contenu de la source est
écrit sur la cible, les performances peuvent être meilleures que celles d’une reconstruction normale si :
● Les volumes de stockage ne sont pas compatibles avec le provisionnement dynamique.
● Le contenu de la source et de la cible de la reconstruction est presque identique.
● Seules les données différentes sont écrites au cours du processus de reconstruction dynamique.
44
Migration des données
La propriété de provisionnement dynamique détectée pour les volumes de stockage permet de créer des volumes virtuels Metro Node
compatibles avec le provisionnement dynamique sur lesquels les hôtes peuvent envoyer des commandes de suppression de mappages
pour libérer les blocs inutilisés. Toutefois, la propriété thin-rebuild configurée contrôle la synchronisation des miroirs qui s’exécute sur le
back-end Metro Node.
Le support dynamique de Metro Node fournit plus d’informations sur les fonctionnalités de provisionnement dynamique de Metro Node.
PRÉCAUTION : Si un volume de stockage à provisionnement dynamique contient des données différentes de zéro
avant d’être connecté à Metro Node, les performances de la migration ou de la reconstruction RAID 1 initiale en sont
affectées. Si le pool d’allocation du stockage dynamique manque d’espace et s’il s’agit du dernier tronçon redondant du
RAID 1, le volume perd l’accès au périphérique en cas d’écriture supplémentaire sur un périphérique à provisionnement
dynamique. Ce problème peut causer une indisponibilité des données.
Considérations relatives aux performances
Pour améliorer les performances globales de Metro Node, désactivez la reconstruction automatique ou modifiez la taille de transfert de
reconstruction :
● Désactivez la reconstruction automatique pour éviter une surcharge d’activités lors de la reconnexion de deux clusters.
PRÉCAUTION : La désactivation de la reconstruction automatique empêche la synchronisation du RAID 1 distribué.
Les périphériques enfants sont obsolètes, ce qui augmente la probabilité de lectures distantes.
● Modifiez la taille de transfert de reconstruction. Pour plus d’informations, reportez-vous à la section À propos de la taille de transfert.
Migration ponctuelle des données
Une ponctuelle migration des données permet de déplacer les données entre la source et la cible spécifiées dès que vous utilisez la
commande dm start migration. Aucun fichier de plan de migration réutilisable n’est créé comme pour les migrations par lot.
Démarrage d’une migration de périphériques ponctuelle
Étapes
1. Utilisez la commande drill down pour afficher les composants de la source d’une vue, d’un volume virtuel ou d’un périphérique,
jusqu’au niveau du volume de stockage :
VPlexcli:/clusters/cluster-1> drill-down –o virtual-volumes/Symm1254_7B7_1_vol
virtual-volume: Symm1254_7B7_1_vol (cluster-1)
local-device: Symm1254_7B7_1 (cluster-1)
extent: extent_Symm1254_7B7_1
storage-volume: Symm1254_7B7
2. Identifiez le périphérique utilisé par le volume de stockage source.
3. Utilisez la commande ll /clusters/cluster-*/devices pour afficher les périphériques disponibles.
4. Identifiez un périphérique inutilisé en tant que destination.
5. Accédez au contexte de migration qui convient.
Pour les migrations de périphériques, accédez au contexte device-migration :
VPlexcli:/> cd data-migrations/device-migrations
6. Utilisez la commandedm migration start pour démarrer une migration.
Spécifiez le périphérique --to par un nom si celui-ci est unique dans l’espace de nommage global. Dans le cas contraire, spécifiez un
chemin d’accès complet.
Par exemple :
VPlexcli:/data-migrations/device-migrations> dm migration start --name migrate_012 --from
device_012 --to device_012a --transfer-size 12M
Migration des données
45
PRÉCAUTION : La définition d’une taille de transfert élevée peut entraîner une indisponibilité des données. Ne
modifiez la valeur par défaut que lorsque l’impact sur les performances est parfaitement appréhendé.
Si l’activité des E/S de l’hôte est élevée, la définition d’une taille de transfert élevée peut avoir un impact sur les E/S
de l’hôte.
Reportez-vous à la section À propos de la taille de transfert.
Surveillance de la progression de la migration
Utilisez la commande ls pour afficher l’état de la migration.
À propos de cette tâche
VPlexcli:/> ls data-migrations/device-migrations/ migrate_012
Name
Value
--------------- ---------------------------from-cluster
cluster-1
percentage-done 10
source
device_012
source-exported false
start-time
Fri May 28 13:32:23 MDT 2010
status
in progress
target
device_012a
target-exported false
to-cluster
cluster-2
transfer-size
12M
type
full
Tableau 7. États de migration
Champ
Description
from-cluster
ID de cluster du périphérique source, ou des périphériques du groupe de cohérence.
percentage-done
Pourcentage d’achèvement de la migration. 100 % si la migration est terminée ou a été validée.
source
Périphérique source.
source-exported
Indique si le périphérique source a été exporté lors de la migration. S’applique si la migration
est une migration de périphériques intercluster et si le périphérique n’a pas déjà été exporté.
Les périphériques sont exportés vers un cluster distant pour les rendre visibles sur ce cluster
et peuvent être utilisés en tant que tronçon dans un RAID 1 distribué temporaire lors de la
migration.
● false – Le périphérique source n’a pas été exporté.
● true – Le périphérique source a été exporté.
start-time
Date et heure de début de la migration.
status
État de la migration.
● ready– La migration est prête.
● queued– La migration est en file d’attente.
● in-progress– La migration est en cours.
● paused– La migration est suspendue.
● Commit Pending– La migration est terminée (mais pas validée).
● committed– La migration est validée.
● Partially-committed– L’opération de validation a échoué.
● error– Condition d’erreur, y compris source ou cible inaccessible.
● cancelled– La migration est annulée.
● partially-cancelled – Échec de la tentative d’annulation de la migration. Renouvelez
l’annulation.
target
Périphérique de destination.
46
Migration des données
Tableau 7. États de migration (suite)
Champ
Description
target-exported
Indique si le périphérique cible a été exporté lors de la migration.
● false – Le périphérique cible n’a pas été exporté.
● true – Le périphérique cible a été exporté.
to-cluster
ID de cluster du périphérique de destination.
transfer-size
Taille de la région du cache utilisée pour réaliser la migration. 40 Ko - 128 Mo.
type
Type de reconstruction.
● full – Copie l’intégralité du contenu de la source vers la cible.
● logging – Copie uniquement les blocs modifiés de la source vers la cible.
Pause/reprise d’une migration (en option)
Les migrations actives (une migration qui a été démarrée) peuvent être suspendues et redémarrées ultérieurement.
À propos de cette tâche
Suspendez une migration active pour libérer la bande passante des E/S de l’hôte pendant les périodes de trafic maximal.
Utilisez la commande dm migration pause --migrations pour suspendre une migration.
Spécifiez le nom-de-migration avec un nom, si celui-ci est unique dans l’espace de nommage global. Dans le cas contraire, spécifiez un
chemin d’accès complet.
Par exemple :
● Suspendez la migration d’un appareil :
VPlexcli:/data-migrations/device-migrations> dm migration pause --migrations migrate_012
Utilisez la commande dm migration resume --migrations pour reprendre une migration.
Spécifiez le nom-de-migration avec un nom, si celui-ci est unique dans l’espace de nommage global. Dans le cas contraire, spécifiez un
chemin d’accès complet.
Par exemple :
● Reprenez une migration d’appareil suspendue :
VPlexcli:/data-migrations/device-migrations> dm migration resume --migrations migrate_012
Annulation d’une migration (en option)
Les migrations peuvent être annulées dans les cas suivants :
À propos de cette tâche
● La migration est en cours ou suspendue. La migration est arrêtée et les ressources qu’elle utilisait sont libérées.
● La migration n’a pas été validée. Les périphériques source et cible sont renvoyés à leur état antérieur à la migration.
Utilisez la commande dm migration cancel --force --migrations pour annuler une migration.
Spécifiez le nom-de-migration avec un nom, si celui-ci est unique dans l’espace de nommage global. Dans le cas contraire, spécifiez un
chemin d’accès complet.
Par exemple :
VPlexcli:/data-migrations/device-migrations> dm migration cancel --force --migrations
migrate_012
Migration des données
47
Validation d’une migration terminée
Le processus de migration insère une structure RAID 1 temporaire au-dessus du périphérique source avec la cible en tant que tronçon
obsolète du RAID 1. La migration peut être interprétée comme la synchronisation du tronçon obsolète (la cible).
À propos de cette tâche
Une fois la migration terminée, l’étape de validation déconnecte le tronçon source du RAID 1, et supprime le RAID 1.
Le volume virtuel, ou le périphérique, est identique à celui de la migration, sauf que le périphérique source est remplacé par le périphérique
cible.
Une migration doit être validée pour être nettoyée.
PRÉCAUTION : Assurez-vous que la migration s’est correctement terminée avant de valider la migration.
Utilisez la commande DM migrations commit --force --migrations nom-migration pour valider une migration.
REMARQUE : Vous devez utiliser l’option --force pour valider une migration.
Par exemple :
● Validation de la migration d’un périphérique :
VPlexcli:/data-migrations/device-migrations> dm migration commit --force --migrations
migrate_012
Committed 1 data migration(s) out of 1 requested migration(s).
Nettoyage d’une migration
Pour les migrations de périphériques, le nettoyage démantèle le périphérique source vers ses volumes de stockage. Les volumes de
stockage qui ne sont plus utilisés ne sont pas revendiqués.
Pour les migrations de périphériques uniquement, utilisez l’argument --rename-target pour renommer le périphérique cible après le
périphérique source. Si le périphérique cible est renommé, le volume virtuel qui s’y trouve est également renommé si le volume virtuel
possède un nom par défaut attribué par le système.
Sans l’attribution d’un nouveau nom, les périphériques cibles conservent leurs noms cibles, ce qui peut rendre la relation entre le volume et
le périphérique moins évidente.
Utilisez la commande dm migration clean --force --migrations nom-migration pour nettoyer une migration.
Spécifiez le nom-de-migration avec un nom, si celui-ci est unique dans l’espace de nommage global. Dans le cas contraire, spécifiez un
chemin d’accès complet.
Par exemple :
VPlexcli:/data-migrations/device-migrations> dm migration clean --force --migrations
migrate_012
Cleaned 1 data migration(s) out of 1 requested migration(s).
Suppression des enregistrements de migration
À propos de cette tâche
REMARQUE : Les migrations doivent être annulées ou validées pour pouvoir être supprimées.
Utilisez la commande dm migration remove --force --migrations nom-migration pour supprimer les enregistrements de la
migration.
Spécifiez le nom-de-migration avec un nom, si celui-ci est unique dans l’espace de nommage global. Dans le cas contraire, spécifiez un
chemin d’accès complet.
48
Migration des données
Par exemple :
VPlexcli:/data-migrations/device-migrations> dm migration remove --force --migrations
migrate_012
Removed 1 data migration(s) out of 1 requested migration(s).
Migrations par lot
Les migrations par lot s’exécutent en tant que tâches par lot à partir de fichiers de plan de migration par lot réutilisables. Les fichiers de
plan de migration sont créés avec la commande create-plan.
Un plan de migration par lot unique peut concerner les périphériques.
REMARQUE : Les migrations consomment des ressources de cache. L’exécution simultanée de plusieurs migrations peut avoir un
impact sur les E/S de l’hôte.
Utilisez les migrations par lot pour :
● Procéder au retrait des baies de stockage (baies hors location) et en mettre de nouvelles en ligne.
● Migrer les périphériques vers une autre classe de baies de stockage.
Les étapes de migration par lot sont généralement identiques à celles décrites à la section Procédure générale de migration des données.
Il existe deux étapes supplémentaires pour préparer une migration par lot :
1. Créer un fichier de plan de migration par lot (avec la commande batch-migrate create-plan)
2. Tester le fichier de plan de migration par lot (avec la commande batch-migrate check-plan)
Conditions préalables
Les conditions préalables suivantes sont obligatoires pour les migrations par lot :
● La source et les cibles sont deux périphériques.
● Les périphériques locaux doivent être configurés (migrations de périphériques) sur la baie cible.
● La structure de la cible est identique à la structure de la source.
Création d’un plan de migration par lot
La commande batch-migrate create-plan crée un plan de migration à l’aide des sources et des cibles spécifiées.
À propos de cette tâche
Dans l’exemple suivant, la commande batch-migrate create-plan crée une migration par lot nommée « MigDev-test.txt » pour :
● Migrer deux appareils du cluster-1 vers deux appareils dans le cluster-2.
● Écraser un plan existant portant le même nom.
VPlexcli:/> batch-migrate create-plan --file MigDev-test.txt --sources /clusters/
cluster-1/devices/base0,/clusters/cluster-1/devices/base1 --targets /clusters/cluster-2/
devices/dev1723_618, /clusters/cluster-2/devices/dev1723_61C --force
Extents matching source pattern: base0, base1
Extents matching target pattern: dev1723_61C, dev1723_618
Creating file /var/log/VPlex/cli/MigDev-test.txt as migration plan file.
Wrote file /var/log/VPlex/cli/MigDev-test.txt. Please review and edit this file, and run
this command in the check-plan phase afterward.
Dans l’exemple suivant, la commande batch-migrate create-plan crée une migration par lot pour migrer tous les appareils du
cluster-1 vers le cluster-2.
VPlexcli:/> batch-migrate create-plan migrate.txt --sources /clusters/cluster-1/devices/* -targets /clusters/cluster-2/devices/*
Migration des données
49
Vérification d’un plan de migration par lot
La commande batch-migrate check-plan vérifie le plan de migration par lot spécifié pour les éléments suivants :
À propos de cette tâche
● Migrations de périphériques :
○ Le périphérique cible ne dispose d’aucun volume.
○ Le périphérique source dispose de volumes.
Si le plan de migration contient des erreurs, une description des erreurs s’affiche et la vérification du plan échoue. Par exemple :
VPlexcli:/> batch-migrate check-plan --file MigDev-test.txt
Checking migration plan file /var/log/VPlex/cli/MigDev-test.txt.
Target device '/clusters/cluster-2/devices/dev1723_61C' has a volume.
Target device '/clusters/cluster-2/devices/dev1723_618' has a volume.
Plan-check failed, 2 problems.
Suivez les étapes décrites à la section Modification d’un fichier de migration par lot pour corriger le plan.
Répétez la procédure de vérification et de modification jusqu’à ce que la vérification du plan de migration par lot soit validée. Par exemple :
VPlexcli:/> batch-migrate check-plan --file migrate.txt
Checking migration plan file /temp/migration_plans/migrate.txt.
Plan-check passed.
Modification d’un fichier de migration par lot
Pour modifier un fichier de migration par lot, procédez de l’une des façons suivantes :
À propos de cette tâche
● Utilisez la commande batch-migrate create-plan, spécifiez le même nom de fichier et utilisez l’option --force pour
remplacer l’ancien plan par le nouveau.
● Quittez le serveur de gestion, puis accédez à /var/log/VPlex/cli/.
Utilisez un éditeur de texte (vi) pour modifier le fichier et l’enregistrer.
VPlexcli:/> exit
Connection closed by foreign host.
service@ManagementServer:~> cd /var/log/VPlex/cli/
service@ManagementServer:/var/log/VPlex/cli>
REMARQUE : Pour ajouter des commentaires au fichier du plan de migration, ajoutez des lignes commençant par « / ».
Démarrage d’une migration par lot
À propos de la taille de transfert
La taille de transfert correspond à la taille de la région du cache utilisée pour réaliser la migration. Cette zone est globalement verrouillée,
lue à la source et écrite sur la cible.
La taille du transfert peut être aussi petite que 40 Ko ou aussi grande que 128 Mo et doit être un multiple de 4 Ko. La valeur par défaut est
128 Ko.
Une taille de transfert plus élevée se traduit par une meilleure performance de la migration, mais peut avoir un impact négatif sur les E/S
frontales. Cela est particulièrement vrai pour les migrations Metro Node.
Une taille de transfert plus petite se traduit par une plus faible performance de la migration, mais aussi par un impact réduit sur les E/S
frontales et les temps de réponse pour les hôtes.
50
Migration des données
Définissez une taille de transfert élevée pour les migrations lorsque votre priorité est la protection des données ou la performance de la
migration. Définissez une taille de transfert moins élevée pour les migrations lorsque votre priorité est le temps de réponse du stockage
front-end.
Facteurs à prendre en compte lors de la spécification de la taille de transfert :
● Pour les configurations Metro Node Metro avec bande passante intercluster étroite, définissez la taille de transfert sur une valeur
inférieure, afin que la migration n’affecte pas les E/S interclusters.
● La région spécifiée par la taille de transfert est verrouillée lors de la migration. Les E/S de l’hôte vers ou depuis cette région sont
maintenues. Définissez une taille de transfert plus petite au cours des périodes avec nombre élevé d’E/S de l’hôte.
● Lorsqu’une zone de données est transférée, une diffusion est envoyée au système. Une taille de transfert plus petite signifie plus de
diffusions, ce qui ralentit la migration.
Utilisez la commande batch-migrate start pour démarrer la migration par lot spécifiée.
Par exemple :
VPlexcli:/> batch-migrate start --file migrate.txt --transfer-size 2M
Started 4 of 4 migrations.
Pause/reprise d’une migration par lot (en option)
Les migrations par lot actives (une migration qui a été démarrée) peuvent être suspendues et redémarrées.
À propos de cette tâche
Suspendez une migration par lot active pour libérer la bande passante des E/S de l’hôte pendant les périodes de trafic maximal.
Reprenez la migration par lot pendant les périodes d’E/S faibles.
Utilisez la commande batch-migrate pause pour suspendre la migration active spécifiée. Par exemple :
VPlexcli:/data-migrations/device-migrations> batch-migrate pause --file migrate.txt
Utilisez la commande batch-migrate resume pour reprendre la migration suspendue spécifiée. Par exemple :
VPlexcli:/data-migrations/device-migrations> batch-migrate resume --file migrate.txt
Annulation d’une migration par lot (en option)
Annulez une migration par lot active pour ramener les volumes sources à leur état antérieur au début de la migration.
À propos de cette tâche
Utilisez la commande batch-migrate cancel pour annuler la migration spécifiée. Par exemple :
VPlexcli:/data-migrations/device-migrations> batch-migrate cancel --file migrate.txt
REMARQUE : Afin de réexécuter un plan de migration annulé, utilisez la commande batch-migrate remove pour supprimer les
enregistrements de la migration. Voir Suppression des enregistrements de migration par lot.
Surveillance de la progression de la migration par lot
Utilisez la commande batch-migrate summary avec l’option --verbose pour surveiller la progression de la migration par lot
spécifiée :
À propos de cette tâche
Par exemple :
VPlexcli:/data-migrations/device-migrations> batch-migrate summary --file migrate.txt -verbose
Migration des données
51
sourcesource-site
name status
-------------------------------------------- --R20061115_Symm2264_010
1
migrate.txt 100
R20061115_Symm2264_011
1
migrate.txt 100
R20061115_Symm2264_012
1
migrate.txt 100
R20061115_Symm2264_0113 1
1
migrate.txt 27
Processed 4 migrations:
committed:
0
complete:
3
in-progress: 1
paused:
0
error:
0
cancelled:
0
no-record:
0
target
target-cluster migrationpercentage-complete eta.
----------------------------- ------------R20070107_Symm2A10_1B0
1
R20070107_Symm2A10_1B1
1
R20070107_Symm2A10_1B2
1
R20070107_Symm2A10_1B3
4.08min
Affichage de l’état d’une migration par lot
Utilisez la commande batch-migrate summary pour afficher l’état de la migration par lot spécifiée.
À propos de cette tâche
Par exemple :
VPlexcli:/> batch-migrate summary migrate.txt
Processed 10 migrations from batch migration BR0:
committed:
0
complete:
10
in-progress: 0
paused:
0
error:
0
cancelled:
0
no-record:
0
Tableau 8. Récapitulatif de la migration par lot
Champ
Description
Processed...
Sur le nombre de paires source-cible spécifiées dans le plan de migration par lot, celles qui ont
été traitées.
committed
Sur le nombre de paires source-cible qui ont été traitées, celles qui ont été validées.
completed
Sur le nombre de paires source-cible qui ont été traitées, celles qui sont terminées.
in-progress
Sur le nombre de paires source-cible qui ont été traitées, celles qui sont en cours.
paused
Sur le nombre de paires source-cible qui ont été traitées, celles qui sont suspendues.
error
Tâches qui ont rencontré des erreurs lors du traitement.
cancelled
Sur le nombre de paires source-cible qui ont été traitées, celles qui ont été annulées.
no-record
Sur le nombre de paires source-cible qui ont été traitées, celles qui n’ont pas d’enregistrement
dans l’arborescence de contexte.
REMARQUE : Si plus de 25 migrations sont actives en même temps, elles sont mises en file d’attente, leur état est affiché en tant
que in-progress, et percentage-complete affiche « ? ».
52
Migration des données
Validation d’une migration par lot
Le processus de migration insère une structure RAID 1 temporaire au-dessus des périphériques sources, les périphériques cibles étant un
tronçon obsolète du RAID 1. La migration peut être interprétée comme la synchronisation du tronçon obsolète (la cible).
À propos de cette tâche
Une fois la migration terminée, l’étape de validation déconnecte le tronçon source du RAID 1, puis supprime le RAID.
Le volume virtuel, ou le périphérique, est identique à celui de la migration, sauf que le périphérique source est remplacé par le périphérique
cible.
Une migration doit être validée pour pouvoir être nettoyée.
Lorsque la migration par lot est terminée à 100 %, utilisez la commande batch-migrate commit pour répliquer les volumes sur les
périphériques cibles et supprimer les volumes des périphériques sources.
Pour valider une migration par lot, procédez comme suit :
Étapes
1. Utilisez la commande batch-migrate summary pour vérifier que la migration s’est terminée sans erreur.
2. Utilisez la commande batch-migrate commit --file pour valider la migration.
AVERTISSEMENT : L’opération de validation supprime définitivement les volumes des périphériques sources.
Par exemple :
VPlexcli:/> batch-migrate commit --file migrate.txt
Nettoyage d’une migration par lot
Pour les migrations de périphériques, le nettoyage démantèle le périphérique source vers ses volumes de stockage. Les volumes de
stockage qui ne sont plus utilisés ne sont pas revendiqués.
À propos de cette tâche
Pour les migrations de périphériques uniquement, utilisez l’argument --rename-target (en option) pour renommer le périphérique cible
après le périphérique source. Si le périphérique cible est renommé, le volume virtuel qui s’y trouve est également renommé si le volume
virtuel possède un nom par défaut attribué par le système.
Sans l’attribution d’un nouveau nom, les périphériques cibles conservent leurs noms cibles, ce qui peut rendre la relation entre le volume et
le périphérique moins évidente.
Utilisez la commande batch-migrate clean --file pour supprimer la migration par lot spécifiée.
PRÉCAUTION : Cette commande doit être exécutée avant la suppression de la migration par lot. La commande ne
nettoie pas les migrations qui n’ont aucun enregistrement dans l’arborescence de contextes Vplexcli.
Dans l’exemple suivant, les périphériques sources sont démontés vers leurs volumes de stockage ; les périphériques et les volumes cibles
sont renommés après le nom des périphériques sources
VPlexcli:/> batch-migrate clean --rename-targets --file migrate.txt
Using migration plan file /temp/migration_plans/migrate.txt for cleanup phase.
0: Deleted source extent /clusters/cluster-1/devices/R20061115_Symm2264_010, unclaimed
disks Symm2264_010
1: Deleted source extent /clusters/cluster-1/extents/R20061115_Symm2264_011, unclaimed
disks Symm2264_011
2: Deleted source extent /clusters/cluster-1/extents/R20061115_Symm2264_012, unclaimed
disks Symm2264_012
3: Deleted source extent /clusters/cluster-1/extents/R20061115_Symm2264_013, unclaimed
disks Symm2264_013
its
its
its
its
Migration des données
53
Suppression des enregistrements de migration par lot
Ne supprimez l’enregistrement de migration que si la migration a été validée ou annulée.
À propos de cette tâche
Les enregistrements de migration se trouvent dans le contexte /data-migrations/device-migrations.
Utilisez la commande batch-migrate remove --file pour supprimer des enregistrements pour la migration spécifiée.
Par exemple :
VPlexcli:/data-migrations/device-migrations> batch-migrate remove --file migrate.txt
ou :
VPlexcli:> batch-migrate remove /data-migrations/device-migrations --file migrate.txt.
54
Migration des données
8
Configuration du réseau WAN
Les deux ports WAN sur chaque directeur Metro Node prennent en charge deux liaisons interclusters de 10 Gigabits Ethernet. Les
ports WAN sont configurés dans le cadre de l’installation d’un second cluster. Ce chapitre décrit les contextes et les procédures de
l’interface CLI pour modifier la configuration créée lors de l’installation.
Sujets :
•
•
•
•
•
Matériel et ports WAN Metro Node
Règles de configuration des ports WAN Metro over IP
Contextes de l’interface CLI
Gestion et surveillance du réseau back-end
LDAP
Matériel et ports WAN Metro Node
Dans un cluster Metro Node Metro over IP, le directeur possède deux ports 10 Gigabit Ethernet (10 GbE) nommés WC-00 et WC-01.
AVERTISSEMENT : Les données acheminées sur les ports WAN des directeurs et entre des clusters en configuration
Metro Node Metro ne sont pas chiffrées. Pour éviter les attaques par DNS, les ports WAN doivent être routés
uniquement sur des réseaux sécurisés de confiance. Reportez-vous à l’outil Simple Support Matrix for metro node
(matrice de support simplifiée pour Metro Node) pour plus d’informations sur les périphériques de chiffrement
supportés dans les configurations Metro Node.
Règles de configuration des ports WAN Metro over IP
Les ports WAN Metro over IP doivent respecter les règles suivantes :
● Les deux ports WAN d’un directeur doivent se trouver sur des réseaux physiques différents. Ils doivent également se trouver sur
des sous-réseaux différents, de sorte que le port WC-00 (ip-port-group 0) ne puisse pas voir le port WC-01 (ip-port-group 1) sur un
directeur.
● Tous les ports WC-00s dans le cluster (un pour chaque directeur) doivent se trouver dans le même sous-réseau et être connectés au
même LAN. Les ports qui se trouvent dans le même sous-réseau sont généralement connectés au même commutateur Ethernet.
● Tous les ports WC-01s doivent se trouver dans un sous-réseau, qui ne peut pas être le même sous-réseau que celui utilisé pour les
ports WC-00.
● Le sous-réseau du port de gestion ne peut pas être le même que l’un des sous-réseaux utilisés pour les ports WAN.
Groupes de ports
Tous les ports nommés WC-00 (dans un cluster) sont collectivement désignés par ip-port-group-0.
Tous les ports nommés WC-01 (dans un cluster) sont collectivement désignés par ip-port-group-1.
REMARQUE : Le nom des groupes de ports (ip-port-group-0 et ip-port-group-1) ne peut pas être modifié.
Contextes de l’interface CLI
Le contexte parent de la configuration des connexions Ethernet et WAN est le suivant :
/clusters/cluster-*/connectivity
Le contexte /clusters/cluster-*/connectivity contient un sous-contexte pour chaque rôle de connectivité :
Configuration du réseau WAN
55
●
●
●
●
wan-com – Configuration de la connectivité intercluster.
local-com – Configuration de la connectivité entre directeurs locaux.
front-end – Configuration de la connectivité avec les hôtes.
back-end – Configuration de la connectivité avec les baies de stockage.
Contexte port-groups
Les groupes de ports (ou les chemins de communication) attribués à chaque rôle de connectivité (back-end, front-end, local-com ou
wan-com) sont contenus dans le sous-contexte port-groups de chaque rôle.
Les ports nommés WC-00 (dans chaque cluster) sont collectivement désignés par ip-port-group-0. Il existe deux ports ip-port-group-0s,
un dans chaque cluster. Le port ip-port-group-0s de chaque cluster constitue un canal de communication entre les clusters.
Les ports nommés WC-01 (dans chaque cluster) sont collectivement désignés par ip-port-group-1. Il existe deux ports port-group-1s, un
dans chaque cluster. Le port port-group-1s de chaque cluster constitue un second canal de communication entre les clusters.
Dans l’exemple suivant, une configuration Metro Node Metro possède deux groupes de ports frontaux fc-port-groups dans chaque
cluster :
VPlexcli:/clusters/cluster-1/connectivity/back-end> cd port-groups/
VPlexcli:/clusters/cluster-1/connectivity/back-end/port-groups> ll
Name
Enabled
Member Port
--------------- ----------- ----------fc-port-group-2 all-enabled IO-02
fc-port-group-3 all-enabled IO-03
Avec plusieurs clusters, un port-group local dispose d’un port-group analogue qui porte le même nom sur le cluster distant.
Un port-group contient tous les ports de tous les directeurs qui partagent les caractéristiques suivantes :
●
●
●
●
Ils assurent le même rôle.
Ils sont de même type.
Ils ont le même numéro de port.
Ils se trouvent sur un SLIC qui est inséré dans la même position sur les directeurs respectifs.
Chaque rôle de communication contient une liste de port-groups. Utilisez la commande ll pour afficher un récapitulatif des port-groups
du rôle :
VPlexcli:/clusters/cluster-1/connectivity/wan-com/port-groups> ll
Name
Enabled
Member Port
--------------- ----------- ----------ip-port-group-0 all-enabled WC-00
ip-port-group-1 all-enabled WC-01
La colonne Enabled affiche la propriété activée de chaque port-group :
● all-enabled – Tous les ports du port-group sont activés.
● all-disabled – Tous les ports du port-group sont désactivés.
● inconsistent – Tous les ports membres n’ont pas le même statut d’activation.
La colonne Member Port répertorie le nom du port qui appartient au port-group. Si le nom de port n’est pas le même sur tous les
directeurs, chaque nom unique est répertorié.
Utilisez la commande set sur la propriété enabled pour modifier l’état activé de tous les ports accessibles dans le port-group :
● set enabled all-enabled: active tous les ports accessibles dans le port-group.
● set enabled all-disabled: désactive tous les ports accessibles dans le port-group.
Sous-contexte port-group
Il existe des sous-contextes port-group spécifiques pour chaque port-type : IP (Ethernet) et FC (Fibre Channel), si les ports
correspondants existent. Les sous-contextes associés à un port-group particulier dépendent à la fois du rôle utilisé par le port-group
et du type de port contenus dans le groupe de ports. Un port-group est composé d’un préfixe port-type et d’un suffixe port-number. Les
préfixes port-type sont les suivants :
● FC : port Fibre Channel
56
Configuration du réseau WAN
● IP : port Ethernet
Tous les port-groups contiennent un contexte member-ports qui fournit des informations sur le member-port de chaque directeur.
Les port-groups IP contiennent :
● option-set – Le contexte contient des options de configuration communes aux ports membres.
● subnet – Le contexte contient les options de configuration pour la gestion réseau IP. Les différents rôles ont différents besoins de
gestion réseau. Par conséquent, leurs contextes de sous-réseau contiennent différentes propriétés. Ces sous-réseaux sont décrits
sous leur rôle associé.
● enabled – Résume l’état activé des ports membres individuels.
Ports membres
Toutes les propriétés sous le contexte member-ports sont en lecture seule.
Tous les port-groups comprennent un contexte member-ports qui répertorie le port de chaque directeur du groupe de ports. Les portgroups se rappellent des member-ports des directeurs qui deviennent inaccessibles. Si un directeur devient inaccessible, le port-group
affiche les ports inaccessibles, mais indique qu’ils sont inaccessibles. Le rappel des ports inaccessibles est uniquement possible si l’instance
actuelle de l’interface CLI s’est informée sur le port avant que le directeur ne soit devenu inaccessible. Si un directeur est inaccessible
lorsque l’interface CLI démarre, ses ports ne s’affichent dans aucun port-group.
Une longue liste du contexte member-ports fournit un récapitulatif des ports membres du port-group :
VPlexcli:/clusters/cluster-1/connectivity/wan-com/port-groups/ip-port-group-0/member-ports> ll
Director
Port
Enabled Address
-------------- ----- ------- -------------director-1-1-A WC-00 enabled 192.168.10.35|
director-1-1-B WC-00 enabled 192.168.10.36|
Le contexte member-ports contient un sous-contexte pour chaque directeur qui contribue à un port vers le port-group :
VPlexcli:/clusters/cluster-1/connectivity/wan-com/port-groups/ip-port-group-0/member-ports/
director-1-1-A> ll
Name
Value
--------- -------------address
192.168.10.35|
director
director-1-1-A
enabled
enabled
port-name WC-00
Ces sous-contextes fournissent des informations limitées sur le port de ce directeur. Vous trouverez des informations complètes dans le
contexte du directeur /clusters/*/directors/*/ports.
REMARQUE : Le champ adresse n’est pas spécifique au port-type et affiche l’adresse appropriée pour le type de port.
contexte de sous-réseaux
Un sous-réseau est une sous-division logique d’un réseau IP. Les adresses IP Metro Node sont divisées de façon logique en deux champs :
● Un préfixe de réseau ou de routage.
Sur Metro Node, l’attribut « prefix » comprend un préfixe et un masque de sous-réseau. Indiqué sous la forme d’une adresse IP et d’un
masque de sous-réseau notés sous la forme d’entiers et de points séparés par deux-points.
Par exemple : 192.168.20.0:255.255.255.0
● Un ID spécifique pour la configuration ou l’interface réseau.
REMARQUE : Les adresses de sous-réseau Metro Node doivent être cohérentes. L’adresse du cluster et l’adresse de la
passerelle doivent figurer dans le sous-réseau spécifié par le préfixe.
Seuls les groupes de ports IP ont des contextes de sous-réseau. Utilisez les contextes de sous-réseau pour afficher et modifier la
configuration de réseau IP utilisée par les ports membres. Toutefois, étant donné que les différents rôles ont des exigences de gestion
réseau différentes, les propriétés du contexte de sous-réseau sont dépendantes des rôles.
Conditions requises pour les attributs de sous-réseau :
● mtu doit être défini sur un certain nombre d’octets, entre 1 024 et 9 000.
Configuration du réseau WAN
57
●
●
●
●
prefix doit contenir l’adresse IP d’un quelconque port membre du groupe de ports.
prefix doit contenir l’adresse du cluster.
prefix doit contenir la passerelle.
gateway doit être une adresse unique sur le cluster local.
Notez les points suivants :
● Une adresse vide est constituée de tous les préfixes et ne correspond à aucune adresse.
● Un préfixe vide contient toutes les adresses.
● Une propriété qui n’est pas présente dans un contexte de sous-réseau particulier est considérée vide.
Si une modification est apportée au sous-réseau, elle est validée et appliquée pour tous les ports qui utilisent le sous-réseau.
Lors de la reconfiguration d’un groupe de ports, de nombreuses valeurs doivent être cohérentes les unes avec les autres. Il peut être
nécessaire de supprimer ou d’effacer certaines valeurs d’attribut pour pouvoir en modifier d’autres.
VPlexcli:/clusters/cluster-1/connectivity/wan-com/port-groups/ip-port-group-3> cd subnets/
VPlexcli:/clusters/cluster-1/connectivity/wan-com/port-groups/ip-port-group-3/subnets> ll
Name
-------------cluster-1-SN00
cluster-1-SN01
default-subnet
Pour vider un sous-réseau, utilisez la commande configuration subnet clear.
/connectivity/back-end/
Le contexte de rôle back-end contient les informations de configuration requises pour la connexion aux baies de stockage back-end.
Le rôle back-end ne possède aucune propriété associée. Notez que seules les propriétés IP port-groups possèdent des contextes de
sous-réseau.
port-groups/ip-port-group-*/subnet/
Le contexte de rôle back-end possède des sous-réseaux qui vous permettent de configurer le routage pour accéder aux cibles avec des
adresses non délimitées par l’attribut prefix.
Vous trouverez ci-dessous une description des attributs de sous-réseau :
●
●
●
●
gateway : l’adresse de la passerelle associée à ce sous-réseau.
mtu : l’unité de transfert maximale pour ce sous-réseau.
prefix : le préfixe et le masque pour ce sous-réseau.
remote-subnets : les préfixes des réseaux distants accessibles à partir de ce sous-réseau.
Reportez-vous à la section subnets context pour plus d’informations sur la modification ou l’effacement de ces attributs.
/connectivity/front-end/
Le contexte front-end role contient les informations de configuration requises pour se connecter aux hôtes front-end.
Le rôle front-end possède des sous-réseaux qui vous permettent de configurer le routage pour accéder aux hôtes avec des adresses non
délimitées par l’attribut prefix. Notez que seules les propriétés IP port-groups possèdent des contextes de sous-réseau.
Vous trouverez ci-dessous une description des attributs de sous-réseau du contexte /connectivity/front-end/ :
●
●
●
●
gateway : l’adresse de la passerelle associée à ce sous-réseau.
mtu : l’unité de transfert maximale pour ce sous-réseau.
prefix : le préfixe et le masque pour ce sous-réseau.
remote-subnets : les préfixes des réseaux distants accessibles à partir de ce sous-réseau.
L’attribut remote-subnet est une liste qui peut être modifiée à l’aide des commandes configuration subnet remotesubnets add et configuration subnet remote-subnets remove .
Reportez-vous à la section subnets context pour plus d’informations sur la modification ou l’effacement d’autres attributs.
58
Configuration du réseau WAN
/connectivity/local-com/
Le contexte de rôle local contient les informations de configuration relatives à la communication entre les directeurs dans le cluster en
cours.
Le rôle local ne possède aucune propriété associée.
Gestion et surveillance du réseau back-end
Pour une haute disponibilité, chaque directeur doit avoir plusieurs chemins vers chaque volume de stockage. Des problèmes
d’environnement, tels que la congestion du réseau ou des problèmes de baie, peuvent affecter la disponibilité et les performances de
ces chemins. Pour plus d’informations, reportez-vous aux documents sur les pratiques d’excellence pour Metro Node. Metro Node
surveille la latence de chaque nexus IT back-end ; il est possible de rencontrer des chemins back-end peu performants. Metro Node
dispose de plusieurs mécanismes pour limiter l’impact sur les performances :
Mise hors service d’un nexus IT back-end avec une latence élevé
Si une E/S a besoin de plus de 1 seconde pour se terminer sur une ITL (LUN initiateur cible sur un nexus IT), alors l’ITL et l’IT génèrent
une pénalité lorsque la limite de commande autorisée pour l’ITL est réduite de cinq à un. Si la pénalité cumulée pour une ITL dépasse
2 secondes, la limite de commande sur l’ITL est réduite à zéro, ce qui indique qu’aucune autre commande n’est autorisée sur cette ITL. En
raison d’une latence élevée, si plus de 20 ITL sur un nexus IT sont pénalisées, le nexus IT est marqué comme dégradé et Metro Node cesse
automatiquement d’utiliser le nexus IT pour les E/S basées sur l’hôte jusqu’à ce que les performances s’améliorent.
REMARQUE : Si le dernier chemin disponible vers une unité logique est marqué comme dégradé, il ne peut pas être mis hors service
et une pénalité est appliquée pour autoriser une seule E/S à la fois vers la LU. Une ITL par unité logique et par directeur continue de
recevoir les commandes. Une fois les performances améliorées, Metro Node restaure automatiquement le nombre d’E/S inachevées
par défaut sur l’unité logique.
Les nexus IT back-end dégradés peuvent être surveillés avec la commande Vplexcli back-end degraded list. Pour plus
d’informations, reportez-vous au document CLI Reference Guide for metro node (Guide de référence de l’interface CLI pour Metro Node).
En raison d’une latence élevée continue, lorsqu’un nexus IT est marqué comme dégradé, cette commande répertorie les causes de la
dégradation des performances.
Si un utilisateur constate qu’un nexus IT dégradé a été restauré à un état fonctionnel, il est également possible de restaurer manuellement
son utilisation avec la commande Vplexcli back-end degraded recover.
Marquage d’un nexus IT back-end comme isolé du fait de
performances instables
Si un chemin IT back-end oscille entre les états dégradé et non dégradé à trois reprises sur une période de 30 minutes, le nexus IT
est considéré comme instable et Metro Node cesse automatiquement d’utiliser le nexus IT pour les E/S basées sur l’hôte. Dans cet
état, la commande Vplexcli back-end degraded list identifie la cause de la dégradation comme Isolé du fait de performances
instables.
Dans ce cas, le nexus IT reste dégradé jusqu’à ce que l’utilisateur le restaure manuellement à l’aide de la commande Vplexcli back-end
degraded recover. Il est également possible que le seuil atteigne la valeur par défaut de quatre heures, après quoi le nexus IT est
marqué comme étant en Performances dégradées alors que le processus de restauration vérifie son intégrité avant de le dégrader
(et réactive automatiquement le chemin pour traiter à nouveau les E/S basées sur l’hôte si les tests de performance réussissent). Si
le problème de latence intermittente perdure sur le nexus IT et que l’utilisateur n’est pas en mesure de traiter la cause première, il est
recommandé de faire appel au service client Metro Node afin de marquer manuellement le nexus IT comme dégradé et de mettre le
chemin hors usage, jusqu’à ce que le problème sous-jacent soit résolu.
LDAP
Le protocole LDAP (Lightweight Directory Access Protocol) est un protocole d’application pour l’accès aux et la mise à jour des
services d’informations d’annuaire distribués sur un réseau IP (Internet Protocol). Les services de répertoire fournissent tout ensemble
d’enregistrements organisé avec une structure hiérarchique. LDAP est un protocole qui suit le modèle client-serveur.
Configuration du réseau WAN
59
Structure des répertoires
L’organisation d’un répertoire est une arborescence. La toute première entrée dans un répertoire est connue sous le nom d’entrée racine.
Cette entrée représente normalement l’organisation propriétaire du répertoire.
Figure 4. Structure de répertoire LDAP
SolVe Desktop pour Metro Node fournit des informations sur la configuration de LDAP.
Exemples (commande ldapsearch)
Utilisez la commande ldapsearch pour vérifier les valeurs de mappage des attributs du serveur de répertoire.
● Pour déterminer les utilisateurs qui résident dans une unité d’organisation donnée :
service@ManagementServer:~> /usr/bin/ldapsearch -x -LLL -l 30 -H ldap://
10.31.50.59:389 -b 'ou=dev,ou=vplex,dc=emc,dc=com' -D 'cn=Administrator,dc=emc,dc=com'
objectClass=posixAccount -w password -E pr=1000/noprompt dn
dn: uid=dev1,ou=security,ou=dev,ou=vplex,dc=emc,dc=com
dn: uid=dev2,ou=security,ou=dev,ou=vplex,dc=emc,dc=com
dn: uid=dev3,ou=GUI,ou=dev,ou=vplex,dc=emc,dc=com
● Pour déterminer les utilisateurs qui résident dans une entité de sécurité de groupe qui doit être mappée dans le cas de serveurs
OpenLDAP :
service@ManagementServer:~> /usr/bin/ldapsearch -x -LLL -l 30 -H ldap://10.31.50.59:389 -b
'cn=GUI-Group,ou=vplex,dc=emc,dc=com' -D 'cn=Administrator,dc=emc,dc=com' -w password -E
pr=1000/noprompt
dn: cn=GUI-Group,ou=vplex,dc=emc,dc=com
objectClass: groupOfNames
cn: GUI-Group
description: GUI-Group
member: uid=QE1,ou=gui,ou=qe,ou=vplex,dc=emc,dc=com
member: uid=QE2,ou=gui,ou=qe,ou=vplex,dc=emc,dc=com
member: uid=dev3,ou=GUI,ou=dev,ou=vplex,dc=emc,dc=com
● Pour déterminer les attributs de l’entité de sécurité de l’utilisateur dans le cas d’un serveur OpenLDAP :
service@ManagementServer:~> /usr/bin/ldapsearch -x -LLL -l 30 -H ldap://10.31.50.59:389 b 'uid=dev1,ou=security,ou=dev,ou=vplex,dc=emc,dc=com' -D 'cn=Administrator,dc=emc,dc=com'
-w zephyr01 -E pr=1000/noprompt
dn: uid=dev1,ou=security,ou=dev,ou=vplex,dc=emc,dc=com
sn: dev
60
Configuration du réseau WAN
cn: dev1
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
uid: dev1
loginShell: /bin/bash
homeDirectory: /u/v/x/y/dev1
uidNumber: 50000
gidNumber: 80000
Configuration du réseau WAN
61
9
Consistency Groups
Ce chapitre décrit comment gérer et utiliser les groupes de cohérence Metro Node.
Sujets :
•
•
•
•
À propos des groupes de cohérence Metro Node
Propriétés des groupes de cohérence
Gérer les groupes de cohérence
Utilisation d’un groupe de cohérence
À propos des groupes de cohérence Metro Node
Les groupes de cohérence Metro Node rassemblent des volumes pour doter l’application d’une série de propriétés communes à l’ensemble
du groupe.
Figure 5. Groupe de cohérence Metro Node
Groupes de cohérence synchrones
Les groupes de cohérence synchrones offrent une manière pratique d’appliquer diverses règles et autres propriétés à un groupe de
volumes dans un système Metro Node Local ou Metro Node Metro.
Metro Node supporte jusqu’à 1 024 groupes de cohérence synchrones.
Un groupe de cohérence synchrone :
●
●
●
●
Contient jusqu’à 1 000 volumes virtuels.
Contient soit des volumes locaux, soit des volumes distribués (mais non une combinaison des deux).
Contient des volumes avec une visibilité globale ou locale.
Utilise la mise en cache à écriture immédiate (appelée mode de cache synchrone dans l’interface utilisateur Metro Node).
La fidélité de l’ordre d’écriture est maintenue en terminant toutes les écritures sur le disque avant de confirmer l’écriture sur l’hôte.
La figure suivante représente un groupe de cohérence synchrone qui s’étend sur deux clusters en configuration Metro Node Metro.
62
Consistency Groups
Figure 6. Groupe de cohérence synchrone
● Les hôtes des deux clusters écrivent sur les volumes distribués Metro Node du groupe de cohérence.
● Metro Node écrit les données sur le stockage back-end des deux clusters.
● La confirmation est renvoyée à l’hôte qui émet l’écriture.
Cela garantit que l’image sur le stockage back-end est une copie exacte des deux côtés.
Groupes de cohérence synchrones : visibilité
Les groupes de cohérence synchrones prennent en charge les volumes distribués ou locaux (mais pas les deux dans le même groupe de
cohérence).
Les groupes de cohérence synchrones locaux ont uniquement des volumes locaux en tant que membres. Il est possible de définir la
propriété de visibilité des groupes de cohérence synchrones locaux sur :
● Une visibilité locale : les volumes locaux dans le groupe de cohérence ne sont visibles que pour le cluster local.
● Une visibilité globale : les volumes locaux dans le groupe de cohérence ont du stockage au niveau d’un seul cluster, mais sont visibles
pour les deux clusters.
Visibilité locale
Les groupes de cohérence locaux dont la visibilité est paramétrée sur le cluster local ne peuvent lire et écrire que sur leur cluster local.
La figure suivante illustre un groupe de cohérence local avec visibilité locale.
Consistency Groups
63
Figure 7. Groupe de cohérence local avec visibilité locale
Visibilité globale
Si la propriété visibility des groupes de cohérence locaux est définie sur les deux clusters (visibilité globale), les deux clusters peuvent
recevoir des E/S à partir du cluster qui ne dispose pas de copie locale.
Toutes les écritures de ce cluster distant passent par la liaison WAN intercluster avant d’être confirmées.
Toutes les lectures qui ne peuvent être traitées en local sont transférées à travers la liaison. Cela permet non seulement au cluster distant
de disposer d’un accès à la demande instantané au groupe de cohérence, mais aussi d’ajouter de la latence supplémentaire pour le cluster
distant.
Les groupes de cohérence locaux avec visibilité globale sont supportés dans les environnements Metro Node Metro. Seuls les volumes
locaux peuvent être placés dans un groupe de cohérence local avec visibilité globale. Les groupes de cohérence locaux avec visibilité
globale utilisent toujours le mode de mémoire cache à écriture immédiate (mode de cache synchrone). Les E/S adressées à des groupes
de cohérence locaux avec visibilité globale sont toujours synchrones.
Vous trouverez ci-dessous un groupe de cohérence local avec visibilité globale.
64
Consistency Groups
Figure 8. Groupe de cohérence local avec visibilité globale
Propriétés des groupes de cohérence
Les propriétés d’un groupe de cohérence sont appliquées à tous les volumes virtuels du groupe de cohérence.
Tous les groupes de cohérence ont des propriétés configurables qui déterminent le comportement des E/S, y compris :
●
●
●
●
●
Visibilité
Storage-at-clusters
detach-rule
auto-resume-at-loser
virtual-volumes
Visibilité
La visibilité contrôle les clusters qui connaissent un groupe de cohérence.
REMARQUE : La visibilité des groupes de cohérence est différente de la propriété de visibilité des appareils. La visibilité des
appareils peut être définie sur local (visible uniquement pour le cluster local) ou global (visible pour les deux clusters). Tous les
périphériques distribués disposent d’une visibilité globale.
Par défaut, la propriété de visibilité des groupes de cohérence est définie uniquement sur le cluster dans lequel le groupe de cohérence a
été créé. Si un groupe de cohérence est créé sur le cluster-2, il est initialement visible uniquement sur le cluster-2.
La visibilité des volumes dans le groupe de cohérence doit correspondre à la visibilité du groupe de cohérence.
Si la visibilité d’un volume dans un groupe de cohérence est définie sur local, la visibilité du groupe de cohérence ne peut pas être définie
pour inclure d’autres clusters. Par exemple, si le volume LocalVolume avec la propriété de visibilité définie sur local est ajouté au groupe
de cohérence TestCG, la visibilité de TestCG ne peut pas être modifiée pour inclure d’autres clusters.
En général, la visibilité est définie sur l’une des trois options suivantes :
● Configurez le groupe de cohérence pour qu’il contienne uniquement les volumes locaux du cluster local.
● Configurez le groupe de cohérence pour qu’il contienne uniquement les volumes qui disposent d’un stockage au niveau d’un seul
cluster, mais qui ont une visibilité globale.
Consistency Groups
65
● Configurez le groupe de cohérence pour qu’il contienne uniquement les volumes qui sont distribués avec des tronçons sur les
deux clusters.
Lorsque la visibilité d’un groupe de cohérence est définie sur un cluster, le groupe de cohérence s’affiche sous le contexte /clusters/
cluster-n/consistency-groups pour le cluster.
REMARQUE : Le contexte d’un groupe de cohérence spécifique s’affiche dans le contexte de l’interface de ligne de commande du
groupe de cohérence du cluster uniquement si la propriété de visibilité du groupe de cohérence inclut ce cluster.
Dans des conditions normales de fonctionnement, la propriété de visibilité peut être modifiée pour s’étendre d’un cluster à deux clusters.
Utilisez la commande set dans le contexte /clusters/cluster/consistency-groups/consistency-group pour modifier la
propriété de visibilité. Si le groupe de cohérence TestCG n’est visible que sur le cluster-1, utilisez la commande set pour le rendre visible
pour le cluster-1 et le cluster-2 :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set visibility cluster-1,cluster-2
Si un groupe de cohérence contient des volumes virtuels avec une visibilité donnée (par exemple, la visibilité d’un volume membre est
local), la propriété de visibilité pour le groupe de cohérence ne peut pas être modifiée pour entrer en conflit avec la propriété de visibilité
du volume virtuel membre.
Par exemple, le groupe de cohérence TestCG est visible uniquement au niveau du cluster-1 et contient un volume V dont l’appareil est
défini sur le cluster-1 et a une visibilité locale. Les deux commandes suivantes vont échouer, car le volume V n’est pas visible au niveau du
cluster-2.
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set visibility cluster-1,cluster-2
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set visibility cluster-2
Storage-at-clusters
Storage-at-clusters indique à Metro Node le cluster sur lequel se trouve le stockage physique associé à un groupe de cohérence.
La propriété storage-at-clusters d’un groupe de cohérence doit être un sous-ensemble non vide de la propriété visibility du
groupe de cohérence.
● Si la propriété visibility est définie sur un cluster, storage-at-clusters doit être strictement identique à la propriété
visibility.
● Si la propriété visibility est définie sur deux clusters (1 et 2), storage-at-clusters peut être l’une de ces valeurs :
○ Cluster 1
○ Cluster 2
○ cluster-1 et cluster-2
Un volume qui ne dispose pas d’un stockage local sur chaque cluster spécifié par la propriété storage-at-clusters d’un groupe de
cohérence ne peut pas être ajouté au groupe de cohérence.
Par exemple, si un volume ne dispose que d’un stockage au niveau du cluster-1, il ne peut pas être ajouté à un groupe de cohérence dont la
propriété storage-at-cluster est définie sur cluster-1 et cluster-2.
Un volume qui dispose d’un stockage local sur d’autres clusters que ceux spécifiés par la propriété storage-at-clusters d’un groupe
de cohérence ne peut pas être ajouté au groupe de cohérence.
Par exemple, si un volume dispose d’un stockage au niveau du cluster-1 et du cluster-2, il ne peut pas être ajouté à un groupe de
cohérence dont la propriété storage-at-cluster est définie sur cluster-1.
La propriété storage-at-clusters ne peut pas être modifiée en cas de conflit avec la topologie de l’un des volumes qui se trouvent
actuellement dans le groupe de cohérence.
Utilisez la commande set dans le contexte /clusters/cluster/consistency-groups/consistency-group pour modifier la
propriété storage-at-clusters. Par exemple, pour définir la propriété storage-at-clusters sur les deux clusters :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set storage-at-clusters
cluster-1,cluster-2
REMARQUE : La pratique d’excellence consiste à définir la propriété storage-at-clusters lorsque le groupe de cohérence est
vide.
66
Consistency Groups
detach-rule
Les règles de déconnexion constituent une règle de groupe de cohérence pour la sélection automatique d’un cluster gagnant en cas de
panne de liaison intercluster.
Pour les configurations Metro Node Metro, il existe deux règles de déconnexion de groupe de cohérence :
● no-automatic-winner – Le groupe de cohérence ne sélectionne pas de cluster gagnant.
● winner cluster-name delay seconds – Le cluster défini par cluster-name est déclaré vainqueur si une panne de liaison
intercluster dure plus longtemps que le nombre de secondes défini par le délai.
Si une règle de déconnexion a été paramétrée pour un groupe de cohérence, la règle s’applique à tous les volumes du groupe de
cohérence, et remplace tout ensemble de règles appliqué aux volumes individuels.
Cette propriété ne s’applique pas aux groupes de cohérence locaux.
Par défaut, aucune règle de déconnexion spécifique n’est configurée pour un groupe de cohérence. En revanche, la règle de déconnexion
no-automatic-winner est définie comme valeur par défaut pour un groupe de cohérence avec visibilité sur les deux clusters.
Il est recommandé d’appliquer les règles de déconnexion à un groupe de cohérence qui répond aux besoins de votre application en matière
de continuation des E/S et de tolérance aux pertes de données.
Utilisez les commandes consistency-group set-detach-rule pour configurer la propriété detach-rule d’un groupe de
cohérence :
● Utilisez la commande consistency-group set-detach-rule no-automatic-winner pour définir la propriété detach-rule
sur no-automatic-winner :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set-detach-rule no-automatic-winner
● Utilisez la commande consistency-group set-detach-rule winner pour spécifier quel est le cluster vainqueur, et le
nombre de secondes que Metro Node attend entre une panne de liaison et la déconnexion du cluster gagnant :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set-detach-rule winner --cluster
cluster-1 --delay 5s
Le tableau suivant décrit le comportement de la règle de déconnexion pour un groupe de cohérence synchrone.
Tableau 9. Comportement de la règle de déconnexion – Groupe de cohérence synchrone
Règles de déconnexion
Comportement (indépendamment du cluster sur lequel les
E/S se produisent)
Cluster-1 wins
Les E/S sont autorisées sur le cluster-1
Les E/S sont interrompues sur le cluster-2
Aucune perte de données/aucune restauration des données
Cluster-2 wins
Les E/S sont interrompues sur le cluster-1
Les E/S sont autorisées sur le cluster-2
Aucune perte de données/aucune restauration des données
Aucun cluster automatiquea
Les E/S sont interrompues sur le cluster-1
Les E/S sont interrompues sur le cluster-2
Aucune perte de données/aucune restauration des données
a.
DU sur les deux clusters si la connectivité COM WAN entre les clusters Metro Node tombe en panne.
Notez les points suivants :
● Les E/S actives indiquent des écritures actives.
● Le comportement de la règle de déconnexion décrite dans le tableau précédent est basé sur l’hypothèse qu’un tronçon fonctionnel
existe dans le cluster gagnant, au moment de la partition du cluster.
● Utilisez la commande consistency-group resume-after-rollback pour rétablir l’opération après restauration.
● Avec la règle de déconnexion no-automatic-winner, vous devez désigner manuellement un cluster comme vainqueur pour
reprendre les E/S. Utilisez la commande consistency-group choose-winner pour choisir un vainqueur.
Consistency Groups
67
auto-resume-at-loser
Détermine si le perdant reprend automatiquement les E/S lorsque le lien intercluster est réparé après une défaillance.
Lorsque le lien est restauré, le cluster perdant détecte que les données sur le cluster gagnant sont différentes. Le perdant doit déterminer
s’il est nécessaire de modifier soudainement les données du gagnant ou de continuer à suspendre les E/S.
Par défaut, auto-resume est activé.
En règle générale, cette propriété est définie sur false pour laisser à l’administrateur le temps d’interrompre et de redémarrer
l’application. Dans le cas contraire, les données corrompues dans le cache de l’hôte peuvent ne pas être cohérentes avec l’image sur le
disque sur lequel le cluster gagnant a écrit. Si l’hôte vide ces pages corrompues de la séquence, l’image de données peut être corrompue.
Définissez cette propriété sur true pour les groupes de cohérence utilisés dans un répartiteur de clusters. Dans ce cas, il n’y a aucun
risque de perte de données puisque le gagnant est toujours connecté à l’hôte, évitant ainsi la remise hors séquence.
true (par défaut) – Les E/S reprennent automatiquement sur le cluster perdant une fois le lien intercluster restauré.
Définissez auto-resume-at-loser sur true uniquement lorsque le cluster perdant traite une application en lecture seule, comme des
pages Web.
false – Les E/S restent suspendues sur le cluster perdant une fois le lien intercluster restauré. Les E/S doivent être relancées
manuellement.
Définissez auto-resume-at-loser sur false pour toutes les applications qui ne peuvent pas tolérer un changement soudain des
données.
PRÉCAUTION : La définition de la propriété de reprise automatique sur true peut conduire à une modification
spontanée de la vue des données présentée aux applications au niveau du cluster perdant lorsque le lien intercluster
est restauré. Si l’application n’a pas échoué, il se peut qu’elle ne soit pas en mesure de tolérer la modification soudaine
de la vue de données, ce qui peut conduire à une corruption des données. Définissez la propriété sur false à l’exception
des applications qui peuvent tolérer ce problème et pour les hôtes interconnectés.
Utilisez la commande set dans le contexte avancé pour configurer la propriété de reprise automatique pour un groupe de cohérence :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG/advanced> set auto-resume-at-loser true
virtual-volumes
Les administrateurs peuvent ajouter et supprimer des volumes virtuels dans un groupe de cohérence. Afin d’être ajouté à un groupe de
cohérence, un volume virtuel :
● Ne doit pas être un volume de journalisation.
● Doit disposer d’un stockage sur chaque cluster dans la propriété storage-at-clusters du groupe de cohérence cible.
● Ne doit pas être membre d’un autre groupe de cohérence.
● Les propriétés (telles que les règles de déconnexion ou la reprise automatique) qui sont en conflit avec celles du groupe de cohérence
sont automatiquement modifiées pour correspondre à celles du groupe de cohérence.
REMARQUE : Les volumes virtuels avec des propriétés différentes sont autorisés à rejoindre un groupe de cohérence, mais héritent
des propriétés du groupe de cohérence.
Utilisez la commande consistency-group list-eligible-virtual-volumes pour afficher les volumes virtuels qui peuvent
être ajoutés à un groupe de cohérence.
Utilisez la commande consistency-group add-virtual-volumes pour ajouter un ou plusieurs volumes virtuels à un groupe de
cohérence.
Utilisez la commande ll /clusters/cluster-*/consistency-groups/groupe-de-cohérence pour afficher les volumes virtuels
dans le groupe de cohérence spécifié.
Utilisez la commande consistency-group remove-virtual-volumes pour supprimer un ou plusieurs volumes virtuels d’un
groupe de cohérence.
68
Consistency Groups
Gérer les groupes de cohérence
REMARQUE : Une pratique d’excellence clé pour la création et la gestion de groupes de cohérence consiste à créer une relation
1-à-1 entre les groupes de cohérence et les applications. Tous les volumes requis pour une application (et uniquement ceux-là) doivent
figurer dans un seul et même groupe de cohérence.
Création d’un groupe de cohérence
Avant de créer un groupe de cohérence, évaluez son utilisation :
À propos de cette tâche
● Sur quels clusters se situe l’espace de stockage sous-jacent des volumes virtuels ? Si les volumes sont sur les deux clusters, définissez
la propriété storage-at-cluster sur cluster-1,cluster-2.
● Quelle est la visibilité des volumes virtuels à ajouter ?
Certaines propriétés des volumes virtuels et des groupes de cohérence permettent de définir quels volumes peuvent être ajoutés à un
groupe de cohérence ou d’empêcher la modification d’une propriété du groupe de cohérence.
Par exemple, la propriété visibility d’un groupe de cohérence est définie sur cluster-1. Les volumes virtuels locaux vers
cluster-1 sont ajoutés. La propriété visibility du groupe de cohérence ne peut pas être remplacée par cluster-2 ou
cluster-1,cluster-2, car les volumes ne sont pas visibles sur le cluster-2.
Pour créer un groupe de cohérence et configurer les propriétés qui doivent être définies avant l’ajout de volumes virtuels, procédez
comme suit :
Étapes
1. Utilisez la commande ls /clusters/*/consistency-groups/ pour afficher le nom de tous les groupes de cohérence :
VPlexcli:/> ls /clusters/*/consistency-groups/
/clusters/cluster-1/consistency-groups:
TestCG
local_test
test10
test11
test15
test16
test5
test6
vs_RAM_c1wins vs_RAM_c2wins vs_oban005 vs_sun190
/clusters/cluster-2/consistency-groups:
TestCG
local_test
test10
test11
test15
test16
test5
test6
vs_RAM_c1wins vs_RAM_c2wins vs_oban005 vs_sun190
test12
test7
test13
test8
test14
test9
test12
test7
test13
test8
test14
test9
2. Utilisez la commande consistency-group create pour créer un groupe de cohérence sur un cluster. Spécifiez un nom pour le
nouveau groupe de cohérence qui n’apparaissait pas dans les résultats de l’étape précédente.
VPlexcli:/> consistency-group create --name TestCG --cluster cluster-1
3. Utilisez la commande ls /clusters/cluster-id/consistency-groups/groupe-de-cohérence/ pour afficher le nouveau
groupe de cohérence.
Définition de la propriété visibility
Par défaut, la propriété visibility du groupe de cohérence est définie sur le cluster sur lequel le groupe de cohérence a été créé.
Si un groupe de cohérence est créé sur le cluster-2, il est initialement visible uniquement sur le cluster-2.
Vous pouvez configurer la visibilité comme suit :
● cluster-1 – Volumes locaux sur le cluster-1.
● cluster-2 – Volumes locaux sur le cluster-2.
● cluster-1,cluster-2 – Volumes distribués avec des tronçons sur les deux clusters.
4. Utilisez la commande set pour configurer la propriété visibility du groupe de cohérence.
PRÉCAUTION : Le contexte de l’interface CLI du groupe de cohérence s’affiche uniquement au niveau du cluster
sur lequel le groupe de cohérence a une visibilité. Si la propriété visibility est définie à partir du cluster-1 de sorte
à inclure uniquement le cluster-2, le contexte de l’interface CLI pour le groupe de cohérence disparaît au niveau du
cluster-1 et est uniquement visible à partir du cluster-2.
Consistency Groups
69
Pour définir la propriété visibility du groupe de cohérence sur les deux clusters :
VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::visibility cluster-1,cluster-2
Pour définir la propriété visibility du groupe de cohérence sur le cluster-1 :
VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::visibility cluster-1
Pour définir la propriété visibility du groupe de cohérence sur le cluster-2 :
VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::visibility cluster-2
Définition de la propriété storage-at-clusters
Par défaut, la propriété storage-at-clusters du groupe de cohérence est définie sur empty.
Le champ storage-at-clusters indique à Metro Node le cluster sur lequel se trouve le stockage physique associé à un groupe
de cohérence. Si la propriété visibility est définie sur un cluster, storage-at-clusters doit être identique à la propriété
visibility. Si la propriété visibility est définie sur deux clusters (1 et 2), storage-at-clusters peut être l’une de ces valeurs :
● cluster-1
● cluster-2
● cluster-1,cluster-2
Un volume qui ne dispose pas d’un stockage local sur chaque cluster spécifié par la propriété storage-at-clusters d’un groupe de
cohérence ne peut pas être ajouté au groupe de cohérence.
5. Utilisez la commande set pour configurer la propriété storage-at-clusters du groupe de cohérence.
VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::storage-at-clusters
cluster-1,cluster-2
6. Si vous le souhaitez, vous pouvez utiliser l’une des commandes consistency-group set-detach-rule pour appliquer une
règle de déconnexion.
Par exemple, configurez la règle de déconnexion sur active-cluster-wins :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set-detach-rule active-cluster-wins
7. Utilisez la commande ll pour afficher le nouveau groupe de cohérence.
Reportez-vous au tableau 16, Descriptions des champs de groupe de cohérence pour obtenir une description des champs qui
s’affichent.
Ajout de volumes à un groupe de cohérence
Au maximum, 1000 volumes peuvent être ajoutés à un groupe de cohérence.
À propos de cette tâche
Tous les volumes utilisés par la même application doivent être ajoutés au même groupe de cohérence.
Seuls les volumes locaux peuvent être ajoutés aux groupes de cohérence synchrones avec les propriétés visibility et storage-at-clusters
définies sur le cluster local.
Les volumes distants peuvent être ajoutés aux groupes de cohérence synchrones avec la propriété visibility définie sur les deux clusters et
la propriété storage-at-clusters définie sur un cluster.
Les volumes distribués peuvent être ajoutés aux groupes de cohérence synchrones avec la propriété visibility définie sur les deux clusters
et la propriété storage-at-clusters définie les deux clusters.
Pour ajouter des volumes virtuels à un groupe de cohérence existant, procédez comme suit :
70
Consistency Groups
Étapes
1. Accédez au contexte du groupe de cohérence cible :
VPlexcli:/> cd clusters/cluster-1/consistency-groups/TestCG
2. Utilisez la commande consistency-group list-eligible-virtual-volumes pour afficher les volumes virtuels qui
peuvent être ajoutés au groupe de cohérence :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> consistency-group list-eligiblevirtual-volumes
[TestDDevice-1_vol, TestDDevice-2_vol, TestDDevice-3_vol, TestDDevice-4_vol,
TestDDevice-5_vol]
3. Utilisez la commande add-virtual-volumes pour ajouter des volumes virtuels au groupe de cohérence.
Pour ajouter un seul volume virtuel :
VPlexcli:/clusters/cluster-2/consistency-groups/TestCG> add-virtual-volumes --virtualvolumes TestDDevice-2_vol
REMARQUE : Le chemin complet n’est pas obligatoire si le nom du volume est unique dans Metro Node.
Pour ajouter plusieurs volumes à l’aide d’une seule commande, séparez les volumes virtuels par des virgules :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> add-virtual-volumes
TestDDevice-1_vol,TestDDevice-2_vol
4. Utilisez la commande ll pour afficher la modification.
Suppression de volumes d’un groupe de cohérence
Pour supprimer un ou plusieurs volumes virtuels d’un groupe de cohérence :
Étapes
1. Utilisez la commande ll pour afficher les volumes virtuels dans le groupe de cohérence cible :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> ll
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[]
cache-mode
synchronous
detach-rule
winner cluster-1 10s
operational-status
[(cluster-1,{ summary:: ok, details:: [] }), (cluster-2,{
summary:: ok, details:: [] })]
passive-clusters
[cluster-1, cluster-2]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[TestDDevice-1_vol, TestDDevice-2_vol,
TestDDevice-3_vol,TestDDevice-4_vol,
TestDDevice-5_vol]
visibility
[cluster-1, cluster-2]
Contexts:
Name
Description
------------ ----------advanced
recoverpoint 2. Utilisez la commande consistency-group remove-virtual-volumes pour supprimer un ou plusieurs volumes virtuels.
VPlexcli:/> consistency-group remove-virtual-volumes /clusters/cluster-1/virtual-volumes/
TestDDevice-2_vol, --consistency-group /clusters/cluster-1/consistency-groups/TestCG
Consistency Groups
71
Pour supprimer plusieurs volumes virtuels à l’aide d’une seule commande, séparez les volumes par des virgules :
VPlexcli:/> consistency-group remove-virtual-volumes /clusters/cluster-1/virtual-volumes/
TestDDevice-2_vol, /clusters/cluster-1/virtual-volumes/TestDDevice-3_vol --consistencygroup /clusters/cluster-1/consistency-groups/TestCG
Supprimez deux volumes virtuels du contexte du groupe de cohérence cible :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> remove-virtual-volumes
TestDDevice-2_vol, TestDDevice-3_vol
3. Utilisez la commande ls pour afficher la modification :
VPlexcli:/> ls clusters/cluster-1/consistency-groups/TestCG
/clusters/cluster-1/consistency-groups/TestCG:
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[]
cache-mode
synchronous
detach-rule
winner cluster-1 10s
operational-status
[(cluster-1,{ summary:: ok, details:: [] }), (cluster-2,{
summary:: ok, details:: [] })]
passive-clusters
[cluster-1, cluster-2]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[TestDDevice-1_vol, TestDDevice-4_vol, TestDDevice-5_vol]
visibility
[cluster-1, cluster-2]
Contexts:
Name
Description
------------ ----------advanced
recoverpoint -
Modification des propriétés d’un groupe de cohérence
À propos de cette tâche
Utilisez les règles set-detach des groupes de cohérence pour modifier la règle de déconnexion appliquée à un groupe de cohérence :
● consistency-group set-detach-rule no-automatic-winner
● consistency-group set-detach-rule winner
Utilisez la commande set pour modifier les propriétés suivantes d’un groupe de cohérence :
● Visibilité
● Storage-at-clusters
● Local-read-override
Pour afficher les attributs modifiables (accessibles en écriture) à l’aide de la commande set et leurs entrées valides :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set
attribute
input-description
-----------------------------------------------------------------------------------------------------------------active-clusters
Read-only.
cache-mode
Read-only.
detach-rule
Read-only.
name
Takes a unique, non-empty and non-null name. A valid name starts with a
letter or '_'
and contains only letters, numbers, '-' and '_'.
operational-status
Read-only.
passive-clusters
Read-only.
read-only
Takes one of '0', '1', 'f', 'false', 'n', 'no', 'off', 'on', 't',
'true', 'y', 'yes' (not case sensitive).
storage-at-clusters Takes a list with each element being a 'cluster' context or a context
pattern.
72
Consistency Groups
virtual-volumes
visibility
pattern.
Read-only.
Takes a list with each element being a 'cluster' context or a context
Pour afficher le paramètre actuel d’une propriété :
VPlexcli:/> set /clusters/cluster-1/consistency-groups/TestCG::cache-mode
Pour afficher les valeurs par défaut pour un groupe de cohérence cible :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set --default
attribute
default-value
-------------------- ----------------active-clusters
No default value.
cache-mode
synchronous.
detach-rule
No default value.
name
No default value.
operational-status
No default value.
passive-clusters
No default value.
read-only
No default value.
storage-at-clusters
No default value.
virtual-volumes
No default value.
visibility
No default value.
exemple de modification : définition de visibility
Pour modifier la propriété visibility à partir du contexte du groupe de cohérence cible :
À propos de cette tâche
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set visibility cluster-1,cluster-2
Pour modifier la propriété visibility à partir du contexte de groupe de cohérence :
VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::visibility cluster-1,cluster-2
Pour modifier la propriété visibility à partir du contexte racine :
VPlexcli:/> set /clusters/cluster-1/consistency-groups/TestCG::visibility cluster-1,cluster-2
exemple de modification : application d’une règle de déconnexion
Le tableau suivant répertorie les règles de déconnexion applicables aux groupes de cohérence avec différents paramètres pour les
propriétés visibility et storage-at-clusters.
À propos de cette tâche
Tableau 10. Règles de déconnexion des groupes de cohérence avec les propriétés visibility et storage-atclusters
visibilité
storage-at-clusters
Paramètres de règle de déconnexion
applicables
Cluster 1
Cluster 1
s.o.
cluster-1 et cluster-2
cluster-1 et cluster-2
● no-automatic-winner
● winner cluster-1
● winner cluster-2
cluster-1 et cluster-2
Cluster 1
● no-automatic-winner
● winner cluster-1
Consistency Groups
73
Pour appliquer une règle de déconnexion qui détermine le comportement de tous les volumes d’un groupe de cohérence :
Étapes
1. Utilisez la commande ll pour afficher la règle de déconnexion actuelle (le cas échéant) appliquée au groupe de cohérence :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG2> ll
Attributes:
Name
Value
-------------------- ---------------------active-clusters
[]
cache-mode
synchronous
detach-rule
.
.
.
2. Utilisez l’une des commandes consistency-group set-detach-rule pour appliquer une règle de déconnexion au groupe de
cohérence :
● Utilisez la commande consistency-group set-detach-rule no-automatic-winner pour définir la règle de
déconnexion sur no-automatic-winner.
Dans l’exemple suivant, la commande est utilisée dans le contexte du groupe de cohérence cible :
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set-detach-rule no-automaticwinner
● Utilisez la commande consistency-group set-detach-rule winner pour spécifier quel est le cluster vainqueur, et le
nombre de secondes que Metro Node attend entre une panne de liaison et la déconnexion du cluster gagnant.
Dans l’exemple suivant, la commande est utilisée dans le contexte racine :
VPlexcli:/> consistency-group set-detach-rule winner --cluster cluster-1 --delay 5s -consistency-groups TestCG
Suppression d’un groupe de cohérence
À propos de cette tâche
Pour supprimer un groupe de cohérence vide :
Étapes
1. Utilisez la commande ls -f pour vérifier qu’il n’y a aucun volume virtuel dans le groupe de cohérence (virtual volumes =
[ ]).
VPlexcli:/> ls clusters/cluster-1/consistency-groups/TestCG
Attributes:
Name
Value
-------------------- ---------------------active-clusters
[]
cache-mode
synchronous
detach-rule
operational-status
[ok]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters
[cluster-1, cluster-2]
virtual-volumes
[]
visibility
[cluster-1, cluster-2]
.
.
.
2. Utilisez la commande consistency-group destroy pour supprimer le groupe de cohérence.
74
Consistency Groups
Pour supprimer un groupe de cohérence du contexte racine :
VPlexcli:/> consistency-group destroy clusters/cluster-1/consistency-groups/TestCG
WARNING: The following items will be destroyed:
Context
--------------------------------------------/clusters/cluster-1/consistency-groups/TestCG
Do you wish to proceed? (Yes/No)Yes
Pour supprimer un groupe de cohérence du contexte d’un groupe de cohérence :
VPlexcli:/clusters/cluster-1/consistency-groups> destroy TestCG
WARNING: The following items will be destroyed:
Context
--------------------------------------------/clusters/cluster-1/consistency-groups/TestCG
Do you wish to proceed? (Yes/No)Yes
Affichage des propriétés d’un groupe de cohérence
Vous pouvez afficher les propriétés d’un groupe de cohérence.
Utilisez la commande ls dans le contexte /clusters/*/consistency-groups pour afficher le nom des groupes de cohérence sur
tous les clusters uniquement :
VPlexcli:/> ls /clusters/*/consistency-groups/
/clusters/cluster-1/consistency-groups:
TestCG
local_test
test10
test11
test15
test16
test5
test6
vs_RAM_c1wins vs_RAM_c2wins vs_oban005 vs_sun190
/clusters/cluster-2/consistency-groups:
TestCG
local_test
test10
test11
test15
test16
test5
test6
vs_RAM_c1wins vs_RAM_c2wins vs_oban005 vs_sun190
test12
test7
test13
test8
test14
test9
test12
test7
test13
test8
test14
test9
Utilisez la commande ls dans le contexte /clusters/cluster-name/consistency-groups pour afficher le nom des groupes de
cohérence sur le cluster spécifié uniquement :
VPlexcli:/> ls /clusters/cluster-1/consistency-groups/
/clusters/cluster-1/consistency-groups:
TestCG
test10
test11 test12 test13 test14 test15
test8 test9 vs_RAM_c1wins vs_RAM_c2wins
vs_oban005 vs_sun190
test16
test5
test6
test7
Utilisez la commande ll dans le contexte /clusters/cluster-name/consistency-groups pour afficher une présentation des
groupes de cohérence.
Utilisez cette commande pour surveiller l’intégrité globale des groupes de cohérence et identifier les règles mal configurées :
VPlexcli:/clusters/cluster-1/consistency-groups> ll
Name
Operational Status
Active
Rule
Cache Mode
------------------- ---------------------------- Clusters
------------------- ------------------------------ --------------------------- ---------------------------- -----------D850-008_view1
(cluster-1,{ summary:: ok,
cluster-1
wins synchronous
details:: [] }),
(cluster-2,{ summary:: ok,
details:: [] })
D850-008_view2
(cluster-1,{ summary:: ok,
wins synchronous
details:: [] }),
(cluster-2,{ summary:: ok,
details:: [] })
RAM_LR_cluster-1
(cluster-1,{ summary:: ok,
synchronous
Passive
Detach
Clusters
---------cluster-2
active-cluster-
cluster-1,
active-cluster-
cluster-2
Consistency Groups
75
RAM_RR_cluster-2
winner synchronous
.
.
.
details:: [] }),
(cluster-2,{ summary::
unknown, details:: [] })
(cluster-1,{ summary:: ok,
no-automatic-
details:: [] }),
(cluster-2,{ summary:: ok,
details:: [] })
Utilisez la commande ls dans le contexte /clusters/cluster-name/consistency-groups/consistency-group pour
afficher l’état opérationnel des groupes.
Dans l’exemple suivant, la commande affiche l’état opérationnel d’un groupe de cohérence sur un système Metro Node fonctionnel :
VPlexcli:/> ls /clusters/cluster-1/consistency-groups/cg1
/clusters/cluster-1/consistency-groups/cg1:
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [] }),
(cluster-2,{ summary:: ok, details:: [] })]
passive-clusters
[]
read-only
false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
Name
Description
------------ ----------advanced
Utilisez la commande ll dans le contexte /advanced d’un groupe de cohérence pour afficher les propriétés avancées du groupe de
cohérence spécifié.
VPlexcli:/clusters/cluster-1/consistency-groups/TestCG/advanced> ls
Name
Value
-------------------------- -------auto-resume-at-loser
true
current-queue-depth
current-rollback-data
default-closeout-time
delta-size
local-read-override
true
max-possible-rollback-data maximum-queue-depth
potential-winner
write-pacing
disabled
L’exemple suivant affiche le résultat de la commande ls dans le contexte /clusters/cluster-name/ consistency-groups/
consistency-group lors d’une panne de liaison intercluster.
● L’état detach-rule est no-automatic-winner, ce qui indique que les E/S s’arrêtent sur les deux clusters. Metro Node reste
dans cet état jusqu’à ce que la liaison intercluster redémarre ou que vous interagissez à l’aide de la commande consistency-group
choose-winner.
● L’état summary est suspended, ce qui indique que les E/S sont arrêtées.
● L’état details comporte cluster-departure, ce qui indique que les clusters ne peuvent plus communiquer les uns avec les
autres.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
76
Consistency Groups
cache-mode
detach-rule
operational-status
synchronous
no-automatic-winner
[(cluster-1,{ summary:: suspended, details:: [cluster-departure] }),
(cluster-2,{ summary:: suspended, details:: [cluster-departure] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
● La commande ls affiche le groupe de cohérence cg1 comme suspendu, du fait de l’option requires-resume-at-loser sur le
cluster-2, après que le cluster-2 a été déclaré comme cluster perdant lors d’une panne de liaison intercluster.
● La commande resume-at-loser redémarre les E/S sur le cluster-2.
● La commande ls affiche la modification de l’état opérationnel :
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [] }),
(cluster-2,{ summary:: suspended, details:: [requires-resume-atloser] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> resume-at-loser -c cluster-2
This may change the view of data presented to applications at cluster cluster-2. You
should first stop applications at that cluster. Continue? (Yes/No) Yes
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [] }),
(cluster-2,{ summary:: ok, details:: [] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
Tableau 11. Description des champs de groupe de cohérence
Propriété
Description
Propriétés standard
cache mode
synchronous (par défaut) – Les écritures sont effectuées de manière synchrone. Les
écritures ne sont pas confirmées sur un hôte, sauf si elles ont été envoyées vers le
stockage back-end de tous les clusters.
detach-rule
Règle de sélection automatique d’un cluster gagnant en cas de panne de liaison
intercluster. Un cluster gagnant est conçu pour reprendre les opérations d’E/S en cas
d’échec de la liaison.
● no-automatic-winner – Le groupe de cohérence ne sélectionne pas de cluster
gagnant.
Consistency Groups
77
Tableau 11. Description des champs de groupe de cohérence (suite)
Propriété
Description
● winner – Le cluster défini par nom-cluster est déclaré vainqueur si une panne
de liaison intercluster dure plus longtemps que le nombre de secondes défini par le
délai.
storage-at-clusters
Cluster dans lequel se trouve le stockage physique associé à un groupe de cohérence.
● Modifiable à l’aide de la commande set. Si le nom des clusters est cluster-1 et
cluster-2, les valeurs valides sont les suivantes :
○ cluster-1 – Le stockage associé au groupe de cohérence se situe
uniquement sur le cluster-1.
○ cluster-2 – Le stockage associé au groupe de cohérence se situe
uniquement sur le cluster-2.
○ cluster-1,cluster-2 – Le stockage associé au groupe de cohérence se
situe à la fois sur le cluster-1 et le cluster-2.
● Une fois modifiée, la nouvelle valeur ne peut pas être incompatible avec les volumes
qui sont déjà dans le groupe de cohérence. Modifiez la propriété storage-atclusters uniquement lorsque le groupe de cohérence ne possède pas de volumes
membres.
visibility
Répertorie les clusters sur lesquels le groupe de cohérence est visible.
● Modifiable à l’aide de la commande set. Si le nom des clusters est cluster-1 et
cluster-2, les valeurs valides sont les suivantes :
○ cluster-1 – Le groupe de cohérence est visible uniquement sur le cluster-1.
○ cluster-2 – Le groupe de cohérence est visible uniquement sur le cluster-2.
○ cluster-1,cluster-2 – Le groupe de cohérence est visible à la fois sur le
cluster-1 et le cluster-2.
● La modification de cette propriété modifie l’endroit où le groupe de cohérence est
visible ; cela peut faire apparaître ou disparaître des contextes dans l’arborescence
de contextes.
virtual-volume
Répertorie les volumes virtuels qui sont membres du groupe de cohérence. Modifiable à
l’aide des commandes suivantes :
● consistency-group add-virtual-volumes – Ajoutez un ou plusieurs
volumes virtuels spécifiés à un groupe de cohérence.
● consistency-group remove-virtual-volumes – Supprimez un ou
plusieurs volumes virtuels d’un groupe de cohérence.
Propriétés avancées
auto-resume-at-loser
Propriétés d’affichage uniquement
78
Consistency Groups
Détermine si les E/S reprennent automatiquement sur le cluster déconnecté pour les
volumes d’un groupe de cohérence lorsque le cluster retrouve la connectivité avec son
cluster homologue.
● Applicable uniquement pour les groupes de cohérence multiclusters qui contiennent
des volumes distribués.
● Modifiable à l’aide de la commande set. Définissez cette propriété sur true pour
permettre aux volumes de reprendre les E/S sans intervention de l’utilisateur (avec
la commande resume-at-loser).
● true – Les E/S reprennent automatiquement sur le cluster perdant une fois la
liaison intercluster restaurée.
● false (par défaut) – Les E/S doivent être reprises manuellement une fois la liaison
intercluster restaurée.
● Laissez cette propriété sur false pour laisser aux administrateurs le temps de
redémarrer l’application. Dans le cas contraire, les données corrompues dans le
cache de l’hôte ne sont pas cohérentes avec l’image sur le disque sur lequel le
cluster gagnant a activement écrit. Définir cette propriété sur true peut entraîner
une modification spontanée de la vue des données présentées aux applications
sur le cluster perdant. La plupart des applications ne peuvent pas tolérer cette
modification de données. Si l’hôte vide ces pages corrompues de la séquence,
l’image de données peut être corrompue.
Tableau 11. Description des champs de groupe de cohérence (suite)
Propriété
Description
active-clusters
Pour les groupes de cohérence synchrones, cette propriété est toujours vide ([ ]).
operational status
État actuel du groupe de cohérence par rapport à chaque cluster sur lequel il est visible.
● ok – Les E/S peuvent être traitées sur les volumes du groupe de cohérence.
● suspended – Les E/S sont suspendues pour les volumes du groupe de cohérence.
Les causes sont décrites à la section operational status: details.
● degraded – Les E/S se poursuivent, mais il existe d’autres problèmes, comme
décrit à la section operational status: details.
● unknown – L’état est inconnu, principalement en raison de la perte de la
connectivité de gestion.
operational status: details
Si operational status est ok, ce champ est vide : [ ]. Dans le cas contraire, il
affiche des informations supplémentaires, qui peuvent correspondre à l’un des éléments
suivants :
● cluster-departure – Certains clusters visibles ne sont pas en communication.
● data-safe-failure – Un seul directeur a échoué. Les volumes sont toujours
cohérents après sinistre et restent dans cet état, sauf si un deuxième échec se
produit avant la restauration du premier.
● rebuilding-across-clusters – Un ou plusieurs volumes membres distribués
sont en cours de reconstruction. Au moins un volume du groupe est obsolète sur
le cluster et est en cours de resynchronisation. Si la liaison est interrompue à ce
moment-là, l’ensemble du groupe de cohérence est suspendu. Utilisez la commande
rebuild status pour afficher le volume qui est obsolète sur le cluster.
● rebuilding-within-cluster – Une ou plusieurs reconstructions locales sont en cours
sur le cluster.
● requires-resolve-conflicting-detach – Après la restauration de la
liaison intercluster, deux clusters ont détecté qu’ils se sont déconnectés l’un de
l’autre et ont repris les E/S indépendamment. Les clusters continuent à traiter les
E/S sur leurs versions indépendantes des données. La commande consistencygroup resolve-conflicting-detach doit être utilisée pour rendre la vue
des données cohérente au niveau des clusters.
● requires-resume-after-rollback – Un cluster a déconnecté son cluster
homologue et a restauré l’affichage des données, mais attend la commande
consistency-group resume-after-rollback avant de reprendre les
E/S. Affichage :
○ Il n’y a aucune règle de déconnexion.
○ Si la règle de déconnexion est no-automatic-winner ; ou
○ Si la règle de déconnexion ne peut pas se déclencher, car les conditions ne sont
pas respectées.
￭ unhealthy-devices – Les E/S se sont arrêtées dans ce groupe de
cohérence, car un ou plusieurs volumes sont défectueux et ne peuvent pas
exécuter d’E/S.
￭ will-rollback-on-link-down – Si une liaison est immédiatement
hors service, le cluster gagnant doit restaurer l’affichage des données afin de
reprendre les E/S.
virtual-volumes
Liste des volumes virtuels membres du groupe de cohérence.
Utilisation d’un groupe de cohérence
La bonne pratique consiste à autoriser les E/S à se poursuivre sur un seul cluster. Autoriser la poursuite des E/S sur les deux clusters
entraîne une resynchronisation totale d’un cluster par rapport à l’autre. Toutes les écritures du cluster perdant sont perdues.
À propos de cette tâche
Lorsque les E/S continuent sur les deux clusters :
● Les images de données au niveau des clusters divergent.
Consistency Groups
79
● Les branches de volumes distribués sont logiquement séparées.
Lorsque le lien intercluster est restauré, les clusters détectent que les E/S ont été effectuées de manière indépendante. Les E/S
continuent sur les deux clusters jusqu’à ce que vous choisissiez un cluster gagnant dont l’image de données est utilisée comme source
pour synchroniser les images de données.
Dans l’exemple suivant, les E/S ont repris sur les deux clusters lors d’une panne du lien intercluster. Lorsque le lien intercluster est
restauré, les deux clusters rétablissent le contact et détectent qu’ils ont chacun déconnecté l’autre et effectué les opérations d’E/S.
Étapes
1. Utilisez la commande ls pour afficher l’état opérationnel du groupe de cohérence sur les deux clusters.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
-------------------- ----------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [requires-resolve-conflictingdetach] }),
(cluster-2,{ summary:: ok, details:: [requires-resolve-conflicting-detach] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters
[cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
2. Utilisez la commande resolve-conflicting-detach pour sélectionner le cluster-1 comme gagnant.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> resolve-conflicting-detach -c
cluster-1
This will cause I/O to suspend at clusters in conflict with cluster cluster-1, allowing
you to stop applications at those clusters. Continue? (Yes/No) Yes
Les modifications du cluster-2 apportées aux données sur les volumes dans le groupe de cohérence depuis le début de la panne du lien
sont ignorées.
L’image de données du cluster-2 est ensuite synchronisée avec l’image sur le cluster-1.
Les E/S sont suspendues au niveau du cluster-2 si la stratégie de reprise automatique est définie sur false.
3. Utilisez la commande ls pour vérifier la modification de l’état opérationnel :
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [] }),
(cluster-2,{ summary:: suspended, details:: [requires-resume-atloser] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
● Au niveau du cluster-1, les E/S se poursuivent et l’état est ok.
● Sur le cluster-2, la vue des données a changé et, par conséquent, les E/S sont suspendues.
4. Utilisez la commande consistency-group resume-at-loser pour reprendre les E/S vers le groupe de cohérence sur le
cluster-2.
80
Consistency Groups
Reprise des E/S après restauration
À propos de cette tâche
Sans ces données, l’image de données du cluster gagnant est incohérente. La reprise des E/S au niveau du gagnant nécessite la
restauration de l’image de données du gagnant au dernier point où les clusters correspondaient.
Cela peut entraîner un changement soudain dans l’image de données.
De nombreuses applications ne peuvent pas tolérer des modifications soudaines des données, la restauration et la reprise des E/S
nécessitent donc une intervention manuelle.
Le délai donne à l’administrateur la possibilité d’interrompre les applications avant de modifier l’image de données. L’image de données est
restaurée dès qu’un gagnant est choisi (manuellement ou automatiquement à l’aide d’une règle de déconnexion).
La commande resume-after-rollback confirme que l’application est prête pour la récupération (cela peut impliquer une défaillance de
l’application et/ou le redémarrage de l’hôte).
REMARQUE : Il est recommandé de redémarrer les hôtes des applications concernées.
Étapes
1. Utilisez la commande ls pour afficher le groupe de cohérence sur le cluster gagnant lors d’une panne de lien intercluster.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
-------------------- ------------------------------------------active-clusters
[]
cache-mode
synchronous
detach-rule
operational-status
[suspended, requires-resume-after-rollback]
passive-clusters
[cluster-1, cluster-2]
recoverpoint-enabled false
storage-at-clusters
[cluster-1, cluster-2]
virtual-volumes
[dd1_vol]
visibility
[cluster-1, cluster-2
Contexts:
advanced recoverpoint
2. Utilisez la commande resume-after-rollback pour confirmer que l’application est prête pour la récupération.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> resume-after-rollback --consistencygroup cg1
This will change the view of data at cluster cluster-1, so you should ensure applications
are stopped at that cluster. Continue? (Yes/No) Yes
3. Utilisez la commande ls pour afficher la modification de l’état opérationnel.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
-------------------- ---------------------active-clusters
[cluster-1]
cache-mode
synchronous
detach-rule
operational-status
[ok]
passive-clusters
[cluster-2]
recoverpoint-enabled false
storage-at-clusters
[cluster-1, cluster-2]
virtual-volumes
[dd1_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
Consistency Groups
81
Reprise des E/S sur le cluster perdant
Lors d’une panne de lien entre clusters, vous pouvez autoriser les E/S à reprendre sur l’un des deux clusters, le cluster gagnant.
À propos de cette tâche
Les E/S restent suspendues sur le cluster perdant.
Lors de la restauration du lien entre clusters, les clusters gagnants et perdants se reconnectent, et le cluster perdant détecte que le
cluster gagnant a repris les E/S sans ce dernier.
Sauf configuration explicite, les E/S restent suspendues sur le cluster perdant. Cela empêche les applications du cluster perdant de subir
une modification spontanée des données.
Le délai vous permet d’arrêter les applications.
Après avoir arrêté les applications, utilisez la commande consistency-group resume-at-loser pour :
● Resynchroniser l’image de données sur le cluster perdant avec l’image de données sur le cluster gagnant.
● Reprendre le traitement des opérations d’E/S.
Vous pouvez ensuite redémarrer les applications en toute sécurité sur le cluster perdant.
Pour redémarrer les E/S sur le cluster perdant :
Étapes
1. Utilisez la commande ls pour afficher l’état opérationnel du groupe de cohérence cible.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [] }),
(cluster-2,{ summary:: suspended, details:: [requires-resume-atloser] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
Contexts:
advanced recoverpoint
2. Utilisez la commande consistency-group resume-at-loser pour redémarrer les E/S sur le cluster perdant.
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> resume-at-loser -c cluster-2
This may change the view of data presented to applications at cluster cluster-2. You
should first stop applications at that cluster. Continue? (Yes/No) Yes
3. Utilisez la commande ls pour vérifier la modification de l’état opérationnel :
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls
Attributes:
Name
Value
------------------- ---------------------------------------------------------active-clusters
[cluster-1, cluster-2]
cache-mode
synchronous
detach-rule
no-automatic-winner
operational-status
[(cluster-1,{ summary:: ok, details:: [] }),
(cluster-2,{ summary:: ok, details:: [] })]
passive-clusters
[]
recoverpoint-enabled false
storage-at-clusters [cluster-1, cluster-2]
virtual-volumes
[dd1_vol, dd2_vol]
visibility
[cluster-1, cluster-2]
82
Consistency Groups
Contexts:
advanced recoverpoint
Vous remarquerez peut-être l’état opérationnel rebuilding-across-clusters lors de la reconstruction des appareils.
Définition de l’attribut en lecture seule
Les appareils R2 SRDF (réplicas) constituent un exemple de volume de continuité d’activité (BCV, Business Continuance Volume) géré par
une baie. Pour les groupes de cohérence qui contiennent ces volumes, vous pouvez utiliser la commande set pour définir le groupe de
cohérence en lecture seule.
À propos de cette tâche
Si l’attribut en lecture seule est défini sur true, le système empêche les opérations d’écriture sur les volumes virtuels dans le groupe de
cohérence. Les volumes virtuels d’un groupe de cohérence en lecture seule doivent être locaux, et vous devez mapper chaque volume
virtuel un-à-un vers un volume de stockage unique (par exemple, RAID 0 local sans découpage).
Vous ne pouvez pas ajouter de volumes virtuels avec une topologie non valide à un groupe de cohérence en lecture seule. La commande
consistency-group add-virtual-volumes échoue. Si vous définissez un groupe de cohérence en lecture seule et que ce
groupe de cohérence contient déjà des volumes virtuels avec une topologie non valide, la commande set read-only true échoue.
Un groupe de cohérence ne peut pas être défini sur read-only et recoverpoint-enabled en même temps, puisque les deux
propriétés ne sont pas compatibles.
Étapes
Utilisez la commande set pour définir le groupe de cohérence en lecture seule.
VPlexcli:/> cd/clusters/cluster-1/consistency-groups/test
VPlexcli:/clusters/cluster-1/consistency-groups/test>set read-only true
VPlexcli:/clusters/cluster-1/consistency-groups>ll
Name
Operational Active Passive Detach Rule Cache Mode Read
------ Status
Clusters Clusters ---------- --------Only
------- ----------- ------- -------- ---------- --------- ---DB2_app (Hopkinton,{ winner Hopkinton after 5s synchronous true
summary:: ok,
details:: []
}),
Providence, {
summary:: ok,
details:: []
})
Consistency Groups
83
10
Performances et surveillance
Ce chapitre décrit le RPO/RTO et les procédures de création et d’utilisation des analyseurs de performances.
Sujets :
•
•
•
•
•
•
À propos des performances
À propos de la surveillance des performances
Surveillance des performances avec l’interface CLI
Surveillance des ports
Statistiques
Tableaux de statistiques
À propos des performances
Ce chapitre aborde les sujets suivants en ce qui concerne les performances des systèmes Metro Node :
● Configuration – Paramètres modifiables permettant d’optimiser les performances et de gérer la perte de données maximale admissible
(RPO) et l’objectif de temps de reprise (RTO).
● Surveillance – Outils et techniques permettant de surveiller les performances Metro Node, et d’identifier et de diagnostiquer les
problèmes.
RPO et RTO
Perte de données maximale admissible (RPO) : le RPO (Recovery Point Objective) correspond à l’intervalle de temps entre le point de
défaillance d’un système de stockage et le point dans le passé à partir duquel le système de stockage devrait être en mesure de restaurer
les données client.
Le RPO représente la quantité maximale de perte de données que l’application peut tolérer après une défaillance. La valeur du RPO dépend
fortement de la technique de restauration utilisée. Par exemple, le RPO se compte généralement en jours pour les sauvegardes et en
minutes pour les réplications asynchrones, tandis que pour la mise en miroir ou la réplication synchrone, il se compte en secondes ou est
instantané.
Objectif de temps de reprise (RTO) : le RTO (Recovery Time Objective) correspond au délai dans lequel une solution de stockage est
censée récupérer après une panne et commencer à traiter les demandes des applications.
Le RTO représente la panne d’application tolérable la plus longue en raison d’une défaillance d’un système de stockage. Le RTO est une
fonction de la technologie de stockage. Il peut se mesurer en heures pour les systèmes de sauvegarde, en minutes pour une réplication à
distance et en secondes (ou moins) pour une mise en miroir.
À propos de la surveillance des performances
Les analyseurs de performances collectent et affichent des statistiques afin de déterminer la manière dont un port ou un volume est utilisé,
le nombre d’E/S en cours de traitement, l’utilisation du processeur, etc.
La surveillance des performances est supportée à la fois dans l’interface CLI Metro Node et dans Unisphere, et se divise en trois
types globaux :
● Le contrôle de la charge actuelle permet aux administrateurs d’observer la charge du processeur pendant les mises à niveau et la
charge des E/S sur la liaison WAN intercluster, et de comparer les charges frontales et back-end pendant le data mining ou la
sauvegarde.
Le contrôle de la charge actuelle est supporté dans Unisphere.
● Le contrôle de charge à long terme collecte des données pour la planification de la capacité et l’équilibrage de charge.
Le contrôle de la charge à long terme est supporté par les analyseurs créés dans l’interface CLI et/ou les analyseurs perpétuels.
84
Performances et surveillance
● La surveillance du dépannage permet d’identifier les goulots d’étranglement et les monopoles de ressources.
Les analyseurs de dépannage sont supportés par les analyseurs qui sont créés dans l’interface CLI et/ou les analyseurs perpétuels.
REMARQUE : Dans Unisphere for Metro Node, les statistiques de performances sont affichées par cluster. Pour afficher les
statistiques des deux clusters en configuration Metro, connectez-vous aux deux clusters.
Analyseurs personnalisés
Vous pouvez utiliser l’interface CLI pour créer des moniteurs personnalisés afin de collecter et d’afficher les statistiques sélectionnées pour
les cibles sélectionnées.
Voir la section Surveillance des performances avec l’interface CLI.
Analyseurs perpétuels
GeoSynchrony inclut des analyseurs perpétuels qui collectent un ensemble standard de statistiques de performances toutes les
30 secondes. Les analyseurs perpétuels collectent des statistiques sur les performances des directeurs et des volumes virtuels
Metro Node.
Les fichiers des analyseurs perpétuels sont collectés dans le cadre de la commande collect-diagnostics. La commande collectdiagnostics s’exécute par cluster. Par conséquent, en configuration Metro, exécutez la commande à partir des deux serveurs de gestion
Metro Node.
La sortie des analyseurs perpétuels est capturée dans le fichier smsDump_date.zip du fichier zip collect-diagnostics de base.
Dans le fichier smsDump_date.zip, les fichiers des analyseurs se trouvent dans clilogs/.
Vous pouvez également copier les fichiers perpétuels à partir du serveur de gestion. Ils se trouvent dans /var/log/VPlex/cli/. Il
existe un fichier d’analyseur perpétuel par directeur, identifiable par le mot-clé « PERPETUAL ».
Vous trouverez ci-dessous un exemple des statistiques collectées par les analyseurs perpétuels sur des volumes virtuels :
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.1
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.2
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.3
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.4
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.5
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.6
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.7
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.8
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.9
director-1-1-A_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.10
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.1
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.2
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.3
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.4
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.5
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.6
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.7
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.8
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.9
director-1-1-B_VIRTUAL_VOLUMES_PERPETUAL_MONITOR.log.10
Surveillance des performances avec Unisphere for Metro Node
Le tableau de bord sur la surveillance des performances offre une vue personnalisée des performances de votre système. Vous décidez
des aspects des performances du système à afficher et comparer.
Performances et surveillance
85
Figure 9. Tableau de bord sur la surveillance des performances (pour HTML5)
Les informations sur les performances pour l’actuelle fenêtre de 5 minutes s’affichent sous la forme d’un ensemble de graphiques,
notamment :
● Graphique sur les performances de liaison du WAN : affiche les performances de liaison du WAN pour le cluster auquel vous êtes
connecté. Utilisez ce graphique pour surveiller les performances de liaison afin de mieux déterminer les exigences en bande passante
de votre environnement spécifique, de collecter des données statistiques au fil du temps, de surveiller le trafic réseau pendant les
périodes de pointe ou de planifier des tâches de mobilité des données afin d’éviter toute période d’utilisation de pointe.
● Graphique sur la latence du WAN : fournit une vue temporelle de la latence du WAN. Les catégories avg-lat/min-lat/max-lat
consignent chacune les valeurs observées au cours des 5 dernières secondes ou moins.
● Graphique sur le delta de latence des écritures : indique le delta entre la latence frontale et la latence back-end par directeur.
Il s’agit d’un indicateur clé pour les configurations Metro/Local qui précise la surcharge de temps que Metro Node consacre au
traitement d’une écriture.
● Diagramme sur les erreurs back-end : affiche les erreurs d’E/S back-end depuis et vers la baie de stockage. Il existe
trois catégories d’erreurs back-end : les abandons, les délais d’expiration et les réinitialisations.
● Diagramme sur le débit back-end : affiche les E/S back-end par seconde au fil du temps pour les directeurs. En général, le débit
(plus communément appelé E/S par seconde) est associé aux E/S de petits blocs (demandes d’E/S de 4 Ko ou de 16 Ko).
● Diagramme sur la bande passante back-end : indique le nombre de lectures et d’écritures back-end par seconde au fil du temps
pour les directeurs. En général, la bande passante (mesurée en Ko/s ou Mo/s) est associée aux E/S de blocs volumineux (demandes
de 64 Ko ou plus).
● Graphique sur la latence back-end : fournit des informations détaillées au fil du temps et sous forme graphique sur les statistiques
de latence back-end pour votre système Metro Node. Le graphique vous permet d’afficher les données de performances actuelles
ou historiques que vous pouvez utiliser pour surveiller les charges applicatives de pointe, détecter les problèmes de performances ou
afficher ce qui se passe dans le système lorsqu’un problème spécifique s’est produit.
● Tableau de bord sur l’état des reconstructions : affiche l’état des opérations de reconstruction ou de migration qui s’exécutent
sur votre système Metro Node.
● Graphique sur l’utilisation du processeur : fournit une vue temporelle de la charge d’utilisation du processeur du directeur principal
sur votre système Metro Node. Par défaut, le graphique affiche une moyenne des charges d’utilisation de tous les directeurs de votre
système Metro Node.
● Diagramme sur l’utilisation des segments de mémoire : indique le pourcentage de la mémoire segmentée utilisée par le firmware
sur un directeur.
● Diagramme sur les abandons frontaux : affiche le nombre d’abandons par seconde au fil du temps pour les directeurs sur votre
système Metro Node. Par défaut, le graphique affiche une moyenne des abandons frontaux pour le système Metro Node.
● Diagramme sur la bande passante frontale : affiche le nombre de lectures et d’écritures frontales par seconde au fil du temps
pour les directeurs sur votre système Metro Node. Par défaut, le graphique affiche la bande passante frontale totale pour le système
Metro Node.
● Graphique sur la latence frontale : fournit des informations détaillées au fil du temps et sous forme graphique sur les statistiques
de latence frontale pour votre système Metro Node. Le graphique vous permet d’afficher les données de performances actuelles ou
historiques que vous pouvez utiliser pour surveiller les charges applicatives de pointe, détecter les problèmes de performances ou
afficher ce qui se passe dans le système lorsqu’un problème spécifique s’est produit.
● Diagramme sur la profondeur de la file d’attente frontale : indique le nombre d’opérations frontales par directeur. Il décrit le
nombre d’opérations simultanées inachevées actives dans le système.
● Diagramme sur le débit frontal : affiche le nombre d’E/S frontales par seconde au fil du temps pour les directeurs sur votre
système Metro Node. Par défaut, le graphique affiche le débit frontal total pour le système Metro Node.
86
Performances et surveillance
● Diagramme sur le débit de volume virtuel : fournit une vue temporelle du débit total ou des E/S par seconde d’un volume virtuel.
En général, le débit (plus communément appelé E/S par seconde) est associé aux E/S de petits blocs (demandes d’E/S de 512 o ou
de 16 Ko).
● Graphique sur la latence de volume virtuel : fournit une vue temporelle de la latence des E/S d’un volume virtuel, décomposée en
latence des lectures et latence des écritures. La latence de volume virtuel est définie en fonction de la durée que passe une E/S dans
Metro Node pour un volume virtuel donné.
● Diagramme sur la bande passante de volume virtuel : fournit une vue temporelle de la bande passante totale (ou ko/s ou Mo/s)
des lectures et des écritures pour un volume virtuel. En général, la bande passante (désignée en Ko/s ou Mo/s) est associée aux E/S
de blocs volumineux (demandes de 64 Ko ou plus).
● Tableau de bord sur les ports frontaux : affiche les indicateurs de performances pour tous les ports frontaux nœud Metro Node. Le
tableau de bord ne fournit pas de données historiques. Cependant, il s’actualise toutes les cinq secondes et affiche les données de la
dernière période de cinq secondes.
Surveillance des performances avec l’interface CLI Metro Node
Utilisez l’interface CLI pour créer des analyseurs personnalisés afin de vous aider à diagnostiquer les problèmes de performances.
Deux objets CLI collectent et affichent les statistiques sur les performances :
● monitors - Collectez les statistiques spécifiées depuis la cible spécifiée à l’intervalle spécifié.
● monitor sinks - Dirigez la sortie vers la destination souhaitée. Les récepteurs de moniteur comprennent la console, un fichier, ou une
combinaison des deux.
Surveillance des performances avec l’interface CLI
Cette section décrit la procédure de création d’un analyseur personnalisé avec l’interface CLI Metro Node.
À propos de la rotation et de l’horodatage des fichiers
Les fichiers journaux créés par le récepteur de fichiers d’un analyseur sont automatiquement soumis à rotation lorsqu’ils atteignent la taille
de 10 Mo. Le fichier de 10 Mo est enregistré sous le nom filename.csv.n, où n est un chiffre de 1 à 10, et le résultat est enregistré
dans un nouveau fichier nommé filename.csv.n+1.
Les fichiers .csv peuvent faire l’objet de 10 rotations au plus.
Dans l’exemple suivant, la sortie d’un analyseur a dépassé les 10 Mo. Les 10 Mo initiaux sont enregistrés dans filename.csv.1. Le
résultat suivant est enregistré dans filename.csv.
service@sms-cluster-1:/var/log/VPlex/cli> ll my-data.csv*
-rw-r--r-- 1 service users 2910722 2012-03-06 21:23 my-data.csv
-rw-r--r-- 1 service users 10566670 2012-03-06 21:10 my-data.csv.1
Si le deuxième fichier dépasse les 10 Mo :
● Le précédent fichier filename.csv.1 est remplacé par filename.csv.2
● Le fichier filename.csv est remplacé par filename.csv.1
● Le résultat suivant est enregistré dans filename.csv
Jusqu’à 10 rotations de ce type, les fichiers .csv numérotés sont pris en charge.
Lorsque le récepteur de fichiers est supprimé ou que l’analyseur est détruit, le résultat vers le fichier .csv s’interrompt, et le fichier .csv
en cours est horodaté. Par exemple :
service@sms-cluster-1:/var/log/VPlex/cli> ll my-data.csv*
-rw-r--r-- 1 service users 10566670 2012-03-06 21:23 my-data.csv.1
-rw-r--r-- 1 service users 5637498 2012-03-06 21:26 my-data.csv_20120306092614973
Performances et surveillance
87
Présentation de la procédure : créer un analyseur à l’aide de
l’interface CLI
Pour créer et utiliser un analyseur à l’aide de l’interface CLI, suivez les étapes générales suivantes :
1. Déterminez le type de statistiques à collecter à partir de l’objet cible.
Utilisez la commande monitor stat-list category ou monitor stat-list * pour afficher les statistiques à intégrer au
moniteur.
Reportez-vous aux tableaux de la section Statistiques pour obtenir la liste des statistiques par catégorie.
Notez si les statistiques que vous souhaitez collecter nécessitent la spécification d’une cible.
Spécifiez un seul type de cible par analyseur. Par exemple, vous ne pouvez pas créer d’analyseur qui inclut à la fois le port et les
volumes de stockage en tant que cibles.
2. Déterminez la fréquence à laquelle l’analyseur doit collecter des statistiques.
3. Utilisez la commande monitor create pour créer un analyseur.
4. Utilisez les commandes monitor add-sink pour ajouter un ou plusieurs récepteurs à l’analyseur.
● Ajoutez un récepteur de console pour envoyer les données de performances à la console de gestion Metro Node.
● Ajoutez un récepteur de fichiers pour envoyer les données de performances vers un fichier spécifique.
5. Répétez les étapes 3 et 4 pour chaque directeur.
6. L’analyseur démarre l’opération (interrogation et collecte des données de performances) lorsque le récepteur est ajouté à l’analyseur.
Pour désactiver l’interrogation automatique sans supprimer l’analyseur ou ses récepteurs, effectuez l’une des opérations suivantes :
● Utilisez la commande set pour modifier l’attribut period de l’analyseur sur 0.
● Utilisez la commande set pour modifier l’attribut enabled du récepteur sur false.
7. Utilisez la commande monitor collect pour mettre à jour et collecter les statistiques immédiatement sans attendre la prochaine
collecte automatique de l’analyseur.
8. Surveillez la sortie.
Les récepteurs de console affichent la sortie de l’analyseur sur la console.
Pour les récepteurs de fichiers, accédez à /var/log/VPlex/cli/ sur le serveur de gestion et utilisez la commande tail -fnom
de fichier pour afficher la sortie.
ou :
Envoyez la sortie vers un fichier CSV, ouvrez le fichier dans Microsoft Excel et créez un graphique.
Ne modifiez PAS le fichier CSV dans Microsoft Excel, et enregistrez le fichier. Excel supprime le champ seconds, ce qui entraîne des
horodatages en doublon. Utilisez Excel pour consulter les fichiers CSV, mais sans enregistrer vos modifications.
9. Utilisez la commande monitor destroy pour supprimer l’analyseur :
Création d’un analyseur
Utilisez la commande monitor create pour créer un analyseur et spécifier les statistiques collectées par l’analyseur.
À propos de cette tâche
Reportez-vous à l’aide en ligne pour obtenir la une liste exhaustive des statistiques de l’analyseur de performances.
Créez un analyseur simple avec la période par défaut et aucune cible :
VPlexcli:/monitoring> monitor create --name TestMonitor --director director-2-1-B --stats
director.fe-read,director.fe-write
Successfully created 1 monitor(s) out of 1.
Créez un analyseur pour collecter les statistiques de la catégorie du directeur sur /engines/engine-1-1/directors/director-1-1-A toutes les
10 secondes :
VPlexcli:/monitoring> monitor create --name DirStats --period 10s --director /clusters/
cluster-1/directors/director-1-1-A --stats director.*
88
Performances et surveillance
Créez un analyseur pour collecter des statistiques sur tous les volumes de stockage du cluster-1 :
VPlexcli:/monitoring> monitor create --name SVStats-Cluster1 --director /clusters/cluster-1/
directors/director-1-1-A --stats storage-volume.* --targets /clusters/cluster-1/storageelements/storage-volumes/*
Créez un analyseur pour collecter toutes les statistiques frontales sur le port frontal I0-01 :
VPlexcli:/monitoring> monitor create --name FE-FC01-stats --director /clusters/
cluster-1/directors/director-1-1-A --stats fe-prt.* --targets /clusters/cluster-1/directors/
director-1-1-A/ports/IO-01
Créez un analyseur de performances pour surveiller la latence du COM local pour un directeur spécifique :
VPlexcli:/> monitor create --name local-cluster --stats "com-cluster-io.*" --director
director-1-1-A --targets "/clusters/cluster-1"
Créez un analyseur de performances pour surveiller la latence vers le cluster distant :
VPlexcli:/> monitor create --name remote-cluster --stats "com-cluster-io.*" --director
director-1-1-A --targets "/clusters/cluster-2"
Ajout/suppression de récepteurs d’analyseur
Chaque analyseur doit avoir au moins un récepteur et peut en avoir plusieurs. Il existe deux types de récepteurs :
À propos de cette tâche
console : envoie la sortie vers la console du serveur de gestion Metro Node.
file : envoie la sortie vers le fichier spécifié.
Ajout d’un récepteur de console
Utilisez la commande monitor add-console-sink pour ajouter un récepteur de console à un analyseur existant.
À propos de cette tâche
Les analyseurs de console affichent les statistiques sélectionnées sur la console de gestion Metro Node, ce qui interrompt toute autre
entrée/sortie vers/depuis la console. Reportez-vous à la section Activation/désactivation des récepteurs pour la commande permettant
de désactiver un récepteur de console.
Le format par défaut pour les récepteurs de console est « table ».
Pour ajouter un récepteur de console avec la sortie formatée sous forme de tableau (format de sortie par défaut), procédez comme suit :
VPlexcli:/> monitor add-console-sink --monitor Director-2-1-B_TestMonitorNavigate to the monitor
context and use the ll console command to display the sink:
VPlexcli:/> cd monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor/sinks
VPlexcli:/monitoring/directors/Director-2-1-B/monitors/Director-2-1-B_TestMonitor/sinks> ll
Name
Enabled Format Sink-To
------- ------- ------ ------console true
table
console
VPlexcli:/monitoring/directors/Director-2-1-B/monitors/Director-2-1-B_TestMonitor/sinks> ll
console
/monitoring/directors/Director-2-1-B/monitors/Director-2-1-B_TestMonitor/sinks/console:
Name
Value
------- ------enabled true
format
table
sink-to console
type
console
Performances et surveillance
89
Ajout d’un récepteur de fichiers
Utilisez la commande monitor add-file-sink pour ajouter un récepteur de fichiers à un analyseur existant.
À propos de cette tâche
Le format par défaut des récepteurs de fichiers est CSV (valeurs séparées par des virgules).
Le nom par défaut du nouveau récepteur est file.
L’emplacement par défaut du résultat du récepteur est /var/log/VPlex/cli.
Pour ajouter un récepteur de fichiers afin d’envoyer le résultat vers le fichier .csv spécifié :
VPlexcli:/monitoring/directors/director-1-1-A/monitors> monitor add-file-sink
director-1-1-A_stats --file /var/log/VPlex/cli/director_1_1_A.csv
--monitor
Accédez au contexte des récepteurs d’analyseur et utilisez la commande ll nom-récepteur pour afficher le récepteur :
VPlexcli:/> cd monitoring/directors/director-1-1-A/monitors/director-1-1-A_stats/sinks
VPlexcli:/monitoring/directors/Director-1-1-A/monitors/director-1-1-A_stats/sinks> ll file
/monitoring/directors/Director-1-1-A/monitors/director-1-1-A_stats/sinks/file:
Name
Value
------- ------------------------------enabled true
format
csv
sink-to /var/log/VPlex/cli/director_1_1_A.csv
type
file
Suppression d’un récepteur d’analyseur
Utilisez la commande monitor remove-sink pour supprimer un récepteur d’un analyseur :
À propos de cette tâche
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor> monitor
remove-sink console
Suppression d’un analyseur
Utilisez la commande monitor destroy monitor pour supprimer l’analyseur spécifié.
À propos de cette tâche
Par exemple :
VPlexcli:/monitoring/directors/director-1-1-B/monitors> monitor destroy director-1-1B_TestMonitor
WARNING: The following items will be destroyed:
Context
-----------------------------------------------------------------------/monitoring/directors/director-1-1-B/monitors/director-1-1-B_TestMonitor
Do you wish to proceed? (Yes/No) y
Créer un analyseur SNMP
Les récepteurs SNMP peuvent uniquement s’ajouter aux analyseurs configurés pour collecter des statistiques sur les disques ou les fe-lu.
Toutes les statistiques de la catégorie de statistiques fe-lu doivent être incluses dans l’analyseur.
Dans l’exemple suivant :
● La commande monitor stat-list fe-lu affiche toutes les statistiques de la catégorie fe-lu.
● La commande monitor create crée un analyseur pour collecter toutes les statistiques fe-lu.
● La commande cd modifie le contexte par le nouvel analyseur.
90
Performances et surveillance
● La commande add-snmp-sink ajoute un récepteur SNMP à l’analyseur.
VPlexcli:/monitoring/directors/director-1-1-B/monitors> monitor stat-list fe-lu
Name
Target
Type
Units
--------------- -------------- ------- -------fe-lu.ops
virtual-volume counter counts/s
fe-lu.read
virtual-volume counter KB/s
fe-lu.read-lat
virtual-volume bucket
us
fe-lu.write
virtual-volume counter KB/s
fe-lu.write-lat virtual-volume bucket
us
VPlexcli:/monitoring/directors/director-1-1-B/monitors> monitor create --name
SNMPTestMonitor --director director-1-1-B --stats fe-lu.read,fe-lu.readlat,fe- lu.write,fe-lu.write-lat,fe-lu.ops --targets /clusters/cluster-1/virtual-volumes/
polyvol_e4_extent_Symm0487_393
Successfully created 1 monitor(s) out of 1.
VPlexcli:/monitoring/directors/director-1-1-B/monitors> cd director-1-1-B_SNMPTestMonitor
VPlexcli:/monitoring/directors/director-1-1-B/monitors/director-1-1-B_ SNMPTestMonitor>
add-snmp-sink --name fe-lu-stats
Displaying monitors
Utilisez la commande ls /monitoring/directors/*/monitors pour afficher le nom de tous les analyseurs configurés sur le
système :
VPlexcli:/> ls /monitoring/directors/*/monitors
/monitoring/directors/director-1-1-A/monitors:
DEFAULT_director-1-1-A_PERPETUAL_vplex_sys_perf_mon_v8
director-1-1-A_Billy35_FE_A0-FC00_stats
director-1-1-A_director-fe-21112011
director-1-1-A_diskReportMonitor
.
.
.
/monitoring/directors/director-1-1-B/monitors:
DEFAULT_director-1-1-B_PERPETUAL_vplex_sys_perf_mon_v8
.
.
.
Utilisez la commande ll /monitoring/directors/*/monitors pour afficher des informations récapitulatives sur tous les
analyseurs pour le contexte et l’objet spécifiés :
VPlexcli:/> ll /monitoring/directors/director-1-1-A/monitors
/monitoring/directors/director-1-1-A/monitors:
Name
Ownership Collecting Period
Bucket Bucket
------------------------------------- Data
-----Width
Count
------------------------------- --------- ---------- ----------- -----director-1-1-A_FE_A0-FC00
false
false
5s
64
director-1-1-A_director-fe
false
false
5s
64
director-1-1-A_ipcom-21112011
false
false
5s
64
director-1-1-A_portReportMon
false
false
5s
64
.
.
.
Average
Idle
Bucket
Bucket
Period
For
Min
Max
-------
----
------
------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Utilisez la commande ll /monitoring/directors/*/monitors/nom-analyseur pour afficher des informations détaillées sur
l’ensemble de l’analyseur spécifié :
VPlexcli: ll /monitoring/directors/director-2-1-B/monitors/director-2-1-B_volumeReportMonitor
Attributes:
Name
Value
--------------- -------------------------------------------------------------average-period
bucket-count
64
bucket-max
-
Performances et surveillance
91
bucket-min
bucket-width
collecting-data
firmware-id
idle-for
ownership
period
statistics
targets
true
9
5.44days
true
0s
[virtual-volume.ops, virtual-volume.read,
virtual-volume.write]
DR1_C1-C2_1gb_dev10_vol, DR1_C1-C2_1gb_dev11_vol,
DR1_C1-C2_1gb_dev12_vol, DR1_C1-C2_1gb_dev13_vol,
DR1_C1-C2_1gb_dev14_vol, DR1_C1-C2_1gb_dev15_vol,
DR1_C1-C2_1gb_dev16_vol, DR1_C1-C2_1gb_dev17_vol,
DR1_C1-C2_1gb_dev18_vol, DR1_C1-C2_1gb_dev19_vol, ... (1300
total)
Contexts:
Name
Description
----- -----------------------------------------------------------------------sinks Contains all of the sinks set up to collect data from this performance
monitor.
Utilisez la commande ll /monitoring/directors/*/monitors/nom-analyseur/sinks pour afficher les récepteurs associés à
l’analyseur spécifié :
VPlexcli: ll /monitoring/directors/director-2-1-B/monitors/director-2-1-B_volumeReportMonitor/
sinks
/monitoring/directors/bob70/monitors/bob70_volumeReportMonitor/sinks:
Name Enabled Format Sink-To
---- ------- ------ -------------------------------------------------------file true
csv
/var/log/VPlex/cli/reports/volumeReportMonitor_bob70.csv
Tableau 12. Description des champs d’analyseur et de récepteur
Champ
Description
average-period
Période d’échantillonnage moyenne réelle.
collecting-data
Indique si l’analyseur de performances collecte ou non des données. Un analyseur collecte des
données s’il possède au moins un récepteur activé.
firmware-id
ID de micrologiciel de l’analyseur.
idle-for
Temps écoulé depuis le dernier accès à l’analyseur de performances dans le micrologiciel.
name
Nom unique à échelle du directeur de l’analyseur de performances, destiné à être significatif
pour l’utilisateur.
ownership
Indique si l’analyseur a été créé dans cette instance de la console de gestion Metro Node.
period
Période d’échantillonnage en secondes.
statistics
Liste des statistiques sur les performances surveillées.
targets
Liste des cibles qui s’appliquent aux statistiques sur les performances surveillées. Une cible
peut être un port, un volume de stockage ou un volume virtuel. Certaines statistiques ne
requièrent pas de cibles.
Champs d’affichage des récepteurs de l’analyseur
Name
Pour les récepteurs de fichiers, nom du contexte de récepteur créé. La valeur par défaut est
« file ».
Enabled
Indique si le récepteur de l’analyseur est activé ou désactivé.
Format
Format de sortie exigé. Peut être csv ou table. La valeur par défaut est csv pour les
récepteurs de fichiers et table pour les récepteurs de console.
Sink-To
Pour les récepteurs de fichiers, nom de fichier dans lequel recevoir les données.
92
Performances et surveillance
Activation/désactivation/modification d’une interrogation
L’interrogation (collecte des statistiques spécifiées) débute lorsque le premier récepteur est ajouté à un analyseur. L’interrogation se
produit automatiquement à l’intervalle défini par l’attribut period de l’analyseur.
À propos de cette tâche
Utilisez la commande set pour modifier la période d’interrogation.
Utilisez la commande monitor collect pour exécuter immédiatement une collecte, avant son intervalle d’interrogation défini.
Utilisez la commande set pour désactiver ou modifier l’interrogation automatique d’un analyseur.
Dans l’exemple suivant :
● La commande set change l’attribut de période en 0, ce qui désactive l’interrogation automatique.
● La commande ll affiche la modification :
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor> set
period 0
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor> ll
Attributes:
Name
Value
--------------- -------------------------------------------------------------average-period
bucket-count
64
bucket-max
bucket-min
bucket-width
collecting-data false
firmware-id
4
idle-for
5.78min
ownership
true
period
0s
.
.
.
Pour réactiver l’interrogation, utilisez la commande set pour modifier l’attribut de période en choisissant une valeur différente de zéro.
Activation/désactivation des récepteurs
Utilisez la commande set pour activer ou désactiver un récepteur d’analyseur.
À propos de cette tâche
Pour désactiver un récepteur d’analyseur :
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor/sinks/
console> set enabled false
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor/sinks/
console> ll
Name
Value
------- ------enabled false
format
table
sink-to console
type
console
Pour activer un récepteur d’analyseur :
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor/sinks/
console> set enabled true
VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor/sinks/
console> ll
Name
Value
------- ------enabled true
Performances et surveillance
93
format
sink-to
type
table
console
console
Exécution forcée d’une interrogation immédiate
Utilisez la commande monitor collect pour forcer une interrogation immédiate et la collecte des données de performances sans
attendre l’intervalle d’interrogation automatique.
Par exemple :
VPlexcli:/> monitor collect /monitoring/directors/director-2-1-B/monitors/director-2-1B_TestMonitor
Source:
Time:
director.be-ops (counts/s):
.
.
.
director-2-1-B_TestMonitor
2010-07-01 10:05:55
Surveillance des ports
Détails sur le script port-stats-monitor.
Mise en route
Le script port-stats-monitor peut être utilisé pour identifier les ports Metro Node qui identifient des problèmes. Le système
Metro Node peut rencontrer, ou non, à un problème en raison des problèmes que le script port-stats-monitor identifie. Toutefois, cela
indique qu’il existe un problème dans le SAN qui doit être traité avant qu’il n’affecte Metro Node. Ces problèmes peuvent être ou ne pas
être spécifiques à Metro Node. Parfois, il peut être obligatoire de désactiver les ports problématiques identifiés par le script comme ayant
ou présentant un problème jusqu’à ce que le problème de SAN soit localisé et résolu.
Le script de surveillance des ports FC est doté des fonctionnalités suivantes :
● Il interroge uniquement les ports FC Metro Node une fois par minute et envoie un e-mail à l’adresse e-mail configurée s’il détecte un
problème de structure potentiel.
● Il identifie explicitement le cluster, le directeur et le port qui rencontrent le problème de structure.
● Il crée un rapport sur les paires initiateur-cible FC dégradées.
● Les seuils du script peuvent être modifiés dans le fichier de configuration JSON.
● Il supprime les rapports d’erreurs au bout de 5 minutes, après quoi un e-mail récapitulatif qui décrit les rapports d’erreur de port
pendant la période de suppression des e-mails est envoyé.
REMARQUE : Il est prévu que le support travaille avec l’utilisateur final pour déployer le script de surveillance permettant de
configurer le script port-stats-monitor pour l’adresse du serveur de messagerie et la liste d’adresses e-mail des personnes qui
souhaitent recevoir les rapports que le script envoie.
Exemple : port-monitor start [--email <e-mail>,<e-mail>,…]
Configuration du script pour l’envoi des rapports par e-mail
Démarrez le script et connectez-vous au serveur de messagerie (SMTP) de l’utilisateur final.
VPlexcli:/> port-monitor start --smtp <mail server ip address> -e [<email>,<email>,...]
REMARQUE : Une fois le script démarré, sa sortie est enregistrée dans le fichier ports-stats-monitor.log, qui est visible
sous /var/log/VPlex/cli.
94
Performances et surveillance
Vérification de l’état du script
Étapes
1. Vérifiez l’état du script pour voir s’il est en cours d’exécution.
VPlexcli:/> port-monitor status
Status: running with the following parameters:
Emails: joe@dell.com
SMTP: x.x.x.x
Local-only: False
2. Pour vous assurer que le script redémarre en cas de reboot ou de redémarrage du serveur de gestion, vous pouvez renforcer
la persistance en ajoutant la commande utilisée pour redémarrer le script via Starting the script sur le fichier VPlex-init
dans /var/log/VPlex/cli directory, comme indiqué à cette étape. Utilisez l’éditeur vi et ajoutez la ligne de commande de
démarrage du script à la fin du fichier /var/log/VPlex/cli/VPlexcli-init.
Sample output:
service@ManagementServer:/var/log/VPlex/cli> vim VPlexcli-init
#------------------------------------------------------------------------------#- (C) 2007-2010 EMC Corporation. All rights reserved.
##- This CLI initialization script is executed if it's located in any of the
#- following locations:
#- (CLI terminates the search on first success.)
#- if the --init-file option is specified on the command line then use that file
#- else search for the file "VPlexcli-init" in the following order:
#a. CLI directory (specified with the --cli-directory option)
#b. current dir (of the shell that started CLI)
#c. user.dir (usually equivalent to the current dir)
#d. user.home
#e. classpath
#- This script is processed as if it had been sourced using the 'source' command
#------------------------------------------------------------------------------.
.
ll /monitoring/directors/*/monitors/
#
#
<new entry added below at the end of VPlex-init file,
script -i port_stats_monitor
port-monitor start –smtp <mail server ip address> -e <email>,<email>,...>
Ajout de seuils (si nécessaire)
Étapes
Sur le serveur de gestion (ou les deux avec la version Metro), créez un répertoire port-stats-monitor et copiez le fichier
matériel config.json spécifique (VS2 ou VS6) que vous avez vu plus tôt, après avoir décompressé le fichier port-statsmonitor_6.2.zip dans le répertoire nouvellement créé.
a. Créez le répertoire /var/log/VPlex/cli/port-stats-monitor.
Exemple : mkdir /var/log/VPlex/cli/port-stats-monitor
b. Copiez le fichier matériel <vsX>_config.json qui convient dans ce répertoire pour le matériel Metro Node sur lequel vous
travaillez. Exemples : cp vs2-config.json /var/log/VPlex/cli/port-stats-monitor/config.json ou cp vs6config.json /var/log/VPlex/cli/port-stats-monitor/config.json.
REMARQUE : À l’étape c, n’apportez aucune modification à l’issue du chargement du script. Laissez le script de l’analyseur
s’exécuter quelques instants. En présence de problèmes de performance, l’utilisateur final reçoit des alertes par e-mail à ce sujet
et doit contacter le support Metro Node pour obtenir de l’aide. Accédez à l’étape d, bien que ce soit uniquement pour confirmer
Performances et surveillance
95
que l’analyseur s’exécute. À l’étape d, faites défiler la fenêtre vers le bas jusqu’à lire « Checking status » et exécutez uniquement
cette commande pour l’instant. Les étapes c et d doivent être suivies pour les deux clusters avec la version Metro.
c. Modifiez les seuils par défaut dans le fichier config.json (en option). Si vous pensez qu’une ou plusieurs des valeurs par
défaut peuvent être augmentées de sorte à obtenir de meilleurs résultats, vous pouvez modifier le fichier config.json pour
définir de nouvelles valeurs de seuil (à l’aide de l’éditeur VI). Exemple : vim /var/log/VPlex/cli/port-stats-monitor/
config.json.
Sample Output:
{
"bad_CRC": 5,
"Disc_frame": 40,
"link_fail": 15,
"Loss_of_sync": 45,
"loss_of_sig": 45,
"reset": 5
}
d. Après avoir apporté des modifications au fichier config.json, vous devez redémarrer le script de l’analyseur de ports.
VPlexcli:/> port-monitor restart
VPlexcli:/> port-monitor status
Status: running with the following parameters:
Emails: joe@dell.com <<< this will only show e-mail addresses if configured
SMTP: x.x.x.x
Local-only: False
Threshold config: {u'lr-remote': 5, u'crc-errors': 50, u'invalid-transmissionword': 500, u'link-failure': 10, u'loss-of-signal': 45, u'loss-of-sync': 60}
Informations sur l’utilisation de port-stats-monitor
Utilisation : extrait du script 6.2.x
Port Stats Monitoring
A prodscript for monitoring critical statistics for ports.
## What does this monitor do?
The monitor periodically logs VPLEX FC port statistics and can notify via email if critical
stats have increased past their threshold within a minute interval.
## Usage
After importing the prodscript with `script -i port_stats_monitor`, 5 commands are created:
port-monitor
port-monitor
port-monitor
port-monitor
port-monitor
restart
start
status
stop
test-email
Restart all monitor threads.
Start periodically monitoring for port stat changes
Display the status of the port monitor thread
Stop any in-progress port stat monitor threads.
Test the monitor's email notification.
### Starting the monitor
To start the monitor, run:
` port-monitor start [--email <email>,<email>...]`
options (* = required):
-h | --help
Displays the usage for this command.
--verbose
Provides more output during command execution. This may not have any effect for
some commands.
-e | --email= <emails> [, <emails> ...]
Comma-separated email addresses to notify upon detecting a failure
--smtp= <smtp>
SMTP server address to use for notification emails
--local-only
96
Performances et surveillance
Poll only cluster-local directors
VPlexcli:/> port-monitor start -e example@emc.com
Starting port stat monitor...
### Stopping the monitor
To stop the monitor, run `port-monitor stop`.
### Checking status
To see whether or not the monitor is running, or to see if any unexpected errors were
encountered, run the `port-monitor status` command:
VPlexcli:/> port-monitor status
Status: running with the following parameters:
Emails: None
SMTP: x.x.x.x
Local-only: False
Threshold config: None
### Restarting the monitor
If you wish to restart a stopped monitor with the same parameters as before, run `portmonitor restart`. If you wish to use different options, use the `start` command documented
above.
## Configuring the driver-specific thresholds
The thresholds may be overridden by placing a JSON file at
/var/log/VPlex/cli/port-stats-monitor/config.json, with each key representing a stat to
monitor and the value representing the threshold at which to notify the user. Example
contents of the config.json:
{
"crc-errors": 40,
"link-failure": 15,
"loss-of-sync": 45,
"loss-of-signal": 45,
"invalid-transmission-word": 40,
"lr-remote": 5
}
Exemple de sortie
Exemple de sortie d’e-mail qui peut être envoyée au contact.
From: VPLEX Port Stat Notifier [mailto:vplex-port-stat-notifier@dell.com]
Sent: Day, Month date, YYYY H:MM <AM/PM>
To: <recipient>
Subject: VPlex Port Stat Notification for x.x.x.x <Serial Number>
The port stat monitor detected a problem.
Historical data is located in /var/log/VPlex/cli/port-stats-monitor.log
Current thresholds: crc-errors: 40, invalid-transmission-word: 40, link-failure: 15, loss-ofsignal: 45, loss-of-sync: 45
In the last 60 seconds:
director-1-1-A A1-FC03 (back-end) crc-errors has increased
director-1-1-A A1-FC02 (back-end) crc-errors has increased
director-1-1-A A1-FC01 (back-end) crc-errors has increased
director-1-1-A A1-FC00 (back-end) crc-errors has increased
The following I-Ts on director-1-1-A were banished:
x fcp i 0xc00144878f0e0800 t 0x500601683660190e
by
by
by
by
10924
9541
13655
14982
The following additional reports from the last hour were suppressed:
2019-03-22 14:21:12
director-1-1-B B0-FC02 (front-end) crc-errors has increased by 13354
Performances et surveillance
97
director-1-1-B B0-FC03 (front-end) crc-errors has increased by 19255
director-1-1-B B0-FC00 (front-end) crc-errors has increased by 15254
director-1-1-B B0-FC01 (front-end) crc-errors has increased by 953630
Éléments à prendre en compte
Consignez le nombre de ports et de directeurs qui créent un rapport signalant un problème. Par exemple, si la moitié des ports créent un
rapport signalant un problème, cela peut indiquer un événement à l’échelle de la structure. En revanche, si un seul port crée un rapport
d’erreur, ce problème est localisé sur un nexus IT spécifique.
Le script est conçu pour supprimer les e-mails au bout de 5 minutes (pour ne pas surcharger le serveur de messagerie). À ce stade, il ne
crée de rapport qu’une fois par heure. Le firmware qui se connecte au serveur de gestion contient tous les rapports, y compris ceux qui
ont été supprimés de la messagerie.
Le tableau suivant contient une liste des statistiques surveillées. Les éléments surveillés dépendent du type de matériel (VS2 ou VS6) et
du niveau de code GeoSynchrony. Bien que le script puisse s’appliquer à un niveau de code SP1 6.0 (6.0.1.00.00.08) et plus, ce qu’il peut
surveiller dépend de la disponibilité des statistiques sous-jacentes. Reportez-vous à la section Accessoires (restreints) ci-dessous pour une
vue étendue de ce tableau.
Journalisation : le fichier de journalisation port-stats-monitor.log se trouve sur le serveur de gestion dans /var/log/
VPlex/cli/ directory. Ce fichier journal collecte des données brutes. La commande grep [grep "back-end\|front-end\|
wan-com" /var/log/VPlex/cli/port-stats-monitor.log] peut générer un récapitulatif lié à l’erreur signalée dans le fichier
port-stats-monitor.log.
Example:
grep "back-end\|front-end\|wan-com" /var/log/VPlex/cli/port-stats-monitor.log
/var/log/VPlex/cli/port-stats-monitor.log.9:director-1-1-B
transmission-word has increased by 2956
/var/log/VPlex/cli/port-stats-monitor.log.9:director-1-1-B
has increased by 443
/var/log/VPlex/cli/port-stats-monitor.log.9:director-1-1-B
transmission-word has increased by 3494
/var/log/VPlex/cli/port-stats-monitor.log.9:director-1-1-B
has increased by 528
/var/log/VPlex/cli/port-stats-monitor.log.9:director-1-1-B
transmission-word has increased by 5996
Statistiques
Metro Node collecte et crée des rapports sur trois types de statistiques :
98
Performances et surveillance
B1-FC02 (back-end) invalidB1-FC02 (back-end) loss-of-sync
B1-FC02 (back-end) invalidB1-FC02 (back-end) loss-of-sync
B1-FC02 (back-end) invalid-
● Compteurs : valeur à augmentation monolithique (semblable au compteur kilométrique d’une voiture)
○ Les compteurs sont utilisés pour comptabiliser les octets, les opérations et les erreurs.
○ Souvent indiqué sous la forme d’un taux comme nombre/seconde ou Ko/seconde.
● Mesures : valeur instantanée (semblable à l’indicateur de vitesse d’une voiture)
○ Les mesures sont utilisées pour indiquer l’utilisation du processeur, la mémoire.
○ La valeur peut changer pour chaque échantillon.
● Moyennes par période : moyenne d’une série calculée sur la dernière période d’échantillonnage. Si :
○ current_reading_sum est la somme de toutes les mesures pour la statistique donnée depuis la création de l’analyseur.
○ previous_reading_sum est le compte de toutes les mesures pour la statistique depuis la création de l’analyseur.
○ period-average = (current_reading_sum - previous_reading_sum) / (current_reading_count - previous_reading_count)
La plupart des statistiques nécessitent la spécification d’un port ou d’un volume cible. Le résultat de la commande monitor stat-list
identifie les statistiques qui nécessitent la définition d’une cible, ainsi que le type de cible obligatoire lors de la création d’un analyseur.
Figure 10. Surveillance des cibles
Affichage des statistiques disponibles
Les statistiques sont regroupées en sous-catégories.
Utilisez la commande monitor stat-list suivie de la touche <Tab> pour afficher les sous-catégories de statistiques. Par exemple :
VPlexcli:/> monitor stat-list be-prt, cache, cg, director, directory, fc-com-port, fedirector, fe-lu, fe-prt, ip-com-port, ramf, rdma, storage-volume, virtual-volume, wrt-pacing
Utilisez l’option --categories categories pour afficher les statistiques disponibles dans la catégorie spécifiée. Par exemple :
VPlexcli:/monitoring> monitor stat-list --categories director
Name
Target Type
Units
--------------------- ------ ------- -------director.be-aborts
n/a
counter counts/s
director.be-ops
n/a
counter counts/s
director.be-ops-read
n/a
counter counts/s
director.be-ops-write n/a
counter counts/s
director.be-read
n/a
counter KB/s
.
.
.
Utilisez le caractère générique * pour afficher toutes les statistiques pour toutes les catégories.
Par exemple :
VPlexcli:/> monitor stat-list *
Name
Target
Type
Units
----------------------------------------------- ----------------- ------- -------be-prt.read
backend-port
counter KB/s
be-prt.write
backend-port
counter KB/s
cache.dirty
n/a
reading KB
cache.miss
n/a
counter counts/s
cache.rhit
n/a
counter counts/s
cache.subpg
n/a
counter counts/s
cg.closure
consistency-group bucket
us
cg.delta-util
consistency-group reading %
Performances et surveillance
99
cg.drain-lat
cg.exch-bytes
cg.exch-lat
cg.exch-pages
cg.input-bytes
cg.input-ops
cg.inter-closure
cg.outOfDate-counter
cg.pipe-util
cg.write-bytes
cg.write-lat
cg.write-pages
.
.
.
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
consistency-group
bucket
counter
bucket
counter
counter
counter
bucket
counter
reading
counter
bucket
counter
us
KB/s
us
counts/s
KB/s
counts/s
us
counts/s
%
KB/s
us
counts/s
Statistiques sur les performances frontales
Metro Node collecte des statistiques détaillées sur les performances de ses volumes virtuels, qui incluent principalement les statistiques
de lecture et d’écriture avec la taille d’E/S et les informations de LBA. Vous pouvez utiliser ces données pour identifier et résoudre les
problèmes de performance des E/S avec Metro Node.
Cette fonctionnalité est activée par défaut dans Metro Node. Les statistiques collectées sont disponibles dans le fichier
fe_perf_stats_<timestamp>.log du dossier /var/log/VPlex/cli/. Le fichier comprend les informations suivantes :
Tableau 13. Statistiques sur les performances frontales
Champ
Description
vol
Nom du disque virtuel
File d’attente activée
Nom de la file d’attente
POS
Numéro de série de la tâche dans la file d’attente
I
WWN du port initiateur
T
WWN du port cible
status
État interne ou état du cache
temps
Temps d’exécution de la tâche d’E/S (dans usec)
opcode
Code d’opération de la commande (le cas échéant)
LBA
Valeur de l’élément d’adresse de bloc logique (LBA) dans la
commande (le cas échéant)
len
Blocs ou octets en cours de transfert ou de vérification (le cas
échéant)
Pour gérer les performances de la collecte des statistiques frontales, utilisez ces commandes dans n’importe quel contexte de
l’interface CLI Metro Node :
● front-end-performance-stats stop - arrête une collecte de statistiques sur les performances en cours.
● front-end-performance-stats start - démarre une collecte de statistiques sur les performances en cours.
● front-end-performance-stats status - affiche l’état de la collecte de statistiques détaillées sur les performances frontales.
REMARQUE : Pour plus d’informations sur les commandes, reportez-vous au document CLI Reference Guide for metro node (Guide
de référence de l’interface CLI pour Metro Node).
Tableaux de statistiques
Les tableaux suivants répertorient les statistiques de chaque catégorie :
● Statistiques sur les ports back-end Fibre Channel (be-prt)
● Statistiques sur les caches
100
Performances et surveillance
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Statistiques sur les directeurs
Statistiques sur les directeurs frontaux (fe-director)
Statistiques sur les volumes frontaux (fe-lu)
Statistiques sur les ports frontaux (fe-prt)
Statistiques sur les RAID distants (ramf) Statistiques sur les RAID distants (ramf)
Statistiques sur les volumes de stockage
Statistiques sur les volumes virtuels
Statistiques IP COM WAN (ip-com-port) : surveille les ports IP (n’importe quel port dont le nom comporte GE ou XG)
Statistiques de contrôle des congestions IP
Statistiques sur les E/S de cluster COM
Statistiques sur les chemins COM
Statistiques sur les points de terminaison COM
Statistiques sur l’adaptateur XCOPY
Statistiques sur les initiateurs hôtes
Tableau 14. Statistiques sur les ports back-end Fibre Channel (be-prt)
Statistiques
Type
Description
be-prt.read
Lecture de ports back-end
Nombre d’octets lus via le port FC spécifié.
Écriture de ports back-end
Nombre d’octets écrits via le port FC spécifié.
type : compteur ; unités : octets/seconde ;
arguments : port#
be-prt.write
type : compteur ; unités : octets/seconde ;
arguments : port#
Tableau 15. Statistiques sur les directeurs
Statistiques
Type
Description
director.async-write
Écritures back-end
Nombre d’écritures asynchrones en Ko/seconde.
director.be-aborts
Opérations back-end
Nombre d’opérations d’E/S abandonnées via les ports backend du directeur.
director.be-busies
Opérations back-end
Nombre de notifications d’occupation sur le directeur.
director.be-ops
Opérations back-end
Nombre d’opérations d’E/S exécutées via les ports backend du directeur.
Lecture back-end
Nombre de lectures réalisées par les ports back-end du
directeur.
Écritures back-end
Nombre d’écritures réalisées par les ports back-end du
directeur.
director.be-ops-ws
Opérations back-end
Nombre d’opérations WriteSame back-end
director.be-qfulls
Écritures back-end
Nombre de notifications complètes en file d’attente pour le
port back-end.
director.be-read
Lecture back-end
Nombre d’octets lus par les ports back-end du directeur.
director.be-resets
Compteur
Nombre de réinitialisations back-end par seconde.
director.be-timeouts
Compteur
Nombre d’expirations back-end par seconde.
type : compteur ; unités : nombre/seconde ;
arguments : aucun
type : compteur ; unités : nombre/seconde ;
arguments : aucun
director.be-ops-read
type : compteur ; unités : nombre/seconde ;
arguments : aucun
director.be-ops-write
type : compteur ; unités : nombre/seconde ;
arguments : aucun
type : compteur ; unités : octets/seconde ;
arguments : aucun
Performances et surveillance
101
Tableau 15. Statistiques sur les directeurs (suite)
Statistiques
Type
Description
director.be-unitattns
Compteur
Nombre d’interventions sur l’unité back-end par seconde.
director.be-write
Écritures back-end
Nombre d’octets écrits par les ports back-end du directeur
Opération WriteSame
back-end
Détail des opérations WriteSame back-end.
CPU
Pourcentage d’utilisation du processeur.
Octets de communication
actifs
Nombre d’octets actifs vers un directeur distant.
Octets de communication
en file d’attente
Nombre d’octets en file d’attente vers un directeur distant.
Opérations de
communication actives
Nombre d’opérations actives vers un directeur distant.
Opérations de
communication en file
d’attente
Nombre d’opérations en file d’attente vers un directeur
distant.
Octets de reconstruction
reçus
Nombre d’octets reçus par le nœud à partir du ou des
nœuds distants pour le trafic de reconstruction (lectures
et/ou écritures).
Octets de reconstruction
envoyés
Nombre d’octets envoyés par le nœud à ou aux nœuds
distants pour le trafic de reconstruction (lectures et/ou
écritures)
Opération frontale
Nombre d’opérations d’E/S exécutées via les ports frontaux
du directeur.
Opération frontale active
Nombre d’opérations d’E/S inachevées actives sur les ports
frontaux du directeur.
Opération frontale en file
d’attente
Nombre d’opérations d’E/S inachevées en file d’attente sur
les ports frontaux du directeur.
Lecture frontale
Nombre de lectures réalisées sur les ports frontaux du
directeur.
Écriture frontale
Nombre d’écritures réalisées sur les ports frontaux du
directeur.
type : compteur ; unités : octets/seconde ;
arguments : aucun
director.be-ws
type : compteur ; unités : octets/seconde ;
arguments : aucun
director.busy
type : mesure ; unités : pourcentage ;
arguments : aucun
director.com-bytes-active
type : mesure ; unités : nombre ;
arguments : target-director
director.com-bytes-queued
type : mesure ; unités : nombre ;
arguments : target-director
director.com-ops-active
type : mesure ; unités : nombre ;
arguments : target-director
director.com-ops-queued
type : mesure ; unités : nombre ;
arguments : target-director
director.dr1-rbld-recv
type : compteur ; unités : octets/seconde ;
arguments : aucun
director.dr1-rbld-sent
type : compteur ; unités : octets/seconde ;
arguments : aucun
director.fe-ops
type : compteur ; unités : nombre/seconde ;
arguments : aucun
director.fe-ops-act
type : mesure ; unités : nombre ;
arguments : aucun
director.fe-ops-q
type : mesure ; unités : nombre ;
arguments : aucun
director.fe-ops-read
type : compteur ; unités : nombre/seconde ;
arguments : aucun
director.fe-ops-write
102
Performances et surveillance
Tableau 15. Statistiques sur les directeurs (suite)
Statistiques
Type
Description
Lecture frontale
Nombre d’octets lus à partir des ports frontaux du directeur.
Écriture frontale
Nombre d’octets écrits sur les ports frontaux du directeur.
Mémoire
Pourcentage d’utilisation de la mémoire sur le directeur.
Occupation du processeur
Utilisation totale (utilisateur et système) de chaque
processeur dans le directeur.
director.msg-send-ops
Nombre d’opérations
Nombre total de messages envoyés à partir du directeur.
director.msg-max-lat
Latence maximale
Latence maximale des messages envoyés à partir du
directeur.
director.msg-min-lat
Latence minimale
Latence minimale des messages envoyés à partir du
directeur.
director.msg-avg-lat
Latence moyenne
Latence moyenne des messages envoyés à partir du
directeur.
type : compteur ; unités : nombre/seconde ;
arguments : aucun
director.fe-read
type : compteur ; unités : octets/seconde ;
arguments : aucun
director.fe-write
type : compteur ; unités : octets/seconde ;
arguments : aucun
director.heap-used
type : mesure ; unités : pourcentage ;
arguments : aucun
director.per-cpu-busy
type : mesure ; unités : pourcentage ;
arguments : aucun
Tableau 16. Statistiques sur les directeurs frontaux (fe-director)
Statistiques
Type
Description
fe-director.aborts
Opération frontale
Nombre d’opérations d’E/S abandonnées via les ports
frontaux du directeur.
Latence des opérations
CompareAndWrite
Latence des opérations CompareAndWrite en microsecondes
sur les ports frontaux du directeur spécifié. Le bucket de
latence est ramené à trois buckets, de 0 à la valeur maximale,
au lieu des 64 buckets de latence collectés au sein du
firmware Metro Node.
Latence de lecture du
directeur frontal
Distribution de la latence des lectures en microsecondes sur
les ports frontaux du directeur.
Latence d’écriture du
directeur frontal
Distribution de la latence des écritures en microsecondes sur
les ports frontaux du directeur.
Latence moyenne des
opérations WriteSame du
directeur frontal
Distribution de la latence moyenne des opérations WriteSame
sur les ports frontaux du directeur.
type : compteur ; unités : nombre/seconde ;
arguments : aucun
fe-director.caw-lat
type : bucket ; unités : microseconde ;
arguments : aucun
fe-director.read-lat
type : bucket ; unités : microseconde ;
arguments : aucun
fe-director.write-lat
type : bucket ; unités : microseconde ;
arguments : aucun
fe-director.ws16-avg-lat
type : moyenne par période ; unités : µs ;
arguments : aucun
fe-director.unmap-ops
Opération de suppression Nombre d’opérations de suppression de mappages par
de mappages du directeur seconde exécutées sur le directeur frontal spécifié.
type : compteur ; unités : nombre/seconde ;
frontal
arguments : aucun
Performances et surveillance
103
Tableau 16. Statistiques sur les directeurs frontaux (fe-director) (suite)
Statistiques
Type
Description
fe-director.unmap-avg-lat
Latence moyenne
des suppressions de
mappages du directeur
frontal
Latence moyenne des opérations de suppression de
mappages en microsecondes sur le directeur frontal spécifié.
type : moyenne par période ; unités : µs ;
arguments : aucun
Tableau 17. Statistiques sur les volumes frontaux (fe-lu)
Statistiques
Type
Description
fe-lu.caw-lat
Latence des opérations
CompareAndWrite
Latence des opérations CompareAndWrite en microsecondes
sur le volume frontal spécifié.
Erreur de comparaison
CompareAndWrite
Nombre d’erreurs de comparaison CompareAndWrite sur le
volume frontal spécifié.
Opération
CompareAndWrite
Nombre d’opérations CompareAndWrite sur le volume frontal
spécifié.
Opération sur le volume
frontal
Nombre d’opérations d’E/S sur le volume frontal spécifié.
Lecture sur le volume
frontal
Nombre de lectures sur le volume frontal spécifié.
Latence de lecture sur le
volume frontal
Distribution de la latence des lectures en microsecondes sur le
volume frontal spécifié.
Écriture sur le volume
frontal
Nombre d’écritures sur le volume frontal spécifié.
Latence d’écriture sur le
volume frontal
Distribution de la latence des écritures en microsecondes sur le
volume frontal spécifié.
Latence moyenne des
opérations WriteSame
sur le volume frontal
Distribution de la latence moyenne des opérations WriteSame
sur le volume frontal spécifié.
type : bucket ; unités : microseconde ;
arguments : volume-id
fe-lu.caw-mis
type : compteur ; unités : nombre/seconde ;
arguments : volume-id
fe-lu.caw-ops
type : compteur ; unités : nombre/seconde ;
arguments : volume-id
fe-lu.ops
type : compteur ; unités : nombre/seconde ;
arguments : volume-id
fe-lu.read
type : compteur ; unités : octets/seconde ;
arguments : volume-id
fe-lu.read-lat
type : bucket ; unités : microseconde ;
arguments : volume-id
fe-lu.write
type : compteur ; unités : octets/seconde ;
arguments : volume-id
fe-lu.write-lat
type : bucket ; unités : microseconde ;
arguments : volume-id
fe-lu.ws16-avg-lat
type : moyenne par période ; unités : µs ;
arguments : virtual-volume
fe-lu.ws16-ops
type : compteur ; unités : nombre/seconde ;
arguments : virtual-volume
Opération WriteSame sur Nombre d’opérations WriteSame sur le volume frontal spécifié.
le volume frontal
fe-lu.unmap-ops
Opération suppression de Nombre d’opérations de suppression de mappages par
mappages sur le volume seconde exécutées sur le volume frontal spécifié.
type : compteur ; unités : nombre/seconde ;
frontal
arguments : virtual-volume
fe-lu.unmap-avg-lat
type : moyenne par période ; unités : µs ;
arguments : virtual-volume
104
Performances et surveillance
Latence moyenne
des suppressions de
mappages sur le volume
frontal
Latence moyenne des opérations de suppression de mappages
en microsecondes sur le volume frontal spécifié.
Tableau 18. Statistiques sur les ports frontaux (fe-prt)
Statistiques
Type
Description
fe-prt.caw-lat
Latence des opérations
CompareAndWrite
Latence des opérations CompareAndWrite en microsecondes
sur le port frontal spécifié.
Erreur de comparaison
CompareAndWrite
Nombre d’erreurs de comparaison CompareAndWrite sur le
port frontal spécifié.
Opération
CompareAndWrite
Nombre d’opérations CompareAndWrite sur le port frontal
spécifié.
Opérations sur le port
frontal
Nombre d’opérations d’E/S sur le port FC frontal spécifié.
Lecture sur le port
frontal
Nombre d’octets lus à partir du port FC frontal spécifié.
type : bucket ; unités : microseconde ;
arguments : port#
fe-prt.caw-mis
type : compteur ; unités : nombre/seconde ;
arguments : port#
fe-prt.caw-ops
type : compteur ; unités : nombre/seconde ;
arguments : port#
fe-prt.ops
type : compteur ; unités : nombre/seconde ;
arguments : port#
fe-prt.read
type : compteur ; unités : octets/seconde ;
arguments : port#
fe-prt.read-lat
type : bucket ; unités : microseconde ;
arguments : port#
fe-prt.write
Latence de lecture sur le Distribution de la latence des lectures en microsecondes sur le
port frontal
port FC frontal spécifié.
Écriture sur le port
frontal
Nombre d’octets écrits sur le port FC frontal spécifié.
Latence d’écriture sur le
port frontal
Distribution de la latence des écritures en microsecondes sur le
port FC frontal spécifié.
Latence moyenne des
opérations WriteSame
sur le port frontal
Distribution de la latence moyenne des opérations WriteSame
sur le port FC frontal spécifié.
Opération WriteSame
sur le port frontal
Nombre d’opérations WriteSame sur le port FC frontal spécifié.
Opération de
suppression de
type : compteur ; unités : nombre/seconde ;
mappages sur le port
arguments : port frontal
frontal
Nombre d’opérations de suppression de mappages par seconde
observées sur le port spécifié.
fe-lu.unmap-avg-lat
Latence moyenne des opérations de suppression de mappages
en microsecondes sur le port frontal spécifié.
type : compteur ; unités : octets/seconde ;
arguments : port#
fe-prt.write-lat
type : bucket ; unités : microseconde ;
arguments : port#
fe-prt.ws16-avg-lat
type : moyenne par période ; unités : µs ;
arguments : port frontal
fe-prt.ws16-ops
type : compteur ; unités : nombre/seconde ;
arguments : port frontal
fe-prt.unmap-ops
type : moyenne par période ; unités : µs ;
arguments : port frontal
Latence moyenne des
opérations suppression
de mappages sur le port
frontal
Tableau 19. Statistiques sur les RAID distants (ramf)
Statistiques
Type
Description
ramf.cur-op
Nombre d’opérations en
cours
Nombre instantané d’opérations RAID distantes.
type : mesure ; unités : nombre ;
arguments : aucun
Performances et surveillance
105
Tableau 19. Statistiques sur les RAID distants (ramf) (suite)
Statistiques
Type
Description
ramf.exp-op
Opérations distantes
Nombre total d’E/S par seconde distantes.
Lectures distantes
Lectures distantes à partir d’un autre cluster vers un disque
ou un LUN sur le cluster local.
Écriture distante
Écritures distantes à partir d’un autre cluster vers un disque
ou un LUN sur le cluster local.
Opérations importées
Nombre d’opérations demandées par un directeur donné,
quelle que soit la cible distante.
Lectures importées
Lectures à partir du cluster local vers un disque ou un LUN sur
un cluster distant.
Écritures importées
Écritures à partir du cluster local vers un disque ou un LUN sur
un cluster distant.
Lectures importées
Latence moyenne des lectures distantes à partir du cluster
local vers un disque ou un LUN sur un cluster distant.
Écritures importées
Latence moyenne des écritures distantes à partir du cluster
local vers un disque ou un LUN sur un cluster distant.
type : compteur ; unités : nombre/seconde ;
arguments : aucun
ramf.exp-rd
type : compteur ; unités : octets/seconde ;
arguments : aucun
ramf.exp-wr
type : compteur ; unités : octets/seconde ;
arguments : aucun
ramf.imp-op
type : compteur ; unités : nombre/seconde ;
arguments : aucun
ramf.imp-rd
type : compteur ; unités : octets/seconde ;
arguments : aucun
ramf.imp-wr
type : compteur ; unités : octets/seconde ;
arguments : aucun
ramf.imp-rd-avg-lat
type : moyenne par période ; unités :
microsecondes ; arguments : aucun
ramf.imp-wr-avg-lat
type : moyenne par période ; unités :
microsecondes ; arguments : aucun
Tableau 20. Statistiques sur les volumes de stockage
Statistiques
Type
Description
storage-volume.per-storage-volume-readlatency
Latence de lecture sur le
volume
Distribution de la latence des lectures en microsecondes sur le
volume de stockage spécifié.
Latence d’écriture sur le
volume
Distribution de la latence des écritures en microsecondes sur le
volume de stockage spécifié.
Latence moyenne des
lectures sur le volume
Distribution de la latence moyenne des lectures en
microsecondes sur le volume de stockage spécifié.
Latence moyenne des
écritures sur le volume
Distribution de la latence moyenne des écritures en
microsecondes sur le volume de stockage spécifié.
Latence moyenne des
opérations WriteSame
sur les volumes
Distribution de la latence moyenne des opérations WriteSame
sur tous les volumes de stockage.
type : bucket ; unités : microseconde ;
arguments : volume-id
storage-volume.per-storage-volume-writelatency
type : bucket ; unités : microseconde ;
arguments : volume-id
storage-volume.read-latency
type : bucket ; unités : microseconde ;
arguments : aucun
storage-volume.write-latency
type : bucket ; unités : microseconde ;
arguments : aucun
storage-volume.write-same-avg-lat
106
Performances et surveillance
Tableau 20. Statistiques sur les volumes de stockage (suite)
Statistiques
Type
Description
type : moyenne par période ; unités : µs ;
arguments : aucun
Tableau 21. Statistiques sur les volumes virtuels
Statistiques
Type
Description
virtual-volume.dirty
Volume pollué
Nombre de pages modifiées dans le cache pour le volume
virtuel spécifié.
Opérations de volume
Nombre total d’opérations d’E/S pour le volume virtuel
spécifié.
Lecture sur le volume
Nombre de lectures en octets pour le volume virtuel spécifié.
Écriture sur le volume
Nombre d’écritures en octets pour le volume virtuel spécifié.
type : mesure ; unités : nombre ;
arguments : volume-id
virtual-volume.ops
type : compteur ; unités : nombre/seconde ;
arguments : volume-id
virtual-volume.read
type : compteur ; unités : octets/seconde ;
arguments : volume-id
virtual-volume.write
type : compteur ; unités : octets/seconde ;
arguments : volume-id
Tableau 22. Statistiques IP COM WAN (ip-com-port)
Statistiques
Type
Description
ip-com-port.recv-pckts
Compteur ; unités :
nombre/seconde ;
arguments : port-name
Nombre de paquets reçus via l’UDP sur le port IP COM WAN.
ip-com-port.send-bytes
Compteur ; unités :
octets/seconde ;
arguments : port-name
Nombre d’octets envoyés via l’UDP sur le port IP COM WAN.
ip-com-port.send-drops
Compteur ; unités :
nombre/seconde ;
arguments : port-name
Nombre de paquets envoyés abandonnés sur le port IP
COM WAN.
ip-com-port.send-pckts
Compteur ; unités :
nombre/seconde ;
arguments : port-name
Nombre de paquets envoyés via l’UDP sur le port IP
COM WAN.
ip-com-port.recv-errors
Erreur de réception sur le
port IP COM WAN
Nombre d’erreurs de réception sur le port IP COM WAN.
ip-com-port.send-errors
Erreur d’envoi du port IP
COM WAN
Nombre d’erreurs d’envoi sur le port IP COM WAN.
ip-com-port.recv-dropped
Paquet reçu abandonné
sur le port IP COM WAN
Nombre de paquets reçus abandonnés sur le port IP
COM WAN.
ip-com-port.send-dropped
Paquet envoyé abandonné Nombre de paquets envoyés abandonnés sur le port IP
sur le port IP COM WAN
COM WAN.
ip-com-port.recv-overruns
Dépassement reçu sur le
port IP COM WAN
Nombre de dépassements reçus sur le port IP COM WAN.
ip-com-port.send-overruns
Dépassement envoyé sur
le port IP COM WAN
Nombre de dépassements envoyés sur le port IP COM WAN.
ip-com-port.recv-frame-errors
Trame reçue sur le port IP
COM WAN
Nombre de trames reçues sur le port IP COM WAN.
Performances et surveillance
107
Tableau 22. Statistiques IP COM WAN (ip-com-port) (suite)
Statistiques
Type
Description
ip-com-port.send-carrier-errors
Porteuse envoyée sur le
port IP COM WAN
Nombre de porteuses envoyées sur le port IP COM WAN.
ip-com-port.collisions
Collisions sur le port IP
COM WAN
Nombre de collisions sur le port IP COM WAN.
Tableau 23. Statistiques de contrôle des congestions IP
Statistiques
Description
ip-congestion-control.ip-wan-cc-rtt
Durée de boucle maintenue par le TCP en microsecondes.
ip-congestion-control.ip-wan-cc-rttvar
Écart moyen de la RTT maximale lissée mesurée en microsecondes.
ip-congestion-control.ip-wan-recv-bytes
Nombre total d’octets reçus sur le chemin TCPCOM.
ip-congestion-control.ip-wan-recv-cnt
Nombre total de paquets reçus sur le chemin TCPCOM.
ip-congestion-control.ip-wan-retx-cnt
Nombre total de retransmissions du TCP.
ip-congestion-control.ip-wan-send-bytes
Nombre total d’octets envoyés sur le chemin TCPCOM.
ip-congestion-control.ip-wan-send-cnt
Nombre total de paquets envoyés sur le chemin TCPCOM.
Tableau 24. Statistiques sur les E/S de cluster COM
Statistiques
Description
com-cluster-io.avg-lat
Latence moyenne en microsecondes de l’ensemble des E/S du cluster local vers
l’autre cluster au cours de la dernière période de requête. Utilise un numéro de
cluster comme argument.
type : mesure ; unités : microsecondes ; arguments :
cluster-id
com-cluster-io.max-lat
type : mesure ; unités : microsecondes ; arguments :
cluster-id
com-cluster-io.min-lat
lecture ; unités : microsecondes ; arguments : clusterid
com-cluster-io.send-ops
Latence maximale en microsecondes de l’ensemble des E/S du cluster local vers
l’autre cluster. Utilise un numéro de cluster comme argument.
Latence minimale en microsecondes de l’ensemble des E/S du cluster local vers
l’autre cluster. Utilise un numéro de cluster comme argument.
Nombre d’opérations d’envoi d’E/S vers le cluster.
type : mesure ; unités : aucune ; arguments : clusterid
com-cluster-io.ops-active
Messages actifs inachevés vers un site.
com-cluster-io.bytes-active
Octets actifs inachevés vers un site.
com-cluster-io.bytes-queued
Octets actifs en file d’attente vers un site.
com-cluster-io.ops-queued
Messages actifs en file d’attente vers un site.
Tableau 25. Statistiques sur les groupes d’E/S COM
Statistiques
Description
com-io-group.io-tm-avg
Latence moyenne sur le groupe de canaux au cours des 5 dernières secondes
(mise à jour toutes les 5 secondes).
com-io-group.io-tm-cnt
Messages envoyés sur le groupe de canaux au cours des 5 dernières secondes
(mise à jour toutes les 5 secondes).
com-io-group.io-tm-max
Latence maximale sur le groupe de canaux au cours des 5 dernières secondes
(mise à jour toutes les 5 secondes).
108
Performances et surveillance
Tableau 25. Statistiques sur les groupes d’E/S COM (suite)
Statistiques
Description
com-io-group.io-tm-min
Latence minimale sur le groupe de canaux au cours des 5 dernières secondes
(mise à jour toutes les 5 secondes).
com-io-group.msg-b-in
Renvoie toujours la valeur zéro.
com-io-group.msg-b-out
Nombre total d’octets envoyés sur le groupe de canaux.
com-io-group.msg-cnt-in
Renvoie toujours la valeur zéro.
com-io-group.msg-cnt-out
Nombre total de messages envoyés sur le groupe de canaux.
Tableau 26. Statistiques sur les chemins COM
Statistiques
Description
com-path.ping-count
Nombre de paquets ping envoyés. Ils sont utilisés pour calculer la latence.
com-path.ping-late
Nombre de paquets ping qui ont pris trop de temps.
com-path.ping-lost
Nombre de paquets ping perdus.
com-path.posted-bytes
Nombre d’octets de transmission publiés. (Octets en file d’attente pour la
transmission.)
com-path.posted-send-ack
Nombre de mémoires tampons de confirmation publiées. (Mémoires tampons de
confirmation en file d’attente pour transmission.)
com-path.posted-send-ctl
Nombre de mémoires tampons de contrôle publiées. (Mémoires tampons de
contrôle en file d’attente pour transmission.)
com-path.rtt-avg
Durée de boucle moyenne de déplacement des données le long du chemin.
com-path.rtt-max
Durée de boucle maximale de déplacement des données le long du chemin.
com-path.rtt-min
Durée de boucle minimale de déplacement des données le long du chemin.
com-path.send-bytes
Nombre d’octets de données envoyés le long du chemin. Il inclut les données
ainsi que les en-têtes UDCOM.
com-path.send-posted-bytes
Nombre de mémoires tampons de données de transmission publiées. Autrement
dit, les données en file d’attente pour la transmission.
Tableau 27. Statistiques sur les points de terminaison COM
Statistiques
Description
com-endpoint.ack-bytes-recv
Nombre d’octets de confirmation reçus.
com-endpoint.ack-bytes-sent
Nombre d’octets de confirmation envoyés.
com-endpoint.ack-pckts-recv
Nombre de paquets de confirmation reçus.
com-endpoint.ack-pckts-sent
Nombre de paquets de confirmation envoyés.
com-endpoint.cx-bad-ver
Nombre de paquets de contrôle de version incorrecte.
com-endpoint.cx-bytes-recv
Nombre d’octets de contrôle reçus.
com-endpoint.cx-bytes-sent
Nombre d’octets de contrôle envoyés.
com-endpoint.cx-pckts-recv
Nombre de paquets de contrôle reçus.
com-endpoint.cx-pckts-routed
Nombre de paquets de contrôle routés.
com-endpoint.cx-pckts-sent
Nombre de paquets de contrôle envoyés.
com-endpoint.data-bytes-recv
Nombre d’octets de données reçus.
com-endpoint.data-bytes-sent
Nombre d’octets de données envoyés.
com-endpoint.data-padding-recv
Nombre de paquets de données de remplissage reçus.
Performances et surveillance
109
Tableau 27. Statistiques sur les points de terminaison COM (suite)
com-endpoint.data-pckts-badkey
Nombre de paquets avec une clé de domaine non valide.
com-endpoint.data-pckts-badlen
Nombre de longueurs de paquet de données non valides.
com-endpoint.data-pckts-recv
Nombre de paquets de données reçus.
com-endpoint.data-pckts-routed
Nombre de paquets de données routés.
com-endpoint.data-pckts-runt
Nombre de paquets de données de longueur inférieure à 64 octets.
com-endpoint.data-pckts-sent
Nombre de paquets de données envoyés.
com-endpoint.rx-ack-buf-pend-pckts
Nombre de mémoires tampons de confirmation en attente à traiter.
Il s’agit du nombre de paquets de confirmation entrés, mais pas
encore traités.
com-endpoint.rx-credits
Nombre de crédits reçus.
com-endpoint.tx-posted-bytes
Nombre d’octets transmis publiés. (Octets en file d’attente à
transmettre.)
Tableau 28. Statistiques sur l’adaptateur XCOPY
Statistiques
Description
fe-director.xcopy-avg-lat
Latence moyenne pour traiter l’ensemble des XCOPY frontales reçues
pour un directeur donné, en microsecondes. Collecte automatique dans
le cadre d’une surveillance perpétuelle. Les valeurs collectées sont
disponibles via le fichier de surveillance perpétuelle qui se situe sur le
serveur de gestion Metro Node : /var/log/VPlex/cli/director-[1|2]-[1|2]-[A|
B]_PERPETUAL_vplex_sys_perf_mon.log.
fe-director.xcopy-ops
Nombre d’opérations XCOPY terminées par seconde pour un directeur
donné.
fe-lu.xcopy-avg-lat
Latence moyenne pour traiter les XCOPY frontales reçues pour un volume
virtuel Metro Node donné d’un directeur spécifique, en microsecondes
fe-lu.xcopy-ops
Nombre d’opérations XCOPY traitées par un volume virtuel Metro Node
donné d’un directeur spécifique.
fe-prt.xcopy-avg-lat
Latence moyenne pour traiter les XCOPY frontales reçues sur un port frontal
donné d’un directeur spécifique, en microsecondes au niveau du port.
fe-prt.xcopy-ops
Nombre d’opérations XCOPY traitées par un port frontal Metro Node donné
d’un directeur spécifique
Tableau 29. Statistiques sur les initiateurs hôtes
Statistiques
Description
host-init.unmap-ops
Opérations de suppression de mappages de l’initiateur hôte.
type : compteur ; unités : nombre/seconde ; arguments :
aucun
host-init.unmap-avg-lat
type : moyenne par période ; unités : µs ; arguments :
aucun
110
Performances et surveillance
Latence de suppression de mappages moyenne de l’initiateur hôte.
A
Metro Node avec baies de stockage en mode
actif-passif
Sujets :
•
•
•
•
Baie en mode actif-passif
Baie activée en mode ALUA
Exécution d’un basculement de l’unité logique
Restauration automatique d’une unité logique
Baie en mode actif-passif
Une baie en mode actif-passif dispose généralement de deux contrôleurs et fournit un accès en mode actif-passif à une unité logique (LU)
via un ensemble de ports cibles. Les types d’accès de ces ports sont : actif (ACT) ou passif (PAS). Là où le type actif est utilisé pour les
E/S, le type passif ne peut pas l’être. En cas de perte de chemins actifs vers des unités logiques, l’initiateur (Metro Node) peut décider
d’activer les chemins passifs pour exécuter les E/S en envoyant des commandes SCSI spécifiques au fournisseur à la baie.
Le contrôleur doté des ports cibles actifs d’une unité logique spécifique est appelé contrôleur actif (ACT) de l’unité logique. Le contrôleur
doté des ports cibles passifs d’une unité logique spécifique est appelé contrôleur passif (PAS) de l’unité logique. Le contrôleur actif d’une
unité logique peut être le contrôleur passif d’une autre unité logique et inversement.
Baie activée en mode ALUA
Une baie de stockage dotée du mode ALUA (Asymmetric Logical Unit Access) offre un accès actif/actif à une unité logique via tous les
ports cibles. En fonction de leur bande passante, ces ports sont répartis dans des groupes de ports cibles préférés et non préférés. Les
ports cibles préférés avec bande passante élevée ont l’état d’accès actif/actif optimisé (AAO, Active/Active Optimized) tandis que les
ports cibles non préférés ont l’état d’accès actif/non optimisé (AAN, Active/Non-Optimized). En l’absence de chemins AAO, les E/S se
poursuivent sur les chemins AAN.
Le contrôleur disposant de ports cibles préférés pour une unité logique spécifique est appelé contrôleur actif/actif optimisé (AAO) de
cette unité logique, tandis que le contrôleur avec des ports cibles non préférés pour une unité logique spécifique est appelé contrôleur
actif/non optimisé (AAN) de cette unité logique. Le contrôleur AAO d’une unité logique peut être un contrôleur AAN d’une autre unité
logique et inversement. Dans le cadre du processus de basculement de l’unité logique avec le mode ALUA, l’état de l’accès ALUA actif/
actif optimisé (AAO) équivaut à un chemin actif (ACT), et l’état actif/actif-non optimisé (AAN) équivaut à un chemin passif (PAS), en
interne.
Les cibles annoncent leur prise en charge d’ALUA pour chaque unité logique via une réponse à une demande standard. Il existe trois modes
différents de fonctionnement :
ALUA implicite : l’appareil cible peut modifier de manière indépendante les états d’accès à l’unité logique en interne.
ALUA explicite : l’appareil cible nécessite un initiateur pour modifier les états d’accès à l’unité logique, par le biais de l’envoi de commandes
SCSI spécifiques, si nécessaire.
ALUA implicite-explicite : possède l’avantage de l’ALUA implicite et de l’ALUA explicite. Les cibles peuvent prendre en charge l’ALUA
implicite, l’ALUA explicite ou l’ALUA implicite-explicite.
Exécution d’un basculement de l’unité logique
Lorsque l’unité logique est accessible via tous les chemins, le contrôleur actif devient le contrôleur préféré. Lorsqu’aucun chemin actif
n’est disponible, le contrôleur passif devient le contrôleur préféré. Le basculement de l’unité logique est déclenché par le directeur principal
du cluster Metro Node, lorsque le contrôleur préféré n’est pas son contrôleur actif. Le directeur principal du cluster initie le basculement
de l’unité logique en envoyant des commandes SCSI spécifiques au fournisseur au périphérique cible pour modifier l’état d’accès à l’unité
logique. En fonction de la réponse reçue du périphérique cible pour la commande, le basculement de l’unité logique aboutit ou échoue.
Metro Node avec baies de stockage en mode actif-passif
111
Lorsque le basculement d’une unité logique spécifique d’une baie vers un contrôleur cible spécifique est activé, l’événement de firmware
Metro Node apf/3 est observé. Lorsque le basculement d’une unité logique spécifique d’une baie vers un contrôleur cible spécifique dit
actif aboutit ou échoue, un événement de firmware Metro Node apf/4 est généré.
Par exemple :
apf/3 Failover initiated for logical unit VPD83T3:6006016015a0320061d7f2b300d3e211 on array
EMC~CLARiiON~FNM00124500474 to target controller FNM00124500474.SPA as active.
apf/4 Failover succeeded for logical unit VPD83T3:6006016015a0320061d7f2b300d3e211 on array
EMC~CLARiiON~FNM00124500474 to target controller FNM00124500474.SPA as active.
apf/4 Failover failed for logical unit VPD83T3:600601606bb72200f01fb4fa1e22e311 on array
EMC~CLARiiON~FCNCH072602809 to target controller FCNCH072602809.SPA as active. reason: Scsi
mode select command failed
Vous pouvez trouver des entrées similaires dans le journal des événements du firmware Metro Node /var/log/VPlex/cli/
firmware.log* sur un serveur de gestion en cours d’exécution.
Restauration automatique d’une unité logique
Lorsque l’état de l’unité logique devient nominal, Metro Node tente de restaurer automatiquement l’unité logique vers son contrôleur par
défaut. Celui-ci est généralement défini comme propriétaire de l’unité logique, tel que déterminé par la baie. Le processus d’exécution
du basculement de l’unité logique est redémarré afin d’optimiser les performances du côté de la baie de stockage. Cette restauration
automatique ne se produit que si la propriété autoswitch est activée sur la baie et que l’unité logique est visible via le contrôleur.
REMARQUE : L’outil Simple Support Matrix for metro node (matrice de support simplifiée pour Metro Node) fournit plus
d’informations sur les systèmes de stockage Dell EMC et les baies tierces supportés.
112
Metro Node avec baies de stockage en mode actif-passif
Index
A
G
à propos de : métavolumes 9
affichage : analyseurs 90
analyseur de performances : creation 87
Gestion du stockage dynamique 24, 28
groupe de cohérence : propriétés 65, 75
groupes de cohérence : ajout de volumes 70
groupes de cohérence : application d’une règle de déconnexion 73
groupes de cohérence : création 69
groupes de cohérence : définir la visibilité 73
groupes de cohérence : définition de l’attribut en lecture seule 83
groupes de cohérence : propriétés : auto-resume-at-loser 67
groupes de cohérence : propriétés : detach-rule 67
groupes de cohérence : propriétés : modification de propriétés 72
groupes de cohérence : propriétés : storage-at-clusters 66
groupes de cohérence : propriétés : visibilité 65
groupes de cohérence : propriétés : volumes virtuels 68
groupes de cohérence : redémarrer les E/S sur le cluster perdant
82
groupes de cohérence : reprendre les E/S après restauration 81
groupes de cohérence : supprimer 74
groupes de cohérence : supprimer des volumes 71
groupes de cohérence : synchrones 62
groupes de cohérence : synchrones : visibilité globale 64
groupes de cohérence : synchrones : visibilité locale 63
groupes de ports 55
B
Baie activée en mode ALUA 111
Baie en mode actif-passif 111
Basculement de l’unité logique 111
C
caractère générique 8
CAW : activation/désactivation pour la vue de stockage 18
CAW : activer/désactiver par défaut 19
CAW : afficher le paramètre de vue de stockage 18
CAW : afficher le paramètre par défaut du système 18
CAW : CompareAndWrite 17
CAW : statistiques 19
Cluster 22
compatibilité avec le provisionnement dynamique 24
contexte de sous-réseaux 57
Contexte port-groups 56
D
données : migration, traitement par lot ; données : migration,
plusieurs RAID ; migration des données : plusieurs RAID ; RAID :
migration (traitement par lot) 49
E
ensemble de volumes : ajout de volumes virtuels 69
épuisement du stockage dynamique 24
Espace de travail de l’interface CLI : définition de la largeur de la
fenêtre 8
espace de travail de l’interface de ligne de commande :
journalisation de console 7
extension de volume : détermination de la méthode d’extension de
volume 33
extension de volume : détermination de la méthode d’extension de
volume : utilisation de l’interface CLI 33
extension de volume : détermination de la méthode d’extension de
volume : utilisation de l’interface GUI 34
extension de volume : extension de volumes virtuels 34
extension de volume : extension de volumes virtuels : méthode
d’extension de volume de stockage 35
extension de volume : limitations 33
extension de volume : présentation 33
extensions compatibles avec le provisionnement dynamique 25
F
find 8
fixation d’un miroir 29
I
interface de ligne de commande : définition du seuil de
journalisation ; seuil de journalisation, configuration ; configuration :
seuil de journalisation pour l’interface de ligne de commande 7
M
métavolumes : à propos de 9
métavolumes : affichage 12
métavolumes : champs affichés 12
métavolumes : exigences en matière de performances et de
disponibilité 9
métavolumes : modifier le nom 10
migration 40
migration dynamique 29
migration ponctuelle : analyseur 46
migration ponctuelle : annulation 47
migration ponctuelle : démarrage 45
migration ponctuelle : nettoyage 48
migration ponctuelle : pause/reprise 47
migration ponctuelle : supprimer 48
migration ponctuelle : validation 48
migrations des données : à propos de 39
migrations des données : conditions préalables 40
migrations des données : étapes générales 40
migrations des données : migrations par lot 39
migrations des données : migrations ponctuelles 39
migrations dynamiques 24
migrations par lot 49
migrations par lot : annuler 51
migrations par lot : conditions préalables 49
migrations par lot : créer le plan de migration 49
migrations par lot : état 52
migrations par lot : modifier le plan de migration par lot 50
migrations par lot : nettoyage 53
migrations par lot : pause/reprise 51
migrations par lot : supprimer 54
migrations par lot : surveiller 51
migrations par lot : vérification du plan de migration 50
N
notifications call home : à propos de 15
notifications call-home : gravité des événements 15
P
Ports de WAN : contextes de l’interface CLI 55
Ports WAN 55
ports WAN : contexte de sous-réseaux 57
ports WAN : contexte port-groups 56
ports WAN : règles de configuration Metro 55
provisionnement dynamique 24, 25
Provisionnement dynamique 44
R
récepteur d’analyseur : supprimer 90
récepteur de console 89
récepteurs d’analyseur 89
reconstruction dynamique 24, 29
reconstructions 44
reconstructions : performances 45
reconstructions : stockage à provisionnement dynamique 44
Restauration automatique d’une unité logique 112
rotation des fichiers 87
surveillance des performances : exemples : 10 secondes, directeurs
88
surveillance des performances : exemples : envoyer les statistiques
sur les paramètres CAW au serveur de gestion 88
surveillance des performances : exemples : latence des clusters
distants 88
surveillance des performances : exemples : latence du COM local
88
surveillance des performances : exemples : période par défaut,
aucune cible 88
surveillance des performances : exemples : statistiques sur le WAN
au niveau des ports 88
Surveillance des performances : forcer une interrogation immédiate
94
Surveillance des performances : gérer des récepteurs 93
surveillance des performances : interface GUI Vplex 85
Surveillance des performances : interrogation 93
surveillance des performances : procédure 88
Surveillance des performances : rotation des fichiers 87
surveillance des performances : statistiques 98
Surveillance des performances : supprimer le récepteur d’analyseur
90
surveillance des performances : utilisation de l’interface Vplexcli 87
T
taille de transfert 50
V
volume virtuel 27, 31
W
S
search 8
statistiques 99
statistiques : accès à la mémoire de données distante 100
statistiques : cache 100
statistiques : directeur 100
statistiques : directeur frontal 100
statistiques : Fibre Channel COM WAN (fc-com-port) 100
statistiques : groupe de cohérence (wof-throttle) 100
statistiques : IP COM WAN (ip-com-port) 100
statistiques : LU frontale 100
statistiques : port back-end Fibre Channel 90, 100
statistiques : port frontal 100
statistiques : RAID distant 100
statistiques : répertoire 100
statistiques : volume de stockage 100
statistiques : volume virtuel 100
Statistiques sur les performances frontales 100
suppression de mappages 29
surveillance des performances : à propos de 84
surveillance des performances : affichage des analyseurs 90
Surveillance des performances : afficher les statistiques 99
surveillance des performances : ajout d’un récepteur de console 89
Surveillance des performances : ajoute de récepteurs 89
Surveillance des performances : ajouter un récepteur de fichiers 90
surveillance des performances : création d’un analyseur 88
surveillance des performances : création d’un analyseur à l’aide de
l’interface CLI 88
WriteSame : activation/désactivation 19
WriteSame : activation/désactivation en tant que système par
défaut 21
WriteSame : activation/désactivation pour une vue de stockage 20
WriteSame : afficher le paramètre 20
WriteSame : afficher le paramètre de vue de stockage 20
WriteSame : statistiques 21
WriteSame (16) : afficher le paramètre par défaut 20