Работает постоянно в снимке VMware плохо для производительности?
Я понимаю, что КБ VMware осуждает длительные снимки главным образом из-за двух вещей (По-моему),
Взятие тонн снимков может заполнить хранилище данных. Снимки являются просто файлами дельты. Скажем, у Вас есть VMDK на 50 ГБ, почти полный, и Вы берете снимок. В Вашем снимке Вы зеркально отражаете каждый бит. Ваш файл дельты также составит приблизительно 50 ГБ. Создайте снимки снова, зеркально отразите биты, другой файл дельты на 50 ГБ. Они могут выйти из-под контроля быстро.
Фиксация больших снимков несет риск. При консолидации снимков Вы пишете изменения дельты в исходном VMDK. Это занимает время и несет риск, что, если что-то происходит, Вы просто уничтожили свой VMDK.
Их предупреждения, кажется, имеют логический смысл.
Так как это сказан, это по сути плохо для выполнения моей машины постоянно прочь снимка VMDK? Я хочу сделать свое дерево следующим:
- Основа
- Snap1
- Снимок 2
- Вы здесь
- Snap1
Привяжитесь 1, и 2 будет сразу взят после установки и настройки основной системы. Это машины, которые я планирую обновить часто, таким образом, я просто заставлю свое дерево быть похожим на следующее:
- Основа
- Snap1
- Вы здесь
- Снимок 2
- Snap1
Удалите Snap2 и воссоздайте Snap2.
Я не вижу, как это могло иметь любые последствия по следующим причинам:
Так как я просто установил базовое изображение и взял мои дельты сразу после того, как нет никакого пути, я мог возможно заполнить хранилище данных. Принятие моего базового изображения составляет только 10 ГБ (на настроенном диске 50 ГБ толщиной), даже если моя дельта зеркально отразила каждый бит макс., которым могло бы быть мое общее использование, 60 ГБ (10 ГБ основывают VMDK, который заблокирован + 50 ГБ дельты в снимке файл VMDK). Это предполагает, что я не создаю дальнейшие снимки.
Так как мой вариант использования не призывает к консолидации снимков, я не рискую ошибками после консолидации моих дельт. Когда я пячусь к Snap1 и удаляю Snap2, вся дельта, которая находилась в Snap2 просто, удалена.
Загрузка устройства хранения данных является точно тем же, таким образом, я должен получать тот же IOPS. Я понимаю, что некоторые файлы (главным образом системные файлы) будут существовать на исходном VMDK, и другие (все после основы) будут находиться в дельте, но я не вижу, как ESXi заботился бы. Все файлы находятся на том же физическом хранилище данных, таким образом, производительность должна быть эквивалентна ссылке на все в исходном VMDK без снимков.
Какие-либо мысли? ESXI 5.5 с хранилищем данных, являющимся RAID'd DAS.
У меня нет лицензии vCenter настолько обрабатывающей по шаблону, и клонирование закрыто.
РЕЗУЛЬТАТЫ ТЕСТА
Я вошел рано сегодня для запущения некоторых тестов. Вот результаты. Существует потеря производительности, но я не уверен почему.
Перед созданием снимков: 
После создания снимков: 
Ответ ewwhite правильный, но просто чтобы немного расширить или снизить производительность, рассмотрите следующий сценарий:
Вы создаете виртуальную машину. Виртуальное чтение из vmdk требует чтения с одного физического диска того же размера. Довольно просто.
А теперь представьте, что вы сделали снимок виртуальной машины. Теперь для каждого виртуального чтения вы будете выполнять 2 физических чтения, одно из базового vmdk, а другое из дельта-vmdk, потому что вам нужна информация от обоих, чтобы получить текущее состояние. Теперь вы в два раза больше, чем физический диск читает.
Для двух моментальных снимков вы делаете в три раза больше чтения и так далее. Если у вас много снимков, вы можете увидеть, как это может привести к довольно значительному снижению производительности. Это не обязательно приводит к снижению производительности в n раз (из-за кеширования, разделов, которые не были изменены и т. Д.), Но это не очень хорошая практика.
Да, длительные моментальные снимки влияют на производительность. Есть еще большие последствия для консолидации дельта VMDK обратно в исходный дисковый файл. Это может привести к зависанию операционной системы вашей виртуальной машины или другому нежелательному поведению.
VMware имеет функции создания шаблонов и клонирования , встроенные в vCenter. Для этого вам понадобится лицензия vSphere Essentials за 600 долларов.
Вы можете создать виртуальную машину по своему вкусу, а затем клонировать ее в шаблон. Затем этот шаблон можно использовать для создания новых виртуальных машин из образа «Golden Master».
Это позволяет вам иметь «чистое состояние», но также создавать из этого мастера длительно работающие или постоянные виртуальные машины. образ. Снимки не требуются.
Моментальные снимки VMware ESX предназначены для краткосрочного использования.
Длительное использование и интенсивный ввод-вывод могут вызвать зависание виртуальной машины. Если у вас есть случай, когда ввод-вывод записи больше / быстрее, чем консолидация моментальных снимков, ESX заморозит ВМ для защиты данных. Когда моментальные снимки становятся фрагментированными, а ESX выполняет внутреннюю консолидацию, могут возникать периодические зависания.
Вы можете создавать шаблоны виртуальных машин вручную через ssh. Скопируйте папку виртуальной машины, содержащую vmdk, vmx и т. Д., В новую папку. В vmx-файле недавно скопированной виртуальной машины измените UID и MAC-адрес.
VMware имеет продукт Linked Clone, который вы пытаетесь сделать. И они говорят, что у него есть потенциальные проблемы с производительностью. На практике через некоторое время вы будете переделывать виртуальные машины. https: //www.vmware.com / support / ws5 / doc / ws_clone_typeofclone.html