Разработка системы мониторинга сети для внутренних нужд предприятия ОАО «Хабаровскэнерго»

Введение

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

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

Существуют специальные стандарты моделей управления сетями, что позволяет облегчить управление большими разнородными сетями. Для управления сетями передачи данных по протоколу IP существует протокол управления сетью SNMP (Simple Network Manager Protocol), который обеспечивает поддержку правил взаимодействия управляющей станции и объектов управления. А данные управления хранятся внутри объекта. Таким образом протокол SNMP позволяет управлять самыми разными объектами сети централизованно.

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

1. Обзор существующих технологий мониторинга в телекоммуникациях

1.1 Протокол управления сетью SNMP

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

В целях создания единого подхода к управлению оборудованием, подключенным к сетям IP, был разработан простой протокол сетевого управления (Simple Network Management Protocol — SNMP).

Всю сеть с точки зрения управления можно разделить на систему управления и объекты управления. К системе управления отнесем совокупность вычислительных средств, предназначенных для формирования управляющих воздействий и анализа информации, на основе которой принимается решение об управлении. Объекты управления — это ресурсы, которыми необходимо управлять (активное сетевое оборудование, рабочие станции, сервера и др.).

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

В SNMP-совместимых объектах управления реализован специальный программный модуль, который называется агент. Агенты собирают информацию об управляемых устройствах, в которых они работают, и делают эту информацию доступной для систем управления сетями (network management systems — NMS) с помощью протокола SNMP. Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве — будь то сервер, модем или маршрутизатор — в так называемой административной базе данных (MIB — Management Information Base). SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Для того чтобы проконтролировать работу некоторого устройства сети, необходимо просто получить доступ к его MIB, которая постоянно обновляется самим устройством, и проанализировать значения переменных. Функции анализа и обработки данных, принятия решений о состоянии объекта возложены на управляющую систему. Описанная выше модель управления SNMP представлена на рисунке 1.1.

Технология SNMP состоит из трех частей:

— структура управляющей информации (Structure of Management Information, SMI);

— базы управляющей информации (Management Information Base, MIB);

— сам протокол SNMP, определяющий правила взаимодействия менеджера и агента.

Структура управляющей информации определяет правила описания управляющей информации. Формальное описание объектов осуществляется с помощью языка Abstract Syntax Notation One (ASN.1). Для задания имени объекта достаточно указать его идентификатор (OBJECT IDENTIFIER), представляющий собой последовательность целых чисел. Все идентификаторы организуются в виде листьев дерева. На верхнем уровне дерева присутствуют три узла: iso, ccitt и joint-iso-ccitt, которые принадлежат разным стандартным организациям. В поддереве iso присутствует идентификатор org (узел, являющийся корнем для поддеревьев различных организаций), один из подузлов которого — Министерство обороны США (Department of Defence — DOD). Считается, хотя официально это и не зафиксировано, что первым узлом в поддереве DOD является Internet. Таким образом, объект «internet» имеет идентификатор «1.3.6.1»: internet OBJECT IDENTIFIER := { iso (1) org (3) dod (6) 1}.

Для правильной интерпретации объекта одного идентификатора недостаточно. Необходимо указать тип объекта и дать его смысловое определение. Для этого служит информационная база управления (Management Information Base — MIB). В ней описаны все объекты в соответствии с грамматикой ASN.1. Наличие текстового представления базы MIB на стороне системы управления позволяет не только правильно интерпретировать получаемые данные, но и давать пользователю пояснения об объектах на основе описания, присутствующего в базе. Для объекта управления нет необходимости в наличии текстового варианта базы MIB.

Для наглядности структуру MIB принято представлять в виде дерева. Рассмотрим пример. На рисунке 1.2 приведен фрагмент дерева MIB, по которому можно найти расположение переменной sysDescr. У ветви internet (1) всего шесть поддеревьев. Это:

— Directory (1) — каталог OSI;

— mgmt (2) — стандартные объекты RFC;

— Experimental (3) — эксперименты с internet;

— Private (4) — зависит от производителя;

— Security (5) — безопасность;

— snmp V2 (6) — описание работы SNMP.

Нужная нам переменная sysDescr находится в ветви mgmt (2), так как она относится к применению SNMP для управления устройствами. Далее располагается ветвь mib-2, с которой, в сущности, и начинается база MIB.

Далее, под термином «значение переменной» будем понимать значение объекта, имеющего заданное имя (идентификатор). Использование только объектов, требуемых по спецификации протокола SNMP, не позволяет задействовать некоторые возможности управляемой аппаратуры. Например, маршрутизаторы фирмы Cisco поддерживают многочисленные сетевые протоколы, отличные от IP. С помощью стандартных объектов, описанных в базах MIB, невозможно получить информацию, касающуюся этих протоколов. Для разрешения подобного конфликта в дереве объектов существует специальный узел private (internet 4), одним из подузлов которого является узел «предприятия» (enterprises, private 1). Все объекты, которые фирма-производитель желает сделать доступными по протоколу SNMP, описываются в поддеревьях соответствующей фирмы.

Непосредственно сам протокол SNMP представляет собой простой протокол, работающий по механизму «запрос-ответ». SNMP-сообщения вкладываются в UDP дейтаграммы. Основные операции протокола:

— Get_request — получить значение указанной переменной или информацию о состоянии сетевого элемента;

— Get_next_request — получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);

— Set_request — присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;

— Get_response — отклик на Get_request, Get_next_request и Set_request. Содержит также информацию о состоянии (коды ошибок и другие данные);

— Trap — отклик сетевого объекта на событие или на изменение состояния.

Рисунок 1.1 — Модель управления SNMP

Рисунок 1.2 — Поиск sysDescr (1) в MIB

Схема взаимодействия менеджера и агента по протоколу SNMP приведена на рисунке 1.3.

Взаимодействие менеджера и агента происходит не строго по схеме «запрос-ответ». В ряде случаев необходима активная роль управляемого устройства. Для предоставления ему возможности передать некоторую информацию по собственной инициативе предназначен блок данных Trap (прерывание). К событиям, требующим особого внимания, относятся перезагрузка устройства, исчезновение связи и многие другие. Эти события определяются возможностями устройства.

На сегодняшний момент существует три версии протокола SNMP.

SNMPv1. Данной версией поддерживаются все выше перечисленные операции. Политика безопасности базируется на использовании имени сообщества (Community Name), которое, находясь в заголовке SNMP, несет в себе все возможности защиты сообщений. Данное средство требует, чтобы программа-агент и менеджер опознали одно и то же имя сообщества, прежде чем продолжить выполнение операций сетевого администрирования. Такой уровень защиты является во многих случаях недостаточным, так имя сообщества пересылается в незашифрованном виде в каждом пакете SNMP.

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

Также в SNMPv2 появилась новая операция get_bulk_request, которая позволяет запросить блок однотипных данных (например, таблицу), при этом сокращается количество запросов, что уменьшает трафик.

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

Рисунок 1.3

SNMPv3. В версии 3 протокол SNMP значительно усложнился. Но сохранил поддержку предыдущих версий. На языке версии 3 устройства и компоненты управления называются «сущностями» (entities). Одна сущность (прежде известная как агент) находится на маршрутизаторе, а другая (в прошлом менеджер) — занимается опросом приложений. Каждая сущность имеет SNMP-ядро и приложение. Ядро SNMP составляют четыре функции: контроль доступа, безопасность, обработка сообщений и диспетчер. В модули процессора сообщений и диспетчера включены также функции версий SNMPv1 и 2, в том числе для обработки команд set и get, и для форматирования блоков данных SNMP или PDU (protocol data unit). Диспетчер исполняет роль привратника, т. е. все входящие/выходящие сообщения проходят через него. Обрабатывая SNMP-сообщение, диспетчер определяет, к какой версии протокола оно принадлежит, и отсылает его соответствующему модулю-процессору для анализа. Если диспетчер не может определить версию, например из-за некорректного формата пакета, он регистрирует ошибку. Процессор сообщений пересылает сообщение подсистеме безопасности или подсистеме контроля доступа, а затем отсылает обратно диспетчеру, который и передает его SNMP-приложениям.

Основным достижением версии 3 стал усовершенствованный механизм безопасности. Для обеспечения аутентификации и конфиденциальности используется модель безопасности, ориентированная на пользователя (User-Based Security Model — USM). Модель USM состоит из модулей аутентификации, временного контроля и конфиденциальности. Модули аутентификации и конфиденциальности обеспечивают целостность данных, их достоверность и защиту. Модуль временного контроля призван следить за синхронизацией времени между SNMP-сущностями с целью пресечения взломов типа replay attack — он блокирует пакеты с устаревшими метками времени.

В USM-модели применен алгоритмы MD5 и SHA, и другие алгоритмы хэширования. В качестве меры предосторожности пароль по сети не пересылается. Вместо этого PDU-блок дважды подвергается хэшированию с использованием двух ключей, сгенерированных из закрытого ключа, затем первые 12 октетов выступают в роли кода аутентификации сообщения (Message Authentication Code — MAC), который добавляется к этому сообщению. Такой же процесс, но в обратном порядке происходит на другом конце.

В SNMPv3 определено три уровня аутентификации и конфиденциальности. Первый — это просто отсутствие конфиденциальности, обозначается «noAuthNoPriv». Он аналогичен строковым паролям доступа, передаваемым открытым текстом, которые применяются в версии 1 и 2, и используется в период отладки или когда SNMP-сущности находятся в защищенной среде. Второй уровень — это аутентификация без конфиденциальности, или «authNoPriv». Третий уровень — «authPriv» — это не только аутентификация, но и шифрование SNMP-данных. Для шифрования данных применяется алгоритм DES.

В SNMPv3 также входит модель разделения доступа на базе представлений (VACM — View-based Access-Control Model), позволяющая ограничить доступ к переменным MIB (базы управляющей информации). В модели VACM «представление» (view) определяет, какая часть базы MIB доступна, и устанавливает связь между пользователями и этим представлением. Механизмы VACM требуют, чтобы представление и группа создавались на каждом сетевом устройстве, причем представление определяет доступную часть MIB, а группа — привязывает входящих в нее пользователей к этому представлению.

1.2 Технология RMON

SNMP имеет два главных компонента: транспортный механизм для перемещения данных управления по сети и схему или шаблон данных, известный как база управляющей информации, или MIB. Удаленный мониторинг (RMON — Remote Monitoring) — это расширенная база управляющей информации для поддержки приложений, которым необходимо больше данных, чем SNMP MIB-2 способна предоставить.

Базы RMON состоят из набора статистических, аналитических и диагностических данных, обеспечивая независимость от производителя аппаратуры. Отличие RMON от SNMP состоит в характере собираемой информации, если в MIB-2 эта информация характеризует только события происходящие на узле где установлен агент, то данные RMON характеризуют трафик любых (и неинтеллектуальных) сетевых устройств. Ключевым моментом в эффективности мониторинга RMON является возможность сохранять статистические выборки данных в разные моменты времени в самом зонде, а также в том, что агенты (зонды) RMON производят частичную обработку данных (фильтрацию и сортировку).

Cтандарт RMON работает на физическом и уровне связи сетевой модели OSI и включает 10 групп баз:

— Statistics — совокупный сетевой трафик и статистика ошибок. Счетчики переменных, подсчитывающие число переданных байт, пакетов, пакетов с ошибками, широковещательных пакетов и т. д., определяются как 32-битные счетчики, которые при переполнении обнуляются;

— History — базируясь на группе Statistics, эта группа предназначена для анализа поведения сети во времени, выработки базовой линии, сравнения происходящих в сети изменений в разное время. Зонд может сохранять определяемое пользователем количество статистических выборок (зависит от величины оперативной памяти зонда) через определенный пользователем интервал времени (от 1 сек до 3600 сек) для сбора как кратковременной так и долговременной статистики;

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

— Hosts — в табличном формате предоставляется статистика по трафику для каждого сетевого узла, базируясь на его MAC-адресе;

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

— Matrix — производит отслеживание величины трафика или количества ошибок между двумя устройствами в соответствии с их MAC-адресами;

— Filter — совместно с группой Packet Capture обеспечивает захват пакетов для последующего анализа. Зонд может фильтровать пакеты для последующего поиска специфической информации внутри пакета. Имеется возможность сортировать пакеты с определенным адресом, группой адресов, определенным протоколом и какой-то желаемой комбинацией. Созданные пользовательские фильтры используются группами Capture и Events;

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

— Events — определяет какие сообщения (Traps) могут быть посланы зондом на управляющую консоль (или несколько станций) при возникновении событий: пересечения порога, захват пакета в соответствии с указанным шаблоном, связь есть, связи нет, холодный старт, теплый старт, несанкционированный доступ и другие. Управляющая станция или игнорирует приходящее сообщение или производит запись приходящего сообщения в журнал и выполняет какие-то автоматические действия (выводит сообщение на экран, запускает определенное приложение и т. п.);

— Token Ring обеспечивает получение набора статистических данных для сетей Token Ring.

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

RMON-агенты могут быть либо встроены в оборудование, но тогда их возможности ограничены, либо они могут быть отдельными программными или аппаратными модулями.

1.3 Решения компании Cisco в области управления сетями На основе протокола SNMP и технологии RMON существует большое количество программных и аппаратных решений для управления сетями и их мониторинга. Большие коммерческие комплексы позволяют решать широкий спектр вопросов. Компании-производителя сетевого оборудования предлагают свои программные продукты. Для примера можно назвать системы HP OpenView фирмы Hewlett-Packard, NetView for AIX фирмы IBM, SunNet Manager производства одного из подразделений Sun компании SunConnect, Spectrum компании Cabletron System и NetWare Management System компании Novell (применяется главным образом для организации работ в локальных сетях, построенных на базе семейства операционных систем NetWare).

Так же существует большое количество бесплатных программ, которые обычно решают какие-то более узкие задачи (например, утилиты для просмотра MIB устройства, или программы для сбора значений переменных MIB и записи их в базу данных и др.). Хотя есть и бесплатные аналоги коммерческих платформ управления. Например, программа BlueBird (OpenNMS).

Чтобы иметь представление о функциональности коммерческой системы мониторинга и управления, рассмотрим программные средства, предлагаемые компанией Cisco.

Cisco предлагает серию программных продуктов под общим названием CiscoWorks, которая делиться на два типа:

1. Решения CiscoWorks2000 представляют собой набор полномасштабных решений для средних и больших сетей (enterprise). Эти решения фокусируются на трех основных областях: управление глобальными сетями (WAN), управление локальными сетями (LAN) и управление на уровне предоставления услуг.

Для предоставления законченных решений (end-to-end) в этих областях Cisco предлагает следующие наборы программных продуктов:

— CiscoWorks2000 LAN Management Solution (LMS) — решение для управления локальными коммутируемыми сетями;

— CiscoWorks2000 Routed WAN Management Solution (RWAN) — решение для управления маршрутизируемыми территориальными сетями;

— CiscoWorks2000 Small Network Management Solution (SNMS) — решение для управления локальными сетями небольшого размера;

— CiscoWorks2000 VPN/Security Management Solution (VMS) — решение для управления системой сетевой безопасности;

— CiscoWorks IP Telephony Environment Monitor (ITEM) — решение для управления мультисервисными сетями, поддерживающее Cisco IP Telephony и приложения IP телефонии.

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

— CiscoWorks for Windows (CWW) — облегченная версия сетевого управления, в которой предусмотрены все возможности, необходимые для управления сетью малого предприятия, предприятия средних размеров или рабочей группы;

— CiscoWorks QoS Policy Manager — программный комплекс, облегчающий внедрение дифференцированных услуг и поддержки качества услуг (Quality of Service, QoS) на основе централизованной политики;

— CiscoWorks Wireless LAN Solution Engine — программно-аппаратный комплекс, решающий задачи повседневного мониторинга и управления инфраструктурой беспроводных локальных сетей Cisco Aironet;

— CiscoWorks Hosting Solution Engine — программно-аппаратный комплекс, автоматизирующий задачи поддержки центров обработки данных для бизнес-приложений.

ПО CiscoWorks основано на стандартном протоколе сетевого управления Simple Network Management Protocol (SNMP), что позволяет надежно управлять оборудованием Cisco в самых разнообразных разнородных сетях. В случае установки в качестве дополнения к уже имеющейся платформе сетевого управления CiscoWorks других отдельных компонентов позволяет расширить ее возможности.

Рассмотрим более подробно состав решения для локальных сетей — CiscoWorks2000 LAN Management Solution, так как в данном дипломном проекте рассматривается локальная сеть:

— Campus Manager (CM) — для обнаружения и управления L2/L3 (Layer2/Layer3 — второго и третьего уровня модели OSI — Open System Interconnection) коммутаторами, конфигурирования и управления VLAN (Virtual Local Area Network — виртуальные локальные сети) и ATM LANE (Asynchronous Transfer Mode LAN Emulation — эмуляция ЛВС поверх ATM), а также определения подключения пользователей и IP телефонов;

— Device Fault Manager (DFM) — обеспечивает в режиме реального времени обнаружение и определение причин сбоев сетевого оборудования;

— Cisco nGenius Real-Time Monitor — инструмент для сбора и отображения RMON статистики, генерируемой коммутаторами Catalyst, модулями сетевого анализа Network Analysis Module и внешними пробниками RMON;

— Resource Manager Essentials — для управления критичными сетевыми ресурсами через Интернет с использованием Web-интерфейса. Предоставляет набор инструментов для поиска и устранения неисправностей в сети, сбора детализированных отчетов, централизованного обновления программного обеспечения и конфигураций устройств, управления и конфигурации VPN, CallManager и др.;

— CiscoView (CD-One) — графическое средство управления устройствами;

— CiscoWorks2000 Management Server — общее управление интеграцией со сторонними системами сетевого управления, контролем административного доступа и сервисами для всего семейства решений CiscoWorks2000.

1.4 Системы тарификации для УАТС Современная УАТС имеет возможность выдавать информацию о звонках, идущих через нее, на специальный аппаратный порт, называемый обычно SMDR (Station Message Detail Recording) или CDR (Call Detail Recording). Если к этому порту подключить персональный компьютер, то полученную информацию можно принимать, сохранять и обрабатывать. Но для этого на нем должно быть установлено специальное программное обеспечение — тарификационная система.

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

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

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

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

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

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

Рынок тарификационных систем в настоящее время весьма разнообразен. Условно все учрежденческие тарификационные системы можно разделить на три основные категории:

— простейшие тарификаторы;

— системы, поставляемые в комплекте с УАТС;

— универсальные тарификационные системы.

К первой категории обычно относятся те программы, которые разрабатываются самостоятельно или под конкретный заказ. До последнего времени в тех случаях, когда производители станций не предлагали тарификатор в комплекте с АТС, такие программы создавали сами дистрибуторы УАТС. Данные системы недороги и выполняют лишь функцию тарификации, они практически непригодны для организации финансового учета и контроля телефонных переговоров.

Системы, поставляемые производителями в комплекте с АТС, также имеют ряд недостатков. Обычно они предназначены только для работы с одним типом УАТС, не всегда отвечают современным требованиям, предъявляемым к программному обеспечению, имеют довольно высокую цену и не приспособлены к работе в российских условиях. Кроме того, далеко не все производители УАТС предлагают собственные тарификационные системы.

Универсальные тарификационные системы независимых разработчиков ПО, как правило, отвечают современным требованиям и ориентированы на поддержку АТС различных производителей. Часто они имеют дополнительные возможности для организации учета и обработки накопленной информации, а также для ведения счетов, поэтому иногда их называют еще биллинговыми системами (Billing System). Примерами биллинговых систем зарубежного производства могут служить такие продукты, как Ringmaster (Ирландия), BackTrack (США), PhonEx Pro (Израиль) и CallMaster (Канада).

Особо следует отметить российские разработки — они не только не уступают по качеству зарубежным аналогам, но и лучше адаптированных к российскому рынку, кроме того, выгодно отличаются от остальных своей стоимостью. Примерами таких систем являются «Барсум» (фирма «Рексофт», Санкт-Петербург), PhoneTax (фирма ITSoft, Казань), «ТелеМастер» (фирма «АМТ Ком», Москва).

2. Анализ фрагмента ведомственной сети ОАО «Хабровскэнерго»

2.1 Общая характеристика фрагмента сети. Кабельная система Схема фрагмента ведомственной сети ОАО «Хабаровскэнерго» представлена на странице 88.

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

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

Кабельная система на всех участках сети представлена волокнно-оптическим кабелем разного типа. Для организации телефонной сети и сети передачи данных между узлами используются разные пары волокон одного кабеля. За исключением участка узел, А — узел С, где мультиплексор объединяет трафик телефонной сети и сети передачи данных для передачи по одной паре волокон.

Основные характеристики кабельной системы сведем в таблицу 2.1.

Таблица 2.1

2.2 Характеристика фрагмента телефонной сети Телефонная сеть на рассматриваемом участке представлена учережденческими цифровыми автоматическими станциями Hicom фирмы Siemens и станцией NEAX фирмы NEC (схема на странице 88).

Узел, А оснащен станцией типа Hicom 382, на узле В используется станция типа Hicom 350E, на узлах C и D — станции типа Hicom 3×3, на узле Е — станция типа NEAX 2000 IPS.

Связь станций друг c другом организована по потокам E1. Для этого во всех станциях установлены платы PRI ISDN.

Связь узла, А с узлом В организована по двум потокам Е1, объединенных в модуль STM-1 иерархии SDH, через мультиплексоры STM-1/STM-4 Metropolis AMU фирмы Lucent Technologies. Каждое соединение Е1 между станцией и мультиплексором осуществляется по кабелю витая пара, соединение между мультиплексорами организовано по волоконно-оптической линии.

Так же организовано соединение узлов, А и Е, но используется один поток Е1, который включен в узле, А в тот же мультиплексор Metropolis AMU. Данный мультиплексор имеет 16 интерфейсов для подключения потоков Е1 по кабелю витая пара и два оптических интерфейса STM-1. Таким образом можно организовать две волоконно-оптические линии в двух направлениях.

Узлы, А и С соединены по одному потоку Е1 через мультиплексоры DLC-1100E фирмы НАТЕКС. В конфигурацию данного мультиплексора входят модуль для работы с АТС по интерфейсу Е1 и оптический приемопередатчик.

Узлы, А и D соединены по потоку Е1 напрямую, через оптические интерфейсы станций Hicom 382 и Hicom 3×3, без использования мультиплексоров.

2.3 Характеристика фрагмента сети передачи данных Сеть передачи данных построена на коммутаторах фирмы Cisco (схема на странице 88).

В узлах B, C, D, E используются коммутаторы Catalyst 2950T-24, с 24 портами для подключения сетевых устройств по технологии Ethernet 10/100BaseT. Данная технология предполагает скорость соединения 10 или 100 Мбит/с и использование кабеля витая пара. Коммутаторы Catalyst 2950T являются устройствами второго уровня модели OSI/ISO. Это означает, что при возможности организации виртуальных локальных сетей на данном коммутаторе, коммутация между этими сетями невозможна. Для этого необходимо устройство третьего уровня модели. Поэтому в узле, А используется коммутатор Catalyst 3550T-24, являющийся коммутатором третьего уровня. Catalyst 3550T-24 также имеет 24 порта 10/100BaseT.

Для связи коммутаторов между собой по волоконно-оптической линии используются медиаконверторы, которые преобразуют среду 100BaseT (кабель витая пара) в 100BaseFX (волоконно-оптический кабель). Для связи между узлами, А и B, D, E используются медиаконверторы AT-MC103XL фирмы Allied Telesyn для одномодового кабеля. А между узлами, А и С проложен многомодовый кабель, но там коммутаторы включены в мультиплексоры DLC-1100Е, в конфигурацию которых входит модуль передачи данных с интерфейсом 10/100BaseT. Таким образом, между узлами, А и С используется одна пара волокон для телефонии и передачи данных.

2.4 Характеристика оборудования с позиции мониторинга На коммутаторах Catalyst 2950−24T в узлах B, C, D и E установлено программное обеспечение Cisco IOS версии 12.1(20) ЕА1а. На коммутаторе Catalyst 3550 в узле, А установлено ПО Cisco IOS версии 12.1(11) ЕА1.

Обе версии программного обеспечения поддерживают ряд средств для мониторинга оборудования. Поддерживаются следующие версии протокола SNMP — v1, v2C (Classic), v3. Выбор версии осуществляется при настройке. Таким образом, обеспечивается гибкость уровня безопасности — от доступа к агенту SNMP только по уровню сообщества до поддержки авторизации и шифрования пересылаемых данных. Кроме того, при использовании протокола SNMP с версии 2С, коммутатор сам может выступать в качестве менеджера и таким образом, быть частью иерархической структуры управления сетью.

Кроме возможности использования разной модели безопасности (SNMPv1, SNMPv2C, SNMPv3) в модели SNMPv3 еще возможны различные уровни безопасности. Для коммутаторов Catalyst эти уровни приведены в таблице 2.2.

Таблица 2.2

Так же есть возможность настроить коммутаторы таким образом, чтобы они посылали SNMP-сообщения, называемые «ловушками» при специфичных событиях (например, при изменениях в настройке SNMP на коммутаторе).

Коммутаторы Cisco поддерживают технологию RMON. В ПО Cisco IOS реализовано четыре группы RMON:

— Statistics — сбор статистических данных о трафике, проходящем через интерфейс;

— History — сбор статистических выборок через определенный интервал;

— Alarm — установка некоторым переменным MIB пороговых значений и генерация сообщений (если это определено группой Event) на управляющую станцию;

— Event — определение ситуаций, когда необходимо послать сообщение управляющей станции.

Мультиплексоры Metropolis AMU фирмы Lucent Technologies и DLC-1100E фирмы НАТЕКС также поддерживают протокол SNMP. Но в мультиплексор DLC-1100E необходимо дополнительно установить для этого модуль сетевого управления NMI.

Все станции Hicom и NEAX предусматривают выдачу тарификационной информации на терминальный порт (в данном случае это com-порт). Кроме того, станции Hicom могут накапливать эту информацию на своих внутренних жестких дисках, а временный буфер (на несколько сотен записей) имеют и станции NEAX. Поддерживаются разные форматы выдаваемой информации, которые можно настроить с терминала управления станцией. Станции Hicom 382, 3×3, 350Н имеют по три com-порта, станция NEAX 2000IPS имеет один com-порт.

3. Разработка структуры системы мониторинга

3.1 Выбор решения для мониторинга сети передачи данных Согласно заданию, организуемая система мониторинга должна обеспечивать контроль состояния коммутаторов Cisco Catalyst 2950T-24 и Catalyst 3550−24T и их интерфейсов. Под контролем состояния коммутаторов подразумевается сбор статистики о загрузке центрального процессора, объема свободной памяти и времени наработки на отказ (up-time). Под контролем состояния интерфейсов подразумевается сбор статистики о количестве всех переданных через интерфейс пакетов, о количестве пакетов с ошибками. Необходимо так же организовать оперативное оповещение администратора об изменении статуса интерфейса (up или down).

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

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

Рассматриваемый спектр задач слишком узок для использования специализированных программных комплексов, предлагаемых, например, компанией Cisco. Эти решения, к тому же, являются достаточно дорогими (в среднем от 5 до 30 тысяч долларов США в зависимости от функциональности).

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

Более подходящим решением видится написание собственной программы. На выбор такого решения повлияло ряд факторов:

— поддержка оборудованием единого протокола управления SNMP и наличие на сайте производителя оборудования www.cisco.com списка всех переменных MIB, поддерживаемых оборудованием;

— опыт программирования на языке Perl и наличие готовых модулей для Perl для работы с протоколом SNMP;

— возможность дальнейшего расширения и изменения программы в соответствии с возникающими задачами.

3.2 Выбор решения для тарификационной системы Согласно заданию, необходимо организовать сбор тарификационной информации со станций Hicom и NEAX, и ее хранение для возможности дальнейшей обработки и анализа.

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

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

В рамках данного дипломного проекта должны быть решены следующие задачи:

— сбор информации о звонках со станции и загрузка ее в базу данных;

— отображение в виде графика нагрузки на определенное направление.

3.3 Выбор общей схемы системы мониторинга Рассматриваемый в данном проекте фрагмент сети представлен пятью узлами. Обслуживающий персонал рассматриваемого оборудования располагаются только в центральном узле (узел А). В зданиях, где располагаются другие узлы, персонал находится не постоянно.

Поэтому организуемая система мониторинга должна обеспечивать передачу информации о состоянии оборудования в центральный узел.

Передача информации о состоянии коммутаторов Cisco Catalyst 2950 и Catalyst 3550 по протоколу SNMP происходит по сети передачи данных. Для удаленного управления УАТС Hicom и NEAX возможно подключение к станциям по модему. Поэтому одним из вариантов организации системы сбора информации является установка в центральном офисе выделенного компьютера и написание программ, которые бы по очереди опрашивали по сети передачи данных все коммутаторы и также, по очереди подключаясь к станциям по телефонной сети через модем, скачивали тарификационную информацию. Схема подключения для такого варианта построения системы приведена на рисунке 3.1. Выделенный компьютер подключается по интерфейсу RS-232 (com-порт) к станции, находящейся в центральном узле (узел А), и по такому же интерфейсу подключается к модему, через который можно подключаться к модемам удаленных станций. Так же компьютер подключен к порту коммутатора ЛВС (локальной вычислительной сети), который имеет связь с остальными коммутаторами ведомственной сети. Структурная схема приведена на рисунке 3.2. Вся информация в данном случае собирается в базы данных (БД), находящиеся на выделенном компьютере, где так же могут располагаться программы обработки и отображения полученной статистической информации.

Подобное решение имеет ряд существенных недостатков. Главным недостатком является то, что УАТС NEAX, которая располагается в узле Е имеет всего один порт RS-232 и поэтому периодическое подключение по модему, соединенному с этим портом, для сбора тарификационной информации затруднит удаленное управление этой станцией. К тому же модемное соединение обеспечивает низкую скорость и надежность и увеличивает нагрузку на потоки Е1, которыми соединены станции, а нагрузка на межстанционные соединения в данной сети без того достаточно большая.

Решением этих проблем могло бы стать использование так называемых консольных серверов — устройств, при помощи которых по сети передачи данных возможно подключение к консольным портам различных устройств. Например, компания Digi Internation предлагает широкий спектр оборудования для удаленного доступа к консольным интерфейсам различного оборудования. Для наших целей мог бы послужить так называемый девайс-сервер Digi One TS (примерно 400 долларов США), у которого имеется один интерфейс RS-232 и один интерфейс 100BaseT. При помощи этого устройства управление и сбор информации для тарификации осуществляется по сети передачи данных, что ускоряет оба действия. Кроме этого, обеспечивается большая безопасность при подключении к станциям за счет доступа по паролю к консольному серверу.

Схема подключения для решения с использованием консольных серверов приведена на рисунке 3.3, а структурная схема — на рисунке 3.4.

Рисунок 3.1

Рисунок 3.2

Рисунок 3.3

Рисунок 3.4

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

Использование в каждом узле выделенного персонального компьютера повысит надежность всей системы.

Схема подключения оборудования при использовании выделенного компьютера в каждом узле приведена на рисунке 3.5. Персональный компьютер (ПК) в каждом узле имеет два интерфейса RS-232 (com-порт) и оборудован сетевым адаптером FastEthernet (10/100BaseT), таким образом обеспечивается подключение к консольному порту учрежденческой телефонной станции и к порту коммутатора Cisco Catalyst. Нужно отметить, что коммутаторы ЛВС во всех узлах имеют свободные интерфейсы, что позволяет подключать дополнительные устройства к сети передачи данных. При таком подключении персональный компьютер играет роль и консольного сервера, поэтому достоинства удаленного управления УАТС по сети передачи данных в этом случае сохраняются.

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

В данном проекте было выбрано решение об организации системы мониторинга с выделенными ПК в каждом узле.

Рисунок 3.5

Рисунок 3.6

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

— процессор Intel Pentium с частотой не выше 300 МГц;

— не более 64 Мбайт оперативной памяти;

— наличие свободного дискового пространства — не более 1 Гбайта.

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

Таблица 3.1

Цены на комплектующие предоставлены компанией «Офисная техника» .

Согласно схеме организации системы мониторинга (рисунок 3.5), выделенные компьютеры должны иметь интерфейс RS-232 и сетевой адаптер 10/100BaseT для подключения к сети передачи данных. Наличие консоли (монитора и клавиатуры) не нужно, так как не предполагается совмещать эти компьютеры с рабочими местами персонала, а доступ к ним будет осуществляться удаленно. Выбор процессора Intel Pentium 4 обусловлен соображениями надежности. Два модуля оперативной памяти, по 256 Мбайт каждый, для всех компьютеров необходимы для того, чтобы объем оперативной памяти не стал узким местом для производительности компьютера, в случае, если в дальнейшем на него будут возложены дополнительные функции.

Во всех узлах рассматриваемой сети коммутаторы ЛВС располагаются в специальных телекоммуникационных шкафах. В узлах B, C, D, E УАТС и шкафы с коммутаторами располагаются в одной комнате. В узле, А УАТС и шкаф с коммутатором располагаются в разных комнатах. Установка выделенных компьютеров для мониторинга предполагается в шкафы с коммутаторами, кроме узла А, где компьютер будет располагаться в комнате с УАТС. Это обусловлено ограничением на длину кабеля RS-232, которым должны соединятся станция и компьютер, в 9 метров максимум.

Из программного обеспечения компьютеров необходимо следующее:

— операционная система;

— интерпретатор языка Perl;

— система управления базами данных (СУБД).

Язык программирования Perl является интерпретируемым языком, то есть для запуска программ, написанных на этом языке, необходимо дополнительно ПО — интерпретатор. Собственно сам выбор данного языка программирования обусловлен следующими факторами:

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

— наличие бесплатных и небольших интерпретаторов, а так же быстрота выполнения программ;

— широкий спектр дополнительных модулей (в частности, для работы с базами данных, с протоколом SNMP и с com-портом, что необходимо для решения задач данного проекта);