Были рассмотрены все существующие архитектуры управления КС, начиная с одноуровневой и заканчивая платформенной архитектурой и сделан вывод что нынешние СУ КС используют платформенную архитектуру.

Глава 2. Разработка требований, предъявляемых к современным СУ КС

Имеющиеся международные стандарты на системы управления (ISO 7498-4, ITU-T Х.700), выделяют 5 блоков задач для системы менеджмента [47]:

1. Процесс управление конфигурацией сети и идентификация сетевых устройств.

2. Процесс обрабатывания ошибок.

3. Мониторинг производительности и надежности сети.

4. Процесс управления безопасностью.

5. Процесс учета работы сети.

2.1 Задачи системы управления

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

Процесс управления конфигурацией сети и идентификацией сетевых устройств

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

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

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

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

Еще одна сложная задача - это синхронное настраивание списка маршрутов при отказе от применения протоколов маршрутизации, к примеру, при использовании сети Х.25 подобного протокола попросту нет. С этой проблемой производители стараются справиться своими силами, и компания Cisco Systems создала NetSys, которая решает эту проблему, но только для своего оборудования.

Процесс обрабатывания ошибок

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

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

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

Мониторинг производительности и надежности сети

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

С помощью контролирования параметров надежности и производительности, администратор сети (или организация, предоставляющая услуги) поддерживает необходимый уровень предоставляемых услуг (Service Level Agreement, SLA), с потребителем. Как правило в договоре SLA устанавливаются такие параметры надежности, как вероятность работы службы в течение года и месяца, период простоя системы, а также значения производительности, к примеру, значения средней и предельной пропускной способности при непосредственном подключении двух точек доступа пользователей, скорость реагирования сети (если служба, которая работает в сети, поддерживается сетью), допустимое время задержки транспортных пакетов при трансляции через сеть. Поставщику услуг необходимо иметь набор технологий для анализирования показателей надежности и производительности сети, иначе администратор или информационный отдел не будет иметь возможности контролировать уровень предоставляемых услуг оконечным пользователям сети.

Процесс управления безопасностью

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

Учет работы сети

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

В модели управления OSI нет различия между множеством объектов - мосты, модемы, маршрутизаторы, коммутаторы, мультиплексоры, СУБД, аппаратным обеспечением и ПО, каналы - все они воспринимаются под общим названием "система" и одна система управления общается с другой управляемой через протоколы OSI.

Вышеперечисленных 5 групп недостаточно, если речь идет об интеллектуальных системах управления КС.

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

2.2 Разработка требований к ИСУ КС

Условия работы ИСУ КС могут значительно различаться вследствие разнородности сетевого оборудования, различных требований, предъявляемых пользователями и многочисленности сетевых стандартов и возможных топологий.

Для любой системы управления можно определить такие требования:

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

Своевременно прогнозировать возможные проблемы в работе сетевого оборудования в будущем.

Своевременно сообщать администратору сети о возможных неполадках в работе сети.

Обеспечить анализ собираемых данных о работе сети в режиме реального времени.

Поддерживать сохранность конфиденциальной информации.

Обладать интуитивно-понятным интерфейсом.

При разработке ИСУ КС можно выделить ряд общих требований (рис. 16) [8,40, 41]

Рис. 16. Основные требования к ИСУ КС

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

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

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

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

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

Требование объяснения решений, которое наряду с предыдущим обеспечивает взаимообмен знаний в системе "пользователь - информационная система"

При этом выделяют еще дополнительные принципы [42, 43,44]:

Гибкость. При создании и применении ИСУ КС необходимо использовать широкий спектр проектных решений и средств реализации функций управления, разрешая пользователям выбирать и устанавливать различные варианты системы;

Настраиваемость. Средства ИСУ КС должны разрешать изменения или переход к различным структурам организации управления и предусматривать интерфейсы с системными учетно-контролирующими и управляющими программами;

Интеграция. Подсистемы ИСУ КС должны управлять всеми основными и вспомогательными процессами обработки данных

Выводы

На основе задач, которые предстоит решать системе управления и рассмотренных архитектур систем управления были сформированы обобщенные требования к системе управления КС.

Глава 3. Выбор архитектуры системы управления компьютерными сетями

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

Мосты, маршрутизаторы, коммутаторы и другое активное сетевое оборудование представляю собой объекты сети и все они поддерживают протокол SNMP (RFC-1089,-1157, - 1187, - 1215).

Рассмотрим 7 блоков системы управления представленной на рисунке 17:

· Блок управления и прогнозирования - выполняет функцию контроля системы управления и прогнозирует состояние сети по информации полученной с блока формирования архитектуры сети.

· Блок доступа к оборудованию - дает возможность получать данные из компьютерной сети об активных сетевых устройствах.

· Блок поиска устройств в сети - выполняет функцию поиска устройств в компьютерной сети и восстанавливает схему сети.

· Блок формирования архитектуры сети - с поддержкой настраиваемых параметров (числа внутренних слоев, первоначальные величины весов) устанавливает конструктивные особенности комплекса.

· Блок визуализации - выступает в роли GUI (Graphical User Interface - графический интерфейс пользователя).

· Блок сбора статистики - выполняет функцию сбора статистической информации об устройствах.

· Блок хранения статистики - хранит информацию об устройствах в компьютерной сети.

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

Блок формирования архитектуры сети применяет сохраненную статистику для организации настойки сети и ее учебы.

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

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

Рис. 17. Архитектура системы управления

Глава 4. Выбор способа организации системы мониторинга

4.1 Выбор модели, предназначенной для анализа и оптимизации компьютерной сети

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

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

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

Применяются такие способы сбора данных:

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

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

Независимый способ. Сбор данных не подчиняется ни первому ни второму правилу.

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

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

Если же метод основан на регламентированном способе (не зависит от момента изменения состояния), то вероятность примет вид:

где, с - значение, показывающая среднюю величину времени записи информации в БД относительно реального момента изменения информации; b - Время сбора, получения и записи информации для обновления БД; q - Интервал времени между двумя последовательными запросами одного объекта.

Параметры q и b возможно явно связать, если система мониторинга работает в режиме on-line:

k - число опрашиваемых устройств в сети

n - число потоков в системе мониторинга

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

Способы осуществления многопоточной модели мониторинга на существующих однопроцессорных устройствах

Операционные системы, которые сейчас существуют дают возможность применять многопоточный метод работы приложений [11,12,17, 19,21,22]. Этого добиваются за счет того, что делят время работы процессора между различными приложениями, что дает возможность множеству программ функционировать одновременно. Процессорное время устройства можно поделить на отрезки. В каждый отрезок времени отдельное приложение получит по часть времени для работы в процессоре для собственных потребностей. Количество занятого временного интервала выбирается в соответствии с приоритетом приложения в ОС. Для более важных приложений и интервал использования времени процессора больше. Приложение может и не пользоваться процессором, это случается, если приложение стоит в режиме ожидании. Если у приложения большое количество потоков, то оно получит больше времени обслуживания в процессоре. Данная схема организации процессора очень выгодна для системы мониторинга. Выигрыш во времени получается из-за того, что временные периоды в течении которых опрашиваются оконечные устройства могут не занимать ресурсов процессора. В основном это время ожидания информации от оконечных устройств. Если занять эти периоды ожидания для использования другими протоколами, то возможно выиграть во времени и занять процессорные мощности другими задачами. Этим и обусловлен выигрыш во времени.

Математическая модель для мониторинга систем с пакетной обработкой данных

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

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

Рис. 18. Обработка с помощью пакетного алгоритма.

Если выполнить это требование, то это есть система M/G/1 с обработкой в порядке зачисления [15, 20]. Кроме всего этого, параметры обработки, которые не принимают в расчет времени обработки процессором при установлении последовательности обслуживания, приводит к тому же размещению числа запросов в системе.

И получаем что время отклика является суммой времени ожидания M/G/1 и времени обработки.

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

Математическая модель метода кругового опроса

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

Рис. 19. Модель кругового опроса

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

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

Если на вход системы поступит k запросов, то каждый получит на обработку 1/k общего времени. Отсюда и проистекает определение "разделение ресурса" потому что все запросы делят пропускную способность на равные части.

Этот метод также вписываются в параметры, характеризующие M/G/1 с обработкой по моменту поступления [13].

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

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

В существующих сетях период ожидания ответа на запрос может быть больше в несколько раз чем время обработки процессором запроса [15]. Использование периода ожидания ответа на запрос для обслуживания уже пришедшего ответа можно значительно сократить время мониторинга и как следствие увеличить вероятность предоставления актуальных данных.

4.2 Выбор основных формул для опрашивания оконечных устройств в сети при мониторинге параметров

Обоснование выбора формулы для установления оптимального количества потоков

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

Повышение числа параллельно опрашиваемых устройств по началу увеличивает производительность обработки, но после формирования n+1 потока скорость обработки уменьшается. Это обосновывается конечным числом вычислительных мощностей.

Занятость центрального процессора (CPU), оперативная память (RAM) и поступающий трафик сети оказывает влияние на производительность системы [14,16,18].

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

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

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

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

Из всего сказанного выше получим такое соотношение для нахождения нужного количества потоков, добавляемых в мониторинг:

, где

- средняя продолжительность потока;

- средняя продолжительность занятия ресурсом центрального процессора.

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

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

Представим в виде соотношения вышесказанное:

, где

- средняя продолжительность потока;

- средняя продолжительность занятия потоком ресурса центрального процессора;

- Параметр, указывающий на сколько процессор загружен работой (0<P<1).

Эта пропорция дает возможность установить сколько потоков можно еще добавить в систему мониторинга.

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

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

Отправка данных возникает только если поток готов исполнению. А это случается далеко не на каждом цикле потоке управления.

Выше предложенное соотношение не используется, когда все потоки не умещаются в ОП. Для подобного случая лучше использовать такую формулу:

, где

- средняя продолжительность потока;

- средняя продолжительность занятия потоком ресурса центрального процессора;

- Параметр, указывающий на сколько процессор загружен работой (0<P<1).

- время отправки данных из ОП в файл и обратно (полный цикл - это отправка в ОП перед началом использования и выгрузка из памяти при завершении);

М - количество перезагрузок за время опроса единственного устройства.

M можно достаточно просто определить. Перегрузка возникнет только если поток обрабатывается, а не в состоянии ожидания. Поэтому формула для М примет вид:

, где

- средняя продолжительность занятия потоком ресурса центрального процессора;

- время, в течении которого потоку дан доступ к процессорным мощностям, при трансляции ему управления в течение итерации.

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

Связывая всё вышеперечисленное в одну задачу получим, что:

когда ОП частично свободна

, если ОП переполнена

Еще одним условием для соотношений является ограничение в максимальном возможном сетевом трафике, формируемого системой мониторинга.

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

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

Рассмотрение схемы проведения опроса сети, оптимизированной по времени

Ранее были представлены важные части опроса сети: способ опроса удаленного устройства и модель выбора числа потоков на основе эффективности работы системы.

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

Центральную идея этой модели можно свести к нескольким пунктам:

Найти количество потоков, совершающих опрос;

Деление найденного диапазона на n (n - количество потоков);

В каждом из потоков опросить все рабочие станции одну за другой.

Финалом опроса будет являться время окончания последнего потока.

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

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

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

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

Пусть схема будет такой:

Установим необходимое количество потоков в настоящий момент;

Отправляем на выполнение n-потоков, которые опрашивают n IP-адресов диапазона;

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

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

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

Рис. 20. Графическое представление классической многопоточной реализации мониторинга.

Как видно из этой схемы, мониторинг происходит далеко не оптимально. Время работы системы мониторинга равно времени работы максимального по длительности потока. В предложенной схеме изначально было запущено четыре потока. Далее, распределив адреса на 4 группы, в каждой группе происходит обычный последовательный опрос. А разница во времени между самой "быстрой" группой (нет ни одного активного IР - адреса) и самой "медленной пачкой" (все IР-адреса доступны и могут быть опрошены) может отличаться в сотни раз.

Графическое представление оптимизированной по времени многопоточной модели представлено на рис.21:

Рис. 21. Оптимизированная по времени многопоточная модель мониторинга

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

Когда второй поток заканчивается то лучшее число потоков осталось равным трём, поэтому система создала только 1 поток. А вот после завершения третьего потока, их оптимальное число стало равно 5. Поэтому сразу создается 3 новых потока, и т.д. Становится понятно, что во второй модели нет простоев системы и она оптимизирована по времени. Из графического представления заметно, что в различные интервалы времени в системе применяется различное число потоков.

4.3 Рассмотрение алгоритма проведения опроса удаленных станций

Рассмотрение алгоритма, оптимизированного по времени для мониторинга рабочих устройств

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

Чтобы определить эти принципы, нужно проанализировать те функции, которые возложены на систему.

В нашем случае требуется получить информацию об удалённой станции. Вначале эта задача является простой, но при доскональном анализе возникают несколько препятствий.

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

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

Подпонятием нарушением целостности информации имеется ввиду потеря некоторого количества данных о удаленном устройстве. К примеру, данные об ПО были приняты, а о логических дисках или аппаратных средствах - нет.

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

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

Этот принцип есть добавочное условие для решения поставленной задачи мониторинга.

На рис. 22. представлена блок-схема одной из возможных реализаций этой модели.

Рис. 22. Структура алгоритма для контроля длительности опроса рабочей станции

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

Исследование алгоритма для отсева устройств, при невозможности выполнения опроса устройства для системы мониторинга

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

Самым подходящим методом выбора оконечных устройств является диапазонный способ. Сущность метода заключается в том, что происходит опрос всех IР - адресов в некотором диапазоне. IР-адреса в сети могут быть сгруппированы по местоположению в некоторые логические. К примеру, устройствам, находящимся на одном этаже, могут присваиваться адреса с 192.168.1.2 до 192.168.1.30. Этот способ присвоения IР-адресов часто применяется в предприятиях на территории РФ.

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

Чтобы уменьшить общее время опроса всего диапазона, требуется выполнить две проверки, до запуска опроса определенного устройства. Во-первых, проверить активность IР-адреса устройства и во-вторых проверить запущен ли клиентский агент на устройстве.

Алгоритм проверки включенности компьютера и агента представлен в виде структурной схемы (рис. 23)

Рис. 23. Схема алгоритма проверки работоспособности компьютера и агента перед проведением основного мониторинга

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

Исследование многопоточного алгоритма для опроса устройств в системе мониторинга

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

Рис. 24. Общий вид алгоритма опроса сети.

Этот алгоритм дает возможность выполнить все описанные выше этапы опроса сети.

4.4 Исследование характеристик коммутатора 2-го уровня

Коммутатор управляет кадрами на интерфейсе при помощи такого механизма как управление перегрузками (congestion management). На интерфейсах возникают очереди, и они возможны двух видов: аппаратные и программные. Аппаратные очереди практически всегда реализованы на логике FIFO. Программная же очередь более разнообразна по методам обработки кадров. Программные средства управления очередями:

· WFQ (Weighted Fair Queuing) - происходит разделение трафика на потоки на основе таких характеристик как: адрес назначения, адрес источника, версии протокола, что помогает поддерживать полосу пропускания и уровень задержки.

· CBWFQ (Class-Based Weighted Fair Queuing) - усовершенствованная версия WFQ. Главная особенность в том, что можно задать собственный класс трафика.

· LLQ (Low Latency Queuing) - очередь с уменьшенной задержкой. По сути это модель CBWFQ с приоритетной очередью.

· И множество других методов обработки очередей (Priority queuing (PQ) Custom queuing (CQ), Weighted Random Early Detection (WRED), Modified Deficit Round-Robin (MDRR))

Выбор метода обслуживания входящих кадров

На рисунке 25 представлена стандартная схема с коммутацией кадров, состоящая из коммутирующего устройства (Switch), который соединен с 3-мя устройствами генерирующие трафик и с 3-мя получателями, соединенные с выходными портами. Главное, что необходимо знать это то что коммутаторы 2-го уровня, используемые в сетях с коммутацией кадров, имеют для кратковременного сохранения кадров внутри определенное количество буферной памяти. Линия связи не резервируется и кадры передаются без заявленной заранее скоростью.

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

Контрольная сумма сверяется на коммутационном устройстве и если она совпадает с фактическим значением, то это означает что информация в кадре не искажена и коммутатор принимается обрабатывать заголовок кадра и устанавливает путь назначения. Из-за этого во входной буфер записывается каждый кадр. Поэтому сеть с коммутацией кадров применяет методику с промежуточным хранением (store-and-forward) [23].

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

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

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

У коммутаторов одним из важнейших параметров остается задержка. Задержка - это интервал времени с момента появления кадра на входящем интерфейсе до его прихода на исходящий интерфейс. Задержка сумма времени необходимого на выполнение определенных действий с кадром: сканирования адресной таблицы (например, MAC таблицы), выбор дальнейшей судьбы кадра - отбрасывание или передача на нужный интерфейс. Основная задача следующей работы - это определить величину задержки прохождения кадров в коммутационном устройстве при изменении вместимости буферной памяти и длины самого кадра. И это исследование проводится для двух основных методов обработки кадров LIFO и FIFO.

Моделирование коммутатора второго уровня с методом обслуживания FIFO

Чтобы сделать пример по методу FIFO был симулирован коммутатор в среде SimEvents. Read timer и Start timer отдельные блоки, помогающие замерять интервал прохождения кадра со входящего интерфейса до исходящего интерфейса.

Рис. 25 - Схема коммутатор с FIFO обработкой

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

· FIFO First In First Out (первый пришёл - первый ушёл), является буфером входящего интерфейса;

· Subsystem - система вырабатывания кадров;

· Read Timer, устанавливает время окончания нахождения кадра во входящем буфере коммутатора;

· Start Timer, отмеряет первоначальное время прихода кадра на исходящем интерфейсе.

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

Коммутирующее устройство изображено парой блоков: Path Combiner, Output Switch. Задачи матрицы коммутации реализовывает Path Combiner. Output Switch отправляет кадры принимающим устройствам, подключенным к его исходящим интерфейсам.

В коммутаторе выявлялись задержки с методом обработки кадров FIFO для Fast Ethernet сети. Было рассмотрено множество кадров с длиной от 100 до 1500 байт с шагом 200.

Таблица 4.

Графическое представление результатов исследования (рис. 26)

Рис. 26 - Время продвижения кадра во входящем буфере

Таблица 5

Общее время прохождения кадра в коммутаторе с FIFO обслуживанием

Графическое представление результатов исследования (рис. 27)

Рис. 27 - Время продвижения кадра во входящем буфере

Моделирование коммутатора второго уровня с методом обслуживания LIFO

Второе исследование реализовывалось с методом обработки LIFO - обрабатывается последний из пришедшего в очередь кадр.

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

Другими словами, задержка случается по причине того, что другой кадр уже обрабатывается в коммутаторе.

В существующую модель (рис. 25) были привнесены небольшие модификации.

Было использовано буферное устройство с методом обработки кадров LIFO. Полученная модель коммутатора второго уровня показана на рисунке 28.

Рис. 28 - Коммутатор с методом обработки кадров Last In, First Out

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

Таблица 6.

Суммарная задержка нахождения кадров в коммутационном устройстве представлена в таблице 7.

Графическое представление результатов моделирования:

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

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

Выводы

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

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

· в зависимости от длины кадра и размера буферной памяти при применении метода обработки очереди FIFO время задержки может колебаться от 9.78 до 2491.64 нс.

· метод обработки очереди LIFO обеспечивает в разы меньшее время нахождения кадров во входящем буфере: от 6.58 до 146.71 нс;

· время нахождения кадра в коммутаторе для метода обработки LIFO ограничивается значениями 7.01 - 4.97 нс;

· для метода FIFO время нахождения кадра в коммутаторе имеет большее значение от 11.73 до 200 нс.

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

· определена условия, при которых эффективность метода повышается;

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

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

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

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

Заключение

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

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

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

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

4. Исследован способ обработки и сбора информации для многопоточных приложений.

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

6. Проведено исследование с помощью разработанной имитационной модели коммутатора второго уровня, в результате которого получены времена обработки пакетов мониторинга на коммутаторе для методов обработки очередей FIFO и LIFO.

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

Планируется продолжить исследования для методов LLQ и CBWFQ обслуживания очередей, которые широко используются в современном сетевом оборудовании компаний Cisco, Juniper, Huawei.

Литература

1. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов.4-е изд. - СПб.: Питер - 2010

2. Бондаренко, А.Д. Безопасность протокола SNMPv3/А.Д. Бондаренко // Журнал BYTE - 2006. - №2. - С.74-76

3. Бекман Д. Стандарт SNMPV3 // Сети и системы связи, 2008. - №12 - С.50

4. Городецкий, В. Самойлов, А. Малов. Технология обработки данных для извлечения знаний: Обзор состояния исследований. Новости искусственного интеллекта, № 3-4, 2002. - С.3-12.

5. Крылов, C. B. Мониторинг и управление территориально-распределенными системами через World Wide Web: Дис. канд. техн. наук: 05.13.01 Н. Новгород, 1999 241 с.

6. Олифер, В.Г., Олифер Н.А. Управление неоднородными сетями [Электронный ресурс] / Электрон, дан. - . - Режим доступа: http://www.citforum.ru/nets/tpns/glava_l6. shtml, свободный.

7. Леохин Ю.Л. Корпоративные сети: архитектура, технологии, управление. - М.: Фонд "Качество", 2009, 173 стр

8. Stallings, W. SNMP, SNMPv2 and RMON: Practical Network Management / W. Stallings - Readong, MA: Addison-Wesley, 1996

9. Vandenberg Chr. MIB-II extends SNMP Interoperability / Chr. Vandenberg. - Datapro Research Corporation, McGraw-Hill, October 1990. - 119-124 p.

10. Басс Л. Архитектура программного обеспечения на практике: пер. с англ. / Л. Басс, П. Клементс, Р. Кацман. - 2-е изд. - СПб.: Питер, 2006. - 575 с

11. Кларк Д. Объектно-ориентированное программирование в Visual Basic.net.: Перевод с английского. Санкт-Петербург: Питер, 2003

12. Клейнрок, Л. Вычислительные системы с очередями / Л. Клейнрок; пер. с англ, под ред.В.С. Цыбакова. - М.: Мир, 1979. - 600 с.

13. Константайн Л. Разработка программного обеспечения. Санкт-Петербург: Питер, 2003

14. Безкоровайный М.М., Костогрызов А.И., Львов В.М. Инструментально-моделирующий комплекс для оценки качества функционирования информационных систем. М. Изд. "Вооружение, политика, конверсия", 2001, 303с

15. Кровчик Э.net. Сетевое программирование для профессионалов/ Кровчик Э., Кумар В., Лагари Н., Москва: ЛОРИ, 2014

16. МагдаЮ. Ассемблер: Разработка и оптимизация Windows-приложений. Санкт - Петербург: БХВ-Петербург, 2006

17. Craig Hunt. Windows Server 2003 Network Administration/ Craig Hunt, Roberta Bragg // O'Reilly Media, 2005

18. Гарбер Г.3. Основы программирования на Visual Basic и VBA в Excel / Гарбер Г.3. ­ Москва: СОЛОН­ПРЕСС, 2008. ­ 191 с

19. Бочаров П.П., Печинкин А.В. Теория массового обслуживания, Изд-во РУДН, 1995. - 529 с