Este post demonstra como podemos determinar a estimativa de tempo de janela de manuntenção, assim como acompanhar o progresso de uma atualização de Dom0 do Exadata Cloud Service (ExaCS). Esta atualização envolve a camada física do Exadata e é realizada inteiramente pela Oracle, onde o cliente só precisa indicar a melhor janela de manutenção na console.

Quando há uma atualização agendada para a Infraestrutura do Exadata (Dom0), essa informação é apresentada na tela do recurso “Cloud Exadata Infrastructure”.

Estimativa de Tempo Padrão (Teórica)

Acesse a página do Exadata Cloud Service:

Após clicar no nome do Exadata e abrir a página principal do recurso Exadata Infrastructure, clicando em “view update”, a tela abaixo com os detalhes da atualização será exibida:

Em “Total Estimated Maintenace Time”, é apresentado a soma do tempo estimado para atualizar Switches, Storages e Compute Nodes (atualização do host).

Clicando em “view”, ele apresenta os detalhes sobre o tempo estimado para cada DB node:

Para os Storages servers, é considerado 60 minutos por cada node. Neste caso específico, trata-se de uma configuração com 6 Storage servers, o que dá 6 horas de estimativa no total. A quantidade de Storages é apresentada na tela inicial do recurso Exadata Infrastructure:

Note que em “Network Switches Estimated Maintenace Time”, o tempo apresentado era 0 minutos. Isso é esperado quando não tem atualização na camada dos RoCE Switches.

Estimativa de Tempo Baseada em Histórico

Se o ambiente não for novo e já teve 2 ou 3 atualizações, uma abordagem que podemos considerar é olhar o histórico e ver o tempo de início e fim das atualizações:

Neste exemplo, as últimas 2 atualizações levaram 7 e 10 horas respectivamente. Apesar de ter uma variação considerável entre uma atualização e outra, ainda ficou dentro do tempo total estimado apresentado na console.

Rebalance do ASM

Quando um Storage node é reiniciado durante a atualização, os discos deste Storage em questão ficam com status OFFLINE no diskgroup ASM. Quando a atualização e o reboot do Storage node conclui, esses discos são colocados ONLINE novamente e o ASM inicia o processo de RESYNC dos discos que estavam OFFLINE.

O tempo de RESYNC não é considerado na estimativa de 1:00h que a Oracle considera para cada Storage node:

O tempo de cada RESYNC varia de acordo com a ocupação total dos discos, rebalance power do ASM e o volume de blocos alterados enquanto um dos Storages estava offline, mas normalmente esse tempo fica entre 15 e 30 minutos.

Por outro lado, considerando o cenário “Normal”, também é comum que a atualização em si de cada Storage node não leve 60 minutos, então na prática a estimativa de 1:00h apresentada na console pode acabar englobando atualização do Storage + RESYNC do ASM.

Antes de iniciar a atualização, verifique como está configurado o valor do Rebalance Power no ASM, certificando-se que o parâmetro asm_power_limit tem um valor maior que zero. O valor padrão e recomendado pela Oracle no Exadata é 4.

SQL> alter system set asm_power_limit=4 scope=both;

System altered.

Acompanhando as Etapas da Atualização

Na tela do recurso de Exadata Infrastructure, clicando em Work request, podemos visualizar o status da atualização em andamento:

Clicando no no link da operação “Apply Infra Patch for Cloud Exadata Infrastructure”, podemos acessar a guia “Log messages” e acompanhar o avanço de cadata etapa da atualização:

Quando a etapa de atualização dos Storage servers estiver em execução, podemos tentar observar qual dos Storages está sendo atualizado, consultando quais discos estão com status OFFLINE ou em RESYNC no ASM:

sudo su - grid
sqlplus / as sysasm

SELECT 
lower(FAILGROUP) as cell_name, 
TO_CHAR(MIN(MOUNT_DATE),'DD/MM/YYYY HH24:MI:SS') MIN_MOUNT_DATE,
TO_CHAR(MAX(MOUNT_DATE),'DD/MM/YYYY HH24:MI:SS') MAX_MOUNT_DATE,
COUNT (CASE WHEN MODE_STATUS = 'OFFLINE' THEN 1 ELSE NULL END) DISK_OFFLINE,
COUNT (CASE WHEN MODE_STATUS = 'SYNCING' THEN 1 ELSE NULL END) DISK_SYNCING
FROM V$ASM_DISK
GROUP BY FAILGROUP
ORDER BY 1;

Algumas dicas:

• Failgroup com MOUNT_DATE na data atual e todos os discos ONLINE, indicam que o Storage server em questão já foi atualizado
• DISK_OFFLINE > 0, o Storage server em questão está sendo atualizado
• DISK_SYNCING > 0, o Sotrgae server em questão acabou de ser atualizado e os discos estão sendo rebalanceados antes de o processo de atualização seguir para o próximo Storage server (senão for o último da lista).

Se tiver discos com status de SYNCING, podemos obter uma estimativa da operação de RESYNC assim como em qualquer outro ambiente com ASM, utilizando o comando “asmcmd lsop”:

sudo su - grid
asmcmd lsop

Apesar deste método não poder ser considerando “oficial” para se acompanhar uma atualização de Storage do Exadata, é um método simples e acessível de conseguir ter uma ideia do progresso da atualização que é realizada automaticamente pela Oracle Cloud.