Надежность EBS-дисков - RAID1 или "хуже"?

Из официальной документации Amazon по EBS-дискам до конца не ясно, надежнее ли они RAID1 или нет - всякие разговоры про функциональную зависимость объема диска и времени последнего снапшота диска - не внушают оптимизм:

Во время аварии в европейском ДЦ Amazon у нас из софтварного RAID10 вылетели сразу 2 диска из-за отключения питания в датацентре. В сети также иногда появляются жутковатые сообщения о том, что диск EBS внезапно "сломался", клиенту прислали письмо на тему "ваши данные потерялись, к сожалению" и официально рекомендуется сделать снапшот как раз за минуту перед отказом диска. Такое впечатление, что механизм снапшотов появился именно для "подстраховки" от выхода из строя не очень надежных EBS-дисков.

Публичные виртуальные машины, которые используются для создания собственных приватных образов, имеют только один EBS-диск, не состоящий в рейде и на котором находится корневой раздел. А загрузить машину с корневым разделом на софтварном рейде - мягко сказать, непросто и требует времени.

Тем не менее, за полгода в Amazon у нас не вылетел ни один диск (у нас их около 50), не считая отключения питания после удара молнии, что позволяет относиться к ним как к более-менее надежным RAID1 дискам (репликация на одно устройство, расположенное в том же датацентре), уступающим в надежности s3 (реплицируется дополнительно на 2 устройства в разных датацентрах, и вообще это не блочное устройство), но в 10 раз более надежным, чем обычные жесткие диски.

Софтварный рейд и невысокая производительность EBS-дисков

После миграции в Amazon можно столкнуться с достаточно невысокой производительностью EBS-дисков, что особенно заметно на машинах с MySQL.

"Подсмотрев" идею в RDS (Amazon автоматически, в зависимости от суммарного объема EBS-дисков, размещают информацию базы данных на софтварном рейде) и, использовав смекалку, можно перенести данные на созданный из EBS-дисков софтварный RAID10 (mdadm в Linux):

cat /proc/mdstat
Personalities : [raid10]
md0 : active raid10 sdo[0] sdj[8](S) sdi[7] sdh[6] sdg[5] sdn[4] sdm[3] sdl[2] sdk[1]
629145344 blocks 64K chunks 2 near-copies [8/8] [UUUUUUUU]

Для увеличения уровня отказоустойчивости используются софтварные рейды.

После миграции данных на рейды проблемы с производительностью дисковых подсистем на машинах перестали беспокоить.

Стоит упомянуть, что относительно недавно появились более быстрые SSD-backed диски, которые интересно потестировать на производительность.

  Кластерные файловые системы и EBS-диски

EBS-диски, как оказалось, нельзя одновременно смонтировать на несколько виртуальных машин для использования кластерной файловой системы типа OCFS2 или GFS2. Поэтому для кластеризации контента можно использовать утилиту csync2, форсированную надстройкой для "быстрой" синхронизации часто обновляемых тяжелых папок на базе inotify.

Бекап EBS-дисков

Диски виртуальной машины совсем несложно бекапить, т.к. именно для этого создан инструмент создания снапшотов блочного устройства:

ec2-create-snapshot vol-a5rtbvwe

Операция стартует очень быстро (секунды), а загрузка снапшота в s3 продолжается определенное время, в зависимости от объема диска и загруженности Amazon - до десятков минут.

Мы взрослые люди и понимаем, что целостный снапшот диска может быть если:

• Диск предварительно отмонтирован:

  umount -d /dev/sdh

• Сервер предварительно остановлен.
• Файловая система "заморожена". Хотя в этом случае нужно еще приложениям сказать, чтобы сбросили данные на диск.

Иначе мы получаем снапшот диска "как бы после внезапного выключения питания" и диск нужно будет полечить (fsck) при загрузке машины - что, благодаря, современным журналируемым файловым системам (ext3, ext4, xfs и др.) происходит незаметно и часто быстро за счет проигрывания журнала.

Мы тестировали создание снапшота диска с "живой" (без размонтирования) ext3 и xfs - после некоторой паузы для проигрывания журнала диск (созданный из снапшота) монтируется и работает.

  "Замораживание" файловой системы

