NETSGUIDES

КОМПЬЮТЕРНЫЕ СЕТИ

Поиск:

 

Сетевые мониторы

Статьи / Локальные сети / Глава 14. Принципы управления сетями / Обзор средств управления сетями / Сетевые мониторы

В своей работе вы обязательно будете использовать программные средства, использующие протоколы управления сетью, для сбора информации о сети и иногда для отправки команд удаленным компьютерам. Это не просто средства пассивного наблюдения. Они могут быть использованы для уведомления ответственного лица о возникновении проблемы.
Сетевые мониторы состоят из двух частей: клиентной, расположенной на наблюдаемом устройстве, и серверной, расположенной на устройстве, выполняющем наблюдение и запись собранной информации. Взаимодействие клиентной и серверной частей зависит от протокола наблюдения. Несмотря на это, все программное обеспечение для наблюдения за сетью спроектировано с одной целью — сбора информации о сети. Для выполнения такой работы может потребоваться:
● транспортный протокол сбора статистической информации;
● идентификация узлов сети;
● сбор данных о конфигурации программного обеспечения и оборудования;
● сбор статистической информации о производительности и загруженности каждого сервера Internet (host);
● запись статистической информации об использовании приложений;
● запись сообщений о событиях и ошибках.

Antidetection browser смотрите на http://www.identory.com.

Содержание собираемой информации зависит от элементов, за состоянием которых можно наблюдать и обслуживать отдельными программными продуктами для наблюдения/управления сетью. Каждый сервер Internet (host), допускающий управление такого типа, для каждого наблюдаемого элемента имеет текстовый файл, называемый административной базой данных (MIB — Management Information Base). Файл MIB содержит следующую информацию.

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

Короче, файл MIB содержит список наблюдаемых объектов системы и их характеристики. Комплект средств Windows NT Resource Kit содержит файл MIB (ведущий свою родословную от списка адресов SNMP), называемый TOASTER.MIB, который иллюстрирует синтаксис. Ниже приведен один из объектов файла MIB.

Таким образом, значение, ассоциированное с объектом toasterDoneness, указывает, насколько хорошо был приготовлен тост. Монитор может также оценить, попадает ли это значение в некоторый интервал (скажем, между 3 и 7 для хорошо сделанного тоста) и выдает предупреждение сетевому администратору при выходе величины за допустимые границы.
Значение в скобках внизу ({toaster 4}) — номер объекта. Таким образом, toasterDoneness является четвертым типом объектов, определенным в файле MIB.

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

Для применения наиболее популярного метода сбора данных (когда вам требуется информация сразу о нескольких управляемых объектах), вы можете запросить ее у сетевого монитора. Монитор, в свою очередь, запрашивает информацию у сервера Internet (host), используя при этом имя объекта. Сервер производит поиск имени, определяет связанное с ним значение и возвращает монитору отчет.
Не все протоколы средств наблюдения за сетью используют одинаковые файлы MIB и даже не все протоколы одного типа работают с одинаковыми файлами MIB. Для того чтобы средство наблюдения соответствовало стандартному протоколу, при разработке средства следует придерживаться руководящих принципов сбора данных, указанных в стандарте протокола.
Если в программном продукте для наблюдения используется, как минимум, один определенный MIB, то он должен быть согласован со стандартом. С практической точки зрения это значит, например, что не все использующие SNMP-список сетевые мониторы созданы одинаковыми (равными). Требуется тщательно проверять, какую именно информацию позволяет собирать тот или иной программный продукт.

Простой протокол сетевого управления (SNMP)

Простой протокол сетевого управления (SNMP — Simple Network Management Protocol) является примером события, часто встречающегося в мире сетей: появившееся как временная "затычка" средство становится стандартным, поскольку предназначенная ему на замену усовершенствованная технология несколько опоздала к тому времени, когда это средство стало доступным. Изначально протокол SNMP был спроектирован как простой, облегченный метод наблюдения за интрасетями, в которых используется протокол TCP/IP. Более совершенный протокол CMIP (Common Management Information Protocol — общий протокол передачи управляющей информации), соответствующий модели OSI, предназначался в качестве замены SNMP, но этого так и не произошло по двум причинам. Первая: CMIP и в самом деле более мощный протокол, чем SNMP, и позволяет собирать информацию, которую SNMP собрать не может. Но такое расширение возможностей привело к недопустимой перегрузке ресурсов сети и сервера. Вторая: к тому времени, когда протокол CMIP стал пригодным для использования, протокол SNMP настолько широко распространился, что стоимость его замены стала превышать выгоду от применения протокола CMIP. Таким образом, SNMP стал самым распространенным стандартным протоколом для инструментов сетевого управления.

