Vmware snapshot consolidate что это
Обновлено: 02.07.2024
Снапшоты (снимки) виртуальных машины в VMWare позволяют сохранить состояние виртуального диска виртуальной машины, конфигурацию ВМ и, при необходимости, виртуальной памяти на определенный момент. Снапшоты можно создавать перед установкой обновлений, обновлением приложений или в различных тестовых сценариях. Подавляющее большинство решений по резервному копированию виртуальных машин в процессе создания резервной копии ВМ сначала создают снапшот ВМ, забирают его к себе (на диск или на ленту), а потом удаляют снапшот у ВМ. Тем самым в бэкап попадает состояние ВМ на определенный момент.
В этой статье мы покажем, как создавать в среде VMWare создавать, удалять и консолидировать снапшоты из командной строки PowerCLI.
Создаем снапшот ВМ из PowerCLI
Предположим, вы уже подключились в PowerCLI к своему серверу vCenter с помощью командлета Connect-VIServer. Для создания снапшота используется командлет New–Snapshot.
New-Snapshot -vm msk-app01 -Name beforeAppUpdate
Или можно воспользоваться конвейером:
get-vm -Name msk-app01 | New-Snapshot -Name beforeAppUpdate
В списке снапшотов ВМ появится еще один.
Можно получить список имеющихся снапшотов определенной ВМ с помощью команды:
Get-VM -name msk-app01 | Get-Snapshot | Select VM,Name,Created,SizeMB | FT
Можно получить список снапшотов за определенный период. Например, нам нужно найти все ВМ со снапшотами, созданными более 30 дней назад:
Get-VM| Get-Snapshot |Where | Select-Object VM,Name,Created,SizeGB | FT
Удаление снапшота ВМ из PowerCLI
Можно удалить снапшот с помощью командлета Remove-Snapshot.
Get-VM -Name msk-app01 | Get-Snapshot | Remove-Snapshot
Появится уведомление, в котором у вас запросится подтвердить удаление всех снапшотов.
Если вы хотите удалить только один снапшот, нужно указать его имя.
Get-VM -Name msk-app01 | Get-Snapshot -name beforeAppUpdate | Remove-Snapshot
Можно одной командой удалить все снапшоты старше 30 дней у всех ВМ в vCenter:
Запуск консолидации дисков из PowerCLI
При удалении одного или всех снапшотов (DeleteAll) у виртуальной машины, они немедленно пропадают из консоли Snapshot Manager, после чего выполняется консолидация .vmdk файлов в VMFS хранилище. Если при консолидации произойдет ошибка, старые файлы снапшотов vmdk дисков могут остаться на хранилище. Вы можете выполнить консолидацию дисков с помощью командлета Consolidation:
Про моментальные снимки (снапшоты) виртуальных машин было написано великое множество статей, где чрезмерно подробно описана теоретическая часть сего действа. В своей статье я сфокусируюсь на практической стороне вопроса и исключительно на платформе VMware vSphere.
Так зачем нужны «quiesced» * снапшоты, с чем их едят, и какие типичные проблемы с ними возникают? Взгляд на снапшоты будет представлен в первую очередь с точки зрения резервного копирования, но постараюсь в какой-то мере раскрыть и другие аспекты использования.
* Если кто готов подсказать подходящий русскоязычный термин — милости прошу в комментарии, будет хороший вариант — заменю в тексте англицизм.
Использование снапшотов для резервного копирования
- Снапшот включающий состояние памяти виртуальной машины
- Снапшот предваряемый так называемым quiescing-ом гостевой файловой системы
Собственно, альтернативный вариант и есть наша вторая опция — quiescing. Она представляет намного больший интерес и суть её в том, чтобы подготовить гостевую операционную систему (файловую систему в первую очередь) к снятию бэкапа.
Что же представляет из себя quiescing?
Если мы будем переводить официальную статью, то получится примерно следующее:
«Это процесс приведения данных на виртуальном диске в состояние „подходящее“ для резервного копирования. Данный процесс может включать в себя операции по „сливу грязных буферов“ (flushing dirty buffers) из памяти операционной системы на диск или другие высокоуровневые операции специфичные для конкретных приложений.»
Из данного описания о том, что с виртуальномй машиной происходит на самом деле понятнее не стало. Давайте разбираться сами.
Quiesced = ON, Memory = OFF
Quiesced = OFF, Memory = OFF
Вторую комбинацию мы рассматривать в данной статье не будем и сфокусируемся на процессе quiescing.
Зачем нужен quiescing?
Самый наглядный пример — это проблема USN rollback при восстановлении домен контроллера из бэкапа. Возникает она, если виртуализованный домен контроллер был забэкаплен без использования VSS (то есть без опции quiescing или других средств, которые обеспечивают запись транзакций на диск).
Никаких дополнительных действий и танцев с бубном производить не потребуется, если восстанавливать бэкап, сделанный с опцией quiescing. InvocationID будет корректно сброшен и вы увидите следующую запись в Event Log на загруженном после восстановления домен контроллере:
Event ID 1109: Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this domain controller has been changed.
Поодобное корректное поведение можно наблюдать при использовании Acronis vmProtect 9. Собственно, его мы специально тестировали в рамках резервного копирования и восстановления виртуальных машин с домен контроллером внутри.
USN rollback, очевидно, не единственная возможная проблема при использовании «сырых» снапшотов и другие приложения (например Exchange/SQL — приложения в явном виде поддерживающие VSS) могут быть подвержены сбоям при восстановлении из таких снапшотов.
Как проверить, что снапшот создается корректно с использованием VSS?
Существует несколько способов определения корректности создания консистентного (до уровня приложения) снапшота:
Самый простой способ: войти в гостевую операционную систему и проверить «Просмотр Событий» (надо же было так перевести бедный Event Viewer). После создания снапшота с опциями quiesced=ON, snapshot memory=OFF (см скриншот в начале статьи) должны присутствовать события от соответствующих VSS writers в логах приложений:
Прим.: Ошибка от VSS с Event ID 12289, которую можно заметить на скриншоте, в реальности не является проблемой. Она относится к 3.5'' диску и, чтобы от нее избавиться, достаточно убрать флопик из конфигурации виртуальной машины:
Способ посложнее: использовать компонент Datastore Browser из vSphere клиента: в папке виртуальной машины на датасторе после создания quiesced снапшота должен появиться файл***vss_manifests*.zip.
Внутри файла содержится backup.xml с описанием всех найденных VSS writers в гостевой системе + метаданные по каждому райтеру в writerX.xml.
ВАЖНО: если в vss_manifests.zip содержится только backup.xml — это как правило означает, что снапшот по факту был сделан без использования VSS. Таким образом мы плавно подходим к самому интересному: исследованию проблем со снапшотами. Ниже я перечислю основные причины неработающих снапшотов. Стоит отметить, что основную опасность представляют не неработающие снапшоты (их легко детектировать), а именно те, которые VMware рапортует как успешные, в то время как данные снапшоты не являются таковыми.
Требования к окружению
Если с полезностью опции quiescing все более менее понятно, то при практическом использовании часто возникают проблемы, как правило связанные с некорректностью изначальной конфигурации окружения. Официальное описание части требований находится здесь, и я попытаюсь раскрыть их более наглядно, чтобы было понятно куда смотреть, когда вы столкнетесь с проблемами на практике:
Во-первых, убедитесь, что ваша комбинация vSphere + гостевой ОСи поддерживается для снапшотинга с консистентностью на уровне приложений по данной табличке (взята отсюда).
Данные актуальны для vSphere 5.0 и выше. Как вы можете заметить, для самых популярных на данный момент ОС (Windows 2008 и выше) стоят звездочки — в них то и зарыта главная собака, раскопками которой мы сейчас займемся.
Во-вторых, для того, чтобы quiescing реально работал, необходимо убедиться, что VSS компоненты VMware Tools действительно установлены (и естественно VMware Tools должны быть самой актуальной версии).
На старых версиях vSphere (3.5 и ранее) для quiescing использовался в том числе Legato Sync Driver, который гарантировал консистентность на уровне файловой системы, но не на уровне приложений (для чего как раз и нужны VSS компоненты). В настоящее время этот драйвер практически не используется и повсеместно заменен на VMware Snapshot Provider. Корректность установки можно проверить в гостевой операционной системе (на виртуальной машине) по наличию сервиса VMware Snapshot Provider + соответствующего COM+ компонента.
Какие могут быть косяки на данном этапе?
Если сервис VMware Snapshot Provider отключен, либо совсем не установлен, то VMware при снятии снапшота с опциями quiescing = ON, snapshot memory = OFF отрапортует, что он успешен, однако по факту снапшот будет произведен без использования VSS внутри системы, то есть посредством Legato Sync драйвера.
Заметьте, что в случае Windows 2008 и выше поведение отличается — там подобных событий в логе не наблюдается, а просто сервис Volume Shadow Copy переходит в запущенное, а затем в остановленное состояние.
В-третьих, одной из типичных проблем настройки quiescing'а является параметр disk.EnableUUID=true в конфигурации .vmx виртуальной машины.
Эта настройка имеет смысл только для гостевых систем под управлением Windows 2008 и выше (для Windows 2003 настройка игнорируется). Дополнительной особенностью является тот факт, что данный параметр автоматически прописывается при создании новой виртуальной машины только начиная с vSphere 4.1. Другими словами если виртуальная машина была смигрирована с более старой версии vSphere, то настройки может и не быть.
При отсутствии параметра, или же если он выставлен в «false», поведение при создании снапшота будет аналогично предыдущему случаю: снапшот создастся успешно, но по факту VSS будет не задействован и в результате мы можем получить неконсистентный бэкап. Второй симптом отключенного параметра — это пустой backup.xml (без описания VSS райтеров) в vss_manifests.zip.
В-четвёртых, проверьте наличие динамических дисков внутри гостевой машины. Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОСи. Это правило действует для гостевых ОСей Windows 2008 и выше.
То же самое касается IDE дисков — их не должно быть в конфигурации виртуальной машины (но наличие IDE CD-ROM устройств допустимо и на снапшоты не влияет). При этом надо учитывать, что количество свободных SCSI слотов на одном SCSI контроллере должно быть равно количеству дисков. Например: если на SCSI1 уже присутствуют 8 SCSI дисков, то слотов не хватит.
В-пятых: Неработающий VSS внутри гостевой машины. Это основной пункт вызывающий тонны негодования и обращений в техподдержку VMware. Часто люди, видящие неудачный снапшот, грешат на VMware, хотя винить стоит совсем другого гиганта мысли — Microsoft. Примерно такую картину я получил при попытке создать quiesced снапшот машины после неудачной установки новой базы SQL (виртуальный .iso привод был отмонтирован в процессе установки, что очень не понравилось установщику. :-\
Данная проблема была решена банальной перезагрузкой виртуальной машины, и хотя такой метод помогает очень часто, бывают запущенные случаи, когда VSS внутри сломан чуть менее, чем полностью. В этих случаях самый простой способ выяснить, действительно ли Microsoft виноват — это запустить Windows Backup и сделать резервную копию системного состояния (Backup of System State, если кто привык к английским терминам). Windows Backup (или NTBackup) работает — то проблема на стороне VMware, не работает — косяк Microsoft.
У VMware на эту тему есть несколько официальных статей: например тут и тут. Но есть интересная особенность — для упрощения себе жизни (возможно есть и какие-нибудь другие причины) во второй статье VMware в явном виде рекомендует выставить disk.EnableUUID в «false», что означает отказ от использования VSS при создании quiesced снапшота («quiesced-то не настоящий!»). В общем случае такой метод является не решением, а только временным обходным путем, так как последствия подобного подхода могут проявить себя при восстановлении, то есть именно тогда, когда консистентность приложений является ключевой (вспомнить хотя бы тот же USN rollback).
Подводим итоги
По моему опыту, самыми частыми проблемами при создании снапшотов (их неконсистентность) являются пункты 2, 3 и 5, в то время как IDE или динамические диски встречаются гораздо реже.
Конечно же, не исключены и совершенно мистические случаи: например снапшот не создавался (VMware рапортовала невнятную ошибку) по причине того, что iSCSI LUN (датастор), на котором располагалась проблемная виртуальная машина, был подключен физически через 2 сетевые карты в режиме teaming и при этом одна работала на 100MBit, а вторая на 1Gbit.
Тему quiesced снапшотов можно копать чуть ли не вечность — чего стоит хотя бы факт того, что Windows 2008 при создании quiesced снапшота создает не одну, а две дельты на датасторе и по факту пишет в уже созданный снапшот (это, кстати, одна из корневых причин звездочек напротив данных ОСей в табличке выше); или наличие возможности отключать определенные VSS райтеры через конфигурацию vmbackup.conf на гостевой системе. Мир чудесен и удивителен, но граблей хватит на всех. Если будет желание — я с радостью напишу что-нибудь ещё на эту тему. Как обычно, комментарии привествуются, уточнения — тоже, об ошибках и опечатках — в личку, на вопросы постараюсь ответить asap.
Не забывайте подписываться на наш Хаб, у нас запланировано огромное количество статей на тему бэкапа и восстановления данных, быть может, именно наши статьи помогут вам решить определённые проблемы (а лучше — избежать их). Спасибо за внимание. :)
Предупреждение ‘Virtual Machine disks consolidation is needed’ на вкладке Summary виртуальной машины в консоли VMWare vSphere означает, что при удалении снапшота (операция Delete или Delete All) не удалились корректно (остались на диске) файлы виртуальных vmdk файлов снапшотов или логи. В результате не удается выполнить резервное копирование виртуальной машины.
Самые распространённые причины появления ошибки «Virtual Machine disks consolidation is needed»:
- Плохая производительность дискового хранилища, из-за которого удаление/консолидация снапшотов отваливаются по таймауту или большой размер снапшота;
- На VMFS хранилище недостаточно места для выполнения консолидации;
- vSphere или стороннее приложение (как правило это приложение резервного копирования, HP DataPtotector, Veeam или Netapp VSC) заблокировало файлы снапшотов. Убедитесь, что отсутствует запушенные процессы резервного копирования виртуальной машины;
- Проблемы с потерей подключения (возможно временные) между серверов vCenter и хостом ESXi;
Для исправления ошибки «Virtual machine Consolidation Needed status «необходимо щелкнуть ПКМ по виртуальной машине и выбрать в меню пункт ВМ -> Snapshots -> Consolidate.
Появится окно с запросом:
This operation consolidates all redundant redo logs on your virtual machine. Are you sure you want to continue?
Подтверждаем удаление избыточных логов. После этого vCenter выполнит консолидацию дисков и очистку логов. Процесс консолидации может занять несколько минут, в течении которых производительность ВМ может ухудшиться.
После этого предупреждение о необходимости консолидации ВМ исчезнет.
В некоторых случая при выполнении консолидации в консоли vSphere может появится ошибка:
Unable to access file since it is locked. An error occurred while consolidating disks: Failed to lock the file. Consolidation failed for disk node ‘scsi0:0’: Failed to lock the file.
VMware в этом случае рекомендует выполнить перезапуск агентов Management agents на сервере ESXi. Для этого нужно подключиться к хосту по SSH и выполнить команду:
Однако вы можете попробовать разблокировать файлы виртуальной машины так:
Вы можете найти все виртуальные машины, которые требуют консолидации с помощью PowerCLI. Для этого подключитесь к своему серверу vCenter:
Теперь можно выполнить консолидацию дисков всех полученных машин:
Просто удалите все снапшоты. ВМ останется в текущем состоянии.
Спасибо за быстрый ответ!
А ВМ при этом нужно выключать или должна работать?
Не важно 🙂 Но при выключенной ВМ консолидация и удаление снапшотов выполняется быстрее.
По-хорошему, указывать, что это перевод статьи xxx даже картинки их.
Здравствуйте, возникла небольшая проблема со снапшотами. Veeam Backup хотел сделать резервную копию виртуальной машины но выдал ошибку в процессе работы. В виртуальной машине подключённые HDD заканчиваются на 000001 но в Snaphot Manager нет никаких снапшотов. Место на datastore заканчивается но новые диски с 000001 растут понемножку в объёме. И вот вопрос когда закончиться место на datastore виртуалки не запустятся как можно удалить эти снапшоты но так чтоб потом можно было запустить виртуалки. Поменять в настойках VM путь к нормальных дискам без 00001 но тогда навернека не будет видно последних изменений?
Вышеописанные способы не помогли(
Мне помогло:
1) Выключить VM;
2) Удалить ее из перечня (Remuve from Inventory);
3) Зарегистрировать ее повторно (зайти через vCenter в папку с VM; найти файл с расширением VMX и зарегистрировать);
4) Повторить консолидацию.
Veeam Availability Suite v8 включает в себя гораздо больше новых возможностей по сравнению с предыдущей версией, чем может показаться на первый взгляд. Сегодня речь пойдет о детекторе снапшотов (snapshot hunter) — новой полезной функциональности для администраторов VMware.
Снапшоты: любить или ненавидеть?
Технология работы снапшотов, в сочетании с другими технологиями VMware (vMotion, HA, итд… ) стала тем двигателем прогресса, благодаря которому виртуализация стала настолько популярной. Идея снапшотов насколько очевидна, что сегодня мы воспринимаем её как должное и уже не можем вспомнить, что делали без неё.
Снапшоты – это временные снимки состояния виртуальных машин (ВМ). После создания снапшота диск ВМ переходят в режим «только чтение», а все операции записи записываются на временный диск — файл снапшота. Таком образом, очень легко «откатить» ВМ к моменту создания снапшота, когда это потребуется.
Возможности, которые предоставляет такая функциональность, потрясают — она дает чувство контроля над временем! Установили обновление для ОС, но что-то пошло не так? Просто нажмите кнопку и верните ВМ к исходному состоянию, как будто ничего не случилось. Своего рода машина времени для виртуальной инфраструктуры.
Но чем больше мы используем снапшоты, чем больше мы открываем их “темную” сторону. Cнапшоты занимают место на СХД и могут снизить производительность ВМ при определенных условиях. Это может произойти, так как чтение и запись информации с ВМ происходит с двух разных дисков вместо одного изначально, а сам файл снапшота растет пропорционально интенсивности использования ВМ.
Администраторы VMware знают, что оставленный без присмотра и забытый снапшот — это одна из самых страшных вещей, которые могут случиться с системой. Поэтому отчет об активных снапшотах (Active snapshots report) в приложении Veeam ONE, позволяющий отслеживать такие активности — один из самых часто используемых отчетов:
С помощью это отчета мы можем держать снапшоты под контролем и избегать возможных проблем, но достаточно ли этого? На самом деле нет.
Потерянные снапшоты
По ряду причин vCenter может «потерять» снапшот. Снапшоты могут существовать на СХД, но мы не увидим никакой информации об этом через графический интерфейс vCenter. Это приведет к потере производительности ВМ, а также чрезмерному потреблению места на СХД этой виртуальной машиной.
Расскажем про одну из самых частых проблем, которую мы наблюдаем при обращении пользователей в службу технической поддержки.
В Veeam Backup & Replication любое задание начинается с создания снапшота ВМ. Так программа гарантирует корректную “заморозку” данных на дисках ВМ и обеспечивает их консистентность в резервной копии. В начале задания Veeam Backup & Replication посылает запрос на создание снапшота ВМ в vCenter, и, затем, копирует данные с “замороженного” виртуального диска. По окончании копирования отправляется второй запрос в vCenter на применение данных снапшота (snapshot commit) к диску и удаление снапшота.
На этом этапе может появиться проблема. Даже если vCenter отчитался об успешно проведенной операции по удалению снапшота, снимок мог остаться жить своей жизнью, расти и мешать системе. Иногда vCenter не может получить информацию об этом событии и предупредить администратора о потенциальной опасности.
Детектор снапшотов
Мы разработали детектор снапшотов, который в автоматическом режиме следит за появлением снапшотов-«невидимок» и удаляет их при необходимости.
В этот же момент детектор снапшотов подключается к виртуальной инфраструктуре и считывает данные СХД, где хранятся файлы этой ВМ. Если снапшот, созданный во время резервного копирования, всё ещё находится на СХД, то детектор уведомляет об этом сервер резервного копирования, а пользователь получает оповещение в интерфейсе программы. После этого начинается процесс удаления снапшота.
Для каждой следующей попытки будет применен такой алгоритм:
- “Мягкая консолидация” (обращаемся к нативному механизму консолидации VMware)
- “Жёсткая консолидация без заморозки” (создание и удаление снапшота-помощника)
- “Жёсткая консолидация с заморозкой” (создание и удаление снапшота-помощника с «заморозкой»)
Если и через 12 часов снапшот всё ещё не удален, детектор снапшотов уведомляет пользователя о “зависшем” снапшоте, так как существует вероятность, что проблема может быть решена только вручную. При настроенных письменных уведомлениях вы получите электронное письмо следующего содержания:
“ВМ (имя ВМ) нуждается в консолидации снапшотов, так как все автоматические попытки не привели к успеху. Скорее всего, причина в том, что файл снапшота заблокирован внешним процессом. Пожалуйста, выявите причину блокировки и устраните её в ручном режиме.”
Проверить активность детектора можно через интерфейс программы, на вкладке “история — система” (history — system). Используйте ключевое слово “snapshot”, чтобы отфильтровать только операции детектора снапшотов.
Каждое задание консолидации (VM snapshot consolidation) — это попытка детектора снапшотов удалить “зависший” снапшот.
Детектор снапшотов полностью автоматизирован, и вам ничего не нужно дополнительно настраивать. Он ищет и проверяет только те снапшоты, которые были созданы в результате деятельности заданий резервного копирования и репликации. Таким образом, пользовательские снапшоты не будут затронуты. Также детектор снапшотов использует «умный» алгоритм работы: в случае достижения максимального количества снапшотов на СХД или максимальной латентности по операциям ввода-вывода, детектор будет ждать изменения ситуации на СХД, чтобы начать консолидацию.
Помимо всего прочего, перед началом очередного цикла детектор проверяет не закрыто ли «окно резервного копирования», чтобы провести консолидацию строго в отведенное ей время.
Вдобавок, следует заметить, что детектор работает в соответствии с разработанными VMware процедурами и не причиняет вреда рабочему окружению.
Дополнительные материалы
Andrew, currently working as a Cloud Technologist on the Veeam Product Strategy team, is a certified IT professional with over a decade of industry experience. Initially doing technical support for various solutions, including Veeam Backup & Replication, he has got practical expertise, which helps him to speak the same language as Veeam community members.
You can always find him presenting at different offline/online events, where he loves to solve the challenges associated with data protection. His motto is to help others realize the beauty and power of virtualization and cloud technologies.
Читайте также: