Atualização o do sistema

O processo de atualização do sistema envolve o atualização de seu ambiente inteiro do ambiente do sistema.

Comece aqui a atualizar para a versão 8.1.0 ou posterior da versão 7.7.0 ou posterior.

Se você estiver atualizando a partir de uma liberação anterior à versão 7.7.0, siga as instruções nessa liberação anterior.

Atenção: Se você encontrar uma falha de memória DIMM para qualquer nó durante o processo de atualização, pare imediatamente. Siga este procedimento para assegurar uma atualização bem-sucedida:

Substitua o DIMM no nó com falha.
Remova o nó que tem a falha de DIMM do sistema:
```
svctask rmnode object_id | object_name
```
Verifique o status dos nós restantes no sistema e o status de atualização:
```
svcinfo lssoftwareupgradestatus
```
Se o nó do parceiro estiver ativo e o status de atualização do sistema for atualizando, ocorrerá atualização do nó no modo de serviço e incluído de volta no sistema:
```
svctask addnode
```
Consulte as informações do comando addnode para obter as possíveis sinalizações. A atualização continua.
Se o nó do parceiro estiver ativo e o status de atualização do sistema for stalled, decida se deseja concluir a atualização (rollforward) ou cancelar (retrocesso). Sua decisão é parcialmente baseada no progresso da sua atualização até o momento em que ocorreu a falha. É possível executar rollforward com uma estratégia de atualização de serviço ou remoção do nó (comando rmnode).
- Execute rollforward (serviço atualização): para concluir manualmente o atualização, use um processo de modo de serviço do atualização para atualização os nós de nível inferior restantes. Depois que todos os nós estiverem sendo executados no mesmo nível, a atualização será confirmada.
- Executar rollforward (comando rmnode): use o procedimento de comando rmnode somente se a atualização tiver uma porcentagem de conclusão de 50% ou mais.
- Retroceder (cancelar a atualização):
```
 svctask applysoftware -abort -force
```
  O parâmetro -force será obrigatório se um ou mais nós estiverem offline.
  Importante: O uso do parâmetro -force pode resultar na perda do acesso. Escolha essa opção somente se o nó do parceiro (de seu nó offline) estiver no nível de código original.
  Os nós Updated são retrocedidos para o nível de software original, um nó por vez.
Verifique se todos os nós estão ativos e executando o mesmo firmware.
Insira o seguinte comando:
```
svcconfig backup
```
Verifique o funcionamento do sistema.

Para obter as informações mais recentes sobre restrições antes da atualização, consulte o seguinte site:

http://www.ibm.com/support/docview.wss?uid=ssg1S1001707

Reserve até uma semana para planejar suas tarefas, passar por suas tarefas preparatórias de atualização e concluir a atualização do ambiente do sistema. Os procedimentos de atualização podem ser divididos em processos gerais que são mostrados na Tabela 1.

Tabela 1. Tarefas de Atualização
Sequência	Tarefa de Atualização
1	Antes da atualização, familiarize-se com os pré-requisitos e as tarefas envolvidas. Durante o procedimento de atualização automática, o sistema em cluster atualiza cada um dos nós sistematicamente. Decida se deseja atualização automaticamente ou atualização manualmente. Durante um procedimento de atualização automático, o sistema em cluster atualizações cada um dos nós sistematicamente. O método automático é o procedimento preferencial para atualização software nos nós. No entanto, também é possível atualização cada nó manualmente.
2	Assegure-se de que os clientes do gerenciador de objeto CIM (CIMOM) estejam funcionando corretamente. Quando necessário, atualização esses clientes para que eles possam suportar a nova versão de código do sistema.
3	Assegure-se de que os drivers de caminhos múltiplos no ambiente são totalmente redundantes.
4	Atualização seu sistema. A atualização do sistema inclui atualizações de firmware do componente. A atualização do firmware da unidade é um processo separado.
5	Atualização outros dispositivos no ambiente do sistema. Os exemplos podem incluir atualização hosts e comutadores para os níveis corretos.
Nota: A quantidade de tempo pode variar dependendo da quantidade de trabalho de preparação que é necessária e o tamanho do ambiente. Para atualização automática, leva aproximadamente 20 minutos para cada nó mais 30 minutos para cada sistema. O intervalo de 30 minutos fornece tempo para o software de caminhos múltiplos se recuperar.

Atenção: Se você tiver problemas com suporte a failover do driver de caminhos múltiplos, resolva esses problemas antes de iniciar operações normais.

Firmware e software para o sistema e seus adaptadores conectados são testados e liberados como um único pacote. O número de pacote aumenta sempre que uma nova liberação for feita.

Alguns níveis de código suportam atualizações somente a partir de níveis anteriores específicos ou o código pode ser instalado somente em determinados tipos de hardware. Se você fizer a atualização para mais de um nível acima do nível atual, poderá ser obrigado a instalar um nível intermediário. Por exemplo, se estiver atualização do nível 1 para o nível 3, talvez seja necessário instalar o nível 2 para poder instalar o 3. Para obter mais informações sobre os pré-requisitos de cada nível de código, consulte este website:

www.ibm.com/support

Atenção: Assegure-se de que não há erros sem correção no log e que a data e hora do sistema estão configuradas corretamente. Inicie os procedimentos de correção e assegure-se de corrigir quaisquer erros pendentes antes de tentar atualização o código simultaneamente.

Nota: Uma vez concluída a atualização do software do sistema, a função Fibre Channel over Ethernet (FCoE) pode ser ativada em cada nó, seguindo os procedimentos de correção para esses eventos usando o GUI de gerenciamento. O procedimento de ativação de FCoE envolve uma reinicialização do nó. Deixe tempo para que caminhos múltiplos do host se recuperarem entre a ativação de nós diferentes no mesmo grupo de E/S.

O processo de atualização

Durante o processo de atualização automática, cada nó em um sistema é atualizado, um por vez, e o novo código é colocado temporariamente nos nós. Enquanto cada nó é reiniciado, poderá haver alguma degradação da taxa máxima de E/S que pode ser sustentada pelo sistema. Depois que todos os nós no sistema forem reiniciados com sucesso com o novo nível de código, o novo nível será confirmado automaticamente.

Durante uma atualização automática de código, cada nó de um par de trabalho é atualizado sequencialmente. O nó que está sendo atualizado fica temporariamente indisponível e todas as operações de E/S para esse nó falham. Como resultado, o erro de E/S conta um aumento e as operações de E/S com falha são direcionadas ao nó do parceiro do par de trabalho. Os aplicativos não veem quaisquer falhas de E/S. Quando novos nós são incluídos no sistema, o pacote de atualização é automaticamente transferido por download para os novos nós do .

A atualização normalmente pode ser feita simultaneamente com operações de E/S normais do usuário. Entretanto, o desempenho pode ser afetado. Se quaisquer restrições se aplicarem às operações que podem ser feitas durante a atualização, essas restrições serão documentadas no website do produto que você usa para transferir por download os pacotes de atualização. Durante o procedimento atualização, a maioria dos comandos de configuração não está disponível. Somente os seguintes comandos estão operacionais do momento em que o processo de atualização começa até o momento em que o novo nível de código é confirmado ou até que o processo seja restaurado:

Todos os comandos de informações
O comando rmnode

Para determinar quando seu processo de atualização foi concluído, você será notificado por meio do GUI de gerenciamento. Se você estiver usando a interface da linha de comandos, emita o comando lsupdate para exibir o status do atualização.

Por causa das limitações operacionais que ocorrem durante o processo de atualização, a atualização de código é uma tarefa do usuário. No entanto, se você tiver problemas com uma atualização, entre em contato com o centro de suporte. Não tente solucionar problemas de atualização sem assistência técnica. Para obter mais instruções, consulte o tópico sobre como obter informações, ajuda e assistência técnica.

Driver de caminhos múltiplos

Antes da atualização, assegure-se de que o driver de caminhos múltiplos esteja totalmente redundante com cada caminho disponível e online. Talvez você veja erros relacionados aos caminhos que estão partindo (failover) e a contagem de erros aumentando durante a atualização. Quando os caminhos para os nós estiverem de volta, os nós retrocederão para se tornarem um sistema completamente redundante. Após o atraso de 30 minutos, os caminhos para outro nó ficarão inativos.

Se estiver usando o Driver de Dispositivo do Subsistema (SDD) IBM® ou Módulo Específico do Dispositivo do Driver de Dispositivo do Subsistema (SDDDSM) IBM como o software de caminhos múltiplos no host, as contagens de erro de E/S aumentadas serão exibidas pelos comandos datapath query device ou datapath query adapter para monitorar o estado do software de caminhos múltiplos. Para obter mais informações, consulte Guia do Usuário do IBM Multipath Subsystem Device Driver para obter mais informações sobre os comandos datapath query.

Se você estiver usando o IBM Subsystem Device Driver Path Control Module (SDDPCM) como o software de caminhos múltiplos no host, as contagens de erro de E/S maiores serão exibidas pelos comandos pcmpath query device ou pcmpath query adapter para monitorar o estado do software de caminhos múltiplos.

Relacionamentos de Metro Mirror e de Global Mirror

