Возникновение базовой идеи

Причины для определенного рода озабоченности несовершенством сетевых настроек перечислены. Но путей решения указанных проблем множество. Например, можно проследить, как развивались (если не сказать – метались!) предложения разработчиков SUSE по настройке персистентных сетевых имен от версии дистрибутивов 9.х, где эта проблема возникла, до используемых сейчас 10.х. Аналогично и в отношении применяемого в упомянутом дистрибутиве сетевого экрана. Ведь неспроста в его названии использован индекс 2. Можно, например, пойти вообще радикальным путем, как это предлагается в ALT Linux, и использовать иную схему запуска сети [2]. Так что практика размножения сущностей и версий может продолжаться бесконечно. Для меня выбор способа, который, как кажется сейчас, может решить все проблемы разом, произошел почти историческим путем.

Несколько лет назад, как только код сетевого моста [3] был включен в очередной дистрибутив SUSE, мне показалось очень интересным использовать сетевой мост в качестве встроенного в сервер коммутатора, подключенного к локальной сети. Во-первых, это позволяло сократить объем дополнительного активного сетевого оборудования, использованного в формировании топологии сети, что было очень выгодным в маленьких офисах или при организации сетевых рабочих групп. И во-вторых, выделяло вакантные интерфейсы для горячей замены в случае отказа оборудования, что очень важно, если сервер обслуживается удаленно, поскольку переключить на запасной интерфейс и быстрей и дешевле, чем дожидаться приезда сисадмина, кроме того, что можно и сам сетевой интерфейс использовать как своего рода файловер. И теперь, по прошествии более 4 лет со  времени внедрения подобного способа разметки локальной сети, можно сказать, что эта технология была испытана многолетней практикой и ни разу не подвела.

Но сейчас появились дополнительные аргументы в пользу использования именно сетевых мостов в качестве основы виртуализации. Логика развития серверных систем неизбежно приводит к необходимости внутренней виртуализации ресурсов и компонентов. Причин этому очень много. Их рассмотрение заслуживает отдельной статьи. Как один из последних опубликованных аргументов приведу мнение Эндрю С. Таненбаума (Andrew S. Tanenbaum) о необходимости изоляции подсистем для увеличения надежности и безопасности [4]. Лучший способ добиться изоляции – поместить нужные подсистемы в отдельную виртуальную машину. К слову сказать, статья по ссылке [4] весьма спорная, о чем свидетельствует и сопутствовавшая ей сетевая дискуссия. Здесь предлагается принять на веру, что рано или поздно, но использование вложенных виртуальных машин внутри серверов станет нормой. Практически во всех видах подобной виртуализации ресурсов внутренний, или зависимый, уровень получает непосредственный доступ к сети путем присоединения к виртуальному сетевому мосту (bridge) [5, 6], если исключить всякого рода роутинг. Поэтому будем считать абсолютно обоснованным создание сетевого окружения, приспособленного для подключения виртуальных систем, заранее в расчете на развитие.

Технология изнутри

Итак, выбор сделан – сетевой мост. Статей, описывающих настройку сетевых мостов в Linux и сопутствующие этому вопросы, огромное число, например [7]. Не буду дублировать очевидное. Обращаю ваше внимание лишь на самое важное в контексте предлагаемой идеи. Сам сетевой мост является полностью виртуальным устройством. Реальный трафик принимается только физическими сетевыми устройствами. Чтобы трафик попал на сетевой мост с некоторого физического устройства или, напротив, с сетевого моста поступил в реальный интерфейс, нужное сетевое устройство должно быть подключено к мосту командой:

brctl addif <bridge> <iface>

Иначе трафик не будет проходить. Здесь внимательный читатель уже должен все понять – таким путем реализуется внутренняя коммутация. Это основная идея. То есть изначально сетевой мост предназначен для объединения нескольких реальных сетевых интерфейсов в общий коммутатор. Но ничего не мешает использовать выделенные сетевые мосты для каждого реального интерфейса. Собственно, как и наоборот – для каждого (внимание: здесь еще одно усложнение) реального, но виртуализованного путем назначения на выделенный специальный сетевой мост использовать один или несколько аппаратных сетевых интерфейсов из массива имеющихся в составе оборудования сервера. И вот эту привязку можно производить динамически. Все сказанное иллюстрируется схемой (см. рис. 1).

Рисунок 1. Сравнение традиционного способа настройки с виртуализованным интерфейсом

В левой части традиционная схема подключения, далее – то же самое, но с сетевым мостом, а в правой – новая. Согласно схеме (рис. 1, правая часть) сетевой мост переименовывается, также как и заменяемый интерфейс, а имя физической сетевой карты заменяется на служебное название. Причем все сетевые настройки выполняются вне зависимости от текущего состояния коммутации между ними. Сама же коммутация из стадии настройки переводится в категорию состояния комплексного сетевого соединения, включающего сетевой мост и предназначенные к подключению физические сетевые интерфейсы.

Если сетевая карта вышла из строя, то подключается предназначенная на замену. Если в «джек» сетевой карты вставлен «плуг» другого кабеля, то она подключается на правильный виртуальный интерфейс согласно произведенной кабельной коммутации после проверки трафика на данном кабельном подключении. Если нужно отключить сервер временно от некоторой сети, то можно не вынимать кабель из сетевой карты, не останавливать сетевые сервисы, не запирать firewall, а просто отсоединить физический интерфейс от используемого моста. Но на этом преимущества не кончаются. Все почти так же, как и с вытянутым носом киплинговского слоненка.