Как Сделать Резервную Копию Данных И Mysql В Amazon Web Services

Всем привет! Я хотел бы поделиться своим опытом организации резервных копий файлов и MySQL/XtraDB в Amazon Web Services. Надеюсь, информация окажется полезной, особенно если вы «вынуждены» разворачивать проекты в облаке, а время ограничено :-) Но прежде всего давайте кратко рассмотрим технологии хранения данных, которые предлагает нам Amazon.



Где хранятся данные виртуальной машины?

Итак, начнем с того, что предлагает нам Amazon для хранения данных виртуальных машин — виртуальных блочных устройств.

ЭБС .

Такой диск можно легко создать и подключить к серверу в 2 клика.

Максимальный размер диска — 1 ТБ.

По умолчанию стоит ограничение в 5000 дисков и 20ТБ, но оно увеличивается.

по первому запросу .

Предлагается также технология локальных блочных устройств, данные на которых.

исчезают вместе с сервером (а это запросто может произойти в случае сбоя машины) - но я не буду об этом писать, потому что.

У нас нет Я экспериментировал с этим.



Производительность диска EBS

Сразу видно, что они медленнее «железных».

Насыщенность устройства (%util, команда iostat) при случайном объеме чтения десять-два МБ/сек (на запись — еще меньше) — быстро приближается к 100%.

Замедление хорошо заметно в таких популярных операциях, как копирование папок с диска на диск, распаковка архивов и т. д. Детали и тесты легко найти в Интернете.



Рейд?

Чтобы адекватно начать работать с дисками Amazon, проще всего «засунуть» их в программный рейд. Для баз данных мы используем RAID-10 на 8 EBS-дисках как на ext4, так и на xfs. Происходит программный рейд довольно просто , работает долго и практически не ломается.

Рейд может быть особенно полезен, если вдруг выйдет из строя диск EBS. Однако для ряда задач мы не используем рейды — например, для хранения бинарного журнала MySQL, для резервного копирования и т. д. А для хранения кеша nginx хорошо подходит RAID0 на EBS-дисках, который работает стабильно без сбоев около год.

Надежность EBS дисков

Честно говоря, за полтора года работы с EBS-дисками Amazon они ни разу нас не подвели (никакая ерунда вроде "бадов", ошибок чтения и т.п.

).

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

Долговечность вашего тома зависит как от размера вашего тома, так и от процента данных, которые изменились с момента вашего последнего снимка.

Например, для томов, которые работают с 20 ГБ или менее измененных данных с момента создания последнего моментального снимка Amazon EBS, годовая частота сбоев (AFR) может составлять от 0,1% до 0,5%, где сбой означает полную потерю тома.

Это сопоставимо с обычными жесткими дисками, которые обычно выходят из строя при AFR около 4%, что делает тома EBS в 10 раз более надежными, чем обычные стандартные жесткие диски.

С другой стороны, у нас в производстве находится более сотни загруженных EBS-дисков, и за полтора года программные рейды ни разу не выбили диски из-за ошибок IO. На «жестких» дисках, я уверен, мы бы заменили уже не одно устройство, так что выводы делайте сами.



Доступные технологии резервного копирования

Когда данных относительно мало и они не часто меняются, можно поиграться с tar. Но представьте себе крупный интернет-магазин, который хранит бизнес-информацию как в базе данных, так и в файлах на диске: новые файлы появляются каждую минуту, а общий размер контента составляет сотни гигабайт. ДРБД? Да, но мы в Amazon не пробовали эту технологию, и я часто слышу от коллег о ее невероятных замедлениях при возникновении ошибок.

ЛВМ и снимки в режиме копирования при записи — аналог этой технологии, только с дополнительными вкусностями, предлагает нам Amazon. Снимки блокировку устройства можно выполнять столько раз, сколько необходимо.

