Я только что создал новый виртуальный хост на основе KVM / libvirt, содержащий 4 жестких диска SATA II и работающий с CentOS 5.5 x86_64.
Я решил создать диски виртуальных машин как логические тома в группе томов LVM, управляемой как пул хранения libvirt, вместо обычной практики создания дисков в виде образов qcow.
Я не могу определиться с тем, стоит ли мне создавать логические тома виртуальной машины в группе томов узла виртуальной машины или в выделенной группе томов.
Какой метод выбрать и почему?
Способ 1. Использование группы томов хоста VM
Реализация:
- маленький RAID1,
md0содержащий/bootфайловую систему - большой RAID10,
md1занимающий оставшееся пространство, в котором находится группа томов LVMvghost.vghostсодержит корневую файловую систему хоста VM и раздел подкачки - создавать диски виртуальных машин как логические тома в
vghostсоответствии с требованиями
Плюсы:
- если в корневой файловой системе хоста VM не хватает места, я могу
vghostотносительно легко выделить больше места - Система уже запущена и работает (но начинать все сначала)
Минусы:
Несмотря на то, что этот метод работает, я не могу избавиться от ощущения, что это плохая идея. Я чувствую что:
- это может как-то быть угрозой безопасности
- в какой-то момент в будущем я могу найти некоторые ограничения в настройке и хочу, чтобы я использовал выделенную группу
- система (CentOS, libvirt и т. д.) может и не быть предназначена для такого использования, и поэтому в какой-то момент я могу случайно повредить / потерять файлы и / или файловую систему хоста ВМ
Способ 2: использовать выделенную группу томов
Реализация:
- То же самое, что
md0иmd1в методе 1, за исключением того,md1что make достаточно велик, чтобы вместить его для хоста VM (например, от 5 до 10 ГБ) - большой RAID10,
md2занимающий оставшееся пространство.md2содержит группуvgvmsтомов LVM , логические тома которых должны использоваться исключительно виртуальными машинами
Плюсы:
- Я могу повозиться,
vgvmsне боясь взломать хост-ОС - это кажется более элегантным и безопасным решением
Минусы:
- если файловой системе хоста ВМ не хватает места, мне придется переместить части ее файловой системы (например, / usr или / var)
vgvms, что не очень приятно. - Я должен переустановить хост-ОС (как я уже говорил, я не против)
ОБНОВЛЕНИЕ № 1:
Одна из причин, по которой меня беспокоит нехватка дискового пространства хоста ВМ в способе 2, заключается в том, что я не знаю, достаточно ли мощный хост виртуальной машины для запуска всех служб на виртуальных машинах, т.е. Возможно, мне придется перенести некоторые / все сервисы с виртуальных машин на хост-ОС.
Спецификация оборудования хоста VM:
- Процессор Phenom II 955 X4 Black Edition (3,2 ГГц, 4-ядерный процессор)
- 2x4 ГБ оперативной памяти Kingston PC3-10600 DDR3
- Gigabyte GA-880GM-USB3 материнская плата
- 4 жестких диска WD Caviar RE3 500 ГБ SATA II (7200 об / мин)
- Antec BP500U Basiq 500W ATX блок питания
- Корпус CoolerMaster CM 690
ОБНОВЛЕНИЕ № 2:
Одна из причин, по которой я чувствую, что система не может быть спроектирована для использования VG хоста в качестве пула хранения libvirt в способе 1, - это некое поведение, которое я заметил в virt-manager:
- после добавления он жаловался, что не может активировать VG (очевидно, потому что операционная система хоста уже активировала его)
- после удаления он отказался сделать это, потому что не смог деактивировать VG (очевидно, потому что хост-ОС все еще использует корневые и подкачки LV)
Ответы:
Хорошо продуманный вопрос!
Я бы выбрал метод 2, но это скорее личное предпочтение. Для меня недостатки метода 2 не так уж и важны. Я не вижу, как хост-операционная система перерастает свой раздел на 5-10 ГБ, если только вы не начнете устанавливать на него дополнительные компоненты, чего на самом деле делать не следует. Для простоты и безопасности хост-операционная система должна быть минимальной установкой, на которой не должно быть ничего, кроме минимума, необходимого для администрирования (например, sshd).
Недостатки метода 1 на самом деле тоже не проблема, ИМО. Я не думаю, что возникнет какая-либо дополнительная угроза безопасности, поскольку если корневая виртуальная машина каким-то образом сможет вырваться из своего раздела и заразить / повредить другие разделы, то наличие операционной системы на отдельном виртуальном диске может не иметь никакого значения. Два других минуса - это не то, с чем я могу поговорить по собственному опыту, но я знаю, что CentOS, LVM и libvirt достаточно гибкие и надежные, чтобы о них не беспокоиться.
РЕДАКТИРОВАТЬ - Ответ на обновление 1
В наши дни производительность виртуализации сильно снижается, особенно при использовании процессоров со встроенной поддержкой, поэтому я не думаю, что стоит переносить службу с гостевой виртуальной машины на хост-ОС. Вы можете получить повышение скорости на 10%, работая на «голом железе», но вы потеряете преимущества, связанные с небольшой, жесткой и защищенной операционной системой хоста, и потенциально могут повлиять на стабильность всего сервера. Не стоит, ИМО.
В свете этого я все же предпочел бы метод 2.
Ответ на обновление 2
Кажется, что особый способ, которым libvirt предполагает размещение хранилища, является еще одним аргументом в пользу метода 2. Моя рекомендация: переходите к методу 2.
источник
Пока только одна система пытается использовать любой данный LV в режиме чтения / записи в любое время, целесообразно использовать один и тот же VG для хоста и гостей. Если несколько систем попытаются выполнить запись в один и тот же LV, это приведет к повреждению файловой системы.
источник
Возможно, вы захотите взглянуть на это, может быть, возиться и посмотреть, как этот проект делает то, о чем вы говорите.
ProxmoxVE - это чистый KVM-хост, который использует реализацию libvirt на perl, а не более тяжелый аналог RHEL. Он реализует оба сценария.
Виртуальные диски .raw и разрежены, похожи на .qcow, но быстрее.
Также поддерживаются форматы образов дисков qcow & vmdk, но я думаю, что могут быть ограничения LVM. Я ими не пользуюсь, поэтому не могу много говорить об этом.
Хранилище LVM распределяется между виртуальными машинами на узле и может быть устройствами DRBD.
Что касается совместного использования пространства VG операционной системы, единственное ограничение, которое следует учитывать, это размер снимка во время резервного копирования. Здесь это значение может быть изменено в конфигурационном файле, и я иногда вижу на форумах, где людям приходилось его менять, но настройки по умолчанию служат мне уже пару лет - даже с огромными виртуальными дисками.
Детали хранения LVM PVE:
http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing
Вот как устроены VG:
Найдена группа томов "LDatastore1" с использованием типа метаданных lvm2
Найдена группа томов "LDatastore0" с использованием типа метаданных lvm2
Найдена группа томов "pve" с использованием метаданных типа lvm2
Это мои LV:
ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore0 / vm-4017-disk-2' [512,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1' [32,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1' [32,00 ГБ] наследуют
ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 ГБ] наследуют
ACTIVE «/ dev / pve / swap» [3,62 ГБ] наследуют
ACTIVE «/ dev / pve / root» [7,25 ГБ] наследуют
ACTIVE '/ dev / pve / data' [14.80 GB] наследуют
Это LVM на RAID10 с 6 7200 об / мин дисками Seagate Barracuda SATA:
CPU BOGOMIPS: 53199,93
REGEX / SECOND: 824835
РАЗМЕР HD: 19,69 ГБ (/ dev / mapper / LDatastore0-testlv)
БУФЕРНЫЕ ЧИТАНИЯ: 315,17 МБ / с
Среднее время поиска: 7,18 мс
FSYNCS / SECOND: 2439,31
И это LVM на одном Intel X25-E SATA SSD, тот же VG, что и вышеупомянутые / dev / pve / data, где живут виртуальные машины:
CPU BOGOMIPS: 53203,97
REGEX / SECOND: 825323
РАЗМЕР HD: 7,14 ГБ (/ dev / mapper / pve-root)
БУФЕРНЫЕ ЧИТАНИЯ: 198,52 МБ / с
Среднее время поиска: 0,26 мс
FSYNCS / SECOND: 1867,56
источник