<< Пред. стр.

стр. 10
(общее количество: 13)

ОГЛАВЛЕНИЕ

След. стр. >>

Для потребителя наиболее привлекательной стороной СУБД Paradox является ее пользовательский интерфейс. Фирма Borland уделила большое внимание организации и содержанию программных меню, экранов подсказок и печатной документации. Она предлагает также версию Paradox for Windows.
Прямой и ясный подход системы Paradox к разработке приложений позволяет как опытным программистам, так и новичкам создавать эффективные программы. В этой СУБД имеются средства для быстрого создания как стандартного отчета, так и нестандартных отчетов. Имеются также возможности для импорта и экспорта файлов в очень широком диапазоне форматов и средства для графического представления информации, позволяющие создавать графики десяти типов: от круговой диаграммы до трехмерных графиков. СУБД Paradox включает также модуль QBE "запросов по образцу", позволяющий просто пометить поля, которые нужно включить в запрос. Отдельный модуль SQL Link, предоставляющий доступ к SQL-серверам баз данных, также может быть поставлен фирмой Borland.
Язык прикладного программирования системы Paradox (PAL - Paradox Applications Language) несложен в изучении. Для создания простых прикладных программ система Paradox может запомнить последовательно вводимые вами команды и затем преобразовать их в файл сценария для последующего воспроизведения команд. Опытные PAL-программисты могут составлять таким способом довольно сложные прикладные программы. В Paradox for Windows существует объектно-ориентированная версия PAL, называемая Object PAL.
СУБД Paradox может использовать расширенную и дополнительную память, позволяет создавать базы данных объемом до двух миллиардов записей с числом полей на одну запись до 255.

СУБД R:BASE

На протяжении ряда лет СУБД R:BASE являлась главным конкурентом dBASE, что повлияло на ее возможности, внешний вид, экраны подсказок и документацию. Эта система имеет средства для создания прикладных программ при помощи меню генератора приложений, которыми могут пользоваться непрофессиональные программисты.
СУБД R:BASE содержит управляемый посредством меню модуль "запросов по образцу" QBE, который быстро проводит вас через процедуру формирования запроса к базе данных. При желании можно преобразовать данные, отвечающие запросу, в новую таблицу базы данных. Каждая база данных R:BASE может иметь до 80 таблиц (файлов), и запросы способны использовать до пяти баз данных.
Система меню R:BASE помогает в создании сложных прикладных программ. Генератор приложений может превратить созданные при работе с R:BASE экраны для ввода данных и описания рабочих файлов в прикладную программу, которую затем можно использовать в работе вне среды R:BASE.
Эта система имеет легко осваиваемый процедурный язык. Прикладные программы, создаваемые с помощью этого языка, могут иметь развитую систему меню, экраны подсказок и другие характеристики, облегчающие их использование. Язык программирования R:BASE содержит полный набор команд SQL. СУБД R:BASE способна импортировать и экспортировать файлы в формате dBASE.
Файлы R:BASE могут иметь любое количество записей в базе данных Я ограничены только объемом свободного пространства жесткого диска. СУБД R:BASE использует расширенную или дополнительную память и позволяет иметь до 400 полей в записи.
Подробнее узнать о системе R:BASE можно в:
Microrim
15395 S.E. 30th Place
Bellevue, WA 98007
(800) 628-6990

Заключение

В этой главе вы познакомились с современными сетевыми прикладными программами и их отличительными свойствами по сравнению с программами для индивидуального использования. Вначале вы изучили команды DOS в многопользовательской среде, а затем то, как сетевая ОС на практике применяет права и разрешения. После изучения характеристик многопользовательских прикладных программ: разделения файлов, захвата записей в файлах, идентификации пользователей рабочих станций, печати на разделяемом принтере, вы рассмотрели лицензионные соглашения для сетевых программ.
Кроме этого, было обращено внимание на некоторые прикладные программы для ЛВС. Вы взглянули на текстовые процессоры, настольные издательские системы и электронные таблицы с точки зрения многопользовательских систем. Далее был проведен краткий обзор восьми наиболее распространенных СУБД.
В следующей главе вы рассмотрите, как нужно управлять ЛВС, чтобы она работала эффективно.
Глава 12. Управление ЛВС

Управление ЛВС скорее является искусством, чем наукой. При разрастании ЛВС до сотен (или даже тысяч) рабочих станций поддержание ее работоспособности требует большого опыта и глубоких знаний.
Вероятно, когда-нибудь протоколы управления сетями вместе с новыми версиями сетевых ОС позволят детально контролировать целиком всю сеть, не отрываясь от своей рабочей станции. В будущем аппаратные и программные средства различных производителей будут соответствовать новым стандартам, и управление ЛВС станет систематической и рутинной работой. Но до тех пор материал этой главы может оказать вам существенную помощь в поддержании работоспособности вашей ЛВС.
При возникновении в ЛВС какой-нибудь неполадки для ее устранения необходим систематический подход. Наиболее трудная задача - диагностика сети и идентификация неполадок. В этой главе вы познакомитесь с методами и средствами выявления сетевых ошибок.
Проектировщики сетей предлагают два специальных протокола, предназначенных для управления вычислительными сетями - SNMP (Simple Network Management Protocol - Простой протокол для управления вычислительной сетью) и отвечающий модели стандарта OSI протокол СШР (Common Management Information Protocol - Протокол общего управления информацией). Протоколы, рассматриваемые в главе 5 "Протоколы, кабели, адаптеры , предназначались для обмена данными между рабочими станциями и файловыми серверами, а протоколы SNMP и СШР специально разработаны для диагностики работоспособности различных ЛВС.

Основные принципы управления ЛВС

В настоящее время работа по управлению ЛВС приобретает все большее значение, а специалистов в данной области не хватает.
Современные ЛВС являются динамическими, распределенными структурами. Они объединяют разнообразные компьютеры, межсетевые шлюзы, мосты. разветвители, миниЭВМ и большие ЭВМ. Очень часто разрастающиеся сети могут включать программные системы, изначально разработанные не для больших компьютерных сетей, а также компоненты различных производителей. Управление такими структурами - непростая задача.
Для управления ЛВС в первую очередь необходимо иметь ее план, который будет изменяться и расти вместе с ростом сети. План компьютерной сети должен содержать следующую информацию: о кабельных трассах, о схемах соединения кабелей, о протяженности сети, о стандартах протоколов и оборудования, о росте числа рабочих станций и новых технологиях. Он должен также учитывать появление новых средств и инструментов для управления ЛВС.

Анализ технических вопросов

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

Обработка неполадок при обычной работе
Иногда отказы в одной из компонент ЛВС могут воздействовать на Другие компоненты. Например, внутренняя электроника сетевого адаптера может исказить содержимое принятого пакета данных. Далее эти данные будут переданы адаптером сетевой ОС, которая может не обнаружить ошибку. Если затем эти данные будут размещены в файле, то он окажется испорченным. Система управления ЛВС должна обеспечивать возможность проведения перекрестного контроля для обнаружения такого рода ошибок.

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

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

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

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

Анализ административных вопросов

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

Управление распространением программного обеспечения
Для предотвращения использования нелицензированного программного обеспечения и борьбы с компьютерными вирусами необходимо иметь возможность контроля и управления процессом распространения программ в ЛВС. Одним из способов такого контроля является распространение всего программного обеспечения в ЛВС через некоторый центр. Вначале программы копируются на файловый сервер из единого центра распределения, а затем переносятся на локальные накопители рабочих станций. Для автоматизации этого процесса предназначена утилита фирмы 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

LAN Network Manager - программный продукт фирмы IBM для управления компьютерными сетями. Он предназначен для оказания помощи сетевому администратору в управлении ЛВС с протоколом Token Ring, в особенности таких сетей, которые являются частями больших SNA. Программное обеспечение имеет простой интерфейс на основе меню и может применяться совместно с программой NetView (продукт фирмы IBM для больших ЭВМ) или независимо от нее в односегментной или многосегментной компьютерной сети с протоколом Token Ring. (He следует путать программное обеспечение управления сетью LAN Network Manager фирмы IBM с сетевой ОС LAN Manager фирмы Microsoft).
Программное обеспечение LAN Network Manager совместимо с Архитектурой прикладных систем (SAA - System Application Architecture) и предназначено для работы под управлением программы Presentation Manager ОС OS/2. Это программное обеспечение использует систему управления базой данных в OS/2 Database Manager для хранения и считывания данных о конфигурации сети и истории событий и ошибок.
Версия 1.1 программного обеспечения LAN Network Manager включает 80 команд программы NetView и использует протоколы CMIP и SNMP. Она предоставляет возможность просмотра графического изображения ЛВС.
При автономной работе программа LAN Network Manager действует как фокальная точка в компьютерной сети, а при совместном использовании с программой NetView она является одновременно и входной точкой (агентом) системы NetView для большой ЭВМ ^„огда программное обеспечение LAN Network Manager используется в качестве входной точки, то в терминах SNA это означает, что оно является узлом SSCP (System Services Control Point) и использует коммуникационный сеанс физического устройства SSCP сети SNA для диалога с программой NetView. Обычно в сети SNA имеются несколько узлов SSCP и они обеспечивают широкий набор управленческих услуг: помогают активизировать или деактивизировать сеть, распределяют сетевые ресурсы, управляют нроцессом восстановления сети после коммуникационных сбоев, осуществляют сбор данных о графике сети, взаимодействуют с персоналом, обслуживающим сеть, выполняя его команды и координируя связи различных сегментов сети. Программа NetView сама по себе является узлом SSCP, предоставляющим централизованное управление большой, территориально разбросанной компьютерной сетью.
Что это дает пользователю? У него появляется возможность инициировать и контролировать операции управления сетью с любого терминала или рабочей станции сети, независимо от того, являются ли они физически частями управляемой ЛВС с протоколом Token Ring. Это качество оказывается особенно полезным для сетевых администраторов, которые должны обслуживать компьютерные сети, территориально удаленные от них.

Использование программы NetView фирмы IBM

Программный продукт NetView, ориентированный на применение в больших ЭВМ, объединяет в себе возможности нескольких программ фирмы IBM, разработанных для больших ЭВМ. Система NCCF (Network Communications Control Facility - Средство контроля межсетевых коммуникаций) может работать на многосегментных компьютерных сетях, записывая сигналы тревоги, распределяя управленческие обязанности между несколькими сетевыми операторами и запуская программы-сценарии. Система NLDM (Network Logical Data Manager - Управление логическими данными в сети) осуществляет запись сеансов и данных о маршрутизации в сети. Программный модуль NPDA (Network Problem Determination Application - Приложение для обнаружения сетевых проблем) производит анализ сетевых неполадок, представляя его результаты с различными уровнями детализации. На самом нижнем уровне модуль NPDA выявляет вероятную причину ошибки или сбоя.
Программный продукт NetView интегрирует эти и другие функции в простую прикладную программу, предназначенную для решения задач управления компьютерной сетью, с интерфейсом на основе меню. Этот продукт позволяет оператору легко получить информацию о состоянии узла SNA так же, как и проанализировать статистику или осуществить реконфигурацию сетевых устройств. Оператор программ LAN Network Manager или NetView, например, может реконфигурировать мост в ЛВС, изменив его сетевой адрес или максимальное значение числа мостов, через которые может проходить сообщение в процессе транспортировки. Кроме этого, имеется возможность накопления статистики о производительности и графике сетевых мостов (включая число кадров, которые были проигнорированы или не были переданы из-за ошибок) и о числе широковещательных кадров, предназначенных для приема всеми рабочими станциями.
Можно также использовать средство NCCF программы NetView для передачи запроса или команды программному обеспечению LAN Network Manager, в действительности не находясь у рабочей станции, управляемой этим программным обеспечением. Вы можете запросить текущий статус узла сети с протоколом Token Ring, удалить узел из сети, произвести поточечный тест трассы между двумя узлами, осуществить сброс программы LAN Network Manager и запросить информацию о текущей конфигурации сегмента ЛВС.
Получать информацию о статусе сети, ее истории, а также осуществлять программный контроль системы NetView можно двумя путями. Как уже указывалось, программные средства NetView включают процессор файла сценария, который может быть использован администратором для автоматизации реакции системы на определенные события. Программирование на языке сценария, встроенном в пакет NetView, очень сильно напоминает написание сценариев коммуникационных программ для ПК. Вы без особых затруднений можете написать программу реакции на определенные сигналы тревоги в сети. Ваша программа может даже предпринять попытку устранения ошибки, передавая команду сброса устройства на узел, в котором возникла эта ошибка.
Интерфейс для прикладного программирования пакета NetView более сложен, но позволяет с помощью пользовательских программ на языке высокого уровня получить доступ к данным конфигурации сети и файлам с историей сигналов тревоги. Прикладные программы могут также использовать интерфейс прикладных программ (API - Application Program Interface ) пакета NetView для подачи собственных сигналов тревоги, например, о неполадках в файле базы данных. Пакет NetView осуществляет запись всех сигналов тревоги в файл истории и предпринимает соответствующие действия (определенные вами) по этим сигналам. Этим действием может быть, например, уведомление оператора о том, что требуется его вмешательство.
Новой особенностью API пакета NetView является средство LU 6.2 (для равноправных коммуникаций). LU 6.2 - это протокол, ориентированный на диалог внутри сети SNA. С помощью простых глаголов, таких как распределить, принять-и-ждатъ, передатъ-данные, подтвердить и перераспределить, протокол LU 6.2 облегчает осуществление запросов NetView или выполнение сетевых управленческих заданий (созданных, разумеется, программистами вашей организации).
Другой продукт фирмы IBM Net View/PC предоставляет протокол API к NetView, который другие производители могут использовать в качестве интерфейса со своим оборудованием. Такие компании, как Synoptics, AT&T, Paradyne и Codex выпускают продукты, работающие с NetView и основанные на интерфейсе Net View/PC. Среди устройств с этим интерфейсом имеются адаптеры EtherNet, аппаратные средства управления модемом и сетевые ресурсы Т-1.

Контрольные проверки в ЛВС фирмы IBM

Программный продукт LAN Network Manager работает с другими программами фирмы IBM для контроля доступа к сети. Он помогает в установке правил, определяющих возможность присоединения определенных рабочих станций к сети. С помощью программы LAN Station Manager и устройства 8230 CAU (Controlled Access Unit - Устройство контролируемого доступа) для ЛВС с протоколом Token Ring система LAN Network Manager может обнаруживать попытки несанкционированного вторжения в сеть, генерировать сигналы тревоги и автоматически удалять нарушителей путем перепрограммирования или сброса устройства 8230 CAU. Разумеется, сам продукт LAN Network Manager защищен паролем.
Знаете ли вы точно, как расположены компьютеры в вашей организации? Программный продукт LAN Station Manager вместе с пакетом LAN Network Manager и устройством CAU помогут вам легко составить схему распределения ПК в ЛВС, даже если их положения изменяются со временем.
Средство CAU включает функции представления отчетов для уведомления пакета LAN Network Manager об идентификационных кодах адаптеров, ответвлений и сегментов компьютерной сети. Программа LAN Station Manager, существующая в версиях для DOS и OS/2, осуществляет сбор информации об устройствах с каждой из рабочих станций и затем передает эти данные пакету LAN Network Manager. Этот программный продукт обслуживает базу данных станций, содержащую информацию о пользователях, такую как номер комнаты, порядковый номер и символическое имя машины. Фирма IBM предполагает, что программное обеспечение LAN Station Manager должно быть установлено на всех рабочих станциях. Программное обеспечение LAN Network Manager (или NetView) может сигнализировать CAU или LAN Station Manager о выдаче отчета от этих средств об отдельных рабочих станциях и сравнить эту информацию с расположением машин в определенных местах здания. Таким образом, можно прослеживать за всеми перемещениями ПК по зданию вашей организации.
Фирма IBM довольно ограниченно применяет CMIP и SNMP в своих продуктах, предназначенных для управления компьютерными сетями. Одним из немногих участков, где используются CMIP, является обеспечение связи между устройством CAU и программным пакетом LAN Network Manager. Другие диагностические и управленческие функции внутри сети, вообще говоря, не являются совместимыми с протоколом CMIP. Первичные протоколы, используемые фирмой IBM в своих продуктах, предназначенных для управления компьютерными сетями, были определены в документе "Службы управления сетями SNA" и остаются неизменными до сих пор. В будущем фирма IBM планирует добавление средств поддержки протокола CMIP после того, как определение этого протокола станет более четким.

Использование прикладных программ для управления сетями фирмы IBM

Протокол Token Ring имеет большие скрытые возможности, и вскоре, по-видимому, будет больше прикладных программ для управления сетями, использующих эти возможности. А пока получить представление о состоянии вашей компьютерной сети дают возможность программные продукты фирмы IBM, рассмотренные в этой главе. Однако эти продукты довольно дороги, и вы вряд ли захотите их приобретать для небольших компьютерных сетей. Если же вы используете ЛВС средних размеров с протоколом Token Ring, то в этом случае имеет смысл рассмотреть вопрос о приобретении программного продукта LAN Network Manager.

Использование общих средств для управления ЛВС

Ниже вы познакомитесь со специальными вспомогательными средствами, предназначенными для управления сетями: от рефлектометров с разрешением во временной области (TDR- time-domain reflectometers) до интегрированных систем управления. Некоторые из них очень дороги, но если сеть необходима для вашего бизнеса, то инвестирование средств в них будет разумным.

Оценка цены простоя ЛВС

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

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

Управление компьютерными сетями преследует две цели. Во-первых, правильно организованный процесс работы ЛВС уменьшает число сетевых неполадок. Если проблемы все же возникают, то вторая цель связана с уменьшением возможных потерь и изоляцией неполадок.
Имея в виду эти цели, Международная организация по стандартизации (ISO) определила пять категорий управления, которые должна включать система управления ЛВС: сбой, конфигурация, производительность, защита и учет. Ниже приведено описание категорий управления:
Категория
Описание
Управление учетом
Запись и выдача информации об использовании ресурсов ЛВС
Управление конфигурацией
Определение и управление параметрами, определяющими состояние ЛВС
Обработка сбоев
Обнаружение, изоляция и исправление неполадок в ЛВС
Управление производительностью
Анализ и управление скоростью, с которой ЛВС обрабатывает данные
Управление защитой
Контроль доступа к ресурсам ЛВС

Существует четыре типа продуктов для управления ЛВС, работающих с пятью категориями ISO: контрольно-измерительные приборы, сетевые мониторы, сетевые анализаторы и интегрированные системы управления сетями. Каждый тип имеет свои преимущества и занимает свое место в управлении современными неоднородными сетями.

Различные типы инструментов

Контрольно-измерительные приборы включают: рефлектометры (TDR), осциллографы, детекторы разрывов, измерители мощности и другие аналогичные продукты.

Рефлектометры
Когда-то тестеры кабелей были громоздкими неуклюжими приборами. Современные приборы недороги, имеют достаточно малые размеры и могут легко переноситься для проверки кабелей в любом месте вашего офиса. Иногда эти устройства имеют портативные принтеры для распечатывания о счетов, о проведенных измерениях. Большинство подобных устройства используют батарейное питание, некоторые работают на заряжаемых никель-кадмиевых аккумуляторах. На рис. 12.1 показаны популярные приборы фирмы Microsoft для диагностики ЛВС.

Рис. 12.1. Семейство приборов фирмы Microsoft для диагностики кабелей и соединений в ЛВС

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

БУДУЩЕЕ КАБЕЛЬНЫХ ТЕСТЕРОВ

Производители кабельных тестеров подняли технологию анализа кабелей на очень высокий уровень. Новые устройства расширяют область действия таких тестеров в сферу анализа протоколов. Приборы Fluke 670 LanMeter и FrameScope вышли за пределы физического уровня модели 081 и вторглись в область 2, 3 и даже 4 уровней. Цены на приборы Fluke-670 и FrameScope равны 6000 и 4000 долларам соответственно, что гораздо меньше стоимости анализатора протоколов.
Различные модели этих приборов можно подключать к ЛВС, работающим с физическими протоколами EtherNet или Token Ring для набора статистики, анализа работоспособности и производительности ЛВС. Обычно, под статистикой понимают число пакетов сообщений (суммарное или заданного типа) прошедших за определенное: время. Для ЭДПВС с протоколом EtherNet приборы показывают избыток коллизий (выявляя неисправный адаптер), запаздывающие Коллизии (кабель с очень длинный) и число ошибочных кадров (результат плохого; соединения). В ЛВС с протоколом Token Ring каждый из приборов может распознавать и пересчитывать число кадров уровня MAC.
Вы имеете возможность просмотра общего графика ЛВС, определенного типа ошибочных ситуаций и графика одного из узлов ЛВС., Можно определить узел в большей степени занимающий трафик ЛВС при передаче или приеме кадров. Можно также послать сообщение файловому серверу; или любому другому узлу для определения присутствия этого узла. Если вы определите, что некий кабель или сетевой адаптер мешает работе ЛВС, то, имеется возможность удалить его из кольца. Вы можете контролировать статус: мостов и маршрутизаторов и даже определить время оборота маркера в ЛВС. Эти устройства позволяют вам ассоциировать имена рабочих станций с сетевыми адресами, позволяя видеть, кто из пользователей сети активен в настоящий момент и имеет нормальное соединение с ЛВС. Таким образом, вам не приходиться запоминать, что, например, узел с номером 10005А123466 - эти ПК Маши. Они также имеют последовательные порты, через которые можно осуществлять загрузку программ во флэш-ПЗУ. Конечно, эти приборы позволяют выполнять большую работу по тестированию кабелей, чем можно было бы ожидать от рефлектометров.
Тестеры имеют достаточного размера жидкокристаллические дисплеи с первого взгляда напоминают карманную компьютерную игру. Но именно этот карманный прибор может вылечить вашу ЛВС и, вероятно, в будущем найдет свое место среди ваших инструментов для обслуживания компьютерных сетей.

Что касается кабеля, то короткие замыкания или обрывы могут возникнуть через месяцы после установки ЛВС в результате высыхания его изоляции. С другой стороны, вымокший в воде кабель также не сможет хорошо выдерживать график ЛВС. В процессе разводки кабельных трасс ЛВС часто приходится изгибать кабели, в результате чего в его изоляции могут возникнуть трещины. Все эти неполадки скажутся на работе ЛВС не сразу, а через какое-то время.
Другие неполадки, связанные с кабелями, возникают уже при производстве или установке кабеля. Например, при некачественной распайке концов даже исправный кабель не будет работать. Аналогичная ситуация возникнет и при перепутывании различных пар кабеля. Кроме того, если при планировании, установке или модернизации сети были нарушены приведенные выше (см. главу 5) ограничения на размеры кабеля, то сеть будет работать нестабильно. Одним словом, ошибиться здесь довольно легко.
Перед присоединением вашего кабельного тестера к ЛВС вы должны абсолютно точно знать тип кабеля вашей ЛВС, так как необходимо задать используемому тестеру номинальную скорость распространения сигналов в кабеле для правильного определения расстояний. Эта скорость выражается в долях скорости света и меняется от 0,6 до 0,9. Даже отличие в изоляции (вспененная или невспененная) кабеля влияет на эту величину. Первое, что необходимо сделать с новым тестером - это откалибровать его по отношению к типу кабеля, который вы используете. При калибровке подбирается точное значение для скорости распространения сигнала в кабеле при измерениях с куском кабеля известной длины.
Вам также необходима точная схема топологии вашей ЛВС для того, чтобы можно было точно локализовать место в кабеле, где возникла неполадка, и проанализировать соответствие ее симптомов известным неполадкам в кабельных соединениях.
Основная процедура использования кабельного тестера очень проста. После отсоединения обеих концов кабеля от ЛВС, вы присоединяете один из них к тестеру, а к другому концу, в случае использования неэкранированной витой пары, присоединяется заглушка. После этого можно проводить тестирование состояния кабеля.
Вы можете (и должны) проверить тестером новые кабели ЛВС. Прежде чем подключиться к файл-серверу, нужно убедиться, что кабели во вновь создаваемой ЛВС или новом ее сегменте могут без помех передавать сетевые сигналы. Если же сеть была установлена сторонней организацией, а вы только поддерживаете ее работоспособность, обязательно убедитесь, что проверка кабелей была проведена во время установки.

Применение сетевых мониторов
Сетевыми мониторами называются компьютеры, подключаемые к ЛВС для контроля графика всей сети или выделенной ее части. С помощью проверки данных в каждом пакете информации, сетевые мониторы могут создавать статистические сообщения об использовании сети, типах пакетов, числе переданных и принятых пакетов сообщений каждым узлом ЛВС и другую важную информацию.
Сетевые мониторы относительно недороги и могут использоваться по одному на каждый сегмент в больших компьютерных сетях. Они обычно работают непрерывно, набирая информацию и контролируя неполадки в ЛВС. Сетевые мониторы могут выполнять свою работу, будучи также частью интегрированной системы управления. Цена сетевых мониторов меняется от нескольких сотен долларов (для чисто программных продуктов) до примерно 10000 долларов. На рис. 12.2 показаны относительно недорогие продукты TXD фирмы Thomas Conrad (195 долларов за лицензию для организации). TXD представляет статистическую и диагностическую информацию о ЛВС, работающей под управлением ОС NetWare.

Рис. 12.2. Программное обеспечение TXD фирмы Thomas-Conrad для диагностики сетей NetWare

Сетевые анализаторы
Хотя сетевые мониторы могут обнаруживать неполадки в сети, но выяснение их причин и их устранение является задачей сетевых анализаторов (иногда называемых анализаторами протокола). Сетевые анализаторы предназначены для анализа графика в реальном масштабе времени и имеют средства для перехватывания и декодирования пакетов, а также могут передавать собственные сообщения. Некоторые из них включают набор средств для экспертизы на определенные типы неполадок и имеют встроенные средства для проведения рефлектометрии. Наиболее сложные сетевые анализаторы снабжены специальными аппаратными средствами для обнаружения неполадок, незаметных на уровне обычных сетевых адаптеров. В последнее время разработчики этих систем стали включать элементы искус-
Сетевые анализаторы являются сложными, дорогостоящими инструментами для обнаружения определенного сорта проблем в ЛВС, Эти приборы обладают гораздо более широкими возможностями, чем кабельные тестеры или различные программные средства, и могут применяться для идентификации неисправных устройств, обнаружения ошибок в конфигурации и "узких мест" ЛВС. Когда вы сталкиваетесь с проблемой, требующей тщательного анализа содержимого пакета сообщения, вы подобны врачу, прибегающему к помощи микроскопа для изучения клеток ткани. Так же, как и врач, вы должны произвести сравнение поврежденных клеток с живыми и выяснить, в каком соотношении друг с другом они находятся.
Сетевые анализаторы могут прослушивать пакеты, проходящие через ЛВС для анализа работы компьютерной сети. Анализатор может также выделять только те пакеты, которые удовлетворяют определенным критериям, перехватывать их и суммировать в файл для последующего разбора их содержания. Критерии отбора пакетов сообщений устанавливаются пользователем и могут быть направленными на выделение только ошибочных кадров или кадров от определенных рабочих станций и серверов, кадров больших размеров или содержащих определенный набор данных и т.п. Некоторые анализаторы позволяют увеличивать трафик ЛВС, симулируя дополнительные узлы. Таким образом, пользователю остается только точно определить, какого рода ошибки нужно искать, а сетевой анализатор определит их с указанием устройства, вызывающего эти ошибки. Однако это не означает, что сетевые анализаторы способны заменить опытного специалиста. Напротив, только очень квалифицированные специалисты смогут эффективно пользоваться этим прибором.
Диапазон цен этих приборов начинается с уровня 10000 и достигает 30000 долларов для приборов с возможностью поддержки различных физических сред и способностью декодирования различных протоколов. Анализаторы продаются как конструкторские наборы или законченные приборы. Конструкторский набор состоит из сетевого адаптера для установки на ПК и программного обеспечения. Законченные приборы поставляются в виде выбранного производителем ПК с установленным адаптером. Популярным сетевым анализатором является система Sniffer производства фирмы Network General. На рис. 12.3 и 12.4 представлены продукты семейства Sniffer.
Обзор прибора Network Advisor фирмы Hewlett-Packard. Сетевой анализатор Network Advisor фирмы Hewlett-Packard представляет собой ПК на базе процессора 80386 с монохромным или цветным жидкокристаллическим дисплеем и сетевым интерфейсом для сбора данных. Программное обеспечение фирмы Hewlett-Packard является надстройкой над DOS. Графический пользовательский интерфейс этой системы не похож на интерфейс пакета Windows или Presentation Manager, но также прост в использовании. Часть программного обеспечения, связанная с искусственным интеллектом. Fault Finder (Обнаружитель сбоев), написана на языке Пролог и содержит более 100 правил.
В ЛВС с протоколом Token Ring при обращении за помощью к Fault Finder он предлагает следующие категории:
контроль сбоев включения новой рабочей станции
контроль аппаратных ошибок
контроль кадров тревоги ("маяков") MAC
контроль переполнения, приемников станции
контроль сигналов тревоги ("маяков") в кольце

Рис. 12.3. Комплекс Sniffer фирмы. Network General обычно состоит из компьютера типа laptop с установленным программным обеспечением Sniffer

Рис. 12.4. Семейство изделий Sniffer

А затем спрашивает, какую из неполадок искать. Вы можете предложить анализатору попытаться определить это самостоятельно. К примеру, если вы выбрали последнюю категорию, Fault Finder ответит, что
Кольцо считается переполненным сигналами тревоги (маяками), если станция передала 8 последовательных кадров-маяков MAC.
Фирма Hewlett-Packard предполагает дальнейшее совершенствование этого прибора, продвигаясь от нижнего физического уровня ЛВС к более сложным сценариям работы системы.
За исключением компоненты Fault Finder система Network Advisor имеет в основном те же функции и возможности, что и другие сетевые анализаторы. Она способна захватывать пакеты в течение определенного периода, использовать введенные пользователем фильтры, декодировать кадры уровня MAC, кадры системы AppleTalk, кадры NetWare (IPX, SPX и NCP, а также NetWare Core Protocol), кадры IBM (NetBIOS и 8MB), кадры SNA фирмы IBM и кадры TCP/IP. Подробнее с системой Network Advisor можно познакомиться в:
Hewlett-Packard Company
5070 Centennial Boulevard
Colorado Springs, CO 80919
(719) 531-4497 Fax:
(719) 531-4505

Обзор прибора Sniffer фирмы Network General. Среди других сетевых анализаторов прибор Sniffer выделяется тем, что может декодировать и интерпретировать кадры наибольшего числа протоколов в наибольшем количестве сетей. Однако он не предлагает так же много способов классификации действий в ЛВС, управляемой ОС NetWare, как LANalyzer фирмы Novell, и пользоваться им не так просто, как анализатором LANalyzer. К примеру, если нужно определить, сколько запросов на просмотр директорий выдает некоторая рабочая станция, то сперва необходимо сообщить анализатору, какую структуру данных требуется искать, то есть какие байты в каком месте кадра определяют запрос на просмотр директории. Эту информацию легко считать с экрана Sniffer, но все же приходится вводить задание для поиска в виде набора байтов и их смещений в кадре. В противоположность этому, в LANalyzer в такой ситуации нужно просто выбрать категорию Directory Search (Поиск запросов к директории).
Sniffer может демонстрировать статистику графика ЛВС, давая возможность определить качество работы сети. Чтобы получить представление о том, как выглядит такая статистика, можно взглянуть на рис. 12.5, где показана абсолютная статистика графика при работе Sniffer. На рис. 12.6 изображен также экран, демонстрирующий статус сервера.
В ЛВС Token Ring неисправный сетевой адаптер обычно передает следующему узлу кольца ошибочные данные, поэтому тот в свою очередь начинает периодически выдавать сигнал тревоги (наподобие маяка). Вся работа сети останавливается до тех пор, пока неисправный адаптер не будет найден и заменен. Sniffer способен определить наличие маяков - сигналов тревоги - и указать адрес неисправного узла.

Рис, 12.5. Абсолютная статистика трафика, показанная прибором Sniffer фирмы Network General

Рис. 12.6. Статус сервера, показанный прибором Sniffer

Обнаружение неисправного оборудования и ошибочных кадров на нижних уровнях работы сети - это только один из классов задач, решаемых сетевыми анализаторами. Другим направлением работы является определение "узких мест" ЛВС, ограничивающих ее производительность. Sniffer способен захватывать кадры, идущие между определенными узлами (например, между рабочей станцией и файл-сервером), и показывать степень использования сети, счетчики кадров и общее количество захваченных байт. При последующем анализе этих данных он выдает пользователю информацию о том, когда каждый из кадров возник в сети и что он содержит. Если у вас зафиксировано, какие действия производил оператор рабочей станции во время захвата кадров, то можно сопоставить эти действия с временными задержками кадров различного типа. Предположим, например, что рабочая станция загрузила с файл-сервера исполняемый файл размером 250К. Sniffer продемонстрировал бы вам 250 запросов от рабочей станции перемежающихся 250 ответами от сервера (если пакеты имеют длину 1К). К сожалению, Sniffer не может точно указать, какое именно устройство сервера оказалось слишком медленным - процессор, жесткий диск или контроллер диска. Он анализирует только график сообщений в сети. Поэтому, чтобы получить ясную картину, администратору приходится проводить контрольные эксперименты: менять число активных рабочих станций, их типы и другие параметры.
Более подробную информацию о системе Sniffer можно получить по адресу:
Network General Corporation
4200 Bohannon Drive
Menlo Park, CA 94025
(415) 688-2700
(800) 952-6300
Fax: (415) 321-0855

Сетевой анализатор LANalyzer фирмы Novell. He подлежит сомнению, что никто не знает NetWare лучше, чем специалисты фирмы Novell. Поэтому анализатор этой фирмы LANalyzer особенно хорошо работает в NetWare. Он выполняет примерно те же функции, что и Sniffer.
В сетевом анализаторе LANalyzer имеется набор предустановленных шаблонов, называемых приложениями, которые можно использовать для фильтрации, интерпретации и представления кадров ЛВС. Например, приложения для физического уровня Token Ring включают Devices, ErrMon, Map, Priority, RingChng и RingMon. Эти приложения, особенно ErrMon и RingMon, позволяют определить состояние сетевых адаптеров и кабельных систем. Приложения, называемые BridgeVu, FileView, NodeView, OverView и ServerVu, работая на более высоких уровнях, могут показать график ЛВС, относящийся к операциям сервера, рабочих стан-Ции и межсетевых мостов. Например, если вам необходимо обнаружить Директиву PATH, которая является причиной поиска большого количества несуществующих директорий при запуске программ, можно наблюдать только за операциями открытия файла или поиска в директории, ^и за тем и другим.
LANalyzer представляет собой плату, вставляемую в ПК, и соответствующее программное обеспечение. Пользовательский интерфейс у нее такой же, как и у других утилит этой фирмы (SYSCON, FILER и т.д.).
Детальную информацию об этом комплексе можно получить в:
Novell, Inc.
LANalyzer Products Division
3 2180 Fortune Drive
San Jose, CA 95131
(408) 434-2300
(800) 243-8526

Интегрированные системы для управления ЛВС
Четвертым и последним типом продуктов для управления ЛВС являются Интегрированные системы, управления ЛВС (INMS - Integrated Network Management Systems). Использование таких систем позволяет осуществлять контроль всей компьютерной сети из единого центра. В функции INMS входят все пять категорий управления вычислительной сетью ISO: сбои, производительность, конфигурация, защита данных и учет.
Использование INMS осуществляется с помощью терминала с графическим пользовательским интерфейсом. Он интегрирован со станцией управления сетью, взаимодействующей для определения состояния сети с сетевыми агентами (например, специальным программным обеспечением рабочих станций) на удаленных компьютерных системах. Эти агенты собирают нужную информацию, такую как число пакетов, полученных устройством, и при необходимости передают ее в INMS. При возникновении проблем агенты также могут посылать сигналы тревоги на терминал для непосредственного предупреждения администратора сети. INMS являются наиболее дорогостоящими средствами для управления компьютерными сетями.

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

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

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

ЗНАНИЕ НОРМАЛЬНОГО СОСТОЯНИЯ

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

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

