Восстановление массива Amazon EBS RAID0 из снимков, сделанных с помощью ec2-compatibility-snapshot

Я настроил новый сервер MySQL на Amazon EC2 и решил сохранить свои данные в массиве EBS RAID0. Пока все хорошо, и я тестировал снимки этих устройств с ec2-compatibility-snapshot, отлично.

Теперь, как быстро перестроить массив на новом экземпляре из этих снимков?

Когда вы используете ec2-compatibility-snapshot для создания моментального снимка нескольких томов, вы не можете сказать, какой том использовался для каждого устройства в RAID. Возможно, я совершенно не прав, но поскольку вы распределяете данные по томам, вполне логично, что вы должны поместить каждый НОВЫЙ том в то же место на RAID-массиве, что и том, из которого был создан моментальный снимок.

Пример:

• Тома 3x200 ГБ в конфигурации RAID0.
• vol-1 - это / dev / sdh устройство 0 в RAID
• vol-2 является / dev / sdh1 устройством 1 в RAID
• vol-3 является / dev / sdh2 устройством 2 в RAID

Вы создаете EC2 снимок с: ec2-consistent-snapshot <options> vol-1 vol-2 vol-3.

Теперь у вас есть 3 снимка, и единственный способ отследить, какое это устройство, - это посмотреть на идентификатор исходного тома, затем посмотреть, на какое устройство подключен исходный идентификатор тома, как в экземпляре, и затем проверить детали RAID. Конфигурация на экземпляре исходного тома.

Это, очевидно, невероятно ручная ... и не быстрая (что, очевидно, затрудняет быстрый запуск нового экземпляра mysql, если другой не дает результатов. Не говоря уже о том, что вам придется записывать положения устройств на RAID в то время моментального снимка, потому что в случае сбоя исходного тома у вас нет возможности добраться до конфигурации RAID).

Итак, в заключение:

• Я что-то упускаю из-за того, как работает ec2 -istent-snapshot и программный массив RAID0?
• Если нет, есть ли какие-либо известные решения / лучшие практики по проблеме не зная, какому устройству / положению в RAID-массиве принадлежит снимок?

Я надеюсь, что это было ясно, и спасибо за вашу помощь!

поскольку вы распределяете данные по томам, вполне логично, что вы должны поместить каждый НОВЫЙ том в то же место на RAID-массиве, что и том, из которого был создан моментальный снимок.

Я проверил вашу предпосылку, и, как это ни странно, логично, что наблюдение иное.

Позвольте мне уточнить это:
у меня точно такие же требования, как и у вас. Тем не менее, RAID0, который я использую, имеет только 2 тома.

Я использую Ubuntu 10 и имею 2 устройства EBS, формирующих устройство RAID0, отформатированное с помощью XFS.

Устройство raid0 создавалось с помощью следующей команды:
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

Я установил MYSQL и кучу других программ, которые настроены на использование / dev / md0 для хранения своих файлов данных.

Использование одних и тех же томов : После того, как все сделано, я размонтирую все, остановлю Raid и снова соберу его так: sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg Дело в том, что независимо от порядка /dev/sdg /dev/sghRAID восстанавливается правильно.

Использование снимков : Опубликуйте это, я использую ec2-consistent-snapshotдля создания снимков двух дисков EBS вместе. Затем я создаю тома с этого диска, присоединяю его к новому экземпляру (который уже настроен для программного обеспечения), собираю RAID (я тоже пытался поменять порядок томов EBS), монтирую его и готов идти.

Звучит странно, но это работает.

Я запустил аналогичную конфигурацию ( RAID0 на 4 томах EBS ) и, следовательно, имел те же проблемы при восстановлении массива RAID из снимков, созданных с помощью ec2-compatibility-snapshot .

К счастью, каждое устройство в массиве raid содержит метаданные (в суперблоке), которые записывают его положение в массиве, UUID массива и уровень массива (например, RAID0). Чтобы запросить этот суперблок на любом устройстве, выполните следующую команду (строка, совпадающая с '^ this', описывает запрашиваемое устройство):

$ 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

Если вы выполните тот же запрос на устройстве, которое не является частью массива, вы получите:

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

Что доказывает, что эта команда действительно опирается на информацию, хранящуюся на самом устройстве, а не на какой-то файл конфигурации.

Можно также проверить устройства RAID-массива, начиная с устройства RAID, и получить похожую информацию:

$ sudo mdadm --detail /dev/md0

Я использую его позже вместе с ec2-description-volume для построения списка томов для ec2 -istent-snaptshot ( -n и --debug позволяют протестировать эту команду без создания снимков). Следующая команда предполагает, что каталог / mysql является точкой монтирования тома, а регион 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}')

Я знаю, что это не отвечает на ваш вопрос, но я делаю что-то подобное, но с базовым инструментом Amazon ec2-create-snapshot и скриптом cron. Это не так быстро, как в ec2-compatibility-snapshot, но я получаю дополнительный элемент управления, который мне нужен: fsync, блокировка записи и, самое главное, присваивать имена снимкам соответствующим образом, чтобы они могли быть восстановлены в правильном порядке.