La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Aggiornare una configurazione MetroCluster IP a quattro o otto nodi (ONTAP 9.8 e versioni successive)

10/31/2025 Collaboratori

PDF

È possibile utilizzare questa procedura per aggiornare controller e storage in configurazioni a quattro o otto nodi.

A partire da ONTAP 9.13.1, è possibile aggiornare i controller e lo storage in una configurazione MetroCluster IP a otto nodi espandendo la configurazione fino a diventare una configurazione temporanea a dodici nodi e rimuovendo i vecchi gruppi di disaster recovery (DR).

A partire da ONTAP 9.8, è possibile aggiornare i controller e lo storage in una configurazione MetroCluster IP a quattro nodi espandendo la configurazione fino a diventare una configurazione temporanea a otto nodi e rimuovendo quindi il vecchio gruppo di DR.

Informazioni importanti se si aggiunge un modello di piattaforma precedente

Le seguenti indicazioni riguardano uno scenario insolito in cui è necessario aggiungere un modello di piattaforma precedente (piattaforme rilasciate prima di ONTAP 9.15.1) a una configurazione MetroCluster esistente che contiene un modello di piattaforma più recente (piattaforme rilasciate in ONTAP 9.15.1 o versioni successive).

Se la configurazione MetroCluster esistente contiene una piattaforma che utilizza porte cluster/HA condivise (piattaforme rilasciate in ONTAP 9.15.1 o versioni successive), non è possibile aggiungere una piattaforma che utilizza porte MetroCluster/HA condivise (piattaforme rilasciate prima di ONTAP 9.15.1) senza aggiornare tutti i nodi nella configurazione a ONTAP 9.15.1P11 o ONTAP 9.16.1P4 o versioni successive.

L'aggiunta di un modello di piattaforma più vecchio che utilizza porte condivise/ MetroCluster HA a un MetroCluster contenente un modello di piattaforma più recente che utilizza porte condivise cluster/HA è uno scenario insolito e la maggior parte delle combinazioni non ne è interessata.

Utilizzare la seguente tabella per verificare se la combinazione è interessata. Se la piattaforma esistente è elencata nella prima colonna e la piattaforma che si desidera aggiungere alla configurazione è elencata nella seconda colonna, tutti i nodi nella configurazione devono eseguire ONTAP 9.15.1P11 o ONTAP 9.16.1P4 o versioni successive per aggiungere il nuovo gruppo DR.

Se il tuo MetroCluster esistente contiene…	E la piattaforma che stai aggiungendo è…	Quindi…
Un sistema AFF che utilizza porte cluster/HA condivise: AFF A20 AFF A30 AFF C30 AFF A50 AFF C60 AFF C80 AFF A70 AFF A90 AFF A1K	Un sistema FAS che utilizza porte cluster/HA condivise: FAS50 FAS70 FAS90	Un sistema AFF che utilizza porte MetroCluster/HA condivise: AFF A150, ASA A150 AFF A220 AFF C250, ASA C250 AFF A250, ASA A250 AFF A300 AFF A320 AFF C400, ASA C400 AFF A400, ASA A400 AFF A700 AFF C800, ASA C800 AFF A800, ASA A800 AFF A900, ASA A900	Un sistema FAS che utilizza porte MetroCluster/HA condivise: FAS2750 FAS500f FAS8200 FAS8300 FAS8700 FAS9000 FAS9500	Prima di aggiungere la nuova piattaforma alla configurazione MetroCluster esistente, aggiornare tutti i nodi nella configurazione esistente e in quella nuova a ONTAP 9.15.1P11 o ONTAP 9.16.1P4 o versione successiva.

Se il tuo MetroCluster esistente contiene…

E la piattaforma che stai aggiungendo è…

Quindi…

Un sistema AFF che utilizza porte cluster/HA condivise:

AFF A20
AFF A30
AFF C30
AFF A50
AFF C60
AFF C80
AFF A70
AFF A90
AFF A1K

Un sistema FAS che utilizza porte cluster/HA condivise:

FAS50
FAS70
FAS90

