Механизм динамической балансировки нагрузки - R

advertisement
ИНСТРУМЕНТЫ И ТЕХНОЛОГИИ
Механизм динамической
балансировки нагрузки
Сергей Кубрин
директор
Управления технологического развития
компании RStyle Softlab
В интенсивно развивающемся банковском
мире соотношение «время / качество» опреде
ляет многое. Отражается оно и на требованиях
к ИТтехнологиям. Ведь помимо адекватной
цены, удобства внедрения и сопровождения
аргументами в пользу той или иной АБС явля
ются те особенности, которые позволяют банку
не столько поддерживать уже существующий
бизнес, сколько закрепляться на новых пози
циях. Это касается специфики работы самых
разных приложений — и бэкофисных, и фронт
офисных. Взять хотя бы такие перспективные
сегодня направления, как ретейл и кредитова
ние. Конкуренция в данном секторе велика,
и любая мелочь, упущенная в организации
обслуживания, может обернуться для финансо
вого учреждения неприятными последствиями.
Опять не работает терминал, в который раз
не проводится транзакция, долго не проходит
платеж — эти и другие досадные недоразумения
подрывают доверие клиента и вынуждают его
обратить взгляд в сторону других банков.
Можно ли избежать подобных ситуаций?
Понятие динамической
балансировки
Отдавая предпочтение тому или иному финансовому
учреждению, потребители руководствуются определен
ным списком приоритетов. В нем учитывается наличие
необходимых банковских продуктов, услуг, а также осо
бенности их предоставления, в том числе режим
«24 часа 7 дней в неделю». Банки выстраивают собствен
ную бизнесконцепцию исходя из этих критериев
RSCLUB № 4 2007 г.
ОКТЯБРЬ—ДЕКАБРЬ
Марина Животова
специалист по связям с общественностью
Управления маркетинга
компании RStyle Softlab
и, в свою очередь, ищут разработчиков ПО, способных
реализовать ее на высоком уровне.
То, что работа любого современного банка основана
на применении локальной сети, ни для кого не секрет.
Но далеко не все способы ее организации обеспечивают
бесперебойное функционирование серверов приложе
ний. Остановимся подробнее на одном из главных —
динамической балансировке нагрузки. В сфере банков
ской автоматизации это далеко не новое понятие имеет
принципиальное значение: от него зависят такие пара
метры, как масштабируемость, производительность
и отказоустойчивость программных комплексов.
Представим себе типичную ситуацию: большое
количество пользователей пытается получить доступ
к одному из эксплуатируемых серверов приложений.
Что происходит дальше? Пока остальные, связанные
с ним серверы простаивают без дела, этот начинает
«захлебываться» от наплыва обращений, и в результате
происходит снижение его работоспособности.
Да, скорость обслуживания пользователей зависит,
конечно, от многих факторов (выход из строя компьютера,
проведение профилактического мероприятия и др.),
но опасность представляет собой даже незначительная прио
становка процесса. Ведь для банка это всегда означает потерю
денег, а в некоторых случаях и клиентской лояльности.
Предупредить перегрузку одного оборудования при
простое другого помогает специальная технология — так
называемая динамическая балансировка нагрузки. Она
призвана автоматически распределять поток запросов
от клиентов между объединенными серверами приложений.
И хотя алгоритмы, реализующие соответствующий механизм,
могут быть разными, конечная цель динамической баланси
ровки — повысить эффективность применяемых ИТрешений.
RStyle Softlab, как поставщику банковского ПО, дале
ко не безразличны результаты развития бизнеса своих
клиентов — и реальных, и потенциальных. Наша компа
ния уделяет большое внимание не только разработке
новых, но и техническому усовершенствованию
49
Механизм динамической
балансировки нагрузки
Нагрузка на объединенные между собой серверы
распределяется с учетом закрепленных за ними ролей.
Выделяется четыре таких роли:
1) автономный сервер. Это конфигурация любого
сервера приложений по умолчанию. Не участвует в про
цессе динамической балансировки, то есть пользовате
ли используют его так же, как и раньше;
2) рабочий сервер. Выполняет две функции:
• обслуживает пользователей;
• взаимодействует с мастерсервером, передавая ему
необходимую информацию;
3) мастерсервер. Это рабочий сервер, который
не только обслуживает пользователей, но и предоставля
ет им адреса других рабочих серверов, то есть коорди
нирует процесс балансировки;
4) выделенный мастерсервер — рабочий сервер,
«специализирующийся» только на координации процес
са балансировки.
локальную сеть. Компьютеры объединяются в группу
на основе одинакового номера UDPпорта, который
задается в конфигурации (параметр настройки UDPPORT).
В принципе в локальной сети ничто не мешает организо
вать сразу несколько групп. Это бывает удобно, например,
тогда, когда за каждой из них закрепляется свой круг задач
(за одной — интерактивная работа, за другой — выпуск
отчетности и т. д.) или когда они используют разные
ресурсы (скажем, разные версии RSBank).
Прежде чем запустить механизм динамической
балансировки, для каждого сервера следует определить
роль, характеризующую его участие в процессе. В одной
группе может быть только один мастерсервер, причем
неважно, выделенный он или нет.
Клиентам группа представляется единым сервером,
обрабатывающим поступающие от них запросы.
При необходимости сетевые администраторы могут
добавить в нее серверы или, наоборот, исключить.
И произведено это будет без прекращения обслужива
ния пользователей.
Даже если какойлибо рабочий сервер неожиданно
выйдет из строя, на работе клиентов это фатально
не отразится. Все, что от них потребуется, — повторно
запустить терминал и за считаные секунды автоматиче
ски подключиться к другому серверу.
Что касается параметров настройки, то обязательным
из них является лишь один — указание роли серверов,
остальные имеют значения по умолчанию (табл. 1).
Алгоритмы реализации
динамической балансировки
Взаимодействие рабочих серверов
с мастер$сервером
Предлагаемый механизм динамической баланси
ровки реализуется с помощью алгоритма «минимум
соединений с весовыми коэффициентами» (Weighted
LeastConnections). Другими словами, мастерсервер
предоставляет клиенту тот рабочий сервер, у которого
по сравнению с другими количество активных соедине
ний меньше, а мощность больше. Мощность обозначает
ся весовым коэффициентом, выставляемым администра
тором в параметрах настройки WEIGHT сервера прило
жений. В принципе распределение нагрузки между сер
верами при желании можно сделать и равномерным.
Взаимодействие терминалов с мастерсервером
и рабочими серверами основано только на протоколе
TCP\IP. Поэтому он должен быть сконфигурирован
и активирован на каждом из этих серверов. При соеди
нении терминала с любым рабочим сервером использу
ются одни и те же параметры term.ini, не относящиеся
к способу коммуникации (номер терминала, способ
аутентификации и др.).
Взаимодействие рабочих серверов с мастерсерве
ром построено на UDPдатаграммах. Датаграммы посы
лаются либо адресно, либо широковещательно с приме
нением UDPпорта, который указывается в настройках
сервера приложений. Какие же типы сообщений акту
альны для процесса балансировки?
• MB1 — широковещательное сообщение, которое
отправляется рабочим серверам в момент старта
мастерсервера. Информирует их об адресе мастера
и «заставляет» уведомлять его о своей загрузке. Перед
отправкой первого уведомления мастеру рабочие серве
ры выполняют случайную задержку от 0 до значе
ния параметра UTIMEOUT с целью предотвращения
его перегрузки.
• MB2 — широковещательное сообщение от мастера
рабочим серверам, предупреждающее о его остановке.
Получив эту информацию, рабочие серверы перестают
отправлять данные мастеру.
• М1 — отклик мастера рабочему серверу на его
сообщение WB1 (поиск мастера). Обрабатывается рабо
чим сервером аналогично MB1, но без выполнения
задержки.
• WB1 — широковещательное сообщение, отсылае
мое рабочим сервером в поисках мастерсервера.
уже имеющихся ИТпродуктов. Специально для банков,
использующих два и более сервера, мы доработали
функционал предлагаемых систем, встроив в него меха
низм динамической балансировки. Об особенностях его
реализации и пойдет речь дальше.
Механизм динамической
балансировки RStyle Softlab
Роли серверов приложений
Настройка серверов
для динамической балансировки
Серверы приложений, между которыми предполага
ется распределение нагрузки, должны входить в одну
50
RSCLUB № 4 2007 г.
ОКТЯБРЬ—ДЕКАБРЬ
Механизм динамической
балансировки нагрузки
Таблица 1. Параметры настройки динамической балансировки
1
Назначение
Название
Пояснение
Для серверов приложений
ROLE
Определяет роль сервера: «0» — автономный,
«1» — рабочий, «2» — мастер, «3» — выделенный мастер
UDPPORT
Номер порта, используемый для коммуникации
рабочих серверов со своим мастерсервером
WEIGHT
Вес сервера, учитываемый в процессе балансировки
1
MAXCON
Максимальное количество клиентов,
обслуживаемое данным сервером. Значением «0»
задается ограничение по количеству соединений
0
UTIMEOUT
Интервал в миллисекундах, через который:
· рабочий сервер посылает информацию о своей
загрузке мастерсерверу,
· мастерсервер проверяет актуальность
зарегистрированных у него рабочих серверов
MASTERHOST
Задает имя хоста либо его IPадрес,
на котором работает мастерсервер
—
MASTERPORT
Указывает номер IPпорта мастерсервера
79
SKIPHOST
Определяет серверы приложений, которые
не должны использоваться клиентом. Строка имеет
вид: hostname:port;hostname:port. Например:
SKIPHOST = atlant:78;hermes:5000
Допускается использование нескольких
параметров SKIPHOST
—
Для программтерминалов
Отправляется рабочим сервером через несколько секунд
после старта, если не было получено сообщение MB1.
• W1 — сообщение рабочего сервера мастеру
о своем адресе, поддерживаемых протоколах и загрузке.
Посылается после получения сообщения MB1 или М1
регулярно, через заданные в настройке UTIMEOUT
интервалы.
• W2 — сообщение мастеру от рабочего сервера
о его остановке. Получив такое сообщение, мастерсер
вер перестает выделять этот сервер клиентам.
Все рабочие серверы, входящие в одну группу, мастер
сервер регистрирует у себя в таблице. В эту же таблицу он
заносит данные о каждом сервере (адрес, информацию
о загрузке, а также моменте последнего обновления этих
данных), получаемые им в виде W1сообщения через ука
занный в параметре UTIMEOUT интервал времени. Акту
альность зарегистрированных рабочих серверов регуляр
но проверяется. Если новые сведения о какомлибо
из них не поступали в течение тройного интервала вре
мени, мастер автоматически удаляет его из списка акту
альных, чтобы не предоставлять пользователям.
Взаимодействие терминалов
с мастер$сервером
Чтобы терминал мог воспользоваться механизмом
динамической балансировки, в параметре MASTERHOST
файла term.ini нужно указать адрес мастерсервера. Если
мастерсервер задействует IPпорт, отличный от принятого
1 Все параметры хранятся в системном реестре: HKLM\Software\RStyle Software Lab\
Application Server\<Server Name> (Примеч. авт.)
RSCLUB № 4 2007 г.
ОКТЯБРЬ—ДЕКАБРЬ
Значение
по умолчанию
0
5002
10 000
по умолчанию, необходимо задать новый в параметре
MASTERPORT.
В процессе соединения терминала с мастерсерве
ром выполняются следующие действия:
1) терминал соединяется с мастерсервером по про
токолу TCP/IP, используя параметры MASTERHOST
и MASTERPORT;
2) запрашивает у мастерсервера информацию
о наименее загруженном рабочем сервере, передавая
значение параметра SKIPHOST;
3) мастерсервер проверяет:
• не достигло ли количество пользователей, подсо
единенных к тому или иному рабочему серверу, предела,
заданного в параметре MAXCON, и выбирает тот сервер,
у которого число обслуживаемых клиентов не превыси
ло указанный лимит;
• не входит ли рабочий сервер (его имя и номер порта)
в список SKIPHOST, и, если нет, то останавливается на нем.
Поиск выполняется до тех пор, пока не будет найден рабо
чий сервер, который соответствует обоим критериям.
4) терминал устанавливает соединение с предложен
ным ему рабочим сервером по стандартной схеме;
5) если к рабочему серверу подключиться не удалось,
терминал добавляет его в список из параметра SKIPHOST
и повторяет шаг № 2 (не более четырех раз);
6) отсоединяется от мастерсервера;
7) если соединение с мастерсервером или рабочим
сервером установить не получилось, терминал применяет
для подключения к нему параметры term.ini — так же, как
и при отсутствии механизма динамической балансировки.
51
Механизм динамической
балансировки нагрузки
* * *
Средства администрирования
Для администрирования ПО динамической баланси
ровки может использоваться консольная утилита ADM
и средства доступа по HTTP с помощью вебобозревателя.
В утилиту ADM добавлена команда (D)istribution.
Если сервер, с которым «работает» утилита, выполняет
функции мастера, то при выборе этой команды на экран
выводится информация обо всех рабочих серверах,
участвующих в распределении нагрузки, и количестве
присоединенных к ним клиентов. Например:
N Host
port
Count
———————————————————————
0 NTSERVER1
79
0
1 NTSERVER2
79
0
Воспользоваться вебобозревателем позволяет спе
циальная конфигурация сервера для работы по HTTP.
Для ее настройки нужно задать параметр HTTPPORT,
а для отображения в вебобозревателе информа
ции о рабочих серверах — перейти по URL: http://
<serverName>:<port>/distribution, где serverName — имя
хоста, на котором работает мастерсервер, port — номер
порта, заданный в параметре настройки HTTPPORT2.
2 Утилита rsadmin в настоящее время не отображает информацию о рабочих серверах
на мастерсервере. (Примеч. авт.)
Механизм динамической балансировки незаменим для
банка, ИТинфраструктура которого поддерживается двумя
и более серверами приложений. Он дает ряд преимуществ,
значительно усиливающих конкурентоспособность финансо
вого учреждения. С технической точки зрения это максималь
но эффективное использование ИТресурсов. Оптимально
распределяя пользователей между серверами, механизм
балансировки обеспечивает их бесперебойное функциониро
вание и, следовательно, отказоустойчивость. Помогая обрабо
тать огромный объем данных за единицу времени, повышает
производительность систем. Предоставляя широкие возмож
ности по подключению дополнительных серверов к сети,
улучшает масштабируемость всей ИТинфраструктуры. А алго
ритмы, заложенные в основу механизма, облегчают задачи
по управлению потоками информации.
С точки зрения пользователя, рациональное распределение
серверных ресурсов делает его работу более комфортной. Это
выражается в оперативном и качественном выполнении любой
операции. В частности, без ущерба для обслуживания клиентов
заметно сокращаются сроки подготовки разных видов отчетно
сти. Если же говорить о выгодах банка в целом, то налицо эко
номия средств. Аппаратное ПО, например, застраховано
от нежелательного простоя и, значит, быстрее окупается.
А работа в режиме «24 × 7 × 365» является мощным средством
не только сохранения, но и привлечения клиентов.
Успешный бизнес должен быть технологичным.
Создание бизнестехнологий —
наша работа
С момента основания компания RStyle Softlab уделяет особое внимание реализации
в своих продуктах передовых наработок. Гибкие и функциональные, наши системы
прекрасно адаптируются под специфику бизнеса любого банка. Выбирая RSрешение,
вы можете быть уверены: с нами будет удобно!
Узнайте больше о возможностях наших продуктов на www.softlab.ru
RStyle Softlab. Лицом к людям
Андрей Галковский,
заместитель генерального директора,
директор по развитию
52
RSCLUB № 4 2007 г.
ОКТЯБРЬ—ДЕКАБРЬ
Download