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 dei controller in una configurazione MetroCluster IP mediante switchover e switchback (ONTAP 9.8 e versioni successive)

Collaboratori

A partire da ONTAP 9.8, è possibile utilizzare l'operazione di switchover MetroCluster per fornire un servizio senza interruzioni ai client mentre i moduli controller del cluster partner vengono aggiornati. Altri componenti (ad esempio shelf di storage o switch) non possono essere aggiornati come parte di questa procedura.

Piattaforme supportate da questa procedura

  • Sulle piattaforme deve essere in esecuzione ONTAP 9.8 o versione successiva.

  • La piattaforma di destinazione (nuova) deve essere un modello diverso rispetto alla piattaforma originale.

  • I modelli di piattaforma con shelf interni non sono supportati.

  • È possibile aggiornare solo modelli di piattaforma specifici utilizzando questa procedura in una configurazione MetroCluster IP.

A proposito di questa attività

  • Questa procedura si applica ai moduli controller in una configurazione MetroCluster IP.

  • Tutti i controller della configurazione devono essere aggiornati durante lo stesso periodo di manutenzione.

    L'utilizzo della configurazione MetroCluster con diversi tipi di controller non è supportato al di fuori di questa attività di manutenzione.

  • Gli switch IP devono disporre di una versione firmware supportata.

  • Se la nuova piattaforma ha meno slot rispetto al sistema originale o se ha un numero inferiore o diversi tipi di porte, potrebbe essere necessario aggiungere un adattatore al nuovo sistema.

    Per ulteriori informazioni, consultare "NetApp Hardware Universe".

  • Gli indirizzi IP, le netmask e i gateway delle piattaforme originali verranno riutilizzati sulle nuove piattaforme.

  • In questa procedura vengono utilizzati i seguenti nomi di esempio:

    • Sito_A.

      • Prima dell'aggiornamento:

        • Node_A_1-old

        • Node_A_2-old

      • Dopo l'aggiornamento:

        • Node_A_1-new

        • Node_A_2-new

    • Sito_B

      • Prima dell'aggiornamento:

        • Node_B_1-old

        • Node_B_2-old

      • Dopo l'aggiornamento:

        • Node_B_1-new

        • Node_B_2-new

Workflow per l'aggiornamento dei controller in una configurazione MetroCluster IP

È possibile utilizzare il diagramma del flusso di lavoro per pianificare le attività di aggiornamento.

aggiornamento ip del workflow

Preparazione per l'aggiornamento

Prima di apportare modifiche alla configurazione MetroCluster esistente, è necessario controllare lo stato della configurazione, preparare le nuove piattaforme ed eseguire altre attività varie.

Aggiornamento dei file RCF dello switch MetroCluster prima dell'aggiornamento dei controller

A seconda dei vecchi modelli di piattaforma, se la configurazione dello switch non è sulla versione minima o se si desidera modificare gli ID VLAN utilizzati dalle connessioni MetroCluster back-end, è necessario aggiornare i file RCF dello switch prima di iniziare la procedura di aggiornamento della piattaforma.

A proposito di questa attività

È necessario aggiornare il file RCF nei seguenti scenari:

  • Per alcuni modelli di piattaforma, gli switch devono utilizzare un ID VLAN supportato per le connessioni IP MetroCluster back-end. Se i modelli di piattaforma vecchi o nuovi sono riportati nella tabella seguente, e non utilizzando un ID VLAN supportato, è necessario aggiornare i file RCF dello switch.

    Nota Le connessioni del cluster locale possono utilizzare qualsiasi VLAN, non devono necessariamente trovarsi nell'intervallo specificato.

    Modello di piattaforma (vecchio o nuovo)

    ID VLAN supportati

    • AFF A400

    • 10

    • 20

    • Qualsiasi valore compreso tra 101 e 4096 inclusi.

  • La configurazione dello switch non è stata configurata con la versione RCF minima supportata:

    Modello di switch

    Versione del file RCF richiesta

    Cisco 3132Q-V.

    1.7 o versione successiva

    Cisco 3232C

    1.7 o versione successiva

    Broadcom BES-53248

    1.3 o versione successiva

  • Si desidera modificare la configurazione della VLAN.

    L'intervallo di ID VLAN è compreso tra 101 e 4096.

Gli switch del sito_A verranno aggiornati quando i controller del sito_A verranno aggiornati.

Fasi
  1. Preparare gli switch IP per l'applicazione dei nuovi file RCF.

    Seguire i passaggi descritti nella sezione relativa al fornitore dello switch di "Installazione e configurazione di MetroCluster IP".

  2. Scaricare e installare i file RCF.

    Seguire la procedura descritta in "Installazione e configurazione di MetroCluster IP".

Mappatura delle porte dai vecchi nodi ai nuovi nodi

È necessario verificare che le porte fisiche sul nodo_A_1-old si mappino correttamente alle porte fisiche sul nodo_A_1-new, che consentirà al nodo_A_1-new di comunicare con altri nodi nel cluster e con la rete dopo l'aggiornamento.

A proposito di questa attività

Quando il nuovo nodo viene avviato per la prima volta durante il processo di aggiornamento, riproduce la configurazione più recente del vecchio nodo che sta sostituendo. Quando si avvia Node_A_1-new, ONTAP tenta di ospitare le LIF sulle stesse porte utilizzate su Node_A_1-old. Pertanto, come parte dell'aggiornamento, è necessario regolare la configurazione della porta e della LIF in modo che sia compatibile con quella del vecchio nodo. Durante la procedura di aggiornamento, verranno eseguiti i passaggi sul vecchio e sul nuovo nodo per garantire la corretta configurazione LIF di cluster, gestione e dati.

La seguente tabella mostra esempi di modifiche alla configurazione relative ai requisiti di porta dei nuovi nodi.

Porte fisiche di interconnessione cluster

Vecchio controller

Nuovo controller

