PowerScale: Isilon: Analisi Isilon on-cluster: pool di rete - Supporto per aggiornamenti paralleli

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

• Si tratta di una caratteristica predefinita, in quanto il cluster dispone di reti esterne disgiunte in cui esiste il possibile rischio che tutti i nodi nei pool di rete interessati si riavviino contemporaneamente.
• In tal caso, i client non possono accedere al cluster tramite SmartConnect Zone Name (SCZN) associato a tale pool di rete. 

Definizioni importanti
 

• Disk pool:  Raccolta di dischi distribuiti tra un sottoinsieme di nodi cluster. 
• Policy/livelli di protezione: A tutti i file nel file system /ifs viene assegnato un livello di protezione. OneFS esegue lo striping o il mirroring del contenuto dei file tra i nodi e le unità di un singolo pool di dischi. Un file con un livello di protezione di 2d+1n garantisce che il file sia ancora disponibile se due unità o un nodo nel disk pool che lo contiene smette di funzionare.
• Quartieri:  Set di nodi che contengono interamente uno o più disk pool. Un sottoinsieme di nodi assegnati a un disk pool può sovrapporsi a un sottoinsieme di nodi assegnati a un'altra area limitrofa. Non vi è alcuna sovrapposizione di pool dischi tra nodi vicini. 
• API di database dei pool di dischi e prenotazioni L'API di database dei pool di dischi include una funzione di prenotazione che consente a un'applicazione client, come Upgrade Framework, di rimuovere un set di nodi (riavvio) o unità dal cluster senza violare la protezione su un pool di dischi.
• Reti esterne indipendenti: un cluster presenta reti esterne indipendenti se è presente un set di nodi con interfacce esterne che non si sovrappongono in tutti i pool di dischi.

• Un aggiornamento parallelo installa il nuovo sistema operativo su tutti i nodi e quindi riavvia un sottoinsieme di nodi contemporaneamente, fino a un nodo in ogni disk pool.
• Ogni nodo tenta di effettuare una prenotazione per il proprio turno, fino all'aggiornamento di tutti i nodi.  I sottoinsiemi e le prenotazioni dei nodi si basano sulla disponibilità di nodi e pool di dischi.
• Durante un aggiornamento parallelo, i sottoinsiemi di nodi che non vengono riavviati rimangono online e possono continuare a servire i client.

• Il cluster dispone di reti esterne disgiunte (esempio della KB : groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2)
• Durante l'aggiornamento parallelo, esiste un possibile rischio di non disponibilità dei dati su tali pool di rete poiché tutti i nodi nei pool di rete interessati potrebbero riavviarsi contemporaneamente (ovvero, tutti potrebbero richiedere una prenotazione disk pool per il riavvio simultaneo). 
• In tal caso, non è possibile accedere al nome SCZN del pool di rete interessato. 

• Poiché ogni cluster ha una configurazione di rete diversa, la soluzione non è la stessa per tutti i cluster.
• Per evitare un rischio di non disponibilità dei dati nel pool di rete indipendente durante l'aggiornamento parallelo, è necessaria una modifica alla configurazione di rete nel cluster e nell'ambiente esterno, che in genere richiede diverse approvazioni lato cliente.
• Questo articolo della KB non include una risoluzione diretta per l'errore di controllo IOCA a causa dei punti precedenti.
• Tuttavia, la linea guida generale è che almeno due interfacce dei membri esterni dei nodi nei pool di rete interessati esistano sullo stesso dominio di vicinato/guasto per evitare un rischio di rete/DU disgiunto per tale pool di rete SmartConnect (ad esempio, aggiungere nodi dallo stesso dominio di vicinato/guasto al pool di rete interessato). 
• L'articolo della Knowledge Base fornisce comandi su come determinare i domini di vicinato/errore del cluster e i nodi membri nei pool di rete interessati.

• Utilizzare il comando riportato di seguito per determinare i nodi membri nei pool di rete interessati (nota: Sostituire "<network-pool 1 ID> | <ID> pool di rete 2 | <network-pool 3 ID"> con gli ID del pool di rete interessati dai dettagli di controllo IOCA e separarli utilizzando il carattere "|"). 

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

• Eseguire il comando riportato di seguito per determinare le aree limitrofe del cluster (nota: Sostituire il <Posizione> dello script IOCA e <nuova versione> di OneFS con i relativi valori corretti) 

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

• Fare riferimento incrociato agli output dei comandi precedenti per determinare quali modifiche devono essere apportate ai pool di rete del cluster.
• Una correzione rapida consiste nell'aggiungere tutti i nodi del cluster ai pool di rete interessati. Tuttavia, l'operazione in genere non è semplice, dal momento che l'ambiente di rete esterno potrebbe non consentire questa modifica.
• Dopo aver applicato le modifiche necessarie, eseguire nuovamente il controllo IOCA.
• Se non è possibile determinare le modifiche necessarie, aprire un caso con il supporto per ulteriore assistenza.
• Esempio riportato di seguito per determinare le modifiche necessarie in uno scenario di 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"