В которой:

  1. В следующий снимок диска EBS включены ТОЛЬКО ИЗМЕНЕНИЯ.

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

    Даже если у вас есть 100 снимков с диска объемом 500ГБ, но данные меняются не часто, вы платите примерно за 600-800ГБ, что конечно играет в пользу клиента.

  2. Удалять снимки можно и нужно, чтобы сохранить баланс между размером окна резервного копирования и стоимостью хранения данных.

    При этом, что вызывает восторг, удалить можно ЛЮБОЙ снимок — Amazon автоматически консолидирует данные по мере необходимости.

    И у вас совершенно не болит голова о том, где базовый снимок, а где инкрементный — не важно, ненужные вы удаляете из любой позиции (кто работал с Acronis, оценит удобство).

  3. Снимки дисков сохраняются в S3 .

    S3 — как уже наверное все знают, это хранилище объектов любого формата, реплицирующее данные как минимум ещё в 2 дата-центра.

    Те.

    Снимок диска становится практически «неуничтожимым» и хранится надежнее жесткого диска в запертом шкафчике под рабочим столом :-).

  4. Снимок диска делается практически мгновенно — затем в фоновом режиме данные передаются на S3 определенное время (иногда десятки минут — если Amazon занят).

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

делай это так:

  1. Создать диск из сохраненного снимка.

  2. Подключите диск к серверу.

Конечно, мгновенно перенести 1 ТБ данных из S3 в SAN, где живут EBS-диски, технически невозможно, поэтому хотя блочное устройство и становится доступным операционной системе, в течение определенного времени данные будут загружаться на него в фоновом режиме — поэтому скорость работы с диском поначалу может быть не очень высокой.

Но, тем не менее, согласитесь, насколько удобно сделать инкрементный бэкап большого объема данных и откатить его на любую точку, например, на неделю назад с шагом в 5 минут? :-) Помимо возможности создавать снимки с дисков EBS, вы можете отправлять файлы напрямую на S3. Простая в использовании утилита s3cmd — синхронизировать деревья файловых систем с облаком можно в обе стороны (передаются только изменения на основе расчета md5 на локальном диске и хранения объекта md5 внутри s3 в «ETag»).

Проверенные решения на основе технологий ПРЕДОХРАНИТЕЛЬ s3fs , но заметил подтормаживания и длительные зависания с увеличением ЛА при интенсивном использовании.



Снимок рейда

Как я писал выше, диски EBS показывают адекватную производительность, если объединить их в RAID0, RAID10. Как сделать резервную копию рейда? Должен ли я сделать снимок каждого диска по одному? :-) Мы понимаем, что это невозможно и Amazon нам здесь ничего не предлагает. Добрые люди написали удобную утилиту - ec2-согласованный-снимок .

Вы можете использовать его, а можете повторить его логику в скриптах.

  1. Мы используем файловую систему, поддерживающую заморозку — т.е.

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

    Такая команда( xfs_freeze ) до недавнего времени понимал XFS, но в «последние» дистрибутивы Linux появился возможность «freeze» и другие распространенные файловые системы: ext3/ext4, xfs, jfs, reiserfs.

  2. Сбрасываем изменения и ненадолго отключаем запись в ФС: «fsfreeze -f mountpoint»
  3. Создание снимков каждого рейд-диска: вызов API AWS Создать снимок .

  4. Разрешить запись в ФС: «fsfreeze -u точка монтирования»
Если у вас есть xfs, вы можете использовать команду xfs_freeze .

Для подключения сохраненного рейда лучше написать скрипт, подключение диски к машине и запускаем с них программный рейд. Рейд, сохраненный в снапшотах вышеуказанным методом, прекрасно поднимается без потери лога файловой системы — мы его используем в разных местах продакшена.

Итак, мы научились делать снимки рейдов в s3 с любым объемом данных хотя бы раз в 5 минут и восстанавливать данные из них.

Уверен, что подобные вещи многим пригодятся на различных проектах в облаке.



Снимок всей машины

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

Сделать снимок можно в 2-х режимах: с остановкой аппарата и без остановки.

В последнем случае нас логически предупреждают о возможном «порче» данных на дисках/рейдах: При создании снимка файловой системы мы рекомендуем сначала ее размонтировать.

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

Некоторые файловые системы, такие как xfs, могут заморозить и разморозить активность, чтобы можно было сделать снимок без размонтирования.

После создания снимка машины появляется объект AMI (Amazon Machine Image), который имеет ссылки на сохраненные снимки каждого из ее дисков.

Запустить сервер со всеми дисками/рейдами из этого объекта можно одной командой — вызовом API AWS. Запуск экземпляров .

