Толстый и тонкий клиент в 1С: в чем разница для терминального сервера

Представьте: вы подняли RDS-ферму, завели на неё 30 пользователей 1С, всё работает — и вдруг в часы пик сервер начинает захлёбываться. CPU под 90%, пользователи жалуются на лаги, а вы смотрите в диспетчер задач и не понимаете, почему машина с 64 ГБ оперативки не справляется с бухгалтерией. Скорее всего, дело не в железе. Дело в том, какой клиент 1С вы поставили на терминал.

Толстый и тонкий клиент — это не просто названия разных инсталляторов. Это принципиально разные архитектурные решения, которые по-разному ведут себя в терминальных средах. И если не разобраться в этом до развёртывания, потом будете докупать RAM и гадать, почему не помогает.

Как устроены оба режима

Ключевое различие — где выполняется бизнес-логика. Толстый клиент берёт на себя до 80% вычислений прямо на клиентской машине (или на терминальной сессии — в RDS это одно и то же). Тонкий клиент, появившийся в платформе 8.2, делегирует 90–95% логики серверу 1С, а сам занимается только отрисовкой интерфейса и передачей пользовательских действий.

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

Ещё один важный нюанс: тонкий клиент работает только с клиент-серверной архитектурой 1С — PostgreSQL или MS SQL в роли СУБД. Файловая база — исключительно толстый клиент. Если у вас ещё живёт файловая база на 20+ пользователей в RDS — это отдельный разговор, и начинается он с миграции на клиент-сервер, а не с выбора режима запуска.

Цифры по масштабируемости — не теоретические. При грамотной настройке сервера 1С и достаточном объёме RAM тонкий клиент реально позволяет держать 100+ активных сессий на одном хосте без заметной деградации. Разница в пять-шесть раз по плотности пользователей напрямую влияет на стоимость инфраструктуры — и на то, сколько серверов вам придётся купить.

Что происходит в терминальной сессии

Когда пользователь открывает 1С через RDP, его сессия — это виртуальный рабочий стол на сервере. Толстый клиент в этой сессии ведёт себя ровно так же, как на физической машине: грузит отчёты локально (то есть на CPU сервера), кэширует данные в памяти сессии, обращается к базе напрямую.

Теперь умножьте это на 30 пользователей. Каждый открыл оборотно-сальдовую ведомость за квартал — и сервер одновременно обрабатывает 30 тяжёлых запросов прямо в оперативной памяти сессий. Никакое железо не спасёт, если архитектура не рассчитана на такой сценарий. Отсюда и 90% CPU при, казалось бы, нормальных характеристиках хоста.

Тонкий клиент в той же ситуации отправляет запрос на сервер 1С (отдельный процесс — rphost), тот обрабатывает его централизованно с использованием серверного кэша и возвращает клиенту только готовый результат. Нагрузка на терминальный хост — минимальная. Сервер 1С может быть отдельной машиной — это полностью снимает вычислительную нагрузку с RDS-хоста.

Есть ещё момент, который часто упускают: сетевой трафик внутри фермы. Толстый клиент гоняет данные между базой и сессией в сыром виде — таблицы, объекты, регистры. Тонкий 1С клиент передаёт только управляющие команды и готовые результаты. Экономия трафика на ферме из 50 пользователей составляет 50–70%, что ощутимо даже при гигабитном линке между хостами — особенно если серверы стоят в разных стойках.

Безопасность и данные

Тонкий клиент в терминальной среде выигрывает принципиально — особенно если в компании есть BYOD или удалённые пользователи. Вся бизнес-логика и данные находятся исключительно на сервере 1С. На терминальной сессии хранится только состояние интерфейса. Даже если пользователь работает с личного ноутбука через RDP — он видит только экран, данные физически никуда не уходят с периметра компании.

Толстый клиент кэширует часть данных локально — внутри сессии. При компрометации сессии (перехват RDP-трафика, уязвимость в хосте) эти данные потенциально доступны злоумышленнику. Для оффлайн-аудита иногда удобно, но с точки зрения ИБ-политики и требований регуляторов — дополнительный риск, который нужно закрывать отдельными инструментами. Если инфраструктура готовится к проверке, стоит заранее разобраться, как подготовить серверную инфраструктуру к ИБ-аудиту.

Деплой и обслуживание

Это тема, которую часто недооценивают при выборе архитектуры — и потом жалеют. Толстый клиент нужно ставить на каждую машину или сессию отдельно, следить за синхронизацией версий платформы со стороны сервера 1С. Рассинхронизация версий — распространённая причина загадочных ошибок подключения, которые потом несколько часов разбирают в поддержке.

Тонкий клиент в терминальной ферме разворачивается один раз на хосте. Обновление платформы — одна операция, которая сразу применяется ко всем сессиям. Через GPO и MSI-пакет это делается примерно за час на 50 машин. Без ручной беготни по рабочим местам, без рассинхронизации версий, без звонков "у меня 1С не открывается" на следующий день после обновления.

