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

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

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

• Создание больших снимков сопряжено с риском. При объединении снимков вы записываете дельта-изменения в исходный VMDK. Это требует времени и сопряжено с риском того, что если что-то случится, вы просто уничтожите свой VMDK.

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

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

• База
  • SNAP1
    • Snap 2
    • Вы здесь

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

• База
  • SNAP1
    • Вы здесь
    • Snap 2

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

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

• Так как я просто установил базовый образ и сразу же забрал свои дельты, я никак не мог заполнить хранилище данных. Предполагая, что мой базовый образ составляет всего 10 ГБ (на диске с тонким предоставлением 50 ГБ), даже если моя дельта переворачивает каждый бит, максимальное общее использование может составлять 60 ГБ (базовый VMDK 10 ГБ, который заблокирован + 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 и одно из delta vmdk, потому что вам нужна информация от обоих для получения текущего состояния. Теперь вы дважды читаете с физического диска.

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

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

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

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

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