Министерство образования Российской Федерации
| Вид материала | Документы |
- Государственная программа Российской Федерации «Доступная среда» на 2011 2015 годы, 1560.95kb.
- Российской Федерации Министерство образования и науки Российской Федерации Государственный, 343.55kb.
- Российской Федерации Министерство общего и профессионального образования Российской, 41.11kb.
- Министерство образования Российской Федерации утверждаю: Заместитель Министра образования, 588.7kb.
- Министерство образования Российской Федерации утверждаю: Заместитель Министра образования, 500.97kb.
- Министерство образования российской федерации утверждаю Заместитель Министра образования, 685.06kb.
- Министерство образования российской федерации утверждаю заместитель Министра образования, 798.02kb.
- Министерство образования российской федерации утверждаю Заместитель Министра образования, 748.49kb.
- Министерство образования российской федерации утверждаю Заместитель Министра образования, 1248.34kb.
- Министерство образования российской федерации утверждаю заместитель Министра образования, 1081.02kb.
1 2
Проблемы выполненияЦель системы мониторинга – это надежно поставить своевременную и точную информацию без излишней нагрузки на систему. Следовательно, архитектура должна рассматривать, только те сервисы, которые не потерпят неудачу. Контроль эксплуатационных характеристик Следующие характеристики отличают эффективность, контролирующую информацию от других системных данных, типа файлов и баз данных. Информация об эффективности имеет фиксированный, часто короткий срок службы полезности. Большинство данных мониторинга могут быстро стать старыми – отсюда важным становится быстрый доступ для их чтения, и устранение потребности в долгосрочном хранении. Исключением являются данные, которые архивируется для учета или анализа статистики отказов. Частое изменение данных. В отличие от более статических форм “метаданных”, динамическая информация эффективности обычно изменяется более часто, чем читается. Информация об эффективности часто стохастическая. Часто невозможно характеризовать эффективность ресурса или прикладного компонента, используя одиночное значение. Поэтому, динамическая информация эффективности может нести определения понятия метрики, продолжительности жизни, и т.д., которые вероятно должны вычисляться из исходных данных. Анимация в реальном масштабе времени. Сбор данных и техника доставки данных должны быть высокоэффективны. Поскольку динамические данные могут включать большое количество информации и могут быстро стать просроченными, то система управления данными должна минимизировать время, связанное с сохранением и поиском. Заметим, что эта потребность дифференцирует проблему динамической организации данных от проблемы обеспечения архива записей об эффективности. Архивные данные полезны, и для объясняющих целей и для длительного анализа тренда. Время измерения должно быть минимизированно. Иначе оно будет влиять на измерение времени запроса и скорость трафика. Общие стратегии реализации
Универсальность Одна из самых больших проблем в определении контролирующей архитектуры для использования в среде GRID - универсальность. Проблема в том, что действие контроля имеет минимальный статус на проверяемых системах. В этой модели, можно прибавлять дополнительных менеджеров и дополнительные директивные серверы, если необходимо, уменьшая плотность загрузки, где необходимо. Также, ресурсы, которые продюсер будет использовать, должны, непосредственно, быть намечены. В частности мы полагаем, что GMA более масштабируемый, чем CORBA Service Events. В GMA, данные не будут посланы куда-нибудь, если это не требуется потребителем. Многие службы, включая CORBA, посылают все данные к центральному компоненту, с которым потребители затем входят в контакт. В GMA, только информация подписки данных будет послан центральному директивному серверу. Данные идут непосредственно от продюсера потребителю. Удаленный мониторинг RMON, или база управляющей информации для удаленного мониторинга (Remote MONitoring MIB). Эта стандартная спецификация обеспечивает во многом те же функциональные возможности, что и нестандартные сетевые и протокольные анализаторы. Архитектура RMON Как и SNMP, инфраструктура RMON опирается на клиент-серверную архитектуру. При этом в роли "клиента" выступает приложение, выполняемое на станции управления сетью, а в роли "сервера" – устройства мониторинга, распределенные по сети и занятые сбором информации. Устройства мониторинга называются "зондами", а выполняемое ими программное обеспечение – "агентами". Агенты RMON могут как размещаться на автономных устройствах, так и встраиваться в концентраторы, коммутаторы, маршрутизаторы и другие сетевые устройства. Станция управления сетью и распределенные зонды RMON взаимодействуют по сети по протоколу SNMP. Стратегия использования Диагностировать проблему после того, как она возникла, может быть проще, чем ее предупредить, но это означает напрасную потерю пользователями рабочего времени. С помощью RMON администратор может реализовать превентивное управление своей сетью, т. е. выявлять проблемы до их возникновения. Ключом к реализации такой стратегии является установление типичной картины трафика и задание порогов для предупреждения об отклонении трафика в сети от стандартных шаблонов. Прежде всего, администратору требуется в течение определенного времени собрать данные относительно производительности и использования сети, на которые он мог бы опираться в качестве исходных. Такими данными могут быть, например, сведения о количестве широковещательных, многоадресных и ошибочных пакетов. Затем полученные значения можно усреднить и найти типичные отклонения от этих значений. Найденные отклонения могут служить в качестве ориентиров для задания порогов. Задание порогов – это целое искусство, и тут администратору может помочь только опыт. Если пороги заданы слишком низкими, то администратор будет получать неоправданно большое количество предупреждений; если же пороги установлены на чересчур высоком уровне, то он может пропустить момент накопления отрицательных тенденций в работе сети. Кроме того, кратковременное отклонение от привычной картины трафика зачастую никак не сказывается на общей работе сети, поэтому задавать пороги следует так, чтобы администратору не приходилось потом отвлекаться на временные самоликвидирующиеся проблемы. Вместе с тем ни одна сеть не является статичной, поэтому картина трафика со временем изменяется. Анализ тенденций с помощью групп History и Statistics позволяет, например, выявить момент, когда сеть перестает справляться с предлагаемой нагрузкой, т. е. когда ее пропускную способность требуется увеличить. Мониторинг коммутируемых сетей В разделяемых локальных сетях каждый сегмент должен иметь свой зонд RMON, если администратор хочет знать о трафике в нем. То же справедливо и для коммутируемых локальных сетей, но в них количество сегментов намного больше. Подключение отдельного автономного зонда к каждому порту коммутатора было бы решением, но очень дорогостоящим. К счастью, это далеко не единственный возможный подход. Одно из решений состоит в подключении к каждому порту коммутатора вместо автономного агента концентратора с его собственным встроенным агентом, тем более что по своим функциональным возможностям он зачастую ничем не отличается. Однако такое решение не всегда осуществимо и целесообразно, в частности иногда порт коммутатора рассчитан на подключение только одной станции или сервера. Многие производители встраивают теперь поддержку удаленного мониторинга непосредственно в свои коммутаторы, но делают это по–разному. Одно из решений состоит в предусмотрении порта для мониторинга на коммутаторе, на который копируется весь трафик с указанного порта. Недостаток такого подхода очевиден – подключенный зонд может следить только за одним портом коммутатора единовременно и не видит общей картины трафика через коммутатор. Другое решение состоит в реализации встроенных агентов на каждом из портов, но при этом производители, как правило, ограничиваются всего несколькими группами RMON. Анализ RMON Подчиняясь требованиям пользователей, администраторы информационных систем устанавливают и поддерживают определенный уровень обслуживания. С помощью RMON2 они могут получить высокоуровневое представление о работе сети. В отличие от оригинальных инструментальных средств RMON, средства RMON2 не ограничиваются анализом потоков информации в одной локальной сети или коммутируемом сегменте. Они позволяют отследить использование всей сети в целом. Анализ применения средств RMON в различных компаниях подтверждает, что чем больше сеть, тем больше можно сократить затраты и число сотрудников. Все это благодаря тому, что операторы центрального узла анализируют ошибки и пакеты трафика в разветвленных локальных сетях. Они могут "включить" агенты RMON, встроенные в концентратор или коммутатор, или послать автономный зонд на конкретный узел. Таким образом компания получает возможность отказаться от работы удаленных сотрудников и сократить затраты на командировки. Анализ, проведенный с помощью RMON2, дает "мгновенный снимок" деятельности пользователей и работы приложений в сети. Администраторам информационных систем больше не нужно гадать, почему трафик вдруг стал слишком напряженным. Они получают карту реальных потоков обмена информацией между клиентами и серверами. Тактическое преимущество, которое администраторы получают благодаря новой технологии, в том, что точное представление о характере деятельности сети может подтвердить или опровергнуть предположения о происходящем. Стратегическое же состоит в возможности получить характеристику трафика для определения уровня услуг. Другой класс продуктов – мониторы уровня обслуживания – дают представление о производительности с точки зрения пользователя. С помощью этого вида анализа операторы информационных систем центрального узла могут определять время реакции, а не только отслеживать данные, доставленные по сетям клиент–сервер. Такие инструментальные средства предупреждают о возможных недоработках в области качества обслуживания. Получив предупреждение, операторы центрального узла начинают анализировать трафик сегмента и всей сети с помощью инструментария RMON и RMON2 для поиска и устранения неисправностей и оптимизации производительности. Производители предлагают расширить определенные RMON2 группы данных так, чтобы можно было измерять потоки приложений между контрольными точками. Затем централизованное контролирующее программное обеспечение сможет определить ту часть времени реакции, которая приходится на сеть, и отключить выдачу предупреждений – будем надеяться, еще до того, как пользователи позвонят и пожалуются на низкую производительность. Опасности, подстерегающие пользователей RMON2 Перегрузка устройств Большинство устройств межсетевых взаимодействий поставляются со встроенными возможностями RMON, но контроль загрузки и трафика приложений требует большой процессорной мощности и памяти. Добавление функций RMON2 к устройствам межсетевых взаимодействий может помешать их нормальной работе. Перегрузка сети Остерегайтесь собирать слишком много информации и делать это слишком часто. Объемные данные могут потребовать большой полосы пропускания. Сжимайте данные или выбирайте наиболее важные изменения до передачи их по дорогим соединениям глобальной сети. Размещение зондов Мониторинг RMON требует установки зонда или наличия встроенного агента в каждом сегменте, в то время как мониторинг RMON2 ограничивается установкой всего нескольких зондов для анализа трафика во всей сети. Это существенно, поскольку зонды стоят довольно дорого. Устанавливайте их между сервером и пользователем или на ключевых шлюзах. Направления развития Учитывая высокоуровневое представление деятельности сети с помощью RMON2, пользователи ожидают, что новый стандарт предоставит им более широкие возможности. Специалисты сейчас работают над совершенствованием масштабируемости, экспертизой трафика глобальной сети и функциями, обеспечивающими измерение времени ответа в сети. Практическая часть Пакет MON MON - универсальный ресурс, который может использоваться для контроля сетевых сервисов и ресурсов. Контроль за ресурсами может рассматриваться как две отдельные задачи: проверка состояния и вызов действий после отказа сервиса или ресурса. MON был разработан так, чтобы модули проверки состояния и вызова действий после отказа сервиса или ресурса работали как автономные программы. MON создан как планировщик, который выполняет мониторы (которые проверяют состояние), и вызывает соответствующие предупреждения, если монитор выдает ошибку. Мониторы и предупреждения - не являются частью MON. Это означает, что, если потребуется подключить новый монитор контроля сервисов или новое предупреждение, сервер MON, можно не изменять. Это делает MON легко расширяемым. Список некоторых возможностей MON: Мониторы (Monitors) "Мониторы" - программы, которые проверяют специфическое состояние, корректную работу или отказ на сервере. Они независимы от MON, так чтобы добавить новый модуль проверки работоспособности какого-то сервиса или ресурса вы можете просто написать ваш монитор на любом языке, поместить его в каталог мониторов, и он будет работать. Сервис Набор абстрактных параметров для контроля специфического ресурса, который определяется для каждой группы. Сервисы обычно моделируются после установки сервера SMTP, возможности ICMP ECHO, доступность дискового пространства сервера, или SNMP событий. Асинхронные события (Asynchronous Events) Поддержка асинхронных событий, сообщенных на сервер MON. Это открытый протокол, подобно монитору и аварийным сценариям. Например, отдаленные домены контроля (типа сайтов, отделенных медленными пропускными каналами сети) могут собирать собственные данные в местном масштабе и сообщать о существенных событиях центру управления сетью. Предупреждения (Alerts) "Аварийные" сценарии посылают сообщение или иногда действуют на отказ как MON. Эти предупреждения, подобно мониторам, - не являются частью MON, и их достаточно просто добавить. Также поддерживаются предупреждение, когда сервер возвращается после исправления отказа. Аварийная программа принимает набор параметров командной строки от планировщика, в дополнение к набору стандартных данных через стандартный ввод. Аварийное управление и обработка отказа (Alert Management and Failure Handling) Любой монитор может послать предупреждения, различным людям в разное время. Вы можете эффективно создавать расписание сообщений об отказе. Например, Вы можете посылать сообщение об отказе всем администраторам системы, если случилось какое-то событие на сервере до 20.00, но после 20.00, сообщение посылается только Денису, а письмо по электронной почте каждому. Параллелизация (Parallelization) Параллелизует проверку сервисов по различным хостам или группам хостов. Например, pinging ваших маршрутизаторов может осуществляться, одновременно с pinging ваших WWW серверов. Не создаётся очередь при обработке сервисов. Повторное предупреждение (Repetitive Alert Supression) Повторные предупреждения. Например, письмо по электронной почте посылается раз в час, пока сервис не восстановит свою работу. Как один из вариантов, незначительные отказы в работе могут игнорироваться. Зависимости (Dependencies) Межсервисные зависимости и четная корреляция. Например, если маршрутизатор между контролирующим главным компьютером и вашим сервером WWW -отказал, HTTP не будет работать, то посылается предупреждение, что маршрутизатор является причиной отказа. Это предотвращает каскадный «завал» огромным множеством предупреждений, когда некоторый критический ресурс не работает. Зависимости могут быть поняты как иерархическая форма (дерево), и, когда происходит отказ, дерево просматривается к узлу, который не имеет нерешенных зависимостей. Тем не менее, сложные зависимости могут быть описаны, используя общий граф, так как фактическая реализация не требует иерархической формы. Гибкая конфигурация (Flexible Configuration) Очень гибкий и расширяемый файл конфигурации. Главные компьютеры могут быть сгруппированы вместе, и каждый главный компьютер, или группа может иметь множество собственных сервисов. Клиент-серверная модель (Client/Server Model) Имеет интерактивную командную строку, основанную на WWW, и SkyTel 2 - Way клиентов, который делает запрос сервера для выяснения состояния сервисов и хронологии событий отказа. Очень просто сделать собственного клиента. Осуществлена поддержка множественного опознавания (включая PAM), наряду с управлением доступа отдельного пользователя. Perl модуль API используется, чтобы сделать запрос сервера, так же есть возможность создания собственного дополнительного интерфейса (типа того, который использует преимущества WAP). В этом пункте есть несколько видов интерфейсов WWW, активно обслуживаемых различными частями, каждый со своим собственным сообщением и целью. Сообщения состояния на основе представления (View-based Status Reports) Чтобы уменьшить количество не нужной информации в представлении, представления могут быть сгенерированы как отдельные сообщения для клиентов, которые не должны знать состояние всех проверяемых услуг. Например, в сетевое представление может быть включено состояние всего сетевого механизма, так же, как представление серверов может показывать всю информацию, имеющую отношение к серверам. Представления могут быть сконфигурированы на основании интересов клиента, если это необходимо и клиенты имеют контроль над их собственными представлениями. Хронология (History) Сохраняет список предупреждений и отказов на запросы клиентов, которые были обнаружены. Мобильность (Portability) Написанный на Perl 5. Сервисные мониторы MON. ICMP ECHO (утилита ping) Эффективная достижимость хостов через ICMP ECHO, используя fping, который мультиплексирует утилиты ping, использующие отдельный процесс. Если группа хостов прозванивается, и если существует больше чем один сбой, тогда коллективное время ожидания перед возвращениями сценария монитора будет такое же, если вы прозваниваете только один хост. SMTP SMTP связность тестируется подключением к SMTP порту в одном или более серверах, и для ответа "220" посылается "QUIT", затем ожидается ответ "221" и затем выключение Telnet Ждет login для входа в систему, чтобы определить, работает ли сервис. FTP Проверяет, установлено ли соединение с FTP сервером, соединяясь с сервером FTP, посылая "QUIT" и ожидает соответствующего ответа. NNTP Подобный SMTP, работает по протоколу NNTP. HTTP Работает по протоколу HTTP, чтобы выбрать URL с сервера HTTP. Монитор http_t может измерять время ожидания доставки страницы и сообщать об отказах, если минимальная скорость передачи не выполнена. Есть несколько вариантов монитора HTTP для использования в различных ситуациях. POP 3 Подобный SMTP, работает по протоколу POP 3, чтобы соединиться и выйти из системы. IMAP Подобный SMTP, работает по протоколу IMAP, чтобы соединиться и выйти из системы. Услуги на основе TCP Любые простые сервисы на основе TCP могут быть проверены. MON с помощью монитора "tcp.monitor". Это пошлет вывод серверу, и для специфического ответа, со временем ожидания. Рабочее время через асинхронный SNMP Вычисляет время работы и время простоя любого SNMP-доступного хоста. Сотни главных компьютеров могут опрашиваться за несколько секунд, используя асинхронный метод. Процессы через SNMP «Process.monitor» опрашивает UCD SNMP агентов на некотором количестве хостов и выдает сообщение о возникновении проблем в работе процессов. Этот монитор полезен для обнаружения не работающих процессов. Свободное пространство Сетевого устройства через SNMP «Netappfree.monitor» опрашивает Network Appliance устройства для того чтобы узнать количество свободного места для каждой экспортируемой файловой системы. Для этого не требуется установки новой файловой системы на главном компьютере MON. Для каждой разделяемой файловой системы создается свой конфигурационный файл. Поэтому вам не требуется перезагружать сервер MON. Сетевое время ожидания «Up_rtt.monitor» использует UDP или службу ECHO TCP, чтобы измерить время “запрос-ответ” между сервером MON и некоторым множеством хостов. Если измеренное время ожидания превышает минимум, тогда сообщается об отказе. SUN RPC сервис Монитор RPC может вызывать функцию RPC NULL, чтобы определить, отвечает ли сервер на запросы. Этот метод может использоваться, чтобы опросить NIS, NFS и другие популярные сервисы, которые использует SUN RPC. Установка MON Вся установка упирается в файл конфигурации. Файл конфигурации Файл конфигурации состоит из нуля или большего количества определения групп хостов, и одного или более определений времени запуска и работы. Каждое определение времени может иметь одно или более сервисных определений. Строки анализируются, по-порядку. Основная проблема при конфигурации – это правильно и четко определить, как и в каком порядке следует производить опрос хостов. Также большую роль играет время опроса. От правильной настройки этого файла зависит корректность работы MON. Пакет RRDMON Этот пакет был разработан отдельно от MON, но для MON, и в него входит обработка данных и сохранения их в архив данных. Собственно, говоря далее MON, я буду подразумевать RRDMON. Обработка данных Для чего нужна обработка данных? Вот вопрос, который может задать человек, не имеющий представления о работе системного администратора, если он может получить данные о загрузке трафика или занятости процессора в виде сотни цифр и букв. Сейчас, когда увеличились размеры не только локальных вычислительных сетей, но и люди начали задумываться о создании глобальной вычислительной среды, встает вопрос о ее управлении и контроле. Поток данных о состоянии сети будет описываться сотнями показателей. Как помочь администратору сети быстрее понять насколько корректно работает его сеть или участок сети, за который он отвечает. Способствовать решению этой проблемы может предварительная обработка данных. Моя работа заключалась в том, что я должен был изучить работу пакета MON и провести обработку данных в той форме, в которой это требуется для работы с ней. В этом пакете предусмотрена обработка, но так как этот пакет разрабатывался в расчете на стандартное использование, то много информации там не нужно, а некоторая отсутствует (применяя к вычислительной сети ОИЯИ). В мою задачу входило разобраться со стандартным модулем обработки данных и сделать свой модуль, который отвечал бы необходимым требованиям. Для стандартной обработки данных в пакете MON используется файл mon.cgi, который выводит информацию о состояния сервисов на обследуемых хостах. Список хостов, работу которых нам надо отслеживать, мы описываем в конфигурационном файле MON. В зависимости от топологии сети или назначения хостов мы разбиваем их на группы. После чего мы прописываем какие сервисы нам надо контролировать для каждой группы в отдельности. Информация, предоставляемая пользователю, после выполнения этого файла выглядит несколько громоздко. Это HTML страница с информацией обо всех хостах и сервисах, которые мы отслеживаем, представленная в текстовом формате. Использовать такой вид представления данных можно, когда вы контролируете сеть состоящую из 10-15 компьютеров и количество сервисов не велико. В нашем случае мы имеем достаточно большое количество компьютеров, а так же нам надо знать информацию о работе большого числа сервисов. Поэтому было решено отказаться от стандартного представления. Например, существует массив хостов и массив групп, я создал ещё ассоциативный массив хостов по группам, изменил способ сортировки. Созданный мною модуль основывался на стандартных возможностях пакета MON. Было переработано несколько стандартных процедур сортировки и вывода данных. Создана возможность множественной сортировки, возможность вызова нужных данных. Это позволило сократить время разработки соответствующего модуля и быстро привести визуализацию данных о работе групп хостов и сервисов к требуемой форме. Заключение Достоинства MON очевидны. Не покидая свое рабочее место, администратор может видеть весь трафик в локальном сегменте независимо от его реального физического местонахождения – в той же комнате или по другую сторону земного шара. Зная картину трафика, администратор может выявить тенденции, узкие места и проблемные ситуации. При возникновении какой-либо проблемы администратору не надо мчаться по вызову и устанавливать анализатор протоколов, так как он уже имеет в своем распоряжении мощный распределенный диагностический инструментарий – зонд готов передать накопленные за время его работы данные о трафике на консоль по первому требованию. Преимущества MON неоспоримы, но, используя его с пакетом RRDMON, вы можете повысить эффективность своей работы в несколько раз. Модули этого пакета позволят использовать все скрытые возможности MON и еще добавят недостающие для более эффективной работы. Обработанные данные имеют намного больше преимуществ перед полученной и предварительно не обработанной информацией. Имея только стандартное представление, вы будете должны просмотреть каждый раз все данные, которые к вам поступают, а потом провести их анализ. Удовлетворяют ли они тем критериям нормальной работы сети, которые вы им задали или нет. Это может занять много времени, если вы управляете большой сетью. Пока вы будете анализировать пришедшую информацию, к вам придет новая и так далее. В итоге вы не будете успевать ее анализировать, и случится завал. Обработка этих же данных позволит уменьшить время, затрачиваемое на их анализ. Один раз посмотрев на соответствующий массив данных, вы сможете увидеть все ли в порядке на том участке сети, работу которого он отображает. Для этого не надо просматривать большое количество цифровой информации, за вас это сделает программа. Благодаря этому высвобождается необходимое для работы администратора сети время, которое он может потратить на решение других не менее важных проблем. Например: оптимизации работы вычислительной сети. Список использованной литературы 1. Рэндал Л. Шварц, Том Кристиансен Изучаем PERL – «O’REILLY», 2000г. 2. Набор инструкций для работ с MON и RRDMON. 3. Ресурсы Интернет – сайтов: ссылка скрыта, ссылка скрыта, ссылка скрыта, ссылка скрыта, ссылка скрыта, ссылка скрыта . |