Restauration d'une baie Amazon EBS RAID0 à partir d'instantanés pris avec ec2-consistent-snapshot

J'ai configuré un nouveau serveur MySQL sur Amazon EC2 et j'ai décidé de stocker mes données sur une baie EBS RAID0. Jusqu'à présent, tout va bien, et j'ai testé la prise d'instantanés de ces appareils avec ec2-consistent-snapshot, c'est parfait.

Maintenant, comment reconstruisez-vous rapidement la baie sur une nouvelle instance, à partir de ces instantanés?

Lorsque vous utilisez un instantané cohérent ec2 pour créer un instantané de plusieurs volumes, vous n'avez aucun moyen de savoir quel volume a été utilisé pour chaque périphérique du RAID. Je me trompe peut-être complètement, mais comme vous répartissez les données sur les volumes, il va de soi que vous devez placer chaque nouveau volume au même emplacement sur le RAID que le volume à partir duquel l'instantané a été créé.

Un exemple:

• 3 volumes de 200 Go dans une configuration RAID0.
• vol-1 est / dev / sdh périphérique 0 dans le RAID
• vol-2 est / dev / sdh1 périphérique 1 dans le RAID
• vol-3 est / dev / sdh2 périphérique 2 dans le RAID

vous créez un instantané EC2 avec: ec2-consistent-snapshot <options> vol-1 vol-2 vol-3.

Vous avez maintenant 3 instantanés, et la seule façon de retracer de quel périphérique il s'agit est de regarder l'ID de volume source, puis de voir sur quel périphérique l'ID de volume source est monté comme sur l'instance, puis de vérifier les détails du RAID configuration sur l'instance du volume source.

C'est évidemment incroyablement manuel ... et pas rapide (ce qui rend évidemment difficile de faire apparaître une nouvelle instance mysql rapidement si l'autre échoue. Pour ne pas mentionner, vous devrez enregistrer les positions des périphériques sur le RAID à l'époque d'instantané, car si l'instance de volume source plante, vous n'avez aucun moyen d'accéder à la configuration RAID).

Donc, en conclusion:

• Suis-je en train de manquer quelque chose avec la façon dont le snapshot cohérent ec2 et une matrice logicielle RAID0 fonctionnent?
• Sinon, existe-t-il des solutions / meilleures pratiques connues concernant le problème de ne pas savoir à quel périphérique / position dans la matrice RAID appartient un instantané?

J'espère que c'était clair et merci pour votre aide!

puisque vous répartissez les données sur les volumes, il va de soi que vous devez placer chaque nouveau volume au même emplacement sur le RAID que le volume à partir duquel l'instantané a été créé.

J'ai testé votre prémisse, et aussi logique que cela puisse paraître, l'observation en est autrement.

Permettez-moi de détailler ceci:
j'ai exactement la même exigence que vous. Cependant, le RAID0 que j'utilise n'a que 2 volumes.

J'utilise Ubuntu 10 et j'ai 2 périphériques EBS formant un périphérique RAID0 formaté avec XFS.

Le périphérique raid0 était en train de créer à l'aide de la commande suivante:
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

J'ai installé MYSQL et un tas d'autres logiciels configurés pour utiliser / dev / md0 pour stocker leurs fichiers de données.

En utilisant les mêmes volumes : Une fois terminé, je démonte tout, arrête le Raid et le réassemble comme ceci: sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg Le fait est que quel que soit l'ordre de /dev/sdg /dev/sgh, le RAID se reconstitue correctement.

Utilisation d'instantanés : Publiez ceci, j'utilise ec2-consistent-snapshotpour créer des instantanés des 2 disques EBS ensemble. Je crée ensuite des volumes à partir de ce disque, je l'attache à une nouvelle instance (qui a déjà été configurée pour le logiciel), je réassemble le RAID (j'ai également essayé de changer l'ordre des volumes EBS), je le monte et je suis prêt aller.

Cela semble étrange, mais cela fonctionne.

J'exécute une configuration similaire ( RAID0 sur 4 volumes EBS ) et, par conséquent, avait les mêmes préoccupations pour reconstituer la matrice RAID à partir d'instantanés créés avec ec2-consistent-snapshot .

Heureusement, chaque périphérique dans une matrice RAID contient des métadonnées (dans un superbloc) qui enregistrent sa position dans la matrice, l'UUID de la matrice et le niveau de la matrice (par exemple RAID0). Pour interroger ce superbloc sur n'importe quel périphérique, exécutez la commande suivante (la ligne correspondant à '^ this' décrit le périphérique interrogé):

$ 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 vous effectuez la même requête sur un périphérique qui ne fait pas partie d'une baie, vous obtenez:

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

Ce qui prouve que cette commande repose vraiment sur des informations stockées sur l'appareil lui-même et non sur un fichier de configuration.

On peut également examiner les périphériques d'une matrice RAID à partir du périphérique RAID, en récupérant des informations similaires:

$ sudo mdadm --detail /dev/md0

J'utilise le dernier avec ec2-decrire-volumes pour construire la liste des volumes pour ec2-consistent-snaptshot ( -n et --debug permettent de tester cette commande sans créer de snapshots). La commande suivante suppose que le répertoire / mysql est le point de montage du volume et que la région AWS est 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}')

Je sais que cela ne répond pas à votre question, mais je fais quelque chose de similaire, mais avec l'outil de base ec2-create-snapshot d'Amazon et un script cron. Ce n'est pas aussi rapide qu'un snapshot cohérent avec ec2, mais j'obtiens le contrôle supplémentaire dont j'ai besoin: fsync, verrouiller les écritures et, surtout, nommer les snapshots de manière appropriée afin qu'ils puissent être reconstitués dans le bon ordre.