2006 г.
Распределение нагрузки на WEB приложения
Евгений Расюк, mambo5.ru
Основные технологические моменты.
Решения
на основе дешевых компьютеров объединенных в единый кластер давно
себя зарекомендовали на загруженных 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