Современные корпоративные приложения редко работают на одном сервере. Веб-сервисы, личные кабинеты, системы документооборота, внутренние порталы и другие информационные системы могут одновременно обслуживать сотни или тысячи пользователей. Если весь поток запросов направлять на единственный сервер, он становится не только потенциальным узким местом по производительности, но и единой точкой отказа: при недоступности узла пользователи теряют доступ к сервису.

Для решения этой задачи применяются балансировщики нагрузки и контроллеры доставки приложений - Application Delivery Controller, или ADC. Такие системы располагаются между пользователями и серверами приложений, принимают входящие соединения и распределяют их между несколькими доступными узлами.

К этому классу относится российское решение Termidesk Connect. Разработчик определяет его как контроллер доставки приложений, предназначенный для балансировки нагрузки и обеспечения высокой доступности сервисов в пределах одного центра обработки данных или нескольких площадок. В актуальной версии продукта поддерживаются механизмы распределения трафика, проверки состояния серверов, работы в отказоустойчивом кластере и управления маршрутизацией запросов.

Зачем приложениям требуется балансировка нагрузки

Рассмотрим типичную корпоративную систему. Пользователи подключаются к веб-приложению, которое работает на одном сервере. Пока число запросов невелико, такая архитектура может быть достаточной.

По мере роста нагрузки сервер начинает одновременно обрабатывать всё больше соединений. Увеличивается потребление процессорных ресурсов и оперативной памяти, возрастает время выполнения запросов. В определённый момент добавление аппаратных ресурсов одному серверу перестаёт быть оптимальным способом масштабирования.

Вместо увеличения мощности единственного узла можно запустить несколько экземпляров приложения. Но тогда появляется другая задача: необходимо определить, на какой сервер направлять каждый новый запрос.

Балансировщик становится промежуточной точкой. Пользователь обращается к одному адресу приложения, а балансировщик выбирает сервер, который фактически обработает запрос.

Таким образом, клиенту не требуется знать внутреннюю структуру инфраструктуры. За одним адресом могут находиться два, пять или несколько десятков серверов.

Такой подход позволяет одновременно решать две задачи: распределять вычислительную нагрузку и уменьшать зависимость приложения от состояния отдельного серверного узла.

Место Termidesk Connect в архитектуре

Согласно документации, Termidesk Connect выступает посредником между пользователем и сервером приложения. Получив запрос на соединение, система направляет его на соответствующий сервер с учётом настроенной логики обработки трафика.

Упрощённую архитектуру можно представить следующим образом.

Пользователь обращается к адресу корпоративного сервиса. Соединение сначала приходит на Termidesk Connect. Система анализирует доступность серверов и применяет заданные правила балансировки. После этого запрос отправляется одному из серверов приложений.

Ответ проходит обратно к пользователю через соответствующую сетевую схему.

В результате серверы приложений могут быть скрыты за единым логическим адресом. Это облегчает масштабирование: при необходимости в серверную группу можно добавлять дополнительные экземпляры приложения, не изменяя адрес, который используют конечные пользователи.

Termidesk Connect относится к категории ADC. Такие системы объединяют функции собственно балансировки с дополнительными механизмами управления соединениями, проверки состояния сервисов, маршрутизации и обработки прикладного трафика. Архитектурная документация продукта описывает ADC как уровень, сочетающий балансировку, ускорение приложений, оптимизацию трафика и дополнительные средства обработки соединений.

Распределение запросов между серверами

Ключевая задача балансировщика - определить, какой сервер должен принять очередное соединение.

Самый простой подход заключается в последовательном распределении запросов. Первый запрос получает один сервер, второй - следующий, после чего цикл повторяется.

Однако реальная инфраструктура не всегда состоит из одинаковых узлов. Один сервер может иметь больше процессорных ресурсов, другой уже обслуживает значительное количество соединений, а третий временно работает с повышенной нагрузкой.

Поэтому современные ADC используют различные алгоритмы балансировки. Termidesk Connect предусматривает интеллектуальное распределение нагрузки между экземплярами приложения.

Конкретная логика выбирается администратором с учётом характера сервиса. Для одних приложений важно приблизительно равномерно распределить подключения, для других - учитывать существующие соединения или дополнительные условия.

При проектировании важно понимать, что балансировка не увеличивает производительность самого приложения автоматически. Если программная система плохо масштабируется горизонтально или все серверы зависят от одной перегруженной базы данных, распределение веб-запросов между дополнительными узлами может не устранить реальное ограничение.

Проверки состояния серверов

Балансировка между несколькими узлами имеет смысл только тогда, когда система способна определить, какие из них действительно готовы принимать запросы.

Если один сервер аварийно завершил работу, балансировщик не должен продолжать отправлять ему новых пользователей.

Для этого применяются health checks - проверки работоспособности.

Termidesk Connect поддерживает проверки состояния балансируемых сервисов. Документация продукта предусматривает расширенные health check, а также сбор соответствующей эксплуатационной информации.

Проверка может быть сложнее обычного определения сетевой доступности узла. Сервер способен отвечать на сетевые запросы, но само приложение внутри него уже может функционировать некорректно.

В версиях Termidesk Connect, выпущенных в 2025 году, были расширены возможности HTTP- и HTTPS-проверок, включая использование метода POST и анализ содержимого ответа сервера. Это позволяет проверять не только наличие сетевого соединения, но и фактическую реакцию прикладного сервиса.

При обнаружении недоступного экземпляра его можно исключить из распределения новых запросов. После восстановления сервис снова может быть возвращён в рабочую группу в соответствии с настроенными правилами.

Высокая доступность приложений

Балансировка между backend-серверами решает только часть задачи отказоустойчивости.

Если сам балансировщик существует в единственном экземпляре, он превращается в новую точку отказа. Все серверы приложения могут оставаться исправными, но пользователи не смогут обратиться к ним при недоступности балансировщика.

Поэтому для критичных информационных систем применяются несколько экземпляров ADC.

В Termidesk Connect предусмотрена кластеризация с автоматическим переключением ролей. В версии 1.1 разработчик реализовал сценарий Active/Standby, при котором конфигурации узлов синхронизируются, а при проблеме активного экземпляра может выполняться failover на резервный.

В такой схеме один экземпляр непосредственно обслуживает рабочий трафик, а второй готов принять его при отказе основного.

В версии 1.3, представленной в апреле 2026 года, механизм высокой доступности получил более гибкие условия автоматического переключения. При принятии решения могут учитываться состояние сервисов, доступность сети и пороговые значения отдельных показателей.

При этом наличие двух ADC не делает всю информационную систему полностью отказоустойчивой. Необходимо анализировать остальные компоненты: сетевое оборудование, DNS, серверы приложений, базы данных и системы хранения.

Высокая доступность возникает только тогда, когда в критическом пути отсутствуют непродублированные точки отказа.

Балансировка между несколькими площадками

Организация может размещать инфраструктуру не в одном центре обработки данных, а на нескольких площадках.

Например, основной ЦОД располагается в одном городе, резервный - в другом. Или отдельные вычислительные мощности распределены по нескольким корпоративным площадкам.

В таком случае возникает задача глобального распределения запросов.

Termidesk Connect предусматривает балансировку приложений, развёрнутых на нескольких площадках и в нескольких ЦОД.

Практический смысл подобной архитектуры состоит в том, что пользовательский трафик можно направлять к доступной или соответствующей заданным условиям площадке.

Если один центр обработки данных становится недоступен, существует возможность переключения обслуживания на другую площадку - при условии, что само приложение и его данные подготовлены к такому сценарию.

Именно последнее условие имеет принципиальное значение. Балансировщик способен перенаправить сетевой запрос, но он не может самостоятельно обеспечить синхронность баз данных или файловых хранилищ между двумя ЦОД. Географическая отказоустойчивость должна проектироваться на всех уровнях приложения.

Работа на уровне TCP

Не все корпоративные системы используют исключительно HTTP или HTTPS.

Существуют базы данных, почтовые службы и специализированные сервисы, которые работают поверх других прикладных протоколов, использующих TCP.

В функциональных возможностях Termidesk Connect заявлен режим обратного TCP-прокси.

В этой схеме пользовательское соединение завершается на промежуточном узле, после чего Termidesk Connect устанавливает соответствующее соединение с backend-сервером.

Благодаря этому механизм балансировки может применяться не только к классическому веб-сайту.

Конкретная применимость зависит от протокола, требований приложения к состоянию соединения и используемой схемы маршрутизации. Поэтому перед включением балансировщика для специализированного сервиса необходимо проверить его поведение на тестовом стенде.

Балансировка на уровне приложений

Для HTTP-систем доступны более сложные сценарии, поскольку балансировщик способен учитывать информацию непосредственно в запросах.

На продуктовой странице Termidesk Connect среди функций указаны выбор группы серверов в зависимости от содержимого запроса и его источника, а также возможность модификации запросов.

Это позволяет строить маршрутизацию не только по принципу "выбрать один из одинаковых серверов".

Например, разные группы запросов могут направляться в различные серверные пулы. Такой подход применяется в архитектурах, где за единым внешним адресом работают несколько внутренних сервисов.

Подобная логика требует осторожной настройки. Чем больше правил обработки запросов находится на уровне ADC, тем важнее документировать конфигурацию. Иначе со временем становится сложнее определить фактический маршрут пользовательского трафика.

SSL Offload

Шифрование HTTPS требует выполнения криптографических операций. При большом количестве соединений эти операции создают дополнительную вычислительную нагрузку.

В архитектуре с ADC часть обработки TLS/SSL может быть перенесена с серверов приложений на балансировщик. Такой подход обычно называют SSL Offload или TLS termination.

При запуске Termidesk Connect разработчик отдельно указывал возможность переноса операций шифрования и расшифрования SSL с backend-серверов на балансировщик.

После завершения защищённого соединения на ADC дальнейшее взаимодействие с backend может строиться в соответствии с принятой архитектурой и требованиями безопасности.

Перенос TLS на балансировщик способен уменьшить объём криптографической работы на прикладных серверах. Одновременно ADC становится важной частью контура защиты, поскольку именно на нём располагаются сертификаты и обрабатываются пользовательские соединения.

Поэтому доступ к настройкам такого узла должен быть строго ограничен.

Сохранение пользовательских сессий

Некоторые приложения не полностью независимы от конкретного backend-сервера.

Например, после авторизации часть информации о пользовательской сессии может храниться в памяти того экземпляра приложения, на котором был выполнен вход.

Если каждый следующий запрос случайным образом отправляется на другой сервер, пользователь может столкнуться с ошибками.

Для таких архитектур используются механизмы привязки сессии, часто называемые persistence или sticky sessions.

При проектировании балансировки необходимо выяснить, является ли приложение stateless - то есть может ли любой его экземпляр одинаково обработать продолжение пользовательского сеанса.

Более устойчивой с точки зрения масштабирования обычно является архитектура, в которой состояние вынесено в общее хранилище и backend-серверы взаимозаменяемы. Однако изменение уже существующего корпоративного приложения ради этого может быть сложной задачей.

Поэтому настройка ADC всегда должна учитывать устройство конкретной информационной системы, а не только сетевую схему.

Мониторинг состояния Termidesk Connect

Балансировщик является критичным компонентом, поэтому необходимо наблюдать не только за backend-серверами, но и за самим ADC.

Документация Termidesk Connect предусматривает детализированный мониторинг загрузки процессора, оперативной памяти, сетевого трафика и других показателей. Также поддерживаются журналы событий изменений конфигурации и журналы доступа.

Для интеграции с внешними средствами наблюдения предусмотрена передача логов и статистической информации в сторонние системы через Syslog. Документация также указывает поддержку открытого формата представления метрик OpenMetrics.

Это важно для крупных инфраструктур, где отдельный интерфейс балансировщика не должен становиться единственным местом контроля.

Метрики ADC могут включаться в общую систему observability вместе с данными серверов приложений, баз данных и сетевого оборудования.

Тогда при проблеме специалист видит не только сообщение о недоступности сервиса, но и контекст: нагрузку балансировщика, количество подключений и состояние backend-узлов.

Управление конфигурацией

Для управления Termidesk Connect предусмотрены веб-интерфейс и командная строка. После первоначальной настройки документация указывает доступность административного интерфейса через веб и подключения по SSH.

Графический интерфейс может быть удобен для первоначальной настройки, просмотра серверных групп, health check и правил обработки трафика.

