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.

Prepare os nós para atualização

Colaboradores

Antes de substituir os nós originais, confirme se eles estão em um par de HA, não têm discos ausentes ou com falha, podem acessar o storage uns dos outros e não possuem LIFs de dados atribuídos aos outros nós no cluster. Você também deve coletar informações sobre os nós originais e, se o cluster estiver em um ambiente SAN, confirmar se todos os nós do cluster estão em quórum.

Passos
  1. Confirme se cada um dos nós originais tem recursos suficientes para suportar adequadamente a carga de trabalho de ambos os nós durante o modo de aquisição.

    "Referências"Consulte o link para Gerenciamento de par HA e siga a seção melhores práticas para pares HA. Nenhum dos nós originais deve ser executado com mais de 50% de utilização; se um nó estiver executando com menos de 50% de utilização, ele poderá lidar com as cargas de ambos os nós durante a atualização da controladora.

  2. Conclua as subetapas a seguir para criar uma linha de base de desempenho para os nós originais:

    1. Certifique-se de que a conta de utilizador de diagnóstico está desbloqueada.

      Importante

      A conta de utilizador de diagnóstico destina-se apenas a fins de diagnóstico de baixo nível e deve ser utilizada apenas com orientação do suporte técnico.

      Para obter informações sobre como desbloquear as contas de usuário, "Referências"consulte o link para a Referência de administração do sistema.

    2. Consulte o "Referências"link para o Site de suporte NetApp e faça o download do Coletor de desempenho e estatísticas (Perfstat Converged).

      A ferramenta Convergente Perfstat permite estabelecer uma linha de base de desempenho para comparação após a atualização.

    3. Crie uma linha de base de desempenho, seguindo as instruções no site de suporte da NetApp.

  3. "Referências"Consulte o link para o site de suporte NetApp e abra um caso de suporte no site de suporte da NetApp.

    Você pode usar o caso para relatar quaisquer problemas que possam surgir durante a atualização.

  4. Verifique se as baterias NVMEM ou NVRAM de node3 e node4 estão carregadas e carregue-as se não estiverem.

    Você deve verificar fisicamente node3 e node4 para ver se as baterias NVMEM ou NVRAM estão carregadas. Para obter informações sobre os LEDs para o modelo de node3 e node4, consulte a "Referências"ligação ao Hardware Universe.

    Aviso Atenção não tente limpar o conteúdo do NVRAM. Se houver necessidade de limpar o conteúdo do NVRAM, entre em Contato com o suporte técnico da NetApp.
  5. Verifique a versão do ONTAP em node3 e node4.

    Os novos nós devem ter a mesma versão do ONTAP 9.x instalada neles que está instalada nos nós originais. Se os novos nós tiverem uma versão diferente do ONTAP instalada, você deverá inicializar os novos controladores depois de instalá-los. Para obter instruções sobre como atualizar o ONTAP, consulte "Referências"o link para Atualizar ONTAP.

    As informações sobre a versão do ONTAP em node3 e node4 devem ser incluídas nas caixas de envio. A versão do ONTAP é exibida quando o nó é inicializado ou você pode inicializar o nó no modo de manutenção e executar o comando:

    version

  6. Verifique se você tem duas ou quatro LIFs de cluster em node1 e node2:

    network interface show -role cluster

    O sistema exibe quaisquer LIFs de cluster, como mostrado no exemplo a seguir:

    cluster::> network interface show -role cluster
            Logical    Status     Network          Current  Current Is
    Vserver Interface  Admin/Oper Address/Mask     Node     Port    Home
    ------- ---------- ---------- ---------------- -------- ------- ----
    node1
            clus1      up/up      172.17.177.2/24  node1    e0c     true
            clus2      up/up      172.17.177.6/24  node1    e0e     true
    node2
            clus1      up/up      172.17.177.3/24  node2    e0c     true
            clus2      up/up      172.17.177.7/24  node2    e0e     true
  7. Se você tiver duas ou quatro LIFs de cluster no node1 ou node2, certifique-se de que você pode fazer o ping de ambas as LIFs de cluster em todos os caminhos disponíveis, executando as seguintes subetapas:

    1. Introduza o nível de privilégio avançado:

      set -privilege advanced

      O sistema exibe a seguinte mensagem:

      Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
      Do you wish to continue? (y or n):
    2. Introduza y.

    3. Faça ping nos nós e teste a conetividade:

      cluster ping-cluster -node node_name

      O sistema exibe uma mensagem semelhante ao seguinte exemplo:

    cluster::*> cluster ping-cluster -node node1
    Host is node1
    Getting addresses from network interface table...
    Local = 10.254.231.102 10.254.91.42
    Remote = 10.254.42.25 10.254.16.228
    Ping status:
    ...
    Basic connectivity succeeds on 4 path(s) Basic connectivity fails on 0 path(s)
    ................
    Detected 1500 byte MTU on 4 path(s):
    Local 10.254.231.102 to Remote 10.254.16.228
    Local 10.254.231.102 to Remote 10.254.42.25
    Local 10.254.91.42 to Remote 10.254.16.228
    Local 10.254.91.42 to Remote 10.254.42.25
    Larger than PMTU communication succeeds on 4 path(s)
    RPC status:
    2 paths up, 0 paths down (tcp check)
    2 paths up, 0 paths down (udp check)

    +
    Se o nó usar duas portas de cluster, você verá que ele é capaz de se comunicar em quatro caminhos, como mostrado no exemplo.

    1. Retornar ao privilégio de nível administrativo:

      set -privilege admin

  8. Confirme se o node1 e o node2 estão em um par de HA e verifique se os nós estão conetados uns aos outros e se o takeover é possível:

    storage failover show

    O exemplo a seguir mostra a saída quando os nós estão conetados uns aos outros e a aquisição é possível:

    cluster::> storage failover show
                                  Takeover
    Node           Partner        Possible State Description
    -------------- -------------- -------- -------------------------------
    node1          node2          true     Connected to node2
    node2          node1          true     Connected to node1

    Nenhum dos nós deve estar em giveback parcial. O exemplo a seguir mostra que node1 está em parcial giveback:

    cluster::> storage failover show
                                  Takeover
    Node           Partner        Possible State Description
    -------------- -------------- -------- -------------------------------
    node1          node2          true     Connected to node2, Partial giveback
    node2          node1          true     Connected to node1

    Se qualquer nó estiver em parcial giveback, use o storage failover giveback comando para executar o giveback e use o storage failover show-giveback comando para garantir que nenhum agregado ainda precise ser devolvido. Para obter informações detalhadas sobre os comandos, "Referências"consulte o link para HA PAIR Management.

  9. Confirme que nem o node1 nem o node2 possuem os agregados para os quais é o proprietário atual (mas não o proprietário da casa):

    storage aggregate show -nodes node_name -is-home false -fields owner-name, home-name, state

    Se nem node1 nem node2 possuírem agregados para os quais é o proprietário atual (mas não o proprietário da casa), o sistema retornará uma mensagem semelhante ao seguinte exemplo:

    cluster::> storage aggregate show -node node2 -is-home false -fields owner-name,homename,state
    There are no entries matching your query.

    O exemplo a seguir mostra a saída do comando para um nó chamado node2 que é o proprietário da casa, mas não o proprietário atual, de quatro agregados:

    cluster::> storage aggregate show -node node2 -is-home false
                   -fields owner-name,home-name,state
    
    aggregate     home-name    owner-name   state
    ------------- ------------ ------------ ------
    aggr1         node1        node2        online
    aggr2         node1        node2        online
    aggr3         node1        node2        online
    aggr4         node1        node2        online
    
    4 entries were displayed.
  10. Execute uma das seguintes ações:

    Se o comando Passo 9em …​ Então…​

    Tinha saída em branco

    Pule a Etapa 11 e vá para Passo 12.

    Tinha saída

    Vá para Passo 11.

  11. se node1 ou node2 possuir agregados para os quais é o proprietário atual, mas não o proprietário da casa, complete os seguintes subpassos:

    1. Devolva os agregados atualmente pertencentes ao nó do parceiro para o nó do proprietário da casa:

      storage failover giveback -ofnode home_node_name

    2. Verifique se nem o node1 nem o node2 ainda possuem agregados para os quais é o proprietário atual (mas não o proprietário da casa):

      storage aggregate show -nodes node_name -is-home false -fields owner-name, home-name, state

      O exemplo a seguir mostra a saída do comando quando um nó é o proprietário atual e proprietário de agregados:

    cluster::> storage aggregate show -nodes node1
              -is-home true -fields owner-name,home-name,state
    
    aggregate     home-name    owner-name   state
    ------------- ------------ ------------ ------
    aggr1         node1        node1        online
    aggr2         node1        node1        online
    aggr3         node1        node1        online
    aggr4         node1        node1        online
    
    4 entries were displayed.
  12. confirmar que o node1 e o node2 podem acessar o armazenamento um do outro e verificar se não há discos ausentes:

    storage failover show -fields local-missing-disks,partner-missing-disks

    O exemplo a seguir mostra a saída quando nenhum disco está faltando:

    cluster::> storage failover show -fields local-missing-disks,partner-missing-disks
    
    node     local-missing-disks partner-missing-disks
    -------- ------------------- ---------------------
    node1    None                None
    node2    None                None

    Se algum disco estiver faltando, "Referências"consulte o link para Gerenciamento de disco e agregado com a CLI, Gerenciamento de armazenamento lógico com a CLI e Gerenciamento de par HA para configurar o armazenamento para o par de HA.

  13. Confirme se node1 e node2 estão saudáveis e qualificados para participar do cluster:

    cluster show

    O exemplo a seguir mostra a saída quando ambos os nós são elegíveis e íntegros:

    cluster::> cluster show
    
    Node                  Health  Eligibility
    --------------------- ------- ------------
    node1                 true    true
    node2                 true    true
  14. Defina o nível de privilégio como avançado:

    set -privilege advanced

  15. confirme que node1 e node2 estão executando a mesma versão do ONTAP:

    system node image show -node node1,node2 -iscurrent true

    O exemplo a seguir mostra a saída do comando:

    cluster::*> system node image show -node node1,node2 -iscurrent true
    
                     Is      Is                Install
    Node     Image   Default Current Version   Date
    -------- ------- ------- ------- --------- -------------------
    node1
             image1  true    true    9.1         2/7/2017 20:22:06
    node2
             image1  true    true    9.1         2/7/2017 20:20:48
    
    2 entries were displayed.
  16. Verifique se nem o node1 nem o node2 possuem LIFs de dados que pertencem a outros nós no cluster e verifique as Current Node colunas e Is Home na saída:

    network interface show -role data -is-home false -curr-node node_name

    O exemplo a seguir mostra a saída quando node1 não tem LIFs que são de propriedade própria por outros nós no cluster:

    cluster::> network interface show -role data -is-home false -curr-node node1
     There are no entries matching your query.

    O exemplo a seguir mostra a saída quando o node1 possui LIFs de dados de propriedade do outro nó:

    cluster::> network interface show -role data -is-home false -curr-node node1
    
                Logical    Status     Network            Current       Current Is
    Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
    ----------- ---------- ---------- ------------------ ------------- ------- ----
    vs0
                data1      up/up      172.18.103.137/24  node1         e0d     false
                data2      up/up      172.18.103.143/24  node1         e0f     false
    
    2 entries were displayed.
  17. Se a saída em Passo 15 mostrar que node1 ou node2 possui quaisquer LIFs de dados de propriedade de outros nós no cluster, migre os LIFs de dados de node1 ou node2:

    network interface revert -vserver * -lif *

    Para obter informações detalhadas sobre o network interface revert comando, "Referências"consulte a ligação para os comandos ONTAP 9: Manual Page Reference.

  18. Verifique se o node1 ou o node2 possui quaisquer discos com falha:

    storage disk show -nodelist node1,node2 -broken

    Se algum dos discos tiver falhado, remova-os seguindo as instruções no Disk e no gerenciamento de agregados com a CLI. (Consulte a "Referências"ligação ao Disk e ao gerenciamento de agregados com a CLI.)

  19. Colete informações sobre node1 e node2, completando as seguintes subetapas e gravando a saída de cada comando:

    Observação Você usará essas informações posteriormente no procedimento.
    1. Registre o modelo, a ID do sistema e o número de série de ambos os nós:

      system node show -node node1,node2 -instance

      Observação Você usará as informações para reatribuir discos e desativar os nós originais.
    2. Digite o comando a seguir no node1 e no node2 e Registre informações sobre as gavetas, número de discos em cada compartimento, detalhes do armazenamento flash, memória, NVRAM e placas de rede da saída:

      run -node node_name sysconfig

      Observação Você pode usar as informações para identificar peças ou acessórios que você pode querer transferir para node3 ou node4. Se você não sabe se os nós são sistemas V-Series ou têm software de virtualização FlexArray, você pode aprender isso também com a saída.
    3. Digite o seguinte comando em node1 e node2 e Registre os agregados que estão on-line em ambos os nós:

      storage aggregate show -node node_name -state online

      Observação Você pode usar essas informações e as informações na subetapa a seguir para verificar se os agregados e volumes permanecem on-line durante o procedimento, exceto para o breve período em que eles estão off-line durante a realocação.
    4. Digite o seguinte comando em node1 e node2 e Registre os volumes que estão offline em ambos os nós:

      volume show -node node_name -state offline

    Observação Após a atualização, você executará o comando novamente e comparará a saída com a saída nesta etapa para ver se algum outro volume ficou offline.
  20. Digite os seguintes comandos para ver se algum grupo de interface ou VLANs estão configurados no node1 ou node2:

    network port ifgrp show

    network port vlan show

    Anote se os grupos de interface ou VLANs estão configurados no node1 ou node2; você precisa dessas informações na próxima etapa e posteriormente no procedimento.

  21. Execute as seguintes subetapas em node1 e node2 para confirmar que as portas físicas podem ser mapeadas corretamente posteriormente no procedimento:

    1. Digite o comando a seguir para ver se há grupos de failover no nó que não seja clusterwide:

      network interface failover-groups show

      Grupos de failover são conjuntos de portas de rede presentes no sistema. Como a atualização do hardware da controladora pode alterar o local das portas físicas, os grupos de failover podem ser inadvertidamente alterados durante a atualização.

      O sistema exibe grupos de failover no nó, como mostrado no exemplo a seguir:

      cluster::> network interface failover-groups show
      
      Vserver             Group             Targets
      ------------------- ----------------- ----------
      Cluster             Cluster           node1:e0a, node1:e0b
                                            node2:e0a, node2:e0b
      
      fg_6210_e0c         Default           node1:e0c, node1:e0d
                                            node1:e0e, node2:e0c
                                            node2:e0d, node2:e0e
      
      2 entries were displayed.
    2. Se houver grupos de failover presentes que não `clusterwide`o , Registre os nomes dos grupos de failover e as portas que pertencem aos grupos de failover.

    3. Digite o seguinte comando para ver se há VLANs configuradas no nó:

      network port vlan show -node node_name

      As VLANs são configuradas em portas físicas. Se as portas físicas mudarem, as VLANs precisarão ser recriadas posteriormente no procedimento.

      O sistema exibe VLANs configuradas no nó, como mostrado no exemplo a seguir:

    cluster::> network port vlan show
    
    Network Network
    Node    VLAN Name Port    VLAN ID MAC Address
    ------  --------- ------- ------- ------------------
    node1   e1b-70    e1b     70      00:15:17:76:7b:69
    1. Se houver VLANs configuradas no nó, anote cada porta de rede e o emparelhamento de ID de VLAN.

  22. Execute uma das seguintes ações:

    Se os grupos de interface ou VLANS forem…​ Então…​

    Em node1 ou node2

    Completa Passo 23 e Passo 24.

    Não no node1 ou node2

    Vá para Passo 24.

  23. se você não sabe se node1 e node2 estão em um ambiente SAN ou não SAN, digite o seguinte comando e examine sua saída:

    network interface show -vserver vserver_name -data-protocol iscsi|fcp

    Se nem iSCSI nem FC estiverem configurados para o SVM, o comando exibirá uma mensagem semelhante ao seguinte exemplo:

    cluster::> network interface show -vserver Vserver8970 -data-protocol iscsi|fcp
    There are no entries matching your query.

    Você pode confirmar que o nó está em um ambiente nas usando o network interface show comando com os -data-protocol nfs|cifs parâmetros.

    Se iSCSI ou FC estiver configurado para o SVM, o comando exibirá uma mensagem semelhante ao seguinte exemplo:

    cluster::> network interface show -vserver vs1 -data-protocol iscsi|fcp
    
             Logical    Status     Network            Current  Current Is
    Vserver  Interface  Admin/Oper Address/Mask       Node     Port    Home
    -------- ---------- ---------- ------------------ -------- ------- ----
    vs1      vs1_lif1   up/down    172.17.176.20/24   node1    0d      true
  24. Verifique se todos os nós do cluster estão em quórum, executando as seguintes subetapas:

    1. Introduza o nível de privilégio avançado:

      set -privilege advanced

      O sistema exibe a seguinte mensagem:

      Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
      Do you wish to continue? (y or n):
    2. Introduza y.

    3. Verifique o estado do serviço de cluster no kernel, uma vez para cada nó:

      cluster kernel-service show

      O sistema exibe uma mensagem semelhante ao seguinte exemplo:

    cluster::*> cluster kernel-service show
    
    Master        Cluster       Quorum        Availability  Operational
    Node          Node          Status        Status        Status
    ------------- ------------- ------------- ------------- -------------
    node1         node1         in-quorum     true          operational
                  node2         in-quorum     true          operational
    
    2 entries were displayed.

    +
    Os nós em um cluster estão no quórum quando uma maioria simples dos nós está saudável e pode se comunicar uns com os outros. Para obter mais informações, consulte o "Referências"link para a Referência de Administração do sistema.

    1. Voltar ao nível de privilégio administrativo:

      set -privilege admin

  25. Execute uma das seguintes ações:

    Se o cluster…​ Então…​

    Possui SAN configurada

    Vá para Passo 26.

    Não tem SAN configurada

    Vá para Passo 29.

  26. Verifique se existem LIFs SAN no node1 e node2 para cada SVM que tenha um serviço SAN iSCSI ou FC habilitado digitando o seguinte comando e examinando sua saída:

    network interface show -data-protocol iscsi|fcp -home-node node_name

    O comando exibe informações de SAN LIF para node1 e node2. Os exemplos a seguir mostram o status na coluna Admin/Oper de Status como up/up, indicando que o serviço SAN iSCSI e FC estão ativados:

    cluster::> network interface show -data-protocol iscsi|fcp
                Logical    Status     Network                  Current   Current Is
    Vserver     Interface  Admin/Oper Address/Mask             Node      Port    Home
    ----------- ---------- ---------- ------------------       --------- ------- ----
    a_vs_iscsi  data1      up/up      10.228.32.190/21         node1     e0a     true
                data2      up/up      10.228.32.192/21         node2     e0a     true
    
    b_vs_fcp    data1      up/up      20:09:00:a0:98:19:9f:b0  node1     0c      true
                data2      up/up      20:0a:00:a0:98:19:9f:b0  node2     0c      true
    
    c_vs_iscsi_fcp data1   up/up      20:0d:00:a0:98:19:9f:b0  node2     0c      true
                data2      up/up      20:0e:00:a0:98:19:9f:b0  node2     0c      true
                data3      up/up      10.228.34.190/21         node2     e0b     true
                data4      up/up      10.228.34.192/21         node2     e0b     true

    Como alternativa, você pode visualizar informações mais detalhadas de LIF digitando o seguinte comando:

    network interface show -instance -data-protocol iscsi|fcp

  27. Capture a configuração padrão de qualquer porta FC nos nós originais inserindo o seguinte comando e gravando a saída para seus sistemas:

    ucadmin show

    O comando exibe informações sobre todas as portas FC no cluster, como mostrado no exemplo a seguir:

    cluster::> ucadmin show
    
                    Current Current   Pending Pending   Admin
    Node    Adapter Mode    Type      Mode    Type      Status
    ------- ------- ------- --------- ------- --------- -----------
    node1   0a      fc      initiator -       -         online
    node1   0b      fc      initiator -       -         online
    node1   0c      fc      initiator -       -         online
    node1   0d      fc      initiator -       -         online
    node2   0a      fc      initiator -       -         online
    node2   0b      fc      initiator -       -         online
    node2   0c      fc      initiator -       -         online
    node2   0d      fc      initiator -       -         online
    8 entries were displayed.

    Você pode usar as informações após a atualização para definir a configuração de portas FC nos novos nós.

  28. Se você estiver atualizando um sistema da série V ou um sistema com o software de virtualização FlexArray, capture informações sobre a topologia dos nós originais inserindo o seguinte comando e registrando a saída:

    storage array config show -switch

    O sistema exibe informações de topologia, como mostra no exemplo a seguir:

    cluster::> storage array config show -switch
    
          LUN LUN                                  Target Side Initiator Side Initi-
    Node  Grp Cnt Array Name    Array Target Port  Switch Port Switch Port    ator
    ----- --- --- ------------- ------------------ ----------- -------------- ------
    node1 0   50  I_1818FAStT_1
                                205700a0b84772da   vgbr6510a:5  vgbr6510s164:3  0d
                                206700a0b84772da   vgbr6510a:6  vgbr6510s164:4  2b
                                207600a0b84772da   vgbr6510b:6  vgbr6510s163:1  0c
    node2 0   50  I_1818FAStT_1
                                205700a0b84772da   vgbr6510a:5  vgbr6510s164:1  0d
                                206700a0b84772da   vgbr6510a:6  vgbr6510s164:2  2b
                                207600a0b84772da   vgbr6510b:6  vgbr6510s163:3  0c
                                208600a0b84772da   vgbr6510b:5  vgbr6510s163:4  2a
    7 entries were displayed.
  29. conclua as seguintes subetapas:

    1. Digite o seguinte comando em um dos nós originais e Registre a saída:

      service-processor show -node * -instance

    O sistema exibe informações detalhadas sobre o SP em ambos os nós.

    1. Confirmar se o estado SP é online.

    2. Confirme se a rede SP está configurada.

    3. Registre o endereço IP e outras informações sobre o SP.

      Talvez você queira reutilizar os parâmetros de rede dos dispositivos de gerenciamento remoto, neste caso o SPS, do sistema original para o SPS nos novos nós. Para obter informações detalhadas sobre o SP, "Referências"consulte o link para o Referência de Administração do sistema e os comandos ONTAP 9: Referência de página manual.

  30. se você quiser que os novos nós tenham a mesma funcionalidade licenciada que os nós originais, digite o seguinte comando para ver as licenças de cluster no sistema original:

    system license show -owner *

    O exemplo a seguir mostra as licenças do site para cluster1:

    system license show -owner *
    Serial Number: 1-80-000013
    Owner: cluster1
    
    Package           Type    Description           Expiration
    ----------------- ------- --------------------- -----------
    Base              site    Cluster Base License  -
    NFS               site    NFS License           -
    CIFS              site    CIFS License          -
    SnapMirror        site    SnapMirror License    -
    FlexClone         site    FlexClone License     -
    SnapVault         site    SnapVault License     -
    6 entries were displayed.
  31. Obtenha novas chaves de licença para os novos nós no site de suporte NetApp. Consulte o "Referências"link para Site de suporte da NetApp.

    Se o site não tiver as chaves de licença necessárias, entre em Contato com o representante de vendas da NetApp.

  32. Verifique se o sistema original tem o AutoSupport ativado inserindo o seguinte comando em cada nó e examinando sua saída:

    system node autosupport show -node node1,node2

    O comando output mostra se o AutoSupport está habilitado, como mostrado no exemplo a seguir:

    cluster::> system node autosupport show -node node1,node2
    
    Node             State     From          To                Mail Hosts
    ---------------- --------- ------------- ----------------  ----------
    node1            enable    Postmaster    admin@netapp.com  mailhost
    
    node2            enable    Postmaster    -                 mailhost
    2 entries were displayed.
  33. Execute uma das seguintes ações:

    Se o sistema original…​ Então…​

    Tem AutoSupport ativado…​

    Vá para Passo 34.

    Não tem AutoSupport ativado…​

    Ative o AutoSupport seguindo as instruções em Referência de administração do sistema. (Consulte a "Referências"ligação à Referência da Administração do sistema.)

    Nota: o AutoSupport é ativado por padrão quando você configura o sistema de armazenamento pela primeira vez. Embora você possa desativar o AutoSupport a qualquer momento, você deve deixá-lo habilitado. Ativar o AutoSupport pode ajudar a identificar problemas e soluções de forma significativa em caso de problema no sistema de storage.

  34. Verifique se o AutoSupport está configurado com os detalhes corretos do host de e-mail e IDs do destinatário inserindo o seguinte comando em ambos os nós originais e examinando a saída:

    system node autosupport show -node node_name -instance

    Para obter informações detalhadas sobre o AutoSupport, "Referências"consulte o link para o Referência de Administração do sistema e os comandos ONTAP 9: Referência de página manual.

  35. Envie uma mensagem AutoSupport para o NetApp para node1 digitando o seguinte comando:

    system node autosupport invoke -node node1 -type all -message "Upgrading node1 from platform_old to platform_new"

    Observação Não envie uma mensagem AutoSupport para o NetApp para node2 neste momento; você o faz mais tarde no procedimento.
  36. Verifique se a mensagem AutoSupport foi enviada inserindo o seguinte comando e examinando sua saída:

    system node autosupport show -node node1 -instance

    Os Last Subject Sent: campos e Last Time Sent: contêm o título da mensagem da última mensagem enviada e a hora em que a mensagem foi enviada.

  37. Se o seu sistema utilizar unidades de encriptação automática, consulte o artigo da base de dados de Conhecimento "Como saber se uma unidade tem certificação FIPS" para determinar o tipo de unidades de encriptação automática que estão a ser utilizadas no par de HA que está a atualizar. O software ONTAP é compatível com dois tipos de unidades com autocriptografia:

    • Unidades SAS ou NVMe com criptografia de storage NetApp (NSE) com certificação FIPS

    • Unidades NVMe com autocriptografia (SED) não FIPS

    Observação

    Não é possível combinar unidades FIPS com outros tipos de unidades no mesmo nó ou par de HA.

    É possível misturar SEDs com unidades sem criptografia no mesmo nó ou par de HA.