Reemplace los conmutadores de clúster Cisco Nexus 92300YC con conexiones sin conmutador
Puede migrar de un clúster con una red de clúster conmutada a uno donde dos nodos estén conectados directamente para ONTAP 9.3 y versiones posteriores.
Requisitos de revisión
Revise las siguientes directrices:
-
La migración a una configuración de clúster sin conmutador de dos nodos es una operación no disruptiva. La mayoría de los sistemas tienen dos puertos de interconexión de clúster dedicados en cada nodo, pero también puede utilizar este procedimiento para sistemas con un mayor número de puertos de interconexión de clúster dedicados en cada nodo, como cuatro, seis u ocho.
-
No se puede utilizar la función de interconexión de clúster sin conmutador con más de dos nodos.
-
Si tiene un clúster existente de dos nodos que utiliza conmutadores de interconexión de clúster y ejecuta ONTAP 9.3 o posterior, puede reemplazar los conmutadores con conexiones directas, de espaldas entre los nodos.
Asegúrese de tener lo siguiente:
-
Un clúster saludable que consta de dos nodos conectados por conmutadores de clúster. Los nodos deben estar ejecutando la misma versión de ONTAP .
-
Cada nodo cuenta con el número necesario de puertos de clúster dedicados, que proporcionan conexiones de interconexión de clúster redundantes para dar soporte a la configuración de su sistema. Por ejemplo, existen dos puertos redundantes para un sistema con dos puertos de interconexión de clúster dedicados en cada nodo.
Migrar los interruptores
El siguiente procedimiento elimina los conmutadores del clúster en un clúster de dos nodos y reemplaza cada conexión al conmutador con una conexión directa al nodo asociado.
Los ejemplos del siguiente procedimiento muestran nodos que utilizan "e0a" y "e0b" como puertos de clúster. Es posible que sus nodos estén utilizando diferentes puertos de clúster, ya que estos varían según el sistema.
Paso 1: Prepararse para la migración
-
Cambie el nivel de privilegio a avanzado, ingresando
ycuando se le solicite continuar:set -privilege advancedLa solicitud avanzada
*>aparece. -
ONTAP 9.3 y versiones posteriores admiten la detección automática de clústeres sin conmutador, que está habilitada de forma predeterminada.
Puede verificar que la detección de clústeres sin conmutador está habilitada ejecutando el comando con privilegios avanzados:
network options detect-switchless-cluster showMostrar ejemplo
El siguiente ejemplo de salida muestra si la opción está habilitada.
cluster::*> network options detect-switchless-cluster show (network options detect-switchless-cluster show) Enable Switchless Cluster Detection: true
Si "Habilitar detección de clúster sin interruptor" está activado
false, contacte con el soporte de NetApp . -
Si AutoSupport está habilitado en este clúster, suprima la creación automática de casos invocando un mensaje de AutoSupport :
system node autosupport invoke -node * -type all -message MAINT=<number_of_hours>hdónde
hes la duración del período de mantenimiento en horas. El mensaje notifica al soporte técnico sobre esta tarea de mantenimiento para que puedan suprimir la creación automática de casos durante la ventana de mantenimiento.En el siguiente ejemplo, el comando suprime la creación automática de casos durante dos horas:
Mostrar ejemplo
cluster::*> system node autosupport invoke -node * -type all -message MAINT=2h
Paso 2: Configurar puertos y cableado
-
Organice los puertos del clúster en cada conmutador en grupos de manera que los puertos del clúster en el grupo 1 vayan al conmutador de clúster 1 y los puertos del clúster en el grupo 2 vayan al conmutador de clúster 2. Estos grupos se requerirán más adelante en el procedimiento.
-
Identifique los puertos del clúster y verifique el estado y la salud del enlace:
network port show -ipspace ClusterEn el siguiente ejemplo para nodos con puertos de clúster "e0a" y "e0b", un grupo se identifica como "node1:e0a" y "node2:e0a" y el otro grupo como "node1:e0b" y "node2:e0b". Es posible que sus nodos estén utilizando diferentes puertos de clúster porque estos varían según el sistema.
Verifique que los puertos tengan un valor de
uppara la columna “Enlace” y un valor dehealthypara la columna “Estado de salud”.Mostrar ejemplo
cluster::> network port show -ipspace Cluster Node: node1 Ignore Speed(Mbps) Health Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status Status ----- --------- ---------------- ----- ----- ----------- ------- ------- e0a Cluster Cluster up 9000 auto/10000 healthy false e0b Cluster Cluster up 9000 auto/10000 healthy false Node: node2 Ignore Speed(Mbps) Health Health Port IPspace Broadcast Domain Link MTU Admin/Oper Status Status ----- --------- ---------------- ----- ----- ----------- ------- ------- e0a Cluster Cluster up 9000 auto/10000 healthy false e0b Cluster Cluster up 9000 auto/10000 healthy false 4 entries were displayed. -
Confirme que todos los LIF del clúster están en sus puertos de inicio.
Verifique que la columna “is-home” sea correcta.
truepara cada uno de los LIF del clúster:network interface show -vserver Cluster -fields is-homeMostrar ejemplo
cluster::*> net int show -vserver Cluster -fields is-home (network interface show) vserver lif is-home -------- ------------ -------- Cluster node1_clus1 true Cluster node1_clus2 true Cluster node2_clus1 true Cluster node2_clus2 true 4 entries were displayed.
Si hay LIF de clúster que no están en sus puertos de origen, redirija esas LIF a sus puertos de origen:
network interface revert -vserver Cluster -lif * -
Deshabilitar la reversión automática para los LIF del clúster:
network interface modify -vserver Cluster -lif * -auto-revert false -
Verifique que todos los puertos enumerados en el paso anterior estén conectados a un conmutador de red:
network device-discovery show -port cluster_portLa columna “Dispositivo detectado” debe mostrar el nombre del conmutador del clúster al que está conectado el puerto.
Mostrar ejemplo
El siguiente ejemplo muestra que los puertos del clúster "e0a" y "e0b" están conectados correctamente a los conmutadores del clúster "cs1" y "cs2".
cluster::> network device-discovery show -port e0a|e0b (network device-discovery show) Node/ Local Discovered Protocol Port Device (LLDP: ChassisID) Interface Platform --------- ------ ------------------------- ---------- ---------- node1/cdp e0a cs1 0/11 BES-53248 e0b cs2 0/12 BES-53248 node2/cdp e0a cs1 0/9 BES-53248 e0b cs2 0/9 BES-53248 4 entries were displayed. -
Verifique la conectividad de las interfaces del clúster remoto:
Puedes usar el network interface check cluster-connectivity comando para iniciar una comprobación de accesibilidad para la conectividad del clúster y luego mostrar los detalles:
network interface check cluster-connectivity start`y `network interface check cluster-connectivity show
cluster1::*> network interface check cluster-connectivity start
NOTA: Espere unos segundos antes de ejecutar el programa. show comando para mostrar los detalles.
cluster1::*> network interface check cluster-connectivity show
Source Destination Packet
Node Date LIF LIF Loss
------ -------------------------- ---------------- ---------------- -----------
node1
3/5/2022 19:21:18 -06:00 node1_clus2 node2-clus1 none
3/5/2022 19:21:20 -06:00 node1_clus2 node2_clus2 none
node2
3/5/2022 19:21:18 -06:00 node2_clus2 node1_clus1 none
3/5/2022 19:21:20 -06:00 node2_clus2 node1_clus2 none
Para todas las versiones de ONTAP , también puede usar el cluster ping-cluster -node <name> comando para comprobar la conectividad:
cluster ping-cluster -node <name>
cluster1::*> cluster ping-cluster -node local Host is node2 Getting addresses from network interface table... Cluster node1_clus1 169.254.209.69 node1 e0a Cluster node1_clus2 169.254.49.125 node1 e0b Cluster node2_clus1 169.254.47.194 node2 e0a Cluster node2_clus2 169.254.19.183 node2 e0b Local = 169.254.47.194 169.254.19.183 Remote = 169.254.209.69 169.254.49.125 Cluster Vserver Id = 4294967293 Ping status: Basic connectivity succeeds on 4 path(s) Basic connectivity fails on 0 path(s) Detected 9000 byte MTU on 4 path(s): Local 169.254.47.194 to Remote 169.254.209.69 Local 169.254.47.194 to Remote 169.254.49.125 Local 169.254.19.183 to Remote 169.254.209.69 Local 169.254.19.183 to Remote 169.254.49.125 Larger than PMTU communication succeeds on 4 path(s) RPC status: 2 paths up, 0 paths down (tcp check) 2 paths up, 0 paths down (udp check)
-
Verificar que el clúster esté en buen estado:
cluster ring showTodas las unidades deben ser maestras o secundarias.
-
Configure la configuración sin conmutador para los puertos del grupo 1.
Para evitar posibles problemas de red, debe desconectar los puertos del grupo 1 y volver a conectarlos uno tras otro lo más rápido posible, por ejemplo, en menos de 20 segundos. -
Desconecta simultáneamente todos los cables de los puertos del grupo 1.
En el siguiente ejemplo, los cables se desconectan del puerto "e0a" en cada nodo, y el tráfico del clúster continúa a través del conmutador y el puerto "e0b" en cada nodo:
-
Conecte los puertos del grupo 1 espalda con espalda.
En el siguiente ejemplo, "e0a" en el nodo1 está conectado a "e0a" en el nodo2:
-
-
La opción de red de clúster sin conmutador realiza la transición desde
falseatrue. Esto podría tardar hasta 45 segundos. Confirme que la opción sin interruptor está configurada entrue:network options switchless-cluster showEl siguiente ejemplo muestra que el clúster sin conmutador está habilitado:
cluster::*> network options switchless-cluster show Enable Switchless Cluster: true
-
Verifique la conectividad de las interfaces del clúster remoto:
Puedes usar el network interface check cluster-connectivity comando para iniciar una comprobación de accesibilidad para la conectividad del clúster y luego mostrar los detalles:
network interface check cluster-connectivity start`y `network interface check cluster-connectivity show
cluster1::*> network interface check cluster-connectivity start
NOTA: Espere unos segundos antes de ejecutar el programa. show comando para mostrar los detalles.
cluster1::*> network interface check cluster-connectivity show
Source Destination Packet
Node Date LIF LIF Loss
------ -------------------------- ---------------- ---------------- -----------
node1
3/5/2022 19:21:18 -06:00 node1_clus2 node2-clus1 none
3/5/2022 19:21:20 -06:00 node1_clus2 node2_clus2 none
node2
3/5/2022 19:21:18 -06:00 node2_clus2 node1_clus1 none
3/5/2022 19:21:20 -06:00 node2_clus2 node1_clus2 none
Para todas las versiones de ONTAP , también puede usar el cluster ping-cluster -node <name> comando para comprobar la conectividad:
cluster ping-cluster -node <name>
cluster1::*> cluster ping-cluster -node local Host is node2 Getting addresses from network interface table... Cluster node1_clus1 169.254.209.69 node1 e0a Cluster node1_clus2 169.254.49.125 node1 e0b Cluster node2_clus1 169.254.47.194 node2 e0a Cluster node2_clus2 169.254.19.183 node2 e0b Local = 169.254.47.194 169.254.19.183 Remote = 169.254.209.69 169.254.49.125 Cluster Vserver Id = 4294967293 Ping status: Basic connectivity succeeds on 4 path(s) Basic connectivity fails on 0 path(s) Detected 9000 byte MTU on 4 path(s): Local 169.254.47.194 to Remote 169.254.209.69 Local 169.254.47.194 to Remote 169.254.49.125 Local 169.254.19.183 to Remote 169.254.209.69 Local 169.254.19.183 to Remote 169.254.49.125 Larger than PMTU communication succeeds on 4 path(s) RPC status: 2 paths up, 0 paths down (tcp check) 2 paths up, 0 paths down (udp check)
|
|
Antes de pasar al siguiente paso, debe esperar al menos dos minutos para confirmar una conexión directa en funcionamiento en el grupo 1. |
-
Configure la configuración sin interruptor para los puertos del grupo 2.
Para evitar posibles problemas de red, debe desconectar los puertos del grupo 2 y volver a conectarlos uno tras otro lo más rápido posible, por ejemplo, en menos de 20 segundos. -
Desconecta simultáneamente todos los cables de los puertos del grupo 2.
En el siguiente ejemplo, los cables se desconectan del puerto "e0b" en cada nodo, y el tráfico del clúster continúa a través de la conexión directa entre los puertos "e0a":
-
Conecte los puertos del grupo 2 espalda con espalda.
En el siguiente ejemplo, "e0a" en el nodo1 está conectado a "e0a" en el nodo2 y "e0b" en el nodo1 está conectado a "e0b" en el nodo2:
-
Paso 3: Verificar la configuración
-
Verifique que los puertos de ambos nodos estén conectados correctamente:
network device-discovery show -port cluster_portMostrar ejemplo
El siguiente ejemplo muestra que los puertos del clúster "e0a" y "e0b" están correctamente conectados al puerto correspondiente en el socio del clúster:
cluster::> net device-discovery show -port e0a|e0b (network device-discovery show) Node/ Local Discovered Protocol Port Device (LLDP: ChassisID) Interface Platform ---------- ------ ------------------------- ---------- ---------- node1/cdp e0a node2 e0a AFF-A300 e0b node2 e0b AFF-A300 node1/lldp e0a node2 (00:a0:98:da:16:44) e0a - e0b node2 (00:a0:98:da:16:44) e0b - node2/cdp e0a node1 e0a AFF-A300 e0b node1 e0b AFF-A300 node2/lldp e0a node1 (00:a0:98:da:87:49) e0a - e0b node1 (00:a0:98:da:87:49) e0b - 8 entries were displayed. -
Reactivar la reversión automática para los LIF del clúster:
network interface modify -vserver Cluster -lif * -auto-revert true -
Verifique que todos los LIF estén en casa. Esto podría tardar unos segundos.
network interface show -vserver Cluster -lif lif_nameMostrar ejemplo
Los LIF se han revertido si la columna “Está en casa” está
true, como se muestra paranode1_clus2ynode2_clus2en el siguiente ejemplo:cluster::> network interface show -vserver Cluster -fields curr-port,is-home vserver lif curr-port is-home -------- ------------- --------- ------- Cluster node1_clus1 e0a true Cluster node1_clus2 e0b true Cluster node2_clus1 e0a true Cluster node2_clus2 e0b true 4 entries were displayed.
Si algún clúster LIFS no ha regresado a sus puertos de origen, rediríjalos manualmente desde el nodo local:
network interface revert -vserver Cluster -lif lif_name -
Compruebe el estado del clúster de los nodos desde la consola del sistema de cualquiera de los nodos:
cluster showMostrar ejemplo
El siguiente ejemplo muestra que épsilon en ambos nodos es
false:Node Health Eligibility Epsilon ----- ------- ----------- -------- node1 true true false node2 true true false 2 entries were displayed.
-
Verifique la conectividad de las interfaces del clúster remoto:
Puedes usar el network interface check cluster-connectivity comando para iniciar una comprobación de accesibilidad para la conectividad del clúster y luego mostrar los detalles:
network interface check cluster-connectivity start`y `network interface check cluster-connectivity show
cluster1::*> network interface check cluster-connectivity start
NOTA: Espere unos segundos antes de ejecutar el programa. show comando para mostrar los detalles.
cluster1::*> network interface check cluster-connectivity show
Source Destination Packet
Node Date LIF LIF Loss
------ -------------------------- ---------------- ---------------- -----------
node1
3/5/2022 19:21:18 -06:00 node1_clus2 node2-clus1 none
3/5/2022 19:21:20 -06:00 node1_clus2 node2_clus2 none
node2
3/5/2022 19:21:18 -06:00 node2_clus2 node1_clus1 none
3/5/2022 19:21:20 -06:00 node2_clus2 node1_clus2 none
Para todas las versiones de ONTAP , también puede usar el cluster ping-cluster -node <name> comando para comprobar la conectividad:
cluster ping-cluster -node <name>
cluster1::*> cluster ping-cluster -node local Host is node2 Getting addresses from network interface table... Cluster node1_clus1 169.254.209.69 node1 e0a Cluster node1_clus2 169.254.49.125 node1 e0b Cluster node2_clus1 169.254.47.194 node2 e0a Cluster node2_clus2 169.254.19.183 node2 e0b Local = 169.254.47.194 169.254.19.183 Remote = 169.254.209.69 169.254.49.125 Cluster Vserver Id = 4294967293 Ping status: Basic connectivity succeeds on 4 path(s) Basic connectivity fails on 0 path(s) Detected 9000 byte MTU on 4 path(s): Local 169.254.47.194 to Remote 169.254.209.69 Local 169.254.47.194 to Remote 169.254.49.125 Local 169.254.19.183 to Remote 169.254.209.69 Local 169.254.19.183 to Remote 169.254.49.125 Larger than PMTU communication succeeds on 4 path(s) RPC status: 2 paths up, 0 paths down (tcp check) 2 paths up, 0 paths down (udp check)
-
Si suprimió la creación automática de casos, vuelva a habilitarla invocando un mensaje de AutoSupport :
system node autosupport invoke -node * -type all -message MAINT=ENDPara obtener más información, consulte "Artículo 1010449 de la base de conocimientos de NetApp : Cómo suprimir la creación automática de casos durante las ventanas de mantenimiento programadas".
-
Vuelva a cambiar el nivel de privilegios a administrador:
set -privilege admin