Командная строка важна при автоматизации и сопровождении крупных инфраструктур.

Наличие нескольких методов администрирования, однако, создаёт необходимость контролировать изменения конфигурации. Если часть настроек выполняется вручную, а часть - автоматизированными средствами, должен существовать понятный процесс определения актуального состояния.

Для высокодоступной пары особенно важна синхронизация конфигураций. В противном случае после переключения на резервный ADC пользовательские соединения могут обрабатываться иначе, чем на основном узле.

Termidesk Connect и контейнерная инфраструктура

Современные приложения всё чаще развёртываются не на обычных виртуальных машинах, а в контейнерных средах.

В июле 2026 года была опубликована информация о сценарии совместного использования Termidesk Connect с платформой управления Kubernetes-кластерами "Боцман". В такой архитектуре "Боцман" отвечает за управление кластерами и жизненным циклом контейнеризированных приложений, а Termidesk Connect используется для распределения и маршрутизации пользовательского трафика между сервисами и проверки их состояния.

Этот пример показывает общую роль ADC в контейнерной архитектуре: балансировщик не управляет самим Kubernetes-кластером, а решает задачу доставки внешнего трафика к приложениям.

При этом Kubernetes располагает собственными механизмами Service и Ingress, поэтому конкретное место внешнего ADC зависит от архитектуры организации.

Перед внедрением необходимо определить границу ответственности между сетевым балансировщиком, компонентами Kubernetes и внутренними механизмами приложения.

Информационная безопасность

Балансировщик располагается в важной точке сетевого маршрута и обрабатывает значительную часть пользовательского трафика. Поэтому вопросы безопасности должны учитываться наравне с производительностью.

В Termidesk Connect предусмотрены механизмы разграничения административного доступа. В версии 1.1 разработчик добавил более детализированную настройку прав и поддержку LDAP/LDAPS для соответствующих сценариев централизованного управления учётными записями.

Если ADC выполняет TLS termination, дополнительной защиты требуют закрытые ключи сертификатов.

Следует также ограничивать сетевую доступность административных интерфейсов, хранить журналы изменений и своевременно устанавливать обновления.

Однако ADC нельзя рассматривать как универсальную замену межсетевому экрану, WAF или другим специализированным средствам защиты. Эти компоненты могут работать совместно, но выполняют разные задачи.

Что происходит при отказе backend-сервера

Один из наиболее наглядных сценариев применения балансировщика - отказ отдельного экземпляра приложения.

Предположим, приложение работает на трёх одинаковых серверах. Termidesk Connect распределяет соединения между ними.

Один сервер перестаёт корректно отвечать на проверку состояния. Балансировщик фиксирует это и исключает проблемный узел из набора серверов, которым передаются новые запросы.

Оставшиеся экземпляры продолжают обслуживание.

После восстановления неисправного сервера и успешного прохождения health check он может быть возвращён в распределение нагрузки.

Для пользователя такой отказ потенциально проходит без полной недоступности приложения.

Однако результат зависит от природы существующих соединений. Уже установленная пользовательская сессия на отказавшем сервере может быть потеряна, если само приложение не реализует механизм восстановления состояния.

Поэтому высокая доступность - это свойство всей системы, а не только балансировщика.

Масштабирование приложений

Балансировщик создаёт техническую основу для горизонтального масштабирования.

Когда текущие серверы приближаются к пределу производительности, администратор может добавить ещё один экземпляр приложения и включить его в серверную группу.

После успешной проверки состояния ADC начинает использовать новый узел при распределении трафика.

Такой подход позволяет увеличивать суммарную вычислительную способность приложения без перехода на один значительно более мощный сервер.

Обратный процесс также возможен. При снижении нагрузки часть узлов может быть выведена из обслуживания.

Но горизонтальное масштабирование эффективно только для приложений, архитектура которых допускает работу нескольких экземпляров. Общая база данных, файловое хранилище или внешний сервис всё равно могут стать узким местом.

Поэтому балансировка должна рассматриваться как один из уровней масштабирования.

Планирование внедрения Termidesk Connect

Внедрение ADC лучше начинать с анализа существующего приложения.

