PowerScale : Isilon : Analyse Isilon On-Cluster : Pools réseau - Prise en charge de la mise à niveau parallèle

Network Pools - Parallel Upgrade Support          FAIL

CRITICAL: A parallel upgrade runs the risk of making one or more external networks temporarily unavailable. Affected pools: groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2

• Cela est dû à la conception du cluster, car il comporte des réseaux externes disjoints où il existe un risque possible que tous les nœuds des pools réseau concernés redémarrent simultanément.
• Dans ce cas, les clients ne peuvent pas accéder au cluster via le nom de zone SmartConnect (SCZN) associé à ce pool réseau. 

Définitions importantes :
 

• Pool de disques :  Ensemble de disques répartis entre un sous-ensemble de nœuds de cluster. 
• Niveaux de protection/politiques : Tous les fichiers du système de fichiers /ifs se voient attribuer un niveau de protection. OneFS répartit ou met en miroir le contenu des fichiers sur les nœuds et les disques d’un seul pool de disques. Un fichier avec un niveau de protection de 2d+1n garantit que le fichier sera toujours disponible en cas de défaillance de deux lecteurs ou d’un nœud du pool de disques inclus.
• Quartiers:  Ensembles de nœuds qui contiennent entièrement un ou plusieurs pools de disques. Un sous-ensemble de nœuds attribués à un pool de disques peut se chevaucher avec un sous-ensemble de nœuds attribués à un autre voisinage. Aucun chevauchement de pools de disques ne se produit entre les voisinages. 
• API de BD de pools de disques et réservations L’API de base de données de pools de disques dispose d’une fonctionnalité de réservation qui permet à une application client telle qu’Upgrade Framework de supprimer un ensemble de nœuds (redémarrage) ou de disques du cluster sans violation de la protection sur un pool de disques.
• Réseaux externes disjoints : un cluster comporte des réseaux externes disjoints s’il existe un ensemble de nœuds avec des interfaces externes qui ne se chevauchent pas sur l’ensemble des pools de disques.

• Une mise à niveau parallèle installe le nouveau système d’exploitation sur tous les nœuds, puis redémarre un sous-ensemble de nœuds simultanément, jusqu’à un nœud dans chaque pool de disques.
• Chaque nœud tente d’effectuer une réservation pour que son tour redémarre jusqu’à la mise à niveau de l’ensemble des nœuds.  Les sous-ensembles de nœuds et les réservations sont basés sur le pool de disques et la disponibilité des nœuds.
• Lors d’une mise à niveau parallèle, les sous-ensembles de nœuds qui ne sont pas redémarrés restent en ligne et peuvent continuer à servir les clients.

• Le cluster comporte des réseaux externes disjoints (exemple dans la base de connaissances : groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2)
• Au cours de la mise à niveau parallèle, il existe un risque possible d’indisponibilité des données sur ces pools réseau, car tous les nœuds des pools réseau concernés peuvent redémarrer en même temps (c’est-à-dire qu’ils peuvent tous prendre une réservation de pools de disques pour redémarrer simultanément). 
• Si cela se produit, l’accès au SCZN du pool réseau concerné ne sera pas possible. 

• Étant donné que chaque cluster dispose d’une configuration réseau différente, la solution n’est pas la même pour tous les clusters.
• Afin d’éviter toute indisponibilité des disques sur le pool réseau disjoint lors de la mise à niveau parallèle, une modification de la configuration réseau sur le cluster et l’environnement externe sera nécessaire, ce qui nécessite généralement plusieurs approbations de la part du client.
• Cet article de la base de connaissances n’inclut pas de résolution directe de l’échec de vérification IOCA en raison des éléments susmentionnés.
• Toutefois, il est généralement recommandé qu’au moins deux interfaces membres externes de nœuds dans les pools réseau concernés existent sur le même voisinage/domaine de défaillance afin d’éviter un risque de disjonction réseau/DU pour ce pool réseau SmartConnect (c’est-à-dire ajouter des nœuds du même voisinage/domaine de panne au pool réseau concerné). 
• Cet article de la base de connaissances fournit des commandes sur la façon de déterminer les domaines de voisinage/de défaillance du cluster et les nœuds membres dans les pools réseau concernés.

• Utilisez la commande ci-dessous pour déterminer les nœuds membres dans les pools réseau concernés (Remarque : Remplacez la commande «< network-pool 1 ID> | <Pool réseau 2 ID> | <network-pool 3 ID> » avec les ID de pool réseau concernés provenant des détails de vérification IOCA et séparez-les à l’aide du caractère « | »). 

# isi network pools list -v | egrep -i 'ID: |ifaces' | egrep -A1 '<network-pool 1 ID> | <network-pool 2 ID> | <network-pool 3 ID>'

• Exécutez la commande ci-dessous pour déterminer les voisinages du cluster (Remarque: Remettez en place le <Emplacement> du script IOCA et <Nouvelle version> de OneFS avec leurs valeurs correctes) 

# perl <IOCA script location> -o <New OneFS version>,parallel  -e -r "checkNetworkParallelUpgrade"  

• Croisez les sorties des commandes ci-dessus pour déterminer les modifications à apporter aux pools réseau du cluster.
• Un correctif rapide consisterait à ajouter tous les nœuds de clusters aux pools réseau concernés, mais là encore, il s’agit généralement d’une opération délicate, car il est possible que l’environnement réseau externe ne permette pas cette modification.
• Une fois les modifications requises appliquées, exécutez à nouveau la vérification IOCA.
• Si vous ne parvenez pas à déterminer les modifications nécessaires, ouvrez un dossier auprès du support pour obtenir de l’aide.
• Exemple ci-dessous pour déterminer les modifications nécessaires dans un scénario de test :

1) Determine member nodes in affected network pools:
# isi network pools list -v | grep -i 'ID: |ifaces' | egrep -A1 'groupnet0.subnet0.pool1| groupnet0.subnet1.pool1| groupnet0.subnet1.pool2'
                     ID: groupnet0.subnet0.pool1
                 Ifaces: 1:10gige-agg-1, 2:10gige-agg-1, 4:10gige-agg-1, 3:10gige-agg-1
                     ID: groupnet0.subnet1.pool1
                 Ifaces: 37:10gige-agg-1, 38:10gige-agg-1, 39:10gige-agg-1, 40:10gige-agg-1
                     ID: groupnet0.subnet1.pool2
                 Ifaces: 37:10gige-agg-1, 38:10gige-agg-1, 39:10gige-agg-1, 40:10gige-agg-1

2) Run the IOCA check to determine cluster neighborhoods:
# perl IOCA -o 9.2.1.5,parallel -e -r "checkNetworkParallelUpgrade"
Isilon On-Cluster Analysis                        0.1395
Cluster Name                                      TestCluster
Cluster GUID                                      0050569b6db2ad086861001a2f1dd1d02473
Node Count                                        52
Current OneFS Version                             8.2.2.0
Destination OneFS Version                         9.2.1.5
Destination OneFS Version                         WARN
  WARN: There is a newer patch release available for OneFS 9.2.1: 9.2.1.9
Network Pools - Parallel Upgrade Support          FAIL
  CRITICAL: A parallel upgrade runs the risk of making one or more external networks temporarily unavailable. Affected pools: groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2
  
  ==============================
  Node Neighborhoods
  ==============================
  1: [ 1, 7, 10, 16, 19, 24, 27, 31, 35, 40, 43, 45, 47 ]
  2: [ 2, 6, 9, 15, 18, 23, 26, 29, 33, 38, 41, 46, 48 ]
  3: [ 3, 5, 12, 14, 17, 22, 25, 30, 34, 37, 42, 50, 51 ]
  4: [ 4, 8, 11, 13, 20, 21, 28, 32, 36, 39, 44, 49, 52 ]

3) The possible resolution in this case would be to :

a) A quick fix would be to add all clusters nodes to the impacted network pools groupnet0.subnet0.pool1 & groupnet0.subnet1.pool1, groupnet0.subnet1.pool2
b) Add more nodes to affected network pools ( suggested nodes are based on neighborhood command output ) :

- Possible resolution to groupnet0.subnet0.pool1 : at least add node 7  to the network pool as node 7 exists in the same neighborhood as nodes 1
- Possible resolution to groupnet0.subnet1.pool1 : at least add node 34 to the network pool as node 34 exists in the same neighborhood as nodes 37
- Possible resolution to groupnet0.subnet1.pool2 : at least add node 33 to the network pool as node 33 exists in the same neighborhood as nodes 38

4) After applying the network changes, re-run the IOCA check to confirm that there are no issues:
# perl IOCA -o 9.2.1.5,parallel -e -r "checkNetworkParallelUpgrade"