Quando você atualização um software em um sistema que tem volumes secundários de execução de relacionamentos do Metro Mirror ou Global Mirror, o desempenho da gravação pode ficar comprometido nos volumes primários e os relacionamentos do Global Mirror podem ser interrompidos automaticamente com um ou mais erros com o código de erro 1920. Talvez você deseje parar proativamente esses relacionamentos antes da atualização do software para evitar a degradação de desempenho de gravação e reiniciar os relacionamentos após a atualização ser concluída.

Com o sistema versão 6.4.0 ou mais recente, o suporte para quatro portas Fibre Channel e duas portas Fibre Channel over Ethernet (FCoE) foi ativado. Se um sistema contiver estas versões de software, não será possível estabelecer uma parceria de cópia remota com outro sistema que esteja executando uma versão de software anterior à 6.4.0. Se um sistema que executa 6.4.0 ou posterior possuir uma parceria de cópia remota existente com outro sistema que está executando uma versão de software anterior, não será possível incluir um nó com um total combinado de mais do que quatro portas Fibre Channel e FCoE. Também não é possível ativar mais portas (ativando FCoE ou instalando novo hardware) em nós existentes no sistema. Para resolver esses problemas, há duas opções:

Atualização o software no sistema remoto para 6.4.0 ou mais recente ou
Usar o comando chnodehw -legacy da CLI para desativar o hardware adicional em nós no sistema com 6.4.0 ou versão de software mais recente instalada

O parâmetro -legacy da CLI chnodehw controla a ativação e a desativação das portas FCoE.

Para ativar o hardware adicional, execute o seguinte comando da CLI:

chnodehw node id

Em que node_name | node_id (necessário) especifica o nó a ser modificado. A variável que segue o parâmetro pode ser:

O nome do nó que você designou quando incluiu o nó no sistema.
O ID de nó designado para o nó (não o nome universal do nó).

Para desativar o hardware adicional, execute o seguinte comando:

chnodehw -legacy software_level node_id

Em que software_level indica o nível de software com o qual o nó deve interoperar. Se o valor for menor que 6.4.0, o nó configurará seu hardware para suportar apenas um máximo de quatro portas FCoE ou Fibre Channel. E node_name | node_id (necessário) especifica o nó a ser modificado. A variável que segue o parâmetro pode ser:

O nome do nó designado ao incluir o nó ao sistema
O ID do nó que é designado ao nó (não o nome universal do nó)

Com suporte para seis portas (quatro portas Fibre Channel e duas FCoE) em cada nó com o código 6.4.0, as regras controlam como configurar uma parceria com um sistema pré-6.4.0.

Um sistema 6.4.0 não pode formar uma parceria com um sistema pré-6.4.0 com mais de 4 portas FC/FCoE I/O ativadas.
Por exemplo, uma configuração de parceria de multissistema entre três sistemas, A, B e C.
A <-> B<-> C
O Sistema A tem o pré-6.4.0 instalado e os sistemas B e C têm o 6.4.0 instalado.
Os serviços de cópia remota são possíveis nesta configuração somente se o Sistema B não possuir portas FCoE ativadas.
Parcerias entre sistemas A e B não são afetadas devido às portas FCoE ativadas em nós no sistema C.
Se um sistema 6.4.0 tiver uma parceria já estabelecida com um sistema pré-6.4.0 e se mais hardwares (quatro portas Fibre Channel e duas portas FCoE) forem ativados enquanto a parceria estiver interrompida, a parceria não poderá ser iniciada novamente até que o sistema remoto seja atualizado ou o hardware extra seja desativado usando o comando chnodehw -legacy.
Um nó com uma configuração de hardware mais antiga (incluindo um sistema que foi atualizado de 6.3.0 para 6.4.0 que possui adaptadores Ethernet de 10 Gb) pode gerar logs de eventos indicando que o novo hardware (a função FCoE) está disponível e deve ser ativado com o comando chnodehw. Se desejar continuar a operar parcerias de cópia remota com sistemas que estejam executando níveis de software mais antigos, deixe esse log de eventos sem correção.

Se o hardware adicional for ativado e uma parceria precisar ser estabelecida com um sistema que está executando um software anterior a 6.4, o hardware adicional deverá ser desativado primeiro usando o comando chnodehw -legacy software version (pre 6.4) node id.

Quando um nó for incluído em um sistema, o sistema verificará parcerias (iniciadas) e determinará o menor nível de software dos sistemas parceiros. Este nível de software é transmitido para o nó que está sendo incluído no sistema. O nó processa o equivalente de comando chnodehw -legacy software nível à medida que ele se junta ao sistema.

Após a atualização do sistema

O conteúdo do log de auditoria que estava no sistema antes da atualização é enviado para um arquivo no diretório /dumps/audit no nó de configuração. Agora, o log de auditoria possuirá um conteúdo que resulta de comandos executados após uma atualização bem-sucedida do sistema.