O procedimento descrito aqui contempla a atualização da imagem 11.2.3.3.0 para a imagem 12.1.2.1.2 do Oracle Exadata. Aqui estão descritos os procedimentos para o update do Storage Server e Switch Inifiband.

Primeiro Passo Principal

O primeiro passo de qualquer update para Oracle Exadata é ler o Readme da versão e ler o tópico “Know Issues” que lista todos os possíveis erros que você pode encontrar. Isso não quer dizer que outros erros não podem acontecer, mas você tem um local com a solução dos erros conhecidos. Então leia a Nota 2014306.1.

Segundo Passo Principal

Depois de ler a nota da versão você pode seguir com o download do patch do Storage Server. Os procedimentos de atualização estão descritos no Readme do patch e devem ser lidos (mais de uma vez). É aqui que o processo de update começa efetivamente. Os passo descritos abaixo seguem o Readme do patch (alguns adicionais que sempre utilizo).

Update Storage Passo 1

O primeiro passo do update é executar um Exacheck no ambiente. Não entrarei em detalhes sobre o que ele é, mas a execução dele garante que diversas verificações serão feitas no seu Exadata e um relatório será gerado no final.

Aqui, fiz download do Exacheck na pasta /tmp do nó 1 do Database Server e executei ele. O log da execução deste passo pode ser visto aqui. Revise o resultado e corrija possíveis erros.

Update Storage Passo 2

Para o processo de update precisamos de um arquivo com a lista de todos os Storage Servers, aqui criei um arquivo chamado de “cell_group”, o seu conteúdo pode ser visto aqui. Observe que somente o hostname da rede de gerência é necessário. Também criei um arquivo “dbs_group” com todos os meus Database Servers.

Update Storage Passo 3

Este não é um passo que está listado no processo de update mas pode ajudar muito. Segundo o processo descrito no Readme do patch você não deve iniciar o procedimento via ssh nem ilom. Mesmo conectando em um Database server e disparando o patch de lá (que é o modo correto) você pode ter problemas com a comunicação entre o seu computador e o servidor (ela ser perdida) e o processo de ser interrompido.

Por isso, eu utilizo vnc server do Database Server e disparo o update através desta conexão. Faço isso, pois se a conexão entre o meu computador e o servidor tiver problemas, o update continua e você pode resgatar de onde parou. Inclusive nos primeiros updates do Oracle Exadata essa era uma das formas recomendadas.

Para instalar o vnc server no Database server (rodando a versão 5 do Oracle Linux) você pode seguir as notas MOS 123470.1 e MOS 735767.1. O log da execução deste passo pode ser visto aqui. Neste log observe os rpm’s (que fiz download do repositório oficial da Oracle) instalados, verifique que modifiquei a resolução para 1024×768 (no arquivo vncservers) e que criei uma vncpassword para deixar a conexão mais segura.

Update Storage Passo 4

Para que seja possível você iniciar o update a partir de um Database Server o usuário root deste servidor conectar em todos os Storage servers sem informar a senha. O log da execução deste passo pode ser visto aqui.

Verifique no log que no primeiro momento a equivalência não funcionou. Para corrigir executei o comando presente o Readme para ajustar a equivalência e que após isso o teste funcionou.

Update Storage Passo 5

Antes de parar qualquer serviço ou processo verifique se o seu Grid está com o repair time correto (3.6 horas ou mais), que não está fazendo qualquer operação e têm todos os discos presentes. Caso tenha qualquer disco faltando não continue, se alguma operação estiver em andamento você deve esperar ela terminar. O log da execução deste passo pode ser visto aqui.

Update Storage Passo 6

Verifique se não existe qualquer erro de hardware em qualquer Storage Server. Se você tiver algum não continue, abra uma chamado para substituição do hardware. Caso seja obrigatório o update abra uma SR com a Oracle e verifique se o update pode ser aplicado.

Utilizei o comando “list alerthistory” para verificar isso e o log da execução pode ser visto aqui. No meu caso, todos os alertas estavam sanados.

Update Storage Passo 7

Com os requisitos básicos supridos podemos copiar o patch para uma pasta do Database Server e descompactar, no Readme este passo estava mais adiante mas adiantei ele. Aqui utilizei a pasta “/u01/patch” como local do arquivo, nesta pasta também copiei os arquivos com a lista de host de Storage Server e Database Server. O log da execução deste passo pode ser visto aqui.

Update Storage Passo 8

Um update do Storage Server pode ser aplicado de duas formas: rolling ou non-rolling. No modo rolling os seus bancos de dados podem estar online e o update é aplicado de forma serial em cada Storage Server. No modo non-rolling todos os bancos e Grid deve estar desligados e o update é aplicado de forma paralela em todos os Storager Server, consequentemente é bem mais rápido mas você tem downtime do ambiente.