Сначала необходимо определить, сколько серверов обслуживает сервис и какие протоколы используются. Затем следует выяснить, хранится ли пользовательская сессия непосредственно на backend, существуют ли долгоживущие соединения и какие проверки действительно показывают работоспособность приложения.

После этого определяется требуемая схема высокой доступности самого балансировщика.

Для критичного сервиса использование одного экземпляра ADC обычно не решает проблему единой точки отказа. Поэтому рассматривается кластерная схема.

Следующий этап - создание тестового стенда.

На нём проверяют распределение нагрузки, отключение одного backend-сервера, восстановление узла, отказ основного балансировщика и переключение на резервный.

Отдельно полезно провести нагрузочное тестирование. Оно позволяет установить, какую производительность показывает не только Termidesk Connect, но и вся цепочка от клиента до базы данных.

Только после проверки аварийных сценариев конфигурацию целесообразно переносить в промышленную инфраструктуру.

Ограничения балансировщика нагрузки

ADC способен существенно повысить устойчивость сервисов, но не устраняет все виды отказов.

Если все backend-серверы используют единственную базу данных, её недоступность остановит приложение независимо от состояния балансировщика.

Если два узла Termidesk Connect находятся на одном физическом сервере, отказ этого сервера затронет оба экземпляра.

Если основная и резервная площадки используют один канал связи, повреждение канала может сделать географическое резервирование бесполезным.

Наконец, ошибочная конфигурация балансировщика сама способна нарушить доступность сервиса. Например, неверно настроенная health check может считать исправные серверы недоступными.

Поэтому важны резервное копирование конфигураций, тестирование изменений и постепенный ввод новых правил.

Termidesk Connect как часть инфраструктуры высокой доступности

Termidesk Connect следует рассматривать не как отдельное средство, автоматически обеспечивающее отказоустойчивость приложения, а как инфраструктурный компонент между пользователями и серверными сервисами.

Его функции включают распределение входящего трафика, обратное TCP-проксирование, выбор серверных групп по условиям запроса, работу с приложениями на нескольких площадках и применение алгоритмов балансировки.

По состоянию на 2026 год актуальная продуктовая ветка получила развитие механизмов HA, мониторинга и управления условиями автоматического переключения между узлами. В версии 1.3, анонсированной в апреле 2026 года, были расширены настройки отказоустойчивого кластера.

Практическая ценность этих функций определяется тем, насколько корректно они встроены в архитектуру конкретного сервиса.

Балансировщик должен знать, какие backend-серверы действительно работоспособны, приложение должно выдерживать переключение между экземплярами, а инфраструктура данных - оставаться доступной после отказа отдельных компонентов.

Заключение

Termidesk Connect представляет собой российский контроллер доставки приложений класса ADC, предназначенный для балансировки пользовательского трафика и построения высокодоступных схем доступа к корпоративным сервисам. Решение располагается между клиентами и серверами приложений и распределяет соединения между доступными backend-узлами.

Использование балансировщика позволяет отделить внешний адрес сервиса от его внутренней серверной архитектуры. За одной точкой подключения могут находиться несколько экземпляров приложения, а неисправный сервер может быть исключён из обработки новых запросов на основании проверки состояния.

Для устранения единой точки отказа самого ADC Termidesk Connect поддерживает высокодоступную кластерную конфигурацию с переключением между узлами и синхронизацией настроек. Современные версии также предусматривают более детальные критерии определения необходимости failover.

Дополнительные возможности связаны с балансировкой между несколькими площадками, обратным TCP-прокси, маршрутизацией с учётом характеристик запроса, мониторингом, журналированием и интеграцией с внешними системами сбора метрик.

При этом Termidesk Connect решает только определённую часть задачи высокой доступности. Отказоустойчивая информационная система также требует резервирования серверов приложений, баз данных, сетевого оборудования, систем хранения и других критичных компонентов.

Поэтому внедрение балансировщика следует начинать с анализа всей цепочки предоставления сервиса. Необходимо определить точки отказа, разработать адекватные проверки состояния, протестировать переключение серверов и ADC, проверить работу пользовательских сессий и провести нагрузочные испытания. В таком подходе Termidesk Connect выполняет роль уровня доставки и распределения трафика, а итоговая доступность приложения определяется согласованной работой всей инфраструктуры.