Непонятность с бриджами

Привет всем!

Что то я туплю с бриджами (в перспективе поставить несколько виртуалок под KVM).
Работаю по официальной хавтушке: http://docs.fedoraproject.org/ru-RU/Fedora/12/html/Virtualization_Guide/sect-Virtualization_Guide-Network_Configuration-Bridged_networking_with_libvirt.html
А именно, имею хост, в котором интерфейс описан следующим образом:

Отличие от стандартного описания - только последняя строчка, BRIDGE. Если её нет, хост поднимает сеть и интерфейс получает заданный адрес. Добавляем эту строчку и файл ifcfg-virtbr0:

Делаем network restart. Мост с заданным IP поднимается, но... сам хост (интерфейс p5p1) свой IP теряет:

Если я убираю тотально бриджи, то интерфейс снова получает нужный мне IP:

Коллеги, подскажите, это нормальное поведение для бриджа? Если нормально, то как тогда через бридж обратиться к моему хосту, который должен иметь IP-адрес 192.168.43.8 и висеть на интерфейсе p5p1? Или мне нужно для бриджа задать адрес 192.168.43.8, а потом виртуалки будут сами получать свои айпишники из моей сети по dhcp?

Я по этому пути еще не ходил ни разу и для меня это - некоторая неожиданность...

"Cruiser78" написал:

нужно для бриджа задать адрес 192.168.43.8, а потом виртуалки будут сами получать свои айпишники из моей сети по dhcp

и если позволите: http://hrafn.me/2010/01/kak-nastroit-bridzh-dlya-kvm-na-red-hat-enterprise-linux-5-4/

айпи хоста должен быть прописан в бридже. p5p1 айпи адрес не нужен

dyasny написал:

айпи хоста должен быть прописан в бридже. p5p1 айпи адрес не нужен

Спасибо. С этим (с помощью сообщества) разобрался. Остался только один вопрос. У меня сейчас на серверах есть "блуждающий" IP-адрес (его heartbeat двигает на основной рабочий сервер вслед за переездом сервисов). Сейчас этот бродяга поднимается как очередной виртуальный интерфейс на физическом интерфейсе (ifconfig eth0:1 IP up). Как правильно поднимать такой виртуальный интерфейс, в случае если мы имеем бридж? Прибивать его к физическому интерфейсу как и раньше или к бриджу? Понимаю, что вопросы тупые, но развалить работающую ситему не хочу ни разу. Вначале все надо "на бумаге" выстроить.

Cruiser78 написал:

Вначале все надо "на бумаге" выстроить.

вот это точно :)

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

dyasny написал:

если нужен heartbeat, для него выделяется отдельный интерфейс или даже бонд. ну а вообще, зачем там кластер?

Вопрос не об интерфейсе heartbeat'а. Узлы себя контролируют как раз по отдельному интерфейсу. Вопрос о блуждаещем между узлами алиасном IP-адресе, по которому юзеры и имеют доступ к сервисам этого кластера. Сейчас у меня реализовата такая топология:
1. Сервера имеют по 2 сетевых гигабитных интерфейса.
2. Один смотрит в юзерскую LAN, имеет фиксированный IP и блуждающий алиасный IP адрес.
3. Вторые объединены в отдельную выделенную сеть на отдельном (VLAN) коммутаторе. И по этим вторым сервера гонят служебный трафик, синхронизируют drbdb-диски и так далее. Юзера той служебной сети не видят и тот трафик им не помеха.
4. Поставить дополнительные сетевые карты не имею технической возможности (сервера такие). 1DIN в шкафу.

Вопрос - зачем кластер я даже и обсуждать не хочу. Ибо нужна отказоустойчивость и высокая доступность моих сервисов. Бизнес такой, ждать, пока я что починю или диски в зеркале поменяю - неприемлемо.
Отсюда и вопрос - каким образом реализовать на топологии с мостом блуждающий алиасный IP-адрес. К физическому интерфейсу он прибивается на раз, а вот как быть с мостом?
Сейчас использую для виртуальных машин VirtualBox. С ним такой засады с алиасными интерфейсами нет. Но там я уперся в низкую производительность собственно сетевого интерфейса. А именно - типовая процедура в 1С 7.7 "переиндексация" базы на чистом железе (которое раздает самбу) через самбу у меня проходит за, примерно, 11..12 минут, то если я её запускаю из виртуального терминального сервера (ось та же, RFR-14, но виртуалка запущена на ином, тоже производительном, хосту, там на голом железе оно проходит минут за 8 ) курить надо уже 30-35 минут. Что меня не устраивает ни разу.
Выпускать юзерей на "базовое" железо не хочу принципиально. Пусть в виртуалке резвятся. Вот и ищу решения, которые позволят с малой кровью обеспечить эффективную работу.

во первых мне немного смешно слышать о боевом кластере с vbox, это мне кажется само по себе немного странным.
во вторых, такая артхитектура с ВМ ставится немного иначе - берутся нормальные серверы, поднимается нормальный SAN и который если и реплицировать то на удаленный сайт (железом или тем же Gluster-ом)

если интересно, и озвучите бюджет, то могу помочь подобрать решение на kvm

dyasny написал:

во первых мне немного смешно слышать о боевом кластере с vbox, это мне кажется само по себе немного странным.
во вторых, такая артхитектура с ВМ ставится немного иначе - берутся нормальные серверы, поднимается нормальный SAN и который если и реплицировать то на удаленный сайт (железом или тем же Gluster-ом)

если интересно, и озвучите бюджет, то могу помочь подобрать решение на kvm

Бюджета нет. Только зарплата. Моя. То, что архитектура с VM должна быть иной - я вижу. Сервисы юзерские с хостов должно перевести в виртуальные машины и они уже должны их раздавать юзерам. Но переделать тто, что выросло за несколько лет эксплуатации - нереально. Изначально вообще не было и речи никакой об виртуализации. Каждый сервер подбирался под решение своей задачи. Они и были настроены на решение этого базового функционала в отказоустойчивом варианте. Кроме этого, сервера все различны по вычислительной мощности. Так как подбирались под задачу, база данных (самый могучий хост об 8 ксеоновых ядрах), файловый сервер (сильно попроще) и шлюз (еще проще) в интернет. Плюс, некий запас на вырост.

Этот запас на вырост и позволил развернуть на самом производительном сервере несколько виртуалок, решающих свои частные задачи, почтовый сервер, астериск, WinXP для ночных регламентых работ... Самый простой вариант развернуть эти виртуалки - виртуалбох.

Так что всё росло вполне естественным путем. И что выросло, то выросло.
А с построением виртуальной кластерной инфрастуктуры пока для меня много вопросов. Например, есть кластерный дисковое хранилище на сервисе drbd. Особенность в том, что нет выделенных хостов под это хранилище, оно работает на этих же серверах. С primary девайса самба раздает файловую систему. Если этот узел умирает, то самба с drbd-девайсом возникает на резервном узле и имеет тот же самый IP-адрес. Да, это происходит с разрывом соединения (1С надо переиндексировать после переезда), но это работает и не 1С-ники вообще не замечают переезда файлового сервера. А как быть если самбу затянуть в виртуальную машину (которая будет мигрировать на резервный узел)? Точнее - самбу поднять-то недолго, а вот как она доберется до файловой системы drbd, которая на хосту, а не в виртуальном госте? Вопрос для меня открыт.

Gluster - хорошее решение, но имеет один маленький, но существенный для меня недостаток. Не хочет на этом томе работать 1С в файл-серверном варианте. А на drbd-томе - работает. Кроме этого и MS-Office последних версий более строго начал относться к блокировкам сетевым. И обламывается на открытии документов, если они размещены на гластерном томе. На drbd - проблем нет.

на гластерной ФС можно держать дисковые имиджи для виртуалок, которые для виртуалок являются вполне себе блочными устройствами

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

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

короче подхода тут может быть два:
1. оставить все как есть и надеяться что оно не подохнет
2. поднимать нормальный полноценный виртуальный ДЦ (который скорее всего не ограничится существующими виртуалками - аппетит приходит во время еды все таки)

dyasny написал:

на гластерной ФС можно держать дисковые имиджи для виртуалок, которые для виртуалок являются вполне себе блочными устройствами

Мы говорим об одном и том же? Gluster != glusterfs. Я пользуюсь именно glusterfs. А это реплицирующая надстройка над одной из стандартных файловых систем. При этом разработчик не поддерживает в полном объеме блокировки файловой системы. По крайней мере до версии 3.2.5. Отсюда - невозможность размещения на glusterfs и доступ к ним по cifs (самбе) файлов базы данных 1C v7.7, проблемы с офисными документами при работе с ними из MS-Office 2007 и старше (officeXP - тот на такое кладет). Я даже как-то поплясал на проблемах с MySQL. Вынес из виртуалки хранилище базы MySQL... Система начала колом становиться.
Именно поэтому для подобных приложений и нужна не надстройка над файловой системой, а "подложка" под неё. Ничего более умного, кроме DRBD мне в голову не пришло. Но... На таком томе работает то, что валится на glusterfs-томе.

И мой опыт работы мне подсказывает, что не всё ладно в glusterfs. Побаиваюсь я размещать на нем образы виртуальных систем. Были у меня сбои, когда эти многогигабайтные гластерные образы разваливались. Поэтому у меня подход простой - образы максимально неизменны (кроме логов), лежат на простых зеркальных дисках, а вся их переменная составляющая, базы данных, настройки и так далее, максимально вынесены во внешнее хранение. И доступ к ним или по тому же glusterfs или по cifs. Как то так. Плюс - отдельная резервная копия образа.

dyasny написал:

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

Это в саморощенной системе. Где отсутствует документация. Я же, хоть и ращу систему самостоятельно, но документацию стараюсь писать. Что, где стоит и как первоначально настроено - описано. Может не полностью, но основные моменты отражены.
А следующий админ - всегда будет делать что-то свое. Это особенность информатизации малого бизнеса, где нет понятия - "типовое решение". Это у крупняков - департаменты информатизации с обширным штатом админов, где каждый админ пасет свою корову. И каждому админу есть оперативная замена на предмет выхода его из строя. Там система от одного админа не зависит. А в малом бизнесе - хорошо если в фирме админ штатный. А может быть и мимо проходящий (я, кстати, такое принял). Там смена админа - всегда более или менее болезненное мероприятие. И уровень болезненности зависит только от квалификации нового админа.

dyasny написал:

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

А это проблема любой кластерной (или зеркалированной) файловой системы. Любой сбой - валиден и реплицируется автоматом. Здесь только бэкапы спасти могут. К тому же не совсем согласен с тезисом отвала железа и полного даунтайма всего. Есть HA-решения, как минимум - heartbeat. У меня выход из строя одного сервера совершенно не означает дайнтайма его сервисов. Они просто мигрируют на запасной узел. Ну будет мигрировать не самба с LDAP и dhcp, а набор виртуалок. Особенно если они на кластерной файловой системе расположены. Пока не вижу причины для даунтайма виртуалок. Более того - если образы виртуалок сохранены и растиражированы по узлам, то нет большой проблемы загрузить их вручную на любом из резервных серверов если нет HA-кластера под ними, не автоматизирована миграция. То есть именно виртуализация и спасает от полного даунтайма всего при выходе из строя железа. Пока родной сервер чинишь виртуалка поработает на соседнем сервере.

dyasny написал:

короче подхода тут может быть два:
1. оставить все как есть и надеяться что оно не подохнет
2. поднимать нормальный полноценный виртуальный ДЦ (который скорее всего не ограничится существующими виртуалками - аппетит приходит во время еды все таки)

Первый подход я реализовал уже. И он мне малоинтересен. Теперь я сильно думаю на предмет второго подхода виртуальные машины на HA-кластере. Но у меня для его полноценной реализации на технологии KVM не хватает одного сервера. Здесь, как я полагаю надо иметь пару серверов под НА-кластерное фалохранилище с самбой и пару мощных серверов под НА-вычислительный, собственно, кластер.

А у меня только три сервера. Один мощный, под виртуалки и пара простеньких. Вот и приходится изгаляться. Часть НА-сервисов живет на физических хостах, а часть - в своих виртуальных машинах.

"Cruiser78" написал:

А у меня только три сервера. Один мощный, под виртуалки и пара простеньких.

это не тянет на полноценный виртуальный ДЦ, и виртуалки в нем не смогут быть НА, потому что в случае падения единственного мощного хоста поднимать их окажется негде.

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

Есть такие решения на базе KVM - https://alteeve.com/w/2-Node_Red_Hat_KVM_Cluster_Tutorial но они сложны, и поддерживать их тоже не просто. а если система вдруг начинает расти, то очень быстро упирается в потолок. У одного клиента, который именно так начал, через полтора года оказалось около 180 4-ех нодовых кластеров, что вообще не управляемо.

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

dyasny написал:

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

Я по этой дороге и иду. Поднимаюсь с коленок. Но очень медленно. И кое что еще очень долго будет в наколенном варианте.
Кстати, о пользе чтения манов. У меня нет проблемы с блуждающим HA-алиасом. У меня на серверах по 2 физических интерфейса. И на одном, служебном, я поднимаю мост. А на интерфейсах, что доступны юзерям - виртуалка пойдет через macvtap. Всё решается элементарно.

macvtap - еще один костыль, а в надежной системе их не должно быть слишком много.

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

dyasny написал:

macvtap - еще один костыль, а в надежной системе их не должно быть слишком много.

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

1. Почему костыль? Если оно штатно в систему встроено? Значит уже и не костыль, вроде?
2. Меня останавливает от примениния RH следующее. Я подписываюсь у них на ознакомительные версии, беру триалы, изучаю... А в час Х, когда срок изучения заканчивается, что призойдет? "Прекращение техподдержки" и триальности - за этим термином может скрываться очень многое:
Вариант 1: Карета превращается в тыкву. То есть перестает работать без последующего ввода нужных лицензионных ключей. Думаю, что это маловероятно, но всё же...
Вариант 2: Карета медленно превращается в тыкву. Например, путем перекрытия триального доступа в репозитории RH. Хочешь получать обновления или ставить дополнительные программы из RH-репозитоиев - покупай техподдержку, ларчик откроется. Приятного тоже немного.
Вариант 3: Специалисты RH просто перестают отвечать на мои вопросы. То есть - разбирайся с системой самостоятельно. Но репозитории все открыты.
Вот что именно произойдет по прекращению триальности?

"Cruiser78" написал:

1. Почему костыль? Если оно штатно в систему встроено? Значит уже и не костыль, вроде?

macvtap толжен заменять собой tun/tap плюс стандартный бридж, но в qemu это не поддерживается, поэтому приходится использовать tap плюс macvtap. В классической схеме tap используется qemu нативно, и цепляется к нормальному бриджу.
кроме того macvtap лучше всего работает с vepa, а это требует поддерживающего vepa свитча, что во первых дорого, а во вторых не всегда целесообразно.
пока что macvtap имеет смысл только для ускорения связи между ВМ на одном бридже, что по моим наблюдениям никогда не было проблемой и в классической схеме. Короче технология хорошая, но свежая и сыроватая. Лучше подождать пока OVS попадет в мейнстримовые репозитории и пользоваться им.

"Cruiser78" написал:

2. Меня останавливает от примениния RH следующее. Я подписываюсь у них на ознакомительные версии, беру триалы, изучаю... А в час Х, когда срок изучения заканчивается, что призойдет? "Прекращение техподдержки" и триальности - за этим термином может скрываться очень многое:

по окончании триала, RHN account сбрасывается на минимальный, то есть доступ к апдейтам и саппорту пропадет. Сама система работать будет и дальше, это не ESXi где через месяц вмезапно включаются ограничения по функционалу и количеству ресурсов.
Более того, по окончании триала никто не будет требовать снести систему и перестать пользоваться ей, так что протянуть без апдейтов до получения бюджета не проблема.

Если хочется сидеть на неподдерживаемой системе, где стабильность не на первых местах но зато функционал всегда более продвинут, то можно просто взять oVirt, который к RHEV относится примерно как Fedora к RHEL, с примерно теми же подходами в плане поддержки настоящих боевых серверов

dyasny написал:

Более того, по окончании триала никто не будет требовать снести систему и перестать пользоваться ей, так что протянуть без апдейтов до получения бюджета не проблема.

Ну, это нормально. Ничто не мешает в триальный период неспешно утянуть к себе всё содержимое RH-репов. И в дальнейшем пользоваться долго этим зеркалом. А на виртуальные машины ставить то, что надо, CentOS, RF, Вынь... И обновлять их. Обновления важны для "серверов приложений". А сам хост-носитель - он должен быть прежде всего надежен, стабилен, отлит из бронзы. И для врагов он недоступен.

"Cruiser78" написал:

Обновления важны для "серверов приложений"

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

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