Протокол CMIP - претендент № 2

В гл. 6 была упомянута технология SMDS, служащая примером мощной технологии, вытесненной менее мощной Frame Relay, изначально предназначавшейся для временного заполнения определенной ниши до окончания разработки SMDS, Это довольно обычная история — то же самое случилось и со CMIP-протоколом.
Протокол CMIP задумывался как более мощное средство, призванное заменить протокол SNMP. CMIP поддерживает функции, которые в SNMP отсутствуют; он может работать на любой платформе (версия для взаимодействия только с TCP/IP называется СМОТ). Он может предоставить такие средства управления, которые отсутствуют в SNMP. В сущности, он работает совершенно иначе, чем SNMP. Вместо опроса устройств для определения их статуса или получения о них какой-либо информации, CMIP ждет, пока устройства сами не предоставят отчеты диспетчеру CMIP.
По иронии судьбы, причиной отказа от CMIP стала его мощность. Он требует больше серверных ресурсов, чем может позволить большинство сетей. В конце 90-х гг. — все это уже история. По поводу протокола CMIP публикуется многообещающая информация: "Если CMIP поступит в коммерческое пользование, он будет- иметь огромное число заказчиков, поскольку над его разработкой продолжают работать все учебные институты". Однако кажется маловероятным, что CMIP сможет вскоре заменить SNMP. Протокол SNMP широко распространен и пользуется признанием, чтобы его в данный момент можно было легко заменить, и хотя он не такой мощный, как CMIP, зато не так требователен к ресурсам.

Как работает протокол SNMP. При работе протокола SNMP используют файлы MIB подобно тому, как при переписи населения — опрос. Через регулярные промежутки времени (или по сигналу запроса) серверная часть SNMP запрашивает у устройства информацию о его статусе, используя данные из MIB-файла устройства. Когда агент получает такой запрос, он возвращает требуемые значения. Между клиентной и серверной частями монитора информация перемещается с помощью протокола UDP (User Datagram Protocol — протокол пользовательских дейтаграмм), являющегося компонентой транспортного уровня протокола TCP/IP. UDP — протокол без соединения (точнее без подтверждения). Это значит, что он позволяет передавать сообщения, не заботясь об их приеме, и поэтому не вносит большого вклада в сетевой трафик.
Конечно, протокол SNMP или какое-либо другое средство наблюдения за сетью увеличивают сетевой трафик, но все они спроектированы так, чтобы это воздействие было минимальным.
Устройства для наблюдения за сетью, которые требуют большого сетевого трафика (и, следовательно, "несут ответственность" за большую часть трафика), не особенно полезны.

Примечание:
Хотя существует стандарт, регламентирующий применение SNMP в сетях с протоколом IPX/SPX (в котором для передачи сообщений применяется протокол IPX вместо UDP), но гораздо более вероятно, что вы столкнетесь с протоколом SNMP в сетях TCP/IP. Не все версии протокола SNMP поддерживают передачу сообщений посредством IPX-протокола.

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

Не в каждом устройстве сети имеется агент SNMP. Он есть только в тех, за которыми необходимо наблюдать, и сконфигурированных для поддержки SNMP. Поддерживающие протокол SNMP устройства, например, маршрутизаторы или мосты, всегда снабжены агентами SNMP, но если вы хотите наблюдать за компьютером определенного (возможно, нестандартного) типа, вам следует самому установить агента. В NT это делается путем запуска средств SNMP как на наблюдаемом устройстве, так и на диспетчерском компьютере.
По умолчанию (и согласно рекомендациям стандарта) агенты SNMP конфигурируются следующим образом: для приема сообщений назначается порт 161, для пакетов перехода (traps) - порт 162. Если вам требуется установить на отдельном компьютере несколько агентов SNMP, вы можете изменить назначенный порт. В NT, например, информация о назначенных портах хранится в файле SERVICES (файл без расширения; но вы можете открыть этот файл с помощью редактора Notepad), который находится в папке System32\Drivers\Etc. Поищите там, например, такие записи:

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

Предупреждение:
Это средство не имеет "защиты от дурака". Редактируйте файл SERVICE (или иным образом изменяйте конфигурацию какого-либо другого порта), только если вы абсолютно уверены в том, что вы делаете, и твердо знаете, что не измените установки других портов устройства.

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

get — отыскивает указанный параметр управляемого объекта;
get next — отыскивает следующий параметр в файле MIB;
set — изменяет параметр управляемого объекта, пользуясь привилегией на чтение/запись.

Когда диспетчер SNMP получает от агента данные, он может либо просто отобразить их, либо сохранить в базе данных для дальнейшего использования.
Операции get и set выполняют только в ответ на запрос от диспетчера SNMP. Без запроса агент SNMP посылает сообщение только в двух случаях: когда узел останавливается или запускается, или когда значения некоторых контролируемых параметров выходят за пределы допуска и требуется передать сигнал тревоги. Эти сообщения называют пакетами переходов (traps). Они отправляются по IP- и IPX-адресам или по адресу сервера Internet (host), указанному вами во время установки средств обслуживания SNMP на данном компьютере.

Сетевое взаимодействие по протоколу SNMP. Система защиты SNMP-протокола базируется на концепции среды (communities), представляющей собой логическую структуру SNMP-машин, объединенных под общим именем, аналогично рабочей группе. Подобно рабочей группе, члены среды часто физически расположены близко друг от друга, но это не обязательное условие. По сути дела, имя среды — пароль и должно трактоваться только таким образом.
Лишь те агенты и диспетчеры, которые входят в одну среду, могут общаться друг с другом. Когда монитор посылает агенту сообщение с запросом на получение информации, имя среды является составной частью сообщения. Когда он принимает сообщение, то проверяет корректность полученного имени среды. В случае несовпадения агент отбрасывает сообщение и, при необходимости, может зарегистрировать факт неудавшейся аутентификации. Только в случае, если агент и диспетчер используют одинаковое имя среды, сообщение будет обрабатываться.
По умолчанию все серверы NT, поддерживающие SNMP-протокол, изначально являются частью открытой (public) среды. Для дополнительной безопасности вы можете удалить имя среды или создать другую среду. Машина SNMP — агент или диспетчер — может быть членом одновременно нескольких сред. Если диспетчер SNMP не входит в состав ни одной среды, он уподобляется устройству, не имеющему защитного пароля, и любой клиент SNMP может взаимодействовать с диспетчером независимо от того, членом какой именно среды является клиент.

Удаленное наблюдение (RMON)

На протяжении всей истории сетей, помимо средств наблюдения за сетью, предоставляемых протоколом SNMP, применялись также и аппа-ратно реализованные устройства удаленного наблюдения, например, сетевые мониторы и сетевые зонды (probe). Обычно (но не всегда) эти устройства представляют собой автономные инструментальные средства для решения задачи сбора сетевых данных, и они должны быть установлены в каждом сегменте маршрутизированной сети.
RMON (Remote Monitoring — удаленное наблюдение) — средство работы с оборудованием, предназначенным для выполнения сложных функций управления сетью. RMON — это протокол для сбора информации обо всей сети из единственного узла, применение которого позволяет отказаться от услуг специалиста, непосредственно наблюдающего за объектом, который подозревается в неисправности, и анализирует сетевые данные. Вместо этого центрального узла можно активировать удаленный монитор и поручить ему направлять информацию об определенном сегменте на центральную консоль. Единственное ограничение здесь то же самое, что и в случае применения протокола SNMP: наблюдаемое устройство должно иметь установленный агент RMON.
Хотя в обоих протоколах RMON и SNMP используются файлы MIB, это вовсе не одна и та же вещь. Оба они — средства управления сетями, но RMON обеспечивает поддержку расширенного набора файлов MIB, позволяющих собирать больше информации, чем SNMP. Основная функция SNMP заключается в получении подтверждения о том, что все части сети работают нормально. RMON предназначен для большего — он фактически является сетевым анализатором, используемым для измерения трафика данных в определенном сегменте локальной сети с целью определения его структуры и причины появления сколько-нибудь существенных узких мест. В определенных случаях RMON может использоваться не только для чтения данных, но и для записи, в зависимости от того, имеет ли какой-либо смысл задание значений параметров отдельного объекта. Как и при использовании протокола SNMP вам не следует наблюдать за процессом сбора данных в реальном масштабе времени. Инструментальные средства RMON позволяют подавать сигнал тревоги при выходе значений некоторых параметров за предварительно установленные допустимые границы или записывать данные в специальный журнал для последующего просмотра.
Первая версия протокола RMON позволяла собирать информацию только на канальном уровне. Но в версии RMON2, стандартизованной в июне 1997 г., предусмотрен сбор информации уже на сетевом уровне, вплоть до уровня портов, если это необходимо. RMON2 также поддерживает работу с некоторыми (специфическими для глобальных сетей) типами данных и позволяет идентифицировать ситуации, возникшие из-за каких-либо проблем на сетевом уровне, например, обрыва кабеля. RMON не фиксирует ошибки в пакетах на канальном уровне, поскольку данные из MIB-файла позволяют идентифицировать их только путем "разборки"
кадра и его последующего чтения. Если на канальном уровне имеются ошибки, объем получаемой полезной информации будет относительно невелик. Однако на сетевом и вышележащих уровнях RMON может идентифицировать ошибки протокола и сообщать о них.
Данные, собираемые с помощью RMON, могут быть получены от одного из следующих источников.

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

