Я периодически делаю снимки тома EBS (Amazon Web Services Elastic Block Store) объемом 1 ТБ в качестве резервной копии. В случае, если вся зона доступности становится недоступной, мой план аварийного восстановления заключается в создании нового тома EBS из последнего моментального снимка в другой зоне доступности в том же регионе.
Как я могу узнать, сколько времени займет создание нового тома EBS? У меня RTO (целевое время восстановления) составляет 6 часов. Могу ли я встретить это с таким подходом?
Вероятно, это не должно / не имеет никакого значения, но я нахожусь в регионе ap-southeast-2 (то есть в Сиднее).
Как я могу узнать, сколько времени займет создание нового тома EBS?
Создай.
А затем попробуйте его использовать. Продолжайте использовать его в течение нескольких часов и дней и отметьте, что вы наблюдаете.
Первый ответ на ваш вопрос: на самом деле это займет всего несколько секунд.
Проблема с этим ответом в том, что он не рассказывает всей истории:
Новые тома, созданные из существующих снимков состояния EBS, загружаются в фоновом режиме. Это означает, что после создания тома из моментального снимка нет необходимости ждать, пока все данные перейдут из Amazon S3 в ваш том EBS, прежде чем ваш подключенный экземпляр сможет начать доступ к тому и всем его данным. Если ваш экземпляр получает доступ к данным, которые еще не были загружены, том немедленно загружает запрошенные данные из Amazon S3 и продолжает загрузку остальных данных в фоновом режиме.
Однако вы должны понимать, что здесь означает термин «немедленно». Сразу не означает, что громкость изначально такая же, как в конечном итоге. Помните: разница между микросекундами и миллисекундами кажется интуитивно небольшой, но все же она составляет 1000 раз.
[...] блоки хранилища на томах, которые были восстановлены из моментальных снимков, должны быть инициализированы (извлечены из Amazon S3 и записаны на том), прежде чем вы сможете получить доступ к блоку.
Это предварительное действие требует времени и может привести к значительному увеличению задержки операции ввода-вывода при первом обращении к каждому блоку.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html
Это моя точка зрения выше - для создания громкости требуется всего несколько секунд, после чего его можно использовать, но медленно.
Тома EBS являются логическими объектами. Когда том восстанавливается из моментального снимка, каждый блок на томе логически настоящее и логически доступен, как только станет доступен новый том, но не обязательно физически присутствует на томе при первой попытке его чтения.
Задержка в загрузке блоков, в целом, является небольшой платой за немедленную доступность любого конкретного блока в любом месте тома, но влияние может быть значительным, причем значимость частично зависит от того, как используется том.
Ссылка выше объясняет, как можно ускорить процесс разминки с помощью dd или fio. В документации не учитывается тот факт, что вы можете использовать любой из них в режиме только для чтения. с установленным объемом, и получите преимущество немедленной доступности, подготовив том к действию. Это будет иметь дальнейшее негативное влияние на первоначальный случайный доступ, но боль закончится раньше, чем если вы вообще ничего не сделаете, и по этой причине это, вероятно, будет вашим лучшим выбором ... но вы должны пройти свой сценарий аварийного восстановления его темпы, наблюдайте за его работой и соответственно корректируйте свою стратегию.
У Майкла, как всегда, есть отличный ответ на ваш вопрос. Вы также можете предварительно нагреть громкость, что займет немного времени, но приведет к более быстрому включению всех блоков, так что вы получите удар производительности впереди. Запуск экземпляра в другой зоне доступности, вероятно, можно было бы создать в сценарии с использованием некоторой комбинации событий, лямбда-выражения и CloudFormation или Opsworks, хотя для этого потребуются некоторые эксперименты. Однако в AWS так обычно не делают.
Еще один потенциально лучший вариант в зависимости от вашего варианта использования и бюджета - использовать эластичный балансировщик нагрузки с автоматическим масштабированием и несколькими меньшими экземплярами, распределяя ваш трафик по двум или более зонам доступности. Это означает, что в случае сбоя зоны доступности ваш другой инстанс продолжит обслуживать трафик, а ваш ELB / AS автоматически создаст больше инстансов в работающих зонах доступности. Как только первая зона доступности восстановится, она в конечном итоге снова сбалансирует нагрузку во всех зонах доступности.
Если ваше приложение работает так же хорошо на двух экземплярах меньшего размера, чем на одном большом экземпляре, это будет стоить вам немного больше для ELB с нулевым RTO. Если цена важнее доступности, вы, вероятно, захотите следовать своему первоначальному плану с исходным RTO.
Обратите внимание, что моментальные снимки хранятся в регионе в пределах AZ. Если весь регион выходит из строя, вы не можете получить к нему доступ из другого региона.
Создание моментального снимка EBS может в основном зависеть от объема, а также от чтения / записи, происходящих на диске, задержки сети (незначительное влияние). И лично я не предлагаю делать снимки корневых томов EBS в качестве резервных копий из-за проблем с ОС. Если том представляет собой диск с данными, да, вы можете использовать моментальные снимки в качестве резервной копии.
Я считаю, что ваш RTO должен быть достаточно хорошим, чтобы восстановить объем.