Azione richiesta

e0a, e0b

e3a, e3b

Nessuna porta corrispondente. Dopo l'aggiornamento, è necessario ricreare le porte del cluster.

e0c, e0d

e0a,e0b,e0c,e0d

e0c e e0d corrispondono alle porte. Non è necessario modificare la configurazione, ma dopo l'aggiornamento è possibile distribuire le LIF del cluster tra le porte del cluster disponibili.

Fasi
  1. Determinare quali porte fisiche sono disponibili sui nuovi controller e quali LIF possono essere ospitate sulle porte.

    L'utilizzo della porta del controller dipende dal modulo della piattaforma e dagli switch che verranno utilizzati nella configurazione IP di MetroCluster. È possibile ottenere l'utilizzo delle porte delle nuove piattaforme da "NetApp Hardware Universe".

  2. Pianificare l'utilizzo delle porte e compilare le seguenti tabelle come riferimento per ciascuno dei nuovi nodi.

    Durante l'esecuzione della procedura di aggiornamento, fare riferimento alla tabella.

    Node_A_1-old

    Node_A_1-new

    LIF

    Porte

    IPspaces

    Domini di broadcast

    Porte

    IPspaces

    Domini di broadcast

    Cluster 1

    Cluster 2

    Cluster 3

    Cluster 4

    Gestione dei nodi

    Gestione del cluster

    Dati 1

    Dati 2

    Dati 3

    Dati 4

    SAN

    Porta intercluster

Avvio in rete dei nuovi controller

Dopo aver installato i nuovi nodi, è necessario eseguire il netboot per assicurarsi che i nuovi nodi eseguano la stessa versione di ONTAP dei nodi originali. Il termine netboot indica che si sta eseguendo l'avvio da un'immagine ONTAP memorizzata su un server remoto. Durante la preparazione per il netboot, è necessario inserire una copia dell'immagine di boot di ONTAP 9 su un server Web a cui il sistema può accedere.

Fasi
  1. NetBoot i nuovi controller:

    1. Accedere a. "Sito di supporto NetApp" per scaricare i file utilizzati per eseguire il netboot del sistema.

    2. Scaricare il software ONTAP appropriato dalla sezione di download del software del sito di supporto NetApp e memorizzare il ontap-version_image.tgz file in una directory accessibile dal web.

    3. Passare alla directory accessibile dal Web e verificare che i file necessari siano disponibili.

      Se il modello di piattaforma è…​

      Quindi…​

      sistemi della serie 8000

      Estrarre il contenuto di ontap-version_image.tgz file nella directory di destinazione:

      tar -zxvf ontap-version_image.tgz

      Nota Se si sta estraendo il contenuto su Windows, utilizzare 7-zip o WinRAR per estrarre l'immagine di netboot. L'elenco delle directory deve contenere una cartella netboot con un file kernel:netboot/kernel

      L'elenco delle directory deve contenere una cartella netboot con un file kernel:

      netboot/kernel

      Tutti gli altri sistemi

      L'elenco delle directory deve contenere una cartella netboot con un file kernel:

      _ontap-version_image.tgz

      Non è necessario estrarre _ontap-version_image.tgz file.

    4. Al prompt DEL CARICATORE, configurare la connessione netboot per una LIF di gestione:

      Se l'indirizzo IP è…​

      Quindi…​

      DHCP

      Configurare la connessione automatica:

      ifconfig e0M -auto

      Statico

      Configurare la connessione manuale:

      ifconfig e0M -addr=ip_addr -mask=netmask -gw=gateway

    5. Eseguire il netboot.

      Se il modello di piattaforma è…​

      Quindi…​

      Sistemi della serie FAS/AFF8000

      netboot http://web_server_ip/path_to_web-accessible_directory/netboot/kernel

      Tutti gli altri sistemi

      netboot http://_web_server_ip/path_to_web-accessible_directory/ontap-version_image.tgz

    6. Dal menu di avvio, selezionare l'opzione (7) installare prima il nuovo software per scaricare e installare la nuova immagine software sul dispositivo di avvio.

      Ignorare il seguente messaggio:

    "This procedure is not supported for Non-Disruptive Upgrade on an HA pair". Si applica agli aggiornamenti software senza interruzioni e non agli aggiornamenti dei controller.

    1. Se viene richiesto di continuare la procedura, immettere `y`E quando viene richiesto il pacchetto, inserire l'URL del file immagine:

      http://web_server_ip/path_to_web-accessible_directory/ontap-version_image.tgz

    2. Immettere il nome utente e la password, se applicabile, oppure premere Invio per continuare.

    3. Assicurarsi di entrare n per ignorare il ripristino del backup quando viene visualizzato un prompt simile a quanto segue:

      Do you want to restore the backup configuration now? {y|n} **n**
    4. Riavviare immettendo y quando viene visualizzato un prompt simile a quanto segue:

      The node must be rebooted to start using the newly installed software. Do you want to reboot now? {y|n}

Cancellazione della configurazione su un modulo controller

Prima di utilizzare un nuovo modulo controller nella configurazione MetroCluster, è necessario cancellare la configurazione esistente.

Fasi
  1. Se necessario, arrestare il nodo per visualizzare il prompt DEL CARICATORE:

    halt

  2. Al prompt DEL CARICATORE, impostare le variabili ambientali sui valori predefiniti:

    set-defaults

  3. Salvare l'ambiente:

    saveenv

  4. Al prompt DEL CARICATORE, avviare il menu di avvio:

    boot_ontap menu

  5. Al prompt del menu di avvio, cancellare la configurazione:

    wipeconfig

    Rispondere yes al prompt di conferma.

    Il nodo si riavvia e viene visualizzato di nuovo il menu di avvio.

  6. Nel menu di avvio, selezionare l'opzione 5 per avviare il sistema in modalità di manutenzione.

    Rispondere yes al prompt di conferma.

