Техника настройки

Рассмотрим технику настройки резервного копирования файлов и MySQL/InnoDB/XtraDB в приложениях, развернутых в облаке, на примере Amazon Web Services.

Представим себе крупный интернет-магазин, который хранит бизнес-информацию как в базе данных, так и на дисках. Новые файлы появляются ежеминутно, а общий размер контента составляет сотни гигабайт. Как делать резервные копии в таком случае?

Прежде всего разберемся в технологиях хранения данных. Для хранения данных виртуальных машин сервис Amazon предлагает виртуальные блочные устройства EBS. Такие диски очень просто создаются и подключаются к серверу в 2 клика, максимальный размер диска - 1ТБ (по умолчанию есть ограничение на 5000 дисков и 20ТБ, но его увеличивают по первой просьбе). Что же касается производительности EBS-дисков, то сразу можно сказать, что они медленнее «железных» дисков (это видно даже на простых операциях типа копирования папок с диска на диск, распаковке архивов и т.д.).

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

Для резервного копирования Amazon предлагает нам LVM и snapshot'ы в режиме "copy-on-write". Snapshot'ы блочного устройства можно делать столько раз, сколько необходимо. При этом:

• В очередной snapshot EBS-диска попадают только изменения.
• Удалять snapshot'ы можно и нужно для сохранения баланса между размером окна резервирования и стоимостью хранения данных. При этом можно удалять любой лишний snapshot - Amazon автоматически консолидирует данные нужным образом.
• Snapshot'ы дисков сохраняются в Amazon S3 - хранилище объектов любого формата, реплицирующее данные минимум еще в 2 дата-центра.
• Snapshot диска делается практически мгновенно, затем в фоне данные передаются в Amazon S3 определенное время (иногда десятки минут, если Amazon загружен).

Таким образом, мы можем делать snapshot'ы большой папки часто меняющего контента хоть каждые 5 минут и они будут надежно сохранены в Amazon S3. Если нам потребуется откатить, например, 1ТБ изменяемых данных на 5 минут назад, то мы с легкостью сделаем это сделаем следующим образом:

• сделаем диск из сохраненного snapshot'а;
• и подключим диск к серверу.

Разумеется, технически невозможно мгновенно передать 1ТБ данных из Amazon S3 в SAN, где живут EBS-диски. Поэтому, хотя блочное устройство и становится доступным операционной системе, данные на него будут заливаться в фоне определенное время и, возможно, скорость работы с диском поначалу будет не очень высокой. Но, тем не менее, такой подход позволяет удобно делать инкрементальный бекап большого объема данных и откатывать их на любую точку (например, на неделю назад с шагом в 5 минут).

Кроме возможности создания snapshot'ов с EBS-дисков, можно напрямую отправлять файлы в Amazon S3. В этом случае удобна в использовании утилита s3cmd, позволяющая синхронизировать деревья файловой системы с облаком в обоих направлениях (передаются только изменения на базе расчета md5 на локальном диске и хранения md5 объекта внутри Amazon S3 в ETag).

Snapshot RAID'а

Для хорошей производительности мы объединили EBS-диски в RAID'ы, но как же делать бекап RAID'а? Можно воспользоваться специальной утилитой ec2-consistent-snapshot (или в своих скриптах повторить ее логику) и выполнить следующие действия:

• Использовать файловую систему, поддерживающую freeze.
• Сбросить изменения и кратковременно запретить запись в файловую систему (команда fsfreeze или xfs_freeze в зависимости от типа файловой системы).
• Сделать snapshot'ы каждого диска RAID'а (AWS API call CreateSnapshot).
• Разрешить запись в файловую систему.

Для подключения сохраненного RAID'а лучше написать скрипт, подключающий диски к машине и запускающий из них программный RAID. Сохраненный в snapshot'ы вышеуказанным способом RAID прекрасно «поднимается», не проигрывая журнал файловой системы.

Snapshot машины целиком

Иногда удобнее сделать snapshot всей машины целиком. Выполняется это с помощью команды CreateImage, которая позволяет сделать snapshot в двух режимах: с остановкой машины или без. Но обратите внимание, что в последнем случае возможна порча данных на дисках или RAID'ах.

После создания snapshot'а машины появляется объект AMI (Amazon Machine Image), имеющий ссылки на сохраненные snapshot'ы каждого своего диска. Можно одной командой запустить из этого объекта сервер со всеми дисками/RAID'ами (AWS API call RunInstances). Рабочие сервера можно не только бекапить целиком, но и разворачивать из бекапа целиком со всеми RAID'ами одной командой. Однако есть серьезный «подводный камень»: команда CreateImage совершенно непрозрачна и неясно, сколько времени она снимает snapshot'ы со всех дисков сервера (скажем, секунду или 10 секунд?). Поэтому необходимо тщательно тестировать скрипт перед его использованием.

Инкрементальный бекап MySQL

Инкрементальный бекап MySQL с помощью сервиса Amazon делается следующим образом:

• Сбрасываются буферы MySQL/InnoDB/XtraDB на диск: FLUSH TABLES WITH READ LOCK.
• Сбрасываются изменения и кратковременно запрещается запись в файловую систему.
• Делается snapshot всех дисков машины: CreateImage. Но если есть опасения (см. выше про «подводный камень»), то делаются snapshot'ы каждого диска RAID'а с базой данных: AWS API call CreateSnapshot.
• Разрешается запись в файловую систему.
• Снимается глобальная блокировка всех таблиц во всех базах данных: UNLOCK TABLES.

Теперь у нас имеется объект AMI с «горячим» бекапом MySQL.

Таким образом, довольно просто делать инкрементальный бекап сервера MySQL в Amazon S3 хоть каждые 5 минут с возможностью его быстрого ввода в использование. Если сервер используется в репликации, то он восстановит базу данных как правило без особых проблем при условии, что вы не забыли в настройках задать консервативные настройки репликации (либо базу можно довольно быстро вернуть в работу вручную):

sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
sync_master_info = 1
sync_relay_log = 1
sync_relay_log_info = 1

Написание скриптов для работы с объектами сервиса Amazon

Для системного администратора имеются специальные утилиты, получающие REST-методы API сервиса Amazon. Поэтому, чтобы написать скрипт по основным действиям с сервисом Amazon, необходимо для каждого используемого веб-сервиса скачать утилиты и вызовы к ним прописать в bash-скрипте. В качестве примера рассмотрим скрипт, меняющий у сервера аппаратное обеспечение («железо»):

#!/bin/bash

#Change cluster node hw type

#Which node to change hardware?
NODE_INSTANCE_ID=$1

#To which hw-type to change?
#Some 64-bit hw types: t1.micro (1 core, 613M), m1.large (2 cores, 7.5G), m1.xlarge (4 cores, 15G),
#m2.xlarge (2 cores, 17G), c1.xlarge (8 cores, 7G)
NODE_TARGET_TYPE='c1.xlarge'

#To which reserved elastic ip to bind node?
NODE_ELASTIC_IP=$2

ec2-stop-instances $NODE_INSTANCE_ID

while ec2-describe-instances $NODE_INSTANCE_ID | grep -q stopping
do
    sleep 5
    echo 'Waiting'
done

ec2-modify-instance-attribute --instance-type $NODE_TARGET_TYPE $NODE_INSTANCE_ID

ec2-start-instances $NODE_INSTANCE_ID

ec2-associate-address $NODE_ELASTIC_IP -i $NODE_INSTANCE_ID

Для разработчиков имеются библиотеки на разных языках для работы с API сервиса Amazon (например, AWS SDK for PHP - библиотека для работы из PHP).