PowerFlex: Karty sieciowe SVM mogą być niepoprawnie przypisane podczas konwersji SVM
Summary: Podczas procesu konwersji SVM karty sieciowe SVM mogą być przypisane niepoprawnie.
Symptoms
Użytkownik nie może uaktualnić ani przekonwertować podstawowego MDM (ostatniego MDM) podczas konwersji SVM, ponieważ podsieci nie mogą się komunikować.
Scenariusz
Karty sieciowe zostały nieprawidłowo uporządkowane po konwersji SVM:
Istnieją dwa możliwe scenariusze:
Scenariusz #1 — podstawowe karty sieciowe DATA przełączają karty sieciowe w różnych podsieciach (nie można trasować):
Patrząc na query_cluster możemy zobaczyć, że adresy IP podstawowego MDM są w odwrotnej kolejności niż dodatkowe:
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
Dane wyjściowe podstawowego interfejsu MDM, które mogą się różnić w zależności od systemu operacyjnego (OS), pokazują, że eth1 znajduje się w podsieci 10.128.0.x, a eth2 znajduje się w podsieci 10.128.8.x, w tej samej kolejności co pomocnicze:
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
Scenariusz #2 — podstawowe karty sieciowe przełączane przez adresy IP zarządzania i danych:
Dane wyjściowe podstawowego interfejsu MDM, które mogą się różnić w zależności od systemu operacyjnego, pokazują, że eth0 przechowuje adres IP MGMT, a eth[1|2] przechowuje adresy IP DATA1 i DATA2:
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
Dane wyjściowe dodatkowych interfejsów MDM, które mogą się różnić w zależności od systemu operacyjnego, pokazują, że eth0 przechowuje adres IP DATA1 , a eth[1|2] przechowuje adresy IP DATA2 i MGMT:
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
Patrząc na query_cluster dane wyjściowe, każdy węzeł oczekuje użycia eth1 i eth2 dla adresów VIP:
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
Wpływ
Ponieważ podsieci nie mogą się komunikować, w przypadku awarii lub przejścia w tryb failover może to spowodować DU.
Cause
Ten problem może wystąpić, jeśli szablon zostanie zmodyfikowany przed uruchomieniem procedury uaktualnienia/konwersji.
Resolution
Określ prawidłowe wyrównanie i zmień zgodne z nim karty sieciowe. PowerFlex zazwyczaj stosuje się domyślnie:
ETH0=sio_mgmt ETH1=sio_data1 ETH2=sio_datat2
Kroki dla zmian w eth[0|1|2]:
- Przełącz klaster w tryb pojedynczy (musimy usunąć i ponownie dodać z odpowiednią kolejnością adresów IP)
- Edytuj skrypty /etc/sysconfig/network-scripts/ifcfg-eth* w dodatkowym MDM, aby dopasować je do bieżącej podstawowej kolejności MDM (MGMT na eth0, DATA1 na eth1, DATA2 na eth2)
- Przełącz SDS znajdujący się w bieżącym dodatkowym MDM w tryb konserwacji (MM), ponieważ zmieniamy adresy IP po ponownym uruchomieniu
- Uruchom ponownie SVM umieszczone w module MM
- Po ponownym nawiązaniu połączenia z tym węzłem sprawdź, czy adresy IP są w tej samej kolejności co bieżący podstawowy MDM, jak wspomniano w kroku #2
- Upewnij się, że serwer SDS jest ponownie podłączony, a następnie wyjdź z modułu MM
- Usuń dodatkowy MDM, który właśnie został ponownie uruchomiony z klastra MDM
- Dodaj ponownie jako rezerwowe MDM, upewniając się, że kolejność adresów IP w "new_mdm_ip" jest zgodna z bieżącym podstawowym (DATA1, DATA2)
- Zmień z powrotem na tryb 3-węzłowy/5-węzłowy
- Sprawdź, czy klaster jest prawidłowy i zsynchronizowany
- Przełączanie własności MDM
- Po pomyślnym przejęciu własności MDM przełącznika przejdź do ostatniego pozostałego węzła do aktualizacji/konwersji SVM
Wersje, których dotyczy problem
System operacyjny VxFlex 3.0.x
Naprawiono w wersji
System operacyjny VxFlex 3.0.1.5
PowerFlex 3.5.1.3
PowerFlex 3.6.0.327
PowerFlex 4.0.0.1003