Xen-based виртуализация

[anovo]

Коллеги, коротко описание задачи.
1. Small office - 20 РМ, на клиентах ХР.
2. На серверной стороне - единственный МСЭ под Линуксом (sshd, natd, netfilter)
3. Есть серверное железо начального (Xeon 3075 (2 core x 2.66 w/VT) / 4 Gb DDR2 RAM ECC / 2 x 300 G SATA / LSI RAID)

Задача - организовать, используя бесплатные реализации GNU\Linux, следующее:
1. Системные сервисы - DHCP/DNS/LDAP
2. Storage-сервис - SMB
3. БД сервис - MySQL
4. Майл-сервис
5*. Интернет-сервисы - (WWW/SMF/CMS/FTP/VPN)
* - некритично в данный момент

Сервисов несколько, типы у них разные, серверное железо одно - решил использовать технологию виртуализации Xen-based "из коробки" (чтобы не собирать из исходников xen-kernel).
Посмотрел доки и реализации Citrix XenServer Express 4.1 / openSuSE 10.3 Xen-kernel  / CentOS 5.1 Xen-kernel.
Решил остановиться на последнем. Используя аппаратную поддержку виртуализации Intel VT, можно использовать вирт-машины как full-virt (QEMU), так и para-virt (XEN).

Вопросы.
1. Есть ли положительный опыт использования в похожей ИТ-среде бесплатных дистрибов с xen-ядром?
2. Есть ли положительный опыт использования в похожей ИТ-среде CentOS 5.1 xen-based?

[rPman]

причём тут ксен?
P.S. из указанного списка непонятно только про SQL (что за БД) и WWW (может нужен именно IIS с ASP).

[anovo]

причём тут ксен?
P.S. из указанного списка непонятно только про SQL (что за БД) и WWW (может нужен именно IIS с ASP).

Встречный вопрос по сабжу - у Вас какой опыт в использовании виртуализации в production environment?
Xen при том, что (а) не хочется хостить все требуемые сервисы в пределах одной ОС, а физический сервер один (хотя и возможны некоторые варианты с chroot) и (б) используется ядро 2.6.18.53-el5xen.
ПС. 1. MySQL и 2. IIS отдельно от винды не поставляется (а), лицензия и CAL на нее стоят денег (б), топик в nix-ветке, потому Apache полностью устраивает (в), ASP тоже не нужен, т.к. есть PHP (г).

[never hood]

Правильная идея.
Виртуализация в CentOS подробно описана в руководстве, прилагаемом к дистру (взято из RHEL).
Там все неплохо расписано (еще более подробно все расписано в этом руководстве для RHEL 5.2, который уже вышел, а CentOS 5.2 выйдет буквально на днях, так что уже можно приступать к изучению последней версии документа - он более чем в два раза объемнее).
Возьмите здесь.

[SG_]

Правильная идея.
Виртуализация в CentOS подробно описана в руководстве, прилагаемом к дистру (взято из RHEL).
Там все неплохо расписано (еще более подробно все расписано в этом руководстве для RHEL 5.2, который уже вышел, а CentOS 5.2 выйдет буквально на днях, так что уже можно приступать к изучению последней версии документа - он более чем в два раза объемнее).
Возьмите здесь.

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

[never hood]

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

если говорить о сервере, который будет работать годами (до семи уж точно), то именно штатные решения и стоит брать во внимание. Иначе, с каждым обновлением ядра вы будете пересобирать свое решение.
RH (как и CentOS) в этом смысле очень(!) рационально себя ведет, ведь даже новые драйвера портируются для старых дистрибутивов. Увы, но ни vserver, ни virtuozzo не входят в стандартные репозитории, а если процессор поддерживает виртуализацию, то xen (а также kvm) весьма достойное решение - хорошо документированное и официально поддерживаемое.

[anovo]

Правильная идея.
Виртуализация в CentOS подробно описана в руководстве, прилагаемом к дистру (взято из RHEL).
Там все неплохо расписано (еще более подробно все расписано в этом руководстве для RHEL 5.2, который уже вышел, а CentOS 5.2 выйдет буквально на днях, так что уже можно приступать к изучению последней версии документа - он более чем в два раза объемнее).
Возьмите здесь.

