CC BY
23
УДК 681.3
А.В. Бабич, асп., 8-920-273-25-34, babich@tula.ru (Россия, Тула, ТулГУ), Г.Б. Берсенев, канд. техн. наук, доц., (4872) 33-24-45, bersgen@gmail.com (Россия, Тула, ТулГУ)
БАЛАНСИРОВКА НАГРУЗКИ С СОХРАНЕНИЕМ РЕШЕНИЙ ДЛЯ РАСПРЕДЕЛЕННОЙ ГОСТЕВОЙ СИСТЕМЫ МОНИТОРИНГА
Рассматриваются вопросы балансировки нагрузки с сохранением решений для распределенной гостевой системы мониторинга. Предложена методика построения нагрузочных профилей серверов. Получены приближения для оценки и выбора наилучшего решения.
Ключевые слова: мониторинг сети, SNMP, распределенная гостевая система, балансировка нагрузки, аналитические приближения, выбор решения.
Система мониторинга является неотъемлемой частью корпоративной сети, обеспечивающей ее высокую готовность, бесперебойность и эффективность работы. Постоянное увеличение размеров и усложнение структуры корпоративных сетей приводит к значительному росту нагрузки на ресурсы сети со стороны процессов мониторинга. Поэтому в последние годы все чаще создаются распределенные, располагающиеся на нескольких выделенных серверах системы мониторинга. Основные работы по улучшению производительности распределенных систем мониторинга направлены на создание систем с динамической балансировкой нагрузки [1,2].
В настоящее время актуальной становится задача создания распределенных «гостевых» систем мониторинга, агенты которых используют свободные ресурсы серверов корпоративной сети, что позволяет значительно сократить расходы на мониторинг. «Гостевые» системы мониторинга по использованию должны быть схожи с системами распределенных вычислений типа BOINC (Berkeley Open Infrastructure for Network Computing) [3]. При этом предполагается, что агенты системы мониторинга могут загружать серверы корпоративной сети только до определенного уровня.
Таким образом, в данной работе рассматривается распределенная динамически конфигурируемая система активного мониторинга, которая будет размещаться на существующих серверах корпоративной сети и использовать их свободные ресурсы. Объекты мониторинга, представленные в виде набора источников данных, будут сохранять свои данные на серверах-агентах посредством системы RRDtool, причем для каждого источника данных будет создан отдельный RRD (Round Robin Database) файл.
В [4] приведен алгоритм динамической балансировки нагрузки для данной системы. Алгоритм основан на объединении агентов в логическую
иерархию. Балансировка состоит из трех этапов: локальные балансировки, двухуровневые балансировки и глобальная балансировка.
В данной работе предлагается улучшить производительность работы системы мониторинга за счет сохранения и последующего использования решений задачи динамической балансировки нагрузки. Такой подход позволит не выполнять алгоритм [4] задачи динамической балансировки перед каждым опросом.
На рис. 1 приведена статистика средней загрузки процессора (в процентах) биллингового сервера Тульского государственного университета. Видно, что в промежуток времени 04:00 - 08:00 загрузка мала и меняется в пределах одного процента. В период времени 8:00 - 9:00 наблюдается резкий рост нагрузки и в последующий период ее стабилизация. Обслуживаемые данным сервером подразделения начинают свою работу в 8:00 и 8:30.
Load
ю
5-1-►
04:00 06:00 08:00 10:00 12:00
■ load
Рис. 1. Использование процессора серверами-агентами
Аналогичная статистика была собрана для других серверов корпоративной сети. Поскольку опрос источников данных производится довольно часто (с периодом 3 - 5 минут), то проведенный анализ статистических данных позволяет утверждать следующее: состояние корпоративной сети с точки зрения загрузки серверов обычно изменяется незначительно на периоде опроса (увеличенный участок на рис. 1), а существенные изменения носят циклический характер и связаны с суточной активностью пользователей или запуском периодических заданий. Поэтому предлагается сохранять и использовать готовые (предыдущие) решения по распределению источников данных для опроса.
С каждым решением задачи балансировки нагрузки, полученным посредством алгоритма [4], необходимо хранить количество ресурсов сер-
веров, которое необходимо для обеспечения опроса без перегрузки серверов. На рис. 2 приведен пример использования ресурсов процессора серверами Sl - S6 сети для одного из таких решений.
Рис. 2. Использование процессора серверами-агентами
В этом примере 0,7 - максимально разрешенная загрузка, которую может создать на сервере система мониторинга. В общем случае данное значение может быть разным для различных серверов. Оно определяется видом работ, которые выполняет сервер. Белым цветом на рис. 2 обозначена текущая загрузка серверов основными заданиями, серым - значения загрузки процессами системы мониторинга, заштрихованные области - запас по загрузке, который может использовать система мониторинга. Обозначенные серым цветом и подписанные на рис. 2 значения, по сути представляют решение задачи балансировки нагрузки. Из этого примера видно, что данное решение может быть использовано даже при изменении основной нагрузки на серверы: если загрузка серверов si, s2, s5 вырастет не больше, чем на 0,1; серверов s3, s6 - не более, чем на 0,2, а сервера s4 не увеличится.
Введем следующие обозначения: S = [s^} - множество серверов сети; SA - множество серверов сети, на которых размещены агенты системы мониторинга, SA с S, Nsa = |SA|; D = [d^} - множество источников данных, N d = Dl.
Множество имеющихся ресурсов серверов опроса обозначим через R = {Rb r2,-j RNsa Ь где Rm = (Rmb Rm 2, Rm3, Rm 4 ) - ресурсы сервера sm четырех типов (процессор, память, сеть, диск). Соответствующие ресурсы серверов сети, требуемые для опроса источника данных, обозначим через Z = (Zi, Z2, Z3, Z4). Отметим, что в алгоритмах балансировки нагрузки количество ресурсов измеряется в безразмерных и нормализованных единицах [5].
Предположим, что Q = {qn} - множество решений задачи назначения агентам источников данных для опроса, причем q1 - решение задачи
назначения агентам источников данных для хранения. Каждое решение qn, п = 1, NQ , где NQ = , характеризуется объемами потребляемых ресурсов на серверах-агентах:
X = {Хп,п = }, Хп = {Хп1, Хп2, Хп3,., XnNSA}, Хпт = (Хпт1, Хпт 2, Хпт3, Хпт 4). Пусть БС = {БСп }, ВСп = {ВСт }, п = 1, NQ , т = 1, NSA , т.е. каждому элементу Хп, определяющему множества потребляемых ресурсов
серверами-агентами системы мониторинга, соответствует элемент БСп, определяющий множества распределенных по агентам для опроса источников данных.
Элемент БСп по сути является решением задачи назначения агентам источников данных для опроса (qn = БСп), т.к. содержит в себе множества ВСт для каждого сервера, а элементы множества X вычисляются следующим образом:
X
^ nmi
DCn
■ Zi.
Основная трудность при использовании балансировки на основе сохраненных решений состоит в сложности модернизации алгоритма динамической балансировки нагрузки [4], так как разработанные алгоритмы локальных и двухуровневых балансировок являются полностью распределенными и не хранят решения целиком на каком-либо хосте. Поэтому необходимо, чтобы один из агентов был назначен главным. На нем будут храниться решения задачи динамической балансировки, он будет принимать решения о выборе вида балансировки. В связи с тем, что на главном агенте должны аккумулироваться решения, при выполнении алгоритма балансировки (как при локальных балансировках, так и при балансировке поддеревьев) агенты должны передавать данные о назначенных для опроса источниках данных и наличии ресурсов главному агенту.
Рассмотрим дополнительные данные, которые будут храниться системой при данной модернизации алгоритма балансировки [4]. Множество
DCn содержит идентификаторы источников данных, общее число которых равно Nd . Учитывая, что в языке программирования Perl, который выбран авторами для реализации системы, все числа хранятся в формате с плавающей запятой (double), необходимо NqNd таких ячеек памяти для хранения множества DCnи 4NqNsa ячеек памяти типа double для хранения множества X . В общей сложности для хранения решений и соответст-
Известия ТулГУ. Технические науки. 2012. Вып. 4 вующих им значений потребляемых ресурсов требуется Nq (4Nsa + Nd )
ячеек памяти. Интерпретатор Perl самостоятельно выделяет память под массивы. При помощи модулей CPAN Devel::Size [6] и Devel::Size::Report [7] экспериментально было выяснено, что для хранения одного числа требуется 28 байт оперативной памяти, а накладные расходы для массивов, содержащих более 200 ячеек, составляют 12-17%.
Предположим, что основными сетевыми устройствами, которые будет опрашивать система мониторинга, будут 24-портовые управляемые коммутаторы. С каждого порта устройства будет считываться следующая информация: количество входящих и исходящих байт, количество входящих и исходящих пакетов (unicast, broadcast, multicast), количество коллизий, количество ошибок контрольных сумм. Таким образом, получается по 10 источников данных от одного порта устройства или 240 источников данных от одного устройства. Предположим, что опрашиваемая сеть имеет 100 серверов, на которых можно разместить агенты, и более 4000 устройств (примерно 106 источников данных). Тогда для хранения одного решения потребуется следующий объем памяти:
1,17 ■ 28 ■ Nq (4Nsa + Nd ) = 1,17 ■ 28 ■ 1 ■ (4 ■ 100 +106) = 32,8 ■ 106 или 33 МБ.
Видно, что для сохранения множества решений задачи балансировки нагрузки будут расходоваться большие объемы оперативной памяти. Поэтому предлагается полностью хранить только решение q1 и считать его оптимальным с той точки зрения, что агенты опрашивают только назначенные им для хранения источники данных, минимизируя тем самым пересылки данных в сети. Остальные решения qn, n = 2, Nq будут хранить
изменения относительно решения q1 . При этом для каждого решения qn, n = 2, Nq в множествах DCm будут храниться только идентификаторы
источников данных, которые в данном решении (в отличие от статического распределения q1 ) перемещаются с данного сервера или наоборот, добавляются к нему для опроса. Причем в первом случае идентификаторы предлагается хранить со знаком «-», во втором - со знаком «+». То есть для Аждого перемещаемого источника данных размер решения в памяти будет занимать две дополнительные ячейки памяти. Полностью решение будет занимать Nq (4Nsa + 2rNd ) ячеек памяти, где r - доля перемещаемых источников данных. Если предположить, что будет перемещаться 10% всех источников данных, для хранения решения потребуется
1,17 ■ 28 ■ Nq (4 Nsa + 2rND) = 1,17 ■ 28 ■ 1 ■ (4 ■ 100 + 2 ■ 0,1 ■ 106) = 6,57 ■ 106 или 6,5 МБ.
При использовании сохраненных решений возникает задача выбора наилучшего решения. Эта задача в общем случае является многокритериальной. Критерии выбираются исходя из требований системы мониторинга и сети [8].
1. Требование системы мониторинга - минимизировать общий интервал опроса - можно формализовать в виде критерия
gl(Q) = тш тах х;(д),
де( е$Л
где т; (д) - интервал опроса источников данных агентом, находящимся на ;-м сервере.
2. Требование сети - минимизировать ухудшение временных характеристик работы сети из-за появления дополнительной нагрузки ( А цесссов мониторинга) на серверах сети. При этом надо учитывать различную степень масштабируемости серверов, определяемую многока-нальностью их аппаратных и программных ресурсов, а также уровни текущей загрузки серверов. Выполнение требования сети можно обеспечить, если ввести в рассмотрение понятия дифференциальной и интегральной стоимости ресурсов серверов [8], а в качестве критерия использовать следующий критерий минимизации стоимости использования серверов сети процессами мониторинга:
ь
g2(() = X IР; (РЖ
де(8; еSAai
где а; - значение загрузки процессора сервера до получения заданий мониторинга, Ь; - значение загрузки сервера при выполнении процессов мониторинга, Р^ (р) - дифференциальная функция стоимости использования ресурсов сервера , в качестве которой предложено использовать зависимость от загрузки процессора сервера р средней длительности пребывания заявок клиентов корпоративной сети на сервере. Наиболее просто эту зависимость можно получить экспериментально, если в качестве заявок рассматривать запросы агентов на опрос.
Необходимо отметить наличие определенной согласованности между целевыми функциями gl(Q) и g 2((), что позволяет использовать од-нокритериальную модель с целевой функцией g2(() для приближенного решения многокритериальной задачи.
Рассмотрим вопросы определения целевой функции g 2((). Для начала отметим, что для каждого сервера-агента необходимо получить зависимость Р^ (р), которую в дальнейшем будем называть нагрузочным профилем сервера. Такую зависимость можно смоделировать только в рамках разомкнутых моделей массового обслуживания, в которых поток заявок на опрос не зависит от того, сколько заявок уже обслуживается сервером. Для
реализации такого потока заявок проще всего использовать запуск заданий на опрос с определенным периодом. Такой опрос упрощает решение проблемы, связанной с возможностью перегрузки сервера. Другими словами, процессы опроса должны быть управляемыми и не должны перегружать серверы, на которых функционируют агенты.
Для построения зависимости длительности опроса от нагрузки на процессор сервера-агента необходимо программами опроса создавать дискретные уровни загрузки и измерять отклики системы. Допустим, что обработка одного источника данных будет занимать Т^ процессорного времени. Для регулирования загрузки процессора предлагается запускать опрос источников данных с определенным периодом Ts. Пусть
Рт = Ть / Ts - дополнительная загрузка, которую создают потоки опроса на сервере si. Пример применения потоков с заданным периодом опроса для управления загрузкой процессора приведен на рис. 3. На обеих диаграммах (рис. 3,а,б) планируемая загрузка процессора составляет 0,5. В первом случае (рис. 3,а) работает один поток. Однако фактическая длительность опроса одного источника данных может занимать значительно больше времени, чем Ть или 2Ть. Поэтому для создания такой же нагрузки предлагается запускать для опроса несколько потоков (рис. 3,б), но с большим периодом опроса.
Рис. 3. Использование потоков опроса для регулирования загрузки
Исследования показали, что значения расчетной и получаемой на практике загрузки практически полностью совпадают (погрешность не более 6 %). Следовательно, при опросе можно довольно точно прогнозировать нагрузку на процессор, которую создаст система мониторинга.
Нагрузочный профиль сервера предлагается строить во время опроса, измеряя время ответа при разных уровнях загрузки процессора. Постепенное увеличение доли загрузки, которую создают потоки системы мониторинга, обеспечивается увеличением величины загрузки процессора Рт = Ты / Ts, создаваемой г-м потоком опроса. Под доступным для системы мониторинга диапазоном загрузки будем понимать разницу между текущей загрузкой процессора сервера (загрузкой заданиями корпоративной
сети) и максимально разрешенной загрузкой. Предлагается доступный для системы мониторинга диапазон загрузки делить на несколько частей (в проводимых экспериментах использовались 4 граничные точки) и для Аждой части (точки) интервала вычислять среднее время ответа. Например, если разрешенная загрузка Ь = 0,7, а текущая основная загрузка сервера al = 0,1, то доступный диапазон для дополнительной загрузки равен 0,6. Выделим точки 0,15; 0,3; 0,45; 0,6 на данном интервале. В общей загрузке процессора сервера это будут точки 0,25; 0,4; 0,55; 0,7 (квадраты на рис. 4). Для этих точек измеряется среднее время ответа (среднее время опроса).
Рис. 4. Точки для построения нагрузочных профилей серверов
Полученные результаты измерений будем использовать для определения аналитических выражений для нагрузочных профилей серверов. Пусть F (X) - зависимость среднего времени пребывания в открытой сети массового обслуживания (СеМО) от интенсивности входного потока заявок, а Xт - пропускная способность СеМО. В [9] предлагается использовать следующее приближение для F (X):
* 1 - БХ 0
F (X) = АХ-+ Т0,
1 - СХ
где 0 < X < Xт , С = 1/ Xт. Если промасштабировать эту зависимость, заменив X на х = X / X т , получим приближение
*
* .ч ,* 1 — Б х п
Т (х) = А х-+ Т,
1-х
которое можно использовать в качестве аналитического приближения нагрузочного профиля сервера Т (р).
Предлагается строить нагрузочные профили по двум крайним точкам диапазона доступной загрузки - первой (Х1, Т(Х1)) и последней
(х2, Т(х2)). Поскольку Т0 определяет Т(р) при р ^ 0, а диапазон
0 < х < XI не используется системой мониторинга, выберем значение Т исходя из предположения, что точка х^ находится на начальном, практически горизонтальном участке функции Т (р). Поэтому примем, что
Т = Т (х!)(1 - е), где е = 0,01. Тогда получим:
в * = XI (Т (Х2) - Т 0)(1 - х2) - х2 (Т (XI) - Т 0)(1 - XI) , х2 (Т (х 2) - Т 0)(1 - Х2) - х2 (Т (XI) - Т 0)(1 - XI)'
А* = (Т(х2) - Т0)(1 - х2) . х2(1 - В х2)
На рис. 4 сплошной и штриховой линиями показаны профили для
*
двух разных серверов, построенные с использованием приближения Т (х). Точки, по которым производилось построение профилей, показаны на рис. 7 кругами и квадратами. Нагрузочный профиль второго, более мощного сервера, строился при уровне текущей нагрузки а 2 = 0,5.
Эксперименты показывают, что нагрузочные профили для одного сервера, построенные при разных значениях основной загрузки сервера и различных диапазонов разрешенной загрузки, практически совпадают. Однако его уточнение необходимо производить при каждом опросе на случай возможного изменения характеристик сервера. Если на реальных серверах изменение аппаратной части происходит не часто, то изменение характеристик виртуальных серверов вполне возможно.
* * 0 * Если А* , В* , Т - коэффициенты приближения Т* (р) для нагрузочного профиля сервера ^, то выражение целевой функции g 2^) будет следующим:
ь
*
g2(й) = Ш1п X 1Т ЫФ =
е£Аа*
Ш1П X
qeQsi еЯА
А*
2
* р * В* — + (В*
1)(1п(р -1) + р)
\
+ рТ 0 + рТ* ь*
У а*
Ш1П X
ЯeQsi eSA
А*
В*
7 2 2
Ь* - а1
2
+ (В* - 1)(1п(Ь -1) - 1п(а* -1) + Ь* - а*)
+(ь*- а )Т1
В настоящее время проводятся теоретические и экспериментальные исследования различных вариантов организации процессов и/или потоков опроса и определения наилучшего из них.
Список литературы
1. Matthew L. Massie, Brent N. Chun, David E. Culler. The ganglia distributed monitoring system: design, implementation, and experience // Parallel Computing. №30. 2004. P. 817 - 840.
2. Distributed Nagios eXecutor. Intellectual Reserve, Inc, 2010. [Электронный ресурс] URL: http://dnx.sourceforge.net/ (дата обращения 19.09.2011).
3. David P. Anderson. BOINC: A System for Public-Resource Computing and Storage. Space Sciences Laboratory, University of California at Berkeley, 2004.
4. Бабич А.В., Берсенев Г.Б. Алгоритмы динамической балансировки нагрузки в распределенной системе активного мониторинга. // Известия ТулГУ. Технические науки. 2011. Вып. 5. Ч.3. С. 251-261.
5. Бабич А.В., Берсенев Г.Б. Представление ресурсов в алгоритмах балансировки распределенной системы мониторинга // Интеллектуальные и информационные системы: материалы всероссийской научно-технической конференции. Тула: Изд-во ТулГУ, 2011. С. 6-8.
6. Devel::Size - search.cpan.org. [Электронный ресурс] URL: http://search.cpan.org/~nwclark/Devel-Size-0.77/lib/Devel/Size.pm (дата обращения 27.09.2011).
7. Devel::Size::Report - search.cpan.org. [Электронный ресурс] URL: http://search.cpan.org/~tels/Devel-Size-Report-0.13/lib/Devel/Size/Report.pm (дата обращения 27.09.2011).
8. Берсенев Г.Б., Бабич А.В. Многокритериальный подход к управлению нагрузкой в распределенной системе мониторинга // Вычислительная техника и информационные технологии: сборник научных статей. Тула: ТулГУ. 2010. Вып. 2. С. 3-10.
9. Берсенев Г.Б., Малинин Д.И. Использование приближений для открытых сетей массового обслуживания с многоканальными узлами // XLV Всероссийская конференция по проблемам математики, информатики, физики и химии: тезисы докладов. Секции математики и информатики. М.: РУДН, 2009. С. 194 - 195.
A.V. Babich, G.B. Bersenev
LOAD BALANCING WITH SOLUTIONS SAVING FOR DISTRIBUTED GUEST MONITORING SYSTEM
Questions of load balancing with solutions saving for distributed guest network monitoring system are considered. Load profiles building method is proposed. Approximations for estimation and choice of the best solution are obtained.
Key words: network monitoring, SNMP, distributed guest system, load balancing, analytic approximations, solution choice.
Получено 18.04.12
