СПОСОБЫ РАСПРЕДЕЛЕНИЯ НАГРУЗКИ В КЛАСТЕРЕ 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