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.

Atualização manual de ONTAP sem interrupções usando a CLI (configurações padrão)

Colaboradores
PDFs

A atualização automatizada usando o System Manager é o método de atualização preferido. Se o Gerenciador do sistema não oferecer suporte à sua configuração, você poderá usar a interface de linha de comando (CLI) do ONTAP para realizar uma atualização manual sem interrupções. Para atualizar um cluster de dois ou mais nós usando o método sem interrupções manual, você deve iniciar uma operação de failover em cada nó em um par de HA, atualizar o nó com falha, iniciar o giveback e repetir o processo para cada par de HA no cluster.

Antes de começar

Você precisa ter requisitos de atualização satisfeitos"preparação".

Atualizando o primeiro nó em um par de HA

Você pode atualizar o primeiro nó em um par de HA iniciando um takeover pelo parceiro do nó. O parceiro atende os dados do nó enquanto o primeiro nó é atualizado.

Se você estiver executando uma grande atualização, o primeiro nó a ser atualizado deve ser o mesmo nó no qual você configurou as LIFs de dados para conetividade externa e instalou a primeira imagem ONTAP.

Depois de atualizar o primeiro nó, você deve atualizar o nó do parceiro o mais rápido possível. Não permita que os dois nós permaneçam em um "versão mista" estado por mais tempo do que o necessário.

Passos

  1. Atualize o primeiro nó no cluster invocando uma mensagem AutoSupport:

    autosupport invoke -node * -type all -message "Starting_NDU"

    Esta notificação do AutoSupport inclui um registo do estado do sistema imediatamente antes da atualização. Ele salva informações úteis de solução de problemas no caso de haver um problema com o processo de atualização.

    Se o cluster não estiver configurado para enviar mensagens AutoSupport, uma cópia da notificação será salva localmente.

  2. Defina o nível de privilégio como avançado, inserindo y quando solicitado a continuar:

    set -privilege advanced

    (`*>`É apresentado o aviso avançado ).

  3. Defina a nova imagem do software ONTAP para ser a imagem padrão:

    system image modify {-node nodenameA -iscurrent false} -isdefault true

    O comando System Image Modify (modificar imagem do sistema) usa uma consulta estendida para alterar a nova imagem do software ONTAP (que é instalada como imagem alternativa) para a imagem padrão do nó.

  4. Monitorize o progresso da atualização:

    system node upgrade-revert show

  5. Verifique se a nova imagem do software ONTAP está definida como a imagem padrão:

    system image show

    No exemplo a seguir, image2 é a nova versão do ONTAP e é definida como a imagem padrão no node0:

    cluster1::*> system image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   true    X.X.X     MM/DD/YYYY TIME
         image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  true    true    X.X.X     MM/DD/YYYY TIME
         image2  false   false   Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  6. Desative o giveback automático no nó do parceiro se estiver ativado:

    storage failover modify -node nodenameB -auto-giveback false

    Se o cluster for um cluster de dois nós, uma mensagem é exibida avisando que a desativação automática da giveback impede que os serviços do cluster de gerenciamento fiquem on-line em caso de falha alternada. Entre y para continuar.

  7. Verifique se o giveback automático está desativado para o parceiro do nó:

    storage failover show -node nodenameB -fields auto-giveback
    cluster1::> storage failover show -node node1 -fields auto-giveback
node     auto-giveback
-------- -------------
node1    false
1 entry was displayed.

  8. Execute o comando a seguir duas vezes para determinar se o nó a ser atualizado está atendendo a qualquer cliente no momento

    system node run -node nodenameA -command uptime

    O comando uptime exibe o número total de operações que o nó executou para clientes NFS, SMB, FC e iSCSI desde que o nó foi inicializado pela última vez. Para cada protocolo, você deve executar o comando duas vezes para determinar se as contagens de operação estão aumentando. Se eles estão aumentando, o nó está atendendo clientes para esse protocolo no momento. Se eles não estiverem aumentando, o nó não estará atendendo clientes para esse protocolo.

    Observação Você deve fazer uma nota de cada protocolo que tem operações de cliente crescentes para que, após o nó ser atualizado, você possa verificar se o tráfego de cliente foi retomado.

    O exemplo a seguir mostra um nó com operações NFS, SMB, FC e iSCSI. No entanto, o nó está atualmente atendendo apenas clientes NFS e iSCSI.

    cluster1::> system node run -node node0 -command uptime
  2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

