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

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

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

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

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


Rambler's Top100

  

Коммутаторы, распределяющие нагрузку

Лоугэн Хабау

Средства распределения нагрузки (load-balancing) находят все более широкое применение на Web-узлах с высоким трафиком, где один сервер не справляется с обработкой всех поступающих запросов.

Менеджерам таких узлов вместо перехода на более мощные аппаратные средства имеет смысл создавать кластеры, или серверные фермы. Возможность направлять трафик на заданный сервер или ферму исходя из адресов URL позволяет создать на нескольких серверных кластерах единый Web-узел.

По мере развития Web-узлов и роста их трафика совершенствуются и средства распределения нагрузки. Наблюдается постепенная трансформация Web-узлов от относительно простых систем с единственным виртуальным кластером и несколькими физическими серверами к значительно более сложным моделям с несколькими виртуальными кластерами, обслуживающими отдельные участки Web-узла: один — для работы со статическим информационным наполнением, другой — для транзакций электронной коммерции (ЭК), третий — для проведения интерактивных опросов. Кроме того, в состав Web-узла могут входить виртуальные кластеры, состоящие из маршрутизаторов Интернет, маршрутизаторов виртуальных частных сетей (Virtual Private Networks — VPN) или межсетевых экранов.

В данном обзоре мы рассмотрим коммутаторы AD3 фирмы Alteon Systems, ServerIronXL фирмы Foundry Networks Web Server Director (WSD) Pro+ фирмы RadWare. Все три устройства имеют развитые функциональные возможности (в числе которых — распределение нагрузки как для исходящего, так и входящего трафика с учетом географии пользователей, маршрутизация трафика на основе cookie-маркеров, адресов URL или сеансовых идентификаторов SSL) и улучшенные управляющие утилиты.

Каждый продукт имеет свои сильные стороны, которые трудно сравнивать: цена за порт, например, у ServerIronXL вдвое ниже, чем у AD3, зато последний имеет внушительный набор функций. В свою очередь, у обоих цена за порт существенно ниже, чем у коммутатора фирмы RadWare. Но это не все. Если вы обходитесь лишь простейшими функциями сортировки URL для реализации Web-кэширования, то к вашим услугам продукт Intel 550T, цена за порт у которого намного ниже, чем у протестированных нами коммутаторов (см. “Intel Express 550T — устройство узкоспециализированного назначения”).

Все эти коммутаторы имеют много важных функций, которых мы не касаемся в данном обзоре, начиная с широких возможностей фильтрации и кончая способностью бороться с атаками типа “отказ в обслуживании”. Устройство WSD фирмы RadWare в большей степени ориентировано на Интернет-провайдеров, обеспечивая, в частности, маршрутизацию до 10 000 адресов URL по сравнению с 256 адресами у ServerIronXL и 64 у AD3. Кроме того, установку WSD у заказчика выполняет специалист компании RadWare.

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

Настройка

Настройка всех трех устройств выполняется почти одинаково. Для задания базовой информации TCP/IP используются последовательный интерфейс и терминальная программа. После этого вся последующая настройка осуществляется либо опять с помощью терминального соединения через последовательный интерфейс, либо через сеанс Telnet, либо через Web-браузер. Все три продукта имеют достаточно простой интерфейс для ввода информации.

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

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

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

Администрирование

Представители фирм Alteon и Foundry сообщили нам, что их заказчики до сих пор предпочитают интерфейс командной строки (Command-Line Interface — CLI) и, похоже, не очень заинтересованы выполнять функции администрирования через браузер. Мы вынуждены только гадать, исходит ли это от самих администраторов или от менеджеров отдела информационных технологий (ИТ). Если бы мы работали в отделе ИТ, то, учитывая имеющийся и прогнозируемый недостаток персонала во всей отрасли, мы бы по возможности свели к минимуму проблемы обучения новых администраторов.

Предлагаемые компаниями Alteon и Foundry интерфейсы CLI подобны ставшему отраслевым стандартом интерфейсу Cisco. Однако мы обнаружили, что команды навигации в них заметно различаются. Например, в интерфейсе ServerIronXL для возврата на предыдущий уровень меню используется команда “exit”, а в AD3 — команда “..”. В интерфейсе WSD меню не используется совсем и все команды полностью вводятся в командной строке. Вместо того чтобы набирать нечто вроде “configuration, IP, address, 192.72.155.10” несколькими отдельными командами, вся строка должна быть введена сразу, что существенно увеличивает вероятность возникновения ошибки. Однако это не столь большая проблема, поскольку у WSD действительно хороший интерфейс управления через браузер, охватывающий все функции этого устройства.

Мы обнаружили, что ряд функций ServerIronXL и AD3 доступны только через интерфейс командной строки. По-видимому, большинство функций устройства фирмы Alteon можно настроить через браузер. Однако в ходе тестирования несколько команд не были восприняты таким образом, хотя мы аккуратно вносили изменения и затем перезагружали коммутатор. Разобравшись с синтаксисом команд, мы сумели подключиться к устройству по протоколу telnet и быстро внести изменения через командную строку.

Функциональные возможности

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

Тестируемые устройства также обеспечивают постоянство каждого соединения, гарантируя при этом, что выполняющий серию транзакций клиент будет в течение всего сеанса подключен к одному и тому же серверу в кластере. В первом поколении основанных на данной технологии решений для обеспечения постоянного соединения использовался IP-адрес клиента. При распространенной ныне практике трансляции сетевых адресов (Network Address Translation — NAT) нет гарантии, что все запросы с данного IP-адреса действительно исходят от одного клиента. В новых продуктах для обеспечения постоянства соединений применяются cookie-маркеры или сеансовые идентификаторы SSL.

Маршрутизация на основе адреса URL дает возможность коммутатору на основании запрошенного клиентом ресурса определить, какие сервер или ферма должны получить запрос и соответствующим образом направить его. Для этого можно использовать указанный в URL путь (например, все запросы, в URL которых встречается слово /homepage, отправляются на один и тот же конкретный кластер), имя файла (filename.gif) или номер порта (порт 80 является портом по умолчанию для протокола HTTP).

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

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

Резервирование

Каждый протестированный нами коммутатор поддерживает резервирование. В режиме “активный—активный” два устройства работают с различными виртуальными кластерами, передавая друг другу нагрузку в момент аварии одного из них. В режиме “активный—пассивный” второе устройство находится в “горячем” резерве и начинает действовать, если первое отказывает. Компании Alteon и RadWare в своих продуктах обеспечивают первый из упомянутых нами режим, а Foundry — второй. Эти функции не тестировались, поскольку у нас было только по одному экземпляру каждого устройства.

Кэширование

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

Все протестированные нами коммутаторы способны по запрошенному клиентом адресу URL определять, куда следует направить запрос — на кэш-сервер или на сервер, обрабатывающий динамическое содержимое. Делают они это путем анализа запрошенного адреса. Например, Web-узел конфигурируется так, чтобы вся статическая информация находилась в каталоге /static. Коммутаторы могут также анализировать тип запрошенного файла — все файлы с расширением JPG должны браться из кэша, а файлы *.CGI или *.ASP — с Web-сервера.

Выравнивание нагрузки на межсетевые экраны и маршрутизаторы

В дополнение к балансировке нагрузки в пределах кластера Web-серверов часто бывает необходимо ее распределить путем создания виртуального кластера межсетевых экранов, маршрутизаторов или VPN-устройств. Коммутаторы фирм Alteon и Foundry такие функции поддерживают (надо отметить, что с коммутатором Foundry работать намного удобнее). Это позволяет создавать группы маршрутизаторов и назначать им относительные весовые коэффициенты, например в случае, когда один подключен к линии T-1, другой — к линии T-3 и т. д.

Алгоритмы

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

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

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

Проверка работоспособности

В каждом коммутаторе заложена возможность несколькими способами проверить, функционируют ли серверы в виртуальном кластере, равно как существуют несколько вариантов действий в случае отказа сервера. Все три устройства могут проверять сервер с помощью эхо-тестирования. Коммутатор компании Alteon способен проверять конкретные порты (например, порт 80) для подтверждения доступности соответствующей службы (в частности, HTTP); адреса URL, чтобы убедиться в исправности соответствующей части Web-сервера, а также состояние серверов RADIUS и IMAP. Продукт фирмы Foundry может также проверять заданные адреса URL и ответы на DNS и HTTP-запросы, а устройство RadWare — заданные порты и адреса URL.

Продукт фирмы RadWare имеет заслуживающую внимания возможность постепенного отключения и подключения сервера в кластере. Если вам нужно перевести сервер в автономный режим и вы просто отключите его, то прервутся соединения подсоединенных к нему клиентов. Коммутатор WSD позволяет вам обозначить любой сервер в кластере как предназначенный к отключению, и поступление запросов на него прекратится. Затем вы даете возможность клиентам завершить текущие сеансы и, когда сервер освободится, выключаете его. WSD позволяет также постепенно возвращать сервер в кластер: когда сервер вновь подключается к сети, то, вместо того чтобы сразу “свалить” на него весь трафик, поскольку он в этот момент оказывается наименее загруженным, вы можете указать, чтобы трафик на него “подавался” постепенно и, таким образом, он не испытывает взрывного роста нагрузки.

Обход коммутатора

Каждая компания называет этот процесс по-разному: Alteon — прямым ответом от сервера (direct-server return), Foundry — прямым ответом от кэш-сервера (direct cache-server return), а RadWare — триангуляцией (triangulation), но общая идея одна и та же. Если запросы посылаются на сервер через коммутатор, естественно предположить, что ответ сервера клиенту должен проходить тоже через коммутатор. Однако можно настроить все так, чтобы сервер отвечал непосредственно клиенту, минуя коммутатор и отправляя трафик прямо на маршрутизатор. Это уменьшает трафик коммутатора и позволяет последнему лучше справляться с более сложными задачами.

