Выбор протокола управления сетью

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

РЕФЕРАТ

на тему: «Выбор протокола управления сетью»

Содержание

Введение

1. Анализ подходов к задаче управления сетями

1.1 Управление и слежение за малыми сетями

1.2 Встроенные в ОС средства

1.3 Платформенный подход

2. Управление крупными сетями. Модель управления менеджер-агент

3. Протокол SNMP

4. Обоснование выбора протокола SNMP

Заключение

Введение

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

К середине 1980гг. стали очевидными проблемы, число которых все более увеличивалось, связанные с этим ростом, особенно у тех компаний, которые применили много разных (и несовместимых) технологий сети. Основными проблемами, связанными с увеличением сетей, являются каждодневное управление работой сети и стратегическое планирование роста сети. Характерным является то, что каждая новая технология сети требует свою собственную группу экспертов для ее работы и поддержки. В начале 1980гг. стратегическое планирование роста этих сетей превратилось в какой-то кошмар. Одни только требования к числу персонала для управления крупными гетерогенными сетями привели многие организации на грань кризиса. Насущной необходимостью стало автоматизированное управление сетями (включая то, что обычно называется "планированием возможностей сети"), интегрированное по всем различным окружениям. Таким образом, постановка задачи выглядит как разработка основы системы для управления крупной сетью под единым протоколом для охвата как можно более широкого спектра оборудования, подключенного к сети.

1. Анализ подходов к задаче управления сетями