cluster1::> system node run -node node0 -command uptime
  2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

  9. Migre todos os LIFs de dados para fora do nó:

    network interface migrate-all -node nodenameA

  10. Verifique quaisquer LIFs que você migrou:

    network interface show

    Para obter mais informações sobre os parâmetros que você pode usar para verificar o status de LIF, consulte a página de manual da interface de rede show.

    O exemplo a seguir mostra que LIFs de dados do node0 migraram com sucesso. Para cada LIF, os campos incluídos neste exemplo permitem verificar o nó e a porta inicial do LIF, o nó e a porta atuais para a qual o LIF migrou e o status operacional e administrativo do LIF.

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node0 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
vserver lif     home-node home-port curr-node curr-port status-oper status-admin
------- ------- --------- --------- --------- --------- ----------- ------------
vs0     data001 node0     e0a       node1     e0a       up          up
vs0     data002 node0     e0b       node1     e0b       up          up
vs0     data003 node0     e0b       node1     e0b       up          up
vs0     data004 node0     e0a       node1     e0a       up          up
4 entries were displayed.

  11. Iniciar uma aquisição:

    storage failover takeover -ofnode nodenameA

    Não especifique o parâmetro -option immediate, porque um controle normal é necessário para o nó que está sendo levado para inicializar na nova imagem de software. Se você não migrar manualmente as LIFs para longe do nó, elas migrarão automaticamente para o parceiro de HA do nó para garantir que não haja interrupções no serviço.

    O primeiro nó inicializa até o estado de espera para giveback.

    Observação Se o AutoSupport estiver habilitado, uma mensagem AutoSupport será enviada indicando que o nó está fora do quórum do cluster. Pode ignorar esta notificação e prosseguir com a atualização.

  12. Verifique se a aquisição foi bem-sucedida:

    storage failover show

    Você pode ver mensagens de erro indicando incompatibilidade de versão e problemas de formato da caixa postal. Esse é um comportamento esperado e representa um estado temporário em uma grande atualização sem interrupções e não é prejudicial.

    O exemplo a seguir mostra que a aquisição foi bem-sucedida. O nó node0 está em espera para o estado de giveback, e seu parceiro está no estado de aquisição.

    cluster1::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node0          node1          -        Waiting for giveback (HA mailboxes)
node1          node0          false    In takeover
2 entries were displayed.

  13. Aguarde pelo menos oito minutos para que as seguintes condições entrem em vigor:

    • O multipathing do cliente (se implantado) está estabilizado.

    • Os clientes são recuperados da pausa em uma operação de e/S que ocorre durante a aquisição.

      O tempo de recuperação é específico do cliente e pode demorar mais de oito minutos, dependendo das caraterísticas dos aplicativos cliente.

  14. Retorne os agregados ao primeiro nó:

    storage failover giveback -ofnode nodenameA

    O giveback primeiro retorna o agregado raiz para o nó do parceiro e, depois que esse nó terminar a inicialização, retorna os agregados não-raiz e quaisquer LIFs que foram definidos para reverter automaticamente. O nó recém-inicializado começa a servir dados para clientes de cada agregado assim que o agregado é retornado.

  15. Verifique se todos os agregados foram devolvidos:

    storage failover show-giveback

    Se o campo Status do Giveback indicar que não há agregados para devolver, todos os agregados foram retornados. Se o giveback for vetado, o comando exibirá o progresso da giveback e qual subsistema vetou a giveback.

  16. Se algum agregado não tiver sido retornado, execute as seguintes etapas:

    1. Revise a solução alternativa de veto para determinar se você deseja abordar a condição "para" ou substituir o veto.

    2. Se necessário, aborde a condição "para" descrita na mensagem de erro, garantindo que todas as operações identificadas sejam terminadas graciosamente.

    3. Execute novamente o comando Storage failover giveback.

      Se você decidiu substituir a condição "para", defina o parâmetro -override-vetos como true.

  17. Aguarde pelo menos oito minutos para que as seguintes condições entrem em vigor:

    • O multipathing do cliente (se implantado) está estabilizado.

    • Os clientes são recuperados da pausa em uma operação de e/S que ocorre durante a giveback.

      O tempo de recuperação é específico do cliente e pode demorar mais de oito minutos, dependendo das caraterísticas dos aplicativos cliente.

  18. Verifique se a atualização foi concluída com sucesso para o nó:

    1. Vá para o nível de privilégio avançado :

      set -privilege advanced

    2. Verifique se o status da atualização está concluído para o nó:

      system node upgrade-revert show -node nodenameA

      O status deve ser listado como completo.

    Se o estado não estiver completo, contactar a assistência técnica.

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

      set -privilege admin

  19. Verifique se as portas do nó estão ativas:

    network port show -node nodenameA

    Você deve executar este comando em um nó que é atualizado para a versão superior do ONTAP 9.

    O exemplo a seguir mostra que todas as portas do nó estão ativas:

    cluster1::> network port show -node node0
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
node0
       e0M       Default      -                up       1500  auto/100
       e0a       Default      -                up       1500  auto/1000
       e0b       Default      -                up       1500  auto/1000
       e1a       Cluster      Cluster          up       9000  auto/10000
       e1b       Cluster      Cluster          up       9000  auto/10000
