Распределение Web-нагрузки

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

Мы испытывали продукты Local Director фирмы Cisco Systems, Big/ip2 фирмы F5 Labs, Web Server Director Pro фирмы RND Networks и HydraWeb Load Manager фирмы HydraWeb Technologies. Все они неплохо проявили себя; каждый из них обладает свойствами, которые делают его особенно полезным для определенной конфигурации сети. Однако полнота набора алгоритмов переадресации и возможности управления в продукте Local Director фирмы Cisco Systems выводят его на первое место в нашем списке.

Эти продукты недешевы, но некоторые их них лучше других подходят для мелких серверных хозяйств. HydraWeb является единственной фирмой, расценки на продукцию которой определяются числом балансируемых серверов. Минимальная конфигурация из четырех серверов стоит 7990 дол., а конфигурация с избыточными серверами - 12 980 дол.

Много похожего

Все продукты балансируют трафик, состоящий из пакетов стандартных протоколов TCP/IP, в том числе UDP (User Datagram Protocol), HTTP и SSL (Secure Socket Layer). Они поддерживают сетевые спецификации 10Base-T и 100Base-T и (кроме Web Server Director) поддерживают FDDI. Поскольку продукты BIG/ip2 и HydraWeb основаны на ядре Unix, они позволяют использовать множество имеющихся утилит Unix, что делает их потенциально более гибкими, чем остальные.

Ни одно из рассмотренных средств балансировки нагрузки не должно быть причиной снижения производительности, поскольку их номинальная мощность намного превосходит максимальную физическую нагрузку, которую они способны поддерживать. Наиболее важными критериями выбора таких продуктов для Web-узлов, установленных в сетях 10 Мбит/с с менее быстрым Internet-соединением (например, T-1 со скоростью 1,54 Мбит/с), являются возможности аварийного резервирования, администрирования, защиты, мониторинга, а также стоимость. Не следует упускать из виду и способность балансировки нагрузки между портами и переконфигурирования поддерживаемых серверов на ходу.

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

Протоколы на базе TCP/IP используют порты для того, чтобы "слушать" приходящий трафик. По умолчанию на Web-серверах обычно используется порт 80, на котором сервер принимает трафик от клиентов. Таким образом, запросы по протоколу HTTP с указанием лишь имени хоста, а не порта (наподобие www.server.com), обрабатываются портом 80. Однако можно указывать любой из портов - от 0 до 65536 (например, www.server.com:9000). Кроме BIG/ip2, все названные балансировщики нагрузки способны распределять поступающие запросы на порты, отличные от порта 80. Благодаря распределению портов в виртуальном IP-адресе можно приравнивать порт 80 к любому иному порту Web-сервера. Это позволяет сетевым службам объявлять легко запоминающееся имя домена, а не сложное наименование сервера, который в действительности обрабатывает запрос.

В отличие от остальных испытанных продуктов, BIG/ip2 не допускает переназначения портов и, следовательно, не способен поддерживать множество имен доменов для HTTP и других протоколов. Однако BIG/ip2 предоставляет возможность разрешения и запрещения входного трафика по каждому порту. Например, порту 80 может быть разрешен только HTTP-трафик, а порту 25 - только FTP.

Обычно балансировщик нагрузки использует один из нескольких алгоритмов для выбора Web-сервера, который способен обработать данный запрос наилучшим образом. Алгоритмы переадресации запросов, применяемые в различных продуктах, варьируются от простого распределения "по кругу" до отслеживания номеров активных подключений или даже мониторинга загрузки Web-серверов (см. врезку "Алгоритмы распределения нагрузки"). Local Director поддерживает наибольшее число алгоритмов переадресации, но не имеет алгоритма, который запускает на каждой машине процесс, непосредственно следящий за ее жизнеспособностью. Этим качеством обладает только HydraWeb.

Аварийное резервирование

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

Local Director, BIG/ip2 и HydraWeb обеспечивают аварийное резервирование путем соединения двух балансировщиков нагрузки через последовательный кабель. Выход из строя одного из них "замечает" другой, и аварийное переключение происходит автоматически. Продукт Web Sever Director рассылает команды предпочтительной маршрутизации по виртуальным IP-адресам со вторичными трассами для аварийных ситуаций, что делает его более отказоустойчивым, чем продукты, использующие физический кабель.

