Моя база данных хранится в / mnt, используя временное хранилище, которое поставляется с экземпляром ec2. Чтобы сделать резервную копию с помощью инструментов api ec2, нам нужен идентификатор тома, но в консоли aws я могу найти идентификатор тома только для корневого хранилища 8 ГБ.
Что делать, если мне нужна резервная копия временного хранилища? Есть ли альтернатива для резервного копирования хранилища инстансов?
Прежде всего, вы должны никогда не хранить что-либо имеющее длительную ценность на временном хранилище в Amazon EC2., за исключением случаев, когда вы точно знаете, что делаете, и готовы всегда иметь резервные копии на определенный момент времени и т. д. - ваш вопрос кажется указывает на то, что вы можете быть ошибочно относятся к концепции эфемерного хранилища, соответствующее различие между хранилищем экземпляров Amazon EC2 Amazon EBS и важные последствия для безопасности данных и резервного копирования требования:
Эфемерное хранилище будет потеряно при циклах остановки / запуска и обычно может исчезнуть, поэтому вы определенно не хотите помещать в него что-либо долговременное, т. Е. только поместите туда временные данные, которые вы можете позволить себе легко потерять или восстановить, например, файл подкачки или строго временные данные, используемые во время вычислений. Конечно, вы можете хранить там, например, огромные индексы, но должны быть готовы перестроить их после того, как хранилище будет очищено по какой-либо причине (перезагрузка экземпляра, сбой оборудования, ...).
Эти объяснения должны прояснить, почему вы не можете выполнить резервное копирование томов временного хранилища с помощью механизма, который применяется исключительно к томам 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:
Если у вас есть возможность настроить программное зеркало RAID, вы можете подключить к экземпляру диск с поддержкой EBS, настроить зеркало, а затем дождаться завершения репликации. Я успешно использовал этот метод для перемещения «эфемерных» данных в EBS после того, как я уже создал экземпляр (и я не хотел выключаться и перезагружаться).
Когда у вас есть данные в EBS, сделайте резервную копию с образами EBS.
Этот метод особенно хорошо работает, когда у вас есть несколько копий данных, работающих на разных идентичных экземплярах, но вам нужно, чтобы в EBS сохранялась только одна из них (в моем случае, используя сервер Couchbase, данные CB были на временных дисках, но у меня был один экземпляров, отраженных в EBS, так что все данные в моем кластере оказались в EBS).
Любое решение для резервного копирования на уровне файлов (не основанное на моментальных снимках EBS) может создать резервную копию вашего эфемерного хранилища. Тем не менее, вы должны подумать, когда использовать эфемерное хранилище, и иметь веские причины использовать его для постоянных данных. Для некоторых приложений, таких как Cassandra, это рекомендуемая конфигурация. В этом случае ваше решение для резервного копирования в основном сбрасывает данные из временного хранилища на том EBS, который будет снят, или напрямую на S3. В некоторых случаях вы можете определить репликацию и убедиться, что все данные на временном устройстве также реплицируются на тома EBS.