В качестве файловой системы, поддерживающей "приостановку", мы выбрали xfs. Эта файловая система рекомендуется Amazon и используется утилитами создания целостного снапшота типа ec2-consistent-backup:

xfs_freeze (-f | -u) mount-point

Действительно, если после xfs_freeze -f сделать снапшот диска, то он монтируется без проигрывания журнала очень быстро.

В CentOS 6 (и видимо в других дистрибутивах с "обновленным" ядром) стало возможным "фризить" также дефолтные файловые системы типа ext3/ext4 командой fsfreeze.

  Бекап софтварного рейда

Если мыслить логически, то нужно:

1. "остановить" файловую систему рейда,
2. запустить создание снапшота для каждого физического диска рейда,
3. "отпустить" файловую систему рейда.

К сожалению, в документации к API Amazon нет информации, сколько времени должно пройти между 2) и 3). Однако опытным путем было найдено (и аналогично делается в данной утилите), что достаточно получить идентификаторы снапшотов из вызова API для каждого диска рейда и файловую систему рейда можно "разморозить" - и при сборке рейда он подхватится без ребилдинга. Иначе - начнет ребилдиться.

Вот так сделали мы:

bxc_exec("/usr/bin/ssh remote_xfs_freezer@hostname".escapeshellarg("sudo /usr/sbin/xfs_freeze -f /xfs_raid_path"));
...
ec2-create-snapshot - для каждого диска рейда
...
bxc_exec("/usr/bin/ssh remote_xfs_freezer@hostname".escapeshellarg("sudo /usr/sbin/xfs_freeze -u /xfs_raid_path"));
...
ec2-create-volume --snapshot id_of_snapshot
...
ec2-attach-volume volume_id -i instance_id -d device
...
mdadm --assemble /dev/mdN /dev/sd[a-z]

Снапшот MySQL?

Можно сбросить данные MySQL на диск: FLUSH TABLES WITH READ LOCK, зафризить файловую систему: xfs_freeze -f /path, затем выполнить API вызов снятия с дисков снапшота ec2-create-snapshot, но есть и другой, полностью устраивающий вариант - асинхронная репликация MySQL в другой ДЦ. Интересным предоставляется создание снапшотов базы с использованием xtrabackup - без вышеописанных "танцев с бубнами".

  Бекапим всю машину сразу

Если отдельно бекапить диски, группы дисков в рейдах, то, при наличии конфига - процесс работает стабильно и прозрачно. Однако, если вам нужно иногда (например, в ДЦ ударила на выходных молния) переезжать между AZ Amazon (датацентрами) - проще ввести уровень абстракции выше ID инстансов, снапшотов и дисков и оперировать категориями ролей и образов (AMI - Amazon Machine Image) машин. Через API можно назначать объектам Amazon тэги и фильтровать по ним выборки.

Мы определили роли: веб-машина, СУБД, балансировщик, машина мониторинга и наши скрипты бекапов работают примерно так:

• Найти машину с тегом "СУБД" и получить ее ID,
• "Заморозить" диски машины,
• Сделать снапшот дисков. Задать снапшоту тэг "СУБД",
• "Разморозить" диски машины,
• Для очистки устаревших снапшотов можно сделать выборку по тэгу и времени и удалить лишние.

Однако, гораздо проще бекапить работающую виртуальную машину в образ (AMI image). При этом в образе сохраняются ее настройки и пути к создаваемым снапшотам, из которых будут созданы диски машины, присоединяемые к ней при старте:

ec2-create-image id_of_instance [--no-reboot]
...
ec2-run-instances ami_image_id

Как говорится, почувствуйте разницу! Можно создать образ с машины с RAID10 из 9 дисков - одной командой, не отвлекаясь на ID ее дисков и снапшотов - вся необходимая для воссоздания машины информация записывается в образ AMI автоматически.
Единственный минус - неясно, на какое время нужно лочить диски/рейды работающей машины, чтобы создать из нее образ AMI. Опытным путем было установлено, что достаточно 2-5 секунд - если меньше, то диски/рейды начинают восстанавливаться при создании новой машины. Также очень удобно то, что поднять машину из бекапа в образ (AMI) можно в другом датацентре (AZ).