Что произойдет при повреждении последовательного кабеля? В случае BIG/ip2 или HydraWeb каждое из устройств примет на себя первичное управление. Это крайне нежелательно, ибо ваш Web-узел станет недоступным до тех пор, пока не будет заменен кабель и восстановлена система. Если неисправность кабеля обнаруживает Local Director, то, по утверждению Cisco, машины не выполняют аварийного переключения, но генерируют SYSLOG-сообщение об аварийной ситуации. Такая ситуация может быть выявлена стандартным мониторингом, а Local Director будет продолжать функционировать, пока не нарушится работа одного из блоков.

Все устройства способны обнаруживать отказавшие серверы, находящиеся за устройством переадресации. В ходе наших испытаний они направляли трафик к оставшимся работоспособными серверам, минуя вышедшие из строя. При сбоях такого типа HydraWeb восстанавливался за 10 с, BIG/ip2 - менее чем за 15 с, Web Server Director - менее чем за 20 и Local Director - за 45 с.

Web Server Director и HydraWeb допускают конфигурирование невыделенных серверов в качестве машин резервирования, которые берут на себя задачи Web-сервера при выходе из строя другой машины.

Поддержание статуса

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

Если передаваемый протокол не запрашивает сведения о статусе, то все устройства, кроме Web Server Director фирмы RND, могут быть настроены так, чтобы не поддерживать таблицу адресов и давать возможность трафику каждый раз следовать к различным машинам. Представители RND утверждают, что компания планирует добавить такую функцию.

Local Director позволяет задавать значения тайм-аута для каждого виртуального сервера и порта, а Web Server Director - сбрасывать таймер до 1 с (в следующем выпуске его можно будет устанавливать на "0", что означает запрет на использование).

Управление системами и мониторинг

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

Все устройства поддерживают большое число серверов - достаточное для любого Web-узла. Local Director поддерживает 10 240 виртуальных и реальных IP-адресов, BIG/ip2 - 255 виртуальных и реальных хостов (в ближайшее время будет выпущена версия 1.7, рассчитанная на поддержку неограниченного числа реальных и виртуальных хостов), Web Server Director - более 50 000 реальных машин и 500 виртуальных адресов, а HydraWeb - безграничное число тех и других.

Local Director имеет командно-управляемый интерфейс для поддержки и мониторинга и может контролироваться через telnet. Конфигурирование выполняется просто - переход в онлайновый режим производится с помощью нескольких команд.

BIG/ip2 может управляться через telnet и консоль интерфейса RS-232. Поскольку этот продукт основан на ОС Unix, возможен его мониторинг с помощью Unix-утилит. Опубликованные в Internet имена и IP-адреса являются виртуальными хостами, откуда устройства балансировки нагрузки переадресовывают трафик одному или нескольким реальным устройствам, обслуживающим запросы. BIG/ip2 предоставляет удобный графический интерфейс, поддерживающий средство шифрования SSH фирмы Data Fellows. Вскоре ожидается выпуск интерфейса под X Windows.

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

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

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

Обращение к HydraWeb через порт RS-232 с помощью его интерфейса Proconsul позволяет модифицировать локальную систему, а сам Proconsul может быть использован вместе с устройствами удаленной консоли. Доступ к оболочке HydraWeb включает в себя административные сервисы для управления продуктом HydraWeb и просмотра состояния системы. Можно также задавать учетные данные, благодаря чему непривилегированные пользователи способны заниматься мониторингом устройства.

Безопасность или доступ?

Все физические устройства применяют тот или иной уровень защиты для машин, нагрузку которых они балансируют. Будучи Unix-продуктами, BIG/ip2 и HydraWeb допускают защиту на основе ОС Unix с помощью таких продуктов, как Free BSD S/Key или SecurID фирмы Security Dynamics Technology. BIG/ip2 реализует несколько функций брандмауэра (таких как контрольный список IP-адресов и портов), которые делают находящиеся за ним серверы "невидимыми" для внешних сетей. HydraWeb поддерживает и коммутируемые телефонные соединения.

Некоторым Web-мастерам хотелось бы так "скрыть" свои Web-серверы, чтобы их IP-адреса и имена не публиковались и не было возможности обращаться к машинам через telnet ping. Для других желательно, чтобы отдельные машины были непосредственно доступны через имя или адрес для целей мониторинга или облегчения связи между машинами. Среди испытанных нами устройств только BIG/ip2 никогда не разрешал доступ к отдельным машинам из сети. Обычно HydraWeb конфигурируется так, что адреса управляемых серверов скрыты от внешней сети, но данная настройка не является обязательной.

