Skip to main content
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.

Substitua um módulo de e/S - AFF A700 e FAS9000

Colaboradores

Para substituir um módulo de e/S, tem de executar uma sequência específica de tarefas.

  • Pode utilizar este procedimento com todas as versões do ONTAP suportadas pelo seu sistema

  • Todos os outros componentes do sistema devem estar funcionando corretamente; caso contrário, você deve entrar em Contato com o suporte técnico.

Passo 1: Desligue o controlador desativado

Você pode desligar ou assumir o controlador prejudicado usando procedimentos diferentes, dependendo da configuração do hardware do sistema de armazenamento.

Opção 1: A maioria das configurações

Para encerrar o controlador com deficiência, você deve determinar o status do controlador e, se necessário, assumir o controlador para que o controlador saudável continue fornecendo dados do armazenamento do controlador com deficiência.

Sobre esta tarefa
  • Se você tiver um sistema SAN, você deve ter verificado mensagens de cluster kernel-service show`evento ) para o blade SCSI do controlador afetado. O `cluster kernel-service show comando (do modo avançado priv) exibe o nome do nó, "status do quorum"desse nó, o status de disponibilidade desse nó e o status operacional desse nó.

    Cada processo SCSI-blade deve estar em quórum com os outros nós no cluster. Qualquer problema deve ser resolvido antes de prosseguir com a substituição.

  • Se você tiver um cluster com mais de dois nós, ele deverá estar no quórum. Se o cluster não estiver em quórum ou se um controlador íntegro exibir false para qualificação e integridade, você deverá corrigir o problema antes de encerrar o controlador prejudicado; "Sincronize um nó com o cluster"consulte .

Passos
  1. Se o AutoSupport estiver ativado, suprimir a criação automática de casos invocando uma mensagem AutoSupport: system node autosupport invoke -node * -type all -message MAINT=<# of hours>h

    A seguinte mensagem AutoSupport suprime a criação automática de casos por duas horas: cluster1:> system node autosupport invoke -node * -type all -message MAINT=2h

  2. Desative a giveback automática a partir da consola do controlador saudável: storage failover modify -node local -auto-giveback false

    Observação Quando vir do pretende desativar a auto-giveback?, introduza y.
  3. Leve o controlador prejudicado para o prompt Loader:

    Se o controlador afetado estiver a apresentar…​ Então…​

    O prompt Loader

    Vá para a próxima etapa.

    A aguardar pela giveback…​

    Pressione Ctrl-C e responda y quando solicitado.

    Prompt do sistema ou prompt de senha

    Assuma ou interrompa o controlador prejudicado do controlador saudável: storage failover takeover -ofnode impaired_node_name

    Quando o controlador prejudicado mostrar aguardando a giveback…​, pressione Ctrl-C e responda y.

Opção 2: O controlador está em um MetroCluster de dois nós

Para desligar o controlador desativado, você deve determinar o status do controlador e, se necessário, trocar o controlador para que o controlador saudável continue fornecendo dados do armazenamento do controlador prejudicado.

Sobre esta tarefa
  • Você deve deixar as fontes de alimentação ligadas no final deste procedimento para fornecer energia ao controlador de integridade.

Passos
  1. Verifique o estado do MetroCluster para determinar se o controlador afetado mudou automaticamente para o controlador saudável: metrocluster show

  2. Dependendo se ocorreu uma mudança automática, proceda de acordo com a seguinte tabela:

    Se o controlador deficiente…​ Então…​

    Mudou automaticamente

    Avance para o passo seguinte.

    Não mudou automaticamente

    Execute uma operação de comutação planejada a partir do controlador íntegro: metrocluster switchover

    Não mudou automaticamente, tentou mudar com o comando e o switchover metrocluster switchover foi vetado

    Reveja as mensagens de veto e, se possível, resolva o problema e tente novamente. Se você não conseguir resolver o problema, entre em Contato com o suporte técnico.

  3. Ressincronize os agregados de dados executando o metrocluster heal -phase aggregates comando do cluster sobrevivente.

    controller_A_1::> metrocluster heal -phase aggregates
    [Job 130] Job succeeded: Heal Aggregates is successful.

    Se a cura for vetada, você tem a opção de reemitir o metrocluster heal comando com o -override-vetoes parâmetro. Se você usar esse parâmetro opcional, o sistema substituirá quaisquer vetos de software que impeçam a operação de recuperação.

  4. Verifique se a operação foi concluída usando o comando MetroCluster operation show.

    controller_A_1::> metrocluster operation show
        Operation: heal-aggregates
          State: successful
    Start Time: 7/25/2016 18:45:55
       End Time: 7/25/2016 18:45:56
         Errors: -
  5. Verifique o estado dos agregados utilizando o storage aggregate show comando.

    controller_A_1::> storage aggregate show
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    ...
    aggr_b2    227.1GB   227.1GB    0% online       0 mcc1-a2          raid_dp, mirrored, normal...
  6. Curar os agregados raiz usando o metrocluster heal -phase root-aggregates comando.

    mcc1A::> metrocluster heal -phase root-aggregates
    [Job 137] Job succeeded: Heal Root Aggregates is successful

    Se a recuperação for vetada, você terá a opção de reemitir o metrocluster heal comando com o parâmetro -override-vetos. Se você usar esse parâmetro opcional, o sistema substituirá quaisquer vetos de software que impeçam a operação de recuperação.

  7. Verifique se a operação heal está concluída usando o metrocluster operation show comando no cluster de destino:

    mcc1A::> metrocluster operation show
      Operation: heal-root-aggregates
          State: successful
     Start Time: 7/29/2016 20:54:41
       End Time: 7/29/2016 20:54:42
         Errors: -
  8. No módulo do controlador desativado, desligue as fontes de alimentação.

Passo 2: Substitua os módulos de e/S.

Para substituir um módulo de e/S, localize-o no chassis e siga a sequência específica de passos.

Passos
  1. Se você ainda não está aterrado, aterre-se adequadamente.

  2. Desconete qualquer cabeamento associado ao módulo de e/S de destino.

    Certifique-se de etiquetar os cabos para que saiba de onde vieram.

  3. Retire o módulo de e/S alvo do chassis:

    1. Prima o botão de came com letras e numerados.

      O botão do came afasta-se do chassis.

    2. Rode o trinco da árvore de cames para baixo até estar na posição horizontal.

      O módulo de e/S desengata do chassis e desloca-se cerca de 1/2 polegadas para fora do slot de e/S.

    3. Retire o módulo de e/S do chassis puxando as patilhas de puxar nas laterais da face do módulo.

      Certifique-se de manter o controle de qual slot o módulo de e/S estava.

      Remover um módulo PCIe

    Legenda número 1

    Trinco do came de e/S com letras e numerado

    Legenda número 2

    Trinco da came de e/S completamente desbloqueado

  4. Coloque o módulo de e/S de lado.

  5. Instale o módulo de e/S de substituição no chassis, deslizando suavemente o módulo de e/S para a ranhura até que o trinco do excêntrico de e/S numerado e com letras comece a engatar com o pino do excêntrico de e/S e, em seguida, empurre o trinco do excêntrico de e/S totalmente para cima para bloquear o módulo no devido lugar.

  6. Recable o módulo I/o, conforme necessário.

Passo 3: Reinicie o controlador após a substituição do módulo de e/S.

Depois de substituir um módulo de e/S, tem de reiniciar o módulo do controlador.

Observação Se o novo módulo de e/S não for o mesmo modelo que o módulo com falha, você deve primeiro reiniciar o BMC.
Passos
  1. Reinicie o BMC se o módulo de substituição não for o mesmo modelo do módulo antigo:

    1. A partir do prompt Loader, mude para o modo de privilégio avançado: priv set advanced

    2. Reinicie o BMC: sp reboot

  2. No prompt Loader, reinicie o nó: bye

    Observação Isso reinicializa as placas PCIe e outros componentes e reinicializa o nó.
  3. Se o sistema estiver configurado para suportar interconexão de cluster de 10 GbE e conexões de dados em NICs de 40 GbE ou portas integradas, converta essas portas em conexões de 10 GbE usando o nicadmin convert comando do modo Manutenção.

    Observação Certifique-se de sair do modo de manutenção depois de concluir a conversão.
  4. Retorne o nó à operação normal: storage failover giveback -ofnode impaired_node_name

  5. Se a giveback automática foi desativada, reative-a: storage failover modify -node local -auto-giveback true

    Observação Se o sistema estiver em uma configuração de MetroCluster de dois nós, será necessário voltar os agregados conforme descrito na próxima etapa.

Etapa 4: Alterne agregados de volta em uma configuração de MetroCluster de dois nós

Depois de concluir a substituição da FRU em uma configuração de MetroCluster de dois nós, você pode executar a operação de switchback do MetroCluster. Isso retorna a configuração ao seu estado operacional normal, com as máquinas virtuais de armazenamento de origem sincronizada (SVMs) no site anteriormente prejudicado agora ativo e fornecendo dados dos pools de discos locais.

Esta tarefa só se aplica a configurações de MetroCluster de dois nós.

Passos
  1. Verifique se todos os nós estão no enabled estado: metrocluster node show

    cluster_B::>  metrocluster node show
    
    DR                           Configuration  DR
    Group Cluster Node           State          Mirroring Mode
    ----- ------- -------------- -------------- --------- --------------------
    1     cluster_A
                  controller_A_1 configured     enabled   heal roots completed
          cluster_B
                  controller_B_1 configured     enabled   waiting for switchback recovery
    2 entries were displayed.
  2. Verifique 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 usando o metrocluster switchback comando de qualquer nó no cluster sobrevivente.

  5. Verifique se a operação de comutação foi concluída: metrocluster show

    A operação de switchback ainda está em execução quando um cluster está no waiting-for-switchback estado:

    cluster_B::> metrocluster show
    Cluster              Configuration State    Mode
    --------------------	------------------- 	---------
     Local: cluster_B configured       	switchover
    Remote: cluster_A configured       	waiting-for-switchback

    A operação de switchback é concluída quando os clusters estão no normal estado.:

    cluster_B::> metrocluster show
    Cluster              Configuration State    Mode
    --------------------	------------------- 	---------
     Local: cluster_B configured      		normal
    Remote: cluster_A configured      		normal

    Se um switchback estiver demorando muito tempo para terminar, você pode verificar o status das linhas de base em andamento usando o metrocluster config-replication resync-status show comando.

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

Passo 5: Devolva a peça com falha ao NetApp

Devolva a peça com falha ao NetApp, conforme descrito nas instruções de RMA fornecidas com o kit. Consulte a "Devolução de peças e substituições" página para obter mais informações.