Распространенность протокола. Процентная доля пакетов, созданных в сегменте помощью каждого из протоколов.

Установление соответствия адресов. Списки установленного соответствия адресов канального уровня адресам сетевого вместе с информацией о том, где это соответствие отслеживалось в последний раз.

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

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

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

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

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

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

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

Совместимые с RMON устройства не обязаны поддерживать обработку всех этих категорий данных, но если уж они поддерживают какую-либо категорию, то должны делать это полностью. Совместимое с RMON устройство может и не предоставлять некоторую часть информации о сервере Internet (host) на сетевом уровне из всего определенного в стандарте набора. К тому же некоторые группы зависят от других групп. Также совместимые с RMON устройства не могут использовать файлы MIB, связанные с матрицей прикладного уровня, если они не применяют матрицу сетевого уровня. Вы не сможете подсчитать трафик между узлами в соответствии с протоколом, если не в состоянии подсчитать трафик между узлами, независимо от транспортного протокола.
RMON важен не только потому, что позволяет собирать разнообразные данные, но также и потому, что обеспечивает непрерывный процесс сбора данных, независимо от того, функционирует ли в данный момент времени соединение между средствами удаленного наблюдения и главной консолью. Такой непрерывный поток собираемых данных поддерживает систему в состоянии, максимально соответствующем текущему моменту.
Например, вы не можете гарантировать, что удаленно управляемое устройство будет всегда соединено с главной консолью наблюдения. В случае прерывания такого соединения как по причине сбоя, так и вследствие запланированного отключения (что особенно вероятно, если монитор и главная консоль отделены друг от друга глобальной сетью WAN), будет наблюдаться разрыв связи между главной консолью и наблюдаемым устройством. Но использование файлов MIB для сбора данных означает, что удаленная система может быть сконфигурирована для сбора своих данных даже в случае, если она не находится в данный момент в контакте с главной консолью.

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

Протокол RMON можно использовать для осуществления непрерывной диагностики неисправностей, сбора информации, не отслеживаемой в данный момент, с целью ее последующего использования. Даже если сеть начинает отказывать, удаленный монитор будет записывать все параметры состояния системы, которые привели к возникновению проблемы — вплоть до момента полного прекращения работы сети. Когда появится такая возможность, с главной консоли можно будет просмотреть эту информацию для идентификации условий, приведших к сбою в работе сети. Поддерживающие RMON устройства могут также быть запрограммированы для записи определенных параметров системы. Устройства будут постоянно собирать информацию. Когда значения записываемых данных превысят заданные границы, монитор может распознать проблему и уведомить об этом главную консоль. Все эти данные весьма полезны, поскольку облегчают работу сетевого администратора. Чем больше данных вы можете получить, тем легче будет изолировать проблему в случае, когда сервер Internet (host), генерирующий большее число ошибок трафика, чем какой-либо другой сервер, пришлет последнее сообщение и остановит работу части сети.
Единственным недостатком RMON являются проблемы совместимости с другими устройствами. RMON1 не полностью согласован, поскольку отдельные производители добавляют различные новые средства к протоколу. Эти средства предоставляют расширенные возможности получения информации с помощью протокола, однако делают несовместимыми между собой различные реализации RMON. Перед покупкой устройств RMON удостоверьтесь, совместимы ли они друг с другом и можно ли контролировать их состояние с помощью ваших средств наблюдения.