Skip to main content
ONTAP MetroCluster
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

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

Collaboratori

È 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.

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.

    Se si aggiornano entrambi i gruppi di DR, è necessario aggiornare un gruppo di DR alla volta.

  • I riferimenti ai "vecchi nodi" indicano i nodi che si intende sostituire.

  • Per le configurazioni a otto nodi, è necessario supportare la combinazione di piattaforme MetroCluster a otto nodi di origine e destinazione.

    Nota 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.

  • 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.

Fasi
  1. 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".

  2. Raccogliere informazioni dai vecchi nodi.

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

    mcc dr gruppo a

    La configurazione a otto nodi viene visualizzata come mostrato nell'immagine seguente:

    mcc dr raggruppa 8 nodi
  3. 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"

      Nell'esempio seguente viene specificata una finestra di manutenzione di 10 ore. A seconda del piano, potrebbe essere necessario dedicare più tempo.

      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.

  4. Se la crittografia end-to-end è attivata, seguire i passaggi da a. "Disattiva la crittografia end-to-end".

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

    Se si utilizza…​

    Utilizzare questa procedura…​

    Spareggio

    1. 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.
    2. 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.

  6. 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:

    mcc dr gruppo b
    Figura 1. Configurazione temporanea a otto nodi
    gruppo dr mcc c4
    Figura 2. Configurazione temporanea a dodici nodi
  7. 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
  8. Spostare i volumi CRS.

  9. 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".

      Nota È 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".

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

    1. 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
      1. Modificare l'indirizzo IP del peer cluster_A:

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

    2. 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
      1. Modificare l'indirizzo IP del peer cluster_B:

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

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

      1. 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::>
  11. Seguire la procedura descritta in "Rimozione di un gruppo di disaster recovery" Per rimuovere il vecchio gruppo DR.

  12. Se si desidera aggiornare entrambi i gruppi di DR in una configurazione a otto nodi, è necessario ripetere l'intera procedura per ciascun gruppo di DR.

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

    gruppo dr mcc d
    Figura 3. Configurazione a quattro nodi
    gruppo dr mcc c5
    Figura 4. Configurazione a otto nodi
  13. 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

  14. 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".

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

    Se si utilizza…​

    Utilizzare questa procedura

    Spareggio

    "Aggiunta di configurazioni MetroCluster" Nella sezione Installazione e configurazione di MetroCluster Tiebreaker.

    Mediatore

    Applicazioni di terze parti

    Consultare la documentazione del prodotto.

  16. Per riprendere la generazione automatica del caso di supporto, inviare un messaggio AutoSupport per indicare che la manutenzione è stata completata.

    1. Immettere il seguente comando:

      system node autosupport invoke -node * -type all -message MAINT=end

    2. Ripetere il comando sul cluster partner.