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.

Completamento del ripristino

Collaboratori

Eseguire le attività richieste per completare il ripristino da un errore di controller multiplo o di storage.

Ripristino degli archivi di oggetti per le configurazioni FabricPool

Se uno degli archivi di oggetti in un mirror FabricPool è stato co-localizzato con il sito di emergenza MetroCluster ed è stato distrutto, è necessario ristabilire l'archivio di oggetti e il mirror FabricPool.

A proposito di questa attività
  • Se gli archivi di oggetti sono remoti e un sito MetroCluster viene distrutto, non è necessario ricostruire l'archivio di oggetti e conservare le configurazioni dell'archivio di oggetti originale e il contenuto dei dati cold.

  • Per ulteriori informazioni sulle configurazioni FabricPool, consultare "Gestione di dischi e aggregati".

Fase
  1. Seguire la procedura "Sostituzione di un mirror FabricPool in una configurazione MetroCluster" in "Gestione di dischi e aggregati".

Verifica delle licenze sui nodi sostituiti

È necessario installare nuove licenze per i nodi sostitutivi se i nodi con problemi utilizzavano funzionalità ONTAP che richiedono una licenza standard (bloccata da nodo). Per le funzionalità con licenze standard, ogni nodo del cluster deve disporre di una propria chiave per la funzionalità.

A proposito di questa attività

Fino all'installazione delle chiavi di licenza, le funzionalità che richiedono licenze standard continuano a essere disponibili per il nodo sostitutivo. Tuttavia, se il nodo compromesso era l'unico nodo nel cluster con una licenza per la funzione, non sono consentite modifiche di configurazione alla funzione. Inoltre, l'utilizzo di funzionalità senza licenza sul nodo potrebbe non essere conforme al contratto di licenza, pertanto è necessario installare la chiave o le chiavi di licenza sostitutive sul nodo sostitutivo il prima possibile.

Le chiavi di licenza devono essere in formato a 28 caratteri.

Si dispone di un periodo di prova di 90 giorni per l'installazione delle chiavi di licenza. Dopo il periodo di tolleranza, tutte le vecchie licenze vengono invalidate. Dopo aver installato una chiave di licenza valida, si hanno a disposizione 24 ore per installare tutte le chiavi prima della fine del periodo di tolleranza.

Nota Se tutti i nodi di un sito sono stati sostituiti (un singolo nodo nel caso di una configurazione MetroCluster a due nodi), le chiavi di licenza devono essere installate sul nodo o sui nodi sostitutivi prima dello switchback.
Fasi
  1. Identificare le licenze sul nodo:

    license show

    Nell'esempio seguente vengono visualizzate le informazioni sulle licenze nel sistema:

    cluster_B::>  license show
             (system license show)
    
    Serial Number: 1-80-00050
    Owner: site1-01
    Package           Type       Description             Expiration
    -------          -------     -------------           -----------
    Base             license     Cluster Base License        -
    NFS              site        NFS License                 -
    CIFS             site        CIFS License                -
    iSCSI            site        iSCSI License               -
    FCP              site        FCP License                 -
    FlexClone        site        FlexClone License           -
    
    6 entries were displayed.
  2. Verificare che le licenze siano valide per il nodo dopo lo switchback:

    metrocluster check license show

    Nell'esempio seguente vengono visualizzate le licenze valide per il nodo:

    cluster_B::> metrocluster check license show
    
    Cluster           Check                             Result
    -------           -------                           -------------
    Cluster_B         negotiated-switchover-ready       not-applicable
    NFS               switchback-ready                  not-applicable
    CIFS              job-schedules                     ok
    iSCSI             licenses                          ok
    FCP               periodic-check-enabled            ok
  3. Se sono necessarie nuove chiavi di licenza, procurarsi le chiavi di licenza sostitutive sul sito di supporto NetApp nella sezione My Support (Assistenza) sotto Software licenss (licenze software).

    Nota Le nuove chiavi di licenza richieste vengono generate automaticamente e inviate all'indirizzo e-mail in archivio. Se non si riceve l'e-mail contenente le chiavi di licenza entro 30 giorni, consultare la sezione "Chi contattare in caso di problemi con le licenze?" dell'articolo della Knowledge base "Processo di sostituzione della scheda madre per aggiornare le licenze su un sistema AFF/FAS."
  4. Installare ogni chiave di licenza:

    system license add -license-code license-key, license-key…​+

  5. Rimuovere le vecchie licenze, se necessario:

    1. Verificare la presenza di licenze inutilizzate:

      license clean-up -unused -simulate

    2. Se l'elenco appare corretto, rimuovere le licenze inutilizzate:

      license clean-up -unused

Ripristino della gestione delle chiavi

Se i volumi di dati sono crittografati, è necessario ripristinare la gestione delle chiavi. Se il volume root è crittografato, è necessario ripristinare la gestione delle chiavi.

Fasi
  1. Se i volumi di dati sono crittografati, 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 key query -node node-name

  2. Se il volume root è crittografato, seguire la procedura descritta in "Ripristino della gestione delle chiavi se il volume root è crittografato".

Esecuzione di uno switchback

Dopo aver corretto la configurazione MetroCluster, è possibile eseguire l'operazione di switchback MetroCluster. L'operazione di switchback MetroCluster riporta la configurazione al suo normale stato operativo, con le macchine virtuali dello storage di origine di sincronizzazione (SVM) sul sito di emergenza attive e i dati provenienti dai pool di dischi locali.

Prima di iniziare
  • Il cluster di emergenza deve essere passato correttamente al cluster esistente.

  • La riparazione deve essere stata eseguita sui dati e sugli aggregati root.

  • I nodi del cluster sopravvissuti non devono trovarsi nello stato di failover ha (tutti i nodi devono essere attivi e in esecuzione per ogni coppia ha).

  • I moduli controller del sito di emergenza devono essere completamente avviati e non in modalità ha Takeover.

  • L'aggregato root deve essere mirrorato.

  • I collegamenti Inter-Switch (ISL) devono essere online.

  • Tutte le licenze richieste devono essere installate sul sistema.

