СПОСОБЫ РАСПРЕДЕЛЕНИЯ НАГРУЗКИ В КЛАСТЕРЕ INTERNET СЕРВИСОВ

СПОСОБЫ РАСПРЕДЕЛЕНИЯ НАГРУЗКИ В КЛАСТЕРЕ INTERNET СЕРВИСОВ
В.П. Петлинский
ФГУП "ГНЦ РФ НИИАР", г.Димитровград,Ульяновской обл.
Результаты, представленные в работе, получены в процессе эксплуатации в ФГУП "ГНЦ РФ НИИАР" кластерных систем высокой готовности High-Availability(HA-system – время восстановления после сбоя (failover) ~
порядка 10 сек.) с простой архитектурой, ориентированных на поддержку Internet/Intranet сервисов и WEB приложений. В ГНЦ РФ НИИАР работают два таких кластера. Первый(для Intranet сервисов) находится в постоянной
эксплуатации более года, второй(для Internet сервисов) около полугода.
Рассматриваемые кластерные системы предназначены для работы в условиях, когда предъявляются жесткие требования к высокой доступности установленных на ней сервисов и приложений. В процессе проектирования
и разработки делалась ориентация на недорогие кластерные решения, которые можно бы было реализовать своими
силами на платформе оборудования Intel и базовом программном обеспечении (ПО), распространяемом на условиях GPL лицензии. Достичь поставленных целей удалось, используя ряд новых решений, реализованных в рамках
проекта High-Availability Linux Project на платформе операционной системы Linux. При создании кластера использованы: свободно распространяемый код программного обеспечения Кластер-Менеджера (пакет Heartbeat) и модуль сетевого зеркалирования разделяемых в кластере данных (пакет DRBD – первая версия ~ июнь 2000г.), позволяющий избавиться от дорогостоящей разделяемой между узлами кластера шины SCSI. Структура двух узлового
кластера и состав основных технических компонент его составляющих достаточно подробно описаны в [3].
В состав ПО кластера входят: – базовая ОС Linux; базовое кластерное ПО (подсистема членства в кластере,
3
коммуникационная подсистема, подсистема Кластер-Менеджера, подсистема мониторинга ресурсов, подсистема
обобществления данных); специальным образом сконфигурированное ПО сервисов – DHCP, DNS, электронной
почты(Postfix и Courier), WWW, FTP, Samba, MySQL, proxy(Squid) и т.п.; утилита администратора кластера.
Различают три класса кластерных систем – с горячим резервированием, с распределенной нагрузкой и балансировкой нагрузки. Описываемые кластеры относятся к классу кластерных систем с распределенной нагрузкой.
Универсальная схема распределения нагрузки, работающая для всех видов сервисов, выглядит следующим образом. Распределение сервисов по узлам выполняет администратор кластера в процессе конфигурирования заданий
для Кластер-Менеджера каждого из узлов. Живучесть сервисов в ходе эксплуатации обеспечивается кластерным
ПО прозрачным для клиентов образом. Принцип переключения сервисов и поведение клиентов по этой схеме в
момент отказа одного из узлов иллюстрирует
В то-же время существует ряд специальных случаев, для которых распределение нагрузки по узлам кластера, можно реализовать по схемам отличным от универсальной. С этим мы столкнулись в процессе эксплутации
кластера для Internet сервисов. Применение этих специальных схем, как будет показано далее, позволяет получить
дополнительные выгоды либо с точки зрения уровня резервирования и живучести, либо с точки зрения более равномерного распределения загрузки узлов кластера.
Первый специальный случай относится к сервису DNS. Как известно, в DNS существуют встроенные средства репликации данных доменных зон между первичными и вторичными серверами. Сведения о серверах , обслуживающих и ответственных за каждую доменную зону хранятся в самом ее описании, и известны DNS серверам
вышестоящих уровней. Это позволяет при отказе первичного сервера выполнять запросы на разрешение имен для
клиентов из "чужих" доменов через вторичные серверы. На клиентах "родного" домена приоритетность обращения
к DNS серверам регулируется порядоком их перечисления. Мы используем в качестве первичного DNS(Сервис-П),
привязанный к переходящему IP-alias адресу, а в качестве вторичных DNS(Сервис-В), привязанные к собственным
IP адресам узлов. При этом мы получаем четыре копии зон(две за счет зеркалирования и две за счет репликации) и
три одновременно работающих процесса обслуживающих DNS запросы(в обычном режиме). В случае отказа одного из узлов имеется минимум один процесс, обслуживающий запросы с failover = 0 сек. Клиенты DNS на узлах кластера для ускорения работы, сконфигурированы таким образом, что их запросы в первую очередь адресуются к
локальным DNS процессам.
Второй специальный случай относится к почтовой службе SMTP. Для SMTP сервиса также возмжно через
службу DNS указать несколько IP адресов серверов, исполняющих SMTP запросы (записи типа MX в доменной
зоне). Этот сервис относится к типу ничего не разделяющих(shared nothing) в кластерной терминологии(все данные
на отправку временные и хранятся в очередях пересылки), поэтому для него не нужны какие либо средства зеркалирования/репликации. Положительный эффект в этом случае – три рабочих процесса в обычном режиме и минимум один с failover = 0 сек. при отказе одного из узлов. Принцип обслуживания запросов и поведение клиентов при
отказе одного из узлов для этих двух случаев иллюстрирует Рис.2. По существу в обеих этих случаях обеспечивается горячее резервирование сервисов. На рисунке не показан процесс перехода Сервис-П на узел 2, он происходит
стандартно, как на Рис.1
Третий специальный случай относится к службе проксирования. Мы обеспечиваем прокси-сервис на базе
Squid[4], проксирующий и кэширующий все HTTP, FTP и другие URL запросы пользователей ГНЦ РФ НИИАР к
Web. Не вдаваясь в детали технологии проксирования, отметим, что основной эффект от использования прокси
заключается в ускорении обслуживания запросов клиентов и сокращении Internet трафика, за счет использования
промежуточного кэша данных, полученых ранее из Internet. Использование универсальной схемы в данном случае
неэффективно, т.к. зеркалировались бы по существу временные данные. Более эффективным является решение на
базе архитектуры Масштабируемого Кэширующего Прокси Кластера (Scalable Caching Proxy Cluster), впервые
предложенной SHARP Corp.[5]. Это решение известно также, как "Super Proxy Script", потому что базируется на
использовании хэширующего Java Script на стороне клиента для выбора нужного прокси-сервера из N, входящих в
кластер. Основная идея заключается в том, что для каждого заданного URL вычисляется некоторая уникальная
checksum, затем от нее определяется хэш-функция i = Modul(checksum(URL),N), собственно значение i и используется для выбора нужного прокси. Запросы к одному и тому же URL всегда маршрутизируются на тот-же самый
прокси, таким образом исключается дублирование данных в кэшах разных прокси, обеспечивается быстрый и
надежный способ проксирования без использования протокола ICP для прокси-сервисов, входяших в кластер. Браузеры на клиентских машинах должны быть сконфигурированы для работы с автоматическим прокси-скриптом ( в
браузерах Netscape это возможно начиная с 3-ьей версии, в Inernet Explorer с 4-ой). Авто-прокси скрипт
FindProxyForURL, используемый в ГНЦ РФ НИИАР приведен ниже. Данный скрипт обеспечивает равномерную
загрузку прокси на обеих узлах кластера(50% на 50%).
function FindProxyForURL(url, host)
{
if (isPlainHostName(host) ||
4
dnsDomainIs(host, ".dom0.niiar.ru") ||
dnsDomainIs(host, ".dom1.niiar.ru") ||
dnsDomainIs(host, ".dom2.niiar.ru") ||
dnsDomainIs(host, ".dom3.niiar.ru") ||
dnsDomainIs(host, ".dom4.niiar.ru") ||
dnsDomainIs(host, ".dom5.niiar.ru") ||
dnsDomainIs(host, ".dom6.niiar.ru") ||
dnsDomainIs(host, ".dom7.niiar.ru") ||
dnsDomainIs(host, ".niiar.ru") ||
isInNet(host, "172.16.0.0", "255.255.252.0") ||
isInNet(host, "192.168.0.0", "255.255.224.0") ||
isInNet(host, "213.242.40.64", "255.255.255.224"))
return "DIRECT";
else
ret = URLhash(url);
if ( (ret % 2) == 0 ) {
return "PROXY proxy1.niiar.ru:3128 ; PROXY proxy2.niiar.ru:3128";
} else {
return "PROXY proxy2.niiar.ru:3128 ; PROXY proxy1.niiar.ru:3128";
}
;
}
/*
<------------------------------------->
directory name hashing here
*/
function URLhash(name)
{
var cnt=0;
var dirptr=0;
var str=name.toLowerCase(name);
if ( str.length ==0) {
return cnt;
}
/* skip filename in directory */
for(var i=str.length – 1;i >=0 ; i--) {
if ( str.substring(i,i +1) == '/' ) {
dirptr = i+1 ;
break;
}
}
for(var i=0;i < dirptr; i++) {
var ch= atoi(str.substring(i,i + 1));
cnt = cnt + ch;
}
return cnt ;
}
function atoi(charstring)
{
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring == "g" )
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring ==
if ( charstring ==
"a" ) return
"c" ) return
"e" ) return
return 0x67;
"i" ) return
"k" ) return
"m" ) return
"o" ) return
"q" ) return
"s" ) return
"u" ) return
"w" ) return
"y" ) return
0x61; if ( charstring ==
0x63; if ( charstring ==
0x65; if ( charstring ==
if ( charstring == "h" )
0x69; if ( charstring ==
0x6b; if ( charstring ==
0x6d; if ( charstring ==
0x6f; if ( charstring ==
0x71; if ( charstring ==
0x73; if ( charstring ==
0x75; if ( charstring ==
0x77; if ( charstring ==
0x79; if ( charstring ==
5
"b" ) return
"d" ) return
"f" ) return
return 0x68;
"j" ) return
"l" ) return
"n" ) return
"p" ) return
"r" ) return
"t" ) return
"v" ) return
"x" ) return
"z" ) return
0x62;
0x64;
0x66;
0x6a;
0x6c;
0x6e;
0x70;
0x72;
0x74;
0x76;
0x78;
0x7a;
if ( charstring
if ( charstring
if ( charstring
if ( charstring
if ( charstring
if ( charstring
return 0x20;
==
==
==
==
==
==
"0"
"2"
"4"
"6"
"8"
"."
)
)
)
)
)
)
return
return
return
return
return
return
0x30;
0x32;
0x34;
0x36;
0x38;
0x2e;
if
if
if
if
if
(
(
(
(
(
charstring
charstring
charstring
charstring
charstring
==
==
==
==
==
"1"
"3"
"5"
"7"
"9"
)
)
)
)
)
return
return
return
return
return
0x31;
0x33;
0x35;
0x37;
0x39;
}
Данный метод позволяет вводить элементы балансировки нагрузки в кластере. Например, задав if ( (ret %
3) < 2 ) мы нагрузим proxy1 в два раза больше, чем proxy2, если к примеру он в два раза производительнее другого.
Схема обслуживания клиента в момент отказа одного из узлов, аналогична изображенной на Рис.2, с той лишь разницей, что запрос "Кто обслуживает сервис?" разрешается локально.
Из всего вышесказанного следует, что гибко комбинируя разные схемы распределения сервисов, в кластере
простой архитектуры можно добиться хорошего баланса загрузки обеих узлов, без использования дополнительного
компьютера – директора кластера.
ЛИТЕРАТУРА:
1.
2.
3.
4.
5.
Robertson,A.L.,:"The High-Availability Linux Project". Http://linux-ha.org/
Philipp
Reisner:"DRBD"
http://www.complang.tuwien.ac.at/reisner/drbd/publications/drbd_paper_for_NLUUG_2001.pdf
Петлинский В.П., Кинский А.О. Кластер простой архитектуры для поддержки Intranet/Internet сервисов ГНЦ
РФ НИИАР на платформе Linux. В сборнике трудов 3-й Всероссийской научной конференции "Научный сервис в сети Интернет", Новороссийск, 2001, Изд-во "Открытые системы".
http://www.squid-cache.org/
http://naragw.sharp.co.jp/sps/
6