5 entries were displayed.

  20. Reverter os LIFs de volta para o nó:

    network interface revert *

    Este comando retorna os LIFs que foram migrados para longe do nó.

    cluster1::> network interface revert *
8 entries were acted on.

  21. Verifique se as LIFs de dados do nó reverteram com êxito de volta para o nó e se eles estão ativos:

    network interface show

    O exemplo a seguir mostra que todas as LIFs de dados hospedadas pelo nó foram revertidas com êxito de volta para o nó e que seu status operacional está ativo:

    cluster1::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data001      up/up    192.0.2.120/24     node0         e0a     true
            data002      up/up    192.0.2.121/24     node0         e0b     true
            data003      up/up    192.0.2.122/24     node0         e0b     true
            data004      up/up    192.0.2.123/24     node0         e0a     true
4 entries were displayed.

  22. Se você determinou anteriormente que esse nó serve clientes, verifique se o nó está fornecendo serviço para cada protocolo que ele estava fornecendo anteriormente:

    system node run -node nodenameA -command uptime

    As contagens de operação repostas para zero durante a atualização.

    O exemplo a seguir mostra que o nó atualizado foi retomado servindo seus clientes NFS e iSCSI:

    cluster1::> system node run -node node0 -command uptime
  3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops

  23. Reative o giveback automático no nó do parceiro se ele tiver sido desativado anteriormente:

    storage failover modify -node nodenameB -auto-giveback true

Você deve continuar a atualizar o parceiro de HA do nó o mais rápido possível. Se você precisar suspender o processo de atualização por qualquer motivo, ambos os nós do par de HA deverão estar executando a mesma versão do ONTAP.

Atualizando o nó de parceiro em um par de HA

Depois de atualizar o primeiro nó em um par de HA, você atualiza o parceiro iniciando um takeover nele. O primeiro nó serve os dados do parceiro enquanto o nó do parceiro é atualizado.

  1. Defina o nível de privilégio como avançado, inserindo y quando solicitado a continuar:

    set -privilege advanced

    (`*>`É apresentado o aviso avançado ).

  2. Defina a nova imagem do software ONTAP para ser a imagem padrão:

    system image modify {-node nodenameB -iscurrent false} -isdefault true

    O comando System Image Modify usa uma consulta estendida para alterar a nova imagem do software ONTAP (que é instalada como a imagem alternativa) para ser a imagem padrão do nó.

  3. Monitorize o progresso da atualização:

    system node upgrade-revert show

  4. Verifique se a nova imagem do software ONTAP está definida como a imagem padrão:

    system image show

    No exemplo a seguir image2, está a nova versão do ONTAP e é definida como a imagem padrão no nó:

    cluster1::*> system image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  false   true    X.X.X     MM/DD/YYYY TIME
         image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  5. Desative o giveback automático no nó do parceiro se estiver ativado:

    storage failover modify -node nodenameA -auto-giveback false

    Se o cluster for um cluster de dois nós, uma mensagem é exibida avisando que a desativação automática da giveback impede que os serviços do cluster de gerenciamento fiquem on-line em caso de falha alternada. Entre y para continuar.

  6. Verifique se o giveback automático está desativado para o nó do parceiro:

    storage failover show -node nodenameA -fields auto-giveback
    cluster1::> storage failover show -node node0 -fields auto-giveback
node     auto-giveback
-------- -------------
node0    false
1 entry was displayed.

  7. Execute o seguinte comando duas vezes para determinar se o nó a ser atualizado está atendendo a qualquer cliente no momento:

    system node run -node nodenameB -command uptime

    O comando uptime exibe o número total de operações que o nó executou para clientes NFS, SMB, FC e iSCSI desde que o nó foi inicializado pela última vez. Para cada protocolo, você deve executar o comando duas vezes para determinar se as contagens de operação estão aumentando. Se eles estão aumentando, o nó está atendendo clientes para esse protocolo no momento. Se eles não estiverem aumentando, o nó não estará atendendo clientes para esse protocolo.

    Observação Você deve fazer uma nota de cada protocolo que tem operações de cliente crescentes para que, após o nó ser atualizado, você possa verificar se o tráfego de cliente foi retomado.

    O exemplo a seguir mostra um nó com operações NFS, SMB, FC e iSCSI. No entanto, o nó está atualmente atendendo apenas clientes NFS e iSCSI.

    cluster1::> system node run -node node1 -command uptime
  2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

cluster1::> system node run -node node1 -command uptime
  2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

  8. Migre todos os LIFs de dados para fora do nó:

    network interface migrate-all -node nodenameB

  9. Verifique o status de quaisquer LIFs que você migrou:

    network interface show

    Para obter mais informações sobre os parâmetros que você pode usar para verificar o status de LIF, consulte a página de manual da interface de rede show.

    O exemplo a seguir mostra que LIFs de dados do node1 migraram com sucesso. Para cada LIF, os campos incluídos neste exemplo permitem verificar o nó e a porta inicial do LIF, o nó e a porta atuais para a qual o LIF migrou e o status operacional e administrativo do LIF.

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node1 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
vserver lif     home-node home-port curr-node curr-port status-oper status-admin
------- ------- --------- --------- --------- --------- ----------- ------------
vs0     data001 node1     e0a       node0     e0a       up          up
vs0     data002 node1     e0b       node0     e0b       up          up
vs0     data003 node1     e0b       node0     e0b       up          up
vs0     data004 node1     e0a       node0     e0a       up          up
4 entries were displayed.

  10. Iniciar uma aquisição:

    storage failover takeover -ofnode nodenameB -option allow-version-mismatch

    Não especifique o parâmetro -option immediate, porque um controle normal é necessário para o nó que está sendo levado para inicializar na nova imagem de software. Se você não tiver migrado manualmente os LIFs para fora do nó, eles migrarão automaticamente para o parceiro de HA do nó para que não haja interrupções no serviço.

    É apresentado um aviso. Tem de introduzir y para continuar.

    O nó que é tomado sobre arranca até o estado de espera para giveback.

    Observação Se o AutoSupport estiver habilitado, uma mensagem AutoSupport será enviada indicando que o nó está fora do quórum do cluster. Pode ignorar esta notificação e prosseguir com a atualização.

  11. Verifique se a aquisição foi bem-sucedida:

    storage failover show

    O exemplo a seguir mostra que a aquisição foi bem-sucedida. O nó node1 está em espera para o estado de giveback, e seu parceiro está no estado de aquisição.

    cluster1::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node0          node1          -        In takeover
node1          node0          false    Waiting for giveback (HA mailboxes)
2 entries were displayed.

  12. Aguarde pelo menos oito minutos para que as seguintes condições entrem em vigor

    • O multipathing do cliente (se implantado) está estabilizado.

    • Os clientes são recuperados da pausa na I/o que ocorre durante a aquisição.

      O tempo de recuperação é específico do cliente e pode demorar mais de oito minutos, dependendo das caraterísticas dos aplicativos cliente.

  13. Retorno dos agregados para o nó de parceiro:

    storage failover giveback -ofnode nodenameB

    A operação de giveback primeiro retorna o agregado raiz para o nó do parceiro e, depois que esse nó tiver terminado a inicialização, retorna os agregados não-raiz e quaisquer LIFs que foram definidos para reverter automaticamente. O nó recém-inicializado começa a servir dados para clientes de cada agregado assim que o agregado é retornado.

  14. Verifique se todos os agregados são devolvidos:

    storage failover show-giveback

    Se o campo Status do Giveback indicar que não há agregados para devolver, todos os agregados serão retornados. Se o giveback for vetado, o comando exibirá o progresso da giveback e qual subsistema vetou a operação da giveback.

  15. Se algum agregado não for retornado, execute as seguintes etapas:

    1. Revise a solução alternativa de veto para determinar se você deseja abordar a condição "para" ou substituir o veto.

    2. Se necessário, aborde a condição "para" descrita na mensagem de erro, garantindo que todas as operações identificadas sejam terminadas graciosamente.

    3. Execute novamente o comando Storage failover giveback.

      Se você decidiu substituir a condição "para", defina o parâmetro -override-vetos como true.

  16. Aguarde pelo menos oito minutos para que as seguintes condições entrem em vigor:

    • O multipathing do cliente (se implantado) está estabilizado.

    • Os clientes são recuperados da pausa em uma operação de e/S que ocorre durante a giveback.

      O tempo de recuperação é específico do cliente e pode demorar mais de oito minutos, dependendo das caraterísticas dos aplicativos cliente.

  17. Verifique se a atualização foi concluída com sucesso para o nó:

    1. Vá para o nível de privilégio avançado :

      set -privilege advanced

    2. Verifique se o status da atualização está concluído para o nó:

      system node upgrade-revert show -node nodenameB

      O status deve ser listado como completo.

    Se o status não estiver concluído, a partir do nó, execute o system node upgrade-revert upgrade comando. Se o comando não concluir a atualização, entre em Contato com o suporte técnico.

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

      set -privilege admin

  18. Verifique se as portas do nó estão ativas:

    network port show -node nodenameB

    Você deve executar este comando em um nó que foi atualizado para ONTAP 9.4.

    O exemplo a seguir mostra que todas as portas de dados do nó estão ativas:

    cluster1::> network port show -node node1
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
node1
       e0M       Default      -                up       1500  auto/100
       e0a       Default      -                up       1500  auto/1000
       e0b       Default      -                up       1500  auto/1000
       e1a       Cluster      Cluster          up       9000  auto/10000
       e1b       Cluster      Cluster          up       9000  auto/10000
5 entries were displayed.

  19. Reverter os LIFs de volta para o nó:

    network interface revert *

    Este comando retorna os LIFs que foram migrados para longe do nó.

    cluster1::> network interface revert *
8 entries were acted on.

  20. Verifique se as LIFs de dados do nó reverteram com êxito de volta para o nó e se eles estão ativos:

    network interface show

    O exemplo a seguir mostra que todas as LIFs de dados hospedadas pelo nó são revertidas com êxito de volta para o nó e que seu status operacional está ativo:

    cluster1::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data001      up/up    192.0.2.120/24     node1         e0a     true
            data002      up/up    192.0.2.121/24     node1         e0b     true
            data003      up/up    192.0.2.122/24     node1         e0b     true
            data004      up/up    192.0.2.123/24     node1         e0a     true
4 entries were displayed.

  21. Se você determinou anteriormente que esse nó serve clientes, verifique se o nó está fornecendo serviço para cada protocolo que ele estava fornecendo anteriormente:

    system node run -node nodenameB -command uptime

    As contagens de operação repostas para zero durante a atualização.

    O exemplo a seguir mostra que o nó atualizado foi retomado servindo seus clientes NFS e iSCSI:

    cluster1::> system node run -node node1 -command uptime
  3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops

  22. Se este foi o último nó no cluster a ser atualizado, acione uma notificação do AutoSupport:

    autosupport invoke -node * -type all -message "Finishing_NDU"

    Esta notificação do AutoSupport inclui um registo do estado do sistema imediatamente antes da atualização. Ele salva informações úteis de solução de problemas no caso de haver um problema com o processo de atualização.

    Se o cluster não estiver configurado para enviar mensagens AutoSupport, uma cópia da notificação será salva localmente.

  23. Confirme se o novo software ONTAP está em execução em ambos os nós do par de HA:

    set -privilege advanced
    system node image show

    No exemplo a seguir, image2 é a versão atualizada do ONTAP e é a versão padrão em ambos os nós:

    cluster1::*> system node image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  24. Reative o giveback automático no nó do parceiro se ele tiver sido desativado anteriormente:

    storage failover modify -node nodenameA -auto-giveback true

  25. Verifique se o cluster está no quórum e se os serviços estão sendo executados usando os cluster show comandos e cluster ring show (nível avançado de privilégio).

    Você deve executar esta etapa antes de atualizar quaisquer pares de HA adicionais.

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

    set -privilege admin

  27. Atualizar quaisquer pares de HA adicionais.