Система управления сетевыми сервисами

20.04.2009

Опубликовано: Вестник Новосибирского государственного университета, серия Информационные технологии, т.7, вып. 2., 2009 г.

В. Е. Тютюньков

Система управления сетевыми сервисами и их распределения

Введение

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

На основании этого, проведены следующие исследования:

выявлены основные принципы и задачи построения информационной системы по управлению локальной сетью;
произведен поиск и анализ существующих решений по автоматизации как работы с клиентами, так и администрирования сети;
на основании этого анализа разработаны пути решения полученных задач (п. 1);
реализована оригинальная система (с рабочим названием «NetHouse») управления услугами по предоставлению доступа к локальной сети, а также автоматизации администрирования сетевого оборудования на основании данных этих слуг.

Задачи

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

Условия предоставления услуг, в частности доступа к сети, могут зависеть от характера взаимоотношений клиента с организацией. Для некоторых организаций эти взаимоотношения часто меняются и очень важно отслеживать все изменения.
Идеальный с точки зрения управления, вариант построений сети — это обеспечение однозначного соответствия «порт коммутатора – клиентский компьютер». Но не всегда у провайдера имеется возможность такое соответствие обеспечить. В этом случае может потребоваться более тонкая настройка сетевого оборудования.
Оборудование, на основе которого построена локальная сеть, может различается как по функциональности, так и по интерфейсу взаимодействия (администрирования) с ним. На данный момент отсутствуют универсальные системы централизованного управления: каждый из производителей сетевого оборудования предоставляет системы управления и настройки только для производимых им самим устройств, в частности, используя специальные внутренние протоколы. Примерами таких системы могут служить «AlliedWare®Operating System» – программная система компании Allied Telesis, управляющая коммутаторами Allied Telesis или «CiscoWorks LAN Management Solution» от компании Cisco.
В некоторых сетях, например, построенных в студенческих общежитиях, очень распространена смена характеристик договора с пользователем, а также характеристик оборудования на стороне клиента (характеристика сетевой карты – MAC-адрес). Для корректной работы такой сети необходимо учитывать историю всех изменений, а также, в определенных случаях, производить дополнительные настройки.
Естественно, не все необходимые ресурсы и сервисы могут быть предоставлены локальной сетью – часть таких ресурсов доступна только в глобальной сети Интернет. Доступ к внешней сети является отдельной услугой (VPN), управляемой биллинговой системой. Необходима возможность интеграции управления этой системой (предоставление и / или сбор данных).

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

одни слишком громоздки и предоставляют абсолютно ненужную функциональность, в то же время не обеспечивая выполнение всех требований. Для существенно более крупных провайдеров, занимающихся не только обычными Ethernet-сетями, но также и Dial-up, ADSL и т. п. услугами, использование таких систем оправдано. Более того, эти системы предназначены именно для таких компаний;
другие являются внутренними разработками небольших отдельных компаний-провайдеров, занимающихся построением локальных сетей. В большинстве случаев информация об используемых системах не распространяется, так как это внутренние разработки провайдеров и у каждого из них есть свои особенности построения сети и управления оборудованием.

Решение

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

Программное решение поставленной задачи реализовано как дополнение к Университетской информационной системе. Университетская информационная система (УИС) [Адаманский и др., 2006] - обширный проект, разрабатываемый в течение 4 лет в Центре новых информационных технологий Новосибирского государственного университета (ЦНИТ НГУ). Система осуществляет автоматизацию внутренних процессов учебного заведения, а также отвечает за ведение электронного документооборота.

Предлагаемая в качестве решения система состоит из следующих основных компонентов (рис. 1):

Service – подсистема работы с пользователями: обеспечивает управление контрактами и услугами пользователей, как ручное, так и автоматическое;
Hardware – подсистема настройки оборудования: занимается такими задачами, как настройка коммутаторов, получение текущих настроек и их отображение, предоставление возможности ручного управления.

Помимо перечисленных выше подсистем, в системе присутствуют и менее обособленные компоненты:

Search – подсистема поиска информации: объединяет данные первых двух подсистем и позволяет осуществлять поиск по этим данным;
Report – подсистема отчетов: является неотъемлемой частью любой системы автоматизации и поддержки.

Рис. 1: Структура системы

Рассмотрим более подробно перечисленные подсистемы.

Подсистема управления пользователями

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

влияние на конфигурацию оборудования. Естественно, услуги по предоставлению доступа к локальной сети непосредственно связаны с настройкой коммутаторов, но также есть услуги, которые явно не влияют на настройки сетевого оборудования;
периодичность. Большинство услуг – разовые, т. е. работы по ним производятся единожды (например, прокладка кабеля), но также есть и периодические услуги: такие, которые предоставляются на определенный срок, по истечению которого услуга вновь может быть востребована (например, пользование сетью);
наличие дополнительных работ. Такие услуги, как «Прокладка кабеля», «Обжим коннектора» должны порождать некоторый подотчетный документ, тесно связанный с самой услугой – наряд на работу. Соответственно, необходима возможность управления этими документами.

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

