Распределение нагрузки на WEB приложения

Евгений Расюк

🕛 10.08.2006, 11:24

Основные технологические моменты.

Решения на основе дешевых компьютеров объединенных в единый кластер давно себя зарекомендовали на загруженных Web-сайтах. С точки зрения клиента вся эта группа машин выглядит как единый экземпляр сервера, они работают идентично одиночным серверам, но в дополнении к ним обеспечивают балансировку нагрузки и передачу управления при сбое.

Кластеризация дает следующие преимущества:

Балансировка запросов, равномерная или определяемая правилами

Отказоустойчивость к сбоям

«Линейное» увеличение производительности

Прозрачное обслуживание и замена узлов кластера

Кластеры бывают трех типов:

High availability-clusters - HA-clusters - кластеры высокой доступности - на основе общего дискового массива. Обычно используют SCSI RAID или SAN (в единицу времени только один из узлов может владеть этим массивом, и соответственно выполнять приложение, другие находится в вечном ожидании).

High Performance Computing Clusters - HPC-clusters - кластеры для обеспечения производительности вычислений. Создаются для распределения одной задачи на множество компьютеров.

Massive Parallel Processing Clusters - MPP-clusters - кластеры для обеспечения масштабируемости сервисов. Создаются для распределения множества однотипных задач на множество компьютеров. Данный тип кластера обычно используется для организации WEB - ферм и мы его рассмотрим более подробно.

Различают две основные разновидности типов кластеризации серверов в случае MPP-clusters:

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

«горизонтальная» - более традиционный подход - это определение клонов приложения на нескольких машин, сформировав для них единый образ системы.

Вполне разумно использование на узлах кластера еще и transparent-proxy или http-сервера в режиме web-акселератора, что позволит создать дополнительное «вертикальное» звено, для оптимизации нагрузки

Использование систем балансировки накладывает определенные обязанности на разработчиков - использование общего или реплицированного источника данных, общего хранилища файлов (NFS), общие для всех файлы настроек и т.д. т.п.

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

сетевом - трансляция адресов с управлением к среде передачи (подмена MAC адреса)

транспортном - перенаправление TCP трафика (port-mapping, NAT)

прикладном - работа через web-акселераторы для оптимизации HTTP запросов (apache mod_accel,mod_bakhand,mod_proxy),lighttpd,nginx).

Отдельно надо сказать про технологию DNS Round Robin, когда сервер имен на каждый новый запрос на преобразование имени в IP отдает очередной адрес из введенного ранее пула. Эта технология неэффективна и может использоваться только в смешанном варианте с другими, так как каждый провайдер имеет в своем распоряжении кэширующие DNS сервера, которые сводят на НЕТ все плюсы.
Трансляция адресов с управлением к среде передачи
(Media access control (MAC) address translation - MAT)

Данная технология реализуется программным способом при условии соблюдении следующего постулата, что каждый узел имеет наряду с уже существующим IP адресом использует в качестве адреса обратной связи (loopback interface address) виртуальный IP системы балансировки. То есть для работы системы требуются, что бы у всех хостов был публичный IP адрес, плюс еще дополнительный для организации кластера.

Особенности при разворачивании балансировки нагрузки этого типа:

все узлы должны быть сбалансированы по производительности, так же все сетевые карточки должны быть объединены общим сетевым устройством (switch).

Так же необходимо на этом коммутаторе выключить VLAN, TRUNK, VPN и другие подобные опции.

Microsoft особо отмечает, что лучшей практикой будет, в случае если маршрутизатор НЕ поддерживает возможность «подмены» МАС адреса, то создать на нем статическую ARP запись. Это же имеет смысл и для FreeBSD

Общая концепция и принцип реализации в Microsoft Windows и FreeBSD не говорит о схожести реализации. Поэтому рассмотрим детали
Microsoft Windows 2003 NLB

Данная технология в Microsoft классифицируется как Network Load Balancing (NLB)

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

Есть несколько ограничений и требований, на которые обращает внимание Microsoft и их необходимо выполнить

Windows не поддерживает использование кластеров с общим RAID массивом (HA-cluster) и NLB на одной машине.

Сетевой трафик должен быть уже очищен от «мусора», то есть необходимо размещать сервера в DMZ - никто не гарантирует стабильность работы в случае DOS атаки.

Работаем только с TCP/IP, все остальные протоколы не поддерживаются (естественно!)

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

Типичными Windows приложениями для NLB являются IIS,ISA,VPN, Windows Media™ , Mobile InformationServer, Terminal Services.

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

Создание кластера происходит с помощью инструмента Network Load Balancing Manager из меню Administrative Tools.

Так же для администрирования, уже по давно принятой традиции в Microsoft, можно использовать CLI интерфейс с помощью команды nlb

Настраиваемыми параметрами являются

Прослушиваемые TСP порты

