SDN-контроллер
Протоколы TRILL и SPB, рассмотренные в предыдущих публикациях, представляют собой ОДИН ИЗ путей решения проблемы масштабирования сетей с топологией Spanning Tree.
Другой путь – использование технологии программно-конфигурируемых сетей SDN (Software-Defined Networking). Это подход получил гораздо большее распространение, чем TRILL и SPB.
Основная идея SDN состоит в замене механизма «форвардинга» пакетов в каждом коммутаторе на управление от централизованного контроллера, который программируется пользователем относительно того, как выдавать инструкции на передачу («форвардинг») пакетов в каждом коммутаторе. Как и в TRILL/SPB, такой подход позволяет сосуществовать как основному маршруту форвардинга, так и резервному. Контроллер может быть как отдельным узлом, так и распределённым набором узлов.
При запуске, и затем периодически при работе, контроллер опрашивает коммутаторы сети, чтобы определить их состояние, а также внутренние параметры. Затем, на основе этой информации, контроллер строит соответствующее дерево Spanning Tree. После этого, коммутаторы будут передавать пакеты только по линкам, определённым в конфигурации сети от контроллера. Звенья, которые не являются частью созданного дерева Spanning Tree также можно использовать для передачи пакетов по известным направлениям, как и в традиционных коммутаторах, с алгоритмом Spanning Tree. Если на коммутатор приходит пакет с неизвестным адресом назначения, то коммутатор сообщает об этом контроллеру, который затем решает, что делать дальше.
Коммутаторы часто конфигурируются так, чтобы сообщать новые адреса источников контроллеру, поэтому контроллер может сообщить всем другим коммутаторам наилучший маршрут трафика от этого нового источника.
SDN-контроллер может быть сконфигурирован как обычный файрволл, не разрешающий передачу между определёнными парами узлов по соображениям безопасности. Например, если в дата центре есть клиент А и клиент В, и у каждого несколько подключённых к дата-центру узлов, то сеть можно программно сконфигурировать так, что ни один пакет с узла клиента А не попадёт через дата-центр ни на один узел клиента В, и наоборот.
Реализация SDN-контроллера чаще всего делается с использованием стандартных программных модулей. Однако, ПО для контроллера можно создавать и под какую-то конкретную сеть, чтобы достигнуть очень точного управления её функционалом.
Реализация OpenFlow
Основа технологии SDN – это способность контроллера сообщать коммутаторам информацию о том, как форвардить пакеты.
Рассмотрим архитектуру коммутатора с протоколом OpenFlow, который является стандартом SDN, созданным организацией ONF (Open Networking Foundation), основанной разработчиками технологии SDN.
Форвардинг в OpenFlow делается по одной или нескольким таблицам потока (flow table). Во flow-table содержатся т.н. «поля соответствия» (match field), а также набор инструкций, выдаваемых по получению тех или иных пакетов, и действий в случае установки соответствия в match field.
Обычно это такие действия:
- Сброс пакета
- Форвардинг пакета на один определённый интерфейс
- Рассылка (flooding) пакета на набор интерфейсов
- Форвардинг пакета на контроллер
- Обработка пакета на другой (с более высоким номером) таблице Flow Table.
Соответствие (Matching) может быть найдено, например, когда IP-адрес источника в пакете соответствует значению IP-адреса назначения в таблице. В этом случае, форвардинг может быть сделан полностью или частично по IP-адресу, а не по Ethernet-адресу. Таким образом, коммутатор OpenFlow может действовать как коммутатор уровня L3, то есть, почти как IP-маршрутизатор.
Таблицы Flow Table немного похожи на таблицы передачи пакетов в коммутаторе (forwarding tables), в которых тоже прописаны соответствия между адресами источника и назначения, и то, какие действия нужно предпринимать в случае установления соответствия при передаче пакета на следующей маршрутизатор.
Обычно, коммутаторы OpenFlow обрабатывают пакеты рассылки, пердавая их (forwarding) на определённые выходные интерфейсы или группы интерфейсов (flooding).
При помощи контроллера SDN, можно установить на определённые выходные интерфейсы атрибут NO_FLOOD, что означает, что те пакеты для рассылки (flooding или broadcast, или что ещё) не будут восприниматься этими интерфейсами. Примерно так организуются сети Spanning Tree.
При рассылке типа broadcast (на все интерфейсы, кроме входного), в отличие от flooding (на некоторые интерфейсы), обращение к таблице Flow Table не требуется.
При назначении соответствий (Match field) может назначаться также величина приоритета. В случае соответствия пакета двум и более полям Flow Table, выбирается поле с наивысшим приоритетом.
Команды OpenFlow для Flow Table также могут включать модификацию (“mangling”) пакетов.
Кроме того, во Flow Table могут быть счётчики, флаги, а также значение времени последнего использования поля (last_used).
Также коммутатор OpenFlow может вводить ограничения на качество услуг Quality-of-Service, например, ограничение полосы пропускания (bandwidth).
Логический коммутатор OpenFlow
Логический коммутатор OpenFlow (OpenFlow Logical Switch, т.е., встроенное в коммутатор программное обеспечение, после чего он становится коммутатором OpenFlow) состоит из таблиц потоков (Flow Table) и таблиц группировки (Group Table), которые производят просмотр соответствий и форвардинг на основе этих соответствий.
Коммутатор обменивается сообщениями с SDN-контроллером, который управляет коммутатором через протокол OpenFlow. При помощи протокола OpenFlow, контроллер может добавлять, модифицировать, и удалять записи в таблицах потока и группировки, как в реактивном режиме (в ответ на пришедшие пакеты), так и проактивно.
Каждая таблица в коммутаторе содержит набор записей по управлению потоками (Flow), каждая из которых состоит из полей соответствия (match fields), счётчиков, а также набор инструкций для того, как поступать с пакетами, у которых есть соответствия. Просмотр соответствий начинается с первой таблицы потока в магистрали потока (Pipeline), и затем продолжается на последующих. Найденные соответствия имеют приоритет в зависимости от положения таблицы в магистрали. Используется первое найденное соответствие. При этом выполняются команды, ассоциированные с данной записью в таблице потока. Если соответствий не найдено, то выполняются команды записи таблицы для отсутствия потока (miss flow). При этом, пакет может быть направлен на контроллер канала OpenFlow, сброшен, или направлен в следующую таблицу потока.
Команды, связанные с каждой записью в таблице потока, либо предписывают какие-то действия с пакетом, либо модифицируют обработку в магистрали потока. Действия могут относится к способу форвардинга пакета, модификации пакета или внесение изменений в таблицу группировки.
Команды обработки в магистрали потока (Pipeline) дают возможность посылать пакеты на следующую таблицу в магистрали, и позволяет обмен информации в форме метаданных между таблицами магистрали.
Обработка пакета в магистрали останавливается, когда команда, ассоциированная с записью в таблице потока, не определяет следующую таблицу. В этот момент, пакет обычно модифицируется и пересылается коммутатором на выходной порт (как это делалось бы и без OpenFlow).
Записи в таблице потока могут сами делать форвардинг пакет на физический порт коммутатора. Однако, это может быть и логический порт, определённый в коммутаторе, а также резервный порт, определённый в SDN.
Резервные порты могут предписывать основные действия форвардинга, такие, как посылка на контроллер, рассылка по набору выходных портов (flooding), а также форвардинг без использования методов OpenFlow, т.е. методами обработки в обычном коммутаторе.
Логические порты, сконфигурированные в коммутаторе, могут определять группы агрегации линков, туннели или интерфейсы петель (loopback interfaces).
Действия, ассоциированные с записями в таблицах flow table, могут также направлять пакеты в группы, которые сконфигурированы для дополнительной обработки. Группа представляет собой набор действий по рассылке flooding, а также более сложную семантику, например, многомаршрутность (multipath), быструю перемаршрутизацию (fast reroute), а также агрегацию линков.
Представляя собой общий уровень абстрагирования, таблицы групп могут использовать много записей в таблицах Flow Table для форвардинга одиночного идентификатора (например, форвардинга IP-адреса на общий интерфейс next hop).
Таблицы группировки Group Table содержат записи групп (group entries), каждая запись групповой таблицы содержит список наборов действий (action bucket) с определённой семантикой, зависящей от типа группы. Действия в одном или нескольких наборов action bucket применяются к пакетам, посылаемым в группу.
Сетевой контроллер СКУД: устройство и назначение
Сетевые контроллеры СКУД используются при автоматизации систем доступа в гостиницах, проходных предприятий. Их можно подключить к сети для удаленного программирования или получения событий по проходу сотрудников в здание. Сетевые контроллеры применяются для учета отработанного времени, интегрируются с компьютерными программами.
Как устроен сетевой контроллер СКУД
Это электронная плата может поставляться в корпусе или без него. В последнем случае компактное устройство прячется в монтажной коробке, отсеке замка, элементе турникета и так далее. К сетевому контроллеру подключается считыватель карт Em-Marine или иного стандарта, кодовые панели, замки и кнопки выхода. При необходимости устройства можно объединять в единую сеть. Примерная схема выглядит следующим образом.
Как устроен сетевой контроллер СКУД
В качестве сетевого протокола может использоваться:
- Шина RS-485. Для подключению к компьютеру через USB потребуется специальный адаптер.
- Ethernet. Соединение выполняется витой парой. Подключение к компьютеру выполняется напрямую через сетевую карту.
- Wi-Fi для беспроводного управления сетевым контроллером СКУД.
Некоторые IP сетевые контроллеры СКУД можно подключить к интернету. В этом случае управлять ими можно будет через смартфон или компьютер в любой точке мира.
- Загружать базу ключей в память устройства,
- Управлять настройками и режимами работы,
- Получать из памяти события прохода через турникет или дверь для учета рабочего времени и регистрации прихода сотрудника на работу.
Примеры использования сетевых контроллеров СКУД
- Автоматизация дверей номеров в гостинице. Администратор со своего рабочего места может прописать новый ключ гостя в память замка или аннулировать его.
- Турникет в проходной предприятия. При прохождении сотрудник предъявляет карту. В памяти устройства фиксируется номер ключа и время прохода. Затем оно передается в компьютерную программу для учета.
- Автоматизация ворот или шлагбаумов, установленных на въезде на охраняемую территорию. Сотрудник охраны может записать новый ключ или прекратить его действие, не покидая пост.
Купить в Москве сетевые контроллеры Ironlogic, ЭРА, ACS и других производителей можно в интернет магазине Техническая лаборатория.