Постоянно работает в снимке 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, поэтому шаблоны и клонирование не обсуждаются.

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

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

Перед снимком:

После моментального снимка: После Shapshoting

— VM_Storage_Inception
источник

Не обязательно - со временем снимки будут расходиться все больше и больше. Наконец, они будут принципиально разными копиями. После того, как вы не сэкономите много дисков, снимая их, преобразуйте снимок в совершенно отдельный том. Как? Обычно я использую dd с третьей виртуальной машины, но в основном меня чуть не распяли за такие еретические мнения, как этот. :-) Но: это будет работать , и будет эффективно .

— Петер - Восстановить Монику

@PeterHorvath - Это то, что я люблю слышать. Умные, хакерские, эффективные, простые решения. Если вы не возражаете, не могли бы вы написать мне, что вы делаете в pastebin? Вы DD DD VMDK и снимок вместе?

— VM_Storage_Inception

Если мне нужно было делать это чаще, я делал это по сценарию. Но это не так, и в большинстве случаев я даже не использую снимки, потому что они медленные.

— Петер - Восстановить Монику

Ответы:

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

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

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

введите описание изображения здесь

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

— ewwhite
источник

Интересно, я посмотрю на это и пойму, как это работает. К сожалению, у меня нет лицензии vCenter, и я бы предпочел, чтобы моя организация не выложила $ 600, если бы не повлияло на производительность моментальные снимки, используемые в описываемом мной способе. Кроме того, создание шаблонов и клонирование, похоже, ничем не отличаются от взятия OVA и его повторного развертывания. Удаление снимков кажется намного быстрее, и я не могу понять, как это повлияет на производительность, даже если это не «Официальный метод, одобренный VMWare».

— VM_Storage_Inception

Чтобы ответить на ваши изменения, не могли бы вы указать мне статью или объяснить, как это повлияет на производительность? Я не могу понять, как было бы предположить, что я использую их, как я описываю. Кроме того, я никогда не буду консолидировать снимки обратно в исходный VMDK.

— VM_Storage_Inception

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

— ewwhite

@VM_Storage_Inception - это звучит почти так, как будто вы хотите, чтобы бедняк подошел к несуществующему руководителю лаборатории продуктов VMWare.

— TheCleaner

Иногда покупка правильного решения имеет смысл. Вы потратили больше усилий и человеко-часов, пытаясь найти обходной путь, чем просто заплатить за лицензию vSphere Essentials (600 долларов США), которая предоставила бы вам поддерживаемый вариант шаблона / клонирования.

— Ewwhite

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

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

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

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

— tfrederick74656
источник

Я почти уверен, что снимки используют таблицу «какой блок в каком файле». Таким образом, чтение одного отдельного блока приведет только к чтению одного блока из соответствующего файла. Конечно, чтение нескольких блоков может привести к доступу к нескольким файлам, что означает штраф за перемещение головок дисков, если вы не используете SSD, но общее количество обращений к дисковым блокам не должно измениться.

— Гунтрам Блом поддерживает Монику

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

— tfrederick74656

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

— Дирк Трилсбек

Система моментальных снимков виртуального диска, которая делает N читает для N моментального снимка, была бы очень глупой реализацией. Я сомневаюсь, что именно так это реализовано в VMWare. Простую оптимизацию можно выполнить, просто создав индексный файл, в котором хранится файл диска, в котором находится каждый блок эмулируемого диска. Предположим, у вас есть виртуальный диск 512 ГБ с размером блока 4 КБ, вам нужен только индекс 64 МБ, чтобы определить в постоянное время, какой из 16 файлов виртуальных дисков содержит блок.

— Ли Райан

Исходя из ответов на serverfault.com/questions/430138 я не согласен. Я всегда думал о снимках как о результате двоичной арифметики, а не просто о сборе новых данных. Таким образом, если у вас есть биты 01010101 в базовом VMDK, вы делаете снимок, а затем измените эти биты на 10101010, ваша дельта будет содержать 11111111 (что означает, что каждый бит в исходном файле изменился, а НЕ новое значение 10101010). Насколько я согласен с приведенным выше комментарием, VMDK, предположительно, являются необработанными файлами. Где будет храниться индекс? Я никогда не видел, чтобы это упоминалось в технических пабах VMWare.

— tfrederick74656

Снимки 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

— Dario
источник