Fasi
  1. Verificare che tutti i nodi siano nello stato abilitato:

    metrocluster node show

    Nell'esempio riportato di seguito vengono visualizzati i nodi che si trovano nello stato abilitato:

    cluster_B::>  metrocluster node show
    
    DR                        Configuration  DR
    Group Cluster Node        State          Mirroring Mode
    ----- ------- ----------- -------------- --------- --------------------
    1     cluster_A
                  node_A_1    configured     enabled   heal roots completed
                  node_A_2    configured     enabled   heal roots completed
          cluster_B
                  node_B_1    configured     enabled   waiting for switchback recovery
                  node_B_2    configured     enabled   waiting for switchback recovery
    4 entries were displayed.
  2. Verificare che la risincronizzazione sia completa su tutte le SVM:

    metrocluster vserver show

  3. Verificare che tutte le migrazioni LIF automatiche eseguite dalle operazioni di riparazione siano state completate correttamente:

    metrocluster check lif show

  4. Eseguire lo switchback eseguendo il metrocluster switchback comando da qualsiasi nodo del cluster esistente.

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

    metrocluster show

    L'operazione di switchback è ancora in corso quando l'output visualizza "Waiting-for-switchback" (in attesa di 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 il seguente comando a livello di privilegio avanzato:

    metrocluster config-replication resync-status show

  6. Ripristinare le configurazioni SnapMirror o SnapVault.

    In ONTAP 8.3, è necessario ristabilire manualmente una configurazione di SnapMirror persa dopo un'operazione di switchback MetroCluster. In ONTAP 9.0 e versioni successive, la relazione viene ristabilita automaticamente.

Verifica di uno switchback riuscito

Dopo aver eseguito lo switchback, si desidera confermare che tutti gli aggregati e le macchine virtuali di storage (SVM) siano ripristinati e in linea.

Fasi
  1. Verificare che gli aggregati di dati di switchover siano ripristinati:

    storage aggregate show

    Nell'esempio seguente, aggr_b2 sul nodo B2 è tornato:

    node_B_1::> storage aggregate show
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    ...
    aggr_b2    227.1GB   227.1GB    0% online       0 node_B_2   raid_dp,
                                                                       mirrored,
                                                                       normal
    
    node_A_1::> aggr show
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    ...
    aggr_b2          -         -     - unknown      - node_A_1

    Se il sito di disastro includeva aggregati senza mirror e gli aggregati senza mirror non sono più presenti, l'aggregato potrebbe essere visualizzato con uno stato “Unknown” nell'output del comando show dell'aggregato di storage. Contattare il supporto tecnico per rimuovere le voci non aggiornate per gli aggregati senza mirror, fare riferimento all'articolo della Knowledge base "Come rimuovere le voci aggregate obsolete senza mirror in un MetroCluster in seguito a un disastro in cui lo storage è stato perso."

  2. Verificare che tutte le SVM di destinazione della sincronizzazione sul cluster sopravvissuto siano inattive (mostrando uno stato Admin di “ssurfared”) e che le SVM di origine della sincronizzazione sul cluster di emergenza siano attive e in esecuzione:

    vserver show -subtype sync-source

    node_B_1::> vserver show -subtype sync-source
                                   Admin      Root                       Name    Name
    Vserver     Type    Subtype    State      Volume     Aggregate       Service Mapping
    ----------- ------- ---------- ---------- ---------- ----------      ------- -------
    ...
    vs1a        data    sync-source
                                   running    vs1a_vol   node_B_2        file    file
                                                                         aggr_b2
    
    node_A_1::> vserver show -subtype sync-destination
                                   Admin      Root                         Name    Name
    Vserver            Type    Subtype    State      Volume     Aggregate  Service Mapping
    -----------        ------- ---------- ---------- ---------- ---------- ------- -------
    ...
    cluster_A-vs1a-mc  data    sync-destination
                                          stopped    vs1a_vol   sosb_      file    file
                                                                           aggr_b2

    Gli aggregati Sync-destination nella configurazione MetroCluster hanno il suffisso "-mc" aggiunto automaticamente al loro nome per facilitarne l'identificazione.

  3. Verificare che le operazioni di switchback siano riuscite utilizzando metrocluster operation show comando.

    Se l'output del comando mostra…​

    Quindi…​

    Che lo stato operativo di switchback sia riuscito.

    Il processo di switchback è completo ed è possibile procedere con il funzionamento del sistema.

    Che l'operazione di switchback o l'operazione switchback-continuation-Agent abbia parzialmente esito positivo.

    Eseguire la correzione suggerita nell'output del comando MetroCluster Operation show.

Al termine

Ripetere le sezioni precedenti per eseguire il switchback nella direzione opposta. Se Site_A ha eseguito uno switchover di Site_B, chiedere a Site_B di eseguire uno switchover di Site_A.

Mirroring degli aggregati root dei nodi sostitutivi

Se i dischi sono stati sostituiti, è necessario eseguire il mirroring degli aggregati root dei nuovi nodi nel sito di emergenza.

Fasi
  1. Nel sito di disaster recovery, identificare gli aggregati che non sono mirrorati:

    storage aggregate show

    cluster_A::> storage aggregate show
    
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    node_A_1_aggr0
                1.49TB   74.12GB   95% online       1 node_A_1         raid4,
                                                                       normal
    node_A_2_aggr0
                1.49TB   74.12GB   95% online       1 node_A_2         raid4,
                                                                       normal
    node_A_1_aggr1
                1.49TB   74.12GB   95% online       1 node_A_1         raid 4, normal
                                                                       mirrored
    node_A_2_aggr1
                1.49TB   74.12GB   95% online       1 node_A_2         raid 4, normal
                                                                       mirrored
    4 entries were displayed.
    
    cluster_A::>
  2. Eseguire il mirroring di uno degli aggregati root:

    storage aggregate mirror -aggregate root-aggregate

    L'esempio seguente mostra come il comando seleziona i dischi e richiede la conferma durante il mirroring dell'aggregato.

    cluster_A::> storage aggregate mirror -aggregate node_A_2_aggr0
    
    Info: Disks would be added to aggregate "node_A_2_aggr0" on node "node_A_2" in
          the following manner:
    
          Second Plex
    
            RAID Group rg0, 3 disks (block checksum, raid4)
              Position   Disk                      Type                  Size
              ---------- ------------------------- ---------- ---------------
              parity     2.10.0                    SSD                      -
              data       1.11.19                   SSD                894.0GB
              data       2.10.2                    SSD                894.0GB
    
          Aggregate capacity available for volume use would be 1.49TB.
    
    Do you want to continue? {y|n}: y
    
    cluster_A::>
  3. Verificare che il mirroring dell'aggregato root sia completo:

    storage aggregate show

    L'esempio seguente mostra che gli aggregati root sono mirrorati.

    cluster_A::> storage aggregate show
    
    Aggregate     Size Available Used% State   #Vols  Nodes       RAID Status
    --------- -------- --------- ----- ------- ------ ----------- ------------
    node_A_1_aggr0
                1.49TB   74.12GB   95% online       1 node_A_1    raid4,
                                                                  mirrored,
                                                                  normal
    node_A_2_aggr0
                2.24TB   838.5GB   63% online       1 node_A_2    raid4,
                                                                  mirrored,
                                                                  normal
    node_A_1_aggr1
                1.49TB   74.12GB   95% online       1 node_A_1    raid4,
                                                                  mirrored,
                                                                  normal
    node_A_2_aggr1
                1.49TB   74.12GB   95% online       1 node_A_2    raid4
                                                                  mirrored,
                                                                  normal
    4 entries were displayed.
    
    cluster_A::>
  4. Ripetere questi passaggi per gli altri aggregati root.

    Qualsiasi aggregato root che non ha lo stato di mirrored deve essere mirrorato.

Riconfigurazione del servizio ONTAP Mediator (configurazioni MetroCluster IP)

Se si dispone di una configurazione IP MetroCluster configurata con il servizio ONTAP Mediator, è necessario rimuovere e riconfigurare l'associazione con il mediatore.

Prima di iniziare
  • È necessario disporre dell'indirizzo IP, del nome utente e della password per il servizio di supporto ONTAP.

  • Il servizio ONTAP deve essere configurato e funzionante sull'host Linux.

Fasi
  1. Rimuovere la configurazione esistente del mediatore ONTAP:

    metrocluster configuration-settings mediator remove

  2. Riconfigurare la configurazione del mediatore ONTAP:

    metrocluster configuration-settings mediator add -mediator-address mediator-IP-address

Verifica dello stato della configurazione MetroCluster

Verificare lo stato della configurazione MetroCluster per verificarne il corretto funzionamento.

Fasi
  1. Verificare che MetroCluster sia configurato e in modalità normale su ciascun cluster:

    metrocluster show

    cluster_A::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_A         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain auso-on-cluster-disaster
    Remote: cluster_B         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain auso-on-cluster-disaster
  2. Verificare che il mirroring sia attivato su ciascun nodo:

    metrocluster node show

    cluster_A::> metrocluster node show
    DR                           Configuration  DR
    Group Cluster Node           State          Mirroring Mode
    ----- ------- -------------- -------------- --------- --------------------
    1     cluster_A
                  node_A_1       configured     enabled   normal
          cluster_B
                  node_B_1       configured     enabled   normal
    2 entries were displayed.
  3. Verificare che i componenti di MetroCluster siano in buone condizioni:

    metrocluster check run

    cluster_A::> metrocluster check run
    
    Last Checked On: 10/1/2014 16:03:37
    
    Component           Result
    ------------------- ---------
    nodes               ok
    lifs                ok
    config-replication  ok
    aggregates          ok
    4 entries were displayed.
    
    Command completed. Use the `metrocluster check show -instance` command or sub-commands in `metrocluster check` directory for detailed results.
    To check if the nodes are ready to do a switchover or switchback operation, run `metrocluster switchover -simulate` or `metrocluster switchback -simulate`, respectively.
  4. Verificare che non siano presenti avvisi sullo stato di salute:

    system health alert show

  5. Simulare un'operazione di switchover:

    1. Dal prompt di qualsiasi nodo, passare al livello di privilegio avanzato:

      set -privilege advanced

    Devi rispondere con y quando viene richiesto di passare alla modalità avanzata e di visualizzare il prompt della modalità avanzata (*).

    1. Eseguire l'operazione di switchover con -simulate parametro:

      metrocluster switchover -simulate

    2. Tornare al livello di privilegio admin:

      set -privilege admin

  6. Per le configurazioni MetroCluster IP che utilizzano il servizio ONTAP Mediator, verificare che il servizio sia attivo e operativo.

    1. Verificare che i dischi Mediator siano visibili al sistema:

      storage failover mailbox-disk show

      L'esempio seguente mostra che i dischi della mailbox sono stati riconosciuti.

      node_A_1::*> storage failover mailbox-disk show
                       Mailbox
      Node             Owner     Disk    Name        Disk UUID
      -------------     ------   -----   -----        ----------------
      sti113-vsim-ucs626g
      .
      .
           local     0m.i2.3L26      7BBA77C9:AD702D14:831B3E7E:0B0730EE:00000000:00000000:00000000:00000000:00000000:00000000
           local     0m.i2.3L27      928F79AE:631EA9F9:4DCB5DE6:3402AC48:00000000:00000000:00000000:00000000:00000000:00000000
           local     0m.i1.0L60      B7BCDB3C:297A4459:318C2748:181565A3:00000000:00000000:00000000:00000000:00000000:00000000
      .
      .
      .
           partner   0m.i1.0L14      EA71F260:D4DD5F22:E3422387:61D475B2:00000000:00000000:00000000:00000000:00000000:00000000
           partner   0m.i2.3L64      4460F436:AAE5AB9E:D1ED414E:ABF811F7:00000000:00000000:00000000:00000000:00000000:00000000
      28 entries were displayed.
    2. Passare al livello di privilegio avanzato:

      set -privilege advanced

    3. Verificare che i LUN della mailbox siano visibili al sistema:

      storage iscsi-initiator show

      L'output mostra la presenza dei LUN della mailbox:

    Node    Type       Label      Target Portal     Target Name                                 Admin/Op
    ----    ----       --------   ---------    --------- --------------------------------       --------
    .
    .
    .
    .node_A_1
                   mailbox
                         mediator 172.16.254.1    iqn.2012-05.local:mailbox.target.db5f02d6-e3d3    up/up
    .
    .
    .
    17 entries were displayed.
    1. Tornare al livello di privilegi amministrativi:

      set -privilege admin