Модель услуг представлена на рис. 2:

Рис. 2: Модель услуги

Рис. 2: Модель услуги

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

Рис. 3: Подключение ЛС

Рис. 4: Пользование сетью

В рис. 3, 4 представлены статусы и переходы между ними для услуг «Подключение ЛС» и «Пользование сетью»:

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

Рассмотрим более детально статусы услуг. На рис. 3 представлены статусы и переходы между ними для услуги «Подключение ЛС».

«Выдан IP». При переводе услуги в этот статус пользователю выдается IP-адрес из списка свободных адресов.
«Получен MAC». Этот статус услуги служит для получения от клиента характеристики его компьютера – MAC-адрес.
«Завершена». Переход услуги в этот статус завершает процесс подключения пользователя к локальной сети: услуга становится активной и на основании данных, сохраненных при предыдущих переходах, клиенту будет предоставляться доступ.

Более сложная система статусов и переходов представлена на рис. 4 – услуга «Пользование сетью»:

«Пауза». Статус услуги, при котором доступ к локальной сети не предоставляется, но в случае положительного баланса на счету клиента услуга автоматически переключится в другой статус («Вкл»).
«Вкл». При переходе в этот статус производятся настройки сетевого оборудования для включения пользователю доступа к сети. Если в этом статусе услуги баланс счета становится отрицательным, услуга автоматически переходит в статус «Пауза».
«Откл». Статус аналогичный статусу «Пауза», но без возможности автоматического включения услуги (используется, например, для прекращения доступа к сети пользователям, нарушившим правила пользования).
«Времено вкл». Аналогичен статусу «Вкл», но без автоматического выключения.

Рис. 5: Зависимости статусов услуг

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

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

Рассмотрим более детально инструкции, выполняемые при переходе услуги из одного статуса в другой:








<!-- предоставляет доступ к управлению конкретным договором с пользователем -->
<net-contract id="<идентификатор договора>">
  <!-- управляет связанным с контрактом адресом -->
  <net-address>
    <!-- добавляет на порт коммутатора новый MAC-адрес -->
    <switchboard-port _addStaticMac="<MAC-адрес>"/>
  </net-address>
  <!-- изменяем параметры услуги: -->
  <!-- устанавливаем флаг состояния во «вкл» и включаем обработку тарифа по этой услуге -->
  <service  id="<идентификатор услуги>"
              state="вкл"
              tariffActive="вкл"/>
</net-contract>

Пример 1. Инструкции услуги «Дополнительный IP-адрес», статус «Активна».


<-- предоставляет доступ к управлению конкретным договором с пользователем -->
<net-contract id="<идентификатор договора>">
  <!-- изменяем параметры услуги: -->
  <!-- 1. устанавливаем флаг состояния в «выкл» -->
  <!-- 2. выключаем обработку тарифа по этой услуге -->
  <!-- 3. не производим обработку тарифа в момент применения статуса -->
  <service  id="<идентификатор услуги>"
              state="выкл"
              tariffActive="выкл"
              _tariffApply="нет">
    <!-- создаем наряд, связанный с услугой -->
    <assignment  actor="<исполнитель>"
                       open="да"
                       successful="нет"
                       template="<шаблон печатной формы>"/>
  </service>
</net-contract>

Пример 2. Инструкции услуги «Вызов», статус «Подготовлена».

В этих примерах представлены инструкции двух услуг, относящихся к разным классам: в примере 1 происходит манипуляция списком статических mac-адресов, а в примере 2 не выполняется никаких настроек оборудования, но вместо этого создается подотчетный документ – наряд на выполнение определенной работы. Использование инструкций позволяет сделать систему услуг фактически независимой от управляемых объектов – достаточно реализовать необходимые обработчики инструкций и мы получим возможность управление не только сетевым, но и любым другие оборудованием. Как видно из примеров, в конфигурации услуги задаются не конкретные инструкции для применения, а их шаблон, который предварительно обрабатывается специальной утилитой, что позволяет производить тонкую настройку выполняемых действий.

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

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

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

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

На рис. 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 дерева конфигурации того или иного параметра;
на основании этих правил производится чтение текущего состояния, и, соответственно, после этого составляется список изменений в конфигурации оборудования и применяется.

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

Заключение

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

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

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

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

Список литературы

Адаманский А.В. Архитектура контейнера программных компонент Jaxion. // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2005. Т. 2, вып. 1., с. 88-91.
Адаманский А.В., Денисов А.Л., Кочеев А.А. Опыт автоматизации вуза. Система
УИС // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2006. Т. 4, вып. 1., с. 2-6.

Статьи

Softmotions