Un sistema AFF che utilizza porte MetroCluster/HA condivise:

AFF A150, ASA A150
AFF A220
AFF C250, ASA C250
AFF A250, ASA A250
AFF A300
AFF A320
AFF C400, ASA C400
AFF A400, ASA A400
AFF A700
AFF C800, ASA C800
AFF A800, ASA A800
AFF A900, ASA A900

Un sistema FAS che utilizza porte MetroCluster/HA condivise:

FAS2750
FAS500f
FAS8200
FAS8300
FAS8700
FAS9000
FAS9500

Prima di aggiungere la nuova piattaforma alla configurazione MetroCluster esistente, aggiornare tutti i nodi nella configurazione esistente e in quella nuova a ONTAP 9.15.1P11 o ONTAP 9.16.1P4 o versione successiva.

A proposito di questa attività

Se si dispone di una configurazione a otto nodi, il sistema deve eseguire ONTAP 9.13.1 o versione successiva.
Se si dispone di una configurazione a quattro nodi, il sistema deve eseguire ONTAP 9.8 o versione successiva.
Se si stanno aggiornando anche gli switch IP, è necessario aggiornarli prima di eseguire questa procedura di aggiornamento.

Questa procedura descrive i passaggi necessari per aggiornare un gruppo DR a quattro nodi. Se si dispone di una configurazione a otto nodi (due gruppi DR), è possibile aggiornare uno o entrambi i gruppi DR.

 Refresh DR groups one at a time.
* References to "old nodes" mean the nodes that you intend to replace.
* For eight-node configurations, the source and target eight-node MetroCluster platform combination must be supported.

Se si aggiornano entrambi i gruppi di DR, la combinazione di piattaforme potrebbe non essere supportata dopo l'aggiornamento del primo gruppo di DR. È necessario aggiornare entrambi i gruppi di DR per ottenere una configurazione a otto nodi supportata.

È possibile aggiornare solo modelli di piattaforma specifici utilizzando questa procedura in una configurazione MetroCluster IP.
- Per informazioni sulle combinazioni di upgrade della piattaforma supportate, consultare la tabella di aggiornamento dell'IP MetroCluster in "Scelta di un metodo di refresh del sistema".
Si applicano i limiti inferiori delle piattaforme di origine e di destinazione. Se si passa a una piattaforma superiore, i limiti della nuova piattaforma si applicano solo dopo il completamento dell'aggiornamento tecnico di tutti i gruppi di DR.
Se si esegue un aggiornamento tecnico su una piattaforma con limiti inferiori rispetto alla piattaforma di origine, è necessario regolare e ridurre i limiti in modo che siano pari o inferiori ai limiti della piattaforma di destinazione prima di eseguire questa procedura.

Attivare la registrazione della console

NetApp consiglia vivamente di attivare la registrazione della console sui dispositivi in uso e di eseguire le seguenti operazioni quando si esegue questa procedura:

Lasciare attivato AutoSupport durante la manutenzione.
Attivare un messaggio AutoSupport di manutenzione prima e dopo la manutenzione per disattivare la creazione del caso per tutta la durata dell'attività di manutenzione.

Consultare l'articolo della Knowledge base "Come eliminare la creazione automatica del caso durante le finestre di manutenzione pianificata".
Abilita la registrazione della sessione per qualsiasi sessione CLI. Per istruzioni su come attivare la registrazione della sessione, consultare la sezione "registrazione dell'output della sessione" nell'articolo della Knowledge base "Come configurare Putty per una connettività ottimale ai sistemi ONTAP".

Eseguire la procedura di aggiornamento

Per aggiornare la configurazione dell'IP di MetroCluster, procedere come segue.

Fasi

Verificare di disporre di un dominio di broadcast predefinito creato sui vecchi nodi.

Quando si aggiungono nuovi nodi a un cluster esistente senza un dominio di broadcast predefinito, le LIF di gestione nodi vengono create per i nuovi nodi utilizzando gli UUID (Universal Unique Identifier) e non i nomi previsti. Per ulteriori informazioni, consultare l'articolo della Knowledge base "LIF di gestione nodi su nodi appena aggiunti generati con nomi UUID".
Raccogliere informazioni dai vecchi nodi.