Aqui eu apliquei o patch no modo “non-rolling” e por isso todo o cluster Grid (em todos os nós) foi desligado. O log da parada do grid (stop cluster –all) e do crs (stop crs) pode ser visto aqui.

Update Storage Passo 9

Depois de desligar o Grid recomendo realizar um reset do Ilom de todos os Storage Servers com o comando “ipmitool bmc reset cold”. Sempre faço isso pois o processo de update tem um timer de controle para o reboot do Storage Server e caso a sua Ilom esteja muito tempo sem reboot ela pode demorar um pouco para voltar e o script de update “acreditar” que ocorreu um travamento. Isso não está descrito Readme, mas não influencia no processo de update. O log da execução deste passo pode ser visto aqui.

Update Storage passo 10

Como estou aplicando em modo “non-rolling” desliguei os serviços do Exadata software em todos os nós. O log da execução deste passo pode ser visto aqui.

Update Storage Passo 11

Este passo serve para verificar se as versões mínimas para update estão presentes, o retorno tem que ser maior que 11.2.2.2.0. Para verificar quais as versões das imagens dos Storage Servers e Database Servers do seu ambiente com os comandos “imagehistory” e “imageinfo”. O log da execução deste passo pode ser visto aqui. Neste mesmo log observe que verifiquei se nos Database Servers existe alguma versão do OFA instalado.

Update Storage Passo 12

O procedimento de patch é realizado através de um script que faz todos o trabalho de conectar em cada Storage Server e aplicar os comandos de update. Nas primeiras versões todos esses passos eram feitos manualmente e eram bem mais demorados e suscetíveis a erros. O script é chamado de “patchmgr” e está localizado dentro do arquivo do patch.

O primeiro passo efetivo do procedimento de patch é realizar um reset de todos os Storage Servers com o comando “reset_force”. O log da execução deste passo pode ser visto aqui.

Observe que por padrão o script não executa o comando imediatamente, você tem 60 segundos para cancelar. Depois de disparar o comando o patchmgr somente retorna ao console quando todos os nós estiverem online novamente.

Update Storage Passo 13

É importante limpar o ambiente antes de iniciar o patch. Com este passo qualquer arquivo de patches passados (como arquivos ocultos que ficam na pasta /boot dos Storage Server) são limpos. O log da execução deste passo pode ser visto aqui.

Update Storage Passo 14

Antes de apresentar o resultado da execução cabe uma explicação sobre alguns arquivos de log. Existem dois arquivos que podem ser acompanhados e nos dão informações da evolução do patch, são os “patchmgr.stdout” e “patchmgr.stderr”.

O primeiro arquivo armazena todas as saídas em console que o patchmgr faz, é um arquivo bem extenso mas para quem gosta de saber o que acontece ele é uma boa fonte de informação. O segundo arquivo armazena qualquer erro que ocorreu.

Neste passo utiliza-se o patchmgr com a opção “patch_check_prereq” para verificar se todos os requisitos estão ok. Ele faz verificações mais profundas do que a que fizemos previamente, como partições e espaço em disco em cada Storage Servers. O log da execução deste passo pode ser visto aqui.

Se verificarmos o arquivo “patchmgr.stdout” podemos observar o que foi feito pelo “patchmg”. Você pode ver um exemplo deste arquivo aqui.

Update Storage Passo 15

Basicamente aplicamos o patch agora. O script patchmgr é executado com o comando o parâmetro “patch”, observe que fiz este procedimento através da tela do VNC.

Pode parecer simples mas o procedimento de patch é complexo e apesar de apresentar somente 5 etapas o que acontece internamente é interessante. De forma bem resumida o que ocorre automaticamente durante o procedimento é:

1. Verificações são feitas (o precheck) e os servidores são reiniciados.
2. Os arquivos de patch são copiados para cada Storage Server.
3. O Linux é atualizado (já que este patch atualiza do OEL5 para o OEL6) em uma partição separada.
4. O Exadata Software é atualizado e scripts são executados.
5. Scripts finais são executados e o Storage Server é reiniciado.
6. Durante o reboot todos os firmwares são verificados e atualizados caso necessário: Ilom, discos, controladoras de discos, placas de rede, placas infiniband e placas Flash.
7. O Storage Server reinicia na versão correta da imagem com todos os serviços operacionais.

Nesta galeria você pode ver as imagens deste procedimento. Observe que ao fundo deixei o log do patchmgr (stdout e stderr) e nas primeiras imagens pode ver que os arquivos estão sendo copiados e os servidores reiniciados. Depois disso o arquivo de “patchmgr.stdout” nos mostra que o “install.sh –nohup” foi disparado e o reboot ocorre. Por fim se você acompanhar na Ilom dos Storage Servers verá que o reboot acontece. Se você acompanhar a Ilom dos Storage Server (recomendo, e pode abrir de todos os Storage Servers) prepare-se para reconectar várias vezes pois como ela é atualizada cada um causa o reboot e revogação de qualquer conexão.