У себя мы создаем бекап всех машин нашей кластерной конфигурации (сотни гигабайт) в образ AMI два раза в сутки.

function bxc_delete_old_instance_backups( AmazonEC2 $ec2, $instanceRole = '', $bkpsMaxCount = 3) {

    if (!$instanceRole || !is_object($ec2) || $bkpsMaxCount<1 ) {
        bxc_log_error("Bad input params: ".__FUNCTION__);
        return false;
    }

    $response = $ec2->describe_images(array(
        'Filter' => array(
            array('Name' => 'tag:Role', 'Value' => 'Image:'.$instanceRole),
            array('Name' => 'state', 'Value' => 'available'),
        )
    ));

    if ( !$response->isOK() ) {
        bxc_log_amazon_error($response, __FUNCTION__.":".__LINE__);
        return false;
    }

    if ( isset($response->body->imagesSet->item) ) {

        $images = array();
        $snaps = array();

        foreach ( $response->body->imagesSet->item as $image ) {
            $images[ (string) $image->name ] = (string) $image->imageId;
            if ( isset($image->blockDeviceMapping->item) ) {
                foreach ( $image->blockDeviceMapping->item as $disk ) {
                    $snaps[ (string) $image->name ][] = $disk->ebs->snapshotId;
                }
            }
 
        }

        if ($images) {
            krsort($images);
        } else {
            bxc_log("No images with tag:Role=Image:$instanceRole");
            return true;
        }

        if ( count($images) <= $bkpsMaxCount ) {
            bxc_log("Nothing to delete");
            return true;
        }

        $imagesToDelete = array_slice($images, $bkpsMaxCount, count($images)-$bkpsMaxCount, true);
 
        foreach ($imagesToDelete as $imageName=>$imageId ) {
            $r = $ec2->deregister_image($imageId);
            if ( $r->isOK() ) {
                bxc_log("Image deleted ok: ".$imageId);

                sleep(5);//Important. Wait to ami really be deleted ;-)

                foreach ( $snaps[$imageName] as $snapId ) {
                    $rr = $ec2->delete_snapshot( $snapId );
                    if ( $rr->isOK() ) {
                        bxc_log("Snapshot deleted ok: ".$snapId);
                    } else {
                        bxc_log_amazon_error($rr, __FUNCTION__);
                        bxc_log_error("Cannot delete snapshot: ".$snapId);
                    }
                }

                
            } else {
                bxc_log_amazon_error($r, __FUNCTION__);
                bxc_log_error("Cannot delete image: ".$imageId);
            }
        }

        return true;

    } else {
            bxc_log("No images with tag:Role=Image:$instanceRole");
            return true;
    }

    return false;
}

  Админка, консоль или API

Amazon AWS имеют неплохую админку, однако многие вещи можно сделать только через API. Для Linux можно установить инструменты командной строки для работы с API Amazon, которые довольно хорошо документированы. Мы используем такие инструменты:

ls /opt/aws/
AutoScaling-1.0.39.0
ElasticLoadBalancing-1.0.14.3
ec2-api-tools-1.4.4.1
env-set.sh

Последний скрипт устанавливает переменные окружения для работы инструментов. Обратите внимание, практически каждый веб-сервис Amazon имеет свой набор утилит, которые нужно скачать и установить отдельно. Для управления машинами, например, документация находится тут, а утилиты командной строки - тут.
Пока неплохо себя показывает в работе официальный SDK для работы с API Amazon для PHP (вышеприведенный скрипт использует именно эту библиотеку).

  Выводы

С EBS-дисками Amazon можно эффективно работать, объединив их в софтварный рейд. К сожалению, нельзя замонтировать EBS-диск к нескольким виртуальным машинам, для работы с кластерной файловой системой типа OCFS2, GFS2. Бекапы как дисков, так и рейдов EBS делаются несложно, необходимо только понять основные принципы и обойти подводные камни. Удобно бекапить машины целиком, а не по отдельному диску - это позволит быстро развернуть конфигурацию в соседнем датацентре, если в ваш ДЦ ударит молния или врежется самолет.