Verifica dello stato di salute di MetroCluster prima dell'aggiornamento del sito

Prima di eseguire l'aggiornamento, è necessario verificare lo stato e la connettività della configurazione di MetroCluster.

Fasi
  1. Verificare il funzionamento della configurazione MetroCluster in ONTAP:

    1. Verificare che i nodi siano multipathing:
      node run -node node-name sysconfig -a

      Eseguire questo comando per ogni nodo della configurazione MetroCluster.

    2. Verificare che non vi siano dischi rotti nella configurazione:
      storage disk show -broken

      Eseguire questo comando su ciascun nodo della configurazione MetroCluster.

    3. Verificare la presenza di eventuali avvisi sullo stato di salute:

      system health alert show

      Eseguire questo comando su ciascun cluster.

    4. Verificare le licenze sui cluster:

      system license show

      Eseguire questo comando su ciascun cluster.

    5. Verificare i dispositivi collegati ai nodi:

      network device-discovery show

      Eseguire questo comando su ciascun cluster.

    6. Verificare che il fuso orario e l'ora siano impostati correttamente su entrambi i siti:

      cluster date show

    Eseguire questo comando su ciascun cluster. È possibile utilizzare cluster date comandi per configurare l'ora e il fuso orario.

  2. Confermare la modalità operativa della configurazione MetroCluster ed eseguire un controllo MetroCluster.

    1. Confermare la configurazione MetroCluster e che la modalità operativa è normal:
      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

  3. Controllare il cablaggio MetroCluster con lo strumento Config Advisor.

    1. Scaricare ed eseguire Config Advisor.

    2. Dopo aver eseguito Config Advisor, esaminare l'output dello strumento e seguire le raccomandazioni nell'output per risolvere eventuali problemi rilevati.

Raccolta di informazioni prima dell'aggiornamento

Prima di eseguire l'aggiornamento, è necessario raccogliere informazioni per ciascuno dei nodi e, se necessario, regolare i domini di broadcast di rete, rimuovere eventuali VLAN e gruppi di interfacce e raccogliere informazioni sulla crittografia.

Fasi
  1. Registrare il cablaggio fisico di ciascun nodo, etichettando i cavi secondo necessità per consentire il cablaggio corretto dei nuovi nodi.

  2. Raccogliere informazioni su interconnessione, porta e LIF per ciascun nodo.

    Per ciascun nodo, è necessario raccogliere l'output dei seguenti comandi:

    • metrocluster interconnect show

    • metrocluster configuration-settings connection show

    • network interface show -role cluster,node-mgmt

    • network port show -node node_name -type physical

    • network port vlan show -node node-name

    • network port ifgrp show -node node_name -instance

    • network port broadcast-domain show

    • network port reachability show -detail

    • network ipspace show

    • volume show

    • storage aggregate show

    • system node run -node node-name sysconfig -a

    • vserver fcp initiator show

    • storage disk show

    • metrocluster configuration-settings interface show

  3. Raccogliere gli UUID per il sito_B (il sito le cui piattaforme sono attualmente in fase di aggiornamento):

    metrocluster node show -fields node-cluster-uuid, node-uuid

    Questi valori devono essere configurati con precisione sui nuovi moduli controller Site_B per garantire un aggiornamento corretto. Copiare i valori in un file in modo da poterli copiare nei comandi appropriati in un secondo momento del processo di aggiornamento.

    L'esempio seguente mostra l'output del comando con gli UUID:

    cluster_B::> metrocluster node show -fields node-cluster-uuid, node-uuid
      (metrocluster node show)
    dr-group-id cluster     node   node-uuid                            node-cluster-uuid
    ----------- --------- -------- ------------------------------------ ------------------------------
    1           cluster_A node_A_1 f03cb63c-9a7e-11e7-b68b-00a098908039 ee7db9d5-9a82-11e7-b68b-00a098908039
    1           cluster_A node_A_2 aa9a7a7a-9a81-11e7-a4e9-00a098908c35 ee7db9d5-9a82-11e7-b68b-00a098908039
    1           cluster_B node_B_1 f37b240b-9ac1-11e7-9b42-00a098c9e55d 07958819-9ac6-11e7-9b42-00a098c9e55d
    1           cluster_B node_B_2 bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f 07958819-9ac6-11e7-9b42-00a098c9e55d
    4 entries were displayed.
    cluster_B::*

    Si consiglia di registrare gli UUID in una tabella simile alla seguente.

    Cluster o nodo

    UUID

    Cluster_B

    07958819-9ac6-11e7-9b42-00a098c9e55d

    Node_B_1

    f37b240b-9ac1-11e7-9b42-00a098c9e55d

    Node_B_2

    bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f

    Cluster_A.

    ee7db9d5-9a82-11e7-b68b-00a098908039

    Node_A_1

    f03cb63c-9a7e-11e7-b68b-00a098908039

    Node_A_2

    aa9a7a7a-9a81-11e7-a4e9-00a098908c35

  4. Se i nodi MetroCluster si trovano in una configurazione SAN, raccogliere le informazioni pertinenti.

    Si dovrebbe ottenere l'output dei seguenti comandi:

    • fcp adapter show -instance

    • fcp interface show -instance

    • iscsi interface show

    • ucadmin show

  5. Se il volume root è crittografato, raccogliere e salvare la passphrase utilizzata per il gestore delle chiavi:

    security key-manager backup show

  6. Se i nodi MetroCluster utilizzano la crittografia per volumi o aggregati, copiare le informazioni relative alle chiavi e alle passphrase.

    1. Se Onboard Key Manager è configurato:
      security key-manager onboard show-backup

      La passphrase sarà necessaria più avanti nella procedura di aggiornamento.

    2. Se la gestione delle chiavi aziendali (KMIP) è configurata, eseguire i seguenti comandi:

      security key-manager external show -instance security key-manager key query

  7. Raccogliere gli ID di sistema dei nodi esistenti:

    metrocluster node show -fields node-systemid,ha-partner-systemid,dr-partner-systemid,dr-auxiliary-systemid

    Il seguente output mostra i dischi riassegnati.

    ::> metrocluster node show -fields node-systemid,ha-partner-systemid,dr-partner-systemid,dr-auxiliary-systemid
    
    dr-group-id cluster     node     node-systemid ha-partner-systemid dr-partner-systemid dr-auxiliary-systemid
    ----------- ----------- -------- ------------- ------------------- ------------------- ---------------------
    1           cluster_A node_A_1   537403324     537403323           537403321           537403322
    1           cluster_A node_A_2   537403323     537403324           537403322           537403321
    1           cluster_B node_B_1   537403322     537403321           537403323           537403324
    1           cluster_B node_B_2   537403321     537403322           537403324           537403323
    4 entries were displayed.

