Итак, у меня сейчас работает довольно крутая установка KVM, CentOS5.5 на хост-доменах и гостевых доменах, libvirt, управляющая всей конфигурацией и т. Д. Файловые системы гостевых доменов хранятся в LVM поверх аппаратного тома RAID5, поэтому я обладают гибкостью для резервного копирования и низкоуровневого резервирования данных.
Сегодня я протестировал virt-clone, и он работал на удивление хорошо, за исключением того, что репликация 24 ГБ данных с дисков LVM приостановленного домена на новые тома LVM для новой виртуальной машины заняла около 30 минут.
У меня вопрос: нельзя ли использовать снимок LVM для создания корневого диска новой виртуальной машины? Например: lvcreate -s guest1_root -n guest2_root -L 8G raid_vg
Насколько я понимаю, снимки LVM состоят в том, что снимок хранит обратную дельту изменений, внесенных в исходные блоки, так что снимок занимает мало фактического места, а исходные блоки можно считывать даже после того, как исходный том был записан. LVM2 добавляет снимки состояния для чтения и записи, что открывает эту интересную возможность.
Действительно, LVM HOWTO даже предлагает использовать эту функцию вместе с Xen:
Это открывает множество новых возможностей, которые были невозможны с моментальными снимками LVM1 только для чтения. (...) Это также полезно для создания томов для использования с Xen. Вы можете создать образ диска, затем сделать его снимок и изменить снимок для конкретного экземпляра domU. Затем вы можете создать еще один снимок исходного тома и изменить его для другого экземпляра domU. Поскольку единственное хранилище, используемое снимком, - это блоки, которые были изменены в источнике или снимке, большая часть тома используется domU.
Это кажется действительно мощным инструментом, и мне интересно, пробовал ли кто-нибудь его в своей производственной среде виртуализации, может вспомнить каких-либо поставщиков (Citrix, VMWare), которые придерживаются этого подхода, или могут возникнуть какие-либо серьезные проблемы с этой идеей. Я могу думать о следующих потенциальных проблемах:
Как люди, у которых, вероятно, больше опыта виртуализации, чем у меня, есть ли что-нибудь, что заставляет хотеть бежать с криком от такой установки?
Хотя я не пробовал LVM для хранения KVM, я использовал его для функции теневого тома в samba и могу сказать вам одно: производительность была ужасной.
Каждый снимок требует дополнительной записи. Если у вас есть один базовый том с моментальными снимками и 4 моментальных снимка, количество операций записи, поступающих на диски, умножается на 5 при записи на базовый том.
Что касается ваших конкретных вопросов:
К сожалению, я знаю только 3 системы, которые хорошо работают со снимками: NetApp WAFL, ZFS и btrfs. Если система не критична, стоит попробовать btrfs.
Это нормально. Что вы делаете не хотите, чтобы родительский элемент снимка (оригинал, или источник, или как вы его хотите назвать) использовался в одно и то же время, потому что это вызовет умножение ввода-вывода (Хьюберт был прав в этом, это просто легко предотвратить, если не использовать постоянную громкость источника).
Если у вас установлена одна основная ОС на LVM и вы снимаете ее четыре раза, у вас не будет большого количества штрафов за ввод-вывод, поскольку вы выполняете запись только в отдельные тома моментальных снимков. Конечно, это не бесплатно, как и другие формы моментальных снимков на других файловых системах или виртуальных дисках. Всегда где-то есть цена.
Еще в одном Хуберт прав: вы должны подумать о размере ваших снимков. Вам нужно будет убедиться, что тома моментальных снимков могут продолжать запись. Полный том моментального снимка сильно повредит материал. Безопасный способ предотвратить это - сделать том моментального снимка того же размера (или больше), что и исходный том. Тем не менее, таким образом вы теряете преимущество использования меньшего дискового пространства.
Вы знаете, что изображения qemu тоже поддерживают моментальные снимки?
LVM с тонким выделением ресурсов следует рассматривать в качестве основного варианта для этого сценария в 2019 году.
Производительность тонких LV является хорошей, и они работают как отдельные тома, поэтому после создания снимка вам не нужно беспокоиться об уходе и целостности оригинала (он может быть поврежден, удален и т. Д., Не затрагивая снимок).
Забота ОП о "снимок занимает мало места" не совсем удовлетворяет традиционный LVM, поскольку пространство должно быть заранее выделено монолитно для каждого снимка. Но тонкие LV распределяются как разреженные файлы и на самом деле занимают мало места.
Компромисс тонкого выделения ресурсов заключается в том, что доступное пространство в тонком пуле должно контролироваться так же, как файловая система, чтобы избежать его заполнения. В дистрибутивах Linux обычно есть демоны для отслеживания этого и отправки предупреждений или принятия мер, когда тонкий пул достигает почти полного состояния.
Я бы пошел так далеко, что сказал, что ZFS стоит попробовать, можно довольно легко настроить систему на базе Nexenta с помощью какого-либо диска, будь то оптоволокно, iscsi и т. Д., И имеет довольно хорошую производительность. Я бы рекомендовал этот подход по сравнению с локальным хранилищем, если производительность не является абсолютно критичной в любой день, поскольку это даст вам простой сценарий восстановления, если ваш сервер виртуализации выйдет из строя.