PowerFlex: Es posible que las NIC de SVM se asignen incorrectamente durante la conversión de SVM
Resumen: Durante un proceso de conversión de SVM, es posible que las NIC de SVM se asignen incorrectamente.
Síntomas
Un usuario no puede actualizar ni convertir el MDM principal (último MDM) durante una conversión de SVM, ya que las subredes no se pueden comunicar.
Situación
Las NIC se solicitaron incorrectamente después de una conversión de SVM:
Hay dos escenarios posibles:
Escenario #1 - NIC de DATOS principales NIC conmutadas en diferentes subredes (no enrutable):
Al observar el query_cluster podemos ver que las direcciones IP del MDM principal están en el orden opuesto al de las secundarias:
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
El resultado de la interfaz de MDM principal, que puede variar según el sistema operativo (SO), muestra que eth1 está en la subred 10.128.0.x y eth2 está en la subred 10.128.8.x, en el mismo orden que las secundarias:
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
Escenario #2 - NIC conmutadas de IP de MGMT y DATA principales:
La salida de la interfaz MDM principal, que puede variar según el SO, muestra que eth0 contiene la IP de MGMTy eth[1|2] contiene las IP de DATA1 y 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
La salida de las interfaces secundarias de MDM, que puede variar según el SO, muestra que eth0 contiene la IP de DATA1 y eth[1|2] contiene las IP de DATA2 y 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
Al observar el query_cluster resultado, cada nodo espera usar eth1 y eth2 para 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
Impacto
Dado que las subredes no pueden comunicarse, si hay un estado de alarma o una conmutación por error, podría producirse una DU.
Causa
Este problema puede ocurrir si la plantilla se modifica antes de ejecutar el procedimiento de actualización/conversión.
Resolución
Determine la alineación correcta y cambie las NIC para que coincidan con ella. Por lo general, PowerFlex se configura de manera predeterminada en:
ETH0=sio_mgmt ETH1=sio_data1 ETH2=sio_datat2
Pasos para los cambios de eth[0|1|2]:
- Poner el clúster en modo único (debemos quitarlo y volver a agregarlo con el orden correcto de las IP)
- Edite los scripts /etc/sysconfig/network-scripts/ifcfg-eth* en el MDM secundario para que coincida con el orden actual del MDM principal (MGMT en eth0, DATA1 en eth1, DATA2 en eth2)
- Coloque el SDS que reside en el MDM secundario actual en modo de mantenimiento (MM), ya que cambiaremos las direcciones IP con un reinicio
- Reinicie la SVM que se colocó en MM
- Al volver a conectarse a este nodo, verifique que las direcciones IP estén en el mismo orden que el MDM principal actual, como se mencionó en el paso #2
- Asegúrese de que el SDS esté reconectado y, a continuación, salga de MM
- Eliminar el MDM secundario que acabamos de reiniciar del clúster de MDM
- Vuelva a agregarlo como MDM en espera y asegúrese de que el orden de las direcciones IP en "new_mdm_ip" coincida con el principal actual (DATA1, DATA2)
- Vuelva al modo de 3 nodos/5 nodos
- Verifique que el clúster esté en buen estado y sincronizado
- Cambiar propiedad de MDM
- Una vez que el cambio de propiedad de MDM se haya realizado correctamente, continúe con el último nodo restante para la actualización/conversión de SVM
Versiones afectadas
VxFlex OS 3.0.x
Problema corregido en la versión
VxFlex OS 3.0.1.5
PowerFlex 3.5.1.3
PowerFlex 3.6.0.327
PowerFlex 4.0.0.1003