Были заданы аналогичные вопросы, но мне нужно знать, что можно было бы порекомендовать в данных обстоятельствах, чтобы знать, упускаю ли я что-то в моем понимании использования EC2.
Небольшой стартап, работающий в сети EC2, попросил меня дать совет по вариантам резервного копирования. В настоящее время они самофинансируются и делают все возможное, чтобы сократить расходы, когда это возможно. Не вдаваясь в конфигурацию их систем, я приведу в качестве примера веб-сервер; это простой веб-сервер с базой данных. Проблема в том, что они не хотят, чтобы сервер был отключен.
Человек, выполнявший настройку, считает, что ему следует либо просто делать периодические дампы базы данных и сохранять их на S3, либо создавать сценарии, которые будут восстанавливать новый сервер на Amazon, когда они необходимы, путем резервного копирования выбранных папок, содержащих информацию о конфигурации. . Он предположил, что создание моментальных снимков сервера было бы расточительным, поскольку они занимают много места на диске и, по сути, между большими дампами данных будет гниение данных, поэтому моментальный снимок быстро устареет.
Я думал сделать снимок виртуальной машины, а затем делать периодические дампы базы данных и сохранять в S3. Если бы они потеряли экземпляр EC2 или что-то вроде обновления сделало его непригодным для использования, они могли бы использовать моментальный снимок для относительно быстрого создания резервной копии сервера с последним дампом базы данных, а не начинать с нуля, чтобы построить новый экземпляр из полностью новый AMI.
Насколько я понимаю, создание снимка экземпляра EC2 (или магазина EBS) потребует простоя, чего они не хотят иметь. Я также читал, что вам следует выключить сервер, чтобы файловая система оставалась согласованной при создании снимка. Поскольку у них еще нет кластера за балансировщиком, они ограничивают возможности использования моментальных снимков.
Создание сценариев для создания серверов, если я не знаю чего-то особенного для Amazon, потребует создания сервера Chef или Puppet, который мог бы развертывать новые серверы с соответствующими ролями на EC2. Прямо сейчас у стартапа нет средств на поддержание такого рода серверов в кулуарах, и прямо сейчас им действительно не нужно развертывать такое количество серверов.
В идеале у них было бы финансирование для создания нескольких серверов за виртуальным балансировщиком или сервисом балансировщика Amazon, а затем отключать серверы по одному для выполнения обновлений или моментальных снимков. Прямо сейчас я бы нервничал при идее делать обновления, потому что если вы делаете дампы базы данных, это не поможет, если обновление системы изменяет библиотеку, на которую опирается их приложение, и служба перестает работать.
Я также предположил, что другой вариант - запустить сценарий, который создает том EBS, монтирует его, а на сервере запускает что-то вроде rsync для захвата большей части информации файловой системы на том EBS, затем сжимает и копирует содержимое на S3, отсоединяет том и уничтожьте его, чтобы сэкономить на хранении, затем сделайте дамп базы данных, чтобы уловить данные, которые в противном случае были бы несовместимыми. Для некоторых из их серверов, скорее всего, возникнет необходимость сохранять на временные тома EBS по мере роста потребностей в базе данных.
Создается песочница VMWare для воссоздания их сетевых систем в среде, где обновления можно предварительно протестировать, прежде чем применять их в производственных системах на Amazon. Я надеюсь, что это минимизирует вероятность того, что обновление системы убьет их приложение.
Итак ... учитывая ограничения на запуск одного сервера с базой данных и сервером приложений в системе, мы стремимся к тому, чтобы время простоя было как можно ближе к отсутствию (ограничение использования моментальных снимков и максимально возможный "горячий" процесс резервного копирования ( создан в реальном времени без остановки сервера), ошибаюсь ли я, предлагая запланировать время для создания моментального снимка экземпляра EC2 в его рабочем состоянии и оттуда делать дамп базы данных для копирования на S3? Есть ли лучшая стратегия для продолжения при создании живой резервной копии сервера, если снимки будут вызывать простои?
В этом вопросе есть кое-что интересное - в частности, что касается идеи простоя. Частично идея состоит в том, что если приложение чувствительно к простоям, время восстановления также должно быть учтено. (В качестве крайнего аргумента, никакие резервные копии не требуют простоя, если только вам не понадобятся эти резервные копии, и в этом случае время простоя может приближаться к бесконечности. ).
Немного о EBS
Тома и моментальные снимки EBS работают на уровне блоков - следствие этого позволяет делать снимки во время работы экземпляра, даже если том EBS используется. Однако в моментальный снимок будут включены только данные, которые фактически находятся на диске (то есть не в файловом кеше). Это последняя причина, которая дает начало идее согласованных снимков.
Интересным моментом здесь является то, что в обоих вышеупомянутых случаях вам не нужно ждать завершения моментального снимка, чтобы повторно подключиться / разморозить и возобновить запись на диск - как только моментальный снимок будет инициирован, ваши данные будут согласованы с этим моментом времени. Обычно для этого требуется всего несколько секунд, в течение которых ваш диск заблокирован от записи. Кроме того, поскольку большинство баз данных разумно структурируют свои файлы на диске - высока вероятность, что вставки имеют минимальный эффект на существующие блоки - что минимизирует данные, добавляемые в моментальный снимок.
Учитывайте смысл бэкапа
Тома EBS уже реплицируются в зоне доступности, поэтому существует определенная степень избыточности. Если ваш экземпляр завершает работу, вы можете просто присоединить том EBS к новому экземпляру и (после того, как вы преодолеете несогласованность) возобновите работу с того места, где вы остановился. Во многих отношениях это делает том EBS похожим на несогласованный моментальный снимок при условии, что у вас есть к нему доступ. Тем не менее, большинство пользователей EC2, вероятно, помнят каскадные отказы томов EBS с начала 2011 года - тома были недоступны в течение нескольких дней, а некоторые пользователи также теряли данные.
RAID1
Если вы пытаетесь защититься от сбоя диска EBS (это действительно происходит), вы можете рассмотреть вариант установки RAID1. Поскольку тома EBS являются блочными устройствами, вы можете легко использовать mdadm, чтобы настроить их в нужной конфигурации. Если один из ваших томов EBS не работает должным образом, достаточно легко вручную вывести его из строя (а позже заменить его другим томом EBS). Конечно, у этого есть недостатки - увеличенное время для каждой записи, большая подверженность изменяющейся производительности, удвоение затрат на ввод-вывод (в денежном выражении, а не с точки зрения производительности), отсутствие реальной защиты от более распространенного отказа AWS (распространенной проблемой в прошлом году было невозможность отсоединить тома EBS, которые находились в заблокированном состоянии) и, конечно, несогласованное состояние диска при сбое.
S3FS
Вариант для некоторых приложений (определенно НЕ для баз данных) - смонтировать S3 как локальную файловую систему (например, через s3fs). Это медленно, в нем отсутствуют некоторые функции, которые можно было бы ожидать от файловой системы, и он может вести себя не так, как ожидалось (возможная согласованность). Тем не менее, для простой цели, например, для обеспечения доступности загруженных файлов в разных экземплярах, это может иметь смысл. Очевидно, это не для всего, что требует хорошей производительности чтения / записи.
Бинарный журнал MySQL
Еще одна опция, специфичная для MySQL, может быть использование bin-log. Вы можете настроить второй том EBS, который будет хранить ваш bin-журнал (чтобы минимизировать влияние добавленных записей в вашу базу данных), и использовать его вместе с любыми дампами базы данных, которые вы делаете. Возможно, вы даже сможете сделать это с помощью s3fs, который действительно может иметь свои достоинства, если производительность будет приемлемой (хотя rsync, вероятно, будет лучше, чем пытаться использовать s3fs напрямую, и вы определенно захотите сжать то, что вы можете).
Однако мы снова возвращаемся к идее цели. Подумайте, что произойдет с приведенными выше предложениями:
Так что на самом деле RAID1 в основном бесполезен, а bin-log занимает слишком много времени - и то, и другое может иметь свои достоинства при определенных обстоятельствах, но далеки от идеи резервного копирования.
Снимки
Важно отметить, что моментальные снимки являются дифференциальными и хранят только фактические блоки, содержащие данные (и сжатые). В отличие от тома EBS, где, если у вас есть том 20 ГБ, но вы используете только 1 ГБ, вы все равно платите за «подготовленное» хранилище (20 ГБ). С моментальным снимком вы платите только за то, что используете. Если данные между снимками не меняются, плата (теоретически) не взимается. (Снимки оплачиваются за PUTS / GETS и использованное хранилище).
Кроме того, я настоятельно рекомендую не хранить данные вашего приложения (включая базы данных) в корневом томе (который, возможно, у вас уже есть). Одним из преимуществ является то, что, как мы надеемся, ваш корневой том претерпевает минимум изменений - это означает, что его моментальные снимки могут быть менее частыми (или будут иметь минимум изменений), что снижает стоимость и упрощает использование.
Также уместно упомянуть, что вы можете удалить старые снимки в любое время - даже если они являются дифференциальными, они не повлияют на другие снимки. Тем не менее, каждый блок, выделенный для моментального снимка, не будет отброшен до тех пор, пока не останется моментального снимка, который все еще ссылается на этот блок.
Проблема с периодическими дампами - это, во-первых, время между дампами (возможно, решается с помощью bin-log MySQL), а также сложность восстановления. Требуется время, чтобы импортировать большой дамп и воспроизвести все события из журнала. Кроме того, создание дампа влияет на производительность. Возможно, для таких дампов потребуется гораздо больше памяти, чем для моментального снимка. Настройка тома EBS исключительно для баз данных и создания моментальных снимков, что было бы предпочтительнее в большинстве случаев (при этом создание моментального снимка также оказывает некоторое влияние на производительность).
Прелесть моментальных снимков и томов EBS в том, что их можно использовать в других экземплярах. Если ваш экземпляр не загружается, вы можете присоединить корневой том к другому экземпляру, чтобы диагностировать и устранить проблему - или просто скопировать с него свои данные - и можете переключать корневые тома всего за пару минут простоя (остановите экземпляр, отсоедините корневой том, присоедините новый корневой том, запустите экземпляр). Эта же идея применима к размещению ваших данных на втором томе EBS. По сути, вы просто запускаете новый экземпляр из своего пользовательского AMI и присоединяете к нему текущий том EBS - это помогает минимизировать время простоя.
(Можно было бы привести аргумент (и я, вероятно, не рекомендовал бы это), что вы можете установить две копии MySQL на одном сервере (главный-подчиненный), используя два тома EBS, а затем выключить подчиненное устройство, чтобы сделать снимок его Объем EBS - он будет постоянным, без простоев - но затраты на производительность, вероятно, того не стоят).
AWS имеет автомасштабирование - которое сможет поддерживать постоянное количество экземпляров (даже если это число равно 1) - однако вы должны развернуть его из моментального снимка - поэтому, если ваш снимок бесполезен, то предпосылка не имеет особого смысла. .
Еще пара моментов - вы можете развернуть столько экземпляров, сколько захотите, из одного снимка (в отличие от тома EBS, который можно подключить только к одному экземпляру в любой момент времени). Кроме того, тома EBS могут использоваться только в зоне доступности, а моментальные снимки могут использоваться в пределах региона.
В идеале со снимком, если ваш сервер выходит из строя, вы можете просто запустить новый, используя последний снимок - особенно если вы отделите корневой том от данных, плохое обновление должно привести к минимуму простоя (так как вы просто перенесите том EBS, содержащий ваши данные, и сделайте его снимок, чтобы сохранить все, что может быть повреждено из-за несогласованности).
В качестве примечания Amazon заявляет, что частота отказов томов EBS увеличивается с увеличением объема данных, измененных на них с момента последнего снимка состояния.
Заключительные рекомендации
Рекомендуемая литература:
(Я действительно считаю, что написал слишком много, но недостаточно сказал - но, надеюсь, вы найдете что-то, что стоит прочитать).
Можно сделать снимок живого тома EBS, однако вы должны позаботиться о том, чтобы файловая система находилась в согласованном состоянии, а затем была заморожена на время создания моментального снимка. Не все файловые системы позволяют это, хотя это определенно возможно и является основой нашего собственного решения для резервного копирования.
Моментальные снимки EBS также довольно дешевы, поскольку они взимают плату только за измененные данные, а плата за данные очень разумна как сама по себе, так и за ее пределами. Однако имейте в виду, что это основано на изменении уровня блока, поэтому может измениться довольно быстро. Это также верно между снимками, только данные, измененные между снимками, оплачиваются. Чтобы дать вам представление о затратах, мы платим <10 долларов в месяц за хранилище моментальных снимков, и мы делаем ежедневные снимки, сохраняя последние 7 ежедневных и еженедельные снимки за последние месяцы, и у нас есть 2 сервера, следующих по этой схеме (~ 20 снимков, Жесткие диски 20 ГБ).
Как насчет дешевого недорогого решения для резервного копирования, такого как Zmanda Cloud Backup? Мы используем его для резервного копирования примерно 6 серверов и 1 SQL Server, и это всего около 10 долларов в месяц. Вы можете зашифровать свои данные с помощью самоподписанного сертификата, и они используют s3 для хранения данных (поэтому при резервном копировании из EC2 плата за передачу данных не взимается).