81  /  96

Бекапим серверы в Amazon

Просмотров: 1359 (Статистика ведётся с 06.02.2017)

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

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

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

«The durability of your volume depends both on the size of your volume and the percentage of the data that has changed since your last snapshot. As an example, volumes that operate with 20 GB or less of modified data since their most recent Amazon EBS snapshot can expect an annual failure rate (AFR) of between 0.1% – 0.5%, where failure refers to a complete loss of the volume»

Во время аварии в европейском ДЦ 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 два раза в сутки.

Очистка "устаревших" образов, вместе с их снепшотами производится скриптом:

Админка, консоль или 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 делаются несложно, необходимо только понять основные принципы и обойти подводные камни. Удобно бекапить машины целиком, а не по отдельному диску - это позволит быстро развернуть конфигурацию в соседнем датацентре, если в ваш ДЦ ударит молния или врежется самолет.


3
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии