Sostituire gli switch cluster Cisco Nexus 9336C-FX2 con connessioni senza switch
È possibile migrare da un cluster con una rete cluster commutata a uno in cui due nodi sono collegati direttamente per ONTAP 9.3 e versioni successive.
Verifica dei requisiti
Consultare le seguenti linee guida:
-
La migrazione a una configurazione cluster senza switch a due nodi è un'operazione senza interruzioni. La maggior parte dei sistemi dispone di due porte di interconnessione cluster dedicate su ciascun nodo, ma è possibile utilizzare questa procedura anche per i sistemi con un numero maggiore di porte di interconnessione cluster dedicate su ciascun nodo, ad esempio quattro, sei o otto.
-
Non è possibile utilizzare la funzione di interconnessione del cluster senza switch con più di due nodi.
-
Se si dispone di un cluster a due nodi esistente che utilizza switch di interconnessione cluster e utilizza ONTAP 9.3 o versione successiva, è possibile sostituire gli switch con connessioni dirette back-to-back tra i nodi.
-
Un cluster integro costituito da due nodi collegati da switch di cluster. I nodi devono eseguire la stessa release di ONTAP.
-
Ciascun nodo con il numero richiesto di porte cluster dedicate, che forniscono connessioni di interconnessione cluster ridondanti per supportare la configurazione del sistema. Ad esempio, esistono due porte ridondanti per un sistema con due porte di interconnessione cluster dedicate su ciascun nodo.
Migrare gli switch
La seguente procedura rimuove gli switch del cluster in un cluster a due nodi e sostituisce ogni connessione allo switch con una connessione diretta al nodo partner.
Gli esempi della seguente procedura mostrano i nodi che utilizzano "e0a" e "e0b" come porte del cluster. I nodi potrebbero utilizzare porte cluster diverse in base al sistema.
Fase 1: Preparazione per la migrazione
-
Impostare il livello di privilegio su Advanced (avanzato), immettendo
y
quando viene richiesto di continuare:set -privilege advanced
Il prompt avanzato
*>
viene visualizzato. -
ONTAP 9.3 e versioni successive supportano il rilevamento automatico dei cluster senza switch, attivato per impostazione predefinita.
È possibile verificare che il rilevamento dei cluster senza switch sia attivato eseguendo il comando Advanced Privilege:
network options detect-switchless-cluster show
Mostra esempio
Il seguente esempio di output mostra se l'opzione è attivata.
cluster::*> network options detect-switchless-cluster show (network options detect-switchless-cluster show) Enable Switchless Cluster Detection: true
Se "Enable Switchless Cluster Detection" (attiva rilevamento cluster senza switch) è
false
, Contattare il supporto NetApp. -
Se AutoSupport è attivato su questo cluster, eliminare la creazione automatica del caso richiamando un messaggio AutoSupport:
system node autosupport invoke -node * -type all -message MAINT=<number_of_hours>h
dove
h
indica la durata della finestra di manutenzione in ore. Il messaggio informa il supporto tecnico di questa attività di manutenzione in modo che possa eliminare la creazione automatica del caso durante la finestra di manutenzione.Nell'esempio seguente, il comando sospende la creazione automatica del caso per due ore:
Mostra esempio
cluster::*> system node autosupport invoke -node * -type all -message MAINT=2h
Fase 2: Configurare le porte e il cablaggio
-
Organizzare le porte del cluster su ciascun switch in gruppi in modo che le porte del cluster nel gruppo 1 vadano allo switch del cluster 1 e le porte del cluster nel gruppo 2 vadano allo switch2 del cluster. Questi gruppi sono richiesti più avanti nella procedura.
-
Identificare le porte del cluster e verificare lo stato e lo stato del collegamento:
network port show -ipspace Cluster
Nell'esempio seguente per i nodi con porte cluster "e0a" e "e0b", un gruppo viene identificato come "node1:e0a" e "node2:e0a" e l'altro come "node1:e0b" e "node2:e0b". I nodi potrebbero utilizzare porte cluster diverse in quanto variano in base al sistema.
Verificare che il valore delle porte sia di
up
Per la colonna "link" e un valore dihealthy
Per la colonna "Health Status" (Stato salute).Mostra esempio
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.
-
Verificare che tutte le LIF del cluster si trovino sulle porte home.
Verificare che la colonna "is-home" sia
true
Per ciascuna LIF del cluster:network interface show -vserver Cluster -fields is-home
Mostra esempio
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.
Se sono presenti LIF del cluster che non si trovano sulle porte home, ripristinare tali LIF alle porte home:
network interface revert -vserver Cluster -lif *
-
Disattivare l'autorevert per le LIF del cluster:
network interface modify -vserver Cluster -lif * -auto-revert false
-
Verificare che tutte le porte elencate nella fase precedente siano collegate a uno switch di rete:
network device-discovery show -port cluster_port
La colonna "dispositivo rilevato" deve essere il nome dello switch del cluster a cui è collegata la porta.
Mostra esempio
L'esempio seguente mostra che le porte del cluster "e0a" e "e0b" sono collegate correttamente agli switch del cluster "cs1" e "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.
-
Verificare la connettività delle interfacce del cluster remoto:
È possibile utilizzare network interface check cluster-connectivity
per avviare un controllo di accessibilità per la connettività del cluster e visualizzare i dettagli:
network interface check cluster-connectivity start
e. network interface check cluster-connectivity show
cluster1::*> network interface check cluster-connectivity start
NOTA: attendere alcuni secondi prima di eseguire il show
comando per visualizzare i dettagli.
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
Per tutte le release di ONTAP, è possibile utilizzare anche cluster ping-cluster -node <name>
comando per controllare la connettività:
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)
-
verificare che il cluster sia integro:
cluster ring show
Tutte le unità devono essere master o secondarie.
-
Impostare la configurazione senza switch per le porte del gruppo 1.
Per evitare potenziali problemi di rete, è necessario scollegare le porte dal raggruppo1 e ricollegarle il più rapidamente possibile, ad esempio in meno di 20 secondi. -
Scollegare tutti i cavi dalle porte del raggruppo1 contemporaneamente.
Nell'esempio seguente, i cavi vengono scollegati dalla porta "e0a" su ciascun nodo e il traffico del cluster continua attraverso lo switch e la porta "e0b" su ciascun nodo:
-
Collegare le porte del gruppo 1 da una parte all'altro.
Nell'esempio seguente, "e0a" sul nodo 1 è collegato a "e0a" sul nodo 2:
-
-
L'opzione di rete del cluster senza switch passa da
false
a.true
. Questa operazione potrebbe richiedere fino a 45 secondi. Verificare che l'opzione switchless sia impostata sutrue
:network options switchless-cluster show
Il seguente esempio mostra che il cluster senza switch è abilitato:
cluster::*> network options switchless-cluster show Enable Switchless Cluster: true
-
Verificare la connettività delle interfacce del cluster remoto:
È possibile utilizzare network interface check cluster-connectivity
per avviare un controllo di accessibilità per la connettività del cluster e visualizzare i dettagli:
network interface check cluster-connectivity start
e. network interface check cluster-connectivity show
cluster1::*> network interface check cluster-connectivity start
NOTA: attendere alcuni secondi prima di eseguire il show
comando per visualizzare i dettagli.
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
Per tutte le release di ONTAP, è possibile utilizzare anche cluster ping-cluster -node <name>
comando per controllare la connettività:
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)
Prima di passare alla fase successiva, è necessario attendere almeno due minuti per confermare una connessione back-to-back funzionante sul gruppo 1. |
-
impostare la configurazione senza switch per le porte del gruppo 2.
Per evitare potenziali problemi di rete, è necessario scollegare le porte dal gruppo 2 e ricollegarle il più rapidamente possibile, ad esempio in meno di 20 secondi. -
Scollegare tutti i cavi dalle porte del raggruppo2 contemporaneamente.
Nell'esempio seguente, i cavi vengono scollegati dalla porta "e0b" su ciascun nodo e il traffico del cluster continua attraverso la connessione diretta tra le porte "e0a":
-
Collegare le porte del group2 in modo che si inserano nella parte posteriore.
Nell'esempio seguente, "e0a" sul nodo 1 è collegato a "e0a" sul nodo 2 e "e0b" sul nodo 1 è collegato a "e0b" sul nodo 2:
-
Fase 3: Verificare la configurazione
-
Verificare che le porte su entrambi i nodi siano collegate correttamente:
network device-discovery show -port cluster_port
Mostra esempio
L'esempio seguente mostra che le porte del cluster "e0a" e "e0b" sono collegate correttamente alla porta corrispondente sul partner del cluster:
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.
-
Riattivare il ripristino automatico per le LIF del cluster:
network interface modify -vserver Cluster -lif * -auto-revert true
-
Verificare che tutte le LIF siano a casa. Questa operazione potrebbe richiedere alcuni secondi.
network interface show -vserver Cluster -lif lif_name
Mostra esempio
I LIF sono stati ripristinati se la colonna "is Home" è
true
, come illustrato pernode1_clus2
e.node2_clus2
nel seguente esempio: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.
Se uno dei cluster LIFS non è tornato alle porte home, ripristinarli manualmente dal nodo locale:
network interface revert -vserver Cluster -lif lif_name
-
Controllare lo stato del cluster dei nodi dalla console di sistema di uno dei nodi:
cluster show
Mostra esempio
L'esempio seguente mostra epsilon su entrambi i nodi da visualizzare
false
:Node Health Eligibility Epsilon ----- ------- ----------- -------- node1 true true false node2 true true false 2 entries were displayed.
-
Verificare la connettività delle interfacce del cluster remoto:
È possibile utilizzare network interface check cluster-connectivity
per avviare un controllo di accessibilità per la connettività del cluster e visualizzare i dettagli:
network interface check cluster-connectivity start
e. network interface check cluster-connectivity show
cluster1::*> network interface check cluster-connectivity start
NOTA: attendere alcuni secondi prima di eseguire il show
comando per visualizzare i dettagli.
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
Per tutte le release di ONTAP, è possibile utilizzare anche cluster ping-cluster -node <name>
comando per controllare la connettività:
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)