Итак, привет всем!
Предистория вопроса
1. Когда разворачивался комплекс, то я (по недостатку опыта) не очень думал об аспектах виртуализации. И заказал серверов по минимуму. Под конкретные решаемые задачи. Шлюз доступа в iNet, файловый сервер, сервер базы данных. Соответственно по железу они различны. Самый слабый сервер - на двухъядерном пеньке с 2 гигабайтами, файл-сервер - тоже самое, но 4 гигабайта на борту, сервер БД - 2 4-х ядерных ксеона с 12-ю гигабайтами. Каждый сервер имеет по два гигабитных сетевых интерфейса. Один из каждой пары смотрит в локальную сеть и доступен юзерям, вторые - объединены в свою независимую сеть и через них сервера обмениваются своей служебной информацией. Коммутатор - управляемый гигабитник, на котором организовано 2 свича. Для юзерей и служебный. Это - ядро железное, оно отлито из бронзы и в него можно только добавлять память. Но не сервер.
2. В процессе разворачиния комплекса, то пришел к выводу, что необходимо иметь распределенную файловую систему высокой доступности. Что и было реализовано на glusterfs и drbd (на файловом сервере и сервере базы данных). А высокую доступность обеспечивает heartbeat, который перебрасывет сервисы самбы, primary-диск drbd и алиасный "фиксированный" IP-адрес с одного физического узла кластера на резервный. Всё это работает как часы.
3. Далее возникла нужда решать еще несколько специфичных задач. Для чего на самом мощном сервере (базы данных) был поставлен VirtualBox и в нем развернуто несколько виртуальных машин, решающих эти задачи. В том числе и терминальный сервер на базе RFR-14+RX@Etersoft+wine@etersoft+1C7.7+Консультант (надо обепечить работу ремутных площадок). Все это работает устойчиво. Но...
Нарисовалась проблема:
При работе нескольких пользователей в терминальном доступе складывается ощущение, что VirtualBox не разделяет сетевой интерфейс между этими пользователями в конкуренцию, а делит его пропорционально - если 2 юзера, то каждому по половинке пропускной способности, если 5 - то каждому только по 1/5-й. Соответственно работа идет не слишком шустро. Ну а учитывая, что сам сетевой интерфейс в VB (я где-то читал) всего на 100 мегабит, то тормоза получаются заметные.
Пути решения проблемы:
1. Простой и эффективный. Развернуть терминальный сервер на самом файловом сервере. Здесь достигаем максимальную скорость работы с данными (раза в 3, примерно, быстрее). Но... Я не хочу пускать юзерей на "рабочий" сервер. Пусть они лучше в виртуалке работают, её не жалко и случись с ней что - поднимается с резервного образа за 5 минут. Если не быстрее.
2. Заменить среду виртуализации VirtualBox на иное. Например, на KVM. И вот здесь возникает непонятность в виртуальном сетеплетении.
Теперь собственно вопрос. Как мне правильно сплести сеть.
- Поднимать виртуальную сеть с NAT, за котрым будут стоять виртуальные машины, мне не подходит. Виртуальные машины должны иметь IP-адреса локальных юзерской и служебной сетей. Так что, дефолтная настройка отпадает. Точнее - я не умею её приготовить таким образом, чтобы KVM пробрасывал внешние вызовы на те или иные IP-адреса на нужные виртуальные машины, стоящие за NAT, в виртуальной сети. Такое возможно?
- Если поднимаем на физическом интерфейсе бридж, то сетевые интерфейсы виртуальных машин на нем будут работать полноценно, иметь нужные IP-адреса моих сетей, но я теряю возможность иметь блуждающий IP-адрес файлового сервера, который перебрасывается между хостами хертбитом. А файловый сервер должен быть развернут именно на узле кластера, а не в виртуальной машине. Так как в виртуальную машину не пробросить /dev/drbd0... DRBD привязывает сервисы файлового сервера крепко к железному компьютеру.
- Если пользуемся macvtap-сетевым интерфейсом виртуальных машин, то физический интерфейс работает в обычном режиме, на нем можно поднять кучу алиасных адресов, но мы теряем возможность обратиться собственно к своему родному физическому интерфейсу. А нужно обращаться именно к нему, по алиасу, который на нем может быть развернут.
Коллеги, ликвидируйте мою безграмотность, подскажите, как вывернуться, как настроить систему таким образом, чтобы были в сети и виртуальные KVM-машины, чтобы на физических интерфейсах можно было поднимать (и управлять ими) алиасные IP-адреса, и чтобы эти виртуальные машины могли обращаться к этим алиасным IP-адресам, поднятым на хостах, на которых и крутятся виртуальные машины. Как это реализовать?
В VirtualBox такой проблемы не возникало вообще. А вот в КVM - не могу найти выход.
LinuxForum.Fans
Организация сети в KVM
Автор: Cruiser78
10 сообщений
5643 просмотров
таким образом, чтобы KVM пробрасывал внешние вызовы на те или иные IP-адреса на нужные виртуальные машины, стоящие за NAT, в виртуальной сети. Такое возможно?
возможно, но очень муторно
я теряю возможность иметь блуждающий IP-адрес файлового сервера, который перебрасывается между хостами хертбитом
купить еще по одной карте - деньги небольшие
[quote="Cruiser78"]таким образом, чтобы KVM пробрасывал внешние вызовы на те или иные IP-адреса на нужные виртуальные машины, стоящие за NAT, в виртуальной сети. Такое возможно?
возможно, но очень муторно
я теряю возможность иметь блуждающий IP-адрес файлового сервера, который перебрасывается между хостами хертбитом
купить еще по одной карте - деньги небольшие[/quote]
Об дополнительной карте я не думал. Деньги небольшие, но сервера - тонкие, 1DIN. И в них нет райзеров. Так что - одной картой, без райзера, не обойтись... Но, это действительно - самое простое решение.
А вот как если помучится? Без третьей платы?
но сервера - тонкие, 1DIN. И в них нет райзеров. Так что - одной картой, без райзера, не обойтись...
заменить на двухпортовые карты, немного дороже, но решение вполне себе рабочее
А вот как если помучится? Без третьей платы?
зачем всегда и во всем пытаться и рыбку съесть и аквариум выпить? бюджет из руководства выбивается элементарно, показав сколько такое решение стоит по сравнению с vmware
[quote="Cruiser78"]но сервера - тонкие, 1DIN. И в них нет райзеров. Так что - одной картой, без райзера, не обойтись...
заменить на двухпортовые карты, немного дороже, но решение вполне себе рабочее[/quote]
Да невозможно это. Материнская плата сервера несет на борту 2 сетевых интерфейса. При этом можно добавить только одну плату. И ту через райзер. Так как корпуса серверов - тонкие, 1DIN.
То, что финансирования добиться можно (и как именно) - это я знаю. Зддесь нет проблем. Просто - не хочу. Не считаю это - своевременным. Тем более, что сейчас - всё работает. И пользователи не жалуются.
KVMизация - это чисто мои амбиции и любопытство... Не больше. Тратить казенные деньги на удовлетворение своего любопытства?...
Тратить казенные деньги на удовлетворение своего любопытства?...
Это фундамент науки.
во первых это как раз то чем занимаются хорошие сисадмины. сидят и придумывают как бы улучшить доверенное им хозяйство, причем так чтоб работы в итоге стало поменьше, что при этом всегда давит на бюджет (поэтому бюджет планируется и выдается каждый год заново). ну а вообще, если свич поддерживает, то можно попробовать еще поиграться с vm-fex или vepa, или прикрутить openvswitch, вдруг такие интерфейсы поддерживают алиасы...
Но принцип KISS никто не отменял
Это фундамент науки.
Неправ полностью. Я был одно время научным работником. Даже должнсть занимал младшего научного сетрудника в НИИ вооружений ВМФ СССР. А потом в ЛЭТИ Ульянова-Ленина. Так вот - истинно говорю - фундамент науки это ватка и липкая лента. В крайнем случае - сургуч. :-)
А наука это способ удовлетворения собственного любопытства за казенный счет.
ТИ по поводу финансирования. У меня есть джентельменское негласное соглашение с руководством. Я не тяну из него деньги на информатизацию, а оно, в ответ, не тянет мне жилы.
А наука это способ удовлетворения собственного любопытства за казенный счет.
Именно это я и имел в виду.
Войдите или зарегистрируйтесь, чтобы ответить.
