Группа томов LVM, совместно используемая хостом KVM / libvirt и гостями: это плохая идея?


12

Я только что создал новый виртуальный хост на основе KVM / libvirt, содержащий 4 жестких диска SATA II и работающий с CentOS 5.5 x86_64.

Я решил создать диски виртуальных машин как логические тома в группе томов LVM, управляемой как пул хранения libvirt, вместо обычной практики создания дисков в виде образов qcow.

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

Какой метод выбрать и почему?


Способ 1. Использование группы томов хоста VM

Реализация:

  • маленький RAID1, md0содержащий /bootфайловую систему
  • большой RAID10, md1занимающий оставшееся пространство, в котором находится группа томов LVM vghost. 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)

Я задал вопрос (# 272324), где ваше решение № 1 было бы очень хорошим ответом! И это именно то, к чему я стремился в подобной установке - и я до сих пор вполне доволен этим. У меня, однако, есть проблема, когда diskIO в гостевой системе работает намного медленнее, чем при «монтировании контура» того же LV в хосте.
stolsvik

Ответы:


3

Хорошо продуманный вопрос!

Я бы выбрал метод 2, но это скорее личное предпочтение. Для меня недостатки метода 2 не так уж и важны. Я не вижу, как хост-операционная система перерастает свой раздел на 5-10 ГБ, если только вы не начнете устанавливать на него дополнительные компоненты, чего на самом деле делать не следует. Для простоты и безопасности хост-операционная система должна быть минимальной установкой, на которой не должно быть ничего, кроме минимума, необходимого для администрирования (например, sshd).

Недостатки метода 1 на самом деле тоже не проблема, ИМО. Я не думаю, что возникнет какая-либо дополнительная угроза безопасности, поскольку если корневая виртуальная машина каким-то образом сможет вырваться из своего раздела и заразить / повредить другие разделы, то наличие операционной системы на отдельном виртуальном диске может не иметь никакого значения. Два других минуса - это не то, с чем я могу поговорить по собственному опыту, но я знаю, что CentOS, LVM и libvirt достаточно гибкие и надежные, чтобы о них не беспокоиться.

РЕДАКТИРОВАТЬ - Ответ на обновление 1

В наши дни производительность виртуализации сильно снижается, особенно при использовании процессоров со встроенной поддержкой, поэтому я не думаю, что стоит переносить службу с гостевой виртуальной машины на хост-ОС. Вы можете получить повышение скорости на 10%, работая на «голом железе», но вы потеряете преимущества, связанные с небольшой, жесткой и защищенной операционной системой хоста, и потенциально могут повлиять на стабильность всего сервера. Не стоит, ИМО.

В свете этого я все же предпочел бы метод 2.

Ответ на обновление 2

Кажется, что особый способ, которым libvirt предполагает размещение хранилища, является еще одним аргументом в пользу метода 2. Моя рекомендация: переходите к методу 2.


Благодарю. Я добавил 2 обновления к моему вопросу, которые дополнительно объясняют, почему я перечислил некоторые минусы, на которые вы обратились. Изменения вообще меняют ваше мнение?
Мосно

@mosno: обновил мой ответ в ответ на ваши обновления.
Стивен Понедельник

Спасибо всем за ваши ответы, все были полезны для меня, и было трудно выбрать, чей ответ принять. Я выбираю Стивена, потому что чувствую, что он делает все возможное, чтобы ответить на заданный вопрос. Для справки, хотя я согласен, что метод 2, вероятно, лучше, я решил остаться с методом 1, потому что он работает и из-за временных ограничений.
Мосно

1
Кроме того, я пока остановился на методе 1, потому что думаю, что было бы полезно изучить ограничения этого метода. Например, я узнал, что если в гостевой ОС вы создаете LVM PG непосредственно на устройстве (например, устройство / dev / vda вместо раздела / dev / vda1), то в pvscan хост-системы выводится список PV гостя (т.е. используйте / dev / vda1, а не / dev / vda).
Mosno

1

Пока только одна система пытается использовать любой данный LV в режиме чтения / записи в любое время, целесообразно использовать один и тот же VG для хоста и гостей. Если несколько систем попытаются выполнить запись в один и тот же LV, это приведет к повреждению файловой системы.


безусловно, существует повышенный уровень сложности для управления этим. Это умно .. может быть слишком умно.
Дворник Unix

@ user37899: это обычный способ работать с LVM
Хавьер

спасибо, но я понимаю это; Я не планировал этого делать.
Мосно

когда я выполняю «lvscan» на хост-ОС, он сообщает о LV гостя как «ACTIVE». На хосте не установлено LV. Является ли LV, просто находящийся в состоянии «ACTIVE», «режимом чтения / записи», или вы подразумеваете явное монтирование к файловой системе хоста?
Мосно

Я имею в виду явное монтирование.
Игнасио Васкес-Абрамс

1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.