Круто, будем ждать (примерно обещают на 14 июня)
Благодарю за инфо   Точно, у меня RHEL V-guide 5.1 был.

если все сервисы линуксовые то зачем вообще виртуализацией железа страдать?

Вопрос резонный, но ответ уже дан в предыдущем посте. Именно "штатные" средства я стараюсь использовать в production environment, будь то МС либо никс. А в случае GNU\Linux-дистров (CentOS, openSuSE) разработчиками дистров в смысле Virtualization подразумевается и применяется Xen/Qemu-based техника. Ну и опять же уже резонно замечено, что аппаратная поддержка виртуализации (hardware assistance Intel VT/AMD-V) позволяет Xen-ядру использовать как режим бинарной трансляции (full), так и режим паравиртуализации (с модификацией ядра для замены системных вызовов гипер-вызовами). По всем тестам, доступным в public domain и которым я вроде доверяю, производительность в случае full-v на Linux-системах страдает не более чем на 5-10% в самых неблагоприятных случаях по сравнению с нативным запуском, что для описанного случая приемлимо. К тому же, имей я бюджет на 2 сервера начального уровня, можно штатно использовать LiveMigration, что предусмотрено RHEL Virtualization, и (если не ошибаюсь) не доступно в случае OpenVZ. Ну и накладные расходы на знакомство с еще одной технологией опять же. Да и зачем отсекать возможность запуска Windows в потенциале, хотя, верно замечено, пока нет потребности.

[rPman]

так и не понял необходимость виртуализации, как уже тут говорилось, для повышения.. секурности можно воспользоваться и chroot, но ИМХО для указанных задач этого не требуется, слишком узкоспециализированый получается сервер. Даже на web сервере не собирается крутиться неконтролируемый код. Виртуализация могла бы быть актуальна для например 'публичного' сервера приложений (для третьих лиц).
production environment - чем больше вы полагаетесь на 'готовые решения' тем ниже секурность (как ни странно, у 'взломщиков' банально готовые решения, не нужно подстраиваться под реалии), чем больше донастраиваете ручками (например банальная смена алгоритма использования ssh - хоть те же порты сменить) - тем она выше. chroot и xen - относится к этим донастройкам ручками (хотя у виртуализации больше вкусностей).
P.S. вообще то у меня опыта коммерческой установки *nix решений практически нет.

[SG_]

так и не понял необходимость виртуализации, как уже тут говорилось, для повышения.. секурности можно воспользоваться и chroot, но ИМХО для указанных задач этого не требуется, слишком узкоспециализированый получается сервер. Даже на web сервере не собирается крутиться неконтролируемый код. Виртуализация могла бы быть актуальна для например 'публичного' сервера приложений (для третьих лиц).
production environment - чем больше вы полагаетесь на 'готовые решения' тем ниже секурность (как ни странно, у 'взломщиков' банально готовые решения, не нужно подстраиваться под реалии), чем больше донастраиваете ручками (например банальная смена алгоритма использования ssh - хоть те же порты сменить) - тем она выше. chroot и xen - относится к этим донастройкам ручками (хотя у виртуализации больше вкусностей).
P.S. вообще то у меня опыта коммерческой установки *nix решений практически нет.

у меня есть. и сталкивался с косяками стандартного и высоконадежного ядра от редхат (центос). предпочитаю ядро собирать под железку. не систему, как гентушнеки, но ядро. вот если бы мне пришлось сотнями серверов оперировать, то может быть и стал юзать полностью стандартные решения и стандартные конфиги. а если чо глючит, то все стрелы переводить на поставщика софта. с десятками серверов проблемы собрать ядрышко один раз при установке и потом иногда перебирать по уже готовому конфигу нету. зато более гибко: устраивает ведро - сервера годами аптайм наращивают (есть несколько с 900 дней аптайма), не устраивает - пересобрал на то что нужно и не ждеш когда же ретхат почешется...

что касается падения производительности...  работал с xen на амазоне. зверушка средней паршивости. и есть большие сомнения, что можно лехко и непринужденно поднять пару десятков линухов в ксене на средней железке и чтобы ресурсы поедали приложения, а не ядра и ненужные демоны. vserver же замечательно это делает. потому что ему не нужно держать десятки загруженных ядер + кучу ненужных в виртуальной системе сервисов.
на vserver это делается лехко и можно (нужно!) под каждый обособленный сервис или группу сервисов создавать свою систему. в этом случае их лехко апгрейдить, переносить, контролировать...

[never hood]

что касается падения производительности...  работал с xen на амазоне. зверушка средней паршивости. и есть большие сомнения, что можно лехко и непринужденно поднять пару десятков линухов в ксене на средней железке и чтобы ресурсы поедали приложения, а не ядра и ненужные демоны. vserver же замечательно это делает. потому что ему не нужно держать десятки загруженных ядер + кучу ненужных в виртуальной системе сервисов.
на vserver это делается лехко и можно (нужно!) под каждый обособленный сервис или группу сервисов создавать свою систему. в этом случае их лехко апгрейдить, переносить, контролировать...

Из вышесказанного так и не стало ясно о каком режиме xen'а идет речь? О полностью виртуальном или паравиртуальном. Я так полагаю, что подразумевался первый режим, а коли об альтернативах не слова, то паравиртуальный даже не был опробован.
А vserver, действительно, неплох, но увы не идет в поставке.
И озвучьте, пожалуйста, какие косяки были вами обнаружены в стандартных ядрах.
Это поможет другим не нарываться, да и голословности не будет.

[anovo]

что касается падения производительности...  работал с xen на амазоне. зверушка средней паршивости. и есть большие сомнения, что можно лехко и непринужденно поднять пару десятков линухов в ксене на средней железке и чтобы ресурсы поедали приложения, а не ядра и ненужные демоны. vserver же замечательно это делает. потому что ему не нужно держать десятки загруженных ядер + кучу ненужных в виртуальной системе сервисов.
на vserver это делается лехко и можно (нужно!) под каждый обособленный сервис или группу сервисов создавать свою систему. в этом случае их лехко апгрейдить, переносить, контролировать...

Требуется уточнить примерные параметры и стоимость "средней железки" тогда. На описанном в начале оборудовании в тестовом режиме 4 full вирт-сервера вполне себе нормально запустились. Больше 5 на имеющейся железке вряд ли кто рискнет запускать. Ну а 10++ ВМ - думаю, потребуется от 8-ядер и, видимо, не менее 8 Гб ОЗУ. Да и надо для таких задач использовать SAN и LiveMigration. Ну и при серьезном использовании виртуализации, видимо, будет смысл приобретать RHEL, а не CentOS. Хотя практика - критерий истины, как известно.  

[SG_]

Из вышесказанного так и не стало ясно о каком режиме xen'а идет речь? О полностью виртуальном или паравиртуальном. Я так полагаю, что подразумевался первый режим, а коли об альтернативах не слова, то паравиртуальный даже не был опробован.
А vserver, действительно, неплох, но увы не идет в поставке.
И озвучьте, пожалуйста, какие косяки были вами обнаружены в стандартных ядрах.
Это поможет другим не нарываться, да и голословности не будет.

на амазоне как раз паравиртуализация. но все равно девайсы тормознее, чем в живой системе. скажем запись на диск всего 30 мег/c. сетевую производительность мерять смысла нет на 100мбит. и разумеется я не мог поменять реальную загрузку железки во время этих операций. но стопудово оно было хуже, чем в случае vserver. и это при  одном виртальном сервере на реальную железку. амазон называет их instance.

про глюки ядер: все они были давно, т.к. я редхаты и центосы сам не использую. последний глюк был год назад, на среднезагруженной системе локалхост пингатся флудовым пингом со скоростью 100-200 пакетов в секунду и с 20% пакетлостом. ping -f 127.0.0.1 если чо. разумеется, все остальное было еще хуже. виновато было ведро из стандартной поставки. 2.6.7 или 9. вобщем такой диапазон.