Доступность корпоративных приложений напрямую зависит от того, насколько устойчиво работает инфраструктура, через которую пользователи получают к ним доступ. Если все запросы направляются на единственный сервер, его перегрузка или отказ способны привести к недоступности сервиса. По мере роста числа пользователей проблема становится заметнее: увеличивается количество одновременных соединений, усложняется архитектура приложений, появляются несколько центров обработки данных и необходимость распределять трафик между ними.
Для решения подобных задач применяются контроллеры доставки приложений - Application Delivery Controller, или ADC. Они располагаются между клиентами и серверами приложений и управляют прохождением запросов. В зависимости от архитектуры ADC может распределять нагрузку, контролировать доступность серверов, поддерживать пользовательские сессии, выполнять SSL-терминирование и обеспечивать переключение трафика при возникновении неисправностей.
К этому классу относится Termidesk Connect - российское решение для балансировки нагрузки и обеспечения высокой доступности приложений. Согласно актуальной документации, продукт может выполнять функции шлюза, локального балансировщика и глобального балансировщика для географически распределенной инфраструктуры.
Что такое балансировка нагрузки
Балансировка нагрузки - механизм распределения входящих соединений между несколькими серверами, предоставляющими один сервис.
Предположим, корпоративное веб-приложение работает на трех серверах. Без балансировщика пользователи могут обращаться непосредственно к одному из них. При росте количества соединений этот сервер становится узким местом, хотя остальные вычислительные ресурсы остаются свободными.
Балансировщик принимает клиентские подключения на виртуальном адресе и определяет, какому реальному серверу передать конкретный запрос.
Такой подход позволяет распределить нагрузку и одновременно создать предпосылки для отказоустойчивости. Если один из серверов становится недоступен, его можно исключить из распределения, направляя новые подключения на оставшиеся рабочие узлы.
Но балансировка и высокая доступность - не одно и то же. Первая отвечает прежде всего за распределение трафика, тогда как вторая требует продуманного резервирования всех критичных элементов инфраструктуры.
Что представляет собой Termidesk Connect
Termidesk Connect относится к классу ADC и выполняет роль промежуточного сетевого уровня между пользователями и серверами приложений.
В официальной документации решение определяется как многофункциональное сетевое устройство, предназначенное для масштабирования, обеспечения высокой доступности и защиты приложений, оптимизации их работы и георезервирования инфраструктуры.
Получив подключение пользователя, система обрабатывает его в соответствии с заданными правилами и направляет на подходящий сервер.
В режиме шлюза Termidesk Connect может использоваться как единая точка доступа к приложениям, серверам и другим сетевым ресурсам.
В режиме балансировщика он распределяет соединения между несколькими серверами.
В географически распределенной архитектуре решение может направлять пользователей между разными ЦОД, учитывая заданные условия доступности и распределения нагрузки.
Таким образом, назначение продукта выходит за рамки простого последовательного распределения HTTP-запросов.
Роль ADC в корпоративной инфраструктуре
Контроллер доставки приложений логически располагается перед серверной частью информационной системы.
Пользователь обращается не непосредственно к одному из серверов приложения, а к виртуальному сервису на ADC. Контроллер принимает соединение, анализирует его в пределах поддерживаемых функций и выбирает дальнейший маршрут.
Подобная архитектура дает возможность изменять серверную часть без необходимости сообщать пользователям адрес каждого отдельного узла.
Например, администратор может добавить четвертый сервер приложения. После включения его в соответствующую группу балансировки часть новых подключений начинает направляться на него.
При выводе сервера на обслуживание происходит обратная операция: узел перестает принимать новый трафик, тогда как пользователь продолжает обращаться по тому же адресу.
За счет этого ADC отделяет клиентскую точку подключения от физической структуры серверного кластера.
Балансировка на уровнях L4 и L7
Сетевое взаимодействие можно анализировать на разных уровнях, и от этого зависит функциональность балансировщика.
Termidesk Connect поддерживает балансировку на транспортном уровне L4 и прикладном уровне L7. В актуальной документации для L4 указаны TCP и UDP, а для L7 - HTTP, HTTPS и WebSocket.
На уровне L4 система работает преимущественно с сетевыми соединениями и транспортными параметрами. Такой подход подходит для приложений, где не требуется анализировать содержимое HTTP-запроса.
L7 дает возможность принимать решения с учетом прикладного протокола.
Например, запросы к разным URI одного сайта могут направляться на различные группы серверов. Это позволяет отделить обработку определенного типа контента или API от основной части приложения.
Выбор уровня зависит от архитектуры сервиса, требований к производительности и необходимой глубины обработки трафика.
Алгоритмы распределения соединений
Сам факт наличия нескольких серверов еще не определяет, как именно между ними будет распределяться нагрузка.
Один из классических алгоритмов - Round Robin. Новые соединения последовательно передаются серверам группы.
Другой вариант - Least Connections. При его использовании учитывается количество текущих активных соединений, и новое подключение направляется на сервер с меньшим их количеством.
Оба алгоритма поддерживаются Termidesk Connect. В актуальной документации также описан CONSISTENTHASHING для L7-балансировки, появившийся в версии 1.4.
Нельзя утверждать, что один алгоритм универсально лучше другого.
Если запросы имеют примерно одинаковую продолжительность и сложность, последовательное распределение может быть вполне эффективным. При сильно различающейся продолжительности соединений учет активных подключений способен дать более равномерный результат.
Оптимальный вариант определяют нагрузочным тестированием.
Проверка состояния серверов
Для обеспечения доступности недостаточно просто распределять соединения. Балансировщик должен понимать, способен ли конкретный сервер обслуживать пользователей.
Для этого применяются health checks - периодические проверки состояния.
Termidesk Connect поддерживает проверки с помощью ping, TCP, HTTP, HTTPS и пользовательских сценариев, позволяющих формировать логические комбинации условий.
Разница между видами проверок принципиальна.
Ответ на ping означает, что узел доступен на сетевом уровне, но не гарантирует работоспособность приложения.
TCP-проверка может подтвердить, что определенный порт принимает соединения.
HTTP-проверка позволяет обратиться непосредственно к веб-сервису и оценить его ответ.
Чем ближе проверка к реальному пользовательскому сценарию, тем точнее можно определить фактическую работоспособность сервиса. Но сложные проверки одновременно создают дополнительную нагрузку, поэтому их параметры необходимо выбирать рационально.
Автоматическое исключение неисправного узла
Представим группу из трех серверов. Один из них продолжает работать на уровне операционной системы, однако приложение на нем перестало отвечать.
Если балансировщик не контролирует состояние сервиса, примерно часть пользователей будет продолжать попадать на проблемный узел.
Health check позволяет обнаружить такое состояние и исключить сервер из обычного распределения соединений в соответствии с настроенной логикой.
После восстановления сервис снова может быть возвращен в рабочую группу.
Именно сочетание балансировки с контролем состояния серверов формирует основу локальной высокой доступности приложения.
При этом необходимо правильно подобрать интервал и тайм-аут проверок. Чрезмерно редкая проверка увеличивает время обнаружения отказа, а слишком агрессивные параметры способны приводить к ложному исключению сервера при кратковременной задержке.
Сохранение пользовательской сессии
Не каждое приложение одинаково работает при постоянном переключении пользователя между серверами.
Иногда после первого подключения требуется, чтобы последующие запросы того же клиента попадали на ранее выбранный сервер. Такой механизм называют persistence, или закреплением сессии.
В Termidesk Connect предусмотрены механизмы сохранения выбора сервера, в том числе с использованием параметров источника и cookie в соответствующих сценариях.
Persistence может быть необходим для приложений, хранящих состояние пользовательской сессии локально.
Однако с архитектурной точки зрения возможность свободно обслуживать пользователя на любом узле часто делает систему гибче. Поэтому вопрос закрепления следует решать с учетом особенностей самого приложения.
Важно также контролировать время жизни привязки. Слишком длительное закрепление способно ухудшить равномерность распределения нагрузки.
Content Switching и маршрутизация запросов
Балансировка L7 позволяет учитывать содержимое запроса.
В Termidesk Connect предусмотрено перенаправление трафика на разные группы серверов в зависимости от параметров запроса, источника, URI и других условий. Такой механизм обычно называют Content Switching.
Практический пример - разделение обычного веб-интерфейса и API.
Пользователь обращается к одному доменному имени, но запросы определенного типа передаются специализированной группе серверов.
Другой сценарий - постепенное внедрение новой версии приложения. Часть запросов может направляться в отдельную серверную группу по заранее установленным правилам.
Подобная маршрутизация делает ADC не просто распределителем соединений, а полноценным элементом архитектуры доставки приложений.
Чем сложнее правила, тем важнее документировать их и тестировать перед изменениями в промышленной среде.
SSL-терминирование
HTTPS обеспечивает шифрование трафика между клиентом и сервисом.
При большом количестве серверов управление сертификатами непосредственно на каждом узле может усложнять эксплуатацию. Одним из вариантов становится SSL-терминирование на ADC.
Termidesk Connect предусматривает соответствующую функциональность при работе в качестве шлюза.
В такой архитектуре защищенное клиентское соединение завершается на контроллере, после чего дальнейшая передача данных организуется согласно требованиям конкретной инфраструктуры.
Централизация позволяет упростить некоторые операции с сертификатами и обработкой HTTPS, однако требует особого внимания к безопасности самого ADC.
Если между балансировщиком и сервером передаются чувствительные данные, необходимо отдельно определить, требуется ли повторное шифрование внутреннего участка соединения.
HTTP-профили и работа с современным веб-трафиком
Современные приложения предъявляют более сложные требования к обработке HTTP, чем традиционные веб-сайты.
В Termidesk Connect 1.4 была добавлена поддержка HTTP/2 в серверном HTTP-профиле, а также мультиплексирование HTTP/1.1. Кроме того, разработчики добавили дополнительные параметры TCP-профилей и механизм перебалансировки HTTP. Версия 1.4.0 датирована 14 августа 2026 года.
Подобные функции имеют значение в высоконагруженных системах, поскольку эффективность использования соединений непосредственно влияет на задержки и потребление ресурсов.
Но результат зависит от приложения.
В одном проекте ограничивающим фактором является сеть, в другом - база данных, в третьем - вычислительные ресурсы серверов.
Поэтому настройку профилей желательно выполнять после измерения реальной нагрузки, а не только на основании теоретических преимуществ конкретного протокола.
Высокая доступность самого балансировщика
Балансировщик, установленный перед несколькими отказоустойчивыми серверами, сам может превратиться в единую точку отказа.
Если используется только один экземпляр ADC и он становится недоступен, пользователи теряют доступ к приложению независимо от состояния серверов.
Поэтому для критичных сервисов резервируют и уровень балансировки.
Termidesk Connect позволяет формировать HA-конфигурацию из двух или более узлов. Согласно документации версии 1.4, поддерживается до 255 узлов. В такой конфигурации предусмотрены синхронизация конфигураций, резервирование IP-адресов виртуальных серверов и переключение трафика между узлами при отказе одного из них.
Узлы объединяются в одноранговый кластер.
При проектировании важно учитывать, что отказоустойчивость ADC является лишь одной частью общей схемы: необходимо также резервировать сетевые соединения, коммутаторы и питание.
Обслуживание без остановки приложений
Отказоустойчивость нужна не только при авариях.
Инфраструктуру необходимо обновлять, а значит, периодически отдельные компоненты приходится выводить из эксплуатации.
В августе 2026 года был выпущен Termidesk Connect 1.4. Одним из направлений развития версии стало обслуживание HA-кластера с уменьшением необходимости прерывать доступность сервисов. Разработчик также сообщил об исправлениях в механизмах L4-балансировки, GSLB, TLS-сессиях и отказоустойчивых конфигурациях.
Для корпоративной среды возможность обслуживать узлы поочередно имеет существенное значение.
Однако перед обновлением промышленной системы все равно необходимы резервное копирование конфигурации, проверка совместимости и план возврата к предыдущей версии.
Отсутствие планового простоя не означает отсутствия необходимости в подготовке.
Географическая балансировка
Локальный балансировщик распределяет трафик между серверами одной инфраструктурной площадки.
Если организация использует несколько ЦОД, возникает задача более высокого уровня - определить, в какой центр обработки данных направить пользователя.
Termidesk Connect поддерживает геобалансировку, или GSLB. Она реализуется с использованием DNS-механизмов.
Допустим, компания располагает площадками в Москве и другом регионе. Для пользователя сохраняется единое доменное имя, однако система может выбирать подходящий ЦОД согласно настроенным правилам.
Такой подход применяется не только для распределения нагрузки, но и для георезервирования.
Если целая площадка становится недоступной, трафик может быть направлен к работоспособному центру обработки данных при условии, что само приложение и данные подготовлены к подобному переключению.
Почему одного GSLB недостаточно для катастрофоустойчивости
Наличие двух ЦОД и глобального балансировщика еще не означает полноценной катастрофоустойчивости.
Приложение на резервной площадке должно быть готово принять нагрузку.
Особенно сложен вопрос данных. Если пользователь перенаправлен во второй ЦОД, но там отсутствует актуальная база данных, доступность сетевого уровня не решает проблему.
Поэтому GSLB является только одним из компонентов георезервирования.
Дополнительно проектируются репликация данных, резервирование приложений, сетевые каналы, DNS-инфраструктура и процедура переключения.
Для каждой информационной системы необходимо определить RTO - допустимое время восстановления, и RPO - допустимую потерю данных во времени.
Только после этого можно оценить, какая схема географического резервирования действительно соответствует бизнес-требованиям.
Защита и аутентификация
ADC находится непосредственно на пути пользовательского трафика, поэтому логично использовать его для выполнения части функций контроля доступа.
Документация Termidesk Connect указывает поддержку LDAP/LDAPS, аутентификации с использованием клиентского сертификата и комбинирования методов. Также заявлены ролевая модель доступа и механизмы защиты от DoS.
Кроме того, возможны операции с HTTP-заголовками: добавление, удаление и изменение в соответствии с политиками.
Эти возможности позволяют интегрировать балансировщик в общую архитектуру безопасности.
Но ADC не следует автоматически считать заменой всем специализированным средствам защиты.
Необходимый набор защитных компонентов определяется моделью угроз, категорией информационной системы, типом публикуемых приложений и требованиями организации.
Режим RAPID
Для сценариев, в которых приоритетом является скорость обработки трафика, в Termidesk Connect предусмотрены режимы RAPID-TCP и RAPID-UDP.
Документация отмечает, что RAPID ориентирован на высокую производительность. Одновременно у подхода есть функциональные ограничения: в частности, отсутствует возможность влиять на данные приложения и не поддерживаются SSL-профили.
Это характерный пример компромисса между производительностью и глубиной обработки трафика.
Если требуется анализ HTTP, изменение заголовков или сложная прикладная маршрутизация, необходим более высокий уровень обработки.
Если же задача заключается прежде всего в быстром распределении большого количества сетевых соединений, более простой путь обработки может оказаться предпочтительным.
Поэтому режим выбирается не по принципу "самый быстрый", а исходя из требований приложения.
Управление и автоматизация
Корпоративный сетевой компонент должен быть удобен не только для первоначальной настройки, но и для дальнейшей эксплуатации.
Termidesk Connect поддерживает управление через веб-интерфейс и командную строку, а также предоставляет API и NETCONF.
Графический интерфейс удобен при ручной настройке и анализе отдельных объектов.
Командная строка востребована у опытных администраторов и при диагностике.
API позволяет интегрировать управление ADC с внешними системами автоматизации.
NETCONF применяется для программного управления конфигурацией сетевых устройств и может быть полезен в инфраструктурах, где изменения выполняются централизованными средствами.
Чем больше количество виртуальных сервисов и серверных групп, тем важнее автоматизация. Ручное изменение десятков однотипных настроек повышает вероятность человеческой ошибки.
Мониторинг и статистика
Балансировщик находится в удобной точке для сбора информации о соединениях, поскольку через него проходит клиентский трафик.
Termidesk Connect предусматривает сбор статистических данных о подключениях и возможность отправки информации во внешние системы, включая Syslog/JSON в соответствующих сценариях.
Такие данные полезны для анализа нагрузки и расследования инцидентов.
Однако мониторинг ADC желательно объединять с наблюдением за серверами приложений, базами данных и сетевой инфраструктурой.
Например, рост времени ответа может быть виден на балансировщике, но его причиной окажется медленный запрос к СУБД.
Поэтому для диагностики необходимо сопоставлять показатели нескольких уровней.
Балансировщик показывает важную часть картины, но не всю информационную систему.
Где может применяться Termidesk Connect
ADC востребован прежде всего там, где приложение обслуживается несколькими серверами либо должно работать с повышенными требованиями к доступности.
Типичные сценарии включают корпоративные веб-системы, внутренние порталы, API, системы удаленного доступа и другие сетевые сервисы.
В материалах разработчика среди задач Termidesk Connect названы разгрузка высоконагруженных веб-приложений, обработка большого количества транзакций, построение географически распределенной архитектуры и контроль доступности балансируемых сервисов.
Решение также может использоваться совместно с инфраструктурой виртуальных рабочих мест. В документации Termidesk VDI прямо отмечено, что встроенного балансировщика в VDI нет и для этой задачи может применяться внешний балансировщик, соответствующий среде интеграции, например Termidesk Connect.
При этом область применения продукта не ограничивается VDI.
Как проектировать схему балансировки
До установки ADC необходимо описать приложение и его сетевые зависимости.
Сначала определяют, сколько серверов предоставляет сервис и способны ли они обслуживать одинаковые запросы.
Затем анализируют протоколы: TCP, HTTP, HTTPS, WebSocket или другие варианты.
Следующий вопрос - состояние пользовательской сессии. Если приложение хранит его локально, может потребоваться persistence.
После этого определяются проверки доступности. Желательно, чтобы health check отражал реальную готовность приложения обслуживать пользователей.
Далее выбирается алгоритм распределения нагрузки и рассчитывается необходимая производительность самого ADC.
Для критичных систем отдельно проектируется HA-кластер балансировщиков.
Если используется несколько ЦОД, добавляются GSLB и механизм синхронизации данных между площадками.
Такой последовательный подход значительно надежнее, чем установка балансировщика без предварительного анализа архитектуры приложения.
Нагрузочное тестирование
После настройки систему необходимо проверить в условиях, максимально приближенных к реальной эксплуатации.
Тестирование должно отвечать на несколько вопросов.
Какое количество соединений способна обработать инфраструктура? Как изменяется время ответа при росте нагрузки? Что происходит при отключении одного сервера? Как быстро health check обнаруживает проблему? Продолжают ли существующие пользовательские сессии работать после переключения?
Отдельно тестируют отказ самого узла Termidesk Connect при использовании HA-конфигурации.
Для географической схемы моделируется потеря целого ЦОД.
Паспортная производительность оборудования или программного решения не заменяет подобные испытания, поскольку реальный результат зависит от протоколов, шифрования, правил L7, характеристик приложения и сетевой топологии.
Выбор программного или аппаратного форм-фактора
В материалах Termidesk Connect указывается возможность выбора программного или аппаратного варианта решения.
Программный формат удобен в виртуализированных средах, где инфраструктурные сервисы требуется развертывать без добавления отдельного физического устройства.
Аппаратный вариант может использоваться там, где организация предпочитает выделенное оборудование или предъявляет соответствующие требования к архитектуре.
Сам по себе форм-фактор не определяет качество балансировки.
При выборе важнее сопоставить производительность, отказоустойчивость, способ резервирования, особенности сетевого подключения и предполагаемый объем трафика.
Необходимо учитывать и перспективу роста, поскольку нагрузка через несколько лет может значительно отличаться от первоначальной.
Место Termidesk Connect в ИТ-инфраструктуре
Termidesk Connect следует рассматривать не как самостоятельное приложение для конечного пользователя, а как инфраструктурный компонент.
Пользователь может вообще не знать о его существовании. Он вводит привычный адрес корпоративного сервиса, а распределение соединения выполняется автоматически.
За этим внешне простым процессом может находиться группа серверов, несколько ЦОД, проверки доступности, правила L7 и механизмы сохранения сессий.
Актуальная документация Termidesk Connect версии 1.4 подробно описывает архитектуру, локальную и географическую балансировку, управление трафиком и HA-конфигурации.
Поэтому при оценке решения полезно ориентироваться не только на перечень возможностей, но и на конкретный сценарий внедрения, поддерживаемые версии и эксплуатационную документацию.
Заключение
Termidesk Connect - решение класса Application Delivery Controller, предназначенное для балансировки нагрузки, повышения доступности приложений и управления доставкой сетевого трафика. Оно располагается между пользователями и серверами и позволяет распределять соединения между несколькими узлами, проверять их состояние и исключать недоступные серверы из обслуживания.
В зависимости от задачи Termidesk Connect может выполнять функции шлюза, локального балансировщика или глобального балансировщика для нескольких центров обработки данных. Поддерживаются балансировка L4 и L7, разные алгоритмы распределения нагрузки, persistence, Content Switching, проверки состояния серверов, SSL-терминирование и механизмы географической балансировки.
Для критически важных систем принципиально значение имеет отказоустойчивость самого ADC. Termidesk Connect позволяет объединять несколько узлов в HA-конфигурацию с синхронизацией части настроек, резервированием адресов виртуальных серверов и переключением трафика при отказе.
Однако балансировщик не делает приложение отказоустойчивым автоматически. Серверная часть должна поддерживать работу нескольких экземпляров, данные - синхронизироваться в соответствии с требованиями проекта, а сеть и электропитание - не содержать непредусмотренных единых точек отказа. Для географического резервирования дополнительно требуется подготовленная инфраструктура второго ЦОД.
Поэтому Termidesk Connect правильнее рассматривать как один из ключевых элементов комплексной архитектуры высокой доступности. Его возможности позволяют централизовать прием трафика, распределять его между серверами и площадками и автоматизировать реакцию на недоступность отдельных узлов. Итоговая надежность сервиса при этом определяется тем, насколько грамотно спроектирована вся цепочка - от клиентского подключения и балансировщика до приложения, базы данных и резервной площадки.