Rimozione del monitoraggio di Mediator o Tiebreaker

Prima di aggiornare le piattaforme, è necessario rimuovere il monitoraggio se la configurazione MetroCluster viene monitorata con l'utility Tiebreaker o Mediator.

Fasi
  1. Raccogliere l'output per il seguente comando:

    storage iscsi-initiator show

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

    Se si utilizza…​

    Utilizzare questa procedura…​

    Spareggio

    "Rimozione delle configurazioni MetroCluster" Nella Guida all'installazione e alla configurazione di MetroCluster Tiebreaker

    Mediatore

    Immettere il seguente comando dal prompt di ONTAP:

    metrocluster configuration-settings mediator remove

    Applicazioni di terze parti

    Consultare la documentazione del prodotto.

Invio di un messaggio AutoSupport personalizzato prima della manutenzione

Prima di eseguire la manutenzione, devi inviare un messaggio AutoSupport per informare il supporto tecnico NetApp che la manutenzione è in corso. Informare il supporto tecnico che la manutenzione è in corso impedisce loro di aprire un caso partendo dal presupposto che si sia verificata un'interruzione.

A proposito di questa attività

Questa attività deve essere eseguita su ciascun sito MetroCluster.

Fasi
  1. Accedere al cluster.

  2. Richiamare un messaggio AutoSupport che indica l'inizio della manutenzione:

    system node autosupport invoke -node * -type all -message MAINT=maintenance-window-in-hours

    Il maintenance-window-in-hours parametro specifica la lunghezza della finestra di manutenzione, con un massimo di 72 ore. 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

  3. Ripetere questi passaggi sul sito del partner.

Passaggio alla configurazione MetroCluster

È necessario passare alla configurazione Site_A in modo che le piattaforme sul sito_B possano essere aggiornate.

A proposito di questa attività

Questa attività deve essere eseguita sul sito_A.

Al termine di questa attività, cluster_A è attivo e fornisce dati per entrambi i siti. Cluster_B è inattivo e pronto per iniziare il processo di aggiornamento.

aggiornamento mcc del cluster a nello switchover
Fasi
  1. Passare alla configurazione MetroCluster del sito_A in modo che i nodi del sito_B possano essere aggiornati:

    1. Eseguire il seguente comando sul cluster_A:

      metrocluster switchover -controller-replacement true

      Il completamento dell'operazione può richiedere alcuni minuti.

    2. Monitorare il funzionamento dello switchover:

      metrocluster operation show

    3. Al termine dell'operazione, verificare che i nodi siano in stato di switchover:

      metrocluster show

    4. Controllare lo stato dei nodi MetroCluster:

      metrocluster node show

    La riparazione automatica degli aggregati dopo lo switchover negoziato viene disattivata durante l'aggiornamento del controller.

Rimozione delle configurazioni dell'interfaccia e disinstallazione dei vecchi controller

È necessario spostare i file LIF dei dati su una porta comune, rimuovere le VLAN e i gruppi di interfacce sui vecchi controller, quindi disinstallare fisicamente i controller.

A proposito di questa attività
Fasi
  1. Avviare i vecchi nodi e accedere ai nodi:

    boot_ontap

  2. Assegnare la porta home di tutti i file LIF di dati sul vecchio controller a una porta comune identica sia sul vecchio che sul nuovo modulo controller.

    1. Visualizzare le LIF:

      network interface show

      Tutti i dati LIFS, inclusi SAN e NAS, verranno gestiti e non verranno gestiti dal sistema operativo poiché sono attivi nel sito di switchover (cluster_A).

    2. Esaminare l'output per trovare una porta di rete fisica comune che sia la stessa sui controller vecchi e nuovi che non sia utilizzata come porta del cluster.

      Ad esempio, e0d è una porta fisica sui vecchi controller ed è presente anche sui nuovi controller. e0d non viene utilizzato come porta del cluster o in altro modo sui nuovi controller.

      Per informazioni sull'utilizzo delle porte per i modelli di piattaforma, consultare "NetApp Hardware Universe"

    3. Modificare tutti i dati LIFS per utilizzare la porta comune come porta home:
      network interface modify -vserver svm-name -lif data-lif -home-port port-id

      Nell'esempio seguente, questo è "e0d".

      Ad esempio:

    network interface modify -vserver vs0 -lif datalif1 -home-port e0d
  3. Rimuovere tutte le porte VLAN utilizzando le porte del cluster come porte membro e ifgrps utilizzando le porte del cluster come porte membro.

    1. Eliminare le porte VLAN:
      network port vlan delete -node node-name -vlan-name portid-vlandid

      Ad esempio:

      network port vlan delete -node node1 -vlan-name e1c-80
    2. Rimuovere le porte fisiche dai gruppi di interfacce:

      network port ifgrp remove-port -node node-name -ifgrp interface-group-name -port portid

      Ad esempio:

    network port ifgrp remove-port -node node1 -ifgrp a1a -port e0d
    1. Rimuovere le porte della VLAN e del gruppo di interfacce dal dominio di broadcast:

      network port broadcast-domain remove-ports -ipspace ipspace -broadcast-domain broadcast-domain-name -ports nodename:portname,nodename:portname,..

    2. Modificare le porte del gruppo di interfacce per utilizzare altre porte fisiche come membro in base alle necessità.:

      ifgrp add-port -node node-name -ifgrp interface-group-name -port port-id

  4. Arrestare i nodi al prompt DEL CARICATORE:

    halt -inhibit-takeover true

  5. Connettersi alla console seriale dei vecchi controller (Node_B_1-old e Node_B_2-old) nel sito_B e verificare che venga visualizzato il prompt DEL CARICATORE.

  6. Raccogliere i valori di bootarg:

    printenv

  7. Scollegare le connessioni di storage e di rete su Node_B_1-old e Node_B_2-old ed etichettare i cavi in modo che possano essere ricollegati ai nuovi nodi.

  8. Scollegare i cavi di alimentazione da Node_B_1-old e Node_B_2-old.

  9. Rimuovere i controller Node_B_1-old e Node_B_2-old dal rack.

Aggiornamento degli RCF dello switch per adattarsi alle nuove piattaforme

È necessario aggiornare gli switch a una configurazione che supporti i nuovi modelli di piattaforma.

A proposito di questa attività

Questa attività viene eseguita nel sito contenente i controller attualmente in fase di aggiornamento. Negli esempi illustrati in questa procedura, si esegue prima l'aggiornamento di Site_B.

Gli switch del sito_A verranno aggiornati quando i controller del sito_A verranno aggiornati.

Fasi
  1. Preparare gli switch IP per l'applicazione dei nuovi file RCF.

    Seguire i passaggi della procedura per il fornitore dello switch:

  2. Scaricare e installare i file RCF.

    Seguire i passaggi descritti nella sezione relativa al fornitore dello switch di "Installazione e configurazione di MetroCluster IP".

Configurazione dei nuovi controller

È necessario eseguire il rack e installare i controller, eseguire la configurazione richiesta in modalità manutenzione, quindi avviare i controller e verificare la configurazione LIF sui controller.

Configurazione dei nuovi controller

I nuovi controller devono essere montati in rack e cablati.

Fasi
  1. Pianificare il posizionamento dei nuovi moduli controller e degli shelf di storage in base alle necessità.

    Lo spazio rack dipende dal modello di piattaforma dei moduli controller, dai tipi di switch e dal numero di shelf di storage nella configurazione.

  2. Mettere a terra l'utente.

  3. Installare i moduli controller nel rack o nell'armadietto.

  4. Collegare i controller agli switch IP come descritto in "Installazione e configurazione di MetroCluster IP".

  5. Accendere i nuovi nodi e avviarli in modalità manutenzione.

Ripristino della configurazione HBA

A seconda della presenza e della configurazione delle schede HBA nel modulo controller, è necessario configurarle correttamente per l'utilizzo da parte del sito.

Fasi
  1. In modalità Maintenance (manutenzione), configurare le impostazioni per gli HBA presenti nel sistema:

    1. Verificare le impostazioni correnti delle porte:

      ucadmin show

    2. Aggiornare le impostazioni della porta secondo necessità.

    Se si dispone di questo tipo di HBA e della modalità desiderata…​

    Utilizzare questo comando…​

    FC CNA

    ucadmin modify -m fc -t initiator adapter-name

    Ethernet CNA

    ucadmin modify -mode cna adapter-name

    Destinazione FC

    fcadmin config -t target adapter-name

    Iniziatore FC

    fcadmin config -t initiator adapter-name

  2. Uscire dalla modalità di manutenzione:

    halt

    Dopo aver eseguito il comando, attendere che il nodo si arresti al prompt DEL CARICATORE.

  3. Riavviare il nodo in modalità Maintenance per rendere effettive le modifiche di configurazione:

    boot_ontap maint

  4. Verificare le modifiche apportate:

    Se si dispone di questo tipo di HBA…​

    Utilizzare questo comando…​

    CNA

    ucadmin show

    FC

    fcadmin show

Impostazione dello stato ha sui nuovi controller e chassis

È necessario verificare lo stato ha dei controller e dello chassis e, se necessario, aggiornarlo in modo che corrisponda alla configurazione del sistema.

Fasi
  1. In modalità Maintenance (manutenzione), visualizzare lo stato ha del modulo controller e dello chassis:

    ha-config show

    Lo stato ha per tutti i componenti deve essere “mccip”.

  2. Se lo stato di sistema visualizzato del controller o dello chassis non è corretto, impostare lo stato ha:

    ha-config modify controller mccip

    ha-config modify chassis mccip

Impostazione delle variabili di boot MetroCluster IP

Alcuni valori di boot MetroCluster IP devono essere configurati sui nuovi moduli controller. I valori devono corrispondere a quelli configurati sui vecchi moduli controller.

A proposito di questa attività

In questa attività, verranno utilizzati gli UUID e gli ID di sistema identificati in precedenza nella procedura di aggiornamento in "Raccolta di informazioni prima dell'aggiornamento".

Fasi
  1. Se i nodi da aggiornare sono i modelli AFF A400, FAS8300 o FAS8700, impostare i seguenti bootargs al prompt DEL CARICATORE:

    setenv bootarg.mcc.port_a_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address,vlan-id

    setenv bootarg.mcc.port_b_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address,vlan-id

    Nota Se le interfacce utilizzano le VLAN predefinite, l'id vlan non è necessario.

    I seguenti comandi impostano i valori per Node_B_1-New utilizzando VLAN 120 per la prima rete e VLAN 130 per la seconda rete:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12,120
    setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12,130

    I seguenti comandi impostano i valori per Node_B_2-New utilizzando VLAN 120 per la prima rete e VLAN 130 per la seconda rete:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13,120
    setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13,130

    L'esempio seguente mostra i comandi per node_B_1-new quando viene utilizzata la VLAN predefinita:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12
    setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12

    L'esempio seguente mostra i comandi per node_B_2-new quando viene utilizzata la VLAN predefinita:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13
    setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13
  2. Se i nodi da aggiornare non sono sistemi elencati nella fase precedente, al prompt DEL CARICATORE per ciascuno dei nodi sopravvissuti, impostare i seguenti bootargs con local_IP/mask:

    setenv bootarg.mcc.port_a_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address

    setenv bootarg.mcc.port_b_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address

    I seguenti comandi impostano i valori per node_B_1-new:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12
    setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12

    I seguenti comandi impostano i valori per node_B_2-new:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13
    setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13
  3. Al prompt DEL CARICATORE dei nuovi nodi, impostare gli UUID:

    setenv bootarg.mgwd.partner_cluster_uuid partner-cluster-UUID

    setenv bootarg.mgwd.cluster_uuid local-cluster-UUID

    setenv bootarg.mcc.pri_partner_uuid DR-partner-node-UUID

    setenv bootarg.mcc.aux_partner_uuid DR-aux-partner-node-UUID

    setenv bootarg.mcc_iscsi.node_uuid local-node-UUID

    1. Impostare gli UUID su Node_B_1-New.

      L'esempio seguente mostra i comandi per impostare gli UUID su Node_B_1-New:

      setenv bootarg.mgwd.cluster_uuid ee7db9d5-9a82-11e7-b68b-00a098908039
      setenv bootarg.mgwd.partner_cluster_uuid 07958819-9ac6-11e7-9b42-00a098c9e55d
      setenv bootarg.mcc.pri_partner_uuid f37b240b-9ac1-11e7-9b42-00a098c9e55d
      setenv bootarg.mcc.aux_partner_uuid bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f
      setenv bootarg.mcc_iscsi.node_uuid f03cb63c-9a7e-11e7-b68b-00a098908039
    2. Impostare gli UUID su Node_B_2-New:

      L'esempio seguente mostra i comandi per impostare gli UUID su Node_B_2-New:

    setenv bootarg.mgwd.cluster_uuid ee7db9d5-9a82-11e7-b68b-00a098908039
    setenv bootarg.mgwd.partner_cluster_uuid 07958819-9ac6-11e7-9b42-00a098c9e55d
    setenv bootarg.mcc.pri_partner_uuid bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f
    setenv bootarg.mcc.aux_partner_uuid f37b240b-9ac1-11e7-9b42-00a098c9e55d
    setenv bootarg.mcc_iscsi.node_uuid aa9a7a7a-9a81-11e7-a4e9-00a098908c35
  4. Se i sistemi originali sono stati configurati per ADP, al prompt DEL CARICATORE di ciascun nodo sostitutivo, abilitare ADP:

    setenv bootarg.mcc.adp_enabled true

  5. Impostare le seguenti variabili:

    setenv bootarg.mcc.local_config_id original-sys-id

    setenv bootarg.mcc.dr_partner dr-partner-sys-id

    Nota Il setenv bootarg.mcc.local_config_id Variable deve essere impostato sul sys-id del modulo controller original, node_B_1-old.
    1. Impostare le variabili su Node_B_1-New.

      L'esempio seguente mostra i comandi per impostare i valori su Node_B_1-New:

      setenv bootarg.mcc.local_config_id 537403322
      setenv bootarg.mcc.dr_partner 537403324
    2. Impostare le variabili su Node_B_2-new.

      L'esempio seguente mostra i comandi per impostare i valori su Node_B_2-New:

    setenv bootarg.mcc.local_config_id 537403321
    setenv bootarg.mcc.dr_partner 537403323
  6. Se si utilizza la crittografia con il gestore delle chiavi esterno, impostare i bootargs richiesti:

    setenv bootarg.kmip.init.ipaddr

    setenv bootarg.kmip.kmip.init.netmask

    setenv bootarg.kmip.kmip.init.gateway

    setenv bootarg.kmip.kmip.init.interface

Riassegnazione dei dischi aggregati root

Riassegnare i dischi aggregati root al nuovo modulo controller, utilizzando i sistemi raccolti in precedenza.

A proposito di questa attività

Questi passaggi vengono eseguiti in modalità manutenzione.

Nota I dischi aggregati root sono gli unici dischi che devono essere riassegnati durante il processo di upgrade dei controller. La proprietà del disco degli aggregati di dati viene gestita come parte dell'operazione di switchover/switchback.
Fasi
  1. Avviare il sistema in modalità di manutenzione:

    boot_ontap maint

  2. Visualizzare i dischi su Node_B_1-New dal prompt della modalità di manutenzione:

    disk show -a

    L'output del comando mostra l'ID di sistema del nuovo modulo controller (1574774970). Tuttavia, i dischi aggregati root sono ancora di proprietà del vecchio ID di sistema (537403322). Questo esempio non mostra i dischi di proprietà di altri nodi nella configurazione MetroCluster.

    *> disk show -a
    Local System ID: 1574774970
    DISK                  OWNER                 POOL   SERIAL NUMBER   HOME                  DR HOME
    ------------          ---------             -----  -------------   -------------         -------------
    prod3-rk18:9.126L44   node_B_1-old(537403322)  Pool1  PZHYN0MD     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod4-rk18:9.126L49   node_B_1-old(537403322)  Pool1  PPG3J5HA     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod4-rk18:8.126L21   node_B_1-old(537403322)  Pool1  PZHTDSZD     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod2-rk18:8.126L2    node_B_1-old(537403322)  Pool0  S0M1J2CF     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod2-rk18:8.126L3    node_B_1-old(537403322)  Pool0  S0M0CQM5     node_B_1-old(537403322)  node_B_1-old(537403322)
    prod1-rk18:9.126L27   node_B_1-old(537403322)  Pool0  S0M1PSDW     node_B_1-old(537403322)  node_B_1-old(537403322)
    .
    .
    .
  3. Riassegnare i dischi aggregati root sugli shelf di dischi ai nuovi controller.

    Se si utilizza ADP…​

    Quindi utilizzare questo comando…​

    disk reassign -s old-sysid -d new-sysid -r dr-partner-sysid

    No

    disk reassign -s old-sysid -d new-sysid

  4. Riassegnare i dischi aggregati root sugli shelf di dischi ai nuovi controller:

    disk reassign -s old-sysid -d new-sysid

    L'esempio seguente mostra la riassegnazione dei dischi in una configurazione non ADP:

    *> disk reassign -s 537403322 -d 1574774970
    Partner node must not be in Takeover mode during disk reassignment from maintenance mode.
    Serious problems could result!!
    Do not proceed with reassignment if the partner is in takeover mode. Abort reassignment (y/n)? n
    
    After the node becomes operational, you must perform a takeover and giveback of the HA partner node to ensure disk reassignment is successful.
    Do you want to continue (y/n)? y
    Disk ownership will be updated on all disks previously belonging to Filer with sysid 537403322.
    Do you want to continue (y/n)? y
  5. Verificare che i dischi dell'aggregato root siano riassegnati correttamente in modalità vecchia rimozione:

    disk show

    storage aggr status

    *> disk show
    Local System ID: 537097247
    
      DISK                    OWNER                    POOL   SERIAL NUMBER   HOME                     DR HOME
    ------------              -------------            -----  -------------   -------------            -------------
    prod03-rk18:8.126L18 node_B_1-new(537097247)  Pool1  PZHYN0MD        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod04-rk18:9.126L49 node_B_1-new(537097247)  Pool1  PPG3J5HA        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod04-rk18:8.126L21 node_B_1-new(537097247)  Pool1  PZHTDSZD        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod02-rk18:8.126L2  node_B_1-new(537097247)  Pool0  S0M1J2CF        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod02-rk18:9.126L29 node_B_1-new(537097247)  Pool0  S0M0CQM5        node_B_1-new(537097247)   node_B_1-new(537097247)
    prod01-rk18:8.126L1  node_B_1-new(537097247)  Pool0  S0M1PSDW        node_B_1-new(537097247)   node_B_1-new(537097247)
    ::>
    ::> aggr status
               Aggr          State           Status                Options
    aggr0_node_B_1           online          raid_dp, aggr         root, nosnap=on,
                                             mirrored              mirror_resync_priority=high(fixed)
                                             fast zeroed
                                             64-bit

Avviare i nuovi controller

È necessario avviare i nuovi controller, assicurandosi che le variabili di boot siano corrette e, se necessario, eseguire le operazioni di ripristino della crittografia.