A questo punto, la configurazione a quattro nodi viene visualizzata come mostrato nell'immagine seguente:

La configurazione a otto nodi viene visualizzata come mostrato nell'immagine seguente:
Per impedire la generazione automatica del caso di supporto, inviare un messaggio AutoSupport per indicare che l'aggiornamento è in corso.
1. Eseguire il seguente comando:
  system node autosupport invoke -node * -type all -message "MAINT=10h Upgrading old-model to new-model"
  
  L'esempio seguente specifica una finestra di manutenzione di 10 ore. Calcolare del tempo aggiuntivo a seconda del piano.
  
  Se la manutenzione viene completata prima che sia trascorso il tempo, è possibile richiamare un messaggio AutoSupport che indica la fine del periodo di manutenzione:
system node autosupport invoke -node * -type all -message MAINT=end
1. Ripetere il comando sul cluster partner.
Se la crittografia end-to-end è attivata, seguire i passaggi da a. "Disattiva la crittografia end-to-end".

Rimuovere la configurazione MetroCluster esistente da Tiebreaker, Mediator o altro software in grado di avviare lo switchover.

Se si utilizza…

Utilizzare questa procedura…

Spareggio

Utilizzare l'interfaccia CLI di tiebreaker monitor remove Comando per rimuovere la configurazione MetroCluster.

Nell'esempio seguente, “cluster_A” viene rimosso dal software:
```
NetApp MetroCluster Tiebreaker :> monitor remove -monitor-name cluster_A
Successfully removed monitor from NetApp MetroCluster Tiebreaker
software.
```
Verificare che la configurazione MetroCluster sia stata rimossa correttamente utilizzando l'interfaccia CLI di tiebreaker monitor show -status comando.
```
NetApp MetroCluster Tiebreaker :> monitor show -status
```

Mediatore

Immettere il seguente comando dal prompt di ONTAP:

metrocluster configuration-settings mediator remove

Applicazioni di terze parti

Consultare la documentazione del prodotto.

Eseguire tutte le operazioni descritte in "Espansione di una configurazione IP MetroCluster" per aggiungere i nuovi nodi e lo storage alla configurazione.

Al termine della procedura di espansione, la configurazione temporanea viene visualizzata come mostrato nelle seguenti immagini:

Figura 1. Configurazione temporanea a otto nodi

Figura 2. Configurazione temporanea a dodici nodi

Verificare che sia possibile il Takeover e che i nodi siano connessi eseguendo il seguente comando su entrambi i cluster:

storage failover show

cluster_A::> storage failover show
                                    Takeover
Node           Partner              Possible    State Description
-------------- -------------------- ---------   ------------------
Node_FC_1      Node_FC_2              true      Connected to Node_FC_2
Node_FC_2      Node_FC_1              true      Connected to Node_FC_1
Node_IP_1      Node_IP_2              true      Connected to Node_IP_2
Node_IP_2      Node_IP_1              true      Connected to Node_IP_1

Spostare i volumi CRS.

Eseguire le operazioni descritte in "Spostamento di un volume di metadati nelle configurazioni MetroCluster".
Spostare i dati dai vecchi nodi ai nuovi nodi seguendo le seguenti procedure:
1. Eseguire tutte le operazioni descritte in "Creare un aggregato e spostare i volumi nei nuovi nodi".
  
  È possibile scegliere di eseguire il mirroring dell'aggregato quando o dopo la sua creazione.
2. Eseguire tutte le operazioni descritte in "Spostamento delle LIF dati non SAN e delle LIF di gestione cluster nei nuovi nodi".

Modificare l'indirizzo IP per il peer del cluster dei nodi in transizione per ciascun cluster:

Identificare il peer cluster_A utilizzando cluster peer show comando:

cluster_A::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
cluster_B         1-80-000011           Unavailable    absent

Modificare l'indirizzo IP del peer cluster_A:

cluster peer modify -cluster cluster_A -peer-addrs node_A_3_IP -address-family ipv4

Identificare il peer cluster_B utilizzando cluster peer show comando:

cluster_B::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
cluster_A         1-80-000011           Unavailable    absent

Modificare l'indirizzo IP del peer cluster_B:

cluster peer modify -cluster cluster_B -peer-addrs node_B_3_IP -address-family ipv4

Verificare che l'indirizzo IP del peer del cluster sia aggiornato per ciascun cluster:

Verificare che l'indirizzo IP sia aggiornato per ciascun cluster utilizzando cluster peer show -instance comando.

Il Remote Intercluster Addresses Nei seguenti esempi viene visualizzato l'indirizzo IP aggiornato.

Esempio per cluster_A:

cluster_A::> cluster peer show -instance

Peer Cluster Name: cluster_B
           Remote Intercluster Addresses: 172.21.178.204, 172.21.178.212
      Availability of the Remote Cluster: Available
                     Remote Cluster Name: cluster_B
                     Active IP Addresses: 172.21.178.212, 172.21.178.204
                   Cluster Serial Number: 1-80-000011
                    Remote Cluster Nodes: node_B_3-IP,
                                          node_B_4-IP
                   Remote Cluster Health: true
                 Unreachable Local Nodes: -
          Address Family of Relationship: ipv4
    Authentication Status Administrative: use-authentication
       Authentication Status Operational: ok
                        Last Update Time: 4/20/2023 18:23:53
            IPspace for the Relationship: Default
Proposed Setting for Encryption of Inter-Cluster Communication: -
Encryption Protocol For Inter-Cluster Communication: tls-psk
  Algorithm By Which the PSK Was Derived: jpake

cluster_A::>

+ Esempio per cluster_B.

cluster_B::> cluster peer show -instance

                       Peer Cluster Name: cluster_A
           Remote Intercluster Addresses: 172.21.178.188, 172.21.178.196 <<<<<<<< Should reflect the modified address
      Availability of the Remote Cluster: Available
                     Remote Cluster Name: cluster_A
                     Active IP Addresses: 172.21.178.196, 172.21.178.188
                   Cluster Serial Number: 1-80-000011
                    Remote Cluster Nodes: node_A_3-IP,
                                          node_A_4-IP
                   Remote Cluster Health: true
                 Unreachable Local Nodes: -
          Address Family of Relationship: ipv4
    Authentication Status Administrative: use-authentication
       Authentication Status Operational: ok
                        Last Update Time: 4/20/2023 18:23:53
            IPspace for the Relationship: Default
Proposed Setting for Encryption of Inter-Cluster Communication: -
Encryption Protocol For Inter-Cluster Communication: tls-psk
  Algorithm By Which the PSK Was Derived: jpake

cluster_B::>

Seguire la procedura descritta in "Rimozione di un gruppo di disaster recovery" Per rimuovere il vecchio gruppo DR.
Se è necessario aggiornare entrambi i gruppi DR in una configurazione a otto nodi, ripetere l'intera procedura per ciascun gruppo DR.

Dopo aver rimosso il vecchio gruppo DR, la configurazione viene visualizzata come mostrato nelle seguenti immagini:

Figura 3. Configurazione a quattro nodi

Figura 4. Configurazione a otto nodi
Confermare la modalità operativa della configurazione MetroCluster ed eseguire un controllo MetroCluster.
1. Verificare la configurazione MetroCluster e che la modalità operativa sia normale:
  
  metrocluster show
2. Verificare che siano visualizzati tutti i nodi previsti:
  
  metrocluster node show
3. Immettere il seguente comando:
  
  metrocluster check run
4. Visualizzare i risultati del controllo MetroCluster:
  
  metrocluster check show
Se la crittografia end-to-end è stata disattivata prima di aggiungere i nuovi nodi, è possibile riattivarla seguendo la procedura descritta in "Attiva la crittografia end-to-end".

Ripristinare il monitoraggio, se necessario, utilizzando la procedura per la configurazione.

Se si utilizza…

Utilizzare questa procedura