Подсистема работы с сетевым оборудованием

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

· неуправляемые коммутаторы настраивать невозможно, в силу их свойств;

· управляемое сетевое оборудование, расположенное выше по топологии, настраивается администратором единожды – при построении сети, и нет необходимости его перенастраивать.

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

На рис. 6 изображена основная часть модели сетевого оборудования.

· «Коммутатор» – хранит информацию и основные настройки для управляемого коммутатора.

· «Порт коммутатора» – для каждого коммутатора имеется конкретный набор портов; является единицей управления.

· «Услуга» – услуга(-и), влияющая на настройки порта.

· «Адрес» – обслуживаемый портом адрес(-а).

Рис. 6: Модель сети

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

Представленная выше модель хранит все необходимые настройки коммутаторов, остается самая главная задача: отобразить состояние модели в конфигурацию реального оборудования (включить / выключить порты, добавить / удалить MAC-адреса в список статических MAC-адресов порта и т. п.). Вся трудность этой задачи в том, что оборудование даже одного и того же производителя может существенно отличаться в интерфейсе настройки, не говоря уже об устройствах различных производителей. Для примера можно взять два коммутатора Allied Telesyn: AT-8000S и AT-8326GB. Они оба настраиваются через протокол telnet, но если более новый AT-8000S управляется через интерфейс командной строки, то AT-8326GB использует псевдографический интерфейс, что затрудняет автоматическую настройку.

Для коммутаторов одного производителя задача не так сложна – практически каждый производитель сетевого оборудования выпускает для своего (и только для своего) оборудования также и программные решения, позволяющие ими управлять. Но в случае наличия устройств различных фирм-производителей из-за различия программного API этих решений, задача централизованного управления различным оборудованием становится довольно трудоемкой.

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

· на основании имеющихся данных система подготавливает набор определенных инструкций в виде текстового файла;

· администратор, используя заранее подготовленные скрипты, модифицирует полученные инструкции в соответствии с индивидуальными особенностями коммутатора;

· на основании модифицированных инструкций производится загрузка конфигурации оборудования.

При данном подходе настройка производится в полуавтоматическом режиме, поэтому получение системой информации о произведенных действиях затруднительно. Более того, сама по себе информация о текущих настройках оборудования не может быть получена, при использовании данного подхода. А эта информация очень важна как для администраторов, так для самой системы: при отсутствии актуальных данных о состоянии коммутаторов и их портов невозможно произвести корректные настройки (в этом случае на время обновления конфигурации будет приостанавливаться доступ к сети у всех клиентов).

В результате более детального изучения способов администрирования сетевого оборудования было выяснено, что стандартный протокол управления сетевыми устройствами, в различной степени поддерживаемый всеми производителями – SNMP (Simple Network Management Protocol⁶) – позволяет решить задачу как отображения состояния модели сети на сетевое оборудование, так и получения актуальной информации о состоянии и настройках этого оборудования:

· каждому коммутатору администратором сопоставляется набор SNMP правил, в частности, идентификаторы ветви SNMP дерева конфигурации того или иного параметра;

· на основании этих правил производится чтение текущего состояния, и, соответственно, после этого составляется список изменений в конфигурации оборудования и применяется.

Данное решение используется в подсистеме работы с сетевым оборудованием для взаимодействия с коммутаторами.

Заключение

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

На основании этих исследований были составлены требования к разработке оригинальной системы, а так же рассмотрены различные аспекты как работы с клиентами, так и администрирования сетевого оборудования. В результате разработан программный комплекс по управлению локальной сетью. Описанное программное решение успешно внедрено и на данных момент используется для управления локальной сетью НГУ.

Так же, можно выделить основные направления дальнейшего исследования и разработки:

· исследование использующейся на данный момент биллинговой системы, интеграция с ней;

· увеличение спектра предоставляемых услуг;

· более строгая настройка зависимостей между услугами;

Поиск по сайту: