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