VMware snapshot - не бекап: выясняем на практике с VI3

Когда VMware выкатила VI3 с VirtualCenter 2.0, мы первым делом полезли щупать снимки виртуальных машин. Возможность откатить виртуалку за пару минут выглядела почти как магия: обновляешь ПО - делаешь snapshot, что-то пошло не так - откатываешься и делаешь вид, что ничего не было. Удобно, чисто, быстро.

Несколько недель спустя к нам пришёл вопрос от клиента: «У нас уже есть снимки, зачем нам ещё и резервные копии?» Вот тут мы и сели разбираться по-настоящему.

Что такое snapshot и чем он не является

VMware snapshot - это не копия виртуальной машины. Это точка фиксации состояния: в момент создания снимка текущий VMDK-файл диска «замораживается», и все последующие записи идут в дельта-файл (VMDK типа redo-log). Если нужно откатиться - система применяет дельту в обратную сторону и возвращает диск к состоянию на момент снимка.

Проблема первая: snapshot хранится вместе с виртуальной машиной, на том же датастоаре. Если хост или хранилище умерли - снимки умерли вместе с ними. Бекап по определению должен жить отдельно от оригинала.

Проблема вторая, которая нас и подловила: производительность.

Как растёт дельта и что это означает

Пока дельта-файл маленький - всё хорошо. Но виртуальная машина работает, пишет данные, и дельта растёт. Операция записи на диск теперь идёт не напрямую в базовый VMDK, а в дельту. Чтение тоже усложняется: если нужного блока нет в дельте - VMware идёт за ним в базовый файл. Чем длиннее цепочка снимков и чем больше каждая дельта - тем больше накладных расходов.

Мы замеряли на тестовом стенде с VI3. При дельте меньше 5-10% от объёма базового VMDK разница практически незаметна. Когда дельта перевалила за 20% - просадка по IOPS стала ощутимой, порядка 15-25% на дисковых операциях записи. При старом снимке в 30%+ дельты гостевая ОС начинала вести себя заметно медленнее. Цифры зависят от профиля нагрузки - у нас был тест с активной записью (SQL Server, логи).

На практике это означает: снимок, который висит неделю на активной VM с базой данных - это уже не «бесплатная страховка», это проблема с производительностью.

Откуда берётся ситуация «снимок завис»

Классический сценарий, который мы видели: администратор создаёт снимок перед обновлением, обновление проходит нормально, снимок забывают удалить. Через неделю клиент спрашивает почему стало медленнее. Открываем VirtualCenter - висит snapshot четырёхдневной давности с дельтой, которая уже прилично распухла.

Второй сценарий: снимок создаётся автоматически каким-то скриптом резервного копирования, но скрипт падает на этапе удаления снимка после завершения. Снимки копятся, цепочка растёт. Виртуалка начинает жаловаться на жизнь молча - если нет мониторинга размера дельты, это обнаруживается случайно.

Правило, которое мы ввели

После этих экспериментов мы зафиксировали для себя несколько чётких правил.

Snapshot живёт не дольше 72 часов. Это не рекомендация - это жёсткая политика для машин под сопровождением. Три дня - достаточный срок, чтобы убедиться, что обновление прошло нормально, и удалить снимок. Если за три дня непонятно - значит либо проблемы серьёзнее, либо снимок не поможет.

Одновременно не больше одного снимка на VM. Цепочки снимков - отдельная история: удаление промежуточного снимка требует слияния всех последующих дельт, что само по себе нагружает хранилище и занимает время пропорционально объёму.

Мониторинг размера дельты. В VirtualCenter можно смотреть на размер snapshot-файлов. Мы добавили проверку в регламент: если дельта перевалила за 10% от базового VMDK - сигнал, что снимок слишком старый или VM слишком активно пишет.

Снимок - не бекап. Это звучит банально, но надо произносить вслух при каждом разговоре с клиентом. Полноценный бекап - это копия на отдельном носителе, физически изолированная от исходной машины. Для виртуальных машин это либо Backup Exec с агентом, либо экспорт VMDK в офлайн, либо схема с SAN-снапшотами - это уже тема отдельного разговора.

Где snapshot реально полезен

Снимки не бесполезны - они просто решают конкретную задачу. Два случая, где мы их используем без вопросов.

Перед обновлением ПО. Создали снимок, запустили апдейт, проверили работоспособность в течение нескольких часов, удалили снимок. Быстрый откат на случай если что-то пошло не так - именно для этого механизм и создавался.

Перед рискованными изменениями конфигурации. Правим реестр, меняем настройки службы, экспериментируем с конфигом. Снимок даёт возможность вернуться к рабочему состоянию за минуты, а не за часы восстановления из бекапа.

В обоих случаях жизненный цикл снимка - часы, максимум сутки. Не больше.

VMotion и High Availability в VI3 - это хорошо. Но если базовая гигиена со снимками не выстроена, никакая отказоустойчивость не поможет, если датастор под завязку забит дельтами.