
- •1. Введение
- •1.1. Основные задачи оптимизации локальных сетей
- •1.2. Критерии эффективности работы сети
- •1.2.1. Время реакции
- •1.2.2. Пропускная способность
- •1.2.3. Показатели надежности и отказоустойчивости
- •2. Параметры оптимизации транспортной подсистемы
- •2.1. Влияние на производительность сети типа коммуникационного протокола и его параметров
- •2.1.1. Номинальная и эффективная пропускная способность протокола
- •2.1.2. Влияние на производительность алгоритма доступа к разделяемой среде и коэффициента использования
- •2.1.3. Влияние размера кадра и пакета на производительность сети
- •2.1.4.Назначение максимального размера кадра в гетерогенной сети
- •2.1.5. Время жизни пакета
- •2.1.6. Параметры квитирования
- •2.1.7. Сравнение сетевых технологий по производительности: Ethernet, TokenRing, fddi, 100vg-AnyLan, FastEthernet, atm
- •2.1.8. Сравнение протоколов ip, ipx и NetBios по производительности
- •2.2. Влияние широковещательного служебного трафика на производительность сети
- •2.2.1. Назначение широковещательного трафика
- •2.2.2. Поддержка широковещательного трафика на канальном уровне
- •2.2.3. Широковещательный шторм
- •2.2.4. Поддержка широковещательного трафика на сетевом уровне
- •2.2.5. Виды широковещательного трафика
- •2.2.5.1. Широковещательный трафик сетей NetWare
- •2.2.5.2. Широковещательный трафик сетей tcp/ip
- •2.2.5.3. Широковещательный трафик сетей NetBios
- •2.2.5.4. Широковещательный трафик мостов и коммутаторов, поддерживающих алгоритм SpanningTree
- •2.2.5.5. Ограничение уровня широковещательного трафика в составных сетях с помощью техники спуфинга
- •2.3. Влияние топологии связей и производительности коммуникационных устройств на пропускную способность сети
- •2.3.1. Разделяемая среда передачи как причина снижения производительности сети
- •2.3.2. Повышение производительности путем сегментации сети мостами и коммутаторами
- •2.3.2.1. Разделение общей среды с помощью локальных мостов
- •2.3.2.2. Требования к пропускной способности моста
- •2.3.2.3. Сегментация сетей с помощью коммутаторов
- •2.3.2.4. Оценка необходимой общей производительности коммутатора
- •2.3.3. Влияние маршрутизаторов на производительность сети
- •2.3.4. Как интерпретировать результаты тестирования мостов, коммутаторов и маршрутизаторов
- •2.4. Типичные ошибочные ситуации: влияние на производительность и диагностика
- •2.4.1. Типичные ошибки в кадрах
- •2.4.1.1. Ошибки в кадрах, связанные с коллизиями
- •2.4.1.2. Диагностика коллизий
- •2.4.1.3. Ошибки кадров Ethernet, связанные с длиной и неправильной контрольной суммой
- •2.4.1.4. Ошибки кадров Ethernet в стандарте rmon
- •2.4.2. Типичные ошибки при работе протоколов
- •2.4.2.1. Несоответствие форматов кадров Ethernet
- •2.4.2.2. Потери пакетов и квитанций
- •2.4.2.3. Несоответствие разных способов маршрутизации в составной сети
- •2.4.2.4. Несуществующий адрес и дублирование адресов
- •2.4.2.5. Превышение значений тайм-аута и несогласованные значения тайм-аутов
- •2.5. Настройка параметров аппаратных и программных средств конечных узлов
- •2.5.1. Оптимизация операционных систем
- •2.5.1.1. Критерии оптимизации ос
- •2.5.1.2. Понятие "узкое место"
- •2.5.2. Процедуры оптимизации WindowsNt с помощью утилиты PerformanceMonitor
- •2.5.2.1. Характеристика PerformanceMonitor
- •2.5.2.2. Наблюдение за потреблением ресурсов процессора, дисков и памяти
- •2.5.2.3. Оптимизация сетевого оборудования
- •2.5.2.4. Оптимизация сервиса рабочей станции
- •2.5.2.5. Оптимизация сервера
- •2.5.2.6. Оптимизация режима работы протокола smb
- •2.5.3. Настройка подсистемы ввода-вывода рабочих станций и серверов
- •2.5.3.1. Оптимизация дискового кэша
- •2.5.3.2. Использование raid-массивов для повышения производительности
- •3. Инструменты мониторинга и анализа сети
- •3.1. Классификация средств мониторинга и анализа
- •3.1.1. Системы управления
- •3.1.2. Встроенные средства мониторинга и анализа сетей
- •3.1.2.1. Агенты snmp
- •3.1.2.2. Агенты rmon
- •3.1.3. Анализаторы протоколов
- •3.1.4. Оборудование для диагностики и сертификации кабельных систем
- •3.1.4.1. Основные электромагнитные характеристики кабельных систем
- •3.1.4.2. Сетевые анализаторы
- •3.1.4.3. Кабельные сканеры
- •3.1.4.4. Тестеры
- •3.2. Продукты для мониторинга и анализа
- •3.2.1. Обзор популярных систем управления: hpOpenView, SunSoftSolstice, CabletronSpectrum, ibmNetView
- •3.2.2. Система управления сетями Optivity
- •3.2.2.1. Динамическое обнаружение конфигурации сети
- •3.2.2.2. Программное конфигурирование сети
- •3.2.2.3. Интегрированное управление маршрутизаторами
- •3.2.2.4. Анализ и управление производительностью на основе стандарта rmon
- •3.2.2.5. Упреждающий анализ ошибок и проблем
- •3.2.2.6. Управление устройствами в реальном масштабе времени
- •3.2.2.7. Дополнительные управляющие средства и утилиты
- •3.2.3. Технические характеристики популярных анализаторов протоколов
- •3.2.4. Продукты мониторинга и анализа сетей компании NetworkGeneral
- •3.2.4.1. Foundation Agent, Foundation Probe, Foundation Manager
- •3.2.4.2. Семействопродуктов Distributed Sniffer System
- •3.2.4.3. Портативные анализаторы
- •3.2.4.4. Дополнительные продукты
- •3.2.5. Анализатор протоколов laNalyser компании Novell
- •3.2.6. Продукты компании Microtest
- •3.2.6.1. Многофункциональное устройство Compas компании Microtest
- •3.2.6.2. Кабельные сканеры компании Microtest
- •3.2.7. Средства мониторинга и анализа компании Fluke
- •3.2.7.1. Особенности 68x Enterprise lanMeter
- •3.2.7.2. Функциональные возможности
- •3.2.7.3. Средства анализа протоколов стека NovellNetWare
- •3.2.7.4. Средства анализа протоколов стекаTcp/ip
- •3.2.7.5. Дополнительные функции анализа стека tcp/ip
- •3.2.7.6. Средства анализа протокола NetBios
- •3.2.7.7. Функции проверки аппаратуры и кабелей
- •4. Использование моделирования для оптимизации производительности сети
- •4.1. Методы аналитического, имитационного и натурного моделирования
- •4.2. Модели теории массового обслуживания
- •4.3. Специализированные системы имитационного моделирования вычислительных сетей
- •4.4. Система имитационного моделирования comnet компании caciProducts
- •4.4.1. ComnetBaseliner
- •4.4.2. Comnetiii
- •4.4.2.1. Общая характеристика
- •4.4.2.2. Типы узлов
- •4.4.2.3. Каналы связи и глобальные сети
- •4.4.2.4. Рабочая нагрузка
- •4.4.2.5. Протоколы
- •4.4.2.6. Представление результатов
- •4.4.3. ComnetPredictor
- •4.5. Построение пилотных проектов проектируемых сетей
3.2.4.2. Семействопродуктов Distributed Sniffer System
DistributedSnifferSystem (DSS) - представляет собой систему, состоящую из нескольких распределенных по сети аппаратных компонент и программного обеспечения, необходимого для непрерывного анализа всех, включая удаленные, сегментов сети.
Система DSS строится из компонент двух типов - SnifferServer (SS) и SniffMasterConsole (SM).
Устройства типа SnifferServer представляют собой специализированный программно-аппаратный комплекс, построенный на базе компьютера класса 486 или Pentium, специализированных сетевых карт и дополнительных интерфейсов для взаимодействия с консолью. На сегодня доступны SnifferServer для анализа следующих сетевых технологий LAN и WAN:
Ethernet (10Base-Т, 10Base-2, 10Base-5);
Token Ring (UTP, STP);
FDDI (multimode fiber);
Fast Ethernet (100Base-TX, 100Base-T4);
ATM (ОС-3а multi-mode fiber, OC-3с copper, DS-3 соах, Е-3 соах);
глобальных сетей (RS-232/Р5-449/Ч.35, X.25, framerelay, ISDNBRI и PRI до скоростей Е1 и T1).
В качестве интерфейсов для взаимодействия с консолью могут быть использованы карты Ethernet, TokenRing или последовательный порт. Таким образом, есть возможность контролировать сегмент практически любой сетевой топологии и использовать различные среды взаимодействия с консолью, включая соединения по модему.
SniffMasterConsole - программное обеспечение, выполняющее функции управления всей системой DSS. SniffMaster выпускается в вариантах для работы с MSWindows 3.1 или старше и для работы с различными вариантами Unix и систем управления сетями (HP-UX с НР OpenView, AIX с NetView, SunOS или Solaris с SunNetManager). Система SniffMaster предоставляет пользователю развитый графический интерфейс управления серверами SnifferServer. Одна единственная консоль SniffMaster способна управлять любым количеством серверов SnifferServer любых сетевых топологий. Кроме того, возможна установка нескольких консолей для управления одним сервером SnifferServer или их группой, что позволяет создавать запасные пункты контроля сети и позволяет нескольким экспертам-администраторам совместно решать возникающие задачи.
Система DSS в общих чертах повторяет типичную схему построения распределенной системы анализа сетей. Однако есть несколько особенностей, выведших именно эту систему в лидеры рынка.
Во-первых, это - концепция взаимодействия сервера и консоли анализа. Развивая концепцию RMON, сервер анализа SnifferServer действует как полностью независимое устройство, не только собирая информацию о функционировании сети (подобно агенту SNMP) или проводя ее первичную обработку (подобно агенту RMON), но и выполняя ее полный анализ на всех семи уровнях сетевой модели ISO/OSI. Более того, сервер берет на себя все функции по отображению информации, формируя некий виртуальный экран с информацией о функционировании конкретного сегмента сети. Далее этот виртуальный экран передается на консоль, где и отображается в отдельном окне. Для управления сервером анализа имеется возможность пересылки команд с консоли на сервер. Любые обмены данными между сервером и консолью оптимизируются, например, при передаче виртуального экрана реально передаются только скомпрессированные данные, представляющие собой изменение содержимого этого экрана по сравнению с предыдущей пересылкой.
Второй особенностью является использование для связи между консолью и сервером фирменного протокола передачи данных NGCP (NetworkGeneralCommunicationProtocol) вместо SNMP. Протокол NGCP базируется на протоколе ТСР и, в отличие от SNMP, является защищенным, то есть все передаваемые посредством NGCP данные передаются в зашифрованном виде. Учитывая, что при работе систем типа SnifferServer любая циркулирующая в сети информация, включая адреса станций, запросы к серверам баз данных и ответы от них и даже пароли доступа, могут быть легко перехвачены и подвергнуты анализу, возможность использования защищенных методов связи оказывается очень уместной. NGCP может быть использован как для связи по локальной сети, так и по коммутируемым и выделенным каналам (в этом случае используется протокол NGCP-serial, подобный PPP).
Программное обеспечение SnifferServer состоит из трех подсистем - мониторинга, интерпретации протоколов и экспертного анализа. Подсистема мониторинга представляет собой систему отображения текущего состояния сети, позволяющую получать статистику по каждой из станций и сегментов сетей по каждому из используемых протоколов. Две остальные подсистемы заслуживают отдельного обсуждения.
Подсистема ProtocolInterpreter
В функции этой подсистемы входит анализ захваченных пакетов и как можно более полная интерпретация каждого из полей заголовков пакетов и его содержимого. Компания NetworkGeneral создала самую мощную подсистему подобного типа - ProtocolInterpreter способен полностью декодировать более 200 протоколов всех семи уровней модели ISO/OSI (TCP/IP, IPX/SPX, NCP, DECnetSunNFS, X-Windows, семейство протоколов SNAIBM, AppleTalk, BanyanVINES, OSI, XNS, Х.25, различные протоколы межсетевого взаимодействия). При этом отображение информации возможно в одном из трех режимов - общем, детализированном и шестнадцатеричном.
Общий режим предусматривает отображение лишь наиболее важной информации о пакете - адреса отправителя и получателя, название высшего по иерархии ISO/OSI протокола, использованного в пакете, краткая характеристика содержимого пакета (например, чтение данных). В этом режиме каждый из пакетов занимает одну строку в окне интерпретатора протоколов.
Детализированный режим предусматривает отображение полной расшифровки всей иерархии протоколов, при этом каждый из уровней иерархии отображается своим цветом, дается расшифровка на близком к естественному английскому, каждого из полей пакетов всех уровней иерархии и подробно описываются данные пакета (рис. 3.2).
Рис. 3.2. ProtocolInterpreter
При работе в шестнадцатеричном режиме пакеты отображаются в шестнадцатеричном виде, а также в виде символов кодировок ASCII или EBCDIC.
Для разработчиков поставляется специальный инструментарий - PDK (ProtocolDevelopmentKit), позволяющий создавать модули поддержки новых протоколов для ProtocolInterpreter.
Подсистема ЕхреrtAnаlysis
Сердцем серверов SnifferServer является экспертная система анализа сети ExpertAnаlysis. В основе системы лежит уникальная база знаний, накопленная специалистами компании NetworkGeneral с 1986 года и основанная на опыте работы с пользователями различных сетей и разработках групп Станфордского и Массачусетского университетов, а также компании NipponTelephoneandTelegraph (NTT).
Основное назначение системы - сокращение времени простоя сети и ликвидация узких мест сети с помощью автоматической идентификации аномальных явлений и автоматической генерации методов их разрешения. Система экспертного анализа предоставляет диагностическую информацию трех категорий:
Симптом - событие в сети, которому администратор сети должен уделить дополнительное внимание (например, физическая ошибка при обращении к узлу сети или единичная повторная передача файла). Не обязательно означает возникновение проблемы, однако при высоком уровне периодичности требует внимания администратора.
Диагноз - неоднократное повторение симптома, подлежащее обязательному расследованию со стороны администратора сети. Обычно диагноз описывает ситуации, характеризующие серьезные неисправности в сети (например, дублируемый сетевой адрес).
Объяснение - контекстно-зависимое экспертное заключение системы анализа для каждого симптома или диагноза. Объяснение содержит описание нескольких возможных причин сложившейся ситуации, обоснование подобного заключения и рекомендации по их устранению.
В системе имеются возможности дополнения существующей базы знаний специфическими данными, полученными администратором сети в процессе ее использования.
Система автоматического анализа ExpertAnalysis основана на уникальной многозадачной технологии анализа пакетов, которую в нескольких словах можно описать следующим образом:
Циркулирующие в сети пакеты непрерывно захватываются и помещаются в кольцевой буфер захвата (первая задача).
Одновременно с этим несколько задач-анализаторов протоколов (по одной на каждое из семейств протоколов) сканируют буфер захвата и генерируют информацию в едином внутреннем формате.
Эта стандартизованная информация поступает на группу задач-экспертов. Каждый из экспертов является таковым лишь в своей узкой области, например, в знании протокола взаимодействия клиента с сервером NetWare. Если эксперт находит событие, связанное с его областью интересов, он генерирует некоторый соответствующий объект (например, "пользователь Guest сервера IBSO") в объектно-ориентированной базе данных о сети, называемой BlackboardKnowledgeBase, и связывает его с соответствующими объектами более низкого уровня (в нашем случае - с адресом IPX станции пользователя Guest, связанным с МАС-адресом платы этой станции, и с сервером IBSO, связанным с адресами IPX и IP, а также с MAC-адресами сетевых плат сервера, а также со всеми уже вошедшими на сервер пользователями, принт-серверами, и т.д.). В результате возникает некоторая сложная структура, отображающая все объекты сети, относящиеся к некоторому протоколу и все возможные связи между ними на всех 7 уровнях модели ISO/OSI.
Существует вторая группа задач-экспертов, постоянно анализирующая состояние базы данных и выдающих сообщения о ненормальном функционировании сети (симптомы или диагнозы). В общей сложности система ExpertAnalysis знакома с более чем 200 различными проблемами функционирования сети.
Последний элемент этой системы - эксперты, генерирующие подробное описание проблемы и методы ее исправления. При этом эти эксперты сканируют базу данных и подставляют в выдаваемые рекомендации реальные объекты сети - МАС-адреса, названия серверов, имена задач и т.д.
Подобная многозадачная система анализа является уникальной на рынке анализаторов. Некоторые из продуктов компаний-конкурентов также предлагают системы с элементами искусственного интеллекта, однако принципы построения их совершенно иные. Исповедуемый компанией NetworkGeneral принцип построения анализатора на основе "круглого стола экспертов", реализованного на основе специализированного многозадачного ядра, позволяет проводить анализ с очень высокой производительностью. Задачи-эксперты одновременно ведут обработку информации по мере ее поступления, а используемые эвристические правила позволяют быстро локализовать круг экспертов по каждому из конкретных случаев и временно приостановить работу других экспертов.
Исповедуемый другими компаниями принцип, требующий последовательного применения всех эвристических правил, ведет к снижению производительности анализа на тех же мощностях процессора и к необходимости использования более мощного процессора для обеспечения соизмеримой производительности.
Система ExpertAnalysis обеспечивает то, что компания NetworkGeneral называет активным анализом. Для понимания этой концепции рассмотрим обработку одного и того же ошибочного события в сети системами традиционного пассивного анализа, и системой активного анализа.
Пусть в сети в 3:00 ночи произошел широковещательный шторм, вызвавший в 3:05 сбой системы создания архивных копий баз данных. К 4:00 шторм прекращается и параметры системы входят в норму. В случае работы в сети системы пассивного анализа трафика пришедшие на работу к 8:00 администраторы не имеют для анализа ничего, кроме информации о втором сбое и, в лучшем случае, общей статистики по трафику за ночь - размер любого буфера захвата не позволит хранить весь трафик, прошедший по сети за ночь. Вероятность ликвидации причины, приведшей к широковещательному шторму в такой ситуации крайне мала.
А теперь рассмотрим реакцию на те же события системы активного анализа. В 3:00, сразу после начала широковещательного шторма, система активного анализа фиксирует наступление нестандартной ситуации, активирует соответствующий эксперт и фиксирует выданную им информацию о событии и его причинах в базе данных. В 3:05 фиксируется новая нестандартная ситуация, связанная со сбоем системы архивирования, и фиксируется соответствующая информация. В результате в 8:00 администраторы получают полное описание возникших проблем, их причин и рекомендации по устранению этих причин.