Берри Нанс. Компьютерные сети
Подождите немного. Документ загружается.
обеспечения
Для предотвращения использования нелицензированного программного
обеспечения и борьбы с компьютерными вирусами необходимо иметь
возможность контроля и управления процессом распространения программ в
ЛВС. Одним из способов такого контроля является распространение всего
программного обеспечения в ЛВС через некоторый центр. Вначале программы
копируются на файловый сервер из единого центра распределения, а
затем
переносятся на локальные накопители рабочих станций. Для автоматизации
этого процесса предназначена утилита фирмы IBM LDU (LAN Distribution
Utility - Утилита распределения программ в ЛВС).
Для того чтобы гарантировать, что все пользователи ЛВС используют
правильные версии программ, необходима процедура синхронизации всех
рабочих станций. В некоторых прикладных программах, например, в
банковских, необходимо, чтобы версии программного обеспечения на всех
рабочих местах были синхронизированы с версией центрального модуля,
обрабатывающего банковские операции. Наиболее простым способом
осуществления этой синхронизации может быть такой, когда в каждый запрос к
центральной базе данных встраивается номер версии используемого
программного обеспечения, а центральный модуль производит проверку версий
и игнорирует устаревшие.
Помощь администратору
В малых ЛВС работа администратора сети обычно выполняется одним из
пользователей, скорее всего, как дополнительная обязанность. В больших ЛВС
(20 или более рабочих станций) для этого нужен штатный администратор. В
любом случае администратор ЛВС нуждается в помощи при обнаружении и
устранении неполадок, в создании резервных копий, в защите данных и
контроле характеристик сети. Программное обеспечение для управления ЛВС
может решать эти вопросы и передавать отчеты на рабочую станцию
администратора, а в ЛВС с сотнями узлов - на центральную машину для их
дальнейшего анализа и обзора.
Обнаружение неполадок
Программное обеспечение системы управления ЛВС ведет учет
неполадок (событий), связанных с сетевыми адаптерами, кабелями и другими
компонентами ЛВС. При возникновении сбоев, например, поломки сетевого
адаптера, программа уведомляет об этом администратора ЛВС и, если она
достаточно совершенна, то может сама предложить варианты решения.
Программное обеспечение системы управления ЛВС также должно
предоставлять средства для контроля активности файлового сервера, серверов
печати, межсетевых шлюзов и иметь возможность для оперативной индикации
сбоев в этих узлах на дисплее администратора.
В ЛВС с сотнями рабочих станций центральная машина может быть
использована для ведения хронологического учета и анализа событий и
неполадок.
Ведение учета событий
Программное обеспечение управления ЛВС должно вести учет событий
^ких, как время суток, когда нагрузки на ЛВС максимальны, появление новых
адресов, ошибочные ситуации. Для этого выделяется специальный Файл, или
информация непосредственно выводится на принтер. Админи-•^тратор затем
может вносить эту информацию в базу данных для накоплена статистики и
последующего анализа. Поэтому программное обеспечение Управления должно
иметь собственные возможности для создания отчетов.
Обычно отчеты выдаются по результатам работы за определенный
периода например, за последние 24 часа.
Определение статуса устройств
Нередко администратору ЛВС может понадобиться информация о статусе
устройств, присоединенных к ЛВС, таких как рабочие станции, мосты и
межсетевые шлюзы. Поэтому программное обеспечение управления ЛВС
должно предоставлять такую информацию. Если сетевые адаптеры дают
информацию о распределении ошибок и загрузках графика, то для
администратора сети представляет интерес методичный сбор такой
информации со всех или выделенных узлов ЛВС.
Другая полезная функция состоит в тестировании состояния трассы ЛВС
между двумя рабочими станциями. Значение этой функции особенно важно при
наличии повторителей или мостов между такими станциями.
Управление конфигурацией ЛВС
Управление конфигурацией ЛВС требует знания того, какое программное
обеспечение установлено на каждой рабочей станции, и как эта станция
сконфигурирована. Для приложений, которые разрабатываются внутри данной
организации и распределяются автоматически (со строгим контролем версий),
эта проблема возникает редко. Но для приложений, получаемых со стороны
(электронные таблицы или текстовые процессоры), слежение за тем, на какой
рабочей станции какая версия программы находится, представляет достаточно
серьезную задачу.
Большие организации чаще всего используют подход, при котором на
накопителе файлового сервера размещается определенный набор программного
обеспечения. Обычно такой набор включает один или два пакета программ в
каждой из стандартных категорий - текстовые процессоры, СУБД, электронные
таблицы и телекоммуникационное средства.
Пользователи любого из этих программных пакетов могут получать
консультации и другую помощь по работе с ними у технического персонала
данной организации. Если же кто-то из пользователей захочет применять
какой-то другой пакет того же назначения, то он не сможет получить
поддержки технического персонала. Более того, такой пакет даже может быть
удален администрацией с файл-сервера.
В большой сети, насчитывающей сотни рабочих станций, такой
централизованный подход упрощает обслуживание и управление работой сети.
При этом контроль версий, разрешение трудностей, обучение сотрудников и
обновление программного обеспечения происходят скоординировано и просто.
Обычно пользователи отдельных рабочих станций могут изменять
конфигурацию применяемых программ в соответствии со своими привычками
и вкусами. Однако в больших сетях такой подход может мешать
централизованной технической поддержке. Конечно, незначительные
изменения конфигурации, например, смена цветов экрана, не вызывают
никаких проблем, но другие установки, такие как нестандартные коды для
принтера или необычная структуры директорий по умолчанию, могут создавать
трудности в масштабах всей сети.
По этим причинам некоторые организации вводят у себя правила,
ограничивающие допустимое конфигурирование программ.
Если у вас есть вопрос к службе технической поддержки, а вы
сконфигурировали используемую программу нестандартным образом, то у
сотрудника этой службы будут дополнительные трудности в диагнозе
ситуации. Поэтому в ЛВС с сотнями и тысячами рабочих станций наилучшим
подходом может быть такой, где имеется стандартная заранее оговоренная
конфигурация для каждой из используемых программ. "Тогда, в случае
возникновения затруднений, технический персонал всегда сможет вернуть
вашу рабочую станцию к стандартной конфигурации и с этой точки начать
выяснение причины возникновения проблемы.
УПРАВЛЕНИЕ КОНТРОЛЕМ ДОСТУПА И ЗАЩИТОЙ ДАННЫХ
Для малых ЛВС функции контроля доступа к сети выполняет сетевая ОС.
В большой вычислительной сети, включающей множество ЛВС и большие
ЭВМ, эти функции должны выполняться средствами управления ЛВС.
Пользовательский псевдоним и пароль позволят вам присоединиться к
ЛВС, но для доступа к определенным ресурсам ЛВС, например, к большой
ЭВМ, вам, возможно, придется пройти через дополнительные контрольные
процедуры. Некоторые приложения содержат собственные системы контроля
доступа. Задача администратора сети в этом случае состоит в установке этих
контрольных процедур на различных уровнях. Программное обеспечение для
управления ЛВС поддерживает функции администратора, как руководителя
службы контроля, и даже может регулировать с помощью паролей доступ к
прикладным программам.
Хотя, как уже упоминалось выше, бездисковые рабочие станции не
экономят денег за счет отсутствия дисков, но зато они могут быть полезны,
если в вашей организации безопасность данных стоит на первом месте. Такие
рабочие станции не позволяют копировать информацию с файл-сервера на
гибкие диски. Они также не дают возможности вносить в систему чужие
программы и файлы данных.
ОПРЕДЕЛЕНИЕ РОЛИ АДМИНИСТРАТОРА СЕТИ
Централизованное управление ЛВС представляет собой очень трудную
задачу. До сих пор нет универсального набора средств для выполнения
ФУНКЦИЙ администратора компьютерной сети. Имеются лишь программные
и
аппаратные средства для частичного выполнения этой работы. Администратор
сети должен обладать очень высокой квалификацией и творческим подходом
при применении тех или иных средств для решения нестандартных ситуаций,
возникающих в компьютерных сетях. Кроме этого, он должен достаточно
хорошо разбираться в конфигурациях сетей, их производительности, в
вопросах учета и планирования, в защите данных и прикладных программах.
ПРИМЕНЕНИЕ ПРОТОКОЛОВ УПРАВЛЕНИЯ ЛВС SNMP
И CMIP
Большая часть работы по управлению ЛВС состоит из слежения за
работой устройств, контроля производительности компьютерной сети,
диагностики проблем и устранения их причин. Много усилий было затрачено
на то, чтобы автоматизировать эти процессы. В результате были разработаны
два четких практически аналогичных протокола для управления ЛВС.
Простой протокол для управления вычислительной сетью (SNMP -
Simple Network Management Protocol) был разработан для решения
коммуникационных проблем TCP/IP.
Протокол общего управления информацией (CMIP - Common Management
Information Protocol), как часть стандартной модели OSI, является продуктом
международного комитета по стандартизации.
Каждый из этих протоколов имеет свои преимущества, и производители
сетевых систем разрабатывают средства управления ЛВС, объединяющие оба
протокола. Ниже будет рассмотрено сходство и различие этих протоколов.
СРАВНЕНИЕ SNMP И CMIP
Протоколы SNMP и CMIP имеют общую цель, состоящую в облегчении
задач управления и диагностики при работе в ЛВС. Оба протокола используют
концепцию MIB (Management Information Base - Базис управления
информацией). MIB состоит из набора переменных, тестовых точек и
контрольных параметров, которые поддерживаются всеми устройствами ЛВС и
могут контролироваться администратором ЛВС. Оба протокола поддерживают
также расширения MIB, вводимые различными производителями с целью сбора
большого количества служебной информации при запросах в ЛВС.
При разработке систем управления компьютерными сетями
производители сочетают возможности протоколов SNMP и CMIP.
Совместимость обоих протоколах MIB позволяет производителям создавать
системы управления ЛВС, которые смогут принимать информацию как от
SNMP, так и от CMIP, а хранить ее в общем формате.
РАЗЛИЧИЯ SNMP И CMIP
Протоколы SNMP и CMIP различаются способами, при помощи которых
они извлекают и выдают данные о вычислительной сети. Эти протоколы
предлагают различные функции, требуют разных затрат вычислительной
мощности и используют разное количество памяти. Каждый из этих протоколов
использует собственный набор протоколов низкого уровня для пересдачи и
приема информации, необходимой для управления ЛВС, и каждый протокол
поддерживается различными комитетами по стандартизации.
Доступ к данным
Протоколы SNMP и CMIP имеют функции извлечения данных, но делают
это разными способами. Протокол SNMP более предназначен для получения
сведений о конкретных устройствах, тогда как CMIP больше ориентирован на
извлечение наборов данных. При использовании SNMP необходима точная
формулировка запроса об интересующем вас предмете. В случае CMIP вы
имеете возможность сделать общий запрос и затем уточнять его, определяя,
какая информация вас не интересует.
Каждый из этих подходов имеет свои преимущества. Для некоторых
проблем, когда точно известно какая информация нужна, протокол SNMP
вполне удовлетворителен. В других случаях вам нужна более обширная
всесторонняя информация.
Опрос или отчет
Протокол SNMP работает через опросы (или поллинг), то есть
центральное устройство управления (возможно, ваша рабочая станция)
периодически опрашивает каждое устройство в ЛВС для определения его
статуса. В протоколе CMIP используются отчеты, в которых устройства
информируют центральную управляющую станцию об изменениях в своем
статусе.
При большом числе устройств протокол SNMP может вызвать большой
график ЛВС и замедлить ее работу, но он может работать с любыми
устройствами, включая самые примитивные, которые не могут сами определить
свою неисправность.
Размеры и производительность
Система управления ЛВС на базе протокола SNMP может быть меньших
размеров, более быстродействующей и менее дорогостоящей по сравнению с
CMIP. Система CMIP требует более быстродействующего компьютера и
большей памяти.
В большинстве случаев производители могут легко реализовать протокол
SNMP на DOS-машине в виде резидентной программы, что вряд ли возможно
для протокола CMIP.
Хотя протокол CMIP имеет большие возможности и характеристики, не
всеми его дополнительными функциями вы будете пользоваться.
Производителям систем управления компьютерными сетями на базе
SNMP приходится проявлять больше творчества, но при этом они все же не
могут достигнуть тех же результатов, которые позволяет получить CMIP.
Протоколы транспортного уровня
Для передачи запросов или ответов при управлении ЛВС в SNMP
используются простые датаграммы. Как уже говорилось в главе 5 "Протоколы,
кабели, адаптеры", при таком способе обмена, связывающиеся стороны должны
предусматривать возможность неполучения данных адресатом. Это значит, что
отправитель должен повторить передачу несколько раз, прежде чем
констатировать факт неработоспособности адресата. В SNMP для
маршрутизации сообщений могут быть использованы простые
коммуникационные протоколы (например, IPX или IP и UDP).
Разницу между датаграммой и сеансным обменом информации легко
понять на примере сравнения связи с помощью писем и телефона. При
телефонных коммуникациях имеется возможность двухстороннего обмена
информацией, письма (как и датаграммы) просто посылают, и они требуют
меньшего объема оборудования.
Использование в протоколе CMIP сеансного обмена информацией делает
его более удобным при необходимости получения большого количества
данных. Однако это может затруднить управление сетью при возникновении
неполадок. Если ЛВС выйдет из строя или практически перестанет
функционировать, SNMP будет продолжать посылать управляющие запросы до
тех пор, пока один из них не пройдет. Сеансный обмен информацией, на
котором базируется CMIP, становится невозможным, как только пропадает
связь в результате сбоя в работе ЛВС.
Стандарты протоколов
Протокол CMIP является протоколом OSI и потому контролируется
Международной организацией по стандартизации ISO. Производители систем
могут проверять свои изделия в COS (Corporation of Open Systems - Корпорация
открытых систем), где производится тестирование на совместимость с
протоколами OSI.
В противоположность этому SNMP не является международным
стандартом. Однако, подобно TCP/IP, SNMP контролируется организацией
Internet Activities Board.
ОЦЕНКА ДОСТУПНОСТИ ПРОДУКТОВ НА БАЗЕ SNMP И CMIP
На практике главным преимуществом SNMP перед CMIP является то, что
изделий на базе SNMP гораздо больше. Несмотря на определенные
преимущества, CMIP был использован в небольшом количестве сетевых
устройств. Продукты же на базе SNMP - маршрутизаторы, EtherNet
разветвители, волоконно-оптические и прочие устройства - широко
распространены. Частично причиной этого является разница в возрасте этих
протоколов - SNMP гораздо старше. Но в настоящее время многие компании
разрабатывают системы управления вычислительными сетями, использующие
CMIP или комбинацию SNMP и CMIP.
КАКОЙ ПРОТОКОЛ ВЫБРАТЬ ДЛЯ ВАШЕЙ ЛВС: SNMP ИЛИ
CMIP?
На каком протоколе должна базироваться система управления вашей ЛВС
SNMP или CMIP? SNMP больше ориентирован на управление конкретными
устройствами, в то время как CMIP лучше подходит для коммуникаций
между двумя или несколькими системами управления ЛВС. С этих
позиций SNMP и CMIP могут играть взаимно дополняющую роль. В
зависимости от размеров и сложности вашей ЛВС может оказаться, что лучшей
является система управления, использующая как CMIP, так и SNMP. Более
того, система может применять SNMP для управления конкретными
устройствами в локальном сегменте ЛВС, а протокол CMIP использоваться,
например, для помощи сетевому администратору в Нью-Йорке управлять
глобальной сетью локальных вычислительных сетей в Чикаго, Лос-Анжелесе и
Далласе.
СРЕДСТВА УПРАВЛЕНИЯ КОМПЬЮТЕРНЫМИ СЕТЯМИ
ФИРМЫ IBM
Большие глобальные компьютерные сети являются обычным делом для
пользователей компьютеров фирмы IBM, поэтому нет ничего удивительного в
том, что эта фирма также предоставляет и средства для управления такими
компьютерными сетями. Протокол Token Ring и Архитектура сетевых систем
(SNA - System Network Architecture) фирмы IBM являются фундаментом, на
котором построены системы LAN Network Manager и NetView.
УПРАВЛЕНИЕ ЛВС С ПРОТОКОЛОМ TOKEN RING
Протокол Token Ring всегда обладал специальными возможностями для
внутренней диагностики и управления - свойствами, в течение длительного
времени не используемыми программным обеспечением. В отличие от сетей с
протоколами ARCnet и EtherNet, в ЛВС с протоколом Token Ring всегда
циркулируют кадры MAC (Контроля доступа к среде), которые предоставляют
ценную информацию о статусе ЛВС. В частности, сетевые адаптеры
используют эту информации для поддержания работоспособности ЛВС, а
прикладные программы, предназначенные для управления компьютерной
сетью, могут использовать эту информацию для определения статуса и
состояния сети.
Некоторые производители предлагают программные средства перехвата
кадров MAC для управления сетью. Одним из таких производителей является
фирма IBM, дополняющая кадры MAC, как определено в сетях SNA, слоями
других протоколов, предназначенных для целей управления компьютерными
сетями. Как правило, в больших организациях сети с протоколом Token Ring,
являются частью сетей SNA. SNA является сетевым стандартом фирмы IBM,
включающим практически любые устройства: терминалы, ПК, ЛВС,
контроллеры, большие ЭВМ и даже дистанционные принтеры. Узлы сетей SNA
можно подразделить на входные точки и фокальные точки. Входные точки
являются источником статистики SNA и информации о статусе устройств, а
фокальные точки предназначены для ее приема и представления информации
оператору.
Внутри SNA фирма IBM ввела стандарт Служб управления сетью, где
определила, как различные системы управления должны связываться друг с
другом. Например, стандарт фирмы IBM устанавливает, что сигнал тревоги
(сигнал об ошибке или о другом значительном событии в ЛВС) должен
содержать следующие данные: адрес узла, где произошла ошибка; дата и время,
когда произошла ошибка; идентификационный номер управляющего
компонента, сообщившего об ошибке; возможная причина ошибки и
рекомендуемые действия. (Конечно, узел, сообщивший об ошибке, может быть
не в состоянии предоставить все перечисленные данные). Несмотря на то что
стандарт SNA был разработан фирмой, он является хорошо
документированным и широко распространенным стандартом, которого
придерживаются многие производители компьютеров для того, чтобы их
аппаратные и программные продукты были совместимы с изделиями IBM.
Не все рабочие станции в ЛВС с протоколом Token Ring являются
равноправными. Одна из них назначается активным монитором, т.е.
наделяется дополнительной ответственностью контроля работоспособности
кольца. Активный монитор занимается обслуживанием синхронизации кольца,
выпускает новые маркеры (при необходимости) для сохранения
работоспособности кольца и создает диагностические кадры при определенных
обстоятельствах. Активным монитором может быть любая рабочая станция,
назначаемая при инициализации кольца. Если активный монитор выходит из
строя, то остальные рабочие станции в ЛВС немедленно начинают переговоры
между собой для назначения нового активного монитора.
В стандарте протокола Token Ring IEEE 802.5 определены шесть типов
пакетов (кадров) MAC. При присоединении к кольцу рабочей станции она
передает пакет "Тест дублирования адреса" для того, чтобы убедиться в
уникальности своего адреса. Для уведомления остальных рабочих станций о
своей работоспособности активный монитор периодически передает пакеты
"Активный монитор присутствует". Другие рабочие станции периодически
передают пакеты "Запасной монитор присутствует". При подозрении о выходе
из строя активного монитора запасные мониторы передают пакет "Требование
маркера". Рабочие станции передают пакет "Маяк" ("Тревога") в случае
возникновения серьезных проблем в сети, таких как обрыв кабеля или
передача, не синхронизированная с получением маркера. Пакет "Очистка"
передается после инициализации кольца или после установления нового
активного монитора.
Программное обеспечение управления сетью осуществляет локализацию
активных мониторов по пакетам MAC "Активный монитор присутствует".
Диагностика сетей выполняется программным обеспечением с помощью
пакетов "Маяк". Кроме этого, используя стандартную технику опроса
(поллинга) кольца по стандарту IEEE 802.5, программное обеспечение имеет
возможность определения статуса каждого сетевого адаптера. Если в ЛВС с
протоколом Token Ring, являющейся частью сети SNA, будет обнаружен
сетевой адаптер, которому запрещено участвовать в обмене данными, то
программное обеспечение может передать сигнал тревоги. При возникновении
ошибок в какой-нибудь из рабочих станций в сети с протоколом Token Ring
истинным виновником этого иногда может быть другая станция. Например,
рабочая станция - ближайший верхний по течению сосед (Nearest Active
Upstream Neighbor - NAUN) - узел, ответственный за передачу маркера или
пакета вниз по течению, мог испортить данные из-за внутренней
неисправности. Программное обеспечение управления компьютерной сетью
может распознавать подобные ситуации с NAUN и правильно
интерпретировать их для выявления истинного виновника.
ИСПОЛЬЗОВАНИЕ ПРИНЦИПОВ SNA В ЛВС С ПРОТОКОЛОМ
TOKEN RING
На следующем после MAC уровне входные и фокальные точки могут
использовать Службы управления (Management Services) SNA для
осуществления функций управления компьютерной сетью. Если на рабочей
станции загружено программное обеспечение, ориентированное на применение
в SNA, ее можно опрашивать, тестировать или диагностировать с удаленной
рабочей станции. SNA имеет широкий набор средств, предназначенных для
выполнения управленческих и служебных функций. В ее рамках существуют
возможности проведения трассировок, записи "снимков" содержимого ОЗУ
(даже с удаленных рабочих станций), требований проведения тестов и передачи
их результатов, получения и записи статистики.
К примеру, для трассировки событий в отдельных сегментах
компьютерной сети фокальная точка выдает запрос "Активизировать канал"
(Activate Link - ACTLINK). Следующее за этим требование "Активизировать
трассировку" (Activate Trace - ACTTRACE) предназначено для записи данных
трассировки (Record Trace Data - RECTRD}, и последнее требование
"Деактивизации трассировки" (Deactivate Trace - DACTTPACE) заканчивает
цикл. Сообщение RECTRD содержит адрес канала, тип трассировки и
трассировочные данные. Запрос ACTTRACE может содержать признак того,
что трассировка предназначена для всего сегмента или для определенного
канала.
Запрос "Требование статистики обслуживания" (Request Maintainance
Statistics - REQM^-S) предназначен для получения из узла SNA данных о
статистике обслуживаемых ресурсов и определяет, нужно ли после передачи
отчета производить сброс счетчиков, набирающих статистику. Рабочая станция
с протоколом Token Ring в сети SNA в качестве ответа на этот запрос может
передать технические данные адаптера: версию сетевого адаптера, версию
программного обеспечения сети, уровень графика и число ошибок. Если число
ошибок превзойдет предварительно установленную пороговую величину, то
рабочая станция может инициировать самостоятельную передачу этой
статистики без предварительных запросов REQMS.
Как видите, в сети SNA нет недостатка в средствах обслуживания и
управления.
ИСПОЛЬЗОВАНИЕ ПРОДУКТА ФИРМЫ IBM LAN NETWORK
MANAGER