Создание списка возможных причин неполадок
Обладая необходимыми опытом и знаниями и имея под рукой характеристики нормального режима работы сети, можно произвести их сопоставление с симптомами неполадок и определить их причины.
Для создания списка возможных неполадок вам необходимо знать, как влияет выход из строя отдельного компонента на работу компьютерной сети. Например, превышение графика может вызвать увеличение числа коллизий в ЛВС с протоколом EtherNet, но слишком длинный сегмент сети или выход из строя трансивера проявляются так же.

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

Общие проблемы

Типичный администратор ЛВС тратит большую часть своего времени на попытку определения производительности ЛВС. Различные части компьютерной сети подвержены разного типа неполадкам и проявляют различные симптомы.

Аппаратные проблемы
Большинство сетевых проблем возникает на физическом уровне модели 081. Они включают обрывы и короткие замыкания в кабелях, неправильное функционирование адаптера и т.п.

Проблемы с кабелями
Обнаружить неполадки в кабельной сети можно с помощью сетевого анализатора или рефлектометра. Нередко при попытке анализа ошибок в графике сети с помощью сетевого анализатора обнаруживаются неполадки в сетевой электронике. Без этого прибора вам пришлось бы искать причину сбоев методом последовательного исключения компонент сети. Еще одним полезным инструментом для обнаружения дефектов в кабелях являются системы контроля кабелей (подробнее они описаны в разделе "Управление сетевым хозяйством ЛВС" ниже в данной главе).

Практика настройки производительности сети

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

НАСТРОЙКА ПРОИЗВОДИТЕЛЬНОСТИ ЛВС

Если управление ЛВС - это искусство и наука, то для поиска «узких мест» в ЛВС нужно быть волшебником с ученой степенью в радиотехнике. Вы можете получить со стороны советы наподобие «Купи более быстрый диск для сервера», «Перейти на Token Ring», №перейти на EtherNet», «Перейти на NetWare», «Перейти на OS/2 LAN Manager». Однако нередко выясняется что после выполнения какого-либо, совета и замены компонента производительность сети не изменилась. «Узкое место» оказалось в другом элементе.
При поиске "узких мест" вам будете полезна информация приведенная ниже.

Факторы, определяющие производительность ЛВС
Когда запускается какое-либо -приложение, .которое; находится на файл-сервере и, в свою очередь, читает и записывает файлы на диске сервера, активность сети возрастает. Прежде всего процессор COMMAND.COM ищет исполняемый файл в каждой директорий, указанной в спецификация PATH. Этот поиск обуславливает диалог сетевыми сообщениями для каждой директории рабочая станция посылает сообщение-запрос «Find File» (Поиск файла), и сервер возвращает ответ. Затем исполняемый файл загружается в память вашей рабочей станций с помощью новой серии сетевых сообщений, обычно пакетов размером 512 или 1024 байт. После загрузки прикладная программа выдает запросы на открытие, чтение, запись и закрытие файлов, которые превращаются в сообщения для сервера. Сервер отвечает на каждый запрос посланиями "ОК" или "Данные здесь". К тому же в сетях на базе |NetBIOS приемник по отдельности подтверждает получение каждого сообщения. В сетях NetWare подтверждение и ответ находятся в одном сообщении.
Сервер должен обслуживать очередь запросов от большого числа рабочих, станций в ЛВС, и это может занимать много времени. При использовании сервера для дистанционной печати могут возникать две проблемы. Множество запросов печати может настолько занимать файловый сервер, что сильно замедляет его реакцию на другие запросы. В дополнение ко всему, сообщения рабочих станции и файлового сервера могут пересекать один или более сетевых мостов, что создаст дополнительную задержку.
Программное обеспечение верхнего уровня (такое, как NEXT.COM в NetWare) осуществляет фильтрацию запросов на обслуживание файлов или принтера и создает одну или более записей сообщений, которые передает на более низкий уровень (IPX.COM). На этом уровне производится передача запросов сетевым драйверам устройств. Драйвер осуществляет передачу данных через 8, 16 или 32 разрядный разъем сетевому адаптеру, который посылает запрос, как только получит доступ к кабелю. На сервере сетевое программное обеспечение проводит данные через множество слоев протоколов до того, как оно будет обработано ОС. Если не весь объем сообщения может быть принят за один прием из-за ограничений памяти (кэш-памяти сервера), то возникнет дополнительная задержка из-за переброски данных на накопитель файлового сервера. Ответное сообщение к рабочей станции проделает обратный путь через программное обеспечение сетевой адаптер сервера, кабель ЛВС, сетевой адаптер и программное обеспечение рабочей станции. Так, только для загрузки в ОЗУ рабочей станции программного файла длиной 250К при использования пакетов длиной 512 байтов будет необходимо выполнить более 500 запросов и 500 ответов. (Большие пакеты вызывают меньшую перегрузку сервера.) И если такие операции выполняют несколько пользователей, то файл-сервер по своему графику напоминает центральный вокзал в Нью-Йорке.

Локализация узких мест
Узким местом ЛВС могут быть рабочие; станции, сетевые драйверы, сетевые резидентные программы; или .сетевые адаптеры. Скорость передачи данных в ЛВС также может быть ограничителем производительности. На сервере центральный Процессор также может иметь недостаточное быстродействие, или сетевое программное обеспечение, может не обладать достаточной эффективностью. Небольшой объем ОЗУ для кэширования файлов также может; быть причиной низкой производительности сервера из-за частых обращений к диску. Кроме того, файл-сервер может проводить слишком много времени, работая как сервер печати. Возможно, быстродействие сервера увеличится, если сконфигурировать его для использования больших пакетов. Не исключено, что производительность сдерживает быстродействие шины. А возможно файл-сервер и сетевой адаптер слишком медленно общаются через 8 разрядный слот. Еще одной причиной может быть малый размер ОЗУ адаптера для буферизации; сетевых сообщений, а также медленная работа сетевого моста. Таким: образом, существует большое количество разного рода причин, ограничивающих производительность ЛВС, это необходимо иметь в виду при поисках возможностей увеличения ее производительности.


Управление сетевым хозяйством ЛВС

Не так давно в помощь администратору компьютерной сети добавилось еще одно средство, позволяющее визуализировать и документировать трассы кабельного хозяйства. В небольших ЛВС для начала достаточно иметь эскиз офиса, на котором показаны кабельные соединения и другие компоненты. Для больших сетей требуется более исчерпывающая начальная информация. Можно использовать систему управления кабелями, которая отобразит план и проследит за всем имеющимся сетевым хозяйством. Сетевое хозяйство - название кабельного оборудования, получившее популярность, среди производителей программ для систем управления кабельным оборудованием сети.
Система управления сетевым хозяйством предлагает целый диапазон средств, позволяющих прослеживать полную физическую инфраструктуру компьютерной сети. Система записывает данные обо всех компонентах, включая их расположение, в базу данных. По запросу она может показать графическое изображение сети с небольшим отчетом о сетевом оборудовании.
Имеется возможность обзора всей компьютерной сети или только отдельных ее деталей. Посредством графического меню можно быстро получить необходимую информацию о сетевых компонентах.
База данных содержит детальную информацию о сетевом хозяйстве - от трассировки кабелей до информации административного характера, связанной с отдельными частями оборудования, кабелями и кабельными трассами. Кроме этого, в базе данных записаны также следующие характеристики:
фабричная марка оборудования, номер модели, цена, расположение в системе, схема соединения и схема разводки проводов.
Эти данные можно использовать для оформления заявок на перемещение, замену или ремонт испорченного оборудования. При этом система хранит историю всех изменений, произведенных в компьютерной сети.

Заключение

В этой главе вы завершили изучение ЛВС, рассмотрев вопросы, методы и инструменты, связанные с управлением сетями. После знакомства с основами систем управления вы рассмотрели протоколы SNMP и CMIP.
Затем обратились к системам управления ЛВС, поставляемым фирмой IBM, сфокусировав основное внимание на возможностях протокола Token Ring. Вы познакомились также с назначением и использованием таких инструментов, как рефлектометры, сетевые мониторы, сетевые анализаторы и интегрированные системы. И наконец, вы имеете список производителей средств управления сетями, который можно использовать для знакомства с определенными компаниями и выпускаемыми ими продуктами.
В следующей главе вы остановитесь на вопросах, с которыми столкнетесь при покупке дополнительных сетевых элементов, считающихся совместимыми с существующей сетью, однако не всегда являющихся таковыми.

Глава 13. Анализ совместимости

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

Пояснение понятия совместимости

Первое, на что хотелось бы обратить внимание при рассмотрении понятия совместимость, это то, что оно совсем не применяется к устройствам, которые действительно совместимы. Например, когда вы покупаете новый телефонный аппарат, а также телефонный шнур к нему с соединителями RJ-11 на концах, а потом включаете телефон в розетку на стене в вашей квартире и звоните с него, то вряд ли вспоминаете об их совместимости. Можно привести еще один пример. Если вы купили в магазине какой-нибудь электроприбор, например, тостер, то сразу включаете его в розетку и начинаете им пользоваться, не задумываясь о совместимости. Это обусловлено тем, что степень совместимости изделий телефонных компаний ч бытовых приборов крайне высока.
Теперь предположим, что нужно объединить несколько различных компьютерных сетей, каждая из которых работает под управлением собственной операционной системы - IBM LAN Server, NetWare, LANtastic, NFS. При этом необходимо организовать вычислительную систему таким образом, чтобы пользователи могли разделять одни и те же ресурсы и файлы на всех серверах. В процессе такой работы вы очень скоро начнете использовать термин совместимость как ругательство.
Если вы покупаете программное обеспечение и аппаратные средства у одного и того же производителя, то сложностей значительно меньше. Фирма IBM, например, распространяет схемы и таблицы, по которым можно определить, какие из ее продуктов совместимы, а какие нет. Однако даже в этом случае остается шанс приобрести несовместимую аппаратуру.
Фирма IBM является очень крупным производителем компьютерного оборудования. Так как это достаточно большая компания, то ее спецификации и рекомендации становятся промышленными стандартами, и это, конечно, оказывает влияние на совместимость. Но, с другой стороны, в модеме производства фирмы IBM используется система команд фирмы Hayes, которая стала стандартной независимо от IBM. Поэтому совместимость более тесно связана не с производителями, а с распространенными стандартами.

Набор протоколов модели OSI

Модель OSI (Open System Interconnection - Связь открытых систем) может использоваться в качестве первого шага для организации совместимых компьютерных сетей. Заметим однако, что эта модель может иметь только рекомендательный характер, так как многие распространенные устройства до сих пор не совместимы с этим стандартом. Тем не менее это важная отправная точка в обсуждениях ЛВС. При анализе совместимости на различных уровнях модели OSI можно обнаружить, что совместимость между различными компонентами становится хуже по мере приближения к верхним уровням стандарта. Это связано с тем, что добиться совместимости особенно непросто именно на верхних уровнях модели OSI.
Модель OSI определяет семь уровней протоколов, разделяемых хорошо определенными интерфейсами. На рис. 5.4 (см. главу 5) показаны эти семь Уровней.
Модель OSI разбивает связь внутри ЛВС на семь независимых частей, или Уровней. Ниже приведено подробное описание этих уровней, а дальше обсуждается проблема совместимости с позиции каждого уровня модели OSI.
Прикладной уровень. Прикладной уровень является самым верхним. В нем осуществляется взаимодействие с пользователем, извлечение информации из баз данных и передача файлов как целого. Прикладной уровень является видимой для пользователя частью модели OSI. На этом уровне попытка доступа к ЛВС трансформируется в запрос, который передается на более низкий уровень - уровень представления. На прикладном уровне не осуществляется никакой реальной работы, а производится передача всех заданий на более низкие уровни. Рабочие запросы, предназначенные для передачи по сети, входят в набор протоколов модели OSI на прикладном уровне, продвигаются вниз по направлению к первому уровню (физическому) где передаются на другую рабочую станцию или файловый сервер, а затем проделывают обратный путь через набор протоколов модели OSI до достижения прикладного уровня на приемном конце.

<< Пред. стр.

стр. 10
(общее количество: 13)

ОГЛАВЛЕНИЕ

След. стр. >>