PowerScale: Isilon: Isilon-On-Cluster-Analyse: Netzwerkpools – Unterstützung für parallele Upgrades

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

• Dies ist beabsichtigt, da der Cluster getrennte externe Netzwerke hat, bei denen das Risiko besteht, dass alle Nodes in den betroffenen Netzwerkpools gleichzeitig neu gestartet werden.
• In diesem Fall können Clients nicht über den SmartConnect-Zonennamen (SCZN), der diesem Netzwerkpool zugeordnet ist, auf das Cluster zugreifen. 

Wichtige Definitionen:
 

• Laufwerkpool:  Sammlung von Festplatten, die auf eine Teilmenge von Cluster-Nodes verteilt sind. 
• Schutzlevel/-policies: Allen Dateien auf dem /ifs-Dateisystem wird ein Schutzlevel zugewiesen. OneFS verteilt oder spiegelt den Inhalt von Dateien über Nodes und Laufwerke eines einzigen Festplattenpools hinweg. Eine Datei mit einem Schutzlevel von 2d+1n garantiert, dass die Datei auch dann verfügbar ist, wenn zwei beliebige Laufwerke oder ein Node im umschließenden Festplattenpool ausfällt.
• Nachbarschaften:  Node-Gruppen, die vollständig einen oder mehrere Laufwerkpools enthalten. Eine Teilmenge von Nodes, die einem Laufwerkpool zugewiesen sind, kann sich mit einer Teilmenge von Nodes überschneiden, die einer anderen Nachbarschaft zugewiesen sind. Es gibt keine Überschneidungen von Festplattenpools zwischen Nachbarschaften. 
• Diskpools DB API und Reservierungen Die Diskpools Database API verfügt über eine Reservierungsfunktion, die es einer Clientanwendung wie dem Upgrade-Framework ermöglicht, einen Satz von Nodes (z. B. Neustart) oder Laufwerke aus dem Cluster zu entfernen, ohne den Schutz in einem Festplattenpool zu beeinträchtigen.
• Nicht verbundene externe Netzwerke: Ein Cluster verfügt über nicht verbundene externe Netzwerke, wenn eine Reihe von Nodes mit externen Schnittstellen vorhanden ist, die sich nicht über alle Festplattenpools hinweg überschneiden.

• Bei einem parallelen Upgrade wird das neue Betriebssystem auf allen Nodes installiert und dann eine Teilmenge der Nodes gleichzeitig neu gestartet, bis zu einem Node in jedem Laufwerkpool.
• Jeder Node versucht, eine Reservierung für den Neustart zu machen, bis alle Nodes aktualisiert wurden.  Node-Teilmengen und -Reservierungen basieren auf dem Festplattenpool und der Node-Verfügbarkeit.
• Während eines parallelen Upgrades bleiben Node-Teilmengen, die nicht neu gestartet werden, online und können weiterhin Clients bedienen.

• Der Cluster verfügt über getrennte externe Netzwerke (Wissensdatenbank-Beispiel : groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2)
• Während des parallelen Upgrades besteht ein mögliches DU-Risiko auf diesen Netzwerkpools, da alle Nodes in den betroffenen Netzwerkpools zur gleichen Zeit neu gestartet werden könnten (d. h. sie könnten alle eine Laufwerkpoolreservierung vornehmen, um gleichzeitig neu zu starten). 
• Wenn dies der Fall ist, ist der Zugriff auf das SCZN des betroffenen Netzwerkpools nicht möglich. 

• Da jeder Cluster eine andere Netzwerkkonfiguration hat, ist die Lösung nicht für alle Cluster gleich.
• Um zu vermeiden, dass während des parallelen Upgrades eine Datennichtverfügbarkeit auf dem nicht verbundenen Netzwerkpool auftritt, ist eine Netzwerkkonfigurationsänderung auf dem Cluster und der externen Umgebung erforderlich, die in der Regel mehrere Genehmigungen auf Seiten der KundInnen erfordert.
• Dieser Wissensdatenbank-Artikel enthält aufgrund der oben genannten Punkte keine direkte Lösung für den IOCA-Prüffehler.
• Die allgemeine Richtlinie lautet jedoch, dass sich mindestens zwei externe Mitgliedsschnittstellen von zwei Nodes in den betroffenen Netzwerkpools in derselben Nachbarschaft/Fehlerdomäne befinden, um ein getrenntes Netzwerk-/DU-Risiko für diesen SmartConnect-Netzwerkpool zu vermeiden (d. h. Nodes aus derselben Nachbarschaft/Fehlerdomäne zum betroffenen Netzwerkpool hinzufügen). 
• Der KB-Artikel enthält Befehle zum Bestimmen der Nachbarschafts-/Fehlerdomänen des Clusters und der Mitglieds-Nodes in betroffenen Netzwerkpools.

• Verwenden Sie den folgenden Befehl, um die Mitglieds-Nodes in den betroffenen Netzwerkpools zu bestimmen (Hinweis: Ersetzen Sie die Datei "<network-pool 1 ID> | <ID> von Netzwerkpool 2 | <network-pool 3 ID>" mit den betroffenen Netzwerkpool-IDs aus der IOCA-Prüfung und trennen Sie sie mit dem Zeichen "|"). 

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

• Führen Sie den folgenden Befehl aus, um die Nachbarschaften des Clusters zu ermitteln (Hinweis: Ersetzen Sie die <IOCA-Skriptspeicherort> und <neue OneFS-Version> mit den korrekten Werten) 

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

• Vergleichen Sie die Ausgaben der obigen Befehle, um festzustellen, welche Änderungen an den Netzwerkpools des Clusters vorgenommen werden müssen.
• Eine schnelle Lösung wäre, alle Cluster-Nodes zu den betroffenen Netzwerkpools hinzuzufügen, aber das ist oft nicht leicht, da die externe Netzwerkumgebung diese Änderung möglicherweise nicht zulässt.
• Nachdem die erforderlichen Änderungen angewendet wurden, führen Sie die IOCA-Prüfung erneut aus.
• Wenn Sie die erforderlichen Änderungen nicht ermitteln können, öffnen Sie einen Fall beim Support, um weitere Unterstützung zu erhalten.
• Im folgenden Beispiel können Sie die erforderlichen Änderungen in einem Testszenario ermitteln:

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"