Release Notes

Comportements attendus
Cette section décrit les comportements attendus dans Metro Node.
● Les volumes système tels que les métadonnées et les volumes de journalisation sont pris en charge par les périphériques thin.
Toutefois, Metro Node se base sur ces volumes pour les opérations système. Toutes les extensions devraient être pré-allouées afin
d’éviter des conditions d’espace insuffisant.
● Alors que les clusters sont en contact, Metro Node empêche que le même volume de stockage ne soit réclamé à chaque cluster.
Toutefois, si les clusters sont partitionnés, Metro Node ne peut empêcher que le même volume de stockage ne soit réclamé aux deux
clusters. Si une telle situation se produit, dès lors que Metro Node la détecte, un événement Call Home est envoyé. Ce problème doit
être corrigé lorsqu’il est détecté.
● Lorsque le tronçon d’un périphérique distribué au sein d’un groupe de cohérence n’est pas sain et est désigné pour une reconstruction,
vous n’avez pas la possibilité de retirer le tronçon dégradé. Un groupe de cohérence distribué a besoin de membres de périphérique
distribué à deux tronçons. Pour éviter ce problème :
1. Utilisez la commande attach mirror pour rattacher un nouveau miroir au tronçon sain.
2. Détachez l’ancien miroir dégradé.
● Si l’utilisation de métadonnées à un cluster dépasse 90 %, Metro Node déclenche un événement Call Home. Si l’utilisation de
métadonnées sur l’autre cluster dépasse également 90 % dans les 8 heures, Metro Node ne déclenche pas d’événement Call Home.
Ceci est un défaut de conception qui survient dans les configurations de Metro Node.
● Dans Unisphere, les assistants provision par pools et provision par volumes de stockage vous permettent de sélectionner uniquement
des groupes de cohérence dont la valeur est définie pour la propriété storage-at-clusters.
● Si vous modifiez le processeur de stockage actif (SP) d’une LUN dans la suite de gestion Navisphere CLARiiON™, le SP incorrect peut
être signalé comme actif dans l’interface utilisateur de Metro Node. Par exemple, SPA peut être signalé comme actif alors qu’en réalité
SPB est actif. Afin de corriger cette erreur de reporting, démarrez des E/S. Après le démarrage des E/S, le système reconnaît quel SP
est actif et l’indique correctement.
● Si les performances d’E/S de l’hôte sont affectées lors d’une migration de données ou d’une reconstruction, réduisez les paramètres
de la taille de transfert de reconstruction pour les périphériques, ou réduisez le nombre de migrations/reconstructions simultanées.
● Veillez à ce que les ressources de l’hôte soient suffisantes pour traiter le nombre de chemins provisionnés pour le système
Metro Node.
● Une faible qualité de service (QoS) sur la liaison WAN-COM dans une configuration Metro pourrait mener à un comportement indéfini
et, dans des cas extrêmes, à une indisponibilité des données. Veuillez suivre les bonnes pratiques pour configurer et contrôler les
liaisons WAN-COM.
● Dans les configurations Metro, Metro Node ne prend pas en charge le chiffrement natif sur la liaison IP WAN COM. Les clients
devraient déployer une appliance externe pour finaliser le chiffrement de données via les liaisons IP WAN entre les clusters.
● Lorsqu’un volume de stockage réclamé devient matériellement inactif, Metro Node l’explore automatiquement dans les 20 secondes.
En cas d’exploration réussie, Metro Node supprime le statut « inactif » du volume, le ramenant donc à un état sain.
PRÉCAUTION :
Pendant que le périphérique est matériellement inactif, n’effectuez pas d’opérations qui modifient
les données des volumes de stockage sous un RAID 1 Metro Node (par le biais d’une maintenance ou d’un
remplacement de disques au sein de la baie). Si de telles opérations sont nécessaires, déconnectez d’abord les
volumes de stockage du RAID 1 Metro Node, effectuez les opérations de modification de données, puis ajoutez à
nouveau au RAID 1 Metro Node les volumes de stockage nécessaires au déclenchement de la reconstruction. Si vous
ne suivez pas ces étapes, les données sous-jacentes de Metro Node sont modifiées à son insu. Sans reconstruction
des données, les tronçons RAID 1 peuvent être incohérents ; cela peut entraîner une corruption des données lors de
la réactivation.
● Par défaut, tout utilisateur créé sur le serveur de gestion qui n’a pas changé son mot de passe au cours des 91 derniers jours verra son
compte bloqué. Le compte utilisateur d’administrateur ne sera jamais bloqué, mais l’utilisateur-administrateur sera obligé de modifier
son mot de passe lors de la connexion suivante. Reportez-vous à la section « Règles applicables aux mots de passe » de la section
de dépannage de SolVe Desktop afin de résoudre les problèmes de blocage de compte. Les stratégies ne sont pas appliquées pour
l’utilisateur de service.
● Les volumes de stockage qui sont utilisés comme volumes système (des tronçons de miroir de périphérique RAID 1 de métavolumes
Metro Node, des volumes de journalisation et des sauvegardes pour le métavolume) doivent être formatés/vidés avant d’être utilisés
par Metro Node en tant que tel.
● Il existe deux méthodes de traitement des défaillances pour les interactions de baie back-end.
○ Les réponses non ambiguës à la défaillance, telles que les requêtes rejetées par le volume de stockage ou le retrait du port de la
structure back-end.
○ Condition selon laquelle les baies de stockage entrent en mode échec de sorte qu’un ou plusieurs de ses ports cibles restent sur la
structure, alors que toutes les commandes SCSI envoyées vers celui-ci par l’initiateur (Metro Node) ont expiré.
Notes de mise à jour
9