ExaCC – Discos Offline após Aplicação de Patch
Caso ainda não esteja familiarizado com o ExaCC, segue abaixo uma explicação rápida sobre como funciona o gerenciamento e aplicação de patches.
O ExaCC, por ser uma solução virtualizada, possui duas camadas principais:
Dom0: camada base (bare metal), responsável pelo gerenciamento físico dos recursos.
DomU: camada virtual onde, de fato, os bancos de dados residem e operam.
A aplicação de patches no Dom0 é de responsabilidade exclusiva da Oracle, enquanto os patches no DomU são de responsabilidade do cliente (nossa).
Sabendo disso, em uma das janelas de manutenção programadas pela Oracle para aplicação de patch no Dom0 — que sempre haviam sido concluídas com sucesso — ocorreu um incidente em que seis discos ficaram offline no ASM ao final do processo.
Assim que concluiu o patch, seis discos do grupo RECO ficaram offline e ficavam oscilando entre seis discos offline e um disco. Achei esse comportamento estranho. Minha primeira ação foi verificar os discos presencialmente para ver se havia algum aviso, e chegando lá, tudo estava "verde", ou seja, tudo ok.
ASMCMD> lsdg
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED HIGH N 512 512 4096 4194304 000000000 000000000 0 000000000 0 Y DATAC1/
MOUNTED HIGH N 512 512 4096 4194304 000000000 000000000 0 000000000 6 N RECOC1/
Analisando o log do ASM encontrei o seguinte aviso:
ORA-15025: could not open disk "/dev/exadata_quorum/QD_RECOC1_XXXXXXXXXXX"
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
WARNING: Read Failed. group:2 disk:18 AU:0 offset:0 size:4096
Sem delongas abri um chamado na Oracle informando todos os logs e o contexto do incidente e eles pediram pra executar esse comando:
asmcmd lsdsk |grep exadata_quorum|xargs ls -l
Ao executar tive a seguinte saída em 1 dos nós:
[grid@sv-xxxxxxxxxx ~]$ asmcmd lsdsk |grep exadata_quorum|xargs ls -l
ls: cannot access /dev/exadata_quorum/QD_RECOC1_XXXXXXXXXXX01: No such file or directory
lrwxrwxrwx 1 root root 8 Mar 25 12:25 /dev/exadata_quorum/QD_DATAC1_XXXXXXXXXXX02 -> …/dm-18
lrwxrwxrwx 1 root root 8 Mar 25 12:25 /dev/exadata_quorum/QD_DATAC1_XXXXXXXXXXX03 -> …/dm-16
lrwxrwxrwx 1 root root 8 Mar 25 12:25 /dev/exadata_quorum/QD_RECOC1_XXXXXXXXXXX04 -> …/dm-17
No nó 2, todos os discos do quorum estavam visíveis; já no nó 1, um dos membros não era exibido.
Ja com bastantes informações coletadas, nossos amigos indianos nos passaram a seguinte nota:
Infrastructure Maintenance Fails During Cell Update Due to Missing Quorum Disk Device Links in a VM (Doc ID 2978693.1)
A nota pede a execução dos seguintes comandos para os quorum discos serem “reapresentados ao O.S”
#udevadm control --reload-rules
#udevadm trigger
Após a execução do comando o diskgroup ja “flegou” o Rebal = Y e ja baixou os discos offline para 1
ASMCMD> lsdg
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED HIGH N 512 512 4096 4194304 000000000 000000000 0 000000000 0 Y DATAC1/
MOUNTED HIGH Y 512 512 4096 4194304 000000000 000000000 0 000000000 1 N RECOC1/
Depois de 2 horas, todos os discos estavam online novamente.
ASMCMD> lsdg
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED HIGH N 512 512 4096 4194304 000000000 000000000 0 000000000 0 Y DATAC1/
MOUNTED HIGH N 512 512 4096 4194304 000000000 000000000 0 000000000 0 N RECOC1/
Assim como a nota menciona, infelizmente o ambiente estava em uma das versões causadas pelo bug:
Exadata image version is 22.1.10.0.0, 22.1.13.0.0, 22.1.14.0.0, or 22.1.15.0.0.
O procedimento, como a nota reforça, pode ser executado “online” sem impacto a produção.
Espero que este artigo seja útil em situações futuras 🙂.
