Ключевые слова:web, balance, optimization, cluser, carp, freebsd, (найти похожие документы)
From: Евгений Расюк <evgeniy.rasyuk@gmail.com.>, http://mambo5.ru
Newsgroups: email
Date: Mon, 26 Jul 2006 14:31:37 +0000 (UTC)
Subject: Распределение нагрузки на WEB приложения.
Распределение нагрузки на WEB приложения.
Основные технологические моменты.
Решения на основе дешевых компьютеров объединенных в единый кластер
давно себя зарекомендовали на загруженных 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 адресом использует в качестве адреса обратной связи
(back interface address) виртуальный IP системы балансировки. То есть
для работы системы требуются, что бы у всех хостов был публичный IP
адрес, плюс еще дополнительный для организации кластера.
Особенности при разворачивании балансировки нагрузки этого типа:
* все узлы должны быть сбалансированы по производительности, так же
все сетевые карточки должны быть объединены общим сетевым устройством (switch).
* Так же необходимо на этом коммутаторе выключить VLAN, TRUNK, VPN
и другие подобные опции.
* В случае если маршрутизатор НЕ поддерживает возможность "подмены"
МАС адреса, то создать на нем статическую ARP запись. Это же имеет
смысл и для FreeBSD
FreeBSD 5.5 CARP
Для FreeBSD вполне хватит встроенной документации (carp(4), sysctl(3),
ifconfig(8)). Для общего развития можно прочитать документ "Firewall
Failover with pfsync and CARP" Ryan McBride. В принципе этих статьей
(как всегда) вполне достаточно для работы, приведу небольшую выдержку из
основных настроек.
Стоить отметить, что возможны два режима работы: для обеспечения
отказоустойчивости (второй узел находится в состоянии ожидания) и в
режиме балансировки нагрузки.
Процедура настройки состоит из следующих этапов
1)Ядро должно быть собрано со следующей опцией
device carp #Common Address Redundancy Protocol
2)Настройка ядра
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)
3) создание сетевого 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 http://balance.sourceforge.net/ функциональная и надежная. В
отличие от redirect, она умеет перекидывать трафик в другие сети, в
отличие от prtunnele она умеет слушать только на определенном IP, и не
падает при нагрузках. У balance есть "старший" - брат BalanceNG - в
дополнение к обычной балансировке эта программа позволяет еще и
проксировать tcp трафик.
Delegate http://www.delegate.org мультиплатформенная (Unix, Windows,
MacOS X and OS/2) многофункциональная программа. Поддержка основных
протоколов (HTTP, FTP, NNTP, SMTP, POP, IMAP, LDAP, Telnet, SOCKS, DNS,
etc), есть возможность кэширования, использование фильтров, авторизации
PAM, настройка доступа по IP.
WEB проксирование
Задача балансировки решается с помощью данной технологии, используя один
из двух механизмов: proxy-сервера в режиме http-акселератора и
web-серверов в режиме reverse-proxy.
У web-серверов есть неоспоримое преимущество, они работают с запросами
клиентов на "своем" поле, т.е. могут производить требуемые разработчику
преобразования (rewrite url, GEO ip, расширенная обработка логов, ошибок
и т.д.) до отправки пакетов узлам кластера.
Вместо классического решения на базе Apache (для Windows и Unix),
выгодней использовать специализированные web-сервера (lighttpd, PHHTTPD)
отличающихся гораздо меньшими требованиями к вычислительным ресурсам.
Стоит особо отметить проект Игоря Сысоева http://sysoev.ru/ - Nginx -
меня поразила простота синтаксиса конфигурационного файла, богатство
используемых технологий и подключаемых модулей. И самым большим плюсом
этого проекта, является моментальная реакция автора на выявленные
ошибки.
p.s. Сравнение всех технологий:
MAT - является самой капризной к своему сетевому окружению, зато
является прозрачной для приложений в работе. Программы не обязаны знать,
что они работают в кластере (это касается передачи IP адреса клиента и
других параметров).
TCP-шлюз простые решения, но мы теряем IP клиента и это не всегда
приемлимо.
Web server в режиме reverse-proxy - самое удобное и лучшее решение.
Позволяет многое сделать в оптимизации запросов, сохраняет IP клиента.
WEB приложение требует небольшой оптимизации, в связи с подменой
передаваемых переменных. Но не позволяет стабильно работать коммерческим
web-приложениям, которые активно используют activeX компоненты для IE,
или подключаемые модули для FireFox
>> * В случае если маршрутизатор НЕ поддерживает возможность "подмены"
>> МАС адреса, то создать на нем статическую ARP запись. Это же имеет
>> смысл и для FreeBSD
Это решение "в лоб". Существует более элегантное решение основанное на отправке самообращенного ARP-запроса, описанного в рамках RFC на ARP.
Суть проблемы такова, что на интерфейсе типа Ethernet, где активен ng_ether, по умолчанию нельзя системными средствами передать фрейм, содержащий "чужой" source MAC address -- он будет заменен на действительный MAC address, присвоенный интерфейсу. Неудивительно, что программы и протоколы, зависящие от данной возможности, будут сбоить.
В этой ситуации должна помочь следующая команда (где ${IFACE} равен имени нужного интерфейса):
ngctl msg ${IFACE}: setautosrc 0
Она отключает автоматическую подстановку source MAC address на узле ng_ether, отвечающем интерфейсу ${IFACE}.
Load balancing isn't perfect, either. Because CARP uses a hash of the originating IP address to determine which system handle the request, it can only do so much. Don't expect equal distribution; one user reported 80/20 between his two firewalls, and my own testing (albeit low-traffic, unscientific, and informal) got roughly that.
....Про Cisco известно то, что у них
по умолчанию ARP timeout несколько часов. Поэтому в тех случаях, когда
ARP часто меняется, на роутере Cisco нужно руками указать приемлемое
значение для ARP timeout.
