Команда дизайн-центра электроники Promwad возвращается на Хабр после зимних каникул с новыми статьями о разработке встроенного ПО и новых устройств для серийного производства. Сегодня мы поделимся своим опытом в теме сетевых технологий.
Среднестатистическая домашняя сеть, также как и сеть небольшого предприятия, — это уже давно не просто два–три компьютера, соединенные через первый попавшийся китайский коммутатор. Вместе с ростом объема контента (базы данных, потоковое аудио/видео и т.д.) и увеличением количества устройств (VoIP-устройства, серверы, NAS-ы, IP-камеры, а в домашних сетях — телевизоры и прочий «интернет вещей») растет и количество передаваемых данных через сетевую инфраструктуру. Потоки данных нужно разделять между собой, при этом не забывая о приоритезации трафика: например, VoIP-трафик желательно пускать с большим приоритетом, чем IPTV, а IPTV в свою очередь — чем торренты. Поэтому не удивительно, что со временем даже малые локальные сети усложняются, а емкости портов одиночных коммутаторов становится недостаточно…
Для увеличения емкости портов крупных узлов сети, а также для увеличения общей пропускной способности сети, чаще всего прибегают к построению т.н. стеков — объединению коммутаторов в иерархические структуры в зависимости от потоков передаваемых данных.
Самой «классической» архитектурой построения сетей является дерево, как показано на рисунке:
При этом трафик от узла A к узлу D проходит через цепочку вышестоящих коммутаторов, что накладывает дополнительные требования к производительности — пропускная способность каждого следующего (вышестоящего) узла дерева должна быть выше предыдущего.
Для того чтобы разгрузить основные узлы сети чаще всего вводят дополнительные связи между коммутаторами. Например, «ядро» сети часто организуют в виде кольца коммутаторов, как показано на схеме ниже:
Если при этом используется старый добрый Ethernet, то во избежание переполнения кольца широковещательным трафиком используют Spanning Tree Protocol, который переводит один из линков между коммутаторами кольца в неактивное состояние. Это позволяет обеспечить альтернативный путь прохождения трафика в случае обрыва центрального кольца в какой-либо из точек. Если же используется какой-либо из протоколов специально предназначенных для «колец», например FDDI или Token Ring, то кольцо не разрывается, а трафик передается по кольцу с наиболее равномерной загрузкой входящих в кольцо коммутаторов.
Ну и конечно же, никто не запрещает при необходимости комбинировать различные топологии в рамках одной сети, вплоть до использования множественно пересекающихся колец, каждый из узлов которого является вершиной дерева.
При построении сети появляется необходимость не просто соединить пассивные узлы-коммутаторы, но и обеспечить передачу данных между узлами с учетом приоритета и разделения разных видов трафика. При этом желательно сохранить возможность централизованного управления сетью из одной точки для задания этих приоритетов. Появляется необходимость объединить все оборудование сети в некую логическую сущность.
Технология Distributed Switch Architecture предоставляет такую возможность, позволяя управлять разветвленной сетью как единым устройством, а также задавать пути прохождения трафика всей системы в целом. При этом узлы-коммутаторы могут представлять из себя простые одночиповые устройства с одним общим для всех узлов управляющим процессором, что положительно сказывается на стоимости системы и затратах на ее обслуживание.
Суть технологии DSA можно кратко свести к введению дополнительного уровня адресации в рамках узлов всей сети, а фактически — в рамках всей емкости портов всех узлов. В качестве примера этой технологии рассмотрим реализацию Distributed Switch Architecture от одного из производителей свитч-микросхем — Marvell. Существует множество реализаций подобной технологии от различных вендоров (при этом разные производители называют эту технологию по-разному), но суть этих решений схожа.
Для успешной работы этой технологии каждому узлу-коммутатору присваивается уникальный Device ID, а каждому порту отдельно взятого устройства — Port ID. Каждый пакет, входящий в любой внешний порт любого узла сети, который невозможно обработать в пределах этого узла (т.е. на основании локальных таблиц и правил), дополняется 4-мя байтами: DSA-тегом. Для обычного трафика в устройствах Marvell используется тег Forward DSA. В этот тег помещается Device ID и Port ID, однозначно определяющие, где именно в пределах сети пакет попал в сеть. Сам же тег помещается сразу за Source Address в MAC-заголовке.
Реализация DSA от Marvell поддерживает 802.1Q — при наличии в пакете VLAN-заголовка его VID и приоритет переносятся в DSA-заголовок, при этом сам VLAN-заголовок из пакета убирается, т. е. размер пакета сохраняется неизменным. Специальный флаг в новом заголовке показывает, что исходный пакет был тегирован, что позволяет восстанавливать VLAN-заголовок на выходе из внешнего порта при необходимости. При переносе приоритета пакета можно воспользоваться специальной таблицей замены, поэтому распределение пакетов по очередям можно задать произвольно.
Поскольку при наличии адресации узлов можно обращаться к каждому из них отдельно, для всей сети коммутаторов можно использовать один общий управляющий CPU, соединенный физически только с одним из узлов. CPU подключается к одному из портов коммутатора, а для обмена с учетом дополнительной адресации используется либо упомянутый выше DSA-заголовок, либо расширенный на 4 байта вариант заголовка — Ethertype DSA, в котором дополнительно включено значение ethertype. Этот ethertype выбирается администратором и задается в конфигурации коммутатора, а также в модуле ядра на управляющем CPU. Использование Ethertype DSA позволяет одновременно передавать через порт как трафик с DSA-тегом, так и обычный сетевой трафик.
Централизованное управление — это одно из важнейших условий при построении сложной сети передачи данных. Реализация DSA от Marvell решает эту задачу с помощью специальных пакетов — Management frames, которые используются с двумя типами DSA-тегов: From_CPU и To_CPU. Как можно понять из названия, первый тип используется для передачи пакетов от CPU к управляемому узлу, а второй тип — от узла к управляющему CPU. Их основное отличие в том, что в теге From_DSA указывается Target Device ID и Target Port ID устройства, а в теге To_DSA — Source Device ID и Source Port ID. Дело в том, что каждый коммутатор в сети знает, к какому порту (прямо или через другие узлы) подключен управляющий CPU, а значит, достаточно только адресовать управляемое устройство.
Среди дополнительных возможностей реализации DSA от Marvell также можно отметить мульти-чиповый мониторинг трафика: трафик любого порта любого узла сети можно продублировать на любой другой порт, включая порт управляющего CPU. При этом можно осуществлять мониторинг любого количества портов, а чтобы обозначить источник используется DSA-тег типа To_Sniffer, в который записывается Source Device ID, Source Port ID и номер VLAN пришедшего пакета.
Начиная с версии 2.6.28 mainline ядра Linux поддерживает использование Distributed Switch Architecture на сетевых интерфейсах. Изначально поддерживались только некоторое модели свитчей от Marvell, но затем добавилась также поддержка чипов Broadcom. Также существует патч для поддержки свитчей от Micrel. Поддержка заключается в дополнительной прослойке в сетевом стеке, которая добавляет в пакет, либо убирает из него DSA-заголовок, отправляя данные в виртуальный сетевой интерфейс в зависимости от данных заголовка. Таким образом, с точки зрения операционной системы, каждый внешний порт всех свитчей DSA-сети (кроме DSA-портов, которыми свитчи соединены между собой) «виден» как отдельный сетевой интерфейс. В случае наличия поддержки со стороны оборудования, такому интерфейсу можно назначить собственный MAC- и IP-адрес, а значит с помощью DSA также можно построить и маршрутизатор с большой емкостью портов.
Стоит отметить, что реализации DSA от разных вендоров не совместимы между собой, а также обладают различным функционалом. Так, например, Micrel KSZ8993M может дополнительно адресовать только номер порта одного устройства, непосредственно подключенного к управляющему CPU. Поэтому в случае использования сети с использованием описанной технологии придется выбрать какого-либо одного производителя чипов.
Рассмотрим пример описания DSA в конфигурации Device Tree для ядра 3.10 или выше:
dsa@0 {
compatible = "marvell,dsa";
#address-cells = <2>;
#size-cells = <0>;
interrupts = <10>;
dsa,ethernet = <ðernet0>;
dsa,mii-bus = <&mii_bus0>;
switch@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <16 0>; /* MDIO address 16, switch 0 in tree */
port@2 {
reg = <2>;
label = "lan2";
};
port@4 {
reg = <4>;
label = "lan4";
};
port@5 {
reg = <5>;
label = "cpu";
};
switch0uplink: port@6 {
reg = <6>;
label = "dsa";
link = <&switch1uplink>;
};
};
switch@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <17 1>; /* MDIO address 17, switch 1 in tree */
port@1 {
reg = <1>;
label = "lan1";
};
port@3 {
reg = <3>;
label = "lan3";
};
switch1uplink: port@5 {
reg = <5>;
label = "dsa";
link = <&switch0uplink>;
};
};
В данном случае описывается архитектура из двух коммутаторов, которую можно представить так:
Поскольку в двух коммутаторах определено по 2 внешних порта, с такой конфигурацией в операционной системе будет дополнительно создано 4 виртуальных сетевых интерфейса, представляющих из себя порты, в которые включены компьютеры A, B, C и D, каждый из которых можно использовать независимо. В таком случае по умолчанию для каждого порта каждого коммутатора будет выделена отдельная независимая MAC-таблица.
При этом конфигурация каждого отдельного коммутатора может производиться как локально по шине MDIO (например, если все оборудование расположено в пределах одного юнита, или чипы расположены на одной печатной плате), так и с помощью специальных конфигурационных пакетов по Ethernet-сети. Благодаря этому можно построить как коммутатор с большой емкостью портов, так и сложную сеть коммутаторов с централизованным управлением.
Стоит отметить что текущая реализация DSA в ядре поддерживает конфигурацию коммутаторов только через шину MDIO, что несколько сужает рамки использования технологии. Однако при необходимости добавление удаленного управления не составит труда.
На этом теоретическую часть описания Distributed Switch Architecture можно считать оконченной, в следующий раз попробуем разобраться с применением этой технологии на практике. Так что если сетевые технологии и разработка электроники — ваша тема, присоединяйтесь к нашим подписчикам на Хабре.
Автор: Promwad
