PowerFlex 3.X: SVM-NICs werden während der SVM-Konvertierung möglicherweise falsch zugewiesen

Ein Nutzer kann während einer SVM-Konvertierung den primären MDM (letzten MDM) nicht aktualisieren oder konvertieren, da die Subnetze nicht miteinander kommunizieren können.

Die NICs wurden nach einer SVM-Konvertierung falsch bestellt:

Es gibt zwei mögliche Szenarien:

Szenario #1 - Primäre DATEN-NICs geschaltete NICs in verschiedenen Subnetzen (nicht routingfähig):

Bei einem Blick auf die query_cluster Ausgabe können wir sehen, dass die IP-Adressen des primären MDM in der entgegengesetzten Reihenfolge der sekundären sind:

Primary MDM:
    Name: Secondary_MDM2, ID: 0x6a3e3168772f4322
        IP Addresses: 10.128.8.62, 10.128.0.62, Management IP Addresses: 10.63.193.162, Port: 9011, Virtual IP interfaces: eth1, eth2
Secondary MDMs:
    Name: Secondary_MDM1, ID: 0x3faea7c32806b951
        IP Addresses: 10.128.0.61, 10.128.8.61, Management IP Addresses: 10.63.193.161, Port: 9011, Virtual IP interfaces: eth1, eth2
    Name: Primary_MDM, ID: 0x02d885dd7c5fc180
        IP Addresses: 10.128.0.60, 10.128.8.60, Management IP Addresses: 10.63.193.160, Port: 9011, Virtual IP interfaces: eth1, eth2

Die Ausgabe der primären MDM-Schnittstelle, die je nach Betriebssystem (BS) variieren kann, zeigt, dass sich eth1 im Subnetz 10.128.0.x und eth2 im Subnetz 10.128.8.x befindet, und zwar in der gleichen Reihenfolge wie die sekundären Subnetze:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.63.193.162  netmask 255.255.255.128  broadcast 10.63.193.255
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 10.128.0.62  netmask 255.255.248.0  broadcast 10.128.7.255
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 10.128.8.62  netmask 255.255.248.0  broadcast 10.128.15.255

Szenario #2 - Primäre MGMT- und DATA-IPs geschaltete NICs:

Die Ausgabe der primären MDM-Schnittstelle, die je nach Betriebssystem variieren kann, zeigt, dass eth0 die MGMT-IP und eth[1|2] die DATA1- und DATA2-IPs enthält:

eth0      Link encap:Ethernet  HWaddr 00:50:56:91:97:CD  
          inet addr:10.202.5.13  Bcast:10.202.5.255  Mask:255.255.255.0
eth1      Link encap:Ethernet  HWaddr 00:50:56:91:3A:FB  
          inet addr:192.168.152.28  Bcast:192.168.159.255  Mask:255.255.248.0
eth2      Link encap:Ethernet  HWaddr 00:50:56:91:4E:57  
          inet addr:192.168.160.28  Bcast:192.168.167.255  Mask:255.255.248.0

Die Ausgabe der sekundären MDM-Schnittstellen, die je nach Betriebssystem variieren kann, zeigt, dass eth0 die DATA1-IP und eth[1|2] die DATA2- und MGMT-IPs enthält:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.152.27  netmask 255.255.248.0  broadcast 192.168.159.255
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.160.27  netmask 255.255.248.0  broadcast 192.168.167.255
eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.202.5.12  netmask 255.255.255.0  broadcast 10.202.5.255

Bei einem Blick auf die query_cluster erwartet jeder Node, eth1 und eth2 für VIPs zu verwenden:

Master MDM:
    Name: agent-svm-de1801vmwesx002, ID: 0x52cd360827eb8e63
        IPs: 192.168.152.28, 192.168.160.28, Management IPs: 10.202.5.13, Port: 9011, Virtual IP interfaces: eth1, eth2
        Version: 2.6.11000
Slave MDMs:
    Name: agent-svm-de1801vmwesx001, ID: 0x361d56fd178799e0
        IPs: 192.168.160.27, 192.168.152.27, Management IPs: 10.202.5.12, Port: 9011, Virtual IP interfaces: eth1, eth2
        Status: Normal, Version: 2.6.11000

Auswirkungen

Da die Subnetze nicht kommunizieren können, kann es bei einem Fehler oder Failover zu einer Nichtverfügbarkeit von Daten kommen.

Dieses Problem kann auftreten, wenn die Vorlage geändert wird, bevor das Upgrade-/Konvertierungsverfahren ausgeführt wird.

Bestimmen Sie die richtige Ausrichtung und passen Sie die NICs an. PowerFlex hat in der Regel die folgenden Standardwerte:

ETH0=sio_mgmt
ETH1=sio_data1
ETH2=sio_datat2

Schritte für eth[0|1|2]-Änderungen:

1. Versetzen Sie das Cluster in den Einzelmodus (wir müssen es entfernen und mit der richtigen Reihenfolge der IPs erneut hinzufügen).
2. Bearbeiten Sie die /etc/sysconfig/network-scripts/ifcfg-eth*-Skripte auf dem sekundären MDM so, dass sie der aktuellen primären MDM-Reihenfolge entsprechen (MGMT auf eth0, DATA1 auf eth1, DATA2 auf eth2)
3. Versetzen Sie den SDS, der sich auf dem aktuellen sekundären MDM befindet, in den Wartungsmodus (Maintenance Mode, MM), da die IP-Adressen mit einem Neustart geändert werden.
4. Starten Sie die SVM neu, die in MM platziert wurde.
5. Überprüfen Sie beim erneuten Verbinden mit diesem Node, dass sich die IPs in der gleichen Reihenfolge wie der aktuelle primäre MDM befinden, wie in Schritt #2 erwähnt
6. Stellen Sie sicher, dass der SDS wieder angeschlossen ist, und beenden Sie dann MM.
7. Entfernen Sie den sekundären MDM, den wir gerade aus dem MDM-Cluster neu gestartet haben.
8. Fügen Sie sie als Stand-by-MDM erneut hinzu und stellen Sie sicher, dass die Reihenfolge der IPs in "new_mdm_ip" mit der aktuellen primären (DATA1, DATA2) übereinstimmt.
9. Wechseln Sie zurück in den 3-Node-/5-Node-Modus
10. Überprüfen Sie, ob das Cluster funktionsfähig und synchronisiert ist.
11. Wechseln der MDM-Eigentumsrechte
12. Sobald die Eigentümerschaft des Switch-MDM erfolgreich ist, fahren Sie mit dem letzten verbleibenden Node für das SVM-Upgrade/die Konvertierung fort.

Betroffene Versionen

VxFlex OS 3.0.x 

Behoben in Version

VxFlex OS 3.0.1.5

PowerFlex 3.5.1.3

PowerFlex 3.6.0.327

PowerFlex 4.0.0.1003