Ощутили ли вы силу технологий? Рабочие сервера можно не только забэкапить целиком, но и поднять из бэкапа ПОЛНОСТЬЮ со всеми рейдами одной командой! Эта технология сэкономила нам десятки часов системного администрирования во время катастрофы Amazon в августе прошлого года — мы подняли машины из снапшотов и развернули конфигурацию в другом дата-центре.

Однако есть серьезный подводный камень — команда CreateImage совершенно непрозрачна и непонятно, сколько времени занимает создание снимков со всех дисков сервера — секунда или 10 секунд? С помощью научных исследований был выбран интервал в 5 секунд, позволяющий сделать полные снимки автомобиля с налетами.

Предупреждаю - тщательно протестируйте скрипт перед запуском его в производство - однако, согласитесь, перед "вкусностью" технологии создания полной резервной копии машины сложно устоять :-)

Инкрементное резервное копирование MySQL

Напомню нашу задачу — бэкапить проект с миллионами обращений в день и сотнями гигабайт часто меняющегося контента (самый тяжелый контент переносится на s3 и скачивается отдельно).

Повторю известные разумные подходы к резервному копированию MySQL:

  1. Логическое резервное копирование с подчиненного устройства.

    Работу основного сервера в этом случае мы не замедляем, однако.

    рискуем сделать резервную копию «случайно» десинхронизированных данных (поэтому нужно следить за синхронизацией, например с помощью pt-таблица-контрольная сумма ).

  2. Двоичный снимок с использованием LVM с рабочего/подчиненного сервера или копирование блоков на диск DRBD на резервной машине.

  3. Инкрементное двоичное резервное копирование с боевого сервера или подчиненного устройства с использованием xtrabackup или похожие платный инструмент .

Чтобы иметь возможность быстро откатить большой интернет-магазин на 5-10 минут назад в случае катастрофического удаления данных в базе (ошибочный запрос, убивающий данные в нескольких таблицах заказов - у кого с этим еще не случалось? : -) ) — похоже, подойдет только 3 вариант. Однако, как оказалось, при создании бинарной инкрементной резервной копии это оказывает значительную нагрузку на и без того слабые EBS-диски, а применение инкрементов к базовой бинарной резервной копии во время восстановления может занять.

несколько часов! Я не рассматриваю здесь сценарии восстановления из логической резервной копии с предварительным редактированием бинарного журнала MySQL — быстро это все равно не сделать.

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

  1. Сброс буферов MySQL/InnoDB/XtraDB на диск: «СБРОСИТЬ ТАБЛИЦЫ С БЛОКИРОВКОЙ ЧТЕНИЯ»
  2. Сбрасываем изменения и ненадолго отключаем запись в ФС: «fsfreeze -f mountpoint»
  3. Делаем снимок всех дисков машины: Создать изображение .

    О подводных камнях читайте выше.

    Если есть какие-либо опасения, мы делаем снимки каждого рейд-диска из базы данных: вызов AWS API Создать снимок .

  4. Разрешить запись в ФС: «fsfreeze -u точка монтирования»
  5. Убираем глобальную блокировку всех таблиц во всех базах данных: «РАЗБЛОКИРОВАТЬ ТАБЛИЦЫ».

Теперь у нас есть объект AMI с горячей резервной копией MySQL и мы сделали все возможное, чтобы он запускался из резервной копии как можно быстрее.

Таким образом, сделать инкрементный бэкап MySQL-сервера в S3 с периодичностью не менее 1 раза в 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. Для каждого используемого веб-сервиса загружается несколько утилит, а вызовы утилит записываются в 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. Вот библиотека для работы с PHP — AWS SDK для PHP .

Как видите, скриптовать работу с объектами Amazon несложно.



P.S.

Архитектура нашего проекта представлена с первого взгляда здесь .

Помимо бэкапов, думаю, стоит написать о простой технике автомасштабирования кластера и переключении трафика между дата-центрами.

22 мая мы проводим БЕСПЛАТНЫЙ семинар посвященный веб-кластерам и высоким нагрузкам, который пройдет в конференц-зале компании «1С».

Надеюсь будет интересно, приходите :-) Теги: #Системное администрирование #Веб-сервисы Amazon

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.