В наше время существует несколько разновидностей подходов к менеджменту сетей, от простого мониторинга встроенными в ОС средствами и до комплексных решений, которые способны оперировать огромными сетями со множеством узлов.Сложность сети, её распределённость и разнообразие применяемого оборудования являются граничными параметрами, обуславливающими целесообразность применения системы управления в какой-либо сети (источник - http://www.compnets.narod.ru/6-1.html).

1.1 Управление и слежение за малыми сетями

Если сеть небольшая, то управлять ей можно, как правило, из разных узлов. Это так называемое децентрализованное управление, где каждый компьютер имеет свой локальный ресурс. О плюсах и минусах данного метода можно прочесть в статье http://www.lessons-tva.info/edu/telecom-loc/m1t4_2loc.html.

В качестве примера можно привести домашнюю сеть из нескольких компьютеров и маршрутизатора, через который машины подключены к интернету. В таком случае достаточно иметь доступ к высшему по иерархии устройству, т.е. роутеру. Современные устройства позволяют подключаться к ним напрямую, через браузер посредством веб-интерфейса. Это очень удобный и простой способ, как для сбора статистики, так и для составления, например, правил доступа или безопасности, равно как и для различного рода настроек устройства, достаточно лишь подключить устройство и выйти на его сетевой адрес. Современный веб-интерфейс можно увидеть на сайтах разработчиков данных устройств, например, http://www.tp-linkru.com/resources/simulator/TL-WR941ND_v2&v3/index.htmили http://www.support.dlink.com/emulators/dir625/109/login.html . О самих же преимуществах и недостатках web-интерфейсов можно прочесть подробнее здесь http://www.computerra.ru/hitech/34344/.

Также возможен вариант терминального доступа к устройствам, когда машина-терминал не производит никаких вычислений, а только перенаправляет информацию ввода в удалённое устройство и выводит информацию на свой экран. Многие устройства позволяют терминальный доступ по telnet, например, http://www.dlink.ru/by/products/5/1630.html

компьютерная сеть протокол

1.2 Встроенные в ОС средства

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

ipconfig -- утилита командной строкидля управления сетевымиинтерфейсами. Это утилита командной строки для вывода деталей текущего соединения и управления клиентскими сервисами DHCP и DNS. Утилита ipconfig позволяет определять, какие значения конфигурации были получены с помощью DHCP, APIPA или другой службы IP-конфигурирования либо заданы администратором вручную. На таблице 1 ниже показаны ключи команды и их расшифровки:

Таблица 1. Ключи команды Ipconfigи их расшифровка

Netstat -показывает содержимое различных структур данных, связанных с сетью, в различных форматах в зависимости от указанных опций. Объём получаемой информации больше чем в программе IPconfig, т.к. показывается текущая конфигурация сокетов. На таблице 2 представлены ключи команды netstat:

Таблица 2. Ключи команды netstat и их расшифровка

Эти встроенные в ОС средства позволяют довольно эффективно следить за сетевым состоянием машины, на которой они запущены. Но они пригодны лишь для сбора наиболее общей информации, и только её сбора. К тому же, они собирают данную информацию только о машине, на которой запущены. Таким образом, эти программы не являются полноценными сетевыми мониторами и удалёнными сетевыми помощниками.

1.3 Платформенный подход

При построении систем управления более крупными локальными и корпоративными сетями обычно используется платформенный подход, когда индивидуальные программы управления разрабатываются не «с нуля», а используют службы и примитивы, предоставляемые специально разработанным для этих целей программным продуктом - платформой. Примерами платформ для систем управления являются такие известные продукты, как HP OpenView, SunNetManager и SunSoltice, CdbletronSpectrum, IMB/Tivoli TMN1 (http://www.compnets.narod.ru/6-1.html). Существет также решение от компании D-Link, но оно распространяется только на оборудование их фирмы и допускает до 1000 элементов в сети. Подробнее - http://www.dlink.ru/ru/products/1386/803.html

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

2. Управление крупными сетями. Модель управления менеджер-агент

Управление сетью в больших объединенных сетях TCP/IP строится на взаимодействии между станцией управления сетью (менеджер) и элементами сети. Данная архитектура системы управления выбирается из-за следующих преимуществ:

- концентрация всей информации о состоянии сети в одном узле управления;

- целостная картина построения сети;

- относительная простота управления правами администраторов сети;

- минимальная длина цикла управления;

- непротиворечивость принимаемых решений.

Источник - http://www.lessons-tva.info/edu/telecom-loc/m1t5_2loc.html

Элементами сети могут быть любые объекты, которые используют семейство протоколов TCP/IP: хосты, маршрутизаторы, X терминалы, терминальные сервера, принтеры и так далее. На элементах сети должно быть запущено программное обеспечение, которое называется агентом.

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

Модель менеджер - агент лежит в основе таких популярных стандартов управления, как стандарты Internet на основе протокола SNMP и стандарты управления ISO/OSI на основе протокола CMIP. Агенты могут отличаться различным уровнем интеллекта -- они могут обладать как самым минимальным интеллектом, необходимым для подсчета проходящих через оборудование кадров и пакетов, так и весьма высоким, достаточным для выполнения самостоятельных действий по выполнению последовательности управляющих действий в аварийных ситуациях, построению временных зависимостей, фильтрации аварийных сообщений и т.п. Подробнее об архитектуре менеджер-агент - http://kunegin.com/ref3/snmp/file0.htm#2.1

Менеджер и агент должны располагать одной и той же моделью управляемого ресурса, иначе они не смогут понять друг друга. Однако в использовании этой модели агентом и менеджером имеется существенное различие. Агент наполняет модель управляемого ресурса текущими значениями характеристик данного ресурса, и в связи с этим модель агента называют базой данных управляющей информации -- ManagementInformationBase, MIB. Менеджер использует модель, чтобы знать о том, чем характеризуется ресурс, какие характеристики он может запросить у агента и какими параметрами можно управлять. Менеджер взаимодействует с агентами по некоему стандартному протоколу. Этот протокол должен позволять менеджеру запрашивать значения параметров, хранящихся в базе MIB, а также передавать агенту управляющую информацию, на основе которой тот должен управлять устройством. Одним из таких протоколов является SNMP - SimpleNetworkManagementProtocol.

3. Протокол SNMP

Протокол SNMP работает на базе протокола UDP и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию, изменять, посылать trap на сервер сбора событий. Протокол определяет формат данных, их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При работе протокол SNMP использует управляющую базу данных (MIB). Взаимодействие с MIB показано на рис.1:

Рис.1. Взаимодействие с базой данных

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

Существуют у этого протокола и недостатки. Неудобство доставляет количество команд и параметров, которые нужно помнить или держать под рукой, что возможно не всегда. Также SNMPсильно грузит процессор опрашиваемого устройства, особенно при больших объёмах передаваемых данных, даже если опрашивается просто несколько интерфейсов. Такая нагрузка обусловлена краеугольным камнем самого протокола - его простотой. Команды, передаваемые менеджером агенту, как правило, очень просты и атомарны в своём значении, что приводит к множественным обменам сообщениями между менеджером и агентом. Не исключены и ошибки переполнения переменных, потому различного рода счётчики необходимо своевременно сбрасывать. Также не всегда на руку играют преимущества протокола UDP - хоть он и быстрее того же TCP, ему свойственна потеря данных в неких «узких местах», где пропускная способность ниже расчётной. Подробнее об snmp - http://kunegin.com/ref3/snmp/

4. Обоснование выбора SNMP

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

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

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

- Огромным плюсом является использование в качестве транспортного протокола UDP. Это значит, что сообщения-trap'ы доходят без промедления и подтверждений, что позволит вовремя оповестить систему менеджера. Также UDP обладает большей скоростью передачи и меньше загружает опрашиваемую систему, что в нашем случае критично.

Таким образом, при разработке системы удалённого доступа и слежения за состоянием сети мы будем использовать именно протокол SNMP.

Заключение

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

Размещено на Allbest.ru