Há uns dois meses recebi um e-mail de madrugada que uma SR nível 2 havia sido aberta para o Exadata e que o acompanhamento do caso estava aberto. De manhã pude observar que um disco de uma célula havia queimado (o segundo em dois anos) e que o ASR havia detectado o problema e aberto uma SR para a troca do disco.

Achei interessante, pois na primeira vez não pude fazer o log dos passos para registro e esta seria a oportunidade. Também na primeira vez não tinha configurado o ASR e só observei que o disco estava com problema quando fui fazer o checkup semanal no Exadata.

Quando um disco falha no Exadata, o primeiro local a detectar é a ILOM, onde o erro é identificado e um evento é gerado. Este evento é lido pelo ASR e uma SR é aberta automaticamente. Após a falha ser detectada pelo ILOM e o disco ser removido, uma alerta é gerado pelo software do Exadata. Além disso, um e-mail é enviado com algumas informações adicionais sobre o erro. Os detalhes deste alerta podem ser verificados através do cellcli da célula.

A imagem abaixo apresenta a lista dos alertas da célula (vários nesta versão antiga da imagem do software do Exadata). Para verificar a lista de alertas basta digitar “list alerthistory” no cellcli. Neste caso, o código do alerta é o 153_1. O alerta pode ser detalhado através do comando “list alert 153_1 detail”. A imagem abaixo demonstra isso. Neste caso, temos a informação de que o disco do slot 10 apresentou a falha, o serial number do disco, o celldisk afetado e os griddisks afetados.

Por curiosidade pode-se observar os detalhes dos griddisks afetados com o comando “list griddisk <nome_gd> detail”.

 

 

 

 

 

Uma rápida análise da lista dos celldisks nos leva a lun afetada. Do resultado do comando “list celldisk <nome_cd> detail ” podemos extrair o número da lun, neste caso a “0_10”.

As informações da lun podem ser verificadas com o comando “list lun <nome_da_lun> detail”. Infelizmente não tirei os dados do “list physicaldisk” para apresentar os detalhes do disco.

Além disso, se conectarmos ao ASM podemos verificar que um disco está faltando na conta, um simples select com count nos mostra a quantidade atual. Neste caso, ao invés de termos 84 (para um V2) temos 83 discos.

Após o disco ter chego a troca pode ser efetuada, que basicamente é uma remoção física do anterior e a adição do novo. Por ser hot swap a troca é efetuada sem desligar a célula. Como podemos observar abaixo, ambas ações (remoção e adição) são detectadas pelo Exadata e alertas são gerados. Neste caso os eventos 153_2 e 153_3.

Primeiro temos o evento de remoção de disco, em que ele é apontado como ausente. Como descrito na mensagem do alerta, esta é somente uma informação adicional e está associada ao alerta pai de código 153. Como eu tirei a imagem após o disco já ter sido trocado, o endTime deste alerta já estava preenchido, o que não iria ocorrer se um novo disco não tivesse sido inserido.

Em sequência temos o alerta de adição/troca do disco. Este alerta de código 153_2 está associado ao de código 153 e nos dá a informação de que como um disco novo/zerado foi adicionado ao mesmo slot do defeituoso a mesma informação quanto a formatação em celldisk e griddisks do anterior serão aplicadas neste novo disco.

Interessante observar que para ambos os alertas acima, temos a informação de endTime e de sequenceBeginTime. Esta última remete ao momento que o primeiro alerta de falha foi disparado.

Por fim, após o rebalanceamento dos dados temos a contagem correta de discos no ASM com o status correto/normal.

Um detalhe importante é que o disco antigo ainda aparecerá na lista do comando “list physical disk”. O disco aparecerá como “not present” por sete dias. Na primeira troca de discos questionei isso, por quanto tipo ele será listado neste estado. A informação passada pela equipe de desenvolvimento do Exadata é que o disco é mantido por sete dias para que seja possível coletar dados mesmo após ter sido removido. Posteriormente uma nota foi criada com esta informação: 1319536.1.