Реферат: Министерство образования Российской Федерации



Министерство образования Российской Федерации


Международный университет природы, общества и человека «Дубна»


БАКАЛАВРСКАЯ РАБОТА


Тема Проблемы мониторинга в глобальных системах____________________________ распределённых_вычислений______________________________________________________________________________________________________________________________________________________________________________________________________________


ФИО студента Абрамов Денис Васильевич ____________________________

Группа 4011__________ Направление системный анализ и управление_____

Выпускающая кафедра __системного анализа и управления_____________


Руководитель работы __________________ ____________________

Консультант (ы) __________________ ____________________

__________________ ____________________

__________________ ____________________


Рецензент __________________ ____________________


Бакалаврская работа допущена к защите «_____»_________________2001 г.

Заведующий кафедрой ______________________/проф. Черемисина Е.Н. /


Дубна


Аннотация

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

Abstract

In the given work the future development of the global distributed computing system is described. And also development of additional units to a software package of monitoring of network and resources in MON were carried out. Some number of the units which gather the information from the system of servers and process it. In order to use servers and resourсes more effectively.

Оглавление

Оглавление 5

Введение 6

Постановка задачи 7

Теоретическая часть 8

^ Метакомпьютинг – как вычислительная инфраструктура будущего 8

Формы метакомпьютера 9

Проект GRID 10

Предпосылки и сферы применения GRID 10

Проект Globus 11

Проект EU Data GRID 12

Проблемы мониторинга в глобальных сетях 13

Архитектура 15

Терминология 16

Компоненты 16

Задания менеджера 18

Проблемы выполнения 18

Общие стратегии реализации 19

Универсальность 20

^ Удаленный мониторинг 20

Архитектура RMON 20

Стратегия использования 20

Мониторинг коммутируемых сетей 21

Анализ RMON 22

Опасности, подстерегающие пользователей RMON2 23

Практическая часть 24

Пакет MON 24

Сервисные мониторы MON. 27

Установка MON 29

Файл конфигурации 29

Пакет RRDMON 29

Обработка данных 29

Заключение 31

Список использованной литературы 32


Введение

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

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

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

Мониторинг сети - дело важное, нужное, но непростое. Сегодняшние сети - это, прежде всего интегрированные системы, которые определяют средства и правила общения на своем специфичном уровне. Однако сетевым администраторам важно не только понимать, но и контролировать это общение. Чем сложнее топология и конфигурация сети, тем большим объемом информации должен обладать сетевой администратор и тем сложнее с технической стороны сделать эту информацию доступной. Любая сеть без качественного мониторинга - это “черная дыра в космосе”, которая влечет за собой непредсказуемость и, как следствие, низкую отказоустойчивость системы.

^ Постановка задачи

Цель

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

^ Исходные данные

Существующий пакет Globus Toolkit управления сетями, пакет мониторинга сети MON, документация прилагаемая к этим пакетам, сервер pccmsy.jinr.ru с установленным MON.

Модель

Для создания опытного модуля я использовал существующий пакет MON и модули, которые входят в его состав, а так же язык Perl 5.

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

1. Проведение анализа и исследование проблемы:

1) Изучение существующих средств управления сетями;

2) Изучение существующего пакета мониторинга сетей ^ MON;

3) Выявление существующих проблем представления данных в MON;

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

3. Создание опытного модуля.

Результаты

Изучение средств мониторинга системы в рамках пакета ^ Globus Toolkit. Развитие средств мониторинга в MON.

Критерии достижения результата

Проектируемый подключаемый модуль должен:

- быть построен и управляем на основе общих принципов создания мониторов в пакете RRDMON;

- быть динамически развивающимся;

- помочь администратору получать нужную и точную информацию о сервисах и ресурсах сети быстрее.


^ Теоретическая часть

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

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

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

Что собой представляет Internet известно сегодня любому – это множество соединенных друг с другом узлов, имеющих собственные процессоры, оперативную и внешнюю память, устройства ввода/вывода. Такая конструкция весьма напоминает многопроцессорную систему, в которой роль магистральных шин выполняет Сеть. Цель метакомпьютинга заключается в том, чтобы превратить аналогии в реальность – стереть барьеры между разнородными, пространственно распределенными вычислительными системами и образовать сверхкомпьютер или метакомпьютер, который для пользователей и программистов выступал бы в виде единой вычислительной среды, доступной с любого рабочего места (ПК или станции).

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

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

^ Формы метакомпьютера

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

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

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

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

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

обеспечение дистанционного доступа к крупным корпоративным вычислительным центрам (настольный суперкомпьютер);

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

агрегация вычислительных центров в региональном и национальном масштабе (интеллектуальные инструменты и метакомпьютер).

^ Проект GRID

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

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

^ Предпосылки и сферы применения GRID

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

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

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

специалисты по вычислительной технике;

ученые–экспериментаторы;

научные ассоциации и коммерческие фирмы.

Проект Globus

На сегодняшний день одним из самых успешных является Globus – совместный проект Аргонской национальной лаборатории и Института информации Университета Южной Калифорнии. Цель проекта – разработка технологий, которые могут быть использованы при создании вычислительных сетей. Следует отметить, что Globus уже привлек внимание российских специалистов, которые представили данный проект как элемент реализации общих идей метакомпьютинга. В проекте предполагается, что вычислительные сети представляют собой долговременно существующую вычислительную среду, которая позволяет программному приложению объединить компьютеры, интеллектуальные инструменты, информационные ресурсы независимо от их географического расположения. Важным моментом является то, что Globus имеет конкретные результаты в виде комплекта разработанных программ.

^ Globus Resource Allocation Manager (GRAM) обеспечивает универсальный интерфейс к широкому ряду локальных средств управления различными ресурсами: процессоры, вторичная память, каналы связи и т.д. GRAM транслирует запросы на ресурсы в команды, специфичные для локальных систем управления выполнением запросов. GRAM – нижний уровень управления ресурсами, посему он непосредственно взаимодействует с локальными планировщиками распределения ресурсов.

^ Globus Security Infrastructure (GSI) – «Инфраструктура Сетевой Безопасности», обеспечивающая общий интерфейс для различных локальных систем безопасности. Особенности этой системы включают однократную проверку пользователя за один сеанс работы. Все последующие запросы на аутентификацию выполняются специальными прокси–серверами. Безопасность в системе Globus реализована с использованием протокола аутентификации X.509, который предполагает использование механизма сертификатов. Безопасность обеспечивается центром сертификации (Certificate Authority – СА), которому доверяют все пользователи, получающие, в свою очередь, собственные сертификаты. В такой схеме безопасности используется правило транзитивности доверия: если пользователь_2 показал, что центр доверяет ему, тогда пользователь_1, убедившись в верности подписи центра, доверяет пользователю_2. Каждый пользователь должен быть зарегистрированным и получить сертификат от центра. С другой стороны, поскольку в процессе аутентификации производится обмен сертификатами, то и пользователь убеждается, что он взаимодействует с верной системой. Процесс аутентификации в Globus производится сейчас с использованием протокола Secure Socket Layer. На базе средств GSI разработаны в частности варианты ftp–сервера и ftp–клиента, которые могут использоваться независимо.

^ GRID Information Service (GIS) – информационная служба, позволяющая получить информацию о состоянии распределенных ресурсов сетевой инфраструктуры Globus. Эта служба базируется на использовании протокола доступа к каталогам LDAP.

^ Global Access to Secondary Storage (GASS) – средства глобального доступа к вторичной памяти. С использованием GASS можно организовать доступ ко всему ряду удаленной вторичной памяти: от дисковой памяти, подключенной к удаленной машине.

^ Проект EU Data GRID

Проект EU Data GRID задуман, как альтернатива проекту GRID в США. Его целью служит объединение всех крупных научных и вычислительных центров Европы в единую вычислительную сеть для дальнейшего проведения совместных экспериментов на больших физических установках в CERN и других научных центрах. Создание этого проекта позволит всем пользователям, имеющим доступ к этой сети получить необходимые данные по всем экспериментам, проводимым в Европе.

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

Проект включает в себя несколько рабочих пакетов:

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

управление рабочей загрузкой (распределенное планирование и управление ресурсами);

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

мониторинг (доступ к информации о состоянии и об ошибках в GRID–инфраструктуре);

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

создание виртуальной частной сети , объединяющей вычислительные ресурсы и ресурсы данных, участвующие в отладке GRID–инфрастуктуры;

управление массовой памятью (создание глобального GRID –интерфейса к существующим системам управления массовой памятью).

В качестве основы промежуточного программного обеспечения для проекта EU Data GRID выбран набор инструментальных средств Globus.

^ Проблемы мониторинга в глобальных сетях

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

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

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

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

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

В некоторых моделях, типа ^ CORBA Event Service, вся передача данных идет через центральный компонент, который потенциально представляет собой узкое место. В GRID большая часть трафика для передачи данных от менеджера до потребителя используется без центрального компонента. Проект также учитывает дублирование и сокращение данных в промежуточных компонентах потребителя/менеджера, играющих роль кэша или фильтра. Использование этих промежуточных компонентов уменьшает загрузку на менеджерах данных, которые имеют несколько потребителей, с последующими сокращениями сетевого трафика, поскольку посредники могут быть помещены «около» потребителей данных. «Directory» сервис содержит только метаданные об исполняемых событиях и компонентах системы и доступен сравнительно редко, что уменьшает шанс, стать узким местом.

Также в ^ GRID рассматривается способ контроля, основанный на SNMP. Но SNMP модель не имеет никакой поддержки подписки потока данных и надежного способа защиты. Тем не менее, GRID определенно предусматривает использование инструментальных средств SNMP как источника мониторинга данных.

Архитектура

Архитектура ^ GMA поддерживает как модель менеджера/потребитель, подобную CORBA Service Event, так и модель запрос/ответ. Для каждой модели, менеджеры или потребители, при соединении, регистрируются в «Directory» сервис. Потребители используют «Directory» сервис, чтобы записать одного или более менеджера данных определенного типа, в которых они заинтересованы. Каждый потребитель делает запись в «Directory» сервис или запрос на определенного менеджера данных. Аналогично, менеджер данных может сделать запрос в «Directory» сервис, чтобы подключить потребителей, которые принимают и обрабатывают данные определенным способом. Как только соответствующий потребитель идентифицирован, менеджер данных подключает его для передачи данных – подобно тому, когда потребитель запросит и подключится к менеджеру данных (после инициализации менеджером).

Терминология

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

Компоненты

Архитектура состоит из следующих компонентов:

• потребители

• менеджеры

• «Directory» сервис

Определяя три интерфейса: потребитель к интерфейсу менеджера, потребитель к «Directory» сервис, и менеджер к «Directory» сервис интерфейсу; мы можем формировать интероперабельную сетку сервисов мониторинга.

«Directory» сервис

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

«Directory» сервис содержит распечатку всех доступных данных и их менеджеров. Это позволяет потребителям обнаруживать то, какие данные являются в настоящее время доступными.

Потребитель

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

Менеджеры

Менеджеры ответственны за предоставление данных потребителям или по запросу или асинхронно. Менеджеры публикуют информацию доступности данных в «Directory» сервис.

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

^ Источники данных

Имеются много возможных источников данных:

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

сетевые датчики: Эти датчики исполняют запросы SNMP на сетевое устройство, обычно маршрутизатор или коммутатор.

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

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

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

датчики микропрограммных средств: Эти датчики собирают информацию относительно сервисов микропрограммных средств типа директивных и опознавательных серверов.

^ Задания менеджера

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

Контроль эксплуатационных характеристик

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

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

Частое изменение данных. В отличие от более статических форм “метаданных”, динамическая информация эффективности обычно изменяется более часто, чем читается.

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

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

Время измерения должно быть минимизированно. Иначе оно будет влиять на измерение времени запроса и скорость трафика.

^ Общие стратегии реализации

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

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

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

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

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

Универсальность

Одна из самых больших проблем в определении контролирующей архитектуры для использования в среде GRID - универсальность. Проблема в том, что действие контроля имеет минимальный статус на проверяемых системах. В этой модели, можно прибавлять дополнительных менеджеров и дополнительные директивные серверы, если необходимо, уменьшая плотность загрузки, где необходимо. Также, ресурсы, которые продюсер будет использовать, должны, непосредственно, быть намечены. В частности мы полагаем, что GMA более масштабируемый, чем CORBA Service Events. В GMA, данные не будут посланы куда-нибудь, если это не требуется потребителем. Многие службы, включая CORBA, посылают все данные к центральному компоненту, с которым потребители затем входят в контакт. В GMA, только информация подписки данных будет послан центральному директивному серверу. Данные идут непосредственно от продюсера потребителю.


^ Удаленный мониторинг

RMON, или база управляющей информации для удаленного мониторинга (Remote MONitoring MIB). Эта стандартная спецификация обеспечивает во многом те же функциональные возможности, что и нестандартные сетевые и протокольные анализаторы.

^ Архитектура RMON

Как и SNMP, инфраструктура RMON опирается на клиент-серверную архитектуру. При этом в роли "клиента" выступает приложение, выполняемое на станции управления сетью, а в роли "сервера" – устройства мониторинга, распределенные по сети и занятые

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

^ Стратегия использования

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

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

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

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

^ Мониторинг коммутируемых сетей

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