Skip to main content
ONTAP MetroCluster
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

A concluir a recuperação

Colaboradores
PDFs

Execute as tarefas necessárias para concluir a recuperação de uma falha de vários controladores ou armazenamento.

Restabelecimento de armazenamentos de objetos para configurações do FabricPool

Se um dos armazenamentos de objetos em um espelho do FabricPool foi co-localizado com o local de desastre do MetroCluster e foi destruído, você deve restabelecer o armazenamento de objetos e o espelho do FabricPool.

Sobre esta tarefa

  • Se os armazenamentos de objetos forem remotos e um site MetroCluster for destruído, você não precisará reconstruir o armazenamento de objetos e as configurações originais do armazenamento de objetos, bem como o conteúdo de dados inativos serão retidos.

  • Para obter mais informações sobre configurações do FabricPool, consulte "Gerenciamento de disco e agregados".

Passo

  1. Seguir o procedimento "Substituição de um espelho FabricPool numa configuração MetroCluster" no "Gerenciamento de disco e agregados".

Verificando licenças nos nós substituídos

Você deve instalar novas licenças para os nós de substituição se os nós deficientes estiverem usando recursos do ONTAP que exigem uma licença padrão (node-locked). Para recursos com licenças padrão, cada nó no cluster deve ter sua própria chave para o recurso.

Sobre esta tarefa

Até instalar chaves de licença, os recursos que exigem licenças padrão continuam disponíveis para o nó de substituição. No entanto, se o nó prejudicado for o único nó no cluster com uma licença para o recurso, nenhuma alteração de configuração será permitida. Além disso, o uso de recursos não licenciados no nó pode deixá-lo fora de conformidade com o contrato de licença, portanto, você deve instalar a chave de licença de substituição ou as chaves no nó de substituição o mais rápido possível.

As chaves de licença devem estar no formato de 28 carateres.

Você tem um período de carência de 90 dias para instalar as chaves de licença. Após o período de carência, todas as licenças antigas são invalidadas. Depois que uma chave de licença válida é instalada, você tem 24 horas para instalar todas as chaves antes que o período de carência termine.

Observação Se todos os nós de um local tiverem sido substituídos (um único nó no caso de uma configuração de MetroCluster de dois nós), as chaves de licença devem ser instaladas no nó ou nós de substituição antes do switchback.
Passos

  1. Identifique as licenças no nó:

    license show

    O exemplo a seguir exibe as informações sobre licenças no 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. Verifique se as licenças são boas para o nó após o switchback:

    metrocluster check license show

    O exemplo a seguir exibe as licenças que são boas para o nó:

    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 você precisar de novas chaves de licença, obtenha chaves de licença de substituição no site de suporte da NetApp na seção meu suporte em licenças de software.

    Observação As novas chaves de licença que você precisa são geradas automaticamente e enviadas para o endereço de e-mail em arquivo. Se não receber o e-mail com as chaves de licença no prazo de 30 dias, consulte a secção "Quem contactar se tiver problemas com as minhas licenças?" no artigo da base de dados de Conhecimento "Pós-processo de substituição da placa-mãe para atualizar o licenciamento em um sistema AFF/FAS."

  4. Instale cada chave de licença:

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

  5. Remova as licenças antigas, se desejar:

    1. Verifique se há licenças não utilizadas:

      license clean-up -unused -simulate

    2. Se a lista estiver correta, remova as licenças não utilizadas:

      license clean-up -unused

Restaurar o gerenciamento de chaves

Se os volumes de dados estiverem criptografados, você precisará restaurar o gerenciamento de chaves. Se o volume raiz estiver criptografado, você deverá recuperar o gerenciamento de chaves.

Passos

  1. Se os volumes de dados estiverem criptografados, restaure as chaves usando o comando correto para a configuração de gerenciamento de chaves.

    Se você estiver usando…​

    Use este comando…​

    Gestão de chaves a bordo

    security key-manager onboard sync

    Para obter mais informações, "Restaurar chaves de criptografia integradas de gerenciamento de chaves"consulte .

    Gerenciamento de chaves externas

    security key-manager key query -node node-name

    Para obter mais informações, "Restaurar chaves de criptografia de gerenciamento de chaves externas"consulte .

  2. Se o volume raiz estiver encriptado, utilize o procedimento em "Recuperar o gerenciamento de chaves se o volume raiz for criptografado".

Executando um switchback

Depois de curar a configuração do MetroCluster, você pode executar a operação MetroCluster switchback. A operação de switchback do MetroCluster retorna a configuração ao seu estado operacional normal, com as máquinas virtuais de armazenamento de origem sincronizada (SVMs) no local de desastre ativas e fornecendo dados dos pools de discos locais.

Antes de começar

  • O cluster de desastres deve ter mudado com sucesso para o cluster sobrevivente.

  • A recuperação deve ter sido realizada nos agregados de dados e raiz.

  • Os nós de cluster sobreviventes não devem estar no estado de failover de HA (todos os nós precisam estar ativos e em execução para cada par de HA).

  • Os módulos do controlador do local de desastre devem ser completamente inicializados e não no modo de aquisição de HA.

  • O agregado raiz deve ser espelhado.

  • Os links interswitches (ISLs) devem estar online.

  • Todas as licenças necessárias devem ser instaladas no sistema.

