Recuperando Software RAID Amazon AWS
Então você acaba de chegar em casa, prepara seu jantar rápido pra poder fazer qualquer outra coisa divertida pós trabalho e BOOM alertas do Nagios dizendo que seu servidor NFS está inoperante.
A Amazon possui três tipos principais de armazenamento disponíveis:
1- Disco ephemeral, um tipo de armazenamento que é apagado quando a maquina é reiniciada ou desligada abruptamente. Toda instância AWS possui uma quantidade fixa desse tipo de disco e seu tamanho varia de acordo com o tipo da instância.
2- Elastic Block Storage (EBS), que é um bloco de armazenamento anexo à instância via rede. Para o sistema operacional é exposto simplesmente como um disco local.
3- EBS com IOP's provisionados, o mesmo descrito no item 2 mas com garantia de performance. Possui custo extra por essa garantia.
Para o EBS não existe necessidade de utilizarmos RAID para garantir segurança dos dados uma vez que seu proprio subsistema possui mecânismos de redundância (mesmo assim faça seus snapshots/backups para se recuperar de uma falha do sistema).
Então quais razões são válidas para utilizar RAID em volumes EBS?
1- Solução de performance de baixo custo. Embora utilizar EBS com IOP's seja a forma correta de garantir performance, existem alguns limitadores como tamanho mínimo dos discos para garantir um determinado volumes de operações de I/O. Isso sem falar no custo. Utilizar diversos pequenos discos EBS em RAID-1 pode melhorar performance para discos de pequeno tamanho.
2- Limitação de 1TB por volume EBS. Você pode usar RAID-0 para unificar diversos discos num grande espaço de armazenamento.
3- Unificar discos efemeros. Com RAID você pode unificar diversos discos efemeros providos com suas maquinas em um unico grande disco. Por sua natureza estes discos degradam, mas o RAID pode ser simplesmente refeito nesse caso.
Embora existam usos plausíveis para RAID em instâncias AWS, nem tudo são flores. Alguns dos problemas que podem ocorrer são:
- Você não pode mais efetuar um snapshot a quente. É necessário parar o RAID completamente, fazer um freeze do sistema de arquivos e efetuar um snapshot dos discos. Dependendo da aplicação e do tamanho destes discos isso pode se tornar problemático.
- A complexidade de configuração de I/O aumenta. Se você utiliza meios de automatizar a criação de instâncias, precisa se preocupar com a configuração e uso deste sistema RAID. Complexidade de manutenção (tais como resizes) e também aumenta o risco de falhas.
Então chegamos no alarme das 22:30 e os problemas que com ele vieram. A maquina em questão era um servidor NFS e possuía dois discos EBS numa formação Software RAID-1 Linux.
Embora utilizar os comandos mdadm para manutenção destes discos seja simples, a Amazon não fornece um terminal para instâncias inicializando, apenas um dump das mensagens do console.
Distribuições Linux embora possam ser configuradas para inicializar mesmo com um RAID degradado (opção bootdegraded=true do kernel), travam esperando por uma ação do root quando o RAID falha completamente.
Infelizmente a Amazon não possui um console que permita efetuar estas operações e no máximo podemos visualizar a saida do console com a opção Get System Log do Dashboard AWS.
Para contornar essa situação, precisamos montar o disco da maquina em outro equipamento, desabilitar as configurações do RAID e inicializar a maquina com o mesmo novamente.
Considerando que você possui as ferramentas ec2 instaladas em seu sistema, segue a lista de comandos a utilizar.
A partir deste ponto a maquina deve ter inicializado normalmente apenas sem o disco RAID.
No meu caso a maquina possuía dois discos RAID e ambos foram montados estranhamente como /dev/md126 e /dev/md127. Foi necessário apenas desmontar os volumes e remontar corretamente:
Um comando útil do mdadm
Para mais explicações de como recuperar RAID "perdidos" sugiro o artigo RAID Recorvery do kernel.org e o Recovering a failed software Raid. Este segundo sendo bastante interessante na questão recuperação de dados.
O conteúdo de grande parte deste artigo foi extraído do link:
http://www.jethrocarr.com/2013/12/29/recovering-sw-raid-with-ubuntu-on-amazon-aws/
Não sei o que faria se não tivesse encontrado esta referência durante a emergência.
Outras páginas interessantes sobre o assunto:
http://help.porticor.com/kb/product-integration-and-use-cases/raid-recovery-on-linux-with-mdadm
http://www.linuxquestions.org/questions/linux-server-73/mdadm-raid-inactive-assemble-fails-with-device-or-resource-busy-4175422782/
http://ubuntuforums.org/showthread.php?t=1548546
http://ubuntuforums.org/showthread.php?t=1615217
http://serverfault.com/questions/557331/is-it-safe-to-snapshot-an-mdadm-raid-with-only-xfs-freeze
A Amazon possui três tipos principais de armazenamento disponíveis:
1- Disco ephemeral, um tipo de armazenamento que é apagado quando a maquina é reiniciada ou desligada abruptamente. Toda instância AWS possui uma quantidade fixa desse tipo de disco e seu tamanho varia de acordo com o tipo da instância.
2- Elastic Block Storage (EBS), que é um bloco de armazenamento anexo à instância via rede. Para o sistema operacional é exposto simplesmente como um disco local.
3- EBS com IOP's provisionados, o mesmo descrito no item 2 mas com garantia de performance. Possui custo extra por essa garantia.
Para o EBS não existe necessidade de utilizarmos RAID para garantir segurança dos dados uma vez que seu proprio subsistema possui mecânismos de redundância (mesmo assim faça seus snapshots/backups para se recuperar de uma falha do sistema).
Então quais razões são válidas para utilizar RAID em volumes EBS?
1- Solução de performance de baixo custo. Embora utilizar EBS com IOP's seja a forma correta de garantir performance, existem alguns limitadores como tamanho mínimo dos discos para garantir um determinado volumes de operações de I/O. Isso sem falar no custo. Utilizar diversos pequenos discos EBS em RAID-1 pode melhorar performance para discos de pequeno tamanho.
2- Limitação de 1TB por volume EBS. Você pode usar RAID-0 para unificar diversos discos num grande espaço de armazenamento.
3- Unificar discos efemeros. Com RAID você pode unificar diversos discos efemeros providos com suas maquinas em um unico grande disco. Por sua natureza estes discos degradam, mas o RAID pode ser simplesmente refeito nesse caso.
Embora existam usos plausíveis para RAID em instâncias AWS, nem tudo são flores. Alguns dos problemas que podem ocorrer são:
- Você não pode mais efetuar um snapshot a quente. É necessário parar o RAID completamente, fazer um freeze do sistema de arquivos e efetuar um snapshot dos discos. Dependendo da aplicação e do tamanho destes discos isso pode se tornar problemático.
- A complexidade de configuração de I/O aumenta. Se você utiliza meios de automatizar a criação de instâncias, precisa se preocupar com a configuração e uso deste sistema RAID. Complexidade de manutenção (tais como resizes) e também aumenta o risco de falhas.
Então chegamos no alarme das 22:30 e os problemas que com ele vieram. A maquina em questão era um servidor NFS e possuía dois discos EBS numa formação Software RAID-1 Linux.
Embora utilizar os comandos mdadm para manutenção destes discos seja simples, a Amazon não fornece um terminal para instâncias inicializando, apenas um dump das mensagens do console.
Distribuições Linux embora possam ser configuradas para inicializar mesmo com um RAID degradado (opção bootdegraded=true do kernel), travam esperando por uma ação do root quando o RAID falha completamente.
Infelizmente a Amazon não possui um console que permita efetuar estas operações e no máximo podemos visualizar a saida do console com a opção Get System Log do Dashboard AWS.
Para contornar essa situação, precisamos montar o disco da maquina em outro equipamento, desabilitar as configurações do RAID e inicializar a maquina com o mesmo novamente.
Considerando que você possui as ferramentas ec2 instaladas em seu sistema, segue a lista de comandos a utilizar.
# Para facilitar variáveis com os IDs dos equipamentos (ex: i-abcd3)
export FAILED=setme
export RECOVERY=setme
# O ID do volume raiz da maquina travada.
export VOLUME=vol-setme
# Parando a maquina com problema
# Aguardar até que esteja completamente parada para poder desanexar o disco.
ec2-stop-instances --force $FAILED
ec2-describe-instances $FAILED | grep INSTANCE | awk '{ print $5 }'
# Anexar o disco da maquina com problema à maquina de recuperação como /dev/sdo
ec2-detach-volume $VOLUME -i $FAILED
ec2-attach-volume $VOLUME -i $RECOVERY -d /dev/sdo
# Montando o volume na maquina de recuperação
ssh recoveryhost.example.com
mkdir /mnt/recovery
mount /dev/sdo /mnt/recovery
# Desligando o RAID dos scripts de inicialização initramfs/initrd
# Necessário descompactar o arquivo e modificar os arquivos dentro dele.
cp /mnt/recovery/boot/initrd.img-LATESTHERE-virtual /tmp/initrd-old.img
cd /tmp/
mkdir initrd-test
mv initrd-old.img initrd-old.img.gz
gzip -d initrd-old.img.gz
cd initrd-test
cpio –extract < ../initrd-old.img
vim scripts/local-premount/mdadm
- degraded_arrays || exit 0
- mountroot_fail || panic "Dropping to a shell."
+ #degraded_arrays || exit 0
+ #mountroot_fail || panic "Dropping to a shell."
find . | cpio -o -H newc > ../initrd-new.img
cd ..
gzip initrd-new.img
cp initrd-new.img.gz /mnt/recovery/boot/initrd.img-LATESTHERE-virtual
# Desligando o mount dos sistemas de arquivo no boot
# O sistema de arquivos falharia mesmo sem o RAID
vim /mnt/recovery/etc/fstab
- /dev/md0 /mnt/myraidarray1 xfs defaults 1 2
+ #/dev/md0 /mnt/myraidarray1 xfs defaults 1 2
- /dev/md1 /mnt/myraidarray2 xfs defaults 1 2
+ #/dev/md1 /mnt/myraidarray2 xfs defaults 1 2
# Tarefa concluída, desmontando o disco
umount /mnt/recovery
# Reanexando o disco de volta à maquina original
ec2-detach-volume $VOLUME -i $RECOVERY
ec2-attach-volume $VOLUME -i $FAILED -d /dev/sda1
# Inicializando a maquina problematica.
# Aguardar que status mude de pending para running
ec2-start-instances $FAILED
ec2-describe-instances $FAILED | grep INSTANCE | awk '{ print $5 }'
A partir deste ponto a maquina deve ter inicializado normalmente apenas sem o disco RAID.
No meu caso a maquina possuía dois discos RAID e ambos foram montados estranhamente como /dev/md126 e /dev/md127. Foi necessário apenas desmontar os volumes e remontar corretamente:
# Meus volumes e minhas nomenclaturas de disco, a sua provavelmente será diferente.
mdadm --manage --stop /dev/md126
mdadm --manage --stop /dev/md127
mdadm --assemble --force /dev/md0 /dev/xvdc1 /dev/xvdd1
mdadm --assemble --force /dev/md1 /dev/xvdb1 /dev/xvde1
# Montar os discos manualmente mount /dev/md0 /mnt/myraidarray1
mount /dev/md1 /mnt/myraidarray2
Um comando útil do mdadm
mdadm --examine /dev/sd[bcdefghijklmn]1 >> raid.status
Para mais explicações de como recuperar RAID "perdidos" sugiro o artigo RAID Recorvery do kernel.org e o Recovering a failed software Raid. Este segundo sendo bastante interessante na questão recuperação de dados.
O conteúdo de grande parte deste artigo foi extraído do link:
http://www.jethrocarr.com/2013/12/29/recovering-sw-raid-with-ubuntu-on-amazon-aws/
Não sei o que faria se não tivesse encontrado esta referência durante a emergência.
Outras páginas interessantes sobre o assunto:
http://help.porticor.com/kb/product-integration-and-use-cases/raid-recovery-on-linux-with-mdadm
http://www.linuxquestions.org/questions/linux-server-73/mdadm-raid-inactive-assemble-fails-with-device-or-resource-busy-4175422782/
http://ubuntuforums.org/showthread.php?t=1548546
http://ubuntuforums.org/showthread.php?t=1615217
http://serverfault.com/questions/557331/is-it-safe-to-snapshot-an-mdadm-raid-with-only-xfs-freeze
Comentários