Распределение нагрузки с учетом географии пользователей

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

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

Дополнительные возможности

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

Документация

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

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

Прилагаемый к коммутатору фирмы Foundry диск CD-ROM содержит документацию по всем продуктам этой компании, что несколько затрудняет поиск нужных сведений. Чтобы иметь возможность изучить документацию, нам пришлось распечатать около 200 страниц из двух PDF-файлов. Мы предпочли бы иметь готовую печатную документацию, пусть даже за дополнительные деньги.

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

Цена и производительность

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

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

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

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

Кроме того, выработка тестовых показателей, которые адекватно характеризовали бы эти коммутаторы, представляет собой отдельную проблему. Ирония состоит в том, что каждая из двух фирм — Foundry и Alteon — прислала нам результаты исследований, проведенных компанией Tolly Group, соответственно показывающие, что именно ее коммутатор лучше всех остальных. Эти два исследования различались способом тестирования: в одном определялось максимальное число соединений, которое устанавливается в секунду, а в другом — сколько соединений коммутатор способен поддерживать одновременно.

Оба параметра могут оказаться важными в зависимости от типа поддерживаемого Web-узла, и ни один из них не отражает ничего, кроме архитектуры устройства. Коммутатор фирмы Alteon поддерживает одновременно до 64 тыс. соединений на каждый порт, поэтому очень большое число запросов от одного пользователя может исчерпать возможности порта. У продукта же компании Foundry таблица сеансов отнесена к коммутатору в целом и может содержать до 1 млн записей. Весьма вероятно, что в реальных условиях ни один из них не обеспечивает значительных преимуществ.

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

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

Другая проблема заключается в том, что единственный пользователь способен во время просмотра Web-узла открыть до тысячи TCP-соединений, каждое — с различной полезной нагрузкой. При том способе, каким коммутаторы производства компаний Alteon и Foundry отслеживают сеансы, будет создано 1000 записей. В то же время при использовании коммутатора фирмы RadWare всем этим соединениям будет соответствовать единственная запись в таблице клиентов.

Таблица клиентов коммутатора RadWare может одновременно содержать 200 тыс. записей, что соответствует миллионам TCP-соединений. Коммутатор ServerIronXL может работать одновременно с 1 млн сеансов, AD3 — с 512 тыс. Эти показатели, вероятно, важнее, чем число соединений в секунду, даже если последнее рассчитано исходя из некоторого разумного размера файла. Причина в том, что пути к большинству Web-узлов включают каналы связи с Интернет.

Линия T1 способна поддерживать до 48 соединений в секунду, если средний размер передаваемого файла составляет 4 Кбайт, и 24 соединения в секунду для файлов размером 8 Кбайт. Линия T3 может поддерживать 1400 соединений в секунду для файлов размером 4 Кбайт и 700 соединений для 8 Кбайт. Даже линия OC3 поддерживает лишь 4500 и 2240 соединений соответственно.

Все три протестированных устройства имеют свои сильные стороны. Например, AD3 предлагает широкий и апробированный набор функциональных возможностей в сочетании с разумной ценой и высокой производительностью. ServerIronXL – самый дешевый и имеет наибольшее число портов, но по функциональности отстает от своих конкурентов. Тем не менее он с успехом может использоваться в большинстве корпоративных узлов. Продукт WSD дорогой, зато оснащен возможностями, которые могут быть весьма кстати для Интернет-провайдеров или очень больших Web-узлов с множеством серверов. Он имеет прекрасную утилиту управления и простую процедуру настройки. Кроме того, фирма RadWare обеспечивает помощь в инсталляции его на месте. Этот коммутатор победил в наших испытаниях, но, надо сказать, с очень небольшим отрывом.





  
4 '2000
СОДЕРЖАНИЕ

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

• Молодым везде у них дорога

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

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

• Измерители оптических потерь

• Проблемы с разъемами категории 6

• Тестируем пакеты системного управления

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

• Как лечить "последнюю милю" внутрипроизводственных сетей

• IP-телефония. Как обеспечить качественную передачу речи. Часть 2

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

• LinkView Classic - классика сетевой диагностики, ProCurve 8000: со временем только лучше, Программное обеспечение SiteNet MultiLink для источников бесперебойного питания, ViPNet - сеть для особо важных приложений, Best 5000: "чистое" питание VIP-систем

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

• Управление сетевой производительностью - дорого, но мило

• Способы модернизации сервера

• Возвращаясь к проблемам удаленного мониторинга

бизнес

• Датские уроки экономного электропитания

• 3Com меняет структуру каналов сбыта

электронная коммерция

• Ищите разумный компромисс

• Коммутаторы, распределяющие нагрузку

• Господство на вертикальных рынках

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

• Платформы сетевой безопасности

• Преступление и наказание


• КАЛЕЙДОСКОП



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