CC BY
78
УДК 004.942
РАЗРАБОТКА БАЛАНСИРОВЩИКА НАГРУЗКИ В ГИБРИДНЫХ СЕТЯХ
А. Н. Привалов, А.К. Клепиков
Описывается модульный принцип работы балансировщика нагрузки в гибридных сетях. Разбирается пример работы балансировщика на сложной задаче обработки базы данных по ключу.
Ключевые слова: балансировка, гибридные сети, динамическая балансировка, обработка базы данных.
Решение задачи распределения нагрузки в гибридных вычислительных сетях вуза на данный момент времени носит актуальный характер [1]. Задача распределения нагрузки в гибридных сетях представляет собой задачу распределения вычислительных задач на уровне приложений. В процессе балансировки происходит выбор сервера, обеспечивающего оптимальное решение задачи распределения нагрузки. Оптимальный сервер
должен удовлетворять условиям:
%< T;
о, < C j;
m, < Mj;
h < Hj;
Es ® min,
где c, - количество операций, выполняемых центральным процессором (ЦП) в секунду; m, - объем оперативной памяти; h, - доступное место на жёстком диске; Esii - стоимость решения задачи при заданной стоимости нормо-часа использования сервера j и времени, требуемого для расчета задачи ,.
Распределение нагрузки по кластеру сервером с одним управляющим модулем в рамках одного вуза решается на данный момент с помощью простых алгоритмов балансировки (Round Robin, RR DNS, RR Weight) и при помощи таких продуктов, как nginx(http://nginx.org/ru/) для веб-серверов и vwmare ESX - для виртуальных серверов.
Балансировка нагрузки между серверами вуза и виртуальными облачными серверами на данный момент выполняется с помощью подстройки существующих локальных решений для целей глобального распределения на уровне приложений с применением указанных выше программных продуктов. Однако такое решение не является рациональным с точки зрения временных и экономических затрат.
Временные затраты при использовании существующих решений на
передачу увеличиваются благодаря работе балансировщика на достаточно высоком сетевом уровне. Главной проблемой использования подобного уровня балансировщиков определяется в самой модели использования облачных серверов (оплата по времени использования). Подобная модель вносит коррективы в работу балансировщиков и не может быть в полной мере реализована в текущих продуктах.
Исходя из анализа недостатков существующих разработок, предлагается разработка балансировщика нагрузки, учитывающего необходимые параметры различных сред (локальных, виртуальных, облачных) и позволяющего создавать карту распределения нагрузки в зависимости из внешней среды параметров работоспособности серверных станций. Важной особенностью алгоритма работы балансировщика должно являться распределение нагрузки в зависимости от экономической эффективности использования внешних ресурсов.
Экономическая эффективность в данном случае определяется произведением составляющих по быстродействию, скорости обработки поступившей вычислительной задачи, стоимости обработки задачи. Параметр стоимости нормо-часа вычислений для серверов вуза и для облачных серверов рассчитывается с применением "Розы Патерса" [4]. Каждая составляющая, необходимая для обеспечения работы вычислительного сервера, вносит вклад в его стоимость. Для серверов вуза таковыми являются стоимости:
- электроэнергии для поддержания работоспособности сервера;
- электроэнергии для поддержания работоспособности серверного помещения;
- серверного оборудования;
- амортизационных расходов;
- обслуживания сервера персоналом.
В качестве примера рассмотрим вуз, имеющий в распоряжении 16 вычислительных серверов, расположенных в одном кондиционируемом помещении и обслуживаемом одним системным администратором. Стоимость нормо-часа вычислений приблизительно в 2 раза меньше, чем значение нормо-часа для облачного сервера, в которые входит безлимитный доступ к серверу на протяжении всего этапа использования.
Для реализации балансировщика в гибридных сетях ввиду сложного состава сети требуется динамичный механизм работы балансировщика, описанный с помощью модели и алгоритмов работы балансировщика [1]. Одной из отличительных особенностей балансировщика в гибридных сетях является его самообучаемость. После ввода входных данных о составе сети и данных по экономической стоимости вычислений балансировщик должен самостоятельно создать карту распределения вычислительных задач на основании полученных данных.
Для реализации балансировщика за основу было взято Open-source
решение Balancer от компании Inlab. Balancer написан на языке Си, которая представляет собой низкоуровневое решение работающего на канальном уровне Layer 2 (Ethernet). Взятый за основу образец позволил определить основные этапы работы с данными на локальном уровне, определить проблемы при использовании статичных алгоритмов распределения данных. Приведем участок кода главного модуля Balancer Inlab: fprintf(stderr, "\n"); fprintf(stderr, "examples:\n");
fprintf(stderr, " balance smtp mailhost1:smtp mailhost2:25 mail-host3\n");
fprintf(stderr, " balance -i smtp\n");
fprintf(stderr, " balance -b 2001:DB8::1 80 10.1.1.1 10.1.1.2\n"); fprintf(stderr, " balance -b 2001:DB8::1 80\n"); fprintf(stderr, "\n");
exit(EX_USAGE) ;
}
// goto background:
void background(void) { int childpid;
if ((childpid = fork()) < 0) { fprintf(stderr, "cannot fork\n"); exit(EX_OSERR) ; } else {
if (childpid > 0) { exit(EX_OK); /* parent */
}
}
#ifdef BalanceBSD
setpgid(getpid(), 0); #else
setpgrp(); #endif if(chdir("/") <0) fprintf(stderr, "cannot chdir\n"); close(0); close(1); close(2);
}
При реализации собственного балансировщика в гибридных сетях из проекта Balancer были заимствованы функции по разбору пакетов дан-
101
ных, подмене заголовков, сборке и перенаправлению пакетов на необходимые сетевые узлы. Механизмы были существенно переработаны и заключены в оболочку проекта на языке С#, выполненного в среде Visual Studio 2010 под названием CloudBalancer. Общая схема работы балансировщика представлена на рис. 1.
Рис. 1. Схема работы CloudBalancer
Для реализации динамической смены алгоритмов балансировки был использован механизм отслеживания состояния работы серверов, для чего были разработаны модуль ServerTrakingModule для серверов вуза и модуль CloudTrakerModule - для облачных серверов.
ServerTrakingModule определяет загруженность серверной станции с помощью получения информации о среде, в которой запущено приложение:
System.Management.ManagementObjectSearcher man = new Sys-tem.Management.ManagementObjectSearcher(" SELECT LoadPercen-tage FROM Win32_Processor");
foreach (System.Management.ManagementObject obj in man.Get()) Библиотека System позволяет получить данные об общем размере оперативной памяти и памяти, заданной в данный момент времени. Класс Drivelnfo был выбран для жесткого диска:
Бпуе1п£Ь[] аПБпуев = БпуеШЬ.ОйБпуевО;
йгеасИ фпуе^ЫЪ ё т а11Бг1уев) {
ёг1уе=ё.Каше;
1уре=ё.Бг1уеТуре;
}
8егуегТгактМоёи1е в реализации на С# представляет собой приложение, работающее на сервере как процесс и реализующее класс 8егуегТгак^ с методами:
- getSysteшInfo() - получает общие сведения о процессоре и оперативной памяти;
- getDiscInfo ()- получает сведения о жестком диске;
- getCuгentPгocLoadI() - получает текущий процент загрузки процессора;
- getCuгentMemoгyUsed() - получает текущий процент использо вания оперативной памяти;
- sendSysteшData() - отправляет массив данных на заданный адрес;
- saveLog() - записывает данные в журнал программы;
- sendTask() - отправляет вычислительную заявку на главный модуль;
- seгia1izeData() - формирует пакет данных для отправки на главный модуль.
Общая логика действия модуля следующая. Когда главный модуль опрашивает SeгveгTгakinModu1e, вызываются методы getSysteшInfo, getDiscInfo - создается массив данных со сведениями о системе. Массив данных с помощью метода sendSysteшData передается вызывающему модулю и в главном модуле формируется представление об узле, расположенном на адресе. Представление записывается в логи с помощью метода saveLog:
localServer #3
IP:192.168.3.26
System Data
CPU: Intel core i7 2300
Memory: 16GB 1600 DDR III
HDD 3026 GB/2832 GB free space
localServer #4 IP:192.168.3.27 System Data CPU: Intel core i5 2100 Memory: 8GB 1600 DDR III HDD 2048 GB/1320 GB free space
localServer #5 IP:192.168.3.28 System Data
CPU: Intel core 2Duo 3200 Memory: 4GB 1600 DDR III HDD 499,42 GB/170 GB free space
На записи данных в лог заканчивается этап первичного получения данных при развертке системы балансировки в сети вуза, после чего все управление по распределению принимает на себя главный модуль -GatewayModule, расположенный на шлюзовом компьютере и управляющий потоком заявок.
Модуль GatewayModule реализует класс GatewayModule с набором методов, позволяющих производить разбор присланного пакета данных для получения данных заголовка, с помощью которых определяются принадлежность пакета к рабочей станции по IPv4 адресу, запись и ведение логов, отправка данных на адрес локального или виртуального облачного сервера, механизм распределения задач.
Рассмотрим пример работы балансировщика на примере веб-сервиса, который позволяет производить обработку базы данных по введенному ключу. Ключ представляет собой входящий файл в формате Microsoft Excel, в котором содержатся определяемые названия и определители, по которым можно однозначно распознать названия.
База данных состоит из таблицы наименований и каждое наименование может быть распознано как одно или несколько уникальных определяемых названий из ключевого файла. Распознание производится с помощью побитовых операций OR|AND.
В результате работы программы формируется выходной ключ в виде слепка результирующей таблицы, где в соответствии таблицы базы данных с наименованиями приводятся соответствия уникальных названий из ключевого файла. Данная задача отличается тем, что ее оптимизация может быть допустима лишь до определенного предела возможностей языка запросов SQL, после чего на скорость составления выходного ключа будет влиять только мощность сервера, на котором эта операция производится.
При условии, что элементы входной строки должны иметь совпадение с одним из элементов четырех логических блоков и не должны включать совпадение с элементами 5-го логического блока, запрос будет иметь вид, представленный на рис. 2.
При поступлении задачи обработки данных по ключу GatewayModule производит отнесение задачи к одному из заранее определенных классов задач. При самообучении балансировщика на вход подаются примерные типовые виды задач, которые будут исполняться в данной
среде, после чего производится тестовый прогон выполнения каждой задачи д! е Q на сервере 8 е 8. В память балансировщика записываются таблица времени обработки каждой из задач, а также количество занятых ресурсов ЦП, оперативной памяти, ЖД на момент обработки задачи.
Одна поступившая задача ц после поступления на GatewayModule получит закрепленные за ней индивидуальные характеристики в случае исполнения ее на каждом из серверов 8 е 8.
IF( CHAR_LENGTH(x1) >4, '$str' LIKE CONCAT('%\ x1, '%'), BINARY '$str' LIKE CONCAT('%', x1, '%')) OR
IF( CHAR_LENGTH(x2) >4, '$str' LIKE CONCAT('%', x2, '%')> BINARY '$str' LIKE CONCAT('%', x2, '%')) OR
IF( CHAR_LENGTH(x3) >4, '$str' LIKE CONCAT('%', x3, '%')> BINARY '$str' LIKE CONCAT('%', x3, '%')) OR
(x1 ='#' AND x2=T AND x3='#')
) (
IF( CHAR_LENGTH(y1) >4, '$str' LIKE CONCAT('%', y1, '%'), BINARY '$str' LIKE CONCAT('%', y1, '%')) OR
IF( CHAR_LENGTH(y2) >4, '$str' LIKE CONCAT('%', y2, '%')> BINARY '$str' LIKE CONCAT('%', y2, '%')) OR
IF( CHAR_LENGTH(y3) >4, '$str' LIKE CONCAT('%', y3, '%')> BINARY '$str' LIKE CONCAT('%', y3, '%')) OR
(y1 ='#' AND y2=T AND y3='#')
) (
IF( CHAR_LENGTH(z1) >4, '$str' LIKE CONCAT('%', z1, '%'), BINARY '$str' LIKE CONCAT('%', z1, '%')) OR
IF( CHAR_LENGTH(z2) >4, '$str' LIKE CONCAT('%', z2, '%')> BINARY '$str' LIKE CONCAT('%', z2, '%')) OR
IF( CHAR_LENGTH(z3) >4, '$str' LIKE CONCAT('%', z3, '%')> BINARY '$str' LIKE CONCAT('%', z3, '%')) OR
IF( CHAR_LENGTH(z4) >4, '$str' LIKE CONCAT('%', z4, '%')> BINARY '$str' LIKE CONCAT('%', z4, '%')) OR
IF( CHAR_LENGTH(z5) >4, '$str' LIKE CONCAT('%', z5, '%')> BINARY '$str' LIKE CONCAT('%', z5, '%')) OR
IF( CHAR_LENGTH(z6) >4, '$str' LIKE CONCAT('%', z6, '%')> BINARY '$str' LIKE CONCAT('%', z6, '%')) OR
(z1 ='#' AND z2=T AND z3='#' AND z4=W AND z5='#' AND z6='#')
) (
IF( CHAR_LENGTH(w1) >4, '$str' LIKE CONCAT('%', w1, '%'), BINARY '$str' LIKE CONCAT('%', w1, ■%')) OR
IF( CHAR_LENGTH(w2) >4, '$str' LIKE CONCAT('%', w2, '%'), BINARY '$str' LIKE CONCAT('%', w2, '%')) OR
IF( CHAR_LENGTH(w3) >4, '$str' LIKE CONCAT('%', w3, '%'), BINARY '$str' LIKE CONCAT('%', w3, ■%')) OR
(w1 ='#' AND w2='#' AND w3='#')
) (
IF( CHAR_LENGTH(not1) >4, '$str' NOT LIKE CONCAT('%', not1, '%'), BINARY '$str' NOT LIKE CONCAT('%', not1, '%')) AND
IF( CHAR_LENGTH(not2) >4, '$str' NOT LIKE CONCAT('%', not2, '%'), BINARY '$str' NOT LIKE CONCAT('%', not2, '%')) AND
Рис. 2. Фрагмент запроса на распознание ключа Предположим, в сети имеются 3 сервера. В таком случае характе-
После того, как задача обработки данных по ключу получит свой класс сложности и характеристики для каждого сервера, она будет отправлена на один из оптимальных серверов из множества подходящих.
После того, как задача расчета будет выполнена и сервер вернет
ристики задачи q будут записаны так:
^(1, ti, Ci, mx, hx, Ex)\ qi(2,12, C2, m2, h2, E 2); qi (3,13, C3, тз, h3, E3).
выходной дамп вновь созданной , он
105
передан назад в
GatewayModule, т.к. в заголовке отправителя пакета будет подставлен IP-адрес шлюзового компьютера. После этого задача будет найдена в таблице текущих исполняемых задач и передана АРМ отправителю. Произойдет запись значений об окончании цикла обработки в лог, после чего цикл обработки задачи будет считаться завершенным.
Динамическая балансировка нагрузки в гибридных сетях представляет собой сложную научно-техническую задачу, особенно сложными моментами решения которой являются: определение класса сложности поступившей задачи, построение схемы переадресации задач в гибридной сети, отслеживание доступной производительности вычислительных серверов, поступление потока вычислительных заявок.
Разработанное приложение CloudBalancer позволяет производить балансировку вычислительных задач в гибридной сети вуза, учитывая особенность строения виртуальной сети вуза и характеристики виртуальных облачных серверов. Отличительной особенностью балансировщика является адаптивный механизм, позволяющий динамическим образом производить балансировку в условиях меняющейся внешней сетевой среды, что позволяет проводить все запланированные вычисления в установленное время и с наименьшими экономическими затратами.
Список литературы
1. Клепиков А.К., Привалов А.Н. Автоматическая балансировка нагрузки в гибридных вычислительных сетях // Известия ТулГУ. Технические науки.2013. С. 188 - 193.
2. Клепиков А.К., Привалов А.Н. Модель распределения ресурсов при "облачных вычислениях" // Известия ТулГУ. Технические науки. 2012. С. 151 - 157.
3. Курилов Л.С., Финогеев А.Г. Фрактальный принцип описания процессов динамики нагрузки в гетерогенной распределенной сетевой среде // Информационные технологии в науке, образовании, телекоммуникации и бизнесе: тез. докл. 33 Междунар. конф. (Украина, Крым, Ялта - Гурзуф, 20 - 30 мая, 2006). Ялта, 2006. С. 40 - 42. (Приложение к журналу «Открытое образование»).
4. Роза Патерса - Википедия [Электронныий ресурс] // Wiki-media Foundation, Inc.: [сайт]. [2014]. URL: https://ru.wikipedia.org/wiki/Роза Петерса (дата обращения: 29.08.2014).
Привалов Александр Николаевич, д-р техн. наук, проф., проф. privalov. 61@,mail. rut, Россия, Тула, Тульский государственный педагогический университет им. Л.Н. Толстого,
Клепиков Алексей Константинович, асп., don-klepikov@yandex. ru Россия, Тула, Тульский государственный педагогический университет им. Л.Н. Толстого
106
DEVELOPMENT LOAD BALANCER IN CONVERGED NETWORKS A.N. Privalov, A.K. Klepikov
The paper describes a modular approach to the work load balancer in converged networks. Understands an example of the balancer on the challenge of processing a database by key.
Key words: balancing, converged networks, dynamic balancing, database processing.
Privalov Aleksandr Nicolaevich, doctor of technical science, professor, privalov. 61@,mail. ru, Russia, Tula, Tula State Pedagogical University,
Klepikov Aleksey Konstantinovich, postgraduate don-klepikov@yandex. ru, Russia, Tula, Tula State Pedagogical University
УДК 004.001
АЛГОРИТМ ФОРМИРОВАНИЯ ТЕПЛОВОГО ИЗОБРАЖЕНИЯ
Е.В. Филиппова
Представлен алгоритм формирования теплового изображения, учитывающий влияние различных факторов. Каждый блок алгоритма обладает своими собственными входными и выходными параметрами.
Ключевые слова: тепловое изображение, интенсивность излучения, теплообмен, спектральные характеристики излучения, конвективной теплоотдачи.
Для проведения моделирования физических процессов формирования теплового изображения математическая модель должна иметь реализацию, обладающую доступным интерфейсом. При проектировании оболочки модели необходимо учитывать множество влияющих факторов. Это выдвигает требование к доступности изменения значений факторов алгоритма расчета на разных уровнях анализа данных.
Выполнение этого условия возможно при реализации системы в интерактивной среде математических вычислений. Это позволяет прослеживать динамику изменений факторов на любом этапе моделирования.
Для проведения расчетов алгоритм разделяется на укрупненные блоки по признаку логической связи проводимых действий:
1. Спектральные характеристики излучения.
107
