Почему снимки виртуальной машины влияют на производительность?

27

В одной из статей VMware KB я читал, что моментальные снимки напрямую влияют на производительность виртуальной машины.

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

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

Может кто-нибудь объяснить немного теории о том, как снимки действительно влияют на производительность? Это просто потому, что скорость дискового ввода-вывода жесткого диска будет медленной?

performance vmware-esxi virtual-machines snapshot Samselvaprabu
источник
2
Не уверен, что это статья КБ, которую вы читали или нет. Я думал, что добавлю это как ссылку.
Аарон Копли

Ответы:

28

Когда вы создаете снимок, исходный образ диска «замораживается» в согласованном состоянии, и с этого момента все обращения к записи переходят в новый разностный образ. Еще хуже, как объясняется здесь и здесь , дифференциальное изображение имеет форму журнала изменений, в котором записываются все изменения, внесенные в файл с момента создания моментального снимка. Это означает, что доступ для чтения должен будет прочитать не только один файл, но и все данные о различиях (исходные данные плюс каждое изменение, внесенное в исходные данные). Количество увеличивается еще больше, когда вы каскадных снимков.

Ансгар Вичерс
источник
2
Лучшее объяснение. Вы не только удваиваете количество операций ввода-вывода в секунду, но и при вычислении разницы на уровне блоков возникают накладные расходы процессора.
Аарон Копли
3
После прочтения этой статьи, на которую ссылается Аарон Копли ( kb.vmware.com/selfservice/microsites/… ), ситуация кажется еще хуже. Снимок не является разностным изображением, это журнал изменений, поэтому, если вы записываете одни и те же данные в одно и то же место в 10 раз, снимок увеличит его размер на 10, умножив на размер записанных вами данных. Вместо этого дифференциальное изображение должно быть более эффективным, поскольку оно должно перезаписывать данные, переписанные в том же месте.
Макс
1
@zespri Проблема затрагивает все платформы виртуализации, использующие эту технологию моментальных снимков, включая Hyper-V.
Ансгар Wiechers
1
Это совершенно неправильно. Смотрите комментарий @Falcon Momot для правильного ответа. Даже в связанной статье просто говорится, что на диске «может не хватить места», что ясно, когда пространство, оставшееся до создания моментального снимка, меньше, чем у диска с моментальным снимком, и у дельтадиска нет места для расширения.
Даниил
2
@AnsgarWiechers Этот ответ определенно неправильный. Связанная статья ( kb.vmware.com/s/article/1015180 ) гласит; «Дочерний диск, созданный с помощью моментального снимка, является разреженным диском. Разреженные диски используют механизм копирования при записи (COW), в котором виртуальный диск не содержит данных местами до тех пор, пока он не будет скопирован с помощью записи». С последующим; «Если на виртуальной машине выполняется моментальный снимок, она вносит изменения в дочерний или разреженный диск. Чем больше операций записи выполняется на этом диске, тем больше он увеличивается до верхнего предела размера базового диска плюс небольшое количество накладных расходов. "
Steve365
5

Когда вы создаете снимок на виртуальной машине, создается Delta Disk, и операционная система записывает в этот файл вместо исходного VMDK. Этот файл называется VM_Name-Delta.VMDK, но если системе необходимо обратиться к файлу перед моментальным снимком, он будет ссылаться на VM_Name.VMDK, увеличивая число операций ввода-вывода этой операции. Если вы делаете несколько снимков, вы обращаетесь к последнему дельта-файлу последнего снимка, а не к исходному VMDK, увеличивая тем самым количество операций ввода-вывода.

Пример.

ОС ---> Снимок (файл A создан) ---> (Файл снимка B создан)

Если мне нужно обратиться к файлу A, он будет просматривать 3 VMDK, чтобы найти это.

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

Файл создан, в нем перечислены все файлы, созданные во время процесса снимка

Zapto
источник
2

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

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

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

Сокол Момот
источник
-2

Из значений High co-stop (% CSTP), замеченных во время действий моментального снимка виртуальной машины :

По мере увеличения размера и количества снимков на виртуальной машине увеличивается количество операций с командами хранения в vmkernel. Для каждой команды хранения, выданной гостевой ОС виртуальной машины, может потребоваться несколько операций с командами хранения для обхода всей цепочки снимков и считывания наиболее подходящего блока данных.

Шахнаваз Усмани
источник