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

Eu configurei um novo servidor MySQL no Amazon EC2 e decidi armazenar meus dados em uma matriz EBS RAID0. Até agora tudo bem, e eu testei tirar instantâneos desses dispositivos com instantâneo consistente com ec2, ótimo.

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

Quando você usa o snapshot consistente com ec2 para criar um snapshot de vários volumes, não há 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 lógico que você deveria colocar cada NOVO volume no mesmo local no RAID que o volume a partir do qual o instantâneo foi criado.

Um exemplo:

• Volumes de 3x200gb em uma configuração RAID0.
• vol-1 é / dev / sdh dispositivo 0 no RAID
• vol-2 é / dev / sdh1 dispositivo 1 no RAID
• vol-3 é / dev / sdh2 dispositivo 2 no RAID

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

Agora você tem três capturas instantâneas, e a única maneira de rastrear qual dispositivo eles são é olhar o ID do volume de origem, depois olhar para qual dispositivo o ID do volume de origem está montado, como na instância, e depois verificar os detalhes do RAID. configuração na instância do volume de origem.

Isso é obviamente incrivelmente manual ... e não rápido (o que obviamente dificulta a criação rápida de uma nova instância mysql se a outra falhar. Sem mencionar, você teria que registrar as posições do dispositivo no RAID no momento do snapshot, porque se a instância do volume de origem travar, você não poderá acessar a configuração RAID).

Então, em conclusão:

• Estou faltando alguma coisa com como o snapshot ec2-consistente e uma matriz RAID0 de software funcionam?
• Caso contrário, existem soluções / práticas recomendadas conhecidas sobre o problema de não saber a qual dispositivo / posição na matriz RAID um snapshot pertence?

Espero que isso esteja claro e obrigado por sua ajuda!

como você está distribuindo dados pelos volumes, seria lógico que você deveria colocar cada NOVO volume no mesmo local no RAID que o volume a partir do qual o instantâneo foi criado.

Testei sua premissa, e por mais lógica que possa parecer, a observação é diferente.

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

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

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

Instalei o MYSQL e vários outros softwares configurados para usar / dev / md0 para armazenar seus arquivos de dados.

Usando os mesmos volumes : Uma vez feito, desmonte tudo, pare o Raid e monte-o da seguinte maneira: sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg o problema é que, independentemente da ordem /dev/sdg /dev/sgh, o RAID se reconstitui corretamente.

Usando instantâneos : Poste isso, eu uso ec2-consistent-snapshotpara criar instantâneos dos 2 discos do EBS juntos. Em seguida, crio volumes a partir deste disco, anexe-o a uma nova instância (que já foi configurada para o software), remonte o RAID (tentei trocar também a ordem dos volumes EBS), monte-o e estou pronto ir.

Parece estranho, mas funciona.

Executo uma configuração semelhante ( RAID0 acima de 4 volumes EBS ) e, consequentemente, tive as mesmas preocupações de reconstituir a matriz RAID a partir de instantâneos criados com o instantâneo consistente com ec2 .

Felizmente, cada dispositivo em uma matriz RAID contém metadados (em um superbloco) que registram sua posição na matriz, o UUID da matriz e o nível da matriz (por exemplo, RAID0). Para consultar esse 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, você obtém:

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

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

Pode-se também examinar os dispositivos de uma matriz RAID iniciando no dispositivo RAID, recuperando informações semelhantes:

$ sudo mdadm --detail /dev/md0

Eu uso o mais tarde junto com o ec2-description-volumes para criar a lista de volumes para o ec2-consistente-snaptshot ( -n e --debug permitem testar esse comando sem criar instantâneos). O comando a seguir assume que o diretório / mysql é o ponto de montagem do 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}')

Sei que isso não responde à sua pergunta, mas estou fazendo algo semelhante, mas com a ferramenta base ec2-create-snapshot da Amazon e um script cron. Não é tão rápido quanto o snapshot consistente com ec2, mas recebo o controle extra necessário: fsync, gravações de bloqueio e, o mais importante, nomeie os snapshots adequadamente para que possam ser reconstituídos na ordem correta.