И способа их обработки - перенаправление, привязка клиента к обрабатывающему серверу (обеспечивая тем самым «сеансовость»)

Создание виртуального IP

Выбор используемой сетевой карточки

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

Так же, стоить отметить, что Microsoft в своем арсенале еще имеет кластер на основе общего дискового массива и балансировку COM+ компонент.
FreeBSD 5.5 CARP

Для FreeBSD вполне хватит встроенной документации (carp(4), sysctl(3), ifconfig(8)). Для общего развития можно прочитать документ “Firewall Failover with pfsync and CARP” Ryan McBride. В принципе этих статьей (как всегда) вполне достаточно для работы, приведу небольшую выдержку из основных настроек.

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

Процедура настройки состоит из следующих этапов
Ядро должно быть собрано со следующей опцией:
device carp #Common Address Redundancy Protocol
Настройка ядра
net.inet.carp.allow - принимать входящие пакеты carp. (default 1)
net.inet.carp.preempt - позволяет виртуальным хостам резервировать друг друга. (default 0).
net.inet.carp.log - ведение логов 0,1,2. ( default 1).
net.inet.carp.arpbalance - балансировка локального трафика. (default 0)
создание сетевого carp интерфейса ifconfig carpN create. Настраиваемые параметры:
advbase и advskew, используются для настройки интервалов посылок объявлений главным хостом группы
pass служит для идентификации carp.
carpdev используется для определения интерфейса, на котором будет размещен carp.
vhid - идентификатор carp-интерфейса.

На сетевом интерфейсе уже должен присутствовать IP адрес из настраиваемой сети.

Пример, создаем виртуальный адрес 192.168.1.10:

Настраиваем ядро
sysctl net.inet.carp.arpbalance=1

На 1 машине:

ifconfig carp0 create
ifconfig carp0 vhid 1 pass SecretPassword 192.168.1.10/24
ifconfig carp1 create
ifconfig carp1 vhid 2 advskew 100 pass SecretPassword 192.168.1.10/24

на 2 машине

ifconfig carp0 create
ifconfig carp0 vhid 1 advskew 100 pass SecretPassword 192.168.1.10/24
ifconfig carp1 create
ifconfig carp1 vhid 2 pass SecretPassword 192.168.1.10/24

И на последнем этапе определяем arp адрес и прописываем его на маршрутизаторе.
Перенаправление TCP трафика(организация TCP шлюза)

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

В случае FireWall решений есть несколько особенностей при реализации:

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

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

Таких ограничений нет у программных TCP редиректоров. Мне удалось поработать с некоторыми (prtunnele, balance, delegate,pen).

Prtunnele - наколенная поделка с богатыми возможностями проброски трафика через промежуточные proxy сервера и нестабильностью работы.

Balance функциональная и надежная. В отличие от redirect, она умеет перекидывать трафик в другие сети, в отличие от prtunnele она умеет слушать только на определенном IP, и не падает при нагрузках. У balance есть «старший» брат - BalanceNG - в дополнение к обычной балансировке эта программа позволяет еще и проксировать tcp трафик.

Delegate - мультиплатформенная (Unix, Windows, MacOS X и OS/2) многофункциональная программа. Поддержка основных протоколов (HTTP, FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, SOCKS, DNS, etc), есть возможность кэширования, использование фильтров, авторизации PAM, настройка доступа по IP.

Для Windows можно порекомендовать использовать портированную PEN (ACL, «весы для узлов», поддержка SSL) - простой и надежный балансировщик.

WEB проксирование

Задача балансировки решается с помощью данной технологии, используя один из двух механизмов: proxy-сервера в режиме http-акселератора и web-серверов в режиме reverse-proxy.

У web-серверов есть неоспоримое преимущество, они работают с запросами клиентов на «своем» поле, т.е. могут производить требуемые разработчику преобразования (rewrite url, GEO ip, расширенная обработка логов, ошибок и т.д.) до отправки пакетов узлам кластера.

Вместо классического решения на базе Apache (для Windows и Unix), выгодней использовать специализированные web-сервера (lighttpd, PHHTTPD) отличающихся гораздо меньшими требованиями к вычислительным ресурсам.

Стоит особо отметить проект Игоря Сысоева - Nginx - меня поразила простота синтаксиса конфигурационного файла, богатство используемых технологий и подключаемых модулей. И самым большим плюсом этого проекта, является моментальная реакция автора на выявленные ошибки.
p.s. Сравнение всех технологий:

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

TCP-шлюз простые решения, но мы теряем IP клиента и это не всегда приемлимо.

Web server в режиме reverse-proxy - самое удобное и лучшее решение. Позволяет многое сделать в оптимизации запросов, сохраняет IP клиента. WEB приложение требует небольшой оптимизации, в связи с подменой передаваемых переменных. Но не позволяет стабильно работать коммерческим web-приложениям, которые активно используют ActiveX компоненты для IE, или подключаемые модули для FireFox