Provisionamento de Discos no Oracle Exadata Storage Server
Pois é, uma pergunta interessante que as vezes eu escuto é: “Como que eu troco os discos no Oracle Exadata”? ou então “Como estão dividos os Discos dentro do ASM no Exadata”?
Apesar de utilizar o ASM como storage compartilhado (sim isso é meio óbvio visto que o “core” do Exadata é o Grid Inrastructure / RAC 11g) os ASMDisks no Exadata tem SIM difrenças em relação a um cluster 11g comum. O Grande ponto nem é tanto o ASM mas sim a topologia de discos que existe no Exadata, que não tem nada a ver com alocação de LUNS em um storage convencional NetAPP ou EMC.
O Primeiro ponto é entender como os discos funcionam dentro do Exadata Storage Server, para depois sim saber como substituí-los em caso de falhas e executar o provisionamento de modo correto.
Revisão Rápida
Alguns pontos importantes sobre o conceito de discos dentro do Exadata Storage Server:
- Cada configuração de Exadata tem um número “X” de Cells.
Ex: 14 Cells no Full Rack, 7 Cells no Half Rack, 3 Cells no Quarter Rack, etc.. Porém é importante lembrar que é permitdo fazer inúmeras combinações, não sendo necessariamente uma regra ter um número “X” fixo de Storage Cells por Cluster dentro do Exadata.
- O Exadata Storage Server é composto de “Células”, que nada mais são que Servidores SUN rodando Linux com seus respectivos discos, Obviamente cada versão de Exadata possui sua versão de hardware para os Storage Cells.
Ex: SUN FIRE X4270 M2, SUN FIRE X4270, SUN FIRE X4170 M2, SUN FIRE X1270, etc..etc..
- Cada Storage Cell possui 12 Discos Rígidos que podem ser divididos em:
- HP (High Performance) – Discos de 600Gb SAS 15.000rpm
- HC (High Capacity) – Discos de 3TBGb SATA2 7.200rpm
- O SO (Linux) de cada Storage Cell é instalado nos Discos id0 e id1 em um RAID 1 a nível de Software, não de hardware. Sendo assim, na perda de um destes discos, o Sistema Operacional da Célula será mantido via RAID de software.
Da mesma maneira que o Compute Node, cada Storage Cell utiliza o conceito de Kernel/Image do Exadata, sendo assim, existem bugs e correções para cada versão do Software Exadata Storage Server instalado. De uma forma geral, a cada versão a Oracle corrige mais e mais bugs (como qualquer outro fabricante) portanto cada vez mais o processo de provisionamento de Discos fica mais simplificado e confiável.
Conceito
Antes de citar falhas/troca de discos no Exadata, é preciso entender como funciona o conceito físico e lógico de armazenamento. A Figura abaixo ilustra de uma forma objetiva isso:
Observações:
- Cada disco físico é representado por uma LUN. Uma Lun está diretamente relacionada à apenas um CellDisk. Um Celldisk Contém vários Griddisks (Na maioria das instalações são 3 Griddisks por CellDisk = DATA, RECO e DBFS). Um Griddisk está sempre relacionado à SOMENTE UM ASM Disk. Um ASM Disk está sempre relacionado à SOMENTE Um Diskgroup no ASM. Por fim, um Diskgroup no ASM é composto por vários ASM Disks.
- A porção utilizada para a instalação do Oracle Linux nos Discos id0 e id1 é exatamente a porção dos demais discos (dados) utilizada para o Diskgroup DBFS (quando este existir).
Geralmente são criados 3 Diskgroups: DATA, RECO e DBFS. Os Griddisks relacionados ao Diskgroup DATA estão sempre alocados na “hot area” dos Griddisks. Esta é a àrea externa to disco físico (disk) que possui maior performance de leitura/gravação. Os Griddisks relacionados ao Diskgroup RECO estão sempre alocados na “cold area” dos Griddisks. Esta é a àrea interna to disco físico (disk) que possui menor performance de leitura/gravação. Os Griddisks alocados para o DBFS, estão mais próximos do centro do Disco físico, sendo assim, utilizam a menor porção do disco (cerca de 29Gb). O DBFS geralmente é dedicado para arquivos temporários ou flat files para operações de LOAD/ETL. Para mais informações sobre o DBFS veja este artigo: Configurando o DBFS no Oracle Exadata Database Machine
Troca de Discos
Como qualquer outro Hardware, o Storage Server pode apresentar problemas, não só de discos, mas de CPU, Memória, Rede, etc. Recentemente me perguntaram: “Como assim? Exadata dá problema de discos??”. Resposta: CLARO, não é um produto mágico e tem sim falhas, bugs, etc.. Um dos motivos mais comuns de falhas de disco ou outros componentes de Hardware é a configuração ou preparação incorreta da rede elétrica que alimenta o Exadata. Picos de energia são causadores de falhas e podem sim corromper discos.
Existem 2 tipos de falhas que podem ocorrer:
- Falhas Físicas
Esta está relacionada a um erro Físico no Disco, e geralmente causa perda de dados no disco.
- Falhas Preditivas (Lógicas)
Esta está relacionada a um erro lógico no Disco, e nem sempre causa perda de dados no disco.
Em ambos os casos, a Oracle ACS efetua a troca do disco físico.
Procedimentos e Pré-Requisitos
Como padrão, a Oracle utiliza o serviço de ASR (Automatic Service Request) para monitoramento de recursos de Hardware. Este recurso tem como finalidade abrir um SR (Service Request) automaticamente para o My Oracle Support onde um técnico de Hardware efetua a troca, porém, existem alguns cuidados a nível de Software (Exadata Storage Server) que devem ser tomados para a troca de Discos. Vamos em frente então.
1 – Identificar em qual Storage Cell se encontra o disco com Falha.
Esta informação pode ser obtida de várias formas:
- Via ASM
select name, header_status, state from v$asm_disk;
- Fisicamente em Frente ao Storage Cell
Na maioria dos casos, o Led de Serviço (Service LED) estará acesso no disco com falha (se falha física)
- Via Distributed Comand Line (dcli) através de um Compute Node
Criar um arquivo “cell_group” com todas as células (geramente localizado em /opt/oracle.SupportTools/onecommand)
2 – Conectar no Storage Cell onde se encontra o disco com Falha.
Nesse ponto é importante verificar o disco com Falha e também o status da Storage Cell
Identificando Falhas Preditivas
# cellcli
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status LIKE ".*failure.*" DETAIL
name: 20:3
deviceId: 19
diskType: HardDisk
enclosureDeviceId: 20
errMediaCount: 0
errOtherCount: 0
foreignState: false
luns: 0_3
makeModel: "SEAGATE ST360057SSUN600G"
physicalFirmware: 0805
physicalInterface: sas
physicalSerial: E07L8E
physicalSize: 558.9109999993816G
slotNumber: 3
status: predictive failure
No exemplo acima, o campo “name:” mostra o “Name” e o “SlotNumber” do disco em questão. (20:3). Também é possível identificar qual a Lun referente ao disco (0_3). Ao final o status em que se encontra o disco: “predictive failure”.
Identificando Falhas Físicas
# cellcli
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=critical DETAIL
name: 28:5
deviceId: 21
diskType: HardDisk
enclosureDeviceId: 28
errMediaCount: 0
errOtherCount: 0
foreignState: false
luns: 0_5
makeModel: "SEAGATE ST360057SSUN600G"
physicalFirmware: 0705
physicalInterface: sas
physicalSerial: E07KZ8
physicalSize: 558.9109999993816G
slotNumber: 5
status: critical
No exemplo acima, o campo “name:” mostra o “Name” e o “SlotNumber” do disco em questão. (28:5). Também é possível identificar qual a Lun referente ao disco (0_5). Ao final o status em que se encontra o disco: “critical”.
Em ambos os casos acima, teoricamente os ASM Disks associados com este Disco/Lun devem estar com status “_dropped” no ASM e então o ASM automaticamente realiza o rebalance dos dados entre os demais discos do Diskgroup. Da mesma forma os Griddisks e o CellDisk relacionado à esta LUN também deve(m) ser excluído(s) automaticamente na remoção do Disco fisicamente com a opção FORCE (DOP FORCE).
** IMPORTANTE **
Em versões do Exadata Storage Server (image) inferiores à 11.2.3.1.0 é comum que em caso de problemas relacionados à provisionamento de discos o software não faça todo o procedimento automaticamente. Em versões superiores à 11.2.3.1.0 na maioria dos casos este artigo não se faz necessário, e o Exadata Storage Server resolve automaticamente a substituição de um disco.
3 – Verirficar o status do Storage Cell
Listando o Status da Storage Cell:
# cellcli
CellCLI> list cell attributes cellsrvStatus,msStatus,rsStatus detail
cellsrvStatus: running
msStatus: running
rsStatus: running
Seguem alguns passos para verificar se está tudo ok e se o Disco está 100% pronto para ser substituído:
** IMPORTANTE **
Os próximos passos se aplicam tanto para falhas Preditivas como falhas Físicas/Criticas.
4 – identificar qual é o CellDisk que está com problemas.
Nesse ponto é importante verificar o disco com Falha e também o status da Storage Cell
(Neste procedimento o exemplo está relacionado à um Exadata Sotrage Cell com discos HP de 600GB):
# cellcli
CellCLI> list celldisk where lun=0_3 detail
name: CD_03_dm02cel01
comment:
creationTime: 2013-08-10T11:41:53-04:00
...
status: normal
CellCLI> list griddisk where celldisk=CD_03_dm02cel01
DATA_Q1_CD_03_dm02cel01 active
DBFS_DG_CD_03_dm02cel01 active
RECO_Q1_CD_03_dm02cel01 active
CellCLI> list celldisk CD_03_dm02cel01 detail
name: CD_03_dm02cel01
comment:
creationTime: 2013-08-10T21:05:42-04:00
deviceName: /dev/sdd
devicePartition: /dev/sdd
diskType: HardDisk
errorCount: 0
freeSpace: 0
id: 909093d9-c154-4f9a-92db-9491268f68c8
interleaving: none
lun: 0_3
physicalDisk: K4E80L
raidLevel: 0
size: 557.859375G
status: predictive failure
** IMPORTANTE **
Salvar a configuração de cada Griddisk dentro deste CellDisk, uma vez que provavelmente será necessário recriar os Griddisks após a substituição do Disco físico.
# cellcli
CellCLI> list griddisk where celldisk=CD_03_dm02cel01 attributes name,size,offset
DATA_Q1_CD_03_dm02cel01 423G 32M
DBFS_DG_CD_03_dm02cel01 29.125G 528.734375G
RECO_Q1_CD_03_dm02cel01 105.6875G 423.046875G
5 – Verificar se o disco já foi removido do ASM
Conectar em um Compute Node do Cluster:
# sqlplus / as sysasm
SQL> set linesize 132
SQL> col path format a50
SQL> select group_number,path,header_status,mount_status,mode_status,name from V$ASM_DISK where path like '%CD_03_dm02cel01';
GROUP_NUMBER PATH HEADER_STATU MOUNT_S MODE_ST NAME
------------ --------------------------------------------------
0 o/192.168.9.1/DBFS_DG_CD_03_dm02cel01 FORMER CLOSED ONLINE
0 o/192.168.9.1/DATA_Q1_CD_03_dm02cel01 FORMER CLOSED ONLINE
0 o/192.168.9.1/RECO_Q1_CD_03_dm02cel01 FORMER CLOSED ONLINE
SQL>
A Coluna “GROUP_NUMBER” deve ser 0 e o campo “NAME” deve ser NULL. Caso os valores sejam diferentes ou o campo “HEADER_STATUS” ainda conste como “MEMBER” será necessário primeiramente remover os ASMDisks do ASM.
# sqlplus / as sysasm
SQL>alter diskgroup dbfs_dg drop disk DBFS_DG_CD_03_dm02cel01 rebalance power 4;
SQL>alter diskgroup reco_q1 drop disk RECO_q1_cd_03_dm02cel01 rebalance power 4;
SQL>alter diskgroup data_q1 drop disk DATA_Q1_CD_03_dm02cel01 rebalance power 4;
Caso ocorra algum erro na remoção, utilizar a opção “FORCE”:
# sqlplus / as sysasm
SQL>alter diskgroup dbfs_dg drop disk DBFS_DG_CD_03_dm02cel01 FORCE rebalance power 4;
SQL>alter diskgroup reco_q1 drop disk RECO_q1_cd_03_dm02cel01 FORCE rebalance power 4;
SQL>alter diskgroup data_q1 drop disk DATA_Q1_CD_03_dm02cel01 FORCE rebalance power 4;
** IMPORTANTE **
Antes de continuar, é importante garantir que o Status dos Griddisks e do CellDisk em questão esteja como citado acima dentro do ASM, e ainda que não exista em execução NENHUMA operação de Rebalance. É muito importante lembrar que todas as operações de rebalance devem ter sido concluídas antes de executar qualquer manutenção nos discos. Caso seja necessário fazer o “DROP FORCE” dos ASM Disks, os mesmos precisarão ser adicionados novamente após a troca do Disco físico.
Verificar operações de Rebalance:
# sqlplus / as sysasm
SQL> select * from gv$asm_operation where state='RUN';
no rows selected.
6 – Verificar se os Griddisks podem ser desativados
Conectar no Storage Cell onde se encontra o disco com Falha:
# cellcli
CellCLI> list griddisk where celldisk=CD_03_dm02cel01
DATA_Q1_CD_03_dm02cel01 active
DBFS_DG_CD_03_dm02cel01 active
RECO_Q1_CD_03_dm02cel01 active
CellCLI> list griddisk attributes name,asmmodestatus,asmdeactivationoutcome where name = DATA_Q1_CD_03_dm02cel01
DATA_Q1_CD_03_dm02cel01 ONLINE Yes
CellCLI> list griddisk attributes name,asmmodestatus,asmdeactivationoutcome where name = DBFS_DG_CD_03_dm02cel01
DBFS_DG_CD_03_dm02cel01 ONLINE Yes
CellCLI> list griddisk attributes name,asmmodestatus,asmdeactivationoutcome where name = RECO_Q1_CD_03_dm02cel01
RECO_Q1_CD_03_dm02cel01 ONLINE Yes
7 – Desativar os Griddisks
Conectar no Storage Cell onde se encontra o disco com Falha:
# cellcli
CellCLI> alter griddisk DATA_Q1_CD_03_dm02cel01 inactive
GridDisk DATA_Q1_CD_03_dm02cel01 successfully altered
CellCLI> alter griddisk DBFS_DG_CD_03_dm02cel01 inactive
GridDisk DBFS_DG_CD_03_dm02cel01 successfully altered
CellCLI> alter griddisk RECO_Q1_CD_03_dm02cel01 inactive
GridDisk RECO_Q1_CD_03_dm02cel01 successfully altered
8 – Validar se o LED de Serviço está Ativo
Antes de remover o Disco efetivamente, é importante validar se o LED de Serviço (Service LED) está ativo indicando que o disco está efetivamente pronto para substituição. O Service LED é representado pela luz AMBAR/LARANJA no Disco. Para identificar o Service LED é necessário estar fisicamente em frente ao Storage Cell onde se encontra o disco:
Posição de Slots/Discos: Exadata Storage Servers – Sun Fire X4275 and Sun Fire X4270M2 servers: (Exadata X2 e V2)
|
HDD2 |
HDD5 |
HDD8 |
HDD11 |
|
HDD1 |
HDD4 |
HDD7 |
HDD10 |
|
HDD0 |
HDD3 |
HDD6 |
HDD9 |
Posição de Slots/Discos:Exadata Storage Servers – Sun Server X3-2L servers: (Exadata X3)
|
HDD8 |
HDD9 |
HDD10 |
HDD11 |
|
HDD4 |
HDD5 |
HDD6 |
HDD7 |
|
HDD0 |
HDD1 |
HDD2 |
HDD3 |
Caso o SERVICE LED não esteja ativo, então deve-se ativá-lo:
# cellcli
CellCLI> alter physicaldisk 20:3 serviceled on
9 – Remover os Griddisks relacionados ao CellDisk. Remover o CellDisk (Apenas se necessário)
Conectar no Storage Cell onde se encontra o disco com Falha:
IMPORTANTE
É importante lembrar que os passos deste item (9) devem ser executados somente caso não seja possível ativar o Service LED para o Disco em questão, ou ainda caso os ASM Disks não sejam reconhecidos como “FORMER”ou “DROPPED”. Caso contrário, basta ativar o Service LED e fazer a remoção do(s) disco(s).
# cellcli
CellCLI> drop griddisk DATA_Q1_CD_03_dm02cel01
CELL-02550: Cell Server (CELLSRV) cannot drop the grid disk.
Como citado anteriormente, o erro acima (CELL-02550) pode ocorrer devido a versão do Exadata Storage Server (image). Se isso acontecer, o procedimento corretivo é fazer um “REENABLE” da Lun em questão (0_3):
# cellcli
CellCLI> ALTER LUN 0_3 REENABLE FORCE;
LUN 0_3 on physical disk 20:3 successfully marked to status normal.LUN 0_3 successfully reenabled.
Fazer novamente o drop dos Griddisks:
# cellcli
CellCLI> drop griddisk DATA_Q1_CD_03_dm02cel01
GridDisk DATA_Q1_CD_03_dm02cel01 successfully dropped
CellCLI> drop griddisk DBFS_DG_CD_03_dm02cel01
GridDisk DBFS_DG_CD_03_dm02cel01 successfully dropped
CellCLI> drop griddisk RECO_Q1_CD_03_dm02cel01
GridDisk RECO_Q1_CD_03_dm02cel01 successfully dropped
Fazer o Drop do CellDisk:
# cellcli
CellCLI> drop celldisk CD_03_dm02cel01
CellDisk Q1_CD_03_dm02cel01 successfully dropped
10 – Substituir o Disco danificado
Neste momento o Service LED deverá ser ativado, e consequentemente o disco estará pronto para ser removido / substituído. Essa atividade é feita pelo Técnico de Field / Hardware da Oracle, uma vez que existem procedimentos para troca do disco. Não se preocupe com isso, o técnico fará a substituição…
Reativando o Disco no Exadata Storage Server
Uma vez substituído, o Disco deve ser reconfigurado no Exadata Storage Server e, obviamente, no ASM. Como citei anteriormente, este procedimento está mais “maduro” nas últimas versões do Exadata, porém é válido fazer a verificação e compreender se o Disco está 100% ativo e funcional no Exadata Storage Server. (O técnico que efetuou a troca do disco não fará esse tipo de atividade).
11 – Verificar se o Disco Físico está Funcional
# cellcli
CellCLI> list physicaldisk 20:3 detail
name: 20:3
...
luns: 0_3
...
physicalInsertTime: 2013-08-10T19:11:58-04:00
...
slotNumber: 3
status: normal
Observar que o “status” do disco consta como “normal”. O campo “physicalInsertTime” reporta exatamente o tempo em que o disco foi inserido e re-criado como um novo “Disco Físico”.
12 – Validar Disco / Configuração
Uma vez que o disco foi substituído, o mesmo precisa estar sincronizado com os demais. Com o comando abaixo o Exadata Storage Server Software irá validar a versão/firmware do disco, e caso necessário, irá atualizar para mesma versão dos demais discos. Caso a versão/firmware esteja acima ou igual a versão atual do Exadata Storage Server Software, então o disco será validado com sucesso.
# cellcli
CellCLI> alter cell validate configuration
13 – Verificar Griddisks e CellDisk
Depois que o Disco físico é substituído, uma LUN é criada automaticamente para o mesmo (0_3). Da mesma forma o CellDisk relacionado à este Disco e os Griddisks deste CellDisk também são re-criados . Os ASM Disks também são automaticamente criados e um processo de rebalance é iniciado para re-distribuição dos dados entre todos os discos dos Diskgroups. (Tudo isso ocorre caso não tenham sido removidos como citado no item 9).
De qualquer forma, em alguns casos (mesmo não executando os passos do item 9) nem sempre todos os passos citados são executados automaticamente, sendo assim, continuemos com a adição do disco:
# cellcli
CellCLI> list lun 0_3 detail
name: 0_3
cellDisk: CD_03_dm02cel01
...
status: normal
CellCLI> list celldisk where lun=0_3 detail
name: CD_03_dm02cel01
comment:
creationTime: 2013-08-10T19:12:04-04:00
...
status: normal
No exemplo acima, vemos a LUN (0_3) e o Cell Disk (CD_03_dm02cel01) criados. Caso o Cell Disk não tenha sido criado, criá-lo novamente:
# cellcli
CellCLI> CREATE CELLDISK CD_03_dm02cel01 LUN='0_3' HARDDISK
CellDisk CD_03_dm02cel01 successfully created
Verificar se todos os Griddisks foram criados (output esperado para Discos HP 600GB):
# cellcli
CellCLI> list griddisk where celldisk=CD_03_dm02cel01 detail
name: DATA_Q1_CD_03_dm02cel01
availableTo:
cellDisk: CD_03_dm02cel01
comment:
creationTime: 2013-08-10T19:13:24-04:00
diskType: HardDisk
errorCount: 0
id: 8cd3556f-ee21-4497-9e0d-10b7ed9b4e74
offset: 32M
size: 423G
status: active
name: DBFS_DG_CD_03_dm02cel01
availableTo:
cellDisk: CD_03_dm02cel01
comment:
creationTime: 2013-08-10T19:14:08-04:00
diskType: HardDisk
errorCount: 0
id: 26d6729c-9d24-44de-b8d9-91831e2010d2
offset: 528.734375G
size: 29.125G
status: active
name: RECO_Q1_CD_03_dm02cel01
availableTo:
cellDisk: CD_03_dm02cel01
comment:
creationTime: 2013-08-19T18:15:31-04:00
diskType: HardDisk
errorCount: 0
id: 09f3859b-2e2c-4b68-97ea-96570d1ded29
offset: 423.046875G
size: 105.6875G
status: active
Caso os Griddisks não tenham sido criados, criar todos:
# cellcli
CellCLI> create griddisk DATA_Q1_CD_03_dm02cel01 celldisk=CD_03_dm02cel01,size=423G
GridDisk DATA_Q1_CD_03_dm02cel01 successfully created
CellCLI> create griddisk DBFS_DG_CD_03_dm02cel01 celldisk=CD_03_dm02cel01,size=105.6875G
GridDisk DBFS_DG_CD_03_dm02cel01 successfully created
CellCLI> create griddisk RECO_Q1_CD_03_dm02cel01 celldisk=CD_03_dm02cel01,size=29.125G
GridDisk RECO_Q1_CD_03_dm02cel01 successfully created
14 – Verificar ASM Disks
Uma vez que os Griddisks foram recriados, os mesmos devem aparecer como ASM Disks dentro do ASM (caso não tenham sido removidos). Juntamente com os discos o processo de Rebalance estará também em andamento:
# sqlplus / as sysasm
SQL> set linesize 132
SQL> col path format a50
SQL> select group_number,path,header_status,mount_status,mode_status,name from V$ASM_DISK where path like '%CD_03_dm02cel01';
GROUP_NUMBER PATH HEADER_STATU MOUNT_S NAME
------------ -------------------------------------------- ------------ ------- ------------------------------
1 o/192.168.9.1/DATA_Q1_CD_03_dm02cel01 MEMBER CACHED DATA_Q1_CD_03_dm02cel01
2 o/192.168.9.1/DBFS_DG_CD_03_dm02cel01 MEMBER CACHED DBFS_DG_CD_03_dm02cel01
3 o/192.168.9.1/RECO_Q1_CD_03_dm02cel01 MEMBER CACHED RECO_Q1_CD_03_dm02cel01
SQL> select * from gv$asm_operation;
INST_ID GROUP_NUMBER OPERA STAT POWER ACTUAL SOFAR EST_WORK EST_RATE
---------- ------------ ----- ---- ---------- ---------- ---------- ---------- ----------
EST_MINUTES ERROR_CODE
----------- --------------------------------------------
2 3 REBAL WAIT 10
1 3 REBAL RUN 10 10 1541 2422
7298 0
A operação de rebalance é identificada através do campo “STATE”=RUN. O Campo “MOUNT_STATE” deve ser identifcado como “ONLINE” ou “CACHED”.
Caso os Griddisks criados anteriormente não sejam automaticamente adicionados ao ASM como ASMDisks então deve-se adicioná-los manualmente:
# sqlplus / as sysasm
SQL> alter diskgroup dbfs_dg add disk 'o/192.168.9.1/DBFS_DG_CD_03_dm02cel01' rebalance power 10;
SQL> alter diskgroup data_q1 add disk 'o/192.168.9.1/DATA_Q1_CD_03_dm02cel01' rebalance power 10;
SQL> alter diskgroup reco_q1 add disk 'o/192.168.9.1/RECO_Q1_CD_03_dm02cel01' rebalance power 10;
15 – Verificar ASM Diskgroups
Validar o espaço total dos Diskgroups no ASM. Neste exemplo foi utilizado um Exadata Half Rack (50TB Raw) totalizando 22.5TB de disco (Normal Redundancy), como vemos abaixo:
# sqlplus / as sysasm
SQL> select name, total_mb, free_mb, round((free_mb/total_mb)*100,2) "% FREE" from v$asm_diskgroup ;
NAME TOTAL_MB FREE_MB % FREE
------------------------- ---------- ---------- ----------
DATA_DM04Y5 36056832 3130212 11.51
DBFS_DG 2192320 1096160 50.0
RECO_DM04Y5 12016512 3004128 25.0
Discos id0 e id1
Como citado no início deste artigo, os discos id0 e id1 do Exadata Storage Cell possuim 29GB cada dedicados para um RAID 1 onde está instalado o Sistema Operacional. Este RAID é configurado a nível de software (SO) e o espaço de cada disco (id0 e id1) é o espaço que é alocado para os CellDisks do DBFS nos demais discos (id2 à id11).
Quando um destes discos (id0 ou id1) necessita ser substituído, o RAID configurado entre eles é “quebrado”, e necessita ser reconfigurado.
** IMPORTANTE **
Este é um cenário que ocorre em versões do Exadata Storage Server Software (image) anteriores à 11.2.3.1.0, em versões posteriores o software corrige o RAID automaticamente após a substituição do disco físico.
Após a troca do disco id0, validar a configuração do RAID no Linux:
# fdisk -l /dev/sda <-- Disco id0 (disco substituído)
Disk /dev/sda: 598.9 GB, 598999040000 bytes
255 heads, 63 sectors/track, 72824 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sda doesn't contain a valid partition table
# fdisk -l /dev/sdab <-- Disco id1
Disk /dev/sdb: 598.9 GB, 598999040000 bytes
255 heads, 63 sectors/track, 72824 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 15 120456 fd Linux raid autodetect
/dev/sdb2 16 16 8032+ 83 Linux
/dev/sdb3 17 69039 554427247+ 83 Linux
/dev/sdb4 69040 72824 30403012+ f W95 Ext'd (LBA)
/dev/sdb5 69040 70345 10490413+ fd Linux raid autodetect
/dev/sdb6 70346 71651 10490413+ fd Linux raid autodetect
/dev/sdb7 71652 71913 2104483+ fd Linux raid autodetect
/dev/sdb8 71914 72175 2104483+ fd Linux raid autodetect
/dev/sdb9 72176 72437 2104483+ fd Linux raid autodetect
/dev/sdb10 72438 72527 722893+ fd Linux raid autodetect
/dev/sdb11 72528 72824 2385621 fd Linux raid autodetect
O RAID de software é gerenciado pelo utilitário “mdadm”. Listando abaixo a configuração do RAID após a troca do disco id0:
# mdadm --detail /dev/md11
/dev/md11:
Version : 0.90
Creation Time : Sat Ago 10 22:10:29 2013
Raid Level : raid1
Array Size : 2385536 (2.28 GiB 2.44 GB)
Used Dev Size : 2385536 (2.28 GiB 2.44 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sat Ago 10 22:40:44 2013
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
UUID : db671f7c:c315bf00:497d0c27:730e4375
Events : 0.73214
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 27 1 active sync /dev/sdb11
Como pode-se ver acima, o disco id0 não possui partições criadas para reestabelecer o RAID. o Metadevicce 11 (assim como os demais) consta apenas com 1 membero (/dev/sdb).
Antes de continuar, este artigo contempla algums porntos:
1 – O Disco substituído foi o id0
2 – O Disco id0 é representado pelo /dev/sda
3 – O Disco id1 é representado pelo /dev/sdb
4 – Devido a troca do disco, todos os metadevices foram impactados (5 à 11)
6 – A Tabela abaixo representa cada metadevice e seu respectivo membro:
Metadevice First Member Second Member
======== ========== ============ /dev/md1 /dev/sda10 /dev/sdb10
/dev/md2 /dev/sda9 /dev/sdb9
/dev/md4 /dev/sda1 /dev/sdb1
/dev/md5 /dev/sda5 /dev/sdb5
/dev/md6 /dev/sda6 /dev/sdb6
/dev/md7 /dev/sda7 /dev/sdb7
/dev/md8 /dev/sda8 /dev/sdb8
/dev/md11 /dev/sda11 /dev/sdb11
O próximo passo é identificar todos os metadevices. Neste cenário, como o disco id0 não possui partições, todos os metadevices estão com apenas 1 membro em funcionamento. Para identificar todos os metadevices utilizar o comando a seguir:
# for x in 1 2 5 6 7 8 11; do mdadm --detail /dev/md$x; done
** IMPORTANTE **
Todas as operações a seguir podem ser feitas com o Storage Server Software online (Cell ativa)
Para correção, será necessário excluir todos os membros com status incorreto dos metadevices. Os mesmos serão adicionados novamente após o particionamento correto do disco /dev/sda:
# mdadm --manage /dev/md5 --fail /dev/sda5 --remove /dev/sda5
# mdadm --manage /dev/md6 --fail /dev/sda6 --remove /dev/sda6
# mdadm --manage /dev/md7 --fail /dev/sda7 --remove /dev/sda7
# mdadm --manage /dev/md8 --fail /dev/sda8 --remove /dev/sda8
# mdadm --manage /dev/md2 --fail /dev/sda9 --remove /dev/sda9
# mdadm --manage /dev/md1 --fail /dev/sda10 --remove /dev/sda10
Recriar todas as partições do disco substituído (/dev/sda) para manter compatibilidade com o outro disco do RAID (/dev/sdb):
# (echo n; echo "";echo 70344;
echo n; echo "";echo 71649;
echo n; echo "";echo 71910;
echo n; echo "";echo 72171;
echo n; echo "";echo 72432;
echo n; echo "";echo 72521 ;
echo n; echo "";echo 72824 ;
echo p;echo w) |fdisk /dev/sda
partprobe
Ajustar manualemente o tipo de cada partição do disco substituído (/dev/sda):
# (echo t; echo 5; echo fd;
echo t; echo 6; echo fd;
echo t; echo 7; echo fd;
echo t; echo 8; echo fd;
echo t; echo 9; echo fd;
echo t; echo 10; echo fd;
echo t; echo 11; echo fd;
echo p;echo w) |fdisk /dev/sda
partprobe
Validar a tabela de parcionamento dos discos (/dev/sda) e (/dev/sdb)
# fdisk -l /dev/sda <-- Disco id0 (disco substituído)
Disk /dev/sda: 598.9 GB, 598999040000 bytes
255 heads, 63 sectors/track, 72824 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 15 120456 fd Linux raid autodetect
/dev/sdb2 16 16 8032+ 83 Linux
/dev/sdb3 17 69039 554427247+ 83 Linux
/dev/sdb4 69040 72824 30403012+ f W95 Ext'd (LBA)
/dev/sdb5 69040 70345 10490413+ fd Linux raid autodetect
/dev/sdb6 70346 71651 10490413+ fd Linux raid autodetect
/dev/sdb7 71652 71913 2104483+ fd Linux raid autodetect
/dev/sdb8 71914 72175 2104483+ fd Linux raid autodetect
/dev/sdb9 72176 72437 2104483+ fd Linux raid autodetect
/dev/sdb10 72438 72527 722893+ fd Linux raid autodetect
/dev/sdb11 72528 72824 2385621 fd Linux raid autodetect
# fdisk -l /dev/sdab <-- Disco id1
Disk /dev/sdb: 598.9 GB, 598999040000 bytes
255 heads, 63 sectors/track, 72824 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 15 120456 fd Linux raid autodetect
/dev/sdb2 16 16 8032+ 83 Linux
/dev/sdb3 17 69039 554427247+ 83 Linux
/dev/sdb4 69040 72824 30403012+ f W95 Ext'd (LBA)
/dev/sdb5 69040 70345 10490413+ fd Linux raid autodetect
/dev/sdb6 70346 71651 10490413+ fd Linux raid autodetect
/dev/sdb7 71652 71913 2104483+ fd Linux raid autodetect
/dev/sdb8 71914 72175 2104483+ fd Linux raid autodetect
/dev/sdb9 72176 72437 2104483+ fd Linux raid autodetect
/dev/sdb10 72438 72527 722893+ fd Linux raid autodetect
/dev/sdb11 72528 72824 2385621 fd Linux raid autodetect
Associar os novos membros / partições para os metadevices utilizados pelo RAID:
# mdadm --manage /dev/md5 --add /dev/sda5
# mdadm --manage /dev/md6 --add /dev/sda6
# mdadm --manage /dev/md7 --add /dev/sda7
# mdadm --manage /dev/md8 --add /dev/sda8
# mdadm --manage /dev/md2 --add /dev/sda9
# mdadm --manage /dev/md1 --add /dev/sda10
# mdadm --manage /dev/md11 --add /dev/sda11
Validar o status dos metadevices do RAID. Exemplo: md11
# mdadm --detail /dev/md11
/dev/md11:
Version : 0.90
Creation Time : Sat Ago 10 22:10:29 2013
Raid Level : raid1
Array Size : 2385536 (2.28 GiB 2.44 GB)
Used Dev Size : 2385536 (2.28 GiB 2.44 GB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 11
Persistence : Superblock is persistent
Update Time : Sat Ago 10 22:40:44 2013
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
UUID : db671f7c:c315bf00:497d0c27:730e4375
Events : 0.73214
Number Major Minor RaidDevice State
0 0 11 1 active sync /dev/sda11
1 8 27 1 active sync /dev/sdb11
Neste momento, todos os membros de todos os metadevices devem estar com status “active sync”, o que siginifica que os dados estão sendo rebalanceados entre o RAID. Para acompanhar o andamento da sincronização de todos os devices, pode-se utilizar o comando abaixo:
for x in 1 2 5 6 7 8 11; do mdadm --detail /dev/md$x; done
Ao término do Sincronismo, os discos id0 e id1 estarão sincronizados e o RAID reestabelecido. Como item final, marcar a partição 1 do disco /dev/sda como “bootável”:
# (echo a; echo 1;
echo p;echo w) |fdisk /dev/sda
O Provisionamento de discos no Exadata Storage Server é uma ativide que exige um certo cuidado e atenção, uma vez que qualquer falha nesse processo pode necessitar o início total do procedimento. Vale lembrar novamente que, como citado várias vezes acima, as versões mais recentes do Exadata Storage Server Software contemplam a correção automática de discos subsituídos e é um processo que se torna cada vez mais estável e confiável. De qualquer forma o conhecimento de conceitos e procedimentos manuais, pode em muitas vezes ajudar a solucionar situações críticas de manutenção de dados.
Referências
- My Oracle Support Portal
- How to Replace a Hard Drive in an Exadata Storage Server (Predictive Failure) [ID 1390836.1]
- How to Replace a Hard Drive in an Exadata Storage Server (Hard Failure) [ID 1386147.1]
- Steps to manually create cell/grid disks on Exadata V2 if auto-create fails during disk replacement [ID 1281395.1]
- New Celldisk Errors CD_FAIL [432] Poor Performance [ID 1475920.1]
- Exadata: After disk replacement ,celldisk and Griddisk is not created automatically [ID 1312266.1]
- Exadata Storage Cell Metadevice md11 degraded after replacing system disk [ID 1464056.1]
- HALRT-02004: Data hard disk predictive failure (Doc ID 1112995.1)
- Exadata Database Machine Documentation:
- Exadata Database Machine Owner’s Guide is available on the Storage Server OS image in /opt/oracle/cell/doc/welcome.html
- Sun Fire X4170, X4270, and X4275 Servers Service Manual (Servicing Customer-Replaceable Devices)
- http://docs.oracle.com/cd/E19477-01/820-5830-13/hotswap.html#50634786_83028
- Sun Fire X4270 M2 Server Product Library Documentation (includes Sun Fire X4270 M2 Server Service Manual)
- http://docs.oracle.com/cd/E19245-01/index.html
- Sun Server X3-2L Documentation Library (includes Service Manual) http://docs.oracle.com/cd/E23393_01/index.html
Abraço