Passos

  1. Confirme se todos os nós estão no estado ativado:

    metrocluster node show

    O exemplo a seguir exibe os nós que estão no estado habilitado:

    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. Confirme se a ressincronização está concluída em todos os SVMs:

    metrocluster vserver show

  3. Verifique se todas as migrações automáticas de LIF que estão sendo executadas pelas operações de recuperação foram concluídas com sucesso:

    metrocluster check lif show

  4. Execute o switchback executando o metrocluster switchback comando de qualquer nó no cluster sobrevivente.

  5. Verifique o progresso do funcionamento do interrutor de comutação:

    metrocluster show

    A operação de switchback ainda está em andamento quando a saída exibe "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 -

    A operação de comutação está concluída quando a saída exibe "normal":

    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 um switchback levar muito tempo para terminar, você pode verificar o status das linhas de base em andamento usando o seguinte comando no nível avançado de privilégio:

    metrocluster config-replication resync-status show

  6. Restabelecer qualquer configuração SnapMirror ou SnapVault.

    No ONTAP 8,3, você precisa restabelecer manualmente uma configuração de SnapMirror perdida após uma operação de switchback MetroCluster. No ONTAP 9.0 e mais tarde, o relacionamento é restabelecido automaticamente.

Verificando um switchback bem-sucedido

Depois de executar o switchback, você deseja confirmar que todos os agregados e máquinas virtuais de storage (SVMs) são trocados de volta e on-line.

Passos

  1. Verifique se os agregados de dados comutados estão invertidos:

    storage aggregate show

    No exemplo a seguir, aggr_B2 no nó B2 mudou de volta:

    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 o local de desastre incluiu agregados sem espelhamento e os agregados sem espelhamento não estiverem mais presentes, o agregado pode aparecer com um estado de "'desconhecido'" na saída do comando storage Aggregate show. Para remover as entradas desatualizadas para os agregados sem espelhamento, consulte o artigo da base de dados de Conhecimento "Como remover entradas agregadas sem espelhamento obsoletas em um MetroCluster após desastre em que o armazenamento foi perdido."

  2. Verifique se todos os SVMs de destino de sincronização no cluster sobrevivente estão inativos (mostrando um estado de administrador "coberto") e os SVMs de origem de sincronização no cluster de desastres estão ativos e em execução:

    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

    Os agregados de destino de sincronização na configuração do MetroCluster têm o sufixo "-mc" automaticamente anexado ao seu nome para ajudar a identificá-los.

  3. Confirme se as operações de switchback foram bem-sucedidas usando o metrocluster operation show comando.

    Se o comando output mostrar…​

    Então…​

    Que o estado de operação de comutação é bem-sucedido.

    O processo de switchback está concluído e você pode prosseguir com a operação do sistema.

    Que a operação de switchback ou switchback-continuation-Agent é parcialmente bem-sucedida.

    Execute a correção sugerida fornecida na saída do comando MetroCluster operation show.
Depois de terminar

Você deve repetir as seções anteriores para executar o switchback na direção oposta. Se o site_A fez um switchover do site_B, faça um switchover do site_A.

Espelhando os agregados de raiz dos nós de substituição

Se os discos tiverem sido substituídos, você precisará espelhar os agregados raiz dos novos nós no local de desastre.

Passos

  1. No local do desastre, identifique os agregados que não são espelhados:

    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. Espelhar um dos agregados de raiz:

    storage aggregate mirror -aggregate root-aggregate

    O exemplo a seguir mostra como o comando seleciona discos e solicita confirmação ao espelhar o agregado.

    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. Verifique se o espelhamento do agregado raiz está concluído:

    storage aggregate show

    O exemplo a seguir mostra que os agregados raiz são espelhados.

    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. Repita estas etapas para os outros agregados de raiz.

    Qualquer agregado de raiz que não tenha o status espelhado deve ser espelhado.

Reconfigurar o serviço do Mediador ONTAP (configurações IP do MetroCluster)

Se você tiver uma configuração IP do MetroCluster configurada com o serviço Mediador do ONTAP, remova e reconfigure a associação com o mediador.

Antes de começar

  • Você deve ter o endereço IP, o nome de usuário e a senha para o serviço do Mediador ONTAP.

  • O serviço Mediador ONTAP deve ser configurado e operar no host Linux.

Passos

  1. Remova a configuração do Mediador ONTAP existente:

    metrocluster configuration-settings mediator remove

  2. Reconfigure a configuração do Mediador ONTAP:

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

Verificando a integridade da configuração do MetroCluster

Você deve verificar a integridade da configuração do MetroCluster para verificar o funcionamento correto.

Passos

  1. Verifique se o MetroCluster está configurado e no modo normal em cada 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. Verifique se o espelhamento está ativado em cada nó:

    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. Verifique se os componentes do MetroCluster estão em bom estado:

    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. Verifique se não existem alertas de saúde:

    system health alert show

  5. Simular uma operação de comutação:

    1. A partir do prompt de qualquer nó, altere para o nível de privilégio avançado:

      set -privilege advanced

    Você precisa responder com y quando solicitado para continuar no modo avançado e ver o prompt do modo avançado (*>).

    1. Efectuar a operação de comutação com o -simulate parâmetro:

      metrocluster switchover -simulate

    2. Voltar ao nível de privilégio de administrador:

      set -privilege admin

  6. Para configurações IP do MetroCluster usando o serviço Mediador ONTAP, confirme se o serviço Mediador está funcionando.

    1. Verifique se os discos Mediator estão visíveis para o sistema:

      storage failover mailbox-disk show

      O exemplo a seguir mostra que os discos da caixa de correio foram reconhecidos.

      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. Mude para o nível de privilégio avançado:

      set -privilege advanced

    3. Verifique se os LUNs da caixa de correio estão visíveis para o sistema:

      storage iscsi-initiator show

      A saída mostrará a presença dos LUNs da caixa de correio:

    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. Voltar ao nível de privilégio administrativo:

      set -privilege admin