Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Исследуем связующее ПО

Барри Нэнс

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

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

Продираясь сквозь дебри

Мы исследовали сетевой трафик, созданный связующим ПО доступа к данным на трехсегментной локальной сети Ethernet, которая состояла из трех серверов, работающих под управлением ОС Windows NT Server 4.0, 15 клиентских ПК с ОС Windows 95, двух клиентских машин IBM с OS/2 Warp и одной клиентской машины Macintosh. В состав БД, к которым был организован доступ, вошли Oracle 7.3 (трафик SQL*NET), IBM DB2 Universal Database 5.0 (трафик DRDA) и Microsoft SQL Server 6.5 (трафик TDS).

В процессах выделения, измерения и оценки функционирования связующего ПО были задействованы два анализатора доступа к данным, которые обеспечивали просмотр сетевого трафика. Программный анализатор Fast Ethernet Sniffer Analyzer версии 5.02 фирмы Network General с модулями для БД Sybase и Oracle предоставлял нам полную информацию о каждом пакете и генерировал отчет с результатами анализа трафика связующего ПО. Выполнение программы EcoSCOPE версии 3.0 фирмы Compuware на одном из серверов Windows NT обеспечивало просмотр не только связей и взаимодействий между приложениями, но и топологии нашей сети.

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

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

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

Сверху вниз или снизу вверх?

Традиционно суть анализа протокола заключается в декодировании и отображении пакетов файловых команд - операций открытия, чтения и записи. В принципе анализатор протокола может отображать пакеты доступа к данным, но только в непреобразованном виде (т. е. в виде шестнадцатеричных байтовых строк). Некоторые из продуктов обрабатывают разные сетевые протоколы (маршрутной информации, протокол определения адреса, HTTP и другие), но декодирование пакетов данных не получило широкого распространения. Следует все же сказать о том, что в этом отношении продукты EcoSCOPE и Sniffer представляют исключение. Для анализа трафика доступа к данным EcoSCOPE использует нисходящий подход, а Sniffer - восходящий.

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

В процессе тестирования, экспериментируя с менеджерами БД Oracle, SQL Server и DB2, мы заметили, что размер трафика к серверу БД и обратно существенно зависит от протокола доступа к данным. Протокол SQL*NET БД Oracle генерировал минимальный трафик, а протокол TDS БД SQL Server - максимальный. Различия вносили и используемые нами сетевые протоколы. Так, протокол NetBEUI был самым "болтливым", IPX/SPX - значительно менее "разговорчивым", а TCP/IP - самым "молчаливым" пользователем сети.

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

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

"Пробки" на мостах

Проводя первый тест, мы по очереди перемещали каждый сервер БД на другой сегмент, заставляя его трафик проходить через мост. Моделируя ситуацию, когда мост перегружен кадрами больших размеров, мы "замедляли" его работу, используя ПО PC Bridge на машине IBM PS/2 Model 70. Кроме того, нам удалось создать программу, которая "забрасывала" мост пакетами, предназначавшимися для некоторого узла сегмента сервера БД. В этой среде с напряженным трафиком клиентским приложениям часто приходилось заново посылать свои запросы, с тем чтобы они наконец попали на сервер.

Анализаторы EcoSCOPE и Sniffer быстро предупреждали нас о возникновении "затора", но сообщали об этом разными способами. Выполняя мониторинг времени отклика, анализатор EcoSCOPE выдавал предупреждающий сигнал посредством ловушки SNMP после того, как время отклика становилось больше определяемой пользователем пороговой величины, которую мы могли регулировать. При сборе базовой статистики мы использовали мониторинг времени отклика для получения отчета Microsoft Access о минимальном, максимальном и среднем значениях этого времени для группы клиентских ПК, связанных с сервером БД Oracle. Получив такой сигнал после переконфигурации сегмента, мы убедились в том, что показатели времени отклика увеличились в четыре раза.

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

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

Этот запутанный SQL

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

Запустив наш тест на выполнение заведомо неудачно составленного SQL-запроса, с помощью обоих анализаторов - EcoSCOPE и Sniffer - нам удалось определить, что время отклика ухудшилось по сравнению с установленной пороговой величиной, равной 500 мс. Ни одно из двух средств непосредственно "не указывало" на SQL-запрос, тем не менее оба они позволили подробно разобраться с чередованием прямых и обратных пакетов, которые обусловили увеличение транзакционного времени SQL Server TDS и Oracle SQL*NET. Детальное декодирование пакетов трафика DRDA БД DB2 наши анализаторы не поддерживали, хотя EcoSCOPE все же позволял отслеживать его долю в использовании сети.

Мы убедились, что "запутанные" SQL-запросы достаточно быстро передавались на сервер БД, а ответы на них клиенты получали немедленно. Очевидно, "узким местом" все-таки был сервер БД (см. "Как работает компилятор SQL"). К сожалению, достаточно трудоемкими оказались детальный анализ на пакетном уровне и изучение временныўх характеристик событий.

Как работает компилятор SQL?

Анализатор протокола умеет выделять в потоке данных пакеты с запросом к БД и соответственно ответом на него. Чрезмерно большая пауза между этими двумя событиями является общей проблемой производительности во многих сетях. Возможно, вам не удастся решить ее путем изменения самой сети. Источником задержки часто оказывается сервер БД, которому требуется большое время для обработки SQL-запросов. Понимание сути происходящего на сервере БД между запросом и ответом может помочь вам грамотно составлять SQL-запросы, которые будут более быстро обрабатываться сервером. Исключение избыточных связей, например, позволяет компилятору SQL обрабатывать запросы к БД быстрее. В результате связующее ПО станет менее ресурсоемким.

До того, как начнет свою работу механизм системы управления реляционными базами данных (СУРБД), компилятор SQL должен распознать и понять английские глаголы, существительные и предлоги (например, команду "Select" на языке SQL), затем преобразовать эти операторы SQL во внутренние команды для обеспечения процессов поиска и обновления, которые входят в состав механизма СУРБД.

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

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





  
6 '1998
СОДЕРЖАНИЕ

колонка редактора

• Cеть напрокат

локальные сети

• Сегментирующие концентраторы для рабочих групп

• Сопряжение сетей Ethernet и Fast Ethernet

• NDPS - решение проблем сетевой печати?

• Рост рынка волоконной оптики

• Можно ли Windows NT доверять секреты?

• Системы микроклимата

• Тестируем переключатели KVM

корпоративные сети

• На переднем крае IP-коммутации

• Исследуем связующее ПО

• Как выбрать коммутатор АТМ

услуги сетей связи

• Практические аспекты построения корпоративных сетей Frame Relay (часть II)

• Связь в Сургуте: слагаемые успеха

• Интеллектуальные сети и услуги

• Куда шагает Frame Relay

системы учрежденческой связи

• Системы микросотовой связи стандарта DECT

• Принципы выбора УПАТС (часть II)

• Документальная телеконференция: недостающее звено между аудио- и видеоконференц-связью

интернет и интрасети

• Border Manager - служба безопасности от Novell

• Кто ищет, тот всегда найдет

защита данных

• Защита от "вероломных" Java-приложений

• Серверы-посредники Socks

• CeBIT'98: технологии информационной безопасности

новые продукты

• Новые сетевые принтеры на Comtek'98, Не хочу отдавать обратно OfficeConnect Dual Analog, С возвращением, LANNET!; Мультисервисный концентратор доступа MC3810 фирмы Cisco, Пополнение семейства Vanguard, Кластер серверов от INPRO Computer Systems

только на сервере

• Система S.W.I.F.T. и информационная безопасность

• Экспертиза, проектирование и реинжиниринг



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх