Restauración de una matriz RAID0 de Amazon EBS a partir de instantáneas tomadas con una instantánea ec2-consistente

Configuré un nuevo servidor MySQL en Amazon EC2 y decidí almacenar mis datos en una matriz EBS RAID0. Hasta ahora todo bien, y he probado tomar instantáneas de esos dispositivos con una instantánea ec2-consistente, genial.

Ahora, ¿cómo reconstruye la matriz en una nueva instancia, a partir de estas instantáneas, rápidamente?

Cuando usa una instantánea ec2-consistente para crear una instantánea de múltiples volúmenes, no tiene forma de saber qué volumen se usó para cada dispositivo en el RAID. Tal vez esté completamente equivocado, pero dado que está tirando datos en los volúmenes, sería lógico que tenga que colocar cada NUEVO volumen en la misma ubicación en el RAID que el volumen desde el que se creó la instantánea.

Un ejemplo:

• Volúmenes de 3x200gb en una configuración RAID0.
• vol-1 es / dev / sdh dispositivo 0 en el RAID
• vol-2 es / dev / sdh1 dispositivo 1 en el RAID
• vol-3 es / dev / sdh2 dispositivo 2 en el RAID

se crea una instantánea con EC2: ec2-consistent-snapshot <options> vol-1 vol-2 vol-3.

Ahora tiene 3 instantáneas, y la única forma de rastrear qué dispositivo son es mirar la identificación del volumen de origen, luego ver en qué dispositivo está montada la identificación del volumen de origen como en la instancia, y luego verificar los detalles del RAID configuración en la instancia del volumen de origen.

Esto es obviamente increíblemente manual ... y no rápido (lo que obviamente hace que sea difícil abrir una nueva instancia de mysql rápidamente si la otra falla. Sin mencionar que tendría que registrar las posiciones del dispositivo en el RAID en ese momento de la instantánea, porque si la instancia del volumen de origen se bloquea, no tiene forma de acceder a la configuración RAID).

Entonces, en conclusión:

• ¿Me estoy perdiendo algo sobre cómo funciona la instantánea ec2-consistente y una matriz RAID0 de software?
• Si no es así, ¿existen soluciones conocidas / mejores prácticas en torno al problema de no saber a qué dispositivo / posición en la matriz RAID pertenece una instantánea?

Espero que esto esté claro, ¡y gracias por tu ayuda!

dado que está tirando datos a través de los volúmenes, sería lógico que tenga que colocar cada NUEVO volumen en la misma ubicación en el RAID que el volumen desde el que se creó la instantánea.

Probé su premisa, y por lógico que parezca, la observación es otra.

Déjame detallar esto:
tengo exactamente el mismo requisito que tú. Sin embargo, el RAID0 que estoy usando tiene solo 2 volúmenes.

Estoy usando Ubuntu 10 y tengo 2 dispositivos EBS formando un dispositivo RAID0 formateado con XFS.

El dispositivo raid0 se estaba creando usando el siguiente comando:
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

He instalado MYSQL y un montón de otro software que está configurado para usar / dev / md0 para almacenar sus archivos de datos.

Usando los mismos volúmenes : una vez hecho, desmonto todo, detengo la incursión y la vuelvo a armar de la siguiente manera: sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg la cuestión es que, independientemente del orden de /dev/sdg /dev/sgh, la INCURSIÓN se reconstituye correctamente.

Uso de instantáneas : publique esto, lo uso ec2-consistent-snapshotpara crear instantáneas de los 2 discos EBS juntos. Luego creo volúmenes desde este disco, lo adjunto a una nueva instancia (que ya se ha configurado para el software), vuelvo a montar el RAID (también he intentado intercambiar el orden de los volúmenes EBS), lo monte y estoy listo ir.

Suena extraño, pero funciona.

Ejecuté una configuración similar ( RAID0 sobre 4 volúmenes EBS ) y, en consecuencia, tuve las mismas preocupaciones para reconstituir la matriz RAID de las instantáneas creadas con la instantánea ec2-consistente .

Afortunadamente, cada dispositivo en una matriz de incursiones contiene metadatos (en un superbloque) que registran su posición en la matriz, el UUID de la matriz y el nivel de la matriz (por ejemplo, RAID0). Para consultar este superbloque en cualquier dispositivo, ejecute el siguiente comando (la línea que coincide con '^ this' describe el 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

Si realiza la misma consulta en un dispositivo que no forma parte de una matriz, obtendrá:

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

Lo que demuestra que este comando realmente se basa en la información almacenada en el dispositivo y no en algún archivo de configuración.

También se pueden examinar los dispositivos de una matriz RAID a partir del dispositivo RAID, recuperando información similar:

$ sudo mdadm --detail /dev/md0

Utilizo el último junto con ec2-describe-volume para construir la lista de volúmenes para ec2 -istent-snaptshot ( -n y --debug permiten probar este comando sin crear instantáneas). El siguiente comando supone que el directorio / mysql es el punto de montaje para el volumen y que la región de AWS es 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}')

Sé que esto no responde a su pregunta, pero estoy haciendo algo similar, pero con la herramienta ec2-create-snapshot base de Amazon y un script cron. No es tan rápido como la instantánea ec2-consistente, pero obtengo el control adicional que necesito: fsync, bloqueo de escritura y, lo más importante, nombrar las instantáneas adecuadamente para que puedan reconstituirse en el orden correcto.