Диагностика и устранение неисправностей при работе в локальной сети

Министерство образования Московской области

ГБОУ СПО МО Подмосковный колледж «Энергия»

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

по предмету: Компьютерные сети

тема работы: «Диагностика и устранение неисправностей при работе в локальной сети»

Студент ___3ИС-1−11

Е.А. Маляров

Специальность _230 401

«Информационные системы (по отраслям)

Московская область

2014 г.

• Введение
• Глава 1. Теоретическая часть. Диагностика локальных сетей
• 1.1. Необходимость создания и применения средств и систем диагностики сетей
• 1.2. Инструменты диагностики
• Глава 2. Организация диагностики компьютерной сети
• 2.1. Общая модель решения проблемы поиска неисправностей
• 2.2. Организация диагностики компьютерной сети
• 2.3. Методика упреждающей диагностики
• 2.4. Организация процесса диагностики
• Глава 3. Практическая часть. Устранение неисправностей в локальной сети
• 3.1. Общие положения
• 3.2. Некоторые частные примеры устранения неполадок сети
• 3.3. Коды ошибок в локальной сети и их устранение
• Заключение
• Литература
• Приложение

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

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

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

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

Глава 1. Диагностика локальных сетей

1.1 Необходимость создания и применения средств и систем диагностики сетей

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

Вместе с тем, по мере осуществления технологических перемен некоторые предыдущие проблемы решились автоматически. Коаксиальный кабель, в котором найти электротехнические неисправности было тяжелее, чем в случае витой пары, становится малоупотребительным в корпоративных средах. Сети Token Ring, главным затруднением которых была их различность с Ethernet, со временем заменяются коммутируемыми сетями Ethernet. Вызывающие многочисленные сообщения об ошибках протоколов сетевого уровня протоколы, такие, как SNA, DECnet и AppleTalk, замещаются протоколом IP. Сам же стек протоколов IP стал более стабильным и легким для поддержки, что доказывают миллионы потребителей и миллиарды страниц Web в Internet. Даже злостным оппонетнам Microsoft приходится признаться, что подключение нового клиента Windows к Internet значительно проще и надежнее установки применявшихся ранее стеков TCP/IP сторонних поставщиков и отдельного программного обеспечения коммутируемого доступа.

Насколько многочисленные современные технологии ни усложняют обнаружение неполадок и координацию производительностью сетей, положение могло бы оказаться еще сложнее, если бы технология АТМ получила широкое расширение на уровне ПК. Своё положительное значение дало и то, что в конце 90-х, ещё не получив признания, были отринуты и некоторые другие высокоскоростные технологии обмена данными, наряду с Token Ring с пропускной способностью 100 Мбит/с, 100VG-AnyLAN и усовершенствованные сети ARCnet. Наконец, в США был отклонен очень сложный стек протоколов OSI (который узаконен некоторыми правительствами европейских государств).

Стуктурно-иерархическая система корпоративных сетей с магистральными каналами Gigabit Ethernet и выделенными портами коммутаторов на 10 либо 100 Мбит/с для отдельных пользовательских систем, дала возможность увеличения максимальной пропускной способности, потенциально доступной клиентам минимум в 10—20 раз. Безусловно, в большинстве корпоративных сетей существуют непростые моменты на уровне серверов или маршрутизаторов доступа, ввиду приходящейся на отдельного пользователя пропускной способности существенно меньшей, чем 10 Мбит/с. Потому замена порта концентратора с пропускной способностью 10 Мбит/с на выделенный порт коммутатора на 100 Мбит/с для конечного узла далеко не всегда приводит к значительному увеличению скорости. Как бы то ни было, если учесть, что стоимость коммутаторов в последнее время снизилась, а на большинстве предприятий и организаций проложен кабель Категории 5, поддерживающий технологию Ethernet на 100 Мбит/с, и установлены сетевые карты, способные работать на скорости 100 Мбит/с сразу после перезагрузки системы, то становится очевидно, почему так нелегко устоять перед искушением усовершенствований. В традиционной локальной сети с разделяемой средой передачи анализатор протоколов или монитор может исследовать весь трафик данного сегмента сети.

См. Приложение 1. — Традиционная локальная сеть с разделяемой средой передачи и анализатором протоколов.

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

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

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

Частичное решение при анализе агрегированных параметров трафика приобретает применение возможностей мониторинга агентов mini-RMON, строеных в каждый порт большинства коммутаторов Ethernet. Но агенты mini-RMON не поддерживают группу объектов Capture из спецификации RMON II, которые обеспечивают полнофункциональный анализ протоколов, и они позволяют оценить степень использования ресурсов, количество ошибок и объем многоадресной рассылки.

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

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

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

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

Предприятиям и организациям, которые развернули крупную оптическую инфраструктуру и обслуживают её самостоятельно, может понадобиться оптический временный рефлектометр (Optical Time Domain Reflecto-meter, OTDR), выполняющий те же функции для оптического волокна, что и рефлектометр для медного кабеля (Time Domain Reflectometer, TDR). Этот прибор действует подобно радару: он посылает импульсные сигналы по кабелю, анализирует их отражения, на основании которых выявляет повреждения в проводнике или другую аномалию, затем сообщает эксперту, в каком месте кабеля возможно отыскать источник проблемы.

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

Во время диагностики локальных беспроводных сетей стандарта 802.11b также возникают определенные проблемы. Фактически диагностика проста поскольку беспроводная среда передачи информации распределяется между всеми обладателями радиоустройств клиентов. Компания Sniffer Technologies впервые предложила решение для анализа протоколов таких сетей с пропускной способностью до 11 Мбит/с. Впоследствии большинство лидирующих поставщиков анализаторов предоставили аналогичные системы.

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

Известно, что операторы беспроводных корпоративных сетей должны препятствовать развертыванию чрезмерно открытых систем, где каждый пользователь в зоне действия сети, обладающий совместимой интерфейсной картой, получает доступ к любому информационному кадру системы. Протокол безопасности беспроводных сетей WEP (Wired Equivalent Privacy) обеспечивает пользовательскую аутентификацию, как гарантию целостности и шифрования данных, но из-за совершенной системы безопасности усложняется анализ причин неполадок сети. В защищенных сетях с поддержкой WEP специалисты по диагностике должны иметь ключи или пароли, защищающие информацию и контролирующие доступ к системе. При доступе в режиме приема всех пакетов анализатор протоколов сможет видеть все заголовки кадров, однако, содержащаяся в них информация будет бессмысленной, без наличия ключей.

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

В результате, проблема диагностики компьютерных сетей является актуальной, а диагностирование неисправностей является задачей управления. Для большинства критически важных систем, проведение продолжительных по времени восстановительных работ не допустимо, потому единственным решением видится использование резервных устройств и процессов, которые немедленно после возникновения сбоев способны взять на себя необходимые функции. На ряде предприятий сети имеют резервный компонент на случай сбоя основного, т. е. nх2 компонентов, где n — количество основных компонентов, необходимое для обеспечения приемлемой производительности. Если среднее время восстановления (Mean Time To Repair, MTTR) достаточно велико, то может понадобиться еще большая избыточность компонентов. Всё дело в том, что время устранения неисправности предсказать нелегко, и значительные затраты в течение непредсказуемого периода восстановления являются признаком плохого управления.

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

1.2 Инструменты диагностики

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

Целесообразно начать рассмотрение с физической плоскости. Для решения проблемы на этом уровне и в электрических или оптических средах передачи данных существуют кабельные тестеры и специализированные инструменты — рефлектометры (Time Domain Reflectometers, TDRs). За более чем 15 лет активного развития корпоративных локальных сетей в результате образования потребности профессиональных сетевых интеграторов в кабельных тестерах реализовано множество функций; примером может служить выполнение автоматизированных тестовых последовательностей с возможностью печати сертификационных документов на основании результатов теста. Тем не менее, в сетях Ethernet с пропускной способностью 10 Мбит/с порой допускаются некоторые вольности в отношении качества их прокладки; технологии 100BaseT и Gigabit Ethernet с медным кабелем намного требовательнее. Как результат, современные кабельные тестеры весьма многосложны.

В число основных поставщиков кабельных тестеров входят компании Fluke Networks, Microtest, Agilent, Acterna и Datacom Textron.

Для диагностики проблем на физическом плане уместно использование следующих средств:

1) Разъем-заглушка (Hardware loopback) — это разъем, замыкающий выходную линию на входную, это компьютеру передавать данные самому себе. Разъем-заглушка используется при диагностике оборудования.

2) Расширенный тестер кабеля (Advanced cable tester; Cable tester) — специальное средство для ведения мониторинг трафика сети и отдельного компьютера и выявления определенных видов ошибок, неисправного кабеля или сетевой платы.

3) Рефлектометр (Time-domain reflectometer) — устройство, для выявления дефектов кабельных линий локационным (рефлектометрическим) методом. Рефлектометр посылает по кабелю короткие импульсы, обнаруживает и классифицирует разрывы, короткие замыкания и другие дефекты, плюс, измеряет длину кабеля и его волновое сопротивление и выдает результаты на экран.

4) Тоновый генератор (Tone generator) — прибор, генерирующий в кабеле переменный или непрерывный тоновый сигнал, по которому тоновый определитель проверяет целостность и качество кабеля. Тоновый определитель — прибор, позволяющий определить целостность и качество кабеля, на основе анализа сигналов, испускаемых тоновым генератором.

5) Цифровой вольтметр (Digital voltmeter) — электронное измерительное устройство общего назначения. Вольтметр позволяет измерять напряжение тока, проходящего через резистор, и определять целостность сетевых кабелей.

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

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

В число лидирующих поставщиков анализаторов протоколов локальных сетей входят Network Associates/Sniffer Technologies, Shomiti, Acterna (прежнее название WWG), Agilent, GN Nettest, WildPackets и Network Instruments.

Третьим диагностическим инструментом является зонд или монитор. Монитор сети (Network monitor) — это программно-аппаратное устройство по отслеживанию сетевого трафика и проверки пакетов на уровне кадров, собирающее информацию о типах пакетов и ошибках.

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

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

Еще одним инструментом диагностики являются интегрированные диагностические средства. Производители диагностического оборудования объединили функции всех перечисленных традиционных инструментов в портативных устройствах для обнаружения распространенных неисправностей на нескольких уровнях OSI. Например, некоторые из этих устройств осуществляют проверку основных параметров кабеля, отслеживают количество ошибок на уровне Ethernet, обнаруживают дублированные IP-адреса, осуществляют поиск и подключение к серверам Novell NetWare, а также отображают распределение в сегменте протоколов третьего уровня.

Среди программных средств диагностики компьютерных сетей, можно выделить специальные системы управления сетью (Network Management Systems) — централизованные программные системы, которые собирают данные о состоянии узлов и коммуникационных устройств сети, а также данные о трафике, циркулирующем в сети. Эти системы не только осуществляют мониторинг и анализ сети, но и выполняют в автоматическом или полуавтоматическом режиме действия по управлению сетью — включение и отключение портов устройств, изменение параметров мостов адресных таблиц мостов, коммутаторов и маршрутизаторов и т. п. Примерами систем управления могут служить популярные системы HPOpenView, SunNetManager, IBMNetView.

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

Экспертные системы. Этот вид систем аккумулирует человеческие знания о выявлении причин аномальной работы сетей и возможных способах приведения сети в работоспособное состояние. Экспертные системы часто реализуются в виде отдельных подсистем различных средств мониторинга и анализа сетей: систем управления сетями, анализаторов протоколов, сетевых анализаторов. Простейшим вариантом экспертной системы является контекстно-зависимая help-система. Более сложные экспертные системы представляют собой так называемые базы знаний, обладающие элементами искусственного интеллекта. Примером такой системы является экспертная система, встроенная в систему управления Spectrum компании Cabletron.

Глава 2. Организация диагностики компьютерной сети

2.1 Общая модель решения проблемы поиска неисправностей

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

На Приложении 1 показана блок — схема общей модели решения проблемы поиска неисправностей. Эта блок — схема не является жесткой схемой поиска неисправностей в объединенной сети, а может служить лишь основой, на которой формируется конкретный процесс устранения нарушений в работе, соответствующий конкретной сетевой среде (см. Приложения.)

Далее описаны конкретные этапы процесса поиска неисправностей.

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

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

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

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

Шаг 5. Осуществите план действий, тщательно выполняя каждый этап и проверяя, удалось ли устранить признаки неисправности.

Шаг 6. После внесения каждого изменения обязательно проконтролируйте результаты. Как правило, для этого должен применяться тот же метод сбора данных, как и на шаге 2 (в частности, при этом снова привлекайте к такой работе заинтересованных специалистов и используйте диагностические инструментальные средства).

Шаг 7. Проанализируйте полученные результаты, чтобы определить, решена ли проблема. В случае положительного ответа процесс поиска неисправности заканчивается.

Шаг 8. Если проблема не решена, разработайте план действий по устранению следующей менее вероятной проблемы из списка. Возвратитесь к шагу 4, снова вносите по одному изменению и повторяйте процесс до тех пор, пока проблема не будет решена.

2.2 Организация диагностики компьютерной сети

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

— выявление дефектов физического плана сети: системы электропитания активного оборудования, кабельной системы, наличия шума от внешних источников;

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

— измерение числа коллизий в сети и выявление их причин;

— измерение числа ошибок передачи данных на уровне канала связи, выявление их причин;

— выявление дефектов архитектуры сети;

— измерение текущей загруженности сервера, определение влияния степени загруженности на время реакции прикладного ПО;

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

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

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

Для проверки сети кабельным сканером вместо активного оборудования к кабелю подключаются с одного конца — сканер, с другого — инжектор. После проверки кабеля сканер и инжектор отключаются, и подключается активное оборудование: сетевые платы, коммутаторы, концентраторы. Но нет полной гарантии, что контакт между активным оборудованием и кабелем будет столь же хорош, как между оборудованием сканера и кабелем. Довольно часто встречаются случаи, когда незначительный дефект вилки RJ-45 не проявляется при тестировании кабельной системы сканером, а обнаруживался впоследствии при диагностике сети анализатором протоколов. См. Приложение 3.

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

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

Второй подход основан на исследовании базовых линий параметров (так называемых трендов), характеризующих работу диагностируемого устройства. Основной принцип второго подхода можно сформулировать следующим образом: «устройство работает хорошо, если оно работает так, как всегда». На этом принципе основана упреждающая (proactive) диагностика сети, цель которой — предотвратить наступление ее критических состояний. Противоположной упреждающей является реактивная (reactive) диагностика, цель которой не предотвратить, а локализовать и ликвидировать дефект. В отличие от первого, данный подход позволяет обнаруживать дефекты, проявляющиеся не постоянно, а время от времени. Недостатком второго подхода является предположение, что изначально сеть работала хорошо. Но «как всегда» и «хорошо» не всегда означают одно и то же.

Третий подход осуществляется посредством контроля интегральных показателей качества функционирования диагностируемого устройства (далее — интегральный подход). Следует подчеркнуть, что с точки зрения методологии диагностики сети между первыми двумя подходами, которые будем называть традиционными, и третьим, интегральным, есть принципиальное различие. При традиционных подходах мы наблюдаем за отдельными характеристиками работы сети и, чтобы увидеть ее «целиком», должны синтезировать результаты отдельных наблюдений. Однако мы не можем быть уверены, что при этом синтезе не потеряем важную информацию. Интегральный подход, наоборот, дает нам общую картину, которая в ряде случаев бывает недостаточно детальной. Задача интерпретации результатов при интегральном подходе, по существу, обратная: наблюдая целое, выявить, где, в каких частностях заключается проблема.

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

2.3 Методика упреждающей диагностики

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

Наблюдаемыми параметрами обычно являются:

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

— параметры работы сервера — утилизация процессора сервера, число отложенных (ждущих) запросов к диску, общее число кэш-буферов, число «грязных» кэш-буферов и т. п.

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

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

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

2.4 Организация процесса диагностики

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

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

Если сеть имеет архитектуру с компактной магистралью (collapsed backbone) и в качестве магистрали используется коммутатор, то анализатор необходимо подключать к тем портам коммутатора, через которые проходит анализируемый трафик. Некоторые программы имеют специальные агенты или зонды (probes), устанавливаемые на компьютерах, подключенных к удаленным портам коммутатора. Обычно агенты (не путать с агентами SNMP) представляют собой сервис или задачу, работающую в фоновом режиме на компьютере пользователя. Как правило, агенты потребляют мало вычислительных ресурсов и не мешают работе пользователей, на компьютерах которых они установлены. Анализаторы и агенты могут быть подключены к коммутатору двумя способами.

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

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

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

Во-первых, анализатор протоколов должен иметь встроенную функцию генерации трафика Во-вторых, анализатор протоколов должен уметь «прореживать» принимаемые кадры, т. е. принимать не все кадры подряд, а, например, каждый пятый или каждый десятый с обязательной последующей аппроксимацией полученных результатов. Если эта функция отсутствует, то при сильной загруженности сети, какой бы производительностью ни обладал компьютер, на котором установлен анализатор, последний будет «зависать» и/или терять кадры. Это особенно важно при диагностике быстрых сетей типа Fast Ethernet и FDDI.

Предлагаемую методику мы будем иллюстрировать на примере использования чисто программного анализатора протоколов Observer компании Network Instruments — это мощный анализатор сетевых протоколов и средство для мониторинга и диагностики сетей Ethernet, беспроводных сетей стандарта 802.11 a/b/g, сетей Token Ring и FDDI. Observer позволяет в режиме реального времени измерять характеристики работы сети, осуществлять декодирование сетевых протоколов (поддерживается более 500 протоколов), создавать и анализировать тренды характеристик работы сети.

Рассмотрим поэтапно действия системного администратора для проведения диагностики сети в случае, когда прикладное программное обеспечение в сети Ethernet стало работать медленно, и необходимо оперативно локализовать и ликвидировать дефект.

Первый этап: Измерение утилизации сети и установление корреляции между замедлением работы сети и перегрузкой канала связи.

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

Параметр «Утилизация канала связи» характеризует величину загруженности сети. Канал связи сети является общим сетевым ресурсом, поэтому его загруженность влияет на время реакции прикладного программного обеспечения. Первоочередная задача состоит в определении наличия взаимозависимости между плохой работой прикладного программного обеспечения и утилизацией канала связи сети. Предположим, что анализатор протоколов установлен в том домене сети (collision domain), где прикладное ПО работает медленно. Средняя утилизация канала связи составляет 19%, пиковая доходит до 82%. Но сделать на основании этих данных достоверный вывод о том, что причиной медленной работы программ в сети является перегруженность канала связи нельзя.

Часто можно слышать о стандарте де-факто, в соответствии с которым для удовлетворительной работы сети Ethernet утилизация канала связи «в тренде» (усредненное значение за 15 минут) не должна превышать 20%, а «в пике» (усредненное значение за 1 минуту) — 35−40%. Приведенные значения объясняются тем, что в сети Ethernet при утилизации канала связи, превышающей 40%, существенно возрастает число коллизий и, соответственно, время реакции прикладного ПО. Несмотря на то, что такие рассуждения в общем случае верны, безусловное следование подобным рекомендациям может привести к неправильному выводу о причинах медленной работы программ в сети. Они не учитывают особенности конкретной сети, а именно: тип прикладного ПО, протяженность домена сети, число одновременно работающих станций.

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

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

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

Если рабочая станция и сервер обладают высокой производительностью, и между ними идет обмен большими порциями данных, то утилизация в канале связи может достигать 80−90% (особенно в пакетном режиме — burst mode). Это абсолютно не замедляет работу сети, а, наоборот, свидетельствует об эффективном использовании ее ресурсов прикладным ПО.

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

Правило 1.2 Высокая утилизация канала связи сети только в том случае замедляет работу конкретного прикладного ПО, когда именно канал связи является «узким местом» для работы данного конкретного ПО.

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

В какой мере канал связи ответственен за недостаточную производительность системы, можно выяснить следующим образом. Выбрав наиболее массовую операцию данного прикладного ПО (например, для банковского ПО такой операцией может быть ввод платежного поручения), следует определить, как утилизация канала связи влияет на время выполнения такой операции. Проще всего это сделать, воспользовавшись функцией генерации трафика, имеющейся в ряде анализаторов протоколов (например, в Observer). С помощью этой функции интенсивность генерируемой нагрузки следует наращивать постепенно, и на ее фоне производить измерения времени выполнения операции. Фоновую нагрузку целесообразно увеличивать от 0 до 50−60% с шагом не более 10%.

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

В данном эксперименте фоновую нагрузку не следует задавать более 60−70%. Даже если канал связи не является узким местом, при таких нагрузках время выполнения операций может возрасти вследствие уменьшения эффективной пропускной способности сети.

Правило 1.3 Максимально допустимая утилизация канала связи зависит от протяженности сети.

При увеличении протяженности домена сети допустимая утилизация уменьшается. Чем больше протяженность домена сети, тем позже будут обнаруживаться коллизии. Если протяженность домена сети мала, то коллизии будут выявлены станциями еще в начале кадра, в момент передачи преамбулы. Если протяженность сети велика, то коллизии будут обнаружены позже — в момент передачи самого кадра. В результате накладные расходы на передачу пакета (IP или IPX) возрастают. Чем позже выявлена коллизия, тем больше величина накладных расходов и большее время тратится на передачу пакета. В результате время реакции прикладного ПО, хотя и незначительно, но увеличивается.

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

Второй этап: Измерение числа коллизий в сети.

Если две станции домена сети одновременно ведут передачу данных, то в домене возникает коллизия. Коллизии бывают трех типов: местные, удаленные, поздние. Местная коллизия (local collision) — это коллизия, фиксируемая в домене, где подключено измерительное устройство, в пределах передачи преамбулы или первых 64 байт кадра, когда источник передачи находится в домене. Алгоритмы обнаружения местной коллизии для сети на основе витой пары (10BaseT) и коаксиального кабеля (10Base2) отличны друг от друга.

В сети 10Base2 передающая кадр станция определяет, что произошла локальная коллизия по изменению уровня напряжения в канале связи (по его удвоению). Обнаружив коллизию, передающая станция посылает в канал связи серию сигналов о заторе (jam), чтобы все остальные станции домена узнали, что произошла коллизия. Результатом этой серии сигналов оказывается появление в сети коротких, неправильно оформленных кадров длиной менее 64 байт с неверной контрольной последовательностью CRC. Такие кадры называются фрагментами (collision fragment или runt). В сети 10BaseT станция определяет, что произошла локальная коллизия, если во время передачи кадра она обнаруживает активность на приемной паре (Rx).

Удаленная коллизия (remote collision) — это коллизия, которая возникает в другом физическом сегменте сети (т. е. за повторителем). Станция узнает, что произошла удаленная коллизия, если она получает неправильно оформленный короткий кадр с неверной контрольной последовательностью CRC, и при этом уровень напряжения в канале связи остается в установленных пределах (для сетей 10Base2). Для сетей 10BaseT/100BaseT показателем является отсутствие одновременной активности на приемной и передающей парах (Tx и Rx).

Поздняя коллизия (late collision) — это местная коллизия, которая фиксируется уже после того, как станция передала в канал связи первые 64 байт кадра. В сетях 10BaseT поздние коллизии часто фиксируются измерительными устройствами как ошибки CRC. Если выявление локальных и удаленных коллизий, как правило, еще не свидетельствует о наличии в сети дефектов, то обнаружение поздних коллизий — это явное подтверждение наличия дефекта в домене. Чаще всего это связано с чрезмерной длиной линий связи или некачественным сетевым оборудованием.

Помимо высокого уровня утилизации канала связи коллизии в сети Ethernet могут быть вызваны дефектами кабельной системы и активного оборудования, а также наличием шумов. Даже если канал связи не является узким местом системы, коллизии несущественно, но замедляют работу прикладного ПО. Причем основное замедление вызывается не столько самим фактом необходимости повторной передачи кадра, сколько тем, что каждый компьютер сети после возникновения коллизии должен выполнять алгоритм отката (backoff algorithm): до следующей попытки выхода в канал связи ему придется ждать случайный промежуток времени, пропорциональный числу предыдущих неудачных попыток. В этой связи важно выяснить, какова причина коллизий — высокая утилизация сети или «скрытые» дефекты сети. Чтобы это определить, мы рекомендуем придерживаться следующих правил:.

Правило 2.1 Не все измерительные приборы правильно определяют общее число коллизий в сети. Практически все чисто программные анализаторы протоколов фиксируют наличие коллизии только в том случае, если они обнаруживают в сети фрагмент, т. е. результат коллизии. При этом наиболее распространенный тип коллизий — происходящие в момент передачи преамбулы кадра (т. е. до начального ограничителя кадра (SFD)) — программные измерительные средства не обнаруживают, так уж устроен набор микросхем сетевых плат Ethernet. Наиболее точно коллизии обнаруживают аппаратные измерительные приборы, например LANMeter компании Fluke.