Снимки состояния (Snapshot)

ESX  позволяет  нам  создавать  для  виртуальных машин  снимки  состояния.  Снимок состояния – это точка возврата. На рис. 5.35 показан диспетчер снимков (Snapshot Manager) виртуальной машины с двумя снимками.

Рис. 5.35. Диспетчер снимков состояния

Обратите  внимание на первый снимок с именем «Snapshot1_before_VMware_ tools». Его иконка  с зеленым  треугольником указывает  на то, что он был сделан при работающей ВМ, с сохранением  ее памяти. То есть при возврате на этот снимок мы вернемся в состояние работающей ВМ.

Создание снимка состояния весьма тривиально. В контекстном меню ВМ выбираем Snapshot ? Take Snapshot.

В открывшемся окне (рис. 5.36) нас попросят ввести имя снимка и описание.

Рис. 5.39. Связь снимков с файлами vmdk

Обратите  внимание:  в файлы  -delta.vmdk пишутся  все изменения данных на диске ВМ. Как максимум, на диске может поменяться все. Поэтому каждый файл

-delta.vmdk по размеру  может быть равен номинальному объему диска ВМ. Изначально  файлы  delta.vmdk создаются размером в один блок VMFS  и по одному блоку увеличиваются при необходимости.  Напомню, что размер блока VMFS мы указываем  при создании  раздела, и допустимые значения  – от 1 (по умолчанию) до 8 Мб.

Существует  еще один нюанс, связанный со снимками  состояния. Диски  ВМ могут быть расположены на других хранилищах,  нежели  ее файл  настроек.  Например, файл настроек и системный  диск ВМ мы разместили на одном хранили ще, где VMFS отформатирован с блоком в 1 Мб. Напомню, что следствием этого является максимальный размер одного файла на этом разделе VMFS в 256 Гб. Допустим, диск с данными этой ВМ мы располагаем  на другом хранилище,  с большим  размером  блока,  потому  что этот диск  хотим  сделать  размером  в 400 Гб. Все хорошо, это штатная  ситуация.  Однако  если теперь мы попытаемся сделать снимок  этой ВМ, то нам не позволят этого сделать  – так как файл  -delta.vmdk для диска с данными этой ВМ создается в рабочем каталоге, на первом хранили ще. А максимальный размер  этого -delta.vmdk равен  размеру  исходного  диска. В моем примере это 400 Гб – а файл такого размера невозможно создать на VMFS  с блоком в 1 Мб.

Также  если размер диска ВМ близок  к максимально возможному на данном VMFS, мы не сможем создать снимок этой ВМ. Это связано с тем, что -delta.vmkd файл требует до 2 Гб дополнительного места из-за накладных  расходов. Получа ется, что если «размер  диска ВМ» плюс 2 Гб больше, чем максимальный размер файла на этом разделе VMFS, то снимок не создастся.

Обратите внимание. При создании  снимка состояния ВМ у нас фиксируется состояние гостевой файловой системы и, необязательно, памяти ВМ. Однако, кроме этого, сохраняется и конфигурация ВМ как объекта ESX(i). Возможна ситуация, когда вы сделали снимок, после этого как-то изменили  конфигурацию инфраструктуры и связанные с этим параметры конфигурации ВМ. Например, поменяли имена групп портов и переключили сетевые контроллеры ВМ на новые группы портов. Или пересоздали хранилища, и CD-ROM виртуальной машины теперь ссылается на файл iso по другому, чем раньше, пути. Тогда при возврате на снимок состояния виртуальная машина окажется в некорректной конфигурации. Возможно, ее нельзя будет включить до устранения конфликта.

Плюсы и минусы снимков состояния

Плюсами снимков состояния является их суть – создание точки возврата. Это, без сомнения, здорово для тестовых виртуальных машин. Это бывает полезно для производственных ВМ. Например, удобно сделать снимок состояния перед установкой  какого-нибудь большого обновления – в случае возникновения каких-то  проблем после его установки  нам легко возвратиться на предыдущее  состояние. Практически все средства резервного  копирования виртуальных машин создают снимок состояния на время самой операции резервного копирования. Однако все остальное является минусами, и давайте эти минусы перечислим:

Q  если вы используете диски ВМ в thick-формате, то они сразу занимают все

выделенное  им место. Если теперь сделать снимок состояния ВМ, то этот снимок  занимает  место сверх уже занятого  самим диском. Как максимум  ВМ  с одним  снимком  состояния может  занять  в два раза  больше  места, чем номинальный объем ее диска. Это, конечно, граничный случай, однако треть, а то и половину  сверх объема диска снимок  за несколько  месяцев занять способен вполне. Это сильно зависит  от интенсивности изменения данных ВМ;

Q  ВМ со снимками состояния нельзя наживую мигрировать на другое храни-

лище с помощью Storage VMotion;

Q  простой  VMotion работает,  однако показывает  вам предупреждение вида

«У ВМ есть снимки состояния. Я ее мигрировать могу, но не рекомендую». Следствием этого  является то, что  перестает  работать  DRS  для  ВМ  со снимками. Это бывает очень неприятно,  когда отвечающий за ВМ администратор сделал снимок состояния виртуальной машины для подстраховки  перед какими-то своими манипуляциями. Подстраховка не понадобилась, и про снимок благополучно  забыли. Но DRS теперь эту ВМ не мигрирует;

Q  уменьшается  надежность  – для ВМ со снимками  состояния выше вероят-

ность каких-то  проблем именно из-за наличия  снимков. Обычно эти проблемы выглядят как не запускающаяся после миграции  или лунного затмения виртуальная машина;

Q  огромной осторожности требует использование снимков состояния на ВМ

с распределенными приложениями  (самый  типичный   пример  —  Active Directory). Если не все, а только часть ВМ, участвующих  в этом приложе нии (один  или несколько  контроллеров домена),  вернулись  в прошлое  –

мы рискуем получить серьезные проблемы вплоть до полной неработоспо собности  всего  распределенного приложения  (в  случае  Active  Directory см. «USN  Rollback»).  Практически 100%-ная  вероятность таких проблем привела  к тому, что Майкрософт не поддерживает использование любых механизмов снимков  (включая снимки  ВМ, снимки  СХД и резервное  копирование  с помощью программ снятия  образов)  с контроллерами домена Active Directory;

Q  когда  на  одном  хранилище   много  ВМ  со  снимками   состояния,  может

уменьшиться производительность дисковой  подсистемы  из-за накладных  расходов, возникающих вследствие  того, что файлы vmdk снимков увеличиваются блоками;

Q  удаление снимков состояния в некоторых случаях требует очень много сво-

бодного места на хранилище.

Вывод: для производственных ВМ снимки  состояния используем строго по делу и удаляем сразу после того, как в них пропала нужда.

Обратите внимание. В этой книге под «снимками состояния (snapshot)» понимаются «снимки состояния (snapshot) VMware». Эта оговорка делается по той причине, что многое из перечисленного неверно для «аппаратных» снапшотов систем хранения. Работают такие снапшоты где-то сходным, а где-то иным образом.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий