Содержание к диссертации
Введение
1. Проблемы мониторинга локальных сетей 7
1.1. Системы мониторинга параметров и конфигурации локальной сети 7
1.1.1. Необходимость мониторинга 7
1.1.2. Способы проведения опроса рабочих станций в локальной сети 8
1.1.3.Способы анализа информации, собранной при опросе рабочих станций //
1.1.4.Методы проведения мониторинга в локальной сети 13
1.1.5. Эффективность функционирования систем мониторинга 14
1.2. Функциональные схемы систем мониторинга 15
1.2.1. Схема менеджер - агент 15
1.2.2. Схемы распределенных систем мониторинга 19
1.2.3. Платформенный подход 23
1.3. Программная реализация систем мониторинга в локальной сети 25
1.3.1. Однопоточные реализации 25
1.3.2. Миогопоточные реализации 25
1.3.3. Сравнение реализаций по основным параметрам 28
1.4. Постановка задачи диссертационного исследования 30
1.5. Выводы 32
2. Математические модели и алгоритмы мониторинга онфигурации рабочих станций 34
2.1. Разработка математической модели системы мониторинга 34
2.1.1 .Основные математические модели для анализа и оптимизации распределённых омпьютерных систем 34
2.1.2. Модель сбора информации при минимизации времени ожидания ответа от источника и оценка эффективности её применения в системах мониторинга 36
2.1.3. Способы реализации многопоточной модели на современных однопроцессорных серверах 38
2.1.4. Математическая модель использующегося в системах мониторинга метода пакетной обработки 38
2.1.5. Математическая модель метода кругового опроса 40
2.2. Разработка основных соотношений для опроса рабочих станций в сети при мониторинге параметров 41
2.2.1. Разработка соотношения для определения оптимального числа потоков 41
2.2.2. Разработка оптимизированной по времени схемы проведения опроса сети 46
2.3. Алгоритм проведения мониторинга рабочих станций 50
2.3.1. Разработка оптимизированного по времени алгоритма для опроса рабочих станций .,50
2.3.2. Разработка алгоритма отсева рабочих станций, опрос которых невозможен при проведения мониторинга в локальной сети 53
2.3.3. Разработка многопоточного алгоритма опроса рабочих станций для мониторинга в локальной сети 55
2.4. Моделирование различных реализаций системы мониторинга и их сравнение между собой 56
2.4.1. Исходные данные 56
2.4.2. Анализ результатов моделирования для различных сетей 58
2.5. ВЫВОДЫ 61
3. Программная реализация системы мониторинга конфигураций рабочих станций в локальной сети 63
3.1. Система управления сетевой инфраструктурой инфраменеджер 4.0 63
3.1.1. Описание системы 63
3.1.2. Структура модулей системы 65
3.1.3. Структура базы данных системы 69
3.1.4. Программные интерфейсы системы 70
3.2. Разработка архитектуры системы мониторинга в рамках системы инфраменеджер 72
3.3. Программная реализация системы мониторинга рабочих станций в среде microsoft visualstudio.net 74
3.3.1. Реализация алгоритма мониторинга рабочих станций 74
3.3.2. Реализация пользовательского интерфейса 77
3.3.3. Реализация справочной системы мониторинга 82
3.4. Альтернативное применение алгоритма опроса сети для call-центров крупных компаний 84
3.5. Выводы 87
4. Анализ полученных результатов 88
4.1. Результаты опроса малой сети (36шт) (УЗСМ) 88
4.2. Результаты опроса крупной сети (453 шт)(Медный Завод) 89
4.3. Оценка вероятности сохранения актуальности данных для систем мониторинга построенных на классическом и разработанном алгоритмах 90
4.4. Выводы 91
Заключение 92
- Схемы распределенных систем мониторинга
- Модель сбора информации при минимизации времени ожидания ответа от источника и оценка эффективности её применения в системах мониторинга
- Разработка многопоточного алгоритма опроса рабочих станций для мониторинга в локальной сети
- Программная реализация системы мониторинга рабочих станций в среде microsoft visualstudio.net
Введение к работе
Актуальность. Бурный рост компьютерных сетей приводит к частым сбоям в их работоспособности. Поэтому необходимо улучшать существующие способы контроля за функционированием локальных вычислительных сетей.
Особо остро стоит эта задача, когда первоначально при проектировании сети были заложены меньшие размеры и нагрузки. Данная ситуация приводит к невозможности пользователей получить своевременный доступ к необходимой информации.
Помимо этого необходимость мониторинга возникает, когда в рамках одной сети объединяется несколько подсетей, изначально спроектированных для решения различных задач. В этом случае в сети увеличивается объём трафика, а также возрастает нагрузка на серверы приложений и особенно сильно - на серверы доменов.
Всё вышесказанное подчёркивает особую актуальность решения задачи постоянного контроля за функционированием сети для гарантированной (предсказуемой) работы сети в целом и доступности для пользователей её компонент. Подобный контроль обеспечивает сохранение целостности и доступности данных, помогает предотвратить несанкционированный доступ к ним.
Несмотря на актуальность создания систем контроля за функционированием сети, проведённый анализ [7,12,27,35,51,72] показывает следующее недостатки современных программных средств:
Быстрый рост сети приводит к тому, что контроль над сетью уменьшается и выходит за рамки изначально заложенных параметров, в том числе и по максимальному времени обнаружения ошибки. Это вызвано увеличением интервалов между опросами сетевого или оконечного оборудования.
Предлагаемые пользователям стандартные решения, как правило, плохо адаптируются к различным сетям и не оптимально используют свободные ресурсы. Помимо этого, существующие системы мониторинга очень часто задействуют именно те ресурсы,
которые уже задействованы в данный момент времени другими приложениями. Научная новизна работы. Автором получены следующие новые научные результаты, которые выносятся на защиту.
Предложен новый подход к проведению мониторинга в локальной сети, позволяющий использовать время ожидания ответа от оконечного или сетевого устройства для обработки ранее полученной информации.
Предложены методы «быстрого отсева» рабочих станций, предотвращения «зависания», а также метод определения оптимального числа потоков в каждый момент времени для системы мониторинга, позволяющие сократить время опроса сети.
Предложен метод динамического многопоточного сбора и обработки информации.
Разработаны алгоритмы для многопоточной реализации мониторинга в локальной сети, позволяющие уменьшить время опроса рабочих станций по отношению к «классической реализации».
Практическая ценность работы. Использование полученных в диссертации моделей, методов и алгоритмов для систем мониторинга позволяет ускорить опрос рабочих станций, и, следовательно, увеличить вероятность достоверного предоставления данных системой о сети. Они легли в основу модуля мониторинга, входящую в состав программного комплекса «ИнфраМенеджер», разработанного компанией «СофтИнтегро» и зарегистрированного Российским агентством по патентам и товарным знакам, что подтверждается соответствующим актом о внедрении. Эксплуатация программного комплекса в крупной локальной сети заполярного филиала ОАО «Норильский Никель» выявила выигрыш во времени опроса и обработки полученных данных более чем на 20% по отношению к «классической» реализации, использовавшейся в системе ранее. Это привело к увеличению вероятности актуальности хранимых в системе данных о сети с 92% до 95,5%.
Также разработанный алгоритм опроса сети был использован для оптимизации работы Call-Center при одновременном приеме звонков и обзвоне клиентов.
Достоверность результатов. Достоверность полученных в работе результатов обуславливается используемыми моделями массового обслуживания, а также совпадением результатов моделирования предложенных алгоритмов в системе GPSS WORLD и полученных данных в результате испытания системы мониторинга.
Апробация работы. По теме диссертации опубликовано 10 научных работ, в том числе 2 в реферируемых журналах, рекомендуемых ВАК для публикаций результатов диссертаций. Результаты диссертационного исследования докладывались на научной конференции МИФИ и в Алуште.
Схемы распределенных систем мониторинга
В крупной корпоративной сети полностью централизованная система мониторинга, построенная на базе единственного менеджера, вряд ли будет работать хорошо по нескольким причинам. Во-первых, такой вариант не обеспечивает необходимой масштабируемости по производительности, так как единственный менеджер вынужден будет обрабатывать весь поток сообщений от всех агентов, что при нескольких тысячах управляемых объектов потребует очень высокопроизводительной платформы для работы менеджера и перегрузит служебной управляющей информацией каналы передачи данных в той сети, где будет расположен менеджер. Во-вторых, такое решение не обеспечит необходимого уровня надежности, так как при отказе единственного менеджера будет потеряно управление сетью.
Схема «менеджер - агент» позволяет строить достаточно сложные в структурном отношении распределенные системы мониторинга.
Обычно распределенная система мониторинга включает большое количество связок менеджер - агент, которые дополняются рабочими станциями операторов сети, с помощью которых они получают доступ к менеджерам [51,52]. Данная схема представлена на рис. 1.2. Каждый агент собирает данные и управляет определенным элементом сети. Менеджеры, иногда также называемые серверами системы мониторинга, собирают данные от своих агентов, обобщают их и хранят в базе данных. Операторы, работающие за рабочими станциями, могут соединиться с любым из менеджеров и с помощью графического интерфейса просмотреть данные об управляемой сети, а также выдать менеджеру некоторые директивы по управлению сетью или ее элементами [78].
Наличие нескольких менеджеров позволяет распределить между ними нагрузку по обработке данных управления, обеспечивая масштабируемость системы. Как правило, связи между агентами и менеджерами носят более упорядоченный характер, чем тот, который показан на рис. 1.2. Чаще всего используются два подхода к их соединению — одноранговый, представленный на рис. 1.3. и иерархический, представленный на рис. 1.4. [51]
В случае одноранговых связей каждый менеджер управляет своей частью сети на основе информации, получаемой от нижележащих агентов. Центральный менеджер отсутствует. Координация работы менеджеров достигается за счет обмена информацией между базами данных каждого менеджера.
Одноранговое построение системы мониторинга сегодня считается неэффективным и устаревшим. Обычно оно вызвано тем обстоятельством, что элементарные системы мониторинга построены как монолитные системы, которые первоначально не были ориентированы на модульность системы (например, многие системы мониторинга, разработанные производителями оборудования, не поддерживают стандартные интерфейсы для взаимодействия с другими системами мониторинга). Затем эти менеджеры нижнего уровня стали объединяться для создания интегрированной системы мониторинга сетью, но связи между ними оказалось возможным создавать только на уровне обмена между базами данных, что достаточно медленно. Кроме того, в базах данных таких менеджеров накапливается слишком детальная информация об управляемых элементах сети (так как первоначально эти менеджеры разрабатывались как менеджеры нижнего уровня), вследствие чего такая информация малопригодна для координации работы всей сети в целом. Такой подход к построению системы мониторинга называется подходом «снизу вверх».
Гораздо более гибким является иерархическое построение связей между менеджерами. Каждый менеджер нижнего уровня выполняет также функции агента для менеджера верхнего уровня. Такой агент работает уже с гораздо более укрупненной моделью своей части сети, в которой собирается именно та информация, которая нужна менеджеру верхнего уровня для управления сетью в целом. Обычно для разработки моделей сети на разных уровнях проектирование начинают с верхнего уровня, на котором определяется состав информации, требуемой от менеджеров-агентов более низкого уровня, поэтому такой подход назван подходом «сверху вниз». Он сокращает объемы информации, циркулирующей между уровнями системы мониторинга, и приводит к гораздо более эффективной системе мониторинга.
При построении систем мониторинга в крупных локальных и корпоративных сетях обычно используется платформенный подход, когда индивидуальные программы мониторинга разрабатываются не «с нуля», а используют службы и примитивы, предоставляемые специально разработанным для этих целей программным продуктом — платформой. Примерами платформ для систем мониторинга являются такие известные продукты, как HP OpenView, SunNet Manager и Sun Soltice, Cabletron Spectrum, IMB/Tivoli TMN10. [7,16,17,46]
Эти платформы создают общую операционную среду для приложений системы мониторинга точно так же, как универсальные операционные системы, такие как Unix или Windows NT создают операционную среду для приложений любого типа, таких как MS Word, Oracle и т. п. Платформа обычно включает поддержку протоколов взаимодействия менеджера с агентами — SNMP и WMI, набор базовых средств для построения менеджеров и агентов, а также средства графического интерфейса для создания консоли управления. В набор базовых средств обычно входят функции, необходимые для построения карты сети, средства фильтрации сообщений от агентов, средства ведения базы данных. Набор интерфейсных функций платформы образует интерфейс прикладного программирования системы управления. Пользуясь этим интерфейсом, разработчики из третьих фирм создают законченные системы управления, которые могут управлять специфическим оборудованием.
Обычно платформа управления поставляется с каким-либо универсальным менеджером, который может выполнять некоторые базовые функции управления без программирования. Чаще всего к этим функциям относятся функции построения карты сети (группа Configuration Management), а также функции отображения состояния управляемых устройств и функции фильтрации сообщений об ошибках (группа Fault Management). Например, одна из наиболее популярных платформ HP OpenView поставляется с менеджером Network Node Manager, который выполняет перечисленные функции.
Чем больше функций выполняет платформа, тем лучше. В том числе и таких, которые нужны для разработки любых аспектов работы приложений, прямо не связанных со спецификой управления. В конце концов, приложения системы мониторинга — это прежде всего приложения, а потом уже приложения системы мониторинга. Поэтому полезны любые средства, предоставляемые платформой, которые ускоряют разработку приложений вообще и распределенных приложений в частности.
Модель сбора информации при минимизации времени ожидания ответа от источника и оценка эффективности её применения в системах мониторинга
На основании вышесказанного и с учётом того, что опрос будет
происходить непрерывно, была сделана оценка вероятности сохранения актуальности информации для сети заполярного филиала ОАО «Норильский никель». Были получены следующие результаты:
Среднее время изменения одного наблюдаемого параметра в сети - 24 часа;
Среднее время подготовки запроса, ожидания ответа и обработки полученной информации для объекта - 2 минуты; Среднее время между двумя последовательными опросами одного узла-2 часа. Для данных значений вероятность сохранения актуальности информации составляет примерно 92%. Это не самый хороший показатель. Считается, что информация актуальна при показателе в 95%.
Если же использовать модель с идеальными каналами связи, то данный показатель равнялся бы 98%.
На представленном ниже графике (рис. 2.1) видна зависимость вероятности сохранения актуальности данных от отношения времени ожидания ответа к времени обработки данных.
Из графика видно, что даже незначительное сокращение времени ожидания данных может привести к существенному увеличению вероятности сохранения актуальности данных, если время ожидания примерно равно времени обработки. Можно сделать вывод, что для сетей, у которых при работе системы мониторинга время обработки информации примерно равно времени ожидания после запроса, есть возможность существенно повысить актуальность информации при использовании алгоритмов, позволяющих использовать время простоя для обработки информации. 2.1.3. Способы реализации многопоточной модели на
современных однопроцессорных серверах
Современные операционные системы позволяют использовать многопоточную схему работы приложений [3,29,37,59,77,88]. Это достигается за счёт распределения рабочего времени процессора между разными приложениями. Это позволяет нескольким программам работать «одновременно».
Всё процессорное время персонального компьютера (сервера) можно разделить на периоды. В один такой период все приложения получают по «кусочку» процессорного времени для своих нужд. Их размеры зависят от приоритетов приложений в операционной системе. Чем выше приоритет -тем длительней временной интервал, в котором приложение использует процессор. В рамках данного интервала приложение также может и не использовать процессор (находится в состоянии ожидания). Чем больше потоков «внутри» приложения, тем больше приложение в целом получает этого процессорного времени. Для сложных математических задач введения механизма параллельного расчета бесполезно, т.к. время работы приложения примерно равно времени процессора для расчета задачи. Для задач мониторинга данная схема, напротив, является довольно выгодной. Она позволяет получить выигрыш по времени за счёт того, что в процессе опроса рабочей станции имеются временные интервалы, в которых не используются ресурсы процессора, памяти, сети. Это интервалы ожидания ответа от удалённой рабочей станции. Тем самым, если использовать эти интервалы для работы других потоков, то можно будет уменьшить время «простоя» процессора. За счёт этого происходит оптимизация по времени.
Пусть все вновь поступающие требования выстраиваются в единую очередь перед обслуживающим прибором (ресурсом). Предположим, что обслуживание происходит в порядке поступления и вновь поступающее требование становится в хвост единственной очереди. Прибор (ресурс) всегда выбирает для обслуживания требование, стоящее в голове очереди, и предоставляет ему один квант времени обслуживания.
Простейший способ свести этот случай к классической системе с обслуживанием в порядке поступления — это предположить, что квант бесконечно малый (случай разделения процессора). В этом случае необходимо ввести дополнительное ограничение, что требования удаляются из обслуживающего прибора вследствие окончания их квантов и поступают обратно прямо в голову единственной очереди, в результате чего сразу же вновь поступают на обслуживание (рис 2.2).
При выполнении данного требования придем к системе M/G/1 с обслуживанием в порядке поступления [33,74]. Кроме того, все дисциплины обслуживания, которые не учитывают времени обслуживания при определении порядка обслуживания, приводят к такому же распределению числа требований в системе [30].
Таким образом, среднее время ответа должно быть суммой заданного времени обслуживания и среднего времени ожидания в системе M/G/1.
Необходимо отметить, что пакетная обработка не делает никакой дискриминации заданий на основе требуемого ими времени обслуживания. Это означает, что среднее время ожидания не зависит от времени обслуживания, и система осуществляет наименьшую возможную дискриминацию требований. Очевидно, это плохой кандидат для обслуживающей системы, когда требуется найти способ сокращения времени ответа для коротких заданий.
Разработка многопоточного алгоритма опроса рабочих станций для мониторинга в локальной сети
Сначала необходимо определиться, как формировать список опрашиваемых рабочих станций. На сегодняшний день эта задача не имеет единого подхода к её решению. В ранних системах мониторинга предлагалось вручную выбирать из списка всех доступных рабочих станций те, для которых надо провести мониторинг. Но в современных условиях такая задача может вызвать большие трудности, ведь одна локальная сеть может содержать сотни и даже тысячи компьютеров.
Наиболее удобным способом для выбора рабочих станций является диапазонный метод. Суть его состоит в том, что опрашиваются все IP-адреса в диапазоне от некого начального адреса до конечного. По требованиям к распределению ІР-адресов в сети они должны быть сгруппированы в некие логические группы по территориальному признаку. Например, компьютерам, находящимся в распоряжении отдела логистики, могут быть присвоены адреса с 123.123.123.10 до 123.123.123.30. Данный способ распределения ІР-адресов широко используется в крупных Российских предприятиях.
Но у данного подхода существуют несколько серьёзных недостатков. Одним из них является то, что в указанном диапазоне могут быть выключенные компьютеры. Это приводит к тому, что на обработку таких адресов уходит весь временной интервал, отведённый на опрос одной рабочей станции, а получить необходимую информацию не удаётся.
Такая же ситуация наблюдается, если компьютер включён, но на нём не установлен или не запущен необходимый агент. Такая же ситуация будет, если данный адрес соответствует какое-нибудь сетевое устройство. Для того чтобы сократить суммарное время опроса диапазона, необходимо ввести две проверки, прежде чем запускать опрос конкретной станции. Это проверка на активность ІР-адреса и проверка запущенности агентов.
Структурная схема алгоритма для проведения предварительной проверки возможности проведения мониторинга
Как видно из схемы, в случае невозможности провести опрос рабочей станции он даже не будет запускаться. Такая схема оправдана, т.к. время проверки возможности опроса пренебрежимо мало по сравнению с опросом.
Как было определено ранее, алгоритм опроса сети состоит из нескольких основных блоков. К таким блокам можно отнести опрос удалённого компьютера и проверку возможности опроса компьютера. Эти элементы были описаны выше, поэтому в структурной схеме, представленной на рис. 2.8., которая иллюстрирует алгоритм опроса сети в целом, представлены в виде одного действия, не раскрывая логики данного процесса.
Для того, чтобы провести моделирование описанных выше
реализаций (включая разработанную в рамках диссертационного исследования), необходимо было определить параметры сети, на которой могут (будут) применяться системы мониторинга с описанными (и возможно разработанным) алгоритмами опроса сети.
Для этих целей была выбрана сеть заполярного филиала ОАО «Норильский никель». Там были получены данные, на основании которых были выведены следующие базовые значения:
Среднее число потоков для опроса сети равно четырём. Критерием для определения этого значения служило условие о недопустимости перегрузки аппаратных средств сети, а также серверов, на которых на предприятии стоят системы мониторинга.
Среднее время опроса одной рабочей станции составляет 80 секунд. Не считая «зависших» запросов, значения находились в интервале между 40 и 120 секундами
Количество перегрузок процессора или памяти равнялось в среднем шесть за час.
На основании этих данных было произведено моделирование опросов сети для различных размеров в системе GPSS WORLD.
Программная реализация системы мониторинга рабочих станций в среде microsoft visualstudio.net
Разработанная корпорацией Microsoft новая технология Microsoft .NET предоставляет универсальные средства создания программных продуктов, поддерживающих высокую степень совместимости устройств, служб и компьютеров. Та часть технологии Microsoft .NET, которая отвечает за непосредственную разработку таких приложений, называется .NET Framework.
.NET Framework состоит из среды выполнения кода (Common Language Runtime, CLR) и набора библиотек классов .NET Framework (Base Class Library, BCL). Используя аналогию с Java-терминологией, можно сказать, что CLR представляет собой виртуальную машину, в которой функционируют .NET-приложения. CLR, являющаяся ядром технологии Microsoft .NET, это среда выполнения кода, в которой обеспечивается эффективное взаимодействие приложений, созданных на различных .NET-языках. Это взаимодействие обеспечивается набором правил Common Language Specification (CLS). С CLR также связано понятие управляемого кода (managed code), выполняемого только в среде CLR и управляемого ею.
Все языки .NET (Visual C++, Visual С# и Visual Basic) имеют в своем распоряжении библиотеки классов .NET Framework. Эти библиотеки поддерживают различные технологии от файлового ввода/вывода и работы с базами данных до XML и играют чрезвычайно важную роль в обеспечении межъязыкового взаимодействия приложений, т. к. позволяют разработчикам использовать единый программный интерфейс ко всем функциональным средствам CLR, например, при создании консольных приложений, разработке приложений Windows GUI (Windows Forms), ASP.NET
Реализация данного алгоритма не вызвала затруднений. В платформе Framework существуют встроенные функции для создания потоков, а с помощью системных библиотек можно получить все необходимые параметры работы процессора и созданных потоков.
К особенностям реализации можно отнести следующие основные моменты:
Запуск мониторинга сети в фоновом режиме по отношению к работе системы ИнфраМенеджер;
Возможность получать информацию о ходе мониторинга не только с формы настройки мониторинга, но из главного окна системы ИнфраМенеджер;
Создание дополнительного управляющего потока (для контроля времени опроса конкретной станции);
Динамическое изменение параметров мониторинга для достижения оптимального быстродействия.
Первая особенность связана с тем, что процесс мониторинга сети может занять длительное время, на протяжении которого администратор системы ИнфраМенеджер должен иметь возможность работать с программой. При этом, он должен знать, когда закончится мониторинг. Для этого внизу основного окна системы был встроена дополнительная строка состояния, позволяющая определить завершённость опроса, не переключаясь на форму мониторинга. Это окно изображено на рис. Как было описано выше, процесс опроса рабочей станции может «зависнуть». Это происходит когда запрос к ней был сформирован и отправлен, а ответ по какой либо причине не получен. Поэтому был введён лимит времени (настраиваемый пользователем исходя из конкретных характеристик данной сети), по истечении которого происходит остановка процесса, из которого был послан запрос. Интервал определяется из расчета, что он превышает не менее чем в три раза среднее время опроса рабочей станции в обычных условиях. В случае необходимости это значение может быть изменено.
Как было сказано в главе 2, разработанная математическая модель и алгоритм мониторинга позволяют динамически отслеживать состояние системы мониторинга и либо увеличивать количество протоков с системе или, наоборот, уменьшать их. Данная функция была реализована в соответствии с алгоритмом. Особенностью реализации является то, что все константы, необходимые для этого, определяются не с помощью стандартных функций платформы Framework (их там нет), а с помощью системных функций, предоставленных операционной системой.
