Я работаю с системой, которая делает набор из 42 сменяющихся ежедневных снимков EBS каждого из своих многочисленных (40) томов для целей аварийного восстановления. Тома EBS объединены в том RAID. Набор согласованных снимков создается путем замораживания файловой системы на время создания снимков. Каждый отдельный том стоит всего 2 ТиБ.
Во время тестирования аварийного восстановления было обнаружено, что для копирования 20+ ТиБ данных приложения (база данных PostgreSQL, множество больших таблиц) из томов, созданных на основе моментальных снимков EBS, на новые, не являющиеся моментальными снимками, требуется более 24 часов. поддерживаемые тома. Это при значительном параллелизме в копии благодаря 8 rsync, работающим одновременно на разных поддеревьях.
Если данные не копируются на новые тома EBS, тогда приложение на основе PostgreSQL работает как муха в меду в течение многих дней, предположительно до тех пор, пока блоки тома EBS не будут загрязнены, поэтому теперь они находятся непосредственно на томе EBS, а не поступают из снимок.
Соответственно, копирование одних и тех же данных из одного набора томов EBS без поддержки моментальных снимков в другой занимает всего несколько часов, а выполнение этого с помощью «реального» оборудования аналогичного масштаба снова занимает гораздо меньше времени.
Почему я могу наблюдать такую огромную разницу в производительности между томами с резервными снимками и простыми томами?
Моя гипотеза заключается в том, что он выполняет копирование при записи, поэтому очищайте блоки, которые не меняются, поскольку снимок необходимо извлекать отдельно. Если имеется стек из 40 снимков, поддерживающих том, то, по-видимому, у него возникают некоторые трудности с быстрым обнаружением блока в самом последнем снимке, в котором он появляется, и его получением.
Есть ли способ заставить AWS эффективно и линейно предварительно заполнить весь новый том EBS из моментального снимка, вместо того, чтобы выполнять ленивое копирование при записи, как это кажется на самом деле?
Есть ли другие идеи для решения этой проблемы? Набор моментальных снимков для аварийного восстановления значительно менее полезен, если восстановление занимает больше дня.
Чтения с восстановленного тома должно хватить.
Когда вы создаете том из существующего снимка, он медленно загружается в фоновом режиме, так что вы можете сразу начать их использовать. Если вы получаете доступ к части данных, которая еще не была загружена, том немедленно загружает запрошенные данные из Amazon S3, а затем продолжает загрузку остальных данных тома в фоновом режиме.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
Как ни странно, это похоже на последовательное "принудительное чтение" с использованием dd работает лучше, чем более случайное чтение, которое было бы результатом чтения из файловой системы, но вы, конечно, можете делать и то, и другое одновременно - смонтируйте его и начните делать все, что вам нужно, но также читать и удалять из блокировать устройство с dd.
Это очевидное различие имеет смысл, особенно если инфраструктура моментальных снимков EBS на самом деле не хранит блоки моментальных снимков в блоках (4096 байт). Похоже, это был бы довольно неэффективный дизайн, требующий тысячи операций для каждого мегабайта.
Это могло бы еще больше улучшить восстановление, если бы вы выполняли несколько последовательных чтений, начиная с разных смещений. Не проверено, но GNU dd очевидно может "пропускать" блоки и начните читать не с самого начала.
Но создавать «свежие» тома точно не нужно. Как только блоки загружены при чтении, они находятся «в» EBS, а не в моментальном снимке.
Если имеется стек из 40 снимков, поддерживающих том, то, по-видимому, у него возникают некоторые трудности с быстрым обнаружением блока в самом последнем снимке, в котором он появляется, и его получением.
На самом деле не имеет значения, сколько снимков это было сделано. Данные не хранятся «в» снимках. Каждый снимок содержит полную запись того, что я небрежно называю «указателями» на все составляющие его блоки данных (а не только на измененные) и, предположительно, где они хранятся в резервном хранилище (S3), используемом инфраструктурой снимков.
Если у вас есть снимки A, B и C, сделанные по порядку с одного тома, а затем вы удаляете снимок B, все блоки, которые изменились с A на B, но не с B на C, по-прежнему доступны для восстановления снимка C, но они не перемещаются буквально из B в C, когда вы удаляете снимок B.
Когда вы удаляете снимок, EBS очищает резервное хранилище от блоков, которые больше не нужны, с помощью подсчета ссылок. Блоки, на которые не ссылается ни один моментальный снимок, обрабатываются в фоновом режиме с помощью многоэтапного процесса, который сначала помечает их как ненужные, что прекращает выставлять вам за них счет, а затем фактически удаляет их через несколько дней, когда тот факт, что они действительно at refcount = 0 подтверждено. Источник.
По этой причине количество моментальных снимков, которые изначально добавляли блоки в восстановленный том, не должно иметь причин для снижения производительности.
Дополнительная, возможно, полезная информация: приведенная ниже информация не влияет на точность вышеприведенного ответа, но может иметь значение в определенных ситуациях.
В конце 2019 года EBS анонсировала новую функцию под названием Быстрое восстановление снимка Это позволяет томам, созданным в назначенных зонах доступности из назначенных моментальных снимков, мгновенно становиться горячими без необходимости разогрева.
Использование кредитной корзины и размер назначенного моментального снимка (то есть размер дискового тома, с которого он был взят), а не размер целевого тома (который может быть больше, чем размер моментального снимка) - это Функция позволяет создавать тома размером 1024 ГБ / размер в час, поэтому моментальный снимок объемом 128 ГБ может создать 8 предварительно подогретых томов в час. По мере того, как снимки становятся меньше, количество томов, которое вы можете создать в час на снимок для каждой зоны доступности, ограничивается 10.
Услуга также поразительно дорогая - 0,75 доллара в час за снимок, за зону доступности (!?) - однако это может быть не то, что вам нужно оставить постоянно работающим, и в этом свете, похоже, есть некоторая потенциальная ценность .
Когда вы активируете функцию, услуга API может сказать вам когда он действительно готов к использованию, и 60 минут на ТиБ - это заявленное расписание для «оптимизации снимка» (что при чтении между строками означает создание и прогрев скрытого первичного тома внутри EBS из снимка, который впоследствии будет клонирован службой для создания дополнительных томов EBS; эта функция фактически может быть использована только после завершения этого этапа, а тома, созданные из одного и того же моментального снимка до этого момента, являются просто обычными томами).
Пока у вас есть время дождаться этапа «оптимизации» и процессы на месте для прекращения режима быстрого восстановления, когда он вам больше не нужен (чтобы избежать очень большого непредвиденного платежа), это, похоже, применимо в ограниченных случаи использования.