Restaurando uma matriz RAID0 do Amazon EBS a partir de instantâneos tirados com um instantâneo consistente com ec2

Question

Configurei um novo servidor MySQL no Amazon EC2 e decidi armazenar meus dados em um EBS RAID0 Array. Até aí tudo bem, e eu testei tirar instantâneos desses dispositivos com um instantâneo ec2-consistente, ótimo.

Agora, como você reconstrói a matriz em uma nova instância, a partir desses instantâneos, rapidamente?

Quando você usa um instantâneo consistente com ec2 para criar um instantâneo de vários volumes, não tem como saber qual volume foi usado para cada dispositivo no RAID. Talvez eu esteja completamente errado, mas como você está distribuindo dados pelos volumes, seria razoável colocar cada novo volume no mesmo local no RAID que o volume do qual o instantâneo foi criado.

Um exemplo:

• volumes de 3 x 200 GB em um RAID0 configuração.
• vol-1 é o dispositivo / dev / sdh 0 no RAID
• vol-2 é o dispositivo / dev / sdh1 1 no RAID
• vol-3 é o dispositivo / dev / sdh2 2 no RAID

você cria um instantâneo ec2 com: ec2-consistent-snapshot <options> vol-1 vol-2 vol-3 .

Agora você tem 3 instantâneos, e a única maneira de rastrear qual dispositivo eles são examina o ID do volume de origem, em seguida, verificar em qual dispositivo o ID do volume de origem está montado como na instância e, em seguida, verificar os detalhes da configuração do RAID na instância do volume de origem.

Isto é obviamente incrivelmente manual ... e não rápido (o que obviamente torna difícil abrir uma nova instância mysql rapidamente se a outra falha. para não mencionar, você teria que gravar as posições do dispositivo no RAID no momento do snapshot, porque se a instância do volume de origem falhar, você não tem como acessar a configuração do RAID).

Então, em conclusão:

• Estou sentindo falta de como o snapshot ec2-consistent-snapshot e o RAID0 de software funcionam?
• Se não, há alguma solução / melhor prática conhecida em torno do problema de não saber a qual dispositivo / posição na matriz RAID pertence uma captura instantânea?

Espero que isso tenha sido claro e obrigado pela sua ajuda!

    

Answer 1

since you're striping data across the volumes, it would stand to reason that you have to put each NEW volume in the same location on the RAID as the volume from which the snapshot was created.

Eu testei sua premissa, e por mais lógica que possa parecer, a observação é outra.

Deixe-me detalhar isso:
Eu tenho exatamente o mesmo requisito que você. No entanto, o RAID0 que estou usando tem apenas 2 volumes.

Estou usando o Ubuntu 10 e tenho dois dispositivos EBS formando um dispositivo RAID0 formatado com XFS.

O dispositivo raid0 estava criando usando o seguinte comando:
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

Eu instalei o MYSQL e um monte de outros softwares que estão configurados para usar / dev / md0 para armazenar seus arquivos de dados.

Usando os mesmos volumes : Uma vez feito isso, eu desnortei tudo, parei o Raid e remontei assim: %código% O problema é que, independentemente da ordem de sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg , o RAID se reconstitui corretamente.

Usando instantâneos : Poste isto, eu uso /dev/sdg /dev/sgh para criar instantâneos dos 2 discos do EBS juntos. Eu, então, crio volumes deste disco, os conecto a uma nova instância (que já foi configurada para o software), remonto o RAID (também tentei trocar a ordem dos volumes do EBS), montei e estou pronto para ir.

Parece estranho, mas funciona.

    

Answer 2

Eu executo uma configuração similar ( RAID0 sobre 4 volumes EBS ) e, consequentemente, tive as mesmas preocupações para reconstituir a matriz RAID dos instantâneos criados com ec2-consistent-snapshot .

Felizmente, cada dispositivo em uma matriz de ataque contém metadados (em um superbloco) que registra sua posição na matriz, o UUID da matriz e o nível da matriz (por exemplo, RAID0). Para consultar este superbloco em qualquer dispositivo, execute o seguinte comando (a linha correspondente a '^ this' descreve o dispositivo consultado):

$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 2ca96b4a:9a1f1fbd:2f3c176d:b2b9da7c
  Creation Time : Mon Mar 28 23:31:41 2011
     Raid Level : raid0
  Used Dev Size : 0
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Mon Mar 28 23:31:41 2011
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : ed10058a - correct
         Events : 1

     Chunk Size : 256K

      Number   Major   Minor   RaidDevice State
this     0     202       17        0      active sync   /dev/sdb1

   0     0     202       17        0      active sync   /dev/sdb1
   1     1     202       18        1      active sync   /dev/sdb2
   2     2     202       19        2      active sync   /dev/sdb3
   3     3     202       20        3      active sync   /dev/sdb4

Se você fizer a mesma consulta em um dispositivo que não faz parte de uma matriz, obterá:

$ sudo mdadm --examine /dev/sda1
mdadm: No md superblock detected on /dev/sda1.

O que prova que este comando realmente depende de informações armazenadas no próprio dispositivo e não de algum arquivo de configuração.

Também é possível examinar os dispositivos de uma matriz RAID a partir do dispositivo RAID, recuperando informações semelhantes:

$ sudo mdadm --detail /dev/md0

Eu uso o mais tarde junto com ec2-describe-volumes para construir a lista de volumes para o ects-snap-snap consistente ( -n e - debug permite testar este comando sem criar instantâneos). O comando a seguir assume que o diretório / mysql é o ponto de montagem para o volume e que a região da AWS é us-west-1 :

$ sudo -E ec2-consistent-snapshot --region us-west-1 --mysql --freeze-filesystem /mysql --mysql-master-status-file /mysql/master-info --description "$(date +'%Y/%m/%d %H:%M:%S') - ASR2 RAID0 (4 volumes) Snapshot" --debug -n $(ec2-describe-volumes --region us-west-1 | grep $(wget http://169.254.169.254/latest/meta-data/instance-id -O - -q) | egrep $(sudo mdadm --detail $(awk '{if($2=="/mysql") print $1}' /etc/fstab) | awk '/ \/dev\//{printf "%s ", $7}' | sed -e 's# /#|/#g') | awk '{printf "%s ", $2}')

    

Answer 3

Eu sei que isso não responde à sua pergunta, mas estou fazendo algo semelhante, mas com a ferramenta básica ec2-create-snapshot da Amazon e um script cron. Não é tão rápido quanto um instantâneo ec2-consistente, mas eu obtenho o controle extra de que preciso: fsync, bloqueio de gravações e, o mais importante, nomeio os instantâneos apropriadamente para que eles possam ser reconstituídos na ordem correta.