Влияние снапшотов на производительность - 2

Влияние снапшотов на производительность - 1

Результаты тестов: Снапшот на перегруженных дисках в деталях

Из предыдущего графика можно извлечь информацию о влиянии снапшота, и вот как это выглядит:

Здесь отлично видна производительность дисковой системы с точки зрения ВМ. А ВМ, как вы помните, пытается нагрузить диски по полной программе – и на чтение и на запись. В начале ВМ смогла получить одновременно 510 ROPS и 250 WOPS (7-25). Затем в точке 30 был создан снапшот, и после того, как IOmeter создал свой тестовый файл, производительность установилась (43-49) на уровне 110 ROPS / 100 WOPS. Впечатляет, не правда ли?

Затем мы удаляем (пытаемся) снапшот в точке 50. Диски остаются перегруженными, и вдобавок VMware накидывает еще больше операций чтения и записи для коммита снапшота. Как итог, производительность чтения проваливается до 28 ROPS. Если сравнить с начальными 510 ROPS, то финальная производительность оказывается на уровне 5.5%!!!

Пляски вокруг снапшотов

Как вы уже знаете, с точки зрения дисковой производительности снапшоты виртуальных машин являются безусловным злом.

Однако есть ситуации, когда может захотеться разделить базовые диски и дельта-файлы для снапшотов по различным датасторам. Например, Linked Clones работают именно так. Так как же это сделать?

В vSphere 4 для этого используется расширенный параметр workingDir.

Однако в 5.0 его влияние изменено для обспечения логики работы Storage DRS, и теперь он влияет только на файл снапшота .vmsn, а дельты сохраняются вместе с базовыми дисками, чтобы гарантировать единую производительность дисковой системы для ВМ. В этом случае требуется еще один расширенный параметр:

snapshot.redoNotWithParent = "TRUE"

Правда в этом случае вам придется воздержаться от использования Storage vMotion для данной ВМ, посколько после перемещения параметр workingDir будет сброшен. Соотв. Storage DRS так же исключается.

Можно ограничить общее количество снапшотов:

snapshot.maxSnapshots = "n"

Тем не менее, я лично не рекомендую использовать данные параметры, как и любые другие расширенные параметры до тех пор, пока это не становится совершенно необходимо и не испробованы другие средства. В большинстве случаев сам факт того, что вы собираетесь их использовать, говорит об ошибке на ранних стадиях или даже в дизайне решения. Хотя, безусловно, в некоторой небольшой доле случаях их использование оправдано.

За указание на существование параметров благодарность Максиму Мошкову. И, разумеется, не забывайте о существовании замечательного русскоязычного форума VMware :)

Влияние снапшотов на производительность - 1

Зачастую пользователи жалуются: "Если я нажимаю "Delete snapshot" - все просто встает!" Причем у кого-то действительно все сильно тормозит, а кто-то практически не замечает, что вообще что-то происходит.
Так что же происходит со снапшотами и как они влияют на производительность?

Описание тестовой среды:

• Windows 2003-R2-SP2 ВМ (32 bit);
• 1 vCPU;
• 2048 MB RAM;
• 5 GB загрузочный диск в режиме "independent" - SAN;
• Конфигурационные файлы ВМ и 4 GB диск для измерений на локальных дисках (10K RAID1);
• IOmeter (version 2006.07.27);
• Perfmon измеряет reads/writes на PhysicalDisk с интервалом 20 секунд;
• ВМ созданы на ESX3.5 и 4.0 для сравнения.

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

Куда уходит место на дисках?

Одна из проблемных областей администраторов платформ виртуализации - куда девается место на дисках?

А все просто.

Overprovisioning

Администраторы забывают, что они больше не работают с железками и выделяют дискового пространства сразу от души, на вырост. Оно и понятно - если купить сервер с дисками, скажем, по 36, то очень скоро место может просто кончиться и единственный вариант - выкидывать эти диски и покупать новые, после чего переносить данные.
В виртуальной среде и конкретно VMware VI диски виртуальных машин можно увеличивать онлайн. Не хватает 8ГБ - на тебе еще 2, до 10. Все ограничивается только необходимостью работы с файловой системой и расширением разделов. Увеличить диски можно всегда, а вот уменьшить - нет, увы.
Каждый гигабайт, который выделен машине без необходимости, "на вырост", лежит мертвым грузом. И его нельзя использовать для других машин. Каждый гигабайт, который выделен "на вырост" без необходимости, будет лежать мертвым грузом очень долго, увеличивая расходы на СХД.

Неразумное использование снапшотов

Некоторые администраторы используют снапшоты не в качестве временной меры, создания точки отката при внесении изменений, а на постоянной основе. Делаем что-то - снапшот. И не удаляем. А вдруг понадобится? Получается как в анекдоте про дохлую кошку: "Не пригодилась".
Снапшоты в абсолютном большинстве случаев не нужны больше, чем на неделю. Патчим систему? Снапшот. Патчи работают, все ОК? Удаляем снапшот.
Практически слышу сразу "А если что-то случится после, то куда откатываться?". Господа, а бэкапы на что? Снапшот - это _быстрый_ откат, это не средство резервного копирования.

Более того, если объединить постоянное использование снапшотов и overprovisioning - вообще грустная картина. Поставили голую систему (пусть будет Windows 2003) на диск в 20ГБ, снапшот. Поставили патч - снапшот, поставили еще что-то - снапшот. Да, у ВМ 2ГБ памяти. Итого имеем, скажем, 5 снапшотов со средней дельтой в 1,5ГБ, и финальное использование диска в 30% (6ГБ). Что это значит на практике? А на практике это значит, что 12ГБ дискового пространства потрачены впустую только на overprovisioning. Каждый снапшот занимает 2ГБ (снимок RAM) + 1,5ГБ (дельта) = 3,5*5 = 17,5ГБ. Итого, ВМ, которой требуется всего 6ГБ впустую расходует почти 30ГБ дискового пространства СХД. Почему, кстати, 12 - потому что чистое использование диска 6ГБ, но 2ГБ свободными оставить стоит хотя бы из соображений дефрагментации (Windows рекомендует не менее 15% диска) и небольшого(!) запаса рабочего места.

В этом случае машина нам обошлась в 37,5/8 = 4,7 раза дороже по статье СХД, чем должна была. (написано по мотивам реальной ВМ)

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

Поэтому:

1) В случае с ВМ заповедь "много не мало" работает в обратную сторону. Семь раз подумай, прежде чем добавить место, отрезать уже не получится.
2) Не храните снапшоты без крайней необходимости, пользуетесь бэкапами.

FT & Snapshots

В качестве ответа на вопрос на сегодняшнем вебинаре по FT & HA.

Fault Tolerance не совместим со снапшотами и соотв. их не поддерживает.

Required

Virtual Machines: Ensure that there is no user requirement to have
virtual machine snapshots since these are not supported for VMware
FT. Delete snapshots from existing virtual machines before protecting
with VMware FT.

http://www.vmware.com/files/pdf/vsphere-migration-prerequisites-checklist.pdf

Почему они несовместимы? Для FT обязательным требованием является thick диск, и даже не просто thick, а eagerzeroedthick, поскольку FT очень чувствительно относится к изменению метаданных. А снапшот виртуального диска представляет собой сам диск и растущий дельта файл, который как раз метаданные изменяет ровно так же, как и thin диск.

Поскольку прозвучал вопрос и про eagerzeroedthick - напомню разницу между ним и просто thick. Thick при создании полностью выделяет место в объеме самого диска, и при первом обращении к каждому блоку сначала его очищает. На практике это моментальное создание, а затем некоторое время низкая дисковая производительность (пока не будет обращений к большинству блоков). Eagerzeroedthick очищает весь диск при создании, поэтому создается такой диск довольно долго, но сразу же после создания выдает максимальные IOPS.

ESX vs Hyper-V: снапшоты

Eric Gray в блоге vcritical.com часто затрагивает тему сравнения ESX и Hyper-V. На этот раз досталось снапшотам.

Чем же так отличается поведение ВМ со снапшотами при работе с разными гипервизорами?

ESX

Снапшоты можно удалять и накатывать "вживую", на работающей ВМ. И соотв. с нулевым временем простоя.

Hyper-V

Удаленные снапшоты накатываются только при выключении машины, что удваивает количество перезагрузок для обслуживания гостевых ОС (в среднем половина ВМ пезагружается по патч-вторникам).

Как работают снапшоты (снимки) в VMware VI

Снапшот - это снимок состояния виртуальной машины (содержимое памяти, настройки ВМ, содержимое дисков) в определенный момент времени.

Возврат к снапшоту (revert to snapshot) восстанавливает текущее состояние виртуальной машины до сохраненного.

Снапшоты можно делать много раз, один за другим, причем можно создать достаточно развесистое дерево состояний, до 32 уровней вложенности.

В линейном процессе снапшотов каждый снапшот имеет родительский и дочерний, за исключением последнего снапшота, не имеющего дочернего по понятным причинам.
В дереве снапшотов сразу несколько дочерних имеют родительским один и тот же снапшот.

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

Соотв. в силу существования снапшотов существуют различные режимы для работы виртуальных дисков. А именно существуют независимые диски (independent), на которые снапшоты никак не влияют. Независимые диски могут работать в persistent (все изменения немедленно записываются на диск, и не откатываются даже при возврате к снашоту) и nonpersistent (все изменения откатываются автоматически при выключении машины или возврате к снапшоту). Обращаю ваше внимание, что nonpersistent диск будет возвращен к тому состоянию, в котором находился, когда мы поставили соотв. галочку в свойствах диска, а не к состоянию на момент снапшота.

Механизм работы снапшотов с виртуальными дисками.

В момент снапшота состояние диска замороживается, а технически это выглядит как блокирование vmdk файла в режиме RO, и создается новый -delta файл, в который будут записываться все изменения на диске. Дисковое простарноство под дельта-файлы выделяется строго по 16MB с целью уменьшения количества блокировок метаданных VMFS. При большом количестве изменений на диске дельта может достичь размера самого диска, но это предел, дальше расти уже не будет. При множественных снапшотах дельта-файлов соотв. становится много, и в режим RO переходят дельты для родительского снапшота. Крайне не рекомендуется запускать после снапшота процессы с интенсивной записью на диск, как например дефрагментацию, поскольку дельта очень интенсивно будет расти.

При возврате к последнему снапшоту дельта-файл просто удаляется, и все изменения пишутся в новый дельта-файл. При удалении снапшота накатываются изменения из его дельты на родительский диск (родительскую дельту). Процесс этот весьма ресурсоемкий и может сильно повлиять на работу как самой виртуальной машины, так и остальных виртуальных машин на этом хранилище. Причем при достаточном размере дельты мы получим ситуацию, когда задача "Delete snapshot" свалится по таймауту (по умолчанию 15 мин). Но особо беспокоится не стоит - накат изменений будет продолжаться до победного конца, несмотря на статус fail в vCenter.

Не рекомендуется использование долгоживущих снапшотов на production машинах, поскольку помимо перерасхода дискового пространства мы получим еще и снижение производительности + невозможность изменения размера диска.

Механизм снапшотов используется также в VCB (VMware Consolidated Backup). При резервном копировании ВМ создается снапшот, после чего он полностью копируется. По окончании копирования снапшот удаляется (накатываются изменения).