есть 2 сервера. 1 для работы, 1 для разработки. Системы стоят отлаженные, а ресурсов железа больше чем необходимо системе. в процессе работы возникает необходимость использовать новое ПО, и как часто это бывает с непосвященным пользователем — делается это путем проб и ошибок, а следовательно и лишний мусор на серверах. на серверах используется Debian и Ubuntu, хотелось бы их оставить хост системами с минимальными телодвижениями
в связи с вышеизложенным есть 2 задачи
1. разделить несколько сайтов по виртуальным машинам для того чтоб к некоторым из них дать безопасный для сервера вне данной виртуалки доступ
2. использовать виртуальную машину для тестов с ПО вроде Jabber, Mail, SQL, Phone сервера пр этом не вредя основному серваку (имеется ввиду чтоб после тестов и выбора снести виртуальную машину не оставив хвостов от тестируемого ПО) но и иметь с хост машины или с виртуальной доступ к тому же sql серверу или астериску
ну и как бонус было бы не плохо получить образ который можно было бы как виртуальную машину переместить с девелоперского сервера на основной в пару команд
изначально думал Virtualbox — удобно перемещать между машинами не взирая на железо, но почитав что пишут другие понял что это далеко не лучший выбор в плане виртуализации и производительности, да и наличие иксов мне не подходит, посмотрел в сторону VServer, но на сколько я понял — скомпрометировав контейнер в нем получаем угрозу хост системе, заинтересовал KVM и XEN, но последний показался слишком мудрым для обычного пользователя, поправьте меня если я дезинформирован и буду рад высказываниям гуру имеющих опыт в данной сфере
PS дабы сократить круг подозреваемых, ограничиваюсь рассмотрением 2-х вариантов KVM и XEN (Kronos). Вариант с Proxmox отпал ввиду того что необходимо с нуля поднимать сервак, да и по сути это тот же KVM только с графическим интерфейсом на базе Debian который не совсем понятно как актуально обновляется.
Если речь идёт только о «поставить/удалить пакеты», то есть среда разработки более-менее вменяемая, то может быть достаточно банального chroot'а и отдельного ssh'а на отдельном IP в нём. Защиты от злодеев не даст, зато минимальный оверхед и удобство в перетаскивании данных туда/сюда.
попробую уточнить на примере.
я ставлю ejabber и он тянет за собой кучу пакетов, далее по каким-то причинам он меня перестает устраивать и я хочу сменить сервер на другой, при удалении сервера часть пакетов на сколько я понимаю могут остаться, виртуалка в данном случае решит проблему с этим — просто убил ее и поднял новую.
защита от злодеев имею ввиду для сайтов которые будут контролироваться не мною и к которым нужно дать доступ на моем сервере — как следствие могут быть залиты скрипты пытающиеся скомпрометировать всю систему, не обязательно владельцем сайта, достаточно того что он может пользоваться TotalComander, а как оттуда уводили пароли я уже не раз видел…
Используйте контейнеры OpenVZ. Это такой изолированный chroot и возможностью ограничения ресурсов. Оверхед у них на много меньше чем у виртуальных машин. Легко переносятся с машины на машину. Я знаю людей, которые их успешно используют для схожих с вами задачь. OpenVZ можно поставить на текущую машину или развернуть с нуля.
OpenVZ — перечрут-недовиртуалка. Память выделяемая через одно место, всякие vzcheck.sh, что бы понять что ему опять не нравится, привязка не только к конкретной OS, но и к конкретному ядру с дополнительными патчами которые не совместимы с другими.
Потери на виртуализацию при использовании аппаратной виртуализации настолько низки, что не стоит связываться с OpenVZ, можно использовать честный Xen и не знать горя
Работа с памятью была изменена в 2.6.32-ом ядре и теперь там все прозрачно. К ядру есть привзяка, но в ближайшем будующем и этот недостаток уйдет и все будет работать на мейнстримной ядре, правда с OpenVZ ядром функциональность будет шире. К примеру в мейстриме пока нет живой миграции.
Про потери все относительно. OpenVZ по прежнему вносит на порядок меньший оверхед и добавляет гибкости.
Вы просто не умели его готовить:). Ну и мы знали про кошмары наших пользователей и все поправили. Советую попробовать еще раз. Теперь работа с памятью ничем не отличается от виртуальных машин, как и у всех конфигурица двумя параметрами ram + swap.
ну там где мне нужны чруты я использую lxc, правда таких мест у меня немного, но спасибо, гляну, если оно так же просто разворачивается теперь, как lxc, то может и найду применение :)
Да, разворачивается просто. Проблема lxc в том что пока из них достаточно просто поафектить хостовую систему. К примеру там по дефолту разрешено писать в /proc/sysrq-trigger, это то что я сразу заметил. OpenVZ контейнеры местами работают более эффективно (например мемори менеджмент). В OpenVZ виртуализовано больше подсистема (например nfs). В OpenVZ есть живая миграция.
Все фичи постепенно переносятся в мейнстримное ядро (в том числе и при нашем участии) и появляются в LXC. А тем временем OpenVZ обрастает новыми фичами.
Версия тулзов OpenVZ, которая не будет работать поверх мейстримного ядра обещает появиться осенью: ru-openvz.livejournal.com/5561.html
спасибо, будем смотреть, может заведу виртуалку, как будет время под это на своем ксене :)
в lxc есть минимум еще одна совершенно прикладная проблема, с тем, что он может при стопе своего таза грохнуть сеть в основной машине, наблюдали в режиме бриджа, если память не изменяет. Но так как во-первых у нас это виртуалки для тестовых целей, а во-вторых всегда есть доступ до них через vnc с ксен-хоста это не показалось страшным
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.