Продолжая тему снапшотов, затронутую в недавней статье, сегодня я расскажу о том, как Veeam Backup & Replication помогает минимизировать влияние снапшотов на «окружающую среду».
По разным причинам иногда снапшоты становятся «незримыми» для vCenter: информация о них не выводится ни в каких отчетах и не видна нигде в UI, однако сами снапшоты живут и здравствуют на СХД. Виртуальная машина преспокойно использует такой снапшот – а вот это как раз и может привести к проблемам из-за «съедаемого» места на СХД и падения производительности. Скажем прямо, проблемы, возникшие по вине снапшота-«невидимки» – достаточно частая причина обращения в саппорт.
Чтобы узнать о методах борьбы со снапшотами (видимыми и невидимыми), смотри под кат.
Крошка сын создал снапшот, и спросила кроха: «Снимок — это хорошо или это плохо?»
Как известно, в среде VMware снапшоты представляют собой дополнительные диски на СХД; на них выполняются все операции записи, пока предыдущая точка находится в состоянии «только чтение». Помимо пользы, существование снапшота влечет за собой ряд не очень приятных последствий: место на диске, занимаемое снапшотами, отнимается от ценных массивов хранения СХД, а из-за того, что чтение-запись ведется на разных виртуальных дисках, производительность виртуальных машин может упасть.
Администраторы VMware знают, что оставить снапшот виртуальной машины открытым для чтения-записи на длительное время означает с большой вероятностью создать проблему для эффективной работы виртуальной инфраструктуры. Поэтому резонно отслеживать наличие таких снапшотов, например, периодически запуская отчет Active Snapshots из пакета отчетов для VMware, входящего в решение Veeam ONE.
Это хороший способ контролировать ситуацию со снапшотами. Однако есть ситуации, когда его может оказаться недостаточно.
Кто такие снапшоты-«невидимки», и как они появляются?
Рассмотрим процесс поближе: в Veeam Backup & Replication любое задание резервного копирования или репликации начинается с создания снапшота виртуальной машины. Такой метод позволяет корректно выполнить «заморозку» (quiescence), т.е. завершить работу с данными, сохраняемыми на виртуальный диск – это гарантирует консистентность данных резервной копии. Итак, в первую очередь Veeam Backup & Replication отправляет на vCenter запрос на создание снапшота. После того, как это произошло, копируются данные «замороженного» виртуального диска целиком либо частично (если выполняется инкрементальный проход бэкапа). Затем Veeam отправляет на vCenter запрос на выполнение коммита — т.е. все изменения, которые писались в дельта-файл снапшота, пока шло копирование данных, должны быть внесены в VMDK, и снапшот должен быть удален – эта процедура называется консолидацией.
Вот тут возможен такой поворот событий: даже если vCenter отрапортовал об удалении снапшота, в реальности этого удаления могло не произойти, и незакрытый снапшот остался жить своей жизнью (причем так, что vCenter об этом не узнал), со всеми вытекающими из этого негативными последствиями. Например, попытка удаления снапшота при том, что диск виртуальной машины был приаттачен к HotAdd proxy, может стать причиной появления снапшота- «невидимки» (подробнее о HotAdd proxy см. здесь – на англ. языке).
В Veeam Backup & Replication v8 удалось побороть проблему снапшотов-«невидимок», которые мог оставить после себя проход бэкапа или репликации. Это было сделано с помощью фичи под названием Snapshot Hunter («охотник за снапшотами»). «Охотник» выслеживает такие снапшоты и автоматически их удаляет.
Что мы видим на экране?
Как только vSphere завершит (или думает, что завершила) работу со снапшотом виртуальной машины, в клиентском UI появится соответствующее уведомление:
Тут же Snapshot Hunter подключается к виртуальной инфраструктуре и читает данные с СХД, где хранятся файлы этой виртуальной машины. Если снапшот, созданный во время бэкапа, всё еще «висит» там, информация об этом выведется в сессии текущего задания в консоли Veeam Backup & Replication, и затем начинается процесс автоматической консолидации.
Наблюдать за работой «охотника» можно и в представлении History: в дереве слева находим узел System (системные задания) и отфильтровываем список системных заданий, используя строку поиска. В правой панели появится список заданий, работающих над консолидацией снапшотов. Каждое такое задание и есть «охотник за снапшотами»:
Что при этом происходит?
Сразу после того, как закончился процессинг задачи и прошёл рапорт о коммите снапшота (напомню, что в терминах Veeam Backup “задача” – это 1 виртуальная машина либо 1 виртуальный диск, если у машины их несколько), выполняется проверка по следующим условиям:
- Смотрим в vSphere на значение атрибута Needs Consolidation вируальной машины – если его значение Yes, это означает, что консолидация данных не произошла.
- Сверяем по vCenter Server database число зарегистрированных снапшотов с количеством дельта-дисков – если это разные значения, это также означает, что консолидация не прошла.
Если проверка выявила, что необходима принудительная консолидация, то сервис Veeam Backup планирует запуск системного задания (то есть «охотника» Snapshot Hunter) в отдельном потоке.
«Охотник» начинает процедуру принудительной консолидации и удаления снапшотов, действуя по следующему алгоритму (после каждого шага также выполняется проверка по описанным выше условиям):
- Сначала пытаемся использовать стандартные средства — обращаемся к Consolidate (тот же нативный механизм VMware, который срабатывает, когда в vSphere client для виртуальной машины вы выбираете команду Snapshot>Consolidate)
- Если это не помогло, то выполняем жёсткую консолидацию, то есть связку операций «создать снапшот, затем удалить» — по замыслу VMware, это должно приводить к принудительному удалению всех «невидимых» снапшотов, вне зависимости от их происхождения (остаются нетронутыми только видимые снапшоты – например, созданные пользователем)
- В конце концов выполняем жёсткую консолидацию с «заморозкой», то есть связку операций «создать снапшот, затем удалить с «заморозкой»» (должна оказать такое же воздействие на «невидимые» снапшоты, не тронув видимые).
Если этот алгоритм не приводит к желаемому результату с первого раза (проверка все равно показывает, например, что Needs Consolidation = Yes), то будет сделано еще 2 попытки с интервалом в 4 часа.
Если по истечении 12 часов снапшот все еще не удается удалить корректным образом (пройдя шаги 1-3), Veeam Backup письменно уведомит пользователя о наличии «зависшего» снапшота, поскольку, скорее всего, проблема требует ручного вмешательства. А именно — если у вас в общих настройках сконфигурирована отправка уведомлений по email (как описано здесь), вы получите письмо такого содержания:
"VM virtual_machine_name needs snapshot consolidation, but all automatic snapshot consolidation attempts have failed.
Most likely reason is a virtual disk being locked by some external process. Please troubleshoot the locking issue, and initiate snapshot consolidation manually in vSphere Client."
Или, говоря по-русски:
"Для виртуальной машины имя_ВМ необходимо выполнить консолидацию снапшота. Попытки автоматической консолидации не привели к успеху. Вероятнее всего, виртуальный диск залочен из-за какого-то внешнего процесса. Пожалуйста, выявите причину такого состояния виртуального диска и выполните консолидацию снапшота в ручном режиме, используя vSphere Client."
И что делать, если потребуется провести консолидацию самостоятельно в ручном режиме?
После того, как вы выяснили, что же именно мешает консолидации и удалению снапшота, и устранили первопричину, рекомендуется следовать процедурам, предписанным VMware.
Для каких снапшотов это работает?
Snapshot Hunter запускается для всех заданий бэкапа и репликации (для нее будут выслеживаться снапшоты на стороне источника) — как для обычных, так и для выполняемых с использованием storage snapshots; он также работает для бэкапа с vCloud Director и для VeeamZIP. При этом «отлавливаются» только снапшоты, созданные этими заданиями в ходе работы Veeam Backup & Replication, а, например, снапшоты, созданные самими пользователями, затронуты не будут.
Такой механизм применяется и для выявления тех снапшотов-«невидимок», которые возникли в ходе работы заданий Veeam Backup & Replication более старой версии.
Влияет ли работа Snapshot Hunter на производительность?
По отношению к ресурсам инфраструктуры «охотник за снапшотами» ведет себя достаточно гуманно: так, если в задание резервного копирования входит несколько машин (или одна машина, но с несколькими виртуальными дисками), то выслеживание и удаление снапшотов для них будет идти параллельно. Если, однако, при этом окажется, что СХД перегружена с точки зрения latency (то есть интенсивность чтения-записи достигла порогового значения), то «охотник» не будет запускать консолидацию, пока интенсивность операций не уменьшится.
Отмечу также, что «охотник» принимает во внимание backup window (окно резервного копирования) при условии, что для задания, ответственного за бэкап, настроено и активировано расписание (как описано здесь). В этом случае перед выполнением консолидации Snapshot Hunter уточнит, не закрылось ли отведенное для бэкапа «окно». Если при любой из трёх попыток (в том числе и первой) окажется, что консолидация не укладывается в «окно», то она не будет запущена, а вместо этого пользователь получит уведомление о необходимости ручного вмешательства.
Где же у него кнопка?
Snapshot Hunter по умолчанию всегда включен, то есть вручную ничего настраивать не нужно. Если потребуется его отключить, это можно сделать, задав значение DisableAutoSnapshotConsolidation (DWORD)=1 в ключе реестра HKLMSOFTWAREVeeamVeeam Backup and Replication. Однако если окажется, что консолидация необходима – пользователь получит нотификацию о необходимости выполнить ее самостоятельно, как описано в статье VMware КВ.
Дополнительная информация:
- Статья на Хабре о механизмах контроля интенсивности операций чтения-записи на СХД
- Статья на Хабре о создании инкрементального бэкапа «на лету»
- Видео о том, что такое HotAdd proxy, о Virtual Appliance Mode, а также о других режимах передачи данных в Veeam Backup & Replication (на русском языке)
- Раздел о Snapshot Hunter в руководстве пользователя Veeam Backup & Replication for VMware (на англ.языке)
Автор: polarowl