Fasi
  1. Arrestare i nuovi nodi:

    halt

  2. Se è configurato un gestore di chiavi esterno, impostare i relativi bootargs:

    setenv bootarg.kmip.init.ipaddr ip-address

    setenv bootarg.kmip.init.netmask netmask

    setenv bootarg.kmip.init.gateway gateway-address

    setenv bootarg.kmip.init.interface interface-id

  3. Verificare se il sistema partner è quello corrente:

    printenv partner-sysid

    Se il partner-sysid non è corretto, impostarlo:

    setenv partner-sysid partner-sysID

  4. Visualizzare il menu di avvio di ONTAP:

    boot_ontap menu

  5. Se viene utilizzata la crittografia root, selezionare l'opzione del menu di avvio per la configurazione della gestione delle chiavi.

    Se si utilizza…​

    Selezionare questa opzione del menu di avvio…​

    Gestione delle chiavi integrata

    Opzione 10

    Seguire le istruzioni per fornire gli input necessari per ripristinare la configurazione di gestione delle chiavi.

    Gestione esterna delle chiavi

    Opzione 11

    Seguire le istruzioni per fornire gli input necessari per ripristinare la configurazione di gestione delle chiavi.

  6. Dal menu di avvio, selezionare “(6) Update flash from backup config”.

    Nota L'opzione 6 riavvia il nodo due volte prima del completamento.

    Rispondere “y” alle richieste di modifica dell'id di sistema. Attendere i secondi messaggi di riavvio:

    Successfully restored env file from boot media...
    
    Rebooting to load the restored env file...
  7. Sul CARICATORE, controllare due volte i valori di bootarg e aggiornarli secondo necessità.

    Attenersi alla procedura descritta in "Impostazione delle variabili di boot MetroCluster IP".

  8. Verificare che il sistema partner sia corretto:

    printenv partner-sysid

    Se il partner-sysid non è corretto, impostarlo:

    setenv partner-sysid partner-sysID

  9. Se viene utilizzata la crittografia root, selezionare nuovamente l'opzione del menu di avvio per la configurazione della gestione delle chiavi.

    Se si utilizza…​

    Selezionare questa opzione del menu di avvio…​

    Gestione delle chiavi integrata

    Opzione 10

    Seguire le istruzioni per fornire gli input necessari per ripristinare la configurazione di gestione delle chiavi.

    Gestione esterna delle chiavi

    Opzione “11”

    Seguire le istruzioni per fornire gli input necessari per ripristinare la configurazione di gestione delle chiavi.

    A seconda dell'impostazione del gestore delle chiavi, eseguire la procedura di ripristino selezionando l'opzione “10” o l'opzione “11”, quindi l'opzione 6 al primo prompt del menu di avvio. Per avviare completamente i nodi, potrebbe essere necessario ripetere la procedura di ripristino, continua con l'opzione “1” (boot normale).

  10. Attendere l'avvio dei nodi sostituiti.

    Se uno dei nodi è in modalità Takeover, eseguire un giveback utilizzando storage failover giveback comando.

  11. Se viene utilizzata la crittografia, ripristinare le chiavi utilizzando il comando corretto per la configurazione di gestione delle chiavi.

    Se si utilizza…​

    Utilizzare questo comando…​

    Gestione delle chiavi integrata

    security key-manager onboard sync

    Gestione esterna delle chiavi

    `security key-manager external restore -vserver SVM -node node -key-server _host_name

  12. Verificare che tutte le porte si trovino in un dominio di trasmissione:

    1. Visualizzare i domini di trasmissione:

      network port broadcast-domain show

    2. Aggiungere eventuali porte a un dominio di broadcast in base alle esigenze.

    3. Ricreare VLAN e gruppi di interfacce in base alle esigenze.

      L'appartenenza alla VLAN e al gruppo di interfacce potrebbe essere diversa da quella del nodo precedente.

Verifica e ripristino della configurazione LIF

Verificare che i file LIF siano ospitati su nodi e porte appropriati, come mappati all'inizio della procedura di aggiornamento.

A proposito di questo tsak
Fasi
  1. Verificare che i file LIF siano ospitati sul nodo e sulle porte appropriati prima di passare al switchback.

    1. Passare al livello di privilegio avanzato:

      set -privilege advanced

    2. Eseguire l'override della configurazione della porta per garantire il corretto posizionamento di LIF:

      vserver config override -command "network interface modify -vserver vserver_name -home-port active_port_after_upgrade -lif lif_name -home-node new_node_name"

    Quando si immette il comando di modifica dell'interfaccia di rete in vserver config override non è possibile utilizzare la funzione di completamento automatico della scheda. È possibile creare la rete interface modify utilizzando il completamento automatico e quindi racchiuderlo in vserver config override comando.

    1. Tornare al livello di privilegio admin:

      set -privilege admin

  2. Ripristinare le interfacce nel nodo principale:

    network interface revert * -vserver vserver-name

    Eseguire questo passaggio su tutte le SVM secondo necessità.

Tornare indietro alla configurazione MetroCluster

In questa attività, viene eseguita l'operazione di switchback e la configurazione MetroCluster torna al funzionamento normale. I nodi sul sito_A sono ancora in attesa di aggiornamento.

switchback del cluster di aggiornamento mcc a.
Fasi
  1. Eseguire il metrocluster node show Su Site_B e controllare l'output.

    1. Verificare che i nuovi nodi siano rappresentati correttamente.

    2. Verificare che i nuovi nodi siano nello stato "in attesa di switchback".

  2. Eseguire la riparazione e lo switchback eseguendo i comandi richiesti da qualsiasi nodo del cluster attivo (il cluster che non è in fase di aggiornamento).

    1. Riparare gli aggregati di dati:
      metrocluster heal aggregates

    2. Riparare gli aggregati root:

      metrocluster heal root

    3. Switchback del cluster:

      metrocluster switchback

  3. Controllare l'avanzamento dell'operazione di switchback:

    metrocluster show

    L'operazione di switchback è ancora in corso quando viene visualizzato l'output waiting-for-switchback:

    cluster_B::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_B         Configuration state configured
                              Mode                switchover
                              AUSO Failure Domain -
    Remote: cluster_A         Configuration state configured
                              Mode                waiting-for-switchback
                              AUSO Failure Domain -

    L'operazione di switchback è completa quando l'output visualizza normale:

    cluster_B::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_B         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain -
    Remote: cluster_A         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain -

    Se il completamento di uno switchback richiede molto tempo, è possibile verificare lo stato delle linee di base in corso utilizzando metrocluster config-replication resync-status show comando. Questo comando si trova al livello di privilegio avanzato.

Verifica dello stato della configurazione di MetroCluster

Dopo aver aggiornato i moduli controller, è necessario verificare lo stato della configurazione MetroCluster.

A proposito di questa attività

Questa attività può essere eseguita su qualsiasi nodo della configurazione MetroCluster.

Fasi
  1. Verificare il funzionamento della configurazione MetroCluster:

    1. Confermare la configurazione MetroCluster e verificare che la modalità operativa sia normale:
      metrocluster show

    2. Eseguire un controllo MetroCluster:
      metrocluster check run

    3. Visualizzare i risultati del controllo MetroCluster:

      metrocluster check show

  2. Verificare lo stato e la connettività MetroCluster.

    1. Verificare le connessioni IP MetroCluster:

      storage iscsi-initiator show

    2. Verificare che i nodi funzionino:

      metrocluster node show

    3. Verificare che le interfacce IP di MetroCluster siano disponibili:

      metrocluster configuration-settings interface show

    4. Verificare che il failover locale sia attivato:

      storage failover show

Aggiornamento dei nodi sul cluster_A.

È necessario ripetere le attività di aggiornamento su cluster_A.

Fasi
  1. Ripetere i passaggi per aggiornare i nodi sul cluster_A, iniziando da "Preparazione per l'aggiornamento".

    Durante l'esecuzione delle attività, tutti i riferimenti di esempio ai cluster e ai nodi vengono invertiti. Ad esempio, quando l'esempio viene dato allo switchover da cluster_A, si passa da cluster_B.

Ripristino del monitoraggio di Tiebreaker o Mediator

Dopo aver completato l'aggiornamento della configurazione MetroCluster, è possibile riprendere il monitoraggio con l'utility Tiebreaker o Mediator.

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

    Se si utilizza…​ Utilizzare questa procedura

    Spareggio

    Mediatore

    Link:../install-ip/concept_mediator_requirements.html [Configurazione del servizio ONTAP Mediator da una configurazione IP MetroCluster].

    Applicazioni di terze parti

    Consultare la documentazione del prodotto.

Invio di un messaggio AutoSupport personalizzato dopo la manutenzione

Una volta completato l'aggiornamento, inviare un messaggio AutoSupport che indica la fine della manutenzione, in modo da poter riprendere la creazione automatica del caso.

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

    1. Eseguire il seguente comando:
      system node autosupport invoke -node * -type all -message MAINT=end

    2. Ripetere il comando sul cluster partner.