LINUX.ORG.RU
ФорумAdmin

Виртуализация


0

2

День добрый. Хочу разделить свой домашний «мини сервер». Какую лучше виртуализацию выбрать? XEN, KVM или OpenVZ ? Какая будет жрать меньше всего ресурсов? На виртуалках будут крутиться игровые сервера. P.S про то что это настоящий гемор, а я еще совсем зеленый прошу не упоминать :)

Какие ОС будут?
Есть ли требования к кастомным ядрам?

Если все linux и без кастомных ядер - то lxc или openvz (контейнеры). Если нужна полноценная виртуализация - KVM.

Если железо слабое, то еще один плюс к контейнерам.

dvrts ★★★
()
Ответ на: комментарий от Castlejam

Сколько гостей будет?
Какие ОС на гостях?

dvrts ★★★
()
Ответ на: комментарий от Castlejam

centos не стоит мучится с дебианом, если нужна винда, то только kvm.

erzent ☆☆
()

По пожиранию ресурсов вроде как идет в таком порядке
KVM>=XEN>OpenVZ>=LXC.
Другими словами KVM жрет больше всех, LXC меньше всех.
В качестве гипервизора советую libvirt

На работе было на одном серваке 4 kvm и 4 LXC. Все под линем, перешел на openvz доволен как слон. Производительность значительно возросла(из-за перехода kvm->openvz) и ограничение ресурсов просто замечательное, ограничить можно что угодно, а главное внутри гостя видно только доступные ресурсы, в отличие от LXC, где память ограничивается через cgroups, и гость все равно видит всю оперативную память хоста, в итоге бывают накладки.

Все зависит от задач. Если просто сервис повесить в отдельное виртуальное окружение до достаточно LXC. Если же нужна более «виртуализованность» (ограничение ресурсов, сортировка процессов разных гостей и хоста и т.д.) то между Openvz и LXC советую Openvz. Это естественно если все гости и хост будут на линуксах.

Для разных систем, советую kvm или xen. Для xen нужны модифицированные образы ОС, для паравиртуализации. Также xen вроде умеет работать как и kvm, через аппаратную виртуализацию процессора. В таком случае производительность будет равная.

К тому же никто не мешает использовать несколько технологий одновременно. На другом серваке у нас на kvm стоит Windows Server 2008 R2, и куча линуксов на LXC.

Кстати все на debian'ах у нас. Ну для libvirt (гипервизор) и правда centos роднее.

demsi
()
Последнее исправление: demsi (всего исправлений: 2)

для сервера OpenVZ и ещё была какая-то специфичная контейнерная. КВМ я считаю, излишество, под нужны консольки.

darkenshvein ★★★★★
()
Ответ на: комментарий от dvrts

В вики debian написано:

LXC may not provide sufficient isolation at this time, allowing guest systems to compromise the host system under certain conditions

LXC не готов? Или старая информация?

nuke666
()
Ответ на: комментарий от nuke666

Если использовать в качестве chroot, то готов полностью.
Но по функционалу до openvz ему далеко.
Единственное что не удобно, он активно развивается. Например помню в один прекрасный момент пропала команда lxc-list.

demsi
()
Ответ на: комментарий от dvrts

Это не так

А какие отличия? юзаю OpenVZ на debian не вижу каких либо ограничений. Вы не могли бы конкретизировать?

demsi
()

Если контейнеры - попробуй Docker, оно щас очень активно развивается.
Если именно «виртуализация» - рекомендую KVM, благо выбор по актуальным дистрам сейчас очень хороший.

Yustas ★★★★
()

Докер! Докер! Стильно, модно, молодёжно, будешь как все в стаде, ничо не соображая качать чьи-то образы из интернета и запускать их.

anonymous
()
Ответ на: комментарий от nuke666

LXC не готов?

LXC (а точнее, его ядерная часть) — это то, чем стремится стать OpenVZ. Последние версии vzctl уже умеют работать с ванильным ядром, но функциональность пока недостаточна для полноценной реальзации всего того, что есть в ядре OpenVZ.

Так что да, пока существует OpenVZ ядро — LXC не готов. Как станет готов, так и нужда в существовании отдельного ядра отпадёт, и тогда OpenVZ тулзы и LXC тулзы станут просто разными способами управления одной и той же функциональностью, доступной в ядре.

INFOMAN ★★★★★
()
Последнее исправление: INFOMAN (всего исправлений: 2)
Ответ на: комментарий от Castlejam

Убрали из-за каких-то несовместимостей с политикой обновлений дебиана, можно добавить отдельный репозиторий и поставить оттуда.

INFOMAN ★★★★★
()
Ответ на: комментарий от INFOMAN

о функциональность пока недостаточна для полноценной реальзации всего того, что есть в ядре OpenVZ

Я бы сказал что в LXC ОЧЕНЬ много не хватает того, что есть в ядре OpenVZ.

demsi
()
Последнее исправление: demsi (всего исправлений: 1)
Ответ на: комментарий от Castlejam

http://www.itroad.ru/iz-novogo-debian-7-wheezy-ubrali-podderzhku-openvz это чепуха? :)

Я конечно не понимаю, что автору помешало просто в /etc/apt/sources.list подключить репозиторий OpenVZ и пользоваться на здоровье. Я перешел на OpenVZ уже когда использовал Debian Wheezy. Поэтому видимо таких проблем не заметил.

Ну обновился он, ядро исчезло. Ну подключи репозиторий OpenVZ да установи ядро. Перезагрузись. Все - проблема решена. Решение 5-15 минут. Автор статьи сильно передергивает.

demsi
()
Ответ на: комментарий от INFOMAN

О как завернули, два раза перечитал. А я думал , что это ребята из Paralels начали пушить часть своего ядерного кода в ванильное ядро - а LXC это как раз пользует. Да и LXC для чего не готов? Для дома?

aeX1pu2b
()
Ответ на: комментарий от aeX1pu2b

Зато ядро родное

Согласен. Это удобней.

А я думал , что это ребята из Paralels начали пушить часть своего ядерного кода в ванильное ядро

А вот это тоже очень круто.

demsi
()
Ответ на: комментарий от INFOMAN

Вроде бы поставил. Разобрался с квотами итп (по мануалу все). А как идет привязка аккаунтов к созданным контейнерам?

Castlejam
() автор топика
Ответ на: комментарий от Castlejam

А как идет привязка аккаунтов к созданным контейнерам?

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

prizident ★★★★★
()
Ответ на: комментарий от prizident

Извиняюсь, не подумал. Забыл что контейнеру дается IP

Castlejam
() автор топика
Ответ на: комментарий от prizident

А можно ли настроить подключение к контейнерам с глобала при условии что в наличии есть всего один IP ?

Castlejam
() автор топика
Ответ на: комментарий от Castlejam

в таблице nat

-A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11080 -j DNAT --to-destination 192.168.10.11:80 -m comment --comment «forward http to ve111»
-A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11022 -j DNAT --to-destination 192.168.10.11:22 -m comment --comment «forward ssh to ve111»

потом заходишь ssh на HNIP:11022

prizident ★★★★★
()
Ответ на: комментарий от Castlejam

-A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11080 -j DNAT --to-destination 192.168.10.11:80 -m comment --comment «forward http to ve111» -A PREROUTING -d <<HNIP>> -p tcp -m tcp --dport 11022 -j DNAT --to-destination 192.168.10.11:22 -m comment --comment «forward ssh to ve111»

Обычный nat.
prizident здесь имеет в виду что эти правила iptables прописываются на машине хоста.

HNIP - Внешний IP хоста.
11080,11022 - порты через которые ты будешь подключаться из вне к гостю. То есть на хосте это будут порты 11080, 11022, при подключении к ним, тебя перенаправит на 80,22 порты гостя. prizident приводит пример с ними, так как обычно на 80 висит веб-сервер, а на 22 ssh. Что тебе нужно пробросить в твоем конкретном случае решать тебе.
192.168.10.11 - это предположение что IP адрес гостя такой.
-m comment --comment «forward http to ve111 - комментарии не обязательны.

Другими словами если немного упростить, нужно вбить две команды:
iptables -t nat -A PREROUTING -d ip_хоста -p tcp -m tcp --dport 11080 -j DNAT --to-destination ip_гостя:80
iptables -t nat -A PREROUTING -d ip_хоста -p tcp -m tcp --dport 11022 -j DNAT --to-destination ip_гостя:22

Порты 11080,11022 использовать не обязательно, можешь использовать любые на твое усмотрение. Главное чтобы они были не заняты.

Если есть желание разобраться в iptables советую прочитать http://www.opennet.ru/docs/RUS/iptables/

demsi
()
Ответ на: комментарий от Castlejam

через тунели putty может быть как-то?

Через тунели тоже можно.
Если подключение идет с машины на линуксе, у нужно подключиться к ssh гостя.

Достаточно на хосте настроить ssh. Не забыть включить опцию AllowTcpForwarding.
На госте я по умолчанию понимаю что ssh тоже настроен и готов принимать входящие соединения.
По умолчанию, чтобы было понятно где какой порт, пусть на хосте ssh слушает на 2222 порту, а на госте на 22 порту. Хотя ничего не мешает им слушать одинаковые порты.
Из вне из клиента пишем ssh -f -N -p 2222 -L локальный_порт:ip_гостя:22 ip_хоста
Туннель проброшен, теперь можно подключаться к гостю по ssh.
Открываем другой ssh -p локальный_порт 127.0.0.1

demsi
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.