Сейчас нелегко найти организацию — будь то цветочный магазин или крупный банк, — который не предоставляет тот или иной ИТ-сервис своему конечному потребителю.
Не могу говорить за "цветочный магазин", но бизнес легко считает, сколько стоит простой сервиса продолжительностью в одну минуту в денежном эквиваленте.
Обеспечение высокой доступности ИТ-сервисов - это сложный и дорогой процесс, в котором задействованы все звенья цепи, объединенные под названием "ИТ-инфраструктура".
Но есть продукты, без которых сложно себе представить создание хоть сколько-нибудь рабочей схемы отказоустойчивых приложений. Речь идет о балансировщиках нагрузки, или их дальнейшем развитии — Контроллерах Доставки Приложений (Application Delivery Controller - ADC).
Исторически компания Увеон (входит в "Группу Астра") занималась решениями по созданию виртуальных рабочих мест на основе технологии VDI (Termidesk VDI) и терминального доступа (Termidesk Terminal). Это сложные инфраструктурные продукты, для которых отказоустойчивость компонентов критически важна.
Ранее в качестве ADC в архитектуре Termidesk использовались либо имеющиеся у заказчиков продукты зарубежных производителей, либо же различные opensource продукты, которые выбирал администратор, исходя из своей квалификации или желания. Подход, при котором перекладывается столь важная роль на неконтролируемые решения, неудобен нам как производителю и, что более важно, администраторам, занимающимся сопровождением и внедрением продуктов компании Увеон.
Кроме того, сам класс решений ADC универсален и не должен быть привязан к какому-то одному решению. В силу того, что все зарубежные производители покинули наш рынок, а opensource ограничен по функциональности и возможности быть полноценно интегрированным в ИТ-инфраструктуру заказчиков, мы решили начать разработку собственного балансировщика/Контроллера Доставки Приложений.
Termidesk Connect
Перед стартом работ по созданию будущего продукта мы, в первую очередь, определили основные характеристики:
Возможность реализации различных форм факторов (виртуальная машина, контейнер, ПАК)
Высокая производительность (Основные метрики: Пропускная способность, TCP сессии в секунду, Конкурентные TCP сессии, HTTP запрос(сы))
Гибкость настройки
Удобство конфигурирования
Собственная отказоустойчивость
Можно было заняться очередным DevOps проектом, взять и объединить несколько OpenSource продуктов и получить "Франкенштейна". Подобных решений великое множество на нашем рынке, и все они сильно ограничены тем функционалом и логикой настройки, которая была в "родительских" продуктах. Про производительность и вовсе говорить не стоит.
Поэтому мы начали разработку с нуля, не опираясь на существующие проекты (но, конечно, мы подглядываем за удачными примерами на рынке).
Так появился Termidesk Connect.
Termidesk Connect представляет собой многофункциональное сетевое устройство, которое обеспечивает масштабирование и высокую доступность приложений, оптимизацию их работы за счет гибких настроек коммуникационных протоколов, а также георезервирование инфраструктуры.
В Termidesk Connect реализованы такие возможности и характеристики как:
Высокая производительность
Балансировка трафика приложений
Reverse Proxy
Возможность выбора группы серверов, в зависимости от содержимого запроса и его источника
Изменение содержимого входящих/исходящих запросов
GSLB: Балансировка приложений работающих на нескольких площадка/ЦОД
SSL Offload – снижение нагрузки с серверов приложений и ИТ-сервисов за счёт переноса операций шифрования/дешифрования с сервера приложений на устройство, оркестрация параметров шифрования.
Интеллектуальные алгоритмы распределения нагрузки между разными компонентами приложений
Удобное управление через графический интерфейс, командную строку, API и Netconf
Гибкость конфигурирования
Логически устройство делится на несколько компонентов, которые объединяются между собой через общую шину - Termidesk Connect Bus. Каждый из компонентов выполняет определенную функцию и имеет возможность разрабатываться отдельной командой.
WEB-UI – Web конфигуратор
Configuration Manager (CM) – сервис настройки и конфигурирования остальных сервисов в шине
Global Server Load Balancing (GSLB) – сервис балансировки на основе DNS запросов
Performance Acceleration staCk(PAC) – Быстрая L4 балансировка
Local Servers Balancer (LSB) – сервис балансировщик локальных серверов.
Health Check (HC) – сервис проверки работоспособности реальных серверов
Если говорить про функционал балансировки нагрузки, то он реализуется двумя компонентами - LSB и PAC.
Несмотря на обилие компонентов, администратору нет необходимости вникать в особенности их взаимодействия. С точки зрения логики настройки, можно представить следующую диаграмму:
Для локальной балансировки
Проверка - то как будут проверяться балансируемые (Реальные) серверы. При создании она никого не проверяет.
Группа Реальных Серверов - список балансируемых серверов, для определения их работоспособности используется ранее созданная проверка, которая указывается при создании группы.
Сервер Балансировки - Абстракция, в которой определяется, по какому алгоритму будут балансироваться сервера, какой тип persistence использовать, а так же при необходимости SSL-профиль, который опишет параметры SSL/TLS при взаимодействии с Реальным Сервером.
Фонд IP - опциональный параметр, в котором можно указать IP-адреса которые должен использовать Termidesk Connect при взаимодействии с Реальным Сервером.
Виртуальный Сервер - точка подключения клиентов к приложению. В нем заданы IP и порт, правила выбора Серверов Балансировки, профиль SSL/TLS и др.
Все эти абстракции можно комбинировать между собой в любом сочетании. Например для всех Групп Реальных Серверов может быть использована одна и та же проверка (а может быть и разные.). Один Сервер Балансировки может быть задействован в конфигурации разных Виртуальных Серверов и так далее.
Процесс подключения можно описать следующим образом:
Клиент хочет получить ресурс, например Web-страницу. Он обращается на IP адрес и порт Виртуального Сервера (VIP)
На Виртуальном Сервере настроены Политики (как минимум одна), в которых описано, какой Сервер Балансировки выбрать для этого запроса.
Сервер Балансировки знает, какой пул Реальных Серверов можно использовать. Знает состояние серверов в пуле (можно ли направить запрос на тот или иной сервер)
Согласно алгоритму балансировки и другим параметрам выбирает Реальный Сервер и направляет на него запрос
Типы балансировки
Поговорим про компоненты и типы балансировки которые реализованы на данный момент:
LSB реализует функционал Реверс прокси. В данном режиме есть возможность терминировать трафик приложений или же осуществлять L4 балансировку. В контексте Termidesk Connect это следующие типы балансировки:
TCP балансировка:
HTTP балансировка
Модуль PAC отвечает за другой тип балансировки, в интерфейсе он отмечается как RAPID-TCP/RAPID-UDP. В отличие от двух предыдущих, на устройстве не происходит терминирования соединения.
Пример для TCP описан ниже:
RAPID-TCP:
Самые высокие цифры производительности получаются именно в данном режиме. Минус данного подхода очевиден при рассмотрении схемы - отсутствует возможность влиять на данные приложения (но мы работаем в данном направлении).
Работа с содержимым запроса
Вспомним, что мы говорим не про "балансировщик", а про Контроллер Доставки Приложений и вернемся к одному из важнейших сценариев применения - влиять на "Контент", а именно:
Принимать решения о выборе балансируемого сервера в зависимости от данных в запросе
Изменять содержимое этих запросов
Отвечать клиенту или перенаправлять его запрос
Разнообразие данных сценариев безгранично. У многих заказчиков есть уникальные задачи для работы с запросами.
Описание логики данных сценариев так же было всегда различно у разных производителей. Например, Citrix Netscaler имеет прекрасный Web конфигуратор, с подсказками и тп. F5 Big-IP исторически славился своими iRules с возможностью описать практически любое поведение в TCL скрипте.
Мы в команде Увеон, как разработчик продукта, не можем предугадать всех возможных задач, которые встанут перед нашими заказчиками. Но мы можем дать инструмент.
Данным инструментом является возможность описание логики с помощью Lua скрипта. Есть возможность задать несколько Lua скриптов, который будут выполняться последовательно друг за другом, тем самым осуществляется приоритет выполнения скриптов.
скрипты позволяют:
Получить IP адрес и порт отправителя
Проверить, попадает ли отправитель в нужную сеть
Проверить состояния Сервера Балансировки (online, offline, ..)
Анализировать HTTP запрос
Модифицировать HTTP запрос
Формировать ответ прямо из Lua скрипта без трансляции данного ответа на Реальный Сервер путем прямой передачи данных клиенту
В качестве примера приведем следующий скрипт:
if (client.http_req.host:find("qwe") and client.remote_p:is_network("10.140.0.0/16")) then
client.bs = "lb1"
client.action = "bs"
elseif client.http_req.host:find("qwe") then
client.http_req.header:field_set("XFF", client.remote_p.ip)
client.bs = "lb2"
client.action = "bs"
else
client.respond.status = 403
client.action = "respond"
Если hostname содержит ’qwe’ И запрос пришел из сети 10.140.0.0/8 – перенаправить на Сервер Балансировки “lb1”,
Если hostname содержит ’qwe’ – Добавить Заголовок XFF: <ip пользователя при подключении> и перенаправить запрос на Сервер Балансировки “lb2”
В противном случае вернуть 403 код ответа (по умолчанию вернется 503 ошибка)
Это короткий пример. Возможных манипуляций и условий может быть значительно больше.
1.4. Способы конфигурации
Конфигурация современного устройства, а особенно такого многофункционального, как Контроллер Доставки Приложений, не может быть ограниченна чем-то одним. Где-то удобен веб-интерфейс, кто-то привык настраивать через командную строку, ну а современные подходы автоматизации требуют совсем иных интерфейсов управления, например REST или NETCONF.
Все эти подходы реализованы в в нашем продукте.
Веб интерфейс
API
Командная строка
Очень важно иметь интуитивно понятный инструмент. Здесь мы можем видеть, что процесс настройки различных параметров максимально прост и понятен. Параметры сгруппированы по типам или задачам и при настройке сразу показывают состояние балансируемых сервисов.
Пример настройки TCP балансировки
Рассмотрим пример создания точки балансировки (В примере тип TCP):
Для начала перейдем в раздел Проверки:
Как можно заметить, существует 2 проверки по умолчанию. Создадим для примера свою:
Далее перейдем в раздел Реальные Серверы. Создадим группу и добавим в нее несколько веб серверов
Выберем ранее созданную проверку
И добавим сервера, между которыми будем балансировать запросы
Не все из серверов прошли проверку
Группа отмечается как "Частично" доступная
Далее создадим Сервер Балансировки
Выберем ранее созданную группу
Алгоритм и другие параметры в этом примере оставим "как есть"
Далее создадим Виртуальный Сервер:
Укажем IP адрес и порт, на котором мы будем ожидать запросы клиентов
Добавим правило выбора Сервера Балансировки. Чем ниже приоритет, тем раньше правило будет обработано
В примере все запросы будут попадать на lb-habr-01
На этом базовая настройка балансировки TCP сессий завершена.
Геобалансировка
Геобалансировка - технология, которая работает на основе DNS. Высокоуровневую архитектуру внедрения для географической балансировки можно представить следующим образом.
Предположим, что у компании есть несколько территориальных офисов и датацентров, размещённых например в Москве и во Владивостоке. Для повышения комфортности работы пользователей при таком распределении офисов нужно обеспечить подключение к ближайшему или наименее загруженному ЦОДу. Для упрощения работы, пользователь знает один (единый) адрес для подключения к необходимым сервисам – Termidesk VDI/Terminal, веб-приложениям, почтовой системе, 1С и тд. Пройдя по этому адресу система определяет какой ЦОД, а затем какой сервер будет обеспечивать наилучшее качество работы и осуществляет подключение пользователя к требуемому серверу/сервису. В случае отказа одного из ЦОДов, пользователи при подключении будут автоматически перенаправляться на оставшиеся доступные ЦОДы.
При перемещении пользователя в новый регион, алгоритм выбора рабочей площадки, также предложит ему наиболее подходящий ЦОД.
Такая схема позволит обеспечить наиболее комфортную работу для пользователей независимо от их текущего местоположения, и количества территориально распределённых ЦОДов.
На каждой площадке (ЦОДе) устанавливается отказоустойчивая пара устройств, которые собираются по схеме активный-резервный.
Локальная отказоустойчивость.
Мы обеспечиваем отказоустойчивость приложений, это значит мы сами не имеем права быть точкой отказа. Для этого сейчас реализован подход Active / Standby. Активное устройство обрабатывает весь трафик, Резервное в первую очередь проверяет Активное устройство. Так же оно может осуществлять проверку балансируемых серверов для создания различных failover сценариев
Между устройствами синхронизируются конфигурация, файлы сертификатов, файлы сценариев. Не используется multicast и тому подобное, так как по нашему опыту это иногда являлось проблемой при работе на различных гипервизорах.
Что дальше?
Развивать существующий функционал, добавлять новые протоколы и методы работы.
Сейчас Termidesk Connect доступен в виде виртуального устройства, но также активно ведется проработка новых форм-факторов.
В следующих статьях мы опишем особенности настройки и конфигурирования.