Для Proxmox-кластеров или гибридных RDS-ферм централизованный деплой — стандартная практика, которая экономит часы работы при каждом релизе платформы. Если добавить к этому автоматизацию через Ansible или скрипты PowerShell для управления сессиями — обслуживание фермы на 100+ пользователей превращается из рутины в набор повторяемых процедур.

Когда толстый клиент всё-таки нужен

Было бы нечестно говорить, что тонкий клиент — универсальный ответ. Есть сценарии, где толстый незаменим.

Разработка и тестирование конфигураций — первый и главный. Конфигуратор в полном объёме работает только в толстом клиенте. Если вы пишете или дорабатываете конфигурацию, отлаживаете обмены, работаете с внешними обработками в режиме разработчика — без него не обойтись. Для таких задач имеет смысл держать отдельную изолированную сессию или виртуалку с толстым клиентом, не смешивая с пользовательской фермой.

Нестабильный канал связи — второй сценарий. Толстый клиент на файловой базе продолжает работу при обрыве сети. Тонкий — нет, сессия падает. Для пользователей с нестабильным VPN или в филиалах с плохим интернетом это реальное ограничение. Если канал рвётся по три раза в день, тонкий клиент через RDS — не лучший выбор для этой точки.

Третий сценарий — массовые операции загрузки и обработки данных. Загрузка прайс-листов, обмен с внешними системами, групповая переработка документов — здесь толстый клиент обрабатывает данные локально, убирая сетевые задержки. Это актуально прежде всего для файловых баз; в клиент-серверной архитектуре разница нивелируется серверным кэшем 1С.

Разумный подход для крупных инсталляций — гибрид: тонкий клиент для большинства пользователей (бухгалтеры, менеджеры, операционисты), толстый — для разработчиков и администраторов 1С в отдельных, изолированных сессиях с соответствующими ресурсами.

Требования к серверу 1С в терминальной среде

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

Ниже — ориентиры по железу для сервера 1С при 50+ пользователях в тонком режиме. Если вы ещё на этапе выбора конфигурации, рекомендуем сначала изучить идеальную конфигурацию терминального сервера для 1С:

• CPU: минимум 8 физических ядер, рекомендуется 16+. Сервер 1С плохо масштабируется горизонтально на уровне одного кластера, поэтому частота ядер важнее их количества — смотрите в сторону процессоров с высоким base clock: Xeon Gold или EPYC серии 7003.
• RAM: 32 ГБ для 50 пользователей — стартовая точка. При активной работе с тяжёлыми отчётами и OLAP-запросами — 64 ГБ и выше. Серверный кэш 1С живёт в памяти, и его нехватка сразу чувствуется на времени открытия отчётов.
• Дисковая подсистема: SSD или NVMe без компромиссов. Серверный кэш 1С и журналы транзакций СУБД активно работают с диском. HDD здесь — прямой путь к деградации под нагрузкой, особенно в часы пик.
• Сеть: гигабитный линк между сервером 1С и терминальным хостом — базовый минимум. При 100+ активных сессиях разумно рассмотреть 10GbE, особенно если база и сервер приложений разнесены по разным узлам.

Мониторинг через Zabbix для таких конфигураций — не опция, а стандарт. Метрики нагрузки на rphost-процессы, объём рабочих процессов кластера 1С, время выполнения серверных вызовов, очереди на сервере СУБД — всё это позволяет обнаружить узкое место раньше, чем пользователи начнут звонить. Реагировать на жалобы всегда дороже, чем предотвращать деградацию проактивно.

Куда движется платформа

Платформа 8.3 принесла веб-клиент — следующий шаг после тонкого. Он работает в браузере, не требует установки клиентской части вообще и хорошо подходит для удалённых филиалов и мобильных пользователей. Нагрузка на терминальный хост — практически нулевая, всё уходит на сервер 1С и веб-сервер (Apache или IIS). Терминальный доступ как таковой уходит из уравнения.

Для новых инсталляций вопрос "толстый или тонкий" всё чаще дополняется третьим вариантом: а может, сразу веб-клиент? Если конфигурация поддерживает управляемые формы (а всё написанное после 2012 года их поддерживает) — этот вопрос стоит задать себе до начала развёртывания. Веб-клиент снимает вопрос терминального доступа как такового: пользователь работает через браузер, а вы управляете только сервером 1С и веб-сервером.

RDP-сервер для 1С останется актуальным ещё долго — не все конфигурации готовы к веб-клиенту, не у всех есть инфраструктура и компетенции для его поддержки. Но вектор понятен: чем меньше логики на клиенте, тем проще управлять инфраструктурой в масштабе. Тонкий клиент — нормальная инженерная архитектура для большинства production-сред прямо сейчас. Веб-клиент — следующая итерация, которая уже доступна.

Вопрос только в том, когда ваша конфигурация будет к ней готова.