Как сделать резервную копию экземпляра / эфемерного хранилища aws ec2?
Я держу свою базу данных в /mnt, используя эфемерное хранилище, которое идет с экземпляром ec2. Чтобы сделать резервную копию с помощью инструментов ec2 api, нам нужен идентификатор тома, но в консоли aws я могу найти идентификатор тома только для корневого хранилища объемом 8 ГБ.
Что мне делать, если требуется резервное копирование эфемерного хранилища? Есть ли альтернатива для резервного копирования хранилища экземпляров?
4 ответа
Прежде всего, вы никогда не должны хранить что-либо долговременное в эфемерном хранилище в Amazon EC2, за исключением тех случаев, когда вы точно знаете, что делаете, и готовы всегда иметь резервные копии на определенный момент времени и т. Д. ошибочен в отношении концепции эфемерного хранилища, соответствующей разницы между хранилищем инстансов Amazon EC2 и Amazon EBS и существенными последствиями в отношении требований к безопасности данных и резервному копированию:
Эфемерное хранилище будет потеряно во время циклов остановки / запуска и, как правило, может исчезнуть, поэтому вы определенно не хотите помещать туда что-либо, имеющее постоянную ценность, т.е. размещаете там только временные данные, которые вы можете себе позволить потерять или восстановить, например, файл подкачки. или строго временные данные, используемые во время вычислений. Конечно, вы можете хранить там огромные индексы, например, но должны быть готовы восстановить их после очистки хранилища по любой причине (перезагрузка экземпляра, аппаратный сбой, ...).
- Это одна из многих причин, по которым Эрик Хаммонд превосходно резюмировал в статье "Вам следует использовать загрузочные инстансы EBS в Amazon EC2"), в которой описывается история и различия между двумя концепциями хранения, а также дается оценка немногих оставшихся возможных преимуществ эфемерного хранилища (в основном, в изобилии и бесплатно).).
Решение проблемы
Эти пояснения должны прояснить, почему вы не можете сделать резервную копию временных томов хранения с помощью механизма, который применяется исключительно к томам EBS (то есть снимкам EBS). Соответственно, вы можете выполнить резервное копирование первого с помощью обычного инструмента резервного копирования на уровне операционной системы по вашему выбору, при этом Duplicity является популярным выбором, дополнительно облегчающим, например, Amazon S3, как указано в моем ответе на " Простое в использовании программное обеспечение для резервного копирования для живого сервера Linux".
Эфемерное хранилище или хранилище экземпляров, как есть, похоже на папку /tmp, содержимое которой исчезает после перезагрузки. Конечно, содержимое эфемерного диска не уничтожается при мягкой перезагрузке, но с ним следует обращаться так, как если бы оно было, поскольку вы не можете реально контролировать или предсказать, когда ваш экземпляр решит умереть.
На это уже указывалось.
Я хотел бы отметить, что если вы создадите и сконфигурируете свои AMI соответствующим образом, вы все равно сможете использовать эфемерное хранилище для существенного улучшения пропускной способности (чтения), при условии, что вы также сохраняете диски EBS для фактического хранилища.
На данный момент я использую экземпляры Linux (Ubuntu Tahr) с bcache. Это происходит главным образом потому, что поддержка ядра bcache является относительно новой (IIRC, первая с bcache была 3.10), и вы определенно захотите использовать как можно более свежее ядро. Кроме того, Tahr - это следующая LTS-версия Ubuntu, и она заканчивается, когда мой проект близок к запуску;)
Bcache в своей конфигурации по умолчанию позволяет получить выгоду от скорости чтения эфемерного хранилища, сохраняя при этом постоянство EBS: он использует быстрое устройство кэширования (эфемерный SSD) и использует его для ускорения медленного устройства (EBS), запись через кеш-устройство (то есть запись одновременно в эфемерный кеш и EBS).
Это означает, что в случае сбоя экземпляра или иного останова вы все равно можете подключить том EBS напрямую без кэша и получить доступ ко всем своим данным, как если бы в противном случае использовали только тома EBS. Вы также можете перенастроить теперь стертые эфемерные устройства и перенастроить их как кэш для EBS, чтобы вернуться к просмотру очень быстрых операций чтения и поиска.
Моя конкретная установка - два EBS-устройства, на которых проводился рейд в полосовом режиме с использованием mdadm + два эфемерных SSD-устройства, которые также совершали набеги таким же образом. Затем я настроил их с помощью bcache, используя эфемерный массив в качестве кеша и массив EBS в качестве "резервного" устройства. Диски EBS могут быть любого размера, и вы всегда можете расширить их (немного сложно с EC2, потому что вам нужно создать снимок текущих томов EBS, а затем создать новые более крупные тома на основе этого снимка - вы не можете изменить размер существующий том EBS).
Конечно, вам нужно будет создать скрипт, который будет запускаться внутри вашего экземпляра при запуске, чтобы сконфигурировать временное хранилище и подключить его в качестве устройства кэширования на устройстве резервного копирования с EBS. Я рекомендую читать и экспериментировать с mdadm и bcache.
Напомним, что при тестировании с помощью инструмента стресса Cassandra я получаю лучшую производительность при чтении с томов EBS, кэшированных с эфемерными дисками, чем при простом расстановке эфемерных дисков. Это из-за алгоритма, используемого в bcache, который очень умный.
Использование эфемерных накопителей в качестве кеша также снижает сетевой трафик и является экономически эффективным, поскольку снижает количество операций ввода-вывода на EBS и, следовательно, ваш ежемесячный счет.
Также обратите внимание на различные типы кэширования, которые предоставляет bcache:
- Обратная запись: используйте твердотельный накопитель в качестве устройства чтения / записи и выполняйте запись на устройство резервного копирования только в том случае, если страницы должны быть удалены из кэша. Это бесполезно для эфемерных установок EC2, так как это сделает ваше устройство резервного копирования бесполезным в случае сбоя или остановки.
- Запись через: все записи идут как в кеш, так и в резервную копию. Это гарантирует, что устройство резервного копирования всегда так же актуально, как устройство кэш-памяти, и его всегда можно использовать без устройства кэш-памяти. Полезно для EC2.
- Обработка записи: все записи идут непосредственно на устройство резервного копирования и не записываются на устройство кэш-памяти до тех пор, пока не произойдет запрос на чтение этих данных в будущем. На устройстве кешируются только операции чтения. Это так же безопасно, как и сквозная запись, и полезно, если вы знаете, что ваши записи вряд ли будут прочитаны в ближайшем будущем. Это позволяет избежать заполнения кеш-устройства данными, которые не часто запрашиваются, так что остается больше места для запрашиваемых данных. Примерами могут служить сервер загрузки файлов, система, в которой вы записываете много данных регистрации и т. Д. Если вы знаете, что весь ваш набор данных значительно больше, чем временный объем хранилища, это, скорее всего, будет наиболее эффективным вариант в большом количестве вариантов использования.
Если вы можете настроить зеркальное отображение программного RAID, вы можете прикрепить диск с EBS-поддержкой к экземпляру, настроить зеркало и дождаться завершения репликации. Я успешно использовал этот метод для перемещения "эфемерных" данных в EBS после того, как я уже создал экземпляр (и я не хотел выключаться и перезагружаться).
Получив данные на EBS, сделайте резервную копию изображений EBS.
Этот метод работает особенно хорошо, когда у вас есть несколько копий данных, работающих в разных идентичных экземплярах, но вам нужно, чтобы только одна из них была сохранена в EBS (в моем случае, при использовании сервера Couchbase, данные CB находились на временных дисках, но у меня была одна из экземпляров, отраженных в EBS, так что все данные в моем кластере оказались в EBS).
Любое решение для резервного копирования на уровне файлов (не основанное на снимках EBS) может создать резервную копию вашего временного хранилища. Тем не менее, вы должны подумать, когда использовать временное хранилище, и иметь веские основания использовать его для постоянных данных. Для определенных приложений, таких как Cassandra, это рекомендуемая конфигурация. В этом случае ваше решение для резервного копирования будет в основном выгружать данные из эфемерного хранилища на том EBS, который будет сниматься моментально, или напрямую на S3. В некоторых случаях вы можете определить репликацию и убедиться, что все данные в эфемерном устройстве также реплицируются на тома EBS.