CC BY
43Математическая модель и метод построения сервиса балансирования нагрузки между серверами асимметричной фермы
Протасов С.С. , Белоусов С. М., Тормасов А. Г. [email protected]).
Исследовательское подразделение компании SWsoft, Inc, USA.
В статье описана математическая модель и метод балансировки нагрузки в асимметричной серверной ферме. Описанная в статье модель построена с использованием теории сетей массового обслуживания и базируется на модели замкнутой сети СМО, описанной в работе [1].
Предложенный метод позволяет существенно повысить эффективность использования ресурсов системы. Метод нашел практическую реализацию при разработке пакета программ виртуализации ресурсов Virtuozzo.
Описание задачи
Как известно, для организации предоставления любого сервиса необходимо наличие соответствующего сервера. Так, Web-сервер это компьютер-сервер, посредством которого сервис предоставляется клиентам.
Обычный способ предоставления сервиса клиенту - это обслуживание его запросов. Обслужить запрос - значит получить запрос и выслать запрашивающей стороне ответ на него.
Web-сервер обладает ограниченным вычислительным ресурсом, то есть может выполнить лишь конечное число операций за единицу времени. Следует помнить, что для построения ответа на запрос требуется произвести некоторое количество операций. Следовательно, web-сервер может обслужить за единицу времени лишь конечное число запросов, которое определяется вычислительной мощностью web-сервера.
Если за единицу времени количество поступивших от клиентов запросов превышает вычислительные возможности сервера, то некоторое число запросов останется не обслуженными. Что бы уменьшить количество необслуженных запросов, необходимо увеличить вычислительную мощность сервера.
Наиболее прямолинейный подход к увеличению мощности web-сервера -использовать более мощный компьютер. Это решение имеет недостатки: во-первых, мощность предлагаемых промышленностью компьютеров ограничена, а во-вторых - стоимость компьютера возрастает быстрее чем его производительность, то есть стоимость в два раза более мощного компьютера возрастет больше чем в два раза.
Другой подход, лишенный вышеуказанных недостатков, состоит в том, чтобы использовать для обслуживания клиентских запросов несколько ,№еЬ-серверов. При этом стоимость решения будет прямо пропорциональна его мощности, и верхний предел на вычислительную мощность определяется не уровнем аппаратной технологии, а количеством web-серверов.
Традиционно сложилось, что множество компьютеров, которые совместно обрабатывают запросы, называется <теЬ-фермой». Компьютеры, принадлежащие web-ферме, называются «реальными серверами».
Согласно принципам организации глобальной сети Интернет, запрос, направляемый на определенный адрес, может получить только один компьютер в сети. Таким образом, для того, что бы запросы, направляемые на адрес web-сервера, могли обрабатывать несколько реальных серверов на компьютере, которой принимает запросы, должен быть запущен специальный сервис, который называется «сервисом балансировки нагрузки». Сервис балансировки нагрузки предназначен для выполнения следующих основных задач:
• прием запросов от клиента;
• выбор реального сервера, который будет обрабатывать данный запрос от клиента;
• перенаправление запроса от клиента реальному серверу;
• прием ответа реального сервера на клиентский запрос;
• перенаправление ответа реального сервера на запрос запрашивающему клиенту.
Таким образом, все запросы, попадающие к web-ферме, проходят сначала через сервис балансировки нагрузки. Следовательно, на обработку одного запроса сервису балансировки нагрузки требуется процессорное время. Поэтому мощность web-сервера в целом ограничена не только мощностью фермы, но и мощностью компьютера, на котором запущен сервис балансировки нагрузки. Отсюда видно, насколько важно реализовать сервис для балансировки нагрузки максимально эффективно.
По типу используемой аппаратуры можно выделить два типа ферм -симметричные фермы и асимметричные фермы. Будем называть ферму симметричной, если все сервера фермы способны обрабатывать одинаковое множество запросов. Будем называть ферму асимметричной, если каждый ее сервер специализирован для обработки какого-то одного класса запросов. Например, в случае НТТР-сервиса, один сервер асимметричной фермы может специализироваться по обработке запросов на текстовые Ыш1-страницы, а другой сервер специализироваться на обработке запросов на мультимедиа файлы.
В то время как в случае симметричной фермы, оба сервера обязаны быть способными обработать запрос на оба типа ресурсов.
Способы построения сервиса балансирования нагрузке между серверами симметричной и асимметричной фермы существенно различаются.
Рис. 1 Модель СМО с центральным обслуживающим прибором
В случае симметричной фермы сервис балансировки нагрузки не должен определять, какой ресурс запрошен клиентом, так как все реальные серверы располагают одинаковым набором ресурсов. Поэтому сервис балансировки нагрузки должен принять соединение и, не дожидаясь поступления запроса, выбрать произвольный реальный сервер для его обслуживания.
Несмотря на простоту устройства симметричной фермы, ее сложно обслуживать. Администратор должен постоянно заботиться о том, что бы все серверы имели строго одинаковое содержимое. Это достаточно сложно с технической точки зрения. Кроме того, это ведет к дополнительным накладным расходам долговременной памяти, так как копия каждого ресурса должна присутствовать на каждом реальном сервере.
Математическая модель вычислительного кластера
Формальную постановку задачи балансировки нагрузки проведем с использованием модели замкнутой сети массового обслуживания с центральным обслуживающим прибором [1]. Она позволяет отразить архитектуру кластера (Рис.1).
Узлы кластера
Она позволяет описать работу мультипрограммной вычислительной системы (с фиксированным числом частей), в которую допускается точно К заданий. Эти задания циркулируют в системе бесконечно долго, коллективно используя N ее ресурсов. Центральный обслуживающий прибор (узел 1) представляет собой корневой узел кластера, а остальные N-1 узлов — периферийные узлы кластера. В такой системе задания циркулируют между узлами кластера, требуя обращения сначала к корневому узлу, а затем к некоторому периферийному узлу кластера, после этого опять требуя обслуживания в центральном узле, а затем вновь обращения к какому-нибудь периферийному узлу кластера и т. д. Следовательно, все время задания возвращаются в корневой узел кластера. Переходные вероятности гг, представляют собой вероятности перехода задания в узел , из узла г; в рассматриваемой модели с центральным обслуживающим прибором имеем
Г г
Р,
г = 1, 1 < , < N,
1, 2 < г < N, у = 1, 0 в остальных случаях
где,
IР, = 1. В
1=1
реальной мультипрограммной ситуации большинство
заданий в конце концов покидают систему, и в моменты их ухода в систему по одному входят новые задания. Это учтено в модели путем разрешения заданию прямого возвращения в корневой узел (с вероятностью р1), что означает уход старого задания и поступление вместо него нового задания, причем новое требование на обслуживание в корневом узле является заявкой супервизорной системы на замену задания. Таким образом, число заданий в системе остается постоянным и равным К. В модели с центральным обслуживающим прибором в каждом узле находится один обслуживающий прибор (тг=1), а время обслуживания в г-м узле распределено по показательному закону с параметром /1г. Пусть матрица R является матрицей переходных вероятностей R (г,) между узлами сети. Тогда случай с центральным обслуживающим прибором можно описать следующей простой матрицей:
Я =
Р: Р 2 Рз
1 0 0 1 0 0
РN
0 0
0 0
1
0
Задача сводится к решению уравнения для рассматриваемой
матрицы решение имеет вид
М?
MPt
i = 1,
i = 2,3,..., N.
Общее решение для любой замкнутой марковской сети массового обслуживания с однолинейными СМО в узлах дается равенством
1 N
Pikг, к kN,
)=^ п G(K) i=1
Xi ,
включающим х, [1], В частном случае рассматриваемой модели с центральным обслуживающим прибором получаем
1 N
p(ki, к 2,--, kN,) =
G(K ) i=1
/
Л
MiP,
V Мг у
где
N
G( K) = ^П
/
кеЛ i=2
\
М\Рг
V Мг У
Следовательно, имеем явное решение, выражаемое через параметры системы [ и д. Пусть теперь А, — стационарная вероятность того, что 1-й узел не пуст. Можно показать [1], что:
О (К -1)/ О (К), I = 1,
МРг
Л, =
М
"Л:
i = 2,3,..., N.
Отсюда, согласно выводам работы [1], получаем А1^1р1 = ä^, (i>2), т. е. интенсивность, с которой задания поступают в i-й узел, равна интенсивности, с которой они покидают этот узел. Это равенство показывает, что мера, определяющая, насколько узкое место создается в i-м узле, пропорциональна скорости изменения производительности в зависимости от роста интенсивности обслуживания в этом узле. При этом производительность определяется как среднее число заданий, обслуживаемых за единицу времени. Она равна А1^1р1. Следовательно, сбалансированная система (система без узких мест) — это такая система, для которой:
7МАм'Р'=МАм'Р'' 1 1S N
Теперь, основываясь на результатах приведенного анализа, рассмотрим задачу балансировки нагрузки в серверной ферме.
Типичный запрос состоит из названия ресурса (URL, имя файла, номер сообщения). При этом до того, как клиент пошлет имя ресурса web-серверу,
между ними может произойти обмен дополнительными сообщениями, опять же, корректными с точки зрения протокола (например, в целях авторизации пользователя). Всю совокупность сообщений (включая запрос и ответ) между установлением соединения между клиентом и web-сервером и его разрывом, будем называть сессией.
В случае асимметричной фермы, каждый реальный сервер web-фермы не обязан уметь отвечать на любой клиентский запрос. Но для каждого клиентского запроса в web-ферме должен присутствовать реальный сервер, который способен обработать данный запрос (например, все URL типа gif могут располагаться на одном реальном сервере, а URL типа html - на другом). Таким образом, сервис балансировки нагрузки должен быть способен на основании клиентского запроса выбрать реальный сервер, который способен обработать этот запрос и перенаправить запрос ему.
Для обмена сообщениями высокоуровневого протокола используется протокол менее высокого уровня. В случае сети Интернет таким протоколом является протокол TCP. Если данные посланы с помощью протокола TCP, то гарантируется их безошибочная доставка. Сообщения высокоуровневых протоколов, клиентские запросы и ответы web-севера в терминах протокола TCP трактуются как данные, которые нужно доставить.
Чтобы передать данные от одного компьютера другому, пользуясь протоколом TCP, требуется установить TCP-соединение между этими компьютерами. При посылке данных с помощью TCP они разбиваются на пакеты, и каждый пакет посылается отдельно. На другом конце соединения пакеты собираются в надлежащем порядке, и получатель получает ту же последовательность данных, что посылал отправитель. К каждому пакету данных приписывается дополнительный заголовок (который так и называется
- TCP-заголовок), в котором указывается информация, позволяющая собирать пакеты в нужном порядке. Так же в TCP-заголовок входит информация, позволяющая обнаруживать искажения данных - это так называемая контрольная сумма, взятая от TCP-заголовка и содержимого пакета. Если содержимое пакета искажается, то контрольная сумма, пересчитанная получателем, не совпадает с контрольной суммой, указанной в TCP-заголовке.
Также в TCP-заголовок входят специальные поля, которые называются «TCP-опциями». Набор TCP-опций определяется при установлении соединения. TCP-опции служат в основном для оптимизации скорости передачи данных, и их набор может зависеть от способа реализации TCP протокола.
TCP протокол сам пользуется услугами протокола более низкого уровня
- IP. Такой способ реализации, когда один протокол пользуется услугами другого протокола называется стеком. В частности, реализация набора
протоколов «TCP-IP-другие протоколы» (ICMP,ARP и т.д.) называется TCP-стеком. Полнее устройств TCP-стека описано в [3].
Обычно TCP-стек реализуется как часть ядра операционной системы. Сервисы, реализующие протоколы более высокого уровня (HTTP, FTP, POP3) обычно реализуются в пользовательском адресном пространстве. При этом сервисы, реализующие высокоуровневые протоколы используют функции TCP-стека посредством специальных системных вызовов. То есть установление соединения, чтение и посылка данных посредством TCP делаются через системные вызовы.
Рис. 2 Процесс балансировки запросов сервисом, расположенном в пользовательском адресном пространстве
При работе в пользовательском адресном пространстве сервис, реализующий один из протоколов, имеет доступ только к данным - все действия по разбиению данных на пакеты, подсчету контрольных сумм и формированию заголовков пакетов происходят внутри TCP-стека и из пользовательского адресного пространства к этой информации нет доступа.
Среди известных аналогов наиболее близок к предлагаемому методу метод, использованный при построении Linux Virtual Server (LVS).
Общими чертами для методики построения Linux Virtual Server и предлагаемого метода, являются:
сервис является частью ядра операционной системы;
• клиентский запрос рассматривается как последовательность пакетов.
Наиболее важное отличие состоит в том, что методика построения Linux Virtual Server не предусматривает внутреннего буфера для хранения пакетов запроса, до тех пор, пока не определится сервер, выполняющий обработку. В силу этого для серверов, построенных на основе Linux Virtual Server, становиться невозможным осуществлять распределение нагрузки на основе содержимого клиентского запроса. Это ведет к тому, что Linux Virtual Server не способен работать с асимметричной фермой.
Другой отличительной особенностью Linux Virtual Server является то, что для приема и посылки пакетов используются не функции tcp-стека системы, а более низкоуровневые функции для манипуляции пакетами.
Описание метода
Сущность предлагаемого метода состоит в том, что клиентский запрос и ответ на него формируются клиентом и web-сервером с помощью одного из широко известных высокоуровневых протоколов (например, HTTP, FTP, POP3). Это значит, что запрос и ответ представляют собой синтаксически корректную с точки зрения правил, установленных протоколом, последовательность байт.
На основании изложенного можно сделать вывод о том, что сервис балансировки нагрузки по предложенному методу должен быть реализован как часть ядра операционной системы (см. Рис. 3). Это дает выигрыш в производительности по следующим причинам:
• для выполнения действий по приему/отправке данных не нужно переключаться между пользовательским адресным пространством и адресным пространством ядра операционной системы. Операция переключения контекстов - достаточно дорогая операция, и, реализуя сервис полностью в пространстве ядра, нам удастся полностью избежать этой операции;
• сервис, реализованный в пользовательском адресном пространстве, не имеет доступа к данным, расположенным в адресном пространстве. Поэтому любая операция по посылке и получению данных влечет за собой дополнительное копирование этих данных из пользовательского адресного пространства в адресное пространство ядра (см. Рис. 2). Реализуя сервис как часть ядра операционной системы, нам удастся полностью избежать копирования данных между адресными пространствами. Это значительно снизит нагрузку на процессор и шину памяти системы;
• большая часть данных (например, ответ клиенту) проходит через сервис для балансировки нагрузки транзитом, то есть данные не обрабатываются сервисом, а только перекладываются из одного соединения в
другое. Имея доступ к заголовкам TCP-пакетов можно оптимизировать механизм перекладывания данных из соединения в соединение, путем использования информации о значении контрольной суммы пакета. Доступ к этой информации возможен только из адресного пространства ядра операционной системы.
Рис. 3 Процесс балансировки запросов сервисом, расположенном в
адресном пространстве ядра
Для получения и отправки данных используются функции TCP-стека системы, которые работают е данными на уровне пакетов. Это значит, что сервис для балансировки нагрузки не должен непосредственно обращаться к сетевому устройству для приема-посылки пакета, а использовать для этого функции ТСР-стека. Причем функции должны оперировать с потоком данных, как с последовательностью пакетов, а не как с непрерывным потоком. Это целесообразно делать по следующим причинам:
• информация, содержащаяся в пришедших ТСР-пакетах, позволяет оптимизировать их посылку в другое соединение. Если пользоваться функциями, работающие на уровне буферов данных, то информация о контрольных суммах и заголовках будет недоступна;
• получая данные как последовательность ТСР-пакетов, сервис может использовать эти пакеты при отправке данных в другое соединение. При этом мы избегаем создания дополнительного буфера для пакета и копирования его содержимого;
• ТСР-стек проделывает работу по правильному выставлению опций в заголовках ТСР-пакетов. Если отправлять пакеты непосредственно в сетевое устройство, опции будут выставлены не правильно и это снизит скорость передачи данных по соединению.
ТСР-пакеты, пришедшие от клиента должны сохраняться во внутренней очереди до тех пор, пока не будет принят клиентский запрос и использовать
эти пакеты для отправки запроса выбранному на его основе реальному серверу. Это позволяет:
• проанализировать запрос, даже если он был разбит на несколько пакетов;
• использовать эти пакеты при посылке запроса реальному серверу, что позволяет избежать дополнительного создания и копирования пакетов, а так же оптимизировать подсчет контрольной суммы.
Для выбора реального сервера, который будет обрабатывать клиентский запрос, должны использоваться предопределенные правила. Эти правила могут использовать следующую информацию:
• содержимое клиентского запроса. Используя эту информацию, можно выбирать реальный сервер в зависимости от типа запрашиваемого ресурса (см. Рис. 4). Это позволяет использовать асимметричную модель web-фермы;
• 1Р-адрес клиента, совершающего запрос. Используя эту информацию можно выделить привилегированную группу пользователей, которой предоставляется лучшее качество обслуживания, то есть запрос распределяется на более мощный и менее загруженный сервер;
• величина загрузки процессоров серверов фермы. Используя эту информацию, для обработки запроса сервис балансировки может выбрать наименее загруженный сервер, что приведет к скорейшему обслуживанию запроса (см. Рис. 5);
• количество занятой памяти на серверах фермы. Используя эту информацию, для обработки запроса сервис балансировки может выбрать наименее загруженный сервер, что приведет к скорейшему обслуживанию запроса.
v' ike scheme
□ fell
hiode
hinds
<yZ ~ ic п n mp д—i- ФЕТ UHIPDIII t hlml
■j-ET mlmne.html f.i= " st n j mpg
CII4 nt
Рис. 4 Процесс балансировки запросов на основе содержимого запроса
Для отправки пакетов должен использоваться алгоритм пересчета контрольной суммы TCP-пакета, который позволяет выразить контрольную сумму данных TCP-пакета через контрольную сумму TCP-заголовка пакета. В TCP-пакете, который получает сервис для балансировки нагрузки со стороны реального сервера или клиента контрольная сумма уже посчитана отправителем.
Proxy-1 ke scheme
I г. CGPline ГСР «Г|ПЧ*А ■> Г'
Client
Рис. 5 Процесс балансировки запросов на основе загрузки процессоров
серверов фермы
Идея алгоритма пересчета контрольной суммы состоит в том, чтобы использовать при подсчете контрольной суммы исходящего пакета
контрольную сумму входящего пакета. Это становиться возможным благодаря тому, что контрольная сумма в некотором смысле "линейно" зависит от буфера, для которого она считается. То есть если буфер разбить на две части, то контрольная сумма всего буфера линейно выразиться через контрольные суммы частей. В исходящем пакете меняется только заголовок, поэтому чтобы получить контрольную сумму исходящего пакета достаточно подсчитать только контрольную сумму заголовка. Если типичная длина ТСР-заголовка 60 байт, а длина области данных 1500 байт, то использование вычислительных ресурсов при применении алгоритма пересчета снижается в 25 раз.
Предложенный метод реализован при создании системы виртуализации ресурсов Virtuozzo. Практика эксплуатации этой системы показала высокую эффективность предложенного метода.
Литература
1. Клейнрок Л. Вычислительные системы с очередями: Пер. с англ. - М.: Мир, 1979. - 600 с.
2. Клейнрок Л. Теория массового обслуживания: Пер. с англ. М.: Машиностроение, 1979.
3. Олифер В., Олифер Н. Новые технологии и оборудование 1Р-сети. -СПб., 2000. - 512с.
4. Вишневский В.М. Теоретические основы проектирования компьютерных сетей. - М.: Техносфера, 2003. 512 С.
