Влияние снапшотов на производительность - 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 - снапшот к нему не применяется и соотв. влияния на производительность он не оказывает.



IOmeter настроен на два теста - с 25мс задержкой и 0мс. Для обоих тестов используются следующие параметры:

Worker name	Block size	Read / Write	Seq / Random	Nr of sectors	Resulting File Size
Writer	4KBytes	100% write	70% random	2.000.000	1 GByte
Reader	4KBytes	100% read	70% random	2.000.000	1 GByte

Детальное описание теста:

1. Загрузить ВМ;
2. Запустить perfmon (read- и write операции в секунду (ROPS и WOPS);
3. Удалить тестовый файл IOmeter и запустить IOmeter workload;
4. Измерить IOPS без снапшота;
5. Остановить IOmeter, удалить тестовый файл;
6. Создать снапшот (память в снапшот не включать);
7. Перезапустить IOmeter после того, как снапшот создан;
8. Имерить IOPS со снапшотом;
9. Удалить снапшот;
10. Измерить IOPS в процессе удаления снапшота;
11. Если снапшот не получается удалить, то остановить IOmeter и дождаться удаления снапшота;
12. Остановить perfmon;
13. Сохранить данные: Статистика VMware в реальном времени для ROPS и WOPS на уровне хоста и ВМ, статистику perfmon;
14. Перенести все данные в один большой Excel файл.

Как работают снапшоты VMware

VMware выбрала технологию осуществления снапшотов прямо противоположную той, которую используют большинство производителей СХД. В VMware все блоки, подлежащие записи в VMDK на самом деле пишутся в (растущий) дельта-файл снапшота. Сам дельта-файл увеличивается блоками по 16MB.

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

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

Другая проблема в коммите/удалении снапшота VMware - куда сохранять данные, которые меняются в процессе удаления снапшота? Можно, конечно, просто заморозить ВМ, закоммитить изменения и потом разморозить ВМ. Но в продуктивных средах это прямо скажем сомнительное решение, большие снапшоты требуют много времени для коммита. И именно поэтому VMware предложила решение: создать еще один снапшот...

Как удаляется снапшот

Предположим, у нас есть ВМ со снапшотом, и администратор нажал на кнопку "Delete snapshot". Что же происходит?

Сначала VMware создает второй снапшот, дочерний удаляемому. Все операции записи, осуществляемые ВМ с этого момента, уходят во второй снапшот. А первый снапшот начинает коммит изменений в базовый диск.

К моменту окончательного удаления снапшота мы получаем ситуацию, с которой начинали - ВМ со снапшотом. Остается надеяться, что снапшот будет меньше по размеру, чем первоначальный. VMware просто повторяет процесс, пока снапшот не станет достаточно маленьким (макс. 16MB). Затем ВМ замораживается, последний снапшот коммитится, и ВМ размораживается. Поскольку последний снапшот был маленьким, время заморозки операций ввода-вывода остается приемлемым.

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

Результаты тестов: Общая производительность чтения/записи при снапшоте

В первом тесте нагрузка генерировалась на уровне 32 ROPS + 32 WOPS одновременно, чтобы не перегрузить зеркало из 10k SAS дисков. Графики производительности были практически идентичными для ESX3.5 и vSphere, поэтому я приведу лишь график для ESX3.5:



Что же мы видим на этом графике?

Sample	Event / Action
01	IOmeter начинает создавать тестовый файл - много WOPS.
10	Тестовый файл создан, IOmeter начинает генерировать нагрузку с 25мс интервалом
13	Постоянная нагрузка около 32 WOPS и 32 ROPS
17	Создан снапшот, IOmeter перезапущен
21	IOmeter создает тестовый файл - много WOPS. Обратите внимание, что WOPS на уровне хоста вдвое выше*
30	Тестовый файл создан, IOmeter начинает генерировать нагрузку
36	ВМ генирирует WOPS и ROPS. Обратите внимание, что ROPS на уровне хоста вдвое выше**
43	Запрошено удаление снапшота. Немедленно выстреливают вверх ROPS и WOPS
46	Заметьте, что количество IOPS на уровне ВМ остается на стабильном уровне
52	Уровень WOPS на уровне хоста еще выше, поскольку удаляется первый снапшот***
60	Снапшот закоммитился, ВМ работает как раньше

Пояснения
*) Файл снапшота растет, VMware требуется вдаое больше операций записи для сохранения всех блоков в пустом, но растущем дельта-файле.

**) При чтении из снапшота VMware сначала необходимо определить, есть этот блок только в базовом файле или в снапшоте существует его обновленная версия. Что приводит к двойному количеству операций чтения.

***) Первичный снапшот (1GB) удален с диска. Внезапно вырастает уровень WOPS. Насколько я понимаю, в данном случае это зависит от размера снапшота, до этого 1GB снапшот вызывал много случайных операций чтения, размазанных по физическому диску. Что в свою очередь приводит к увеличению времени поиска нужного сектора на поверхности диска. После того как большой снапшот удален, остается только маленький, который ближе к track-to-track режиму поиска (практически последовательное чтени), а следовательно меньшее время поиска -> бОльшая производительность диска.

Мы уже получили очень важную информацию: для начала, один лишь факт наличия снапшота означает двукратный рост ROPS. Более того, если ВМ записивает блок, который еще не был записан в снапшот, происходит две операции записи - сначала нужно обновить таблицу "где найти конкретный блок" (снапшот или базовый диск). И это очень сильно влияет на производительность!

Вдобавок, удаление снапшота попросту выстреливает IOPS в космос. Взгляните на отрезок 46..60 - ROPS и WOPS достигли уровня, который способна обеспечить дисковая система.

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

Мы увидели влияние снапшотов на дисковую систему, но влияние снапшота на ВМ было незначительным. Что произойдет, если нагрузка со стороны ВМ будет значительно выше, и мы создадим снапшот?



На этом графике видно, что ВМ полностью нагружает дисковую систему (11-21). IOmeter по-прежнему генерирует равное количество ROPS и WOPS, но диски обеспечивают вдвое большее количество ROPS. Вероятно по причине того, что RAID1 имеет write penalty = 2. Примерно на точке 26 создан снапшот, на промежутке 31-40 создается тестовый файл IOmeter.

На точке 41 начинается интересное, мы видим производительность ВМ со снапшотом. По причине оверхеда на чтение просто от того, что снапшот есть, общая производительность падает в 5(!) раз. В точке 51 дана команда на удаление снапшота, VMware создает второй снапшот и начинает коммит первого. В точке 61 небольшой пик - первый снапшот закоммитился, но второй вырос уже слишком большим. В итоге добавлен снапшот номер 3, пока будет коммититься второй снапшот. Поскольку первый уже удален, у нас остается всего два снапшота.

Но теперь VMware попала в ловушку - к моменту коммита снапшота, следующий уже вырос больше, чем был первый. В итоге это означает, что удалить снапшот мы попросту не сможем. В точке 100 IOmeter остановлен, 128 - снапшот удален, 130 - IOmeter перезапущен.

Продолжение.

Оригинал: Erik Zandboer (vmdamentals.com)