Были заданы аналогичные вопросы, но мне нужно знать, что было бы рекомендовано в данных обстоятельствах, чтобы понять, что-то не хватает в моем понимании использования 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 bin-log
Еще одним параметром, специфичным для MySQL, может быть использование bin-log. Вы можете настроить второй том EBS, в котором будет храниться ваш bin-журнал (чтобы минимизировать влияние добавленных записей в вашу базу данных), и использовать его вместе с любыми дампами базы данных, которые вы принимаете. Возможно, вы даже сможете сделать это с s3fs, что может иметь смысл, если производительность приемлема (хотя rsync, вероятно, будет лучше, чем пытаться использовать s3fs напрямую, и вам определенно захочется сжать то, что вы можете).
И снова мы возвращаемся к идее цели. Рассмотрим, что произойдет с приведенными выше предложениями:
На самом деле RAID1 в основном бесполезен, а bin-log занимает слишком много времени - оба могут иметь свои преимущества при определенных обстоятельствах, но они далеки от идеи резервного копирования.
моментальные снимки
Важно отметить, что моментальные снимки являются дифференциальными и хранят только фактические блоки, которые содержат данные (и сжимаются). В отличие от тома EBS, где, если у вас том объемом 20 ГБ, но используется только 1 ГБ, вы по-прежнему платите за «подготовленное» хранилище (20 ГБ). С моментальным снимком вы платите только за то, что используете. Если данные не меняются между снимками, то (теоретически) плата не взимается. (Снимки взимаются за ПОЛОЖЕНИЯ / ПОЛУЧЕНИЯ и использованное хранилище).
Кроме того, я настоятельно рекомендую, чтобы данные вашего приложения (включая базы данных) не сохранялись на вашем корневом томе (который вы, возможно, уже настроили). Одним из преимуществ является то, что, надеюсь, ваш корневой том видит минимум изменений - это означает, что его снимки могут быть менее частыми (или будут иметь минимум изменений), что снижает стоимость и простоту использования.
Также важно упомянуть, что вы можете удалить старые снимки в любое время - даже если они являются дифференциальными, они не влияют на другие снимки. При этом каждый блок, выделенный для моментального снимка, не будет освобожден до тех пор, пока не останется моментальный снимок, который все еще ссылается на этот блок.
Проблема с периодическими дампами - это, во-первых, время между дампами (возможно, решаемое с помощью bin-журнала 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 сбор за передачу данных не взимается).
источник