Корпоративные приложения должны оставаться доступными при росте числа пользователей, техническом обслуживании серверов и локальных сбоях. Если весь входящий трафик направляется на один сервер, его перегрузка или отказ способны остановить работу сайта, внутреннего портала, системы документооборота либо другого сервиса. Для распределения запросов между несколькими узлами применяются балансировщики нагрузки и более функциональные контроллеры доставки приложений.
Контроллер доставки приложений, или ADC, размещается между пользователями и серверами приложения. Он принимает входящие соединения, анализирует их в пределах настроенных правил, выбирает подходящий сервер и пересылает ему запрос. Дополнительно такое решение может контролировать доступность узлов, обрабатывать защищённые соединения, сохранять пользовательскую сессию на одном сервере и переключать трафик при неполадках.
Termidesk Connect - российский программный контроллер доставки приложений, предназначенный для балансировки нагрузки, масштабирования сервисов и построения отказоустойчивой инфраструктуры. Первая публичная презентация продукта состоялась в марте 2025 года. В актуальной документации рассматривается версия 1.3, поддерживающая локальную и глобальную балансировку, работу в отказоустойчивом кластере и управление сетевым трафиком.
Наличие балансировщика не гарантирует бесперебойность само по себе. Для устойчивой работы также необходимы резервные серверы, надёжные каналы связи, корректные проверки состояния, резервное копирование, мониторинг и заранее отработанный план восстановления.
Зачем нужен контроллер доставки приложений
Простой сетевой балансировщик распределяет соединения между несколькими серверами. Контроллер доставки приложений решает более широкий набор задач. Он может принимать решения не только на основании IP-адреса и порта, но и с учётом параметров HTTP-запроса, доменного имени, пути, заголовков и других признаков.
Например, запросы к основному сайту могут направляться в один серверный пул, обращения к программному интерфейсу - в другой, а статические материалы - в третий. Это позволяет разделять компоненты системы и масштабировать их независимо.
Контроллер также отделяет внешний адрес сервиса от реальных адресов серверов. Пользователь обращается к виртуальному адресу, а инфраструктура за ним может изменяться: серверы добавляются, выводятся на обслуживание или заменяются без изменения пользовательской точки входа.
Termidesk Connect описывается разработчиком как многофункциональное сетевое устройство, способное работать в роли локального балансировщика, глобального балансировщика и шлюза удалённого доступа. Конкретный набор функций зависит от установленной версии и конфигурации.
Как проходит обработка запроса
Пользовательское приложение устанавливает соединение с виртуальным сервером Termidesk Connect. Виртуальный сервер связан с правилами обработки трафика и группой реальных серверов.
После получения запроса контроллер выполняет несколько действий:
- определяет подходящий виртуальный сервис;
- проверяет применимые правила доступа;
- выбирает серверный пул;
- исключает недоступные узлы;
- применяет алгоритм балансировки;
- перенаправляет соединение на выбранный сервер;
- при необходимости сохраняет связь между сессией и сервером.
В документации Termidesk Connect сервер балансировки определяется как логический объект, перенаправляющий пользовательское подключение на один из реальных серверов по заданному алгоритму. Поддерживаются схемы с сохранением клиентского IP-адреса и другие варианты сетевой обработки.
Для пользователя такая архитектура обычно остаётся незаметной. Он обращается к одному адресу, даже если за ним работают десятки серверов.
Балансировка на уровнях L4 и L7
Уровни L4 и L7 относятся к модели сетевого взаимодействия.
Балансировка L4 работает с транспортными соединениями TCP и UDP. Контроллер учитывает адреса, порты и состояние соединения, но не обязан подробно анализировать содержимое прикладного запроса. Такой вариант подходит для большого числа сетевых сервисов и обычно требует меньше вычислительных ресурсов.
Балансировка L7 работает на уровне приложений. Она может учитывать параметры HTTP- или HTTPS-запроса и применять более сложную логику маршрутизации. Например, один домен направляется в один пул, другой - в другой, а запросы к определённому пути обслуживаются специализированными серверами.
В первой версии Termidesk Connect были заявлены балансировка на уровнях L4 и L7 и Content Switching - переключение серверных ресурсов в зависимости от содержимого запроса. В версии 1.1 появилась поддержка UDP, расширившая применение продукта за пределы стандартных веб-приложений.
Выбор уровня зависит от задачи. Если требуется только быстро распределить TCP-соединения, L4 может быть достаточным. Если маршрутизация зависит от содержимого веб-запроса, необходима логика L7.
Алгоритмы распределения нагрузки
Когда в пуле работают несколько серверов, контроллер должен определить, куда направить новое соединение. Для этого используются алгоритмы балансировки.
Простейшая схема последовательно распределяет запросы по всем узлам. Другой алгоритм выбирает сервер с наименьшим количеством активных соединений. Также могут учитываться вес сервера, его производительность, время ответа и другие параметры.
Весовые коэффициенты полезны, если серверы отличаются по ресурсам. Более производительному узлу назначается большая доля запросов, а менее мощному - меньшая.
Нельзя утверждать, что один алгоритм всегда лучше остальных. Для коротких веб-запросов подходит одна модель, для продолжительных соединений - другая. Выбор следует подтверждать нагрузочным тестированием.
В описании Termidesk Connect заявлены интеллектуальные алгоритмы распределения нагрузки между экземплярами приложений. Точные алгоритмы и доступные параметры необходимо проверять в документации конкретного выпуска.
Контроль состояния серверов
Балансировщик должен понимать, способен ли сервер обслуживать запросы. Для этого выполняются проверки состояния - health checks.
Простая проверка определяет, доступен ли сетевой порт. Более глубокая может отправить HTTP-запрос и убедиться, что приложение возвращает ожидаемый код или содержимое. Это важно, потому что работающий сетевой интерфейс ещё не означает исправность самой программы.
Если проверка завершается неудачно, узел временно исключается из распределения. После восстановления и успешного прохождения заданного числа проверок он может быть возвращён в пул.
Параметры проверок требуют осторожной настройки. Слишком редкие проверки замедляют обнаружение сбоя, а слишком частые создают дополнительную нагрузку и способны ошибочно признать сервер недоступным при кратковременной задержке.
Также необходимо продумать, что произойдёт, если недоступными окажутся все узлы пула: будет ли показана служебная страница, использован резервный пул или соединение завершится ошибкой.
Отказоустойчивость самого балансировщика
Установка нескольких серверов приложений не решает проблему, если контроллер остаётся единственной точкой отказа. Поэтому сам балансировщик должен иметь резервирование.
Termidesk Connect поддерживает высокодоступную конфигурацию из двух и более узлов. В документации версии 1.3 указано, что в кластер можно объединить до 255 устройств. Между узлами синхронизируется общая конфигурация, резервируются виртуальные IP-адреса, а при отказе активного устройства трафик переключается на доступный узел.
В базовой логике один узел обрабатывает пользовательский трафик как Active, а один или несколько других находятся в состоянии Standby. При недоступности активного узла виртуальный адрес переносится на резервный.
Документация также описывает "плавающие" адреса и возможность объединения устройств, размещённых на разных площадках и в разных сетях. При этом часть параметров остаётся локальной для каждого узла, а общие объекты синхронизируются.
Кластер следует тестировать не только после установки. Необходимо периодически проверять переключение, восстановление прежнего узла и поведение активных сессий.
Синхронизация конфигурации
При ручном редактировании нескольких балансировщиков легко получить различающиеся настройки. На одном узле может отсутствовать новый сертификат, правило или серверный пул. В момент аварийного переключения это приведёт к непредсказуемому поведению.
Termidesk Connect синхронизирует между узлами кластера общие параметры и необходимые файлы, включая отдельные сертификаты и скрипты. Некоторые сетевые настройки, имена устройств и локальные маршруты остаются индивидуальными.
Администратору важно понимать границу между общей и локальной конфигурацией. Объект, который должен существовать на всех узлах, нельзя случайно создать как локальный. И наоборот, индивидуальный адрес управления не следует распространять на весь кластер.
Перед обновлением желательно сохранить конфигурацию и проверить совместимость версий. Документация требует, чтобы узлы отказоустойчивой группы использовали одинаковую версию Termidesk Connect.
Глобальная балансировка GSLB
Локальный балансировщик распределяет запросы между серверами внутри одной инфраструктуры. GSLB, или глобальная балансировка, применяется, когда приложение работает в нескольких центрах обработки данных или географических регионах.
Запрос можно направлять в ближайший, наименее загруженный или доступный ЦОД. При полном отказе одной площадки пользователи переключаются на другую.
В архитектуре Termidesk Connect глобальный балансировщик предназначен для распределения запросов между ЦОДами и выбора более подходящей площадки по заданной логике. Возможность GSLB была заявлена разработчиком при представлении продукта.
Георезервирование сложнее локального кластера. Необходимо синхронизировать данные приложений, учитывать задержку DNS, доступность внешних каналов и согласованность пользовательских сессий.
Если данные находятся только в одном ЦОД, перенаправление веб-трафика на резервную площадку не обеспечит полноценное восстановление. Поэтому GSLB является лишь частью плана аварийного восстановления.
SSL Offload
При HTTPS-соединении сервер выполняет операции шифрования и расшифрования. При большом количестве запросов это создаёт дополнительную нагрузку.
SSL Offload переносит обработку TLS на контроллер доставки приложений. Termidesk Connect принимает защищённое соединение, выполняет криптографические операции и передаёт запрос на сервер приложения. Между балансировщиком и сервером соединение может оставаться шифрованным либо работать по внутренней незашифрованной сети - выбор зависит от политики безопасности.
Разработчик указывает SSL Offload среди возможностей Termidesk Connect и связывает его с разгрузкой backend-серверов.
Централизация сертификатов упрощает их обновление, но увеличивает критичность балансировщика. Закрытые ключи необходимо защищать, а сроки действия сертификатов - контролировать автоматически.
Также следует отключать устаревшие версии протоколов и слабые наборы шифров. Сам факт применения HTTPS не гарантирует безопасную конфигурацию.
Сохранение пользовательской сессии
Некоторые приложения хранят состояние пользователя в памяти конкретного сервера. Если следующий запрос попадёт на другой узел, человек может потерять авторизацию или незавершённые данные.
Для таких систем применяется persistence - закрепление сессии за определённым сервером. Привязка может выполняться по cookie, адресу клиента или другому признаку.
Сохранение сессии упрощает работу с приложениями, которые не умеют централизованно хранить состояние. Но оно снижает свободу балансировки: один сервер может получить слишком много "закреплённых" пользователей.
Более устойчивой архитектурой считается хранение сессий во внешнем общем хранилище либо создание приложения без состояния. Тогда запросы можно свободно распределять между всеми узлами.
Если сервер с закреплёнными сессиями выходит из строя, необходимо заранее определить, смогут ли пользователи продолжить работу на другом узле или им придётся повторно войти.
Content Switching
Content Switching позволяет выбирать направление трафика на основании содержимого запроса.
Например:
- /api/ передаётся серверам программного интерфейса;
- /media/ направляется в пул статического контента;
- личный кабинет обслуживается отдельной группой серверов;
- запросы с одного доменного имени идут в основное приложение, а с другого - в тестовую среду.
Такой подход уменьшает количество внешних адресов и позволяет использовать одну точку входа для нескольких компонентов.
Termidesk Connect заявляет выбор группы серверов на основании содержимого запроса и его источника, а также возможность модификации запросов.
Правила должны быть документированы и протестированы. Слишком сложная цепочка условий усложняет диагностику: администратору становится трудно понять, почему конкретный запрос попал на определённый сервер.
Ограничение пропускной способности
В инфраструктуре возможны ситуации, когда один клиент или сервер занимает значительную часть канала. Это ухудшает работу остальных сервисов и может привести к отказу из-за перегрузки.
В версии Termidesk Connect 1.3 появилась возможность ограничивать пропускную способность входящего пользовательского и исходящего серверного трафика. Такой механизм помогает уменьшить влияние "шумного" клиента или узла на общую инфраструктуру.
Ограничения следует устанавливать на основании измерений. Слишком низкий предел ухудшит работу легитимных пользователей, а слишком высокий не защитит от перегрузки.
Контроль полосы пропускания не является полной защитой от распределённых атак. Для серьёзных внешних угроз могут понадобиться услуги очистки трафика и другие специализированные средства.
Перебалансировка активных соединений
При добавлении нового сервера обычный балансировщик часто направляет на него только новые подключения. Уже установленные соединения продолжают работать на прежних узлах, поэтому выравнивание нагрузки происходит постепенно.
В Termidesk Connect 1.3 заявлен механизм перебалансировки, который может перераспределять уже установленные соединения после изменения состава или состояния пула. Разработчик связывает это с более равномерной утилизацией серверов после добавления либо восстановления узла.
Практическое применение зависит от протокола и приложения. Принудительное перемещение соединения может быть чувствительным для долгих транзакций, потокового трафика или систем, сохраняющих локальное состояние.
Перед включением функции необходимо проверить, как конкретное приложение переносит разрыв и повторное установление соединения.
Списки контроля доступа
Балансировщик находится на критическом участке сети, поэтому может участвовать в ограничении доступа. В Termidesk Connect 1.1 появились ACL - списки контроля доступа по IP-адресам, портам и диапазонам портов.
С помощью ACL можно разрешить административный доступ только из управляющего сегмента, ограничить обращения к служебному приложению или заблокировать нежелательные источники.
При этом ADC не заменяет полноценный межсетевой экран. Списки на балансировщике должны дополнять общую сетевую политику, а не быть единственным средством защиты.
Ошибочное правило способно заблокировать легитимный трафик. Поэтому изменения желательно применять через контролируемый процесс с возможностью быстрого отката.
Управление и администрирование
Termidesk Connect поддерживает графический веб-интерфейс и командную строку. Графическая консоль удобна для просмотра объектов и повседневных операций, а командная строка - для автоматизации и точной настройки.
Доступ к управляющему интерфейсу следует отделять от пользовательского трафика. Рекомендуется использовать отдельный адрес или сетевой сегмент, ограниченный список источников и защищённую аутентификацию.
В версии 1.1 была добавлена аутентификация администраторов через LDAP и LDAPS. Это позволяет применять централизованные учётные записи и упростить отзыв доступа после увольнения сотрудника.
Административные действия необходимо журналировать. Особенно важны изменения серверных пулов, сертификатов, ACL и отказоустойчивой конфигурации.
Общая учётная запись для всех администраторов затрудняет расследование инцидентов. Предпочтительны персональные учётные записи и минимально необходимые права.
Интеграция с Termidesk VDI
Termidesk Connect может использоваться как шлюз и балансировщик для инфраструктуры виртуальных рабочих мест Termidesk VDI. В такой архитектуре он принимает внешние подключения, распределяет их между компонентами и контролирует доступность узлов.
Разработчик указывает, что интеграция позволяет организовать доставку виртуальных рабочих столов и приложений, а также автоматический мониторинг доступности компонентов.
При этом Connect не ограничен только VDI. Он позиционируется как контроллер для разных корпоративных приложений и сетевых сервисов.
Для внешнего VDI-доступа особенно важны отказоустойчивость шлюза, защита учётных записей и резервирование каналов. Если балансировщик недоступен, пользователи могут потерять возможность подключиться даже при исправных виртуальных машинах.
Сценарии применения
Первый распространённый сценарий - корпоративный веб-портал. Несколько экземпляров приложения размещаются на разных серверах, а Termidesk Connect распределяет запросы и исключает неисправные узлы.
Второй сценарий - программный интерфейс с растущей нагрузкой. Новые backend-серверы добавляются в пул без изменения адреса, которым пользуются клиенты.
Третий - филиальная организация с двумя ЦОДами. Глобальная балансировка направляет запросы на доступную площадку, а локальная - распределяет их внутри выбранного центра.
Четвёртый - инфраструктура удалённых рабочих мест. Контроллер выступает внешней точкой входа и балансирует подключения к шлюзам или другим компонентам VDI.
Пятый - плановое обслуживание. Один сервер выводится из пула, обновляется и возвращается без полной остановки сервиса.
Любой из этих сценариев требует проверки совместимости приложения с балансировкой и резервированием данных.
Подготовка к внедрению
Перед внедрением необходимо составить карту сервисов. Для каждого приложения фиксируются адреса, порты, протоколы, зависимости, ожидаемая нагрузка и допустимое время простоя.
Затем определяются требования:
- нужен ли анализ L7;
- требуется ли сохранение сессий;
- где завершается TLS;
- какие проверки состояния использовать;
- сколько узлов балансировщика необходимо;
- потребуется ли распределение между ЦОДами;
- какие журналы передавать в систему мониторинга;
- как будет выполняться резервное копирование конфигурации.
Важно заранее определить владельца каждого приложения. Только технический специалист сервиса может подтвердить, какой запрос действительно показывает его работоспособность.
Проверка одной главной страницы недостаточна, если критичный backend уже не работает. Health check должен отражать реальную готовность приложения обслуживать пользователей.
Пилотное тестирование
Пилот лучше проводить на некритичном сервисе либо в тестовой среде. На первом этапе проверяется базовая маршрутизация и доступность всех серверов.
Затем моделируются сбои:
- остановка одного реального сервера;
- потеря сети до backend-пула;
- отказ активного узла Termidesk Connect;
- возврат восстановленного сервера;
- истечение или замена TLS-сертификата;
- резкий рост числа соединений;
- ошибочный ответ проверки состояния.
Необходимо измерять не только факт переключения, но и его длительность, влияние на активные сессии и корректность журналов.
Нагрузочное тестирование должно повторять реальный профиль запросов. Большое количество коротких HTTP-запросов и небольшое число долгих соединений создают разную нагрузку.
Мониторинг в эксплуатации
После запуска необходимо контролировать количество соединений, скорость запросов, время ответа, ошибки, состояние пулов и использование системных ресурсов.
Особое внимание уделяется:
- частым исключениям серверов из пула;
- неравномерному распределению нагрузки;
- приближению к пределам пропускной способности;
- ошибкам TLS;
- переключениям узлов кластера;
- изменениям конфигурации;
- срокам действия сертификатов.
Мониторинг должен включать проверку со стороны пользователя. Внутренний статус "сервер доступен" не означает, что сервис корректно работает из внешней сети.
Уведомления следует разделять по критичности. Если система отправляет слишком много незначительных сообщений, действительно важное событие может остаться незамеченным.
Обновление и сопровождение
Балансировщик является критическим компонентом и требует регулярного обновления. Новые версии могут исправлять ошибки, расширять поддержку протоколов и добавлять функции безопасности.
Перед обновлением необходимо изучить документацию выпуска, проверить совместимость конфигурации и сохранить резервную копию.
В отказоустойчивом кластере узлы можно обновлять последовательно, временно переводя трафик на другой экземпляр. Однако порядок зависит от рекомендаций производителя и совместимости версий.
После обновления проверяются синхронизация, виртуальные адреса, health checks, сертификаты и прохождение пользовательского трафика.
Документация и инструкции должны соответствовать фактической версии. Скриншоты и команды предыдущего выпуска могут отличаться от нового интерфейса. Официальные материалы Termidesk Connect прямо предупреждают, что внешний вид отдельных разделов меняется между версиями.
Ограничения контроллера доставки приложений
ADC не исправляет ошибки архитектуры приложения. Если все серверы используют одну незащищённую базу данных, её отказ остановит сервис независимо от числа балансируемых узлов.
Он не заменяет резервное копирование. Балансировка обеспечивает доступность, но не восстанавливает удалённые или повреждённые данные.
Он также не гарантирует защиту от любых атак. Для безопасности могут потребоваться межсетевые экраны, WAF, защита от DDoS, управление уязвимостями и контроль привилегированных учётных записей.
Балансировщик создаёт дополнительный уровень сложности. Ошибка в правилах маршрутизации способна повлиять сразу на несколько приложений. Поэтому конфигурация должна проходить проверку и документироваться.
Наконец, возможности конкретного выпуска продукта необходимо сверять с актуальной документацией. Функции, указанные в дорожной карте, ещё не являются частью установленной версии.
Как оценивать результат внедрения
Результат следует оценивать по измеримым показателям:
- доступность сервисов;
- продолжительность переключения после отказа;
- доля запросов с ошибками;
- равномерность загрузки серверов;
- время ответа;
- продолжительность плановых работ без простоя;
- скорость подключения нового узла;
- количество инцидентов из-за конфигурационных ошибок.
Если после внедрения серверы распределяют нагрузку равномерно, но пользователи продолжают сталкиваться с недоступностью базы данных, проект нельзя считать завершённым.
Отказоустойчивость рассматривается сквозным образом: от DNS и внешнего канала до балансировщика, приложения, базы данных и хранилища.
Заключение
Termidesk Connect - российский программный контроллер доставки приложений, предназначенный для балансировки нагрузки, повышения доступности и масштабирования ИТ-сервисов. Продукт поддерживает распределение TCP- и UDP-трафика, обработку запросов на уровнях L4 и L7, Content Switching, SSL Offload и работу с несколькими центрами обработки данных.
Для резервирования самого контроллера предусмотрена отказоустойчивая конфигурация из нескольких узлов с синхронизацией общих настроек, резервированием виртуальных адресов и автоматическим переключением трафика. В документации версии 1.3 указана возможность объединения до 255 узлов, хотя практический размер кластера должен определяться архитектурой и результатами тестирования.
Версия 1.3 расширила возможности управления пропускной способностью и перебалансировки установленных соединений. Эти механизмы помогают эффективнее распределять ресурсы, но требуют проверки совместимости с конкретными приложениями.
Termidesk Connect может применяться для корпоративных веб-сервисов, программных интерфейсов, геораспределённых систем и инфраструктуры виртуальных рабочих мест. При этом контроллер является только одним элементом отказоустойчивой архитектуры.
Надёжный результат требует резервных backend-серверов, корректных проверок состояния, защищённого административного доступа, мониторинга, резервного копирования и регулярного тестирования аварийных переключений. Только в этом случае балансировщик становится рабочим инструментом обеспечения доступности, а не новой единственной точкой отказа.