Результаты испытаний средств балансировки нагрузки

Алгоритмы распределения нагрузки

Существуют несколько способов распределения нагрузки между Web-серверами. Устройства нового поколения постепенно вытесняют устаревшую технологию Rotary DNS (циклическая система имен доменов). Если вы все еще пользуетесь ею, имеет смысл обратиться к рассматриваемым устройствам, чтобы повысить производительность и отказоустойчивость Web-хозяйства.

Rotary DNS - способ такого изменения элементов DNS, чтобы запросы, поступающие на одно виртуальное имя, могли обслуживаться несколькими машинами. При этом связанные с данным виртуальным именем машины будут обрабатывать запросы по очереди.

Поскольку в Rotary DNS используется стандартная система DNS, невозможно предсказывать и контролировать кэширование для клиентов, а следовательно, реальную нагрузку на серверы. Подключение и отключение машин отнимают много времени, поскольку изменения DNS затрагивают всю сеть; немало трафика может быть направлено к машине, которая была отключена уже несколько часов (или даже дней) тому назад. Технология Rotary DNS меняет IP-адрес, связанный с виртуальным узлом, но не оказывает никого влияния на выбор протоколов или портов, используемых по этому адресу.

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

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

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

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

Алгоритм балансировки нагрузки, получивший название "самый быстрый" (fastest) отслеживает длительность обработки запроса машиной и отсылает трафик серверу с максимально возможной скоростью отклика.

Метод наибольшего числа подключений (most connections) обеспечивает такое распределение нагрузки на машины, чтобы эта нагрузка не превышала максимально допустимые значения.

Поддерживаемые алгоритмы балансировки

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

Достоинства и недостатки средств балансировки нагрузки

Пропускная способность средств балансировки

Корпорация Merrill Lynch испытывает Local Director

Во время подготовки настоящего обзора мы получили электронное сообщение от Энди Сурани, вице-президента по распределенным архитектурам и техническому обеспечению корпорации Merrill Lynch & Co. Его группа только что завершила испытание продукта Local Director фирмы Cisco Systems, и он спрашивал, не хотим ли мы узнать результаты этого тестирования. Мы ответили согласием, и полученный документ оказался вполне впечатляющим, доказав, что в Merryll Lynch разбираются в тестировании.

Анализировались следующие возможности продукта Local Director, версия 1.7:

В испытательной лаборатории имеется ряд рабочих станций и серверов на базе процессоров Pentium фирмы Intel, которые были сконфигурированы посредством Windows NT Server 4.0 (Service Pack 3). Серверы настраивались также с помощью ПО Enterprise Server 2.0 Web server фирмы Netscape Communications. Рабочие станции и серверы подключались к отдельным локальным сетям на коммутаторе Cisco Catalyst 5000 Ethernet и, в свою очередь, связывались с помощью Local Director. Исходная конфигурация была реализована без Local Director, а затем он был введен в сеть в качестве распределителя нагрузки.

Local Director тестировался на время ожидания с помощью трех из четырех предоставленных алгоритмов - наименьшего числа подключений, "самого быстрого" и кругового. Максимальная скорость исходной конфигурации составила 2950 подключений в секунду. Алгоритм наименьшего числа подключений был способен установить до 2970 подключений в секунду (при использовании 70% имеющейся полосы пропускания на 100 Мбит/с). Круговой алгоритм выдал 2850 подключений в секунду (67 Мбит/с из полосы пропускания). Алгоритм "самый быстрый" достиг 2500 подключений в секунду (использовались 60% полосы пропускания). Похоже, что он "отдавал предпочтение" двум серверам из трех: на этих двух серверах загрузка центральных процессоров превышала 90%, тогда как на третьем была существенно меньшей.

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

Производительность Local Director оказалась выше, чем ожидалось. Согласно сведениям Cisco, продукт должен обрабатывать данные без ухудшения эффективности на скорости до 45 Мбит/с. Во время испытаний данные поступали на Local Director со скоростью 70 Мбит/с - при минимальном ухудшении эффективности и безо всяких сбоев.