Постоянная работа в моментальном снимке VMWare плохо сказывается на производительности?

Я понимаю, что VMWare KB не одобряет длительные снимки состояния в основном по двум причинам (на мой взгляд)

Создание тонны снимков может заполнить хранилище данных. Снимки - это просто файлы дельты. Предположим, у вас почти полный VMDK на 50 гигабайт, и вы делаете снимок. В вашем снимке вы переворачиваете каждый бит. Ваш файл дельты также будет около 50 ГБ. Снова снимок, переверните биты, еще один файл дельты 50 гигов. Они могут быстро выйти из-под контроля.
Сохранение больших снимков связано с риском. При объединении снимков вы записываете дельта-изменения в исходный VMDK. Это требует времени и несет в себе риск того, что в случае чего вы просто атакуете свой VMDK.

Их предупреждения кажутся логичными.

С учетом сказанного, плохо ли по своей сути постоянно запускать мою машину с помощью моментального снимка VMDK? Я хочу сделать свое дерево таким:

Основание
- Snap1
  - Snap 2
  - Вы здесь

Snap 1 и 2 будут приняты сразу после установки и подготовки базовой системы. Это машины, которые я планирую часто обновлять, поэтому я просто сделаю свое дерево следующим образом:

Основание
- Snap1
  - Вы здесь
  - Snap 2

Удалите Snap2 и заново создайте Snap2.

Я не понимаю, как это может иметь какие-либо последствия по следующим причинам:

Поскольку я просто установил базовый образ и сразу же взял свои дельты, я никак не мог заполнить хранилище данных. Предполагая, что мой базовый образ составляет всего 10 ГБ (на тонком подготовленном диске 50 ГБ), даже если моя дельта перевернула каждый бит, максимальное мое общее использование может составить 60 ГБ (10 ГБ базового VMDK, который заблокирован + 50 ГБ дельты в файл моментального снимка VMDK). Это предполагает, что я больше не создаю снимков.
Поскольку мой вариант использования не требует консолидации снимков, я не рискую ошибиться при консолидации своих дельт. Когда я возвращаюсь к Snap1 и удаляю Snap2, вся дельта, которая находилась в Snap2, просто удаляется.
Нагрузка на хранилище точно такая же, поэтому я должен получать такие же IOPS. Я понимаю, что некоторые файлы (в основном системные файлы) будут существовать в исходном VMDK, а другие (все, что находится после базы) будут находиться в дельте, но я не понимаю, как это будет заботить ESXI. Все файлы находятся в одном физическом хранилище данных, поэтому производительность должна быть эквивалентна обращению ко всему в исходном VMDK без моментальных снимков.

Есть предположения? ESXI 5.5 с хранилищем данных в виде RAID-массива DAS.

У меня нет лицензии vCenter, поэтому создание шаблонов и клонирование невозможно.

РЕЗУЛЬТАТЫ ИСПЫТАНИЯ

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

Перед моментальным снимком:

После снэпшота:

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

VMware имеет функции шаблонов и клонирования встроен в vCenter. Для этого вам потребуется лицензия vSphere Essentials за 600 долларов.

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

Это позволяет вам иметь «чистое состояние», а также создавать из этого главного образа длительно работающие или постоянные виртуальные машины. Снимки не нужны.

Ответ ewwhite правильный, но просто чтобы немного расширить или снизить производительность, рассмотрите следующий сценарий:

Вы создаете виртуальную машину. Виртуальное чтение из vmdk требует чтения одного физического диска того же размера. Довольно просто.

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

Для двух снимков вы делаете в три раза больше чтения и так далее. Если у вас много снимков, вы можете увидеть, как это может привести к довольно значительному снижению производительности. Это не обязательно приводит к снижению производительности в n раз (из-за кеширования, разделов, которые не были изменены и т. Д.), Но это не очень хорошая практика.

Снимки состояния VMware ESX предназначены для краткосрочного использования.

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

Вы можете создавать шаблоны виртуальных машин вручную через ssh. Скопируйте папку виртуальной машины, содержащую vmdk, vmx и т. Д., В новую папку. В файле vmx вновь скопированной виртуальной машины измените UID и MAC-адрес.

У VMware есть продукт Linked Clone, который вы пытаетесь реализовать. И они говорят, что у него есть потенциальные проблемы с производительностью. На практике через некоторое время вы будете переделывать виртуальные машины. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html