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.

Durante o procedimento não se assuste pela quantidade de reboot’s que verá, eles são necessários. Posso dizer que são os 120 minutos mais longos que vi. Aqui o processo de update de todos os Storage Server demorou em torno de 60 minutos. No fim você verá a seguinte imagem se tido ocorrer com sucesso.

Update Storage Passo 16

Depois do update ter sucesso é fundamental realizar o “cleanup” do patch. Basta chamar o patchmgr com o parâmetro “cleanup”.

Update Storage Passo 17

Esta passo não está descrito no Readme mas eu sempre realizo (antes e depois) em cada patch, é o reboot do servidor e da Ilom. Faço isso para garantir que não irá ocorrer um rollback da versão (uma vez uma célula ficou com o arquivo na pasta /boot e em um reboot posterior ela fez rollback). O log da execução deste passo pode ser visto aqui.

Update Storage Passo 18

Este é uma simples conferência e você pode ver que a imagem “12.1.2.1.2.150617.1” foi aplicada com sucesso. Também pode verificar que a imagem “11.2.3.3.0” está marcada como possível rollback. Por fim verifique que todas as células estão operacionais. O log da execução deste passo pode ser visto aqui.

Terceiro Passo Principal

Após aplicar com sucesso o patch dos Storage Servers basta aplicar o patch nos Switchs Infiniband. Aqui como estou aplicando em um Exadata V2 Half tenho 2 para aplicar. Como o arquivo de atualização já está dentro do mesmo patch basta chamar o patchmgr.

O arquivo de Readme do patch não tem os passos de update e você tem que ler o manual do Oracle Exadata para os procedimentos de update.

Update Switch Passo 1

O primeiro passo é criar um arquivo com as lista switchs a serem atualizados, basta informar o hostname deles. Aqui criei o arquivo “ibs_group” como pode ser visto neste log.

Update Switch Passo 2

O segundo passo é uma simples verificação da versão que está rodando no switch. Esse passo é importante pois a versão do patch “12.1.2.1.2” deve ser aplicada somente sobre as versões “2.1.3-4” ou “1.3.3-2”. Caso você não esteja rodando alguma destas versões deve atualizar para elas antes de prosseguir. Isso está descrito na nota MOS 888828.1.

Para verificar basta logar via ssh no switch e executar o comando “version”. O log da execução deste passo pode ser visto aqui. Recomendo realizar o reboot de cada switch antes de prosseguir (não faça em ambos ao mesmo tempo).

Update Switch Passo 3

Antes de efetivamente aplicar o patch rodamos o patchmgr com o parâmetro “ibswitch_precheck” para verificar os requisitos. Se o resultado for positivo o patch pode prosseguir. O log da execução deste passo pode ser visto aqui.

Update Switch Passo 4

Depois do sucesso das verificações basta executar o patchmgr com o parâmetro “upgrade”. Observe no log disponível aqui que o patch é executado em um switch de cada vez.

Ao fazer ssh em um switch durante o processo podemos ver o que está acontecendo. Observe neste log que o comando “installfw” está rodando e aplicando um arquivo e o script “spfw_upgrade_2.1.5-1.sh” aplicando alguns pacotes. O log da pode ser visto aqui.

Durante o processo de update o patchmgr gera um log específico chamado “upgradeIBSwitch.log” na pasta “/var/log/cellos/” do servidor que disparou o patch. Ele pode ser visto aqui.

Update Switch Passo 5

Por fim basta logar através de ssh no switch e verificar se a versão foi aplicada com sucesso com o comando “version”.  O log da execução deste passo pode ser visto aqui.

Conclusão

Com os passos descrito acima o update de todos os Storage Servers foi realizado com sucesso. Partindo da imagem “11.2.3.3.0” para a imagem “12.1.2.1.2”. O Switch Infiniband foi atualizado da “2.1.3-4” para a “2.1.5-1”.

Você pode ver que existem alguns passos importantes a serem seguidos e que o procedimento de atualização somente deve prosseguir se todos os pré-requisitos estiverem ok. Nas versões mais antigas o procedimento de update era bem mais complexo e dependia de muito mais intervenção manual, por isso não existe muito o que demonstrar além de log’s de execução dos comandos.

O importante aqui é compreender o fluxo. Veja todos os comando executados e todos os logs com os resultados.