Atualizando o software do sistema

O processo de atualização do sistema envolve a atualização de seu ambiente do sistema inteiro. Esse processo pode envolver mudanças na memória e no software.

Comece aqui a atualizar para a versão 8.2.0 ou mais recente da versão 7.7.0 ou mais recente.

Se estiver atualizando de uma liberação anterior à versão 8.2.0, siga as instruções dessa liberação anterior.

Considerações de planejamento

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

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

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

Tabela 1. Atualizando Tarefas
Sequência	Atualizar tarefa
1	Antes de atualizar, familiarize-se com os pré-requisitos e tarefas envolvidos. Durante o procedimento de atualização automática, o sistema atualiza cada um dos nós sistematicamente. Decida se você deseja atualizar automaticamente ou manualmente. Durante um procedimento de atualização automática, o sistema atualiza cada um dos nós sistematicamente. O método automático é o procedimento preferencial para atualizar o software nos nós. No entanto, também é possível atualizar cada nó manualmente.
2	Assegure-se de que os clientes do gerenciador de objeto CIM (CIMOM) estejam funcionando corretamente. Quando necessário, atualize esses clientes para que eles possam suportar a nova versão do código do sistema.
3	Assegure-se de que os drivers de caminhos múltiplos no ambiente são totalmente redundantes.
4	Atualize 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	Atualize outros dispositivos no ambiente do sistema. Exemplos podem incluir atualização de hosts e alternações 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 que o software de caminhos múltiplos seja recuperado.

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 apenas de níveis anteriores específicos ou o código pode ser instalado somente em determinados tipos de hardware. Se você atualizar para mais de um nível acima do nível atual, poderá ser necessário instalar um nível intermediário. Por exemplo, se você estiver atualizando do nível 1 para o nível 3, poderá ser necessário instalar o nível 2 para poder instalar o nível 3. Para obter mais informações sobre os pré-requisitos para 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 atualizar o código simultaneamente.

Nota: Após a conclusão da atualização do software do sistema, a função Fibre Channel over Ethernet (FCoE) (se instalada) pode ser ativada em cada nó seguindo os procedimentos de correção para esses eventos usando a 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.

Multipathing Driver

Antes de atualizar, assegure-se de que o driver de caminhos múltiplos esteja completamente redundante com cada caminho disponível e on-line. Talvez ocorram erros que estão relacionados aos caminhos que vão embora (failover) e a contagem de erros aumenta durante a atualização. Quando os caminhos para os nós estão de volta, os nós retrocedem para se tornar um sistema completamente redundante. Depois do atraso de 30 minutos, ola caminhos para o outro nó ficam inativos.

Se você estiver usando o IBM® SDD (Subsystem Device Driver) ou IBM Subsystem Device Driver Device Specific Module (SDDDSM) como o software de caminhos múltiplos no host, as contagens de erro de E/S maiores 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 IBM Guia do usuário do driver de dispositivo do subsistema de caminhos múltiplos 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 aumentadas 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

Ao atualização o software em um sistema que possui volumes primários ou secundários de execução de relacionamentos do Metro Mirror ou do Global Mirror, o desempenho de gravação pode ser comprometido nos volumes primários e os relacionamentos do Global Mirror podem ser interrompidos automaticamente com um ou mais erros com código de erro 1920. Talvez você queira parar proativamente esses relacionamentos ou grupos de consistências ou a parceria antes de atualização o software para evitar que o desempenho de gravação seja comprometido e reiniciar os relacionamentos após a conclusão da atualização.

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 a versão 6.4.0 ou mais recente 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, então, o nó configurará o seu hardware para suportar apenas um máximo de quatro portas Fibre Channel ou FCoE. 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ó que você designou quando incluiu o nó para o 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 portas 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) estiverem 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ó é incluído em um sistema, o sistema verifica parcerias (iniciadas) e determina 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.

O processo de atualização

Durante o processo de atualização automática, cada nó em um sistema é atualizado um de cada vez e o novo código é preparado 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 a confirmação, pode haver um pequeno impacto no desempenho.

Durante uma atualização de código automática, cada nó de um par de trabalho é atualizado sequencialmente. O nó que está sendo atualizado está 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 veja quaisquer falhas de E/S. Quando novos nós são incluídos no sistema, o pacote de atualização é transferido por download automaticamente para os novos nós a partir do sistema.

Normalmente, a atualização pode ser feita simultaneamente com operações normais de E/S 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 estão documentadas no website do produto que você usa para fazer download dos pacotes de atualização. Durante o procedimento de atualização, a maioria dos comandos de configuração não está disponível. Apenas os comandos a seguir estão operacionais a partir do momento em que o processo de atualização inicia no 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 o processo de atualização é concluído, você é notificado por meio da GUI de gerenciamento. Se você estiver usando a interface da linha de comandos, emita o comando lsupdate para exibir o status da atualização.

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

Incluindo mais memória em um nó ou corrigindo uma falha de DIMM

Importante: Antes de fazer upgrade de um nó incluindo mais memória, deve-se primeiro remover esse nó da configuração do sistema. Para fazer isso, conclua os procedimentos a seguir. Da mesma forma, se você encontrar uma falha de DIMM de memória para qualquer nó durante o processo de atualização, pare imediatamente. Em seguida, siga este procedimento para assegurar uma atualização bem-sucedida.

Se você estiver incluindo memória em um nó, deverá remover esse nó da configuração do sistema. Para isso, é possível usar a GUI de gerenciamento ou a CLI.
- Para usar a GUI de gerenciamento, clique com o botão direito no nó e selecione Remover.
- Para usar a CLI, insira o comando a seguir, em que node_id | node_name identifica o nó:
```
svctask rmnode node_id | node_name
```
Nota: Se estiver substituindo um DIMM com falha, não será necessário remover o nó do sistema. Vá para a etapa 2.
Se estiver corrigindo uma falha de DIMM no nó, remova o DIMM, conforme descrito em Removendo módulos de memória (DIMM). Em seguida, continue para a etapa 3.
Para fazer upgrade de um nó com mais memória ou substituir um DIMM em um nó com falha, siga as etapas que estão descritas em Substituindo os módulos de memória (DIMM). Em seguida, continue para a etapa 4.
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 updating, atualize o nó no modo de serviço e inclua-o 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 deve concluir a atualização (rollforward) ou cancelar (retroceder). Sua decisão é parcialmente baseada no ponto da atualização em você estava quando a falha ocorreu. É possível executar rollforward com uma estratégia de atualização de serviço ou com remoção do nó (comando rmnode).
- Rollforward (atualização de serviço): para concluir manualmente a atualização, use um processo de atualização de modo de serviço para atualizar os nós de nível inferior restantes. Depois que todos os nós estiverem executando o mesmo nível, a atualização será confirmada.
- Rollforward (comando rmnode): use o procedimento de comando rmnode somente se a atualização da conclusão estiver em 50% ou acima.
- Retroceder (cancelar a atualização). O parâmetro -force será obrigatório se um ou mais nós estiverem offline.
```
 svctask applysoftware -abort -force
```
  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 atualizados 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:
```
backup do svcconfig
```
Verifique o funcionamento do 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.