Когда в компании растёт число пользователей 1С, рано или поздно встаёт вопрос: держать «толстый» клиент 1С на каждом компьютере с прямым подключением к базе — или вынести всё на сервер и раздать на места тонкий клиент. Второй путь давно стал стандартом для бухгалтерии, складов и филиалов. Разберём, как собрать тонкий клиент для 1С на российской платформе виртуализации — на примере Inscale — и почему уход Citrix этому не помеха.
1С — это централизованная многопользовательская система: общая база, десятки и сотни одновременных сессий, критичные расчёты по зарплате, складу, закрытию периода. Когда такие нагрузки размазаны по «толстым» клиентам на местах, начинаются классические боли: тяжёлые обновления на каждой машине, риск утечки данных с конечных ПК, тормоза филиалов на слабом канале.
Решение — терминальный доступ: 1С запускается на сервере (или ферме серверов), а на рабочие места ставится тонкий клиент, который держит сессию и показывает только «картинку». Обновили один раз на сервере — обновилось у всех; данные не покидают ЦОД; на местах хватает дешёвого железа. Годами этот сценарий строили на Citrix и Microsoft RDS. После ухода Citrix из России вопрос только в том, на чём собирать тонкий клиент для 1С теперь.
Сам тонкий клиент ничего не считает — он лишь держит сессию до сервера, где работает 1С, и отрисовывает рабочий стол или опубликованное приложение. Платформа отдаёт его по собственному протоколу доставки удалённых рабочих мест; поддерживается и режим RDSH для классического терминального доступа. Для пользователя 1С выглядит привычно, но вся вычислительная нагрузка остаётся на сервере. Базовый сценарий «1С без потери скорости» мы уже разбирали в статье VDI для 1С — здесь идём глубже, в реальные узкие места.
«У нас в филиале интернет еле дышит, 1С по терминалу не потянет» — самое частое возражение. На практике узкое место не в самой идее тонкого клиента, а в протоколе доставки.
Показательный — именно как крайний, исключительный случай — кейс из банковской практики: бэк-офис крупного банка в удалённом северном регионе, где 15 сотрудников сидели на одном канале в 1 Мбит/с и плотно работали с тяжёлыми финансовыми таблицами и базами. Это профиль нагрузки, близкий к многопользовательской 1С. Стандартный протокол «из коробки» убил бы такой канал в первую секунду. За счёт тонкой настройки протокола (а в нём 27 параметров — компрессия, динамические цвета, лимит FPS, интеллектуальное масштабирование разрешения) инженеры ужали потребление одного рабочего места до 50 кбит/с. Важно понимать: это был предел возможностей и исключение из правил, а не штатный режим — комфортная работа начинается примерно от 100 кбит/с. Но именно такой экстремальный случай показывает запас по оптимизации.
Почему вообще возможны такие цифры — это не «магия драйвера». В основе протокола лежит алгоритм компрессии и передачи данных, который разрабатывался под высоконагруженные научные задачи — именно под передачу больших объёмов данных по узким и нестабильным каналам. То есть экономия канала — не маркетинговая надстройка, а ядро технологии, изначально заточенное под передачу больших объёмов данных по узким каналам.
Вывод для 1С прямой: если протокол вытягивает 1С-подобную нагрузку даже в таких жёстких условиях, то на нормальных филиальных каналах тонкий клиент для 1С работает без вопросов — там, где толстый клиент 1С с прямым подключением к базе уже начинает спотыкаться. Подробный разбор низкоскоростного сценария — в статье VDI при плохой связи.
1С прожорлива в пики: закрытие месяца, расчёт зарплаты, инвентаризация. Чтобы сессии не отбирали ресурсы друг у друга, на платформе есть несколько рычагов:
- Два режима балансировки — производительности и плотности. В первом каждой ВМ с 1С гарантируются её ресурсы с минимальной переподпиской; во втором сессии плотно «утрамбовываются» на меньшем числе серверов под реальную, а не пиковую утилизацию.
- Тонкое управление через cgroups — каждой машине нарезается ровно её пул, вплоть до доли гигагерц, чтобы «тяжёлая» 1С не положила соседей. Как это работает — в материале про управление ресурсами через cgroups.
- Ресурсные пулы поверх стандартной переподписки — для приоритезации критичных баз.
Простой 1С в день закрытия периода — это прямые деньги. Отказоустойчивость на платформе работает на уровне гипервизора: при отказе узла пользовательские ВМ (в том числе с 1С) автоматически перезапускаются на живых хостах, а независимый HA-контроллер рассчитан на удержание системы даже при потере центра управления и в сценарии Split-Brain. Как устроена эта живучесть — в разборе отказоустойчивого кластера.
В 1С хранятся персональные данные, финансы, коммерческая тайна, поэтому безопасность тонкого клиента критична. Платформа построена по принципу «не доверяй никому»: внешних пользователей встречает шлюз, который по своим функциям соответствует полноценному NGFW; до прохождения авторизации во внутреннюю сеть нет доступа — закрыты даже сетевые порты узлов; пользователи и администраторы заходят через разные порты. Ядро защищено по стандартам ФСТЭК — это важно для бухгалтерии под 152-ФЗ и для госсектора (см. требования приказа ФСТЭК №117). Пользователи 1С при этом заводятся из существующего каталога — поддерживаются Active Directory, FreeIPA и OpenLDAP «из коробки».
Платформа — прямая российская альтернатива VMware и Citrix, входит в реестр отечественного ПО. И это важно: не «обёртка» над стандартными open-source-компонентами. Ядро KVM глубоко переработано и пропатчено, от Libvirt разработчики отказались ещё в 2019-м (после работы с T-Mobile и Vodafone) и переписали Control Level, работу с памятью, проброс устройств и High Availability на собственном проприетарном коде. Для замены Citrix это значит, что вы получаете не косметику поверх чужого ядра, а самостоятельную инженерную платформу, кодовой базой которой владеет вендор. При этом гипервизор первого типа ставится прямо на «голое железо» и способен работать даже на одной ноде с локальными дисками — без дорогостоящих СХД, что снижает порог входа для небольших 1С-инсталляций.
По скорости развёртывания и масштабу показателен кейс крупного заказчика: VDI на 1500 рабочих мест (кластер из 11 серверов) развернули за полтора дня. Для парка терминальных мест 1С это означает, что переезд с Citrix — вопрос дней, а не кварталов. Пошаговый план — в гайде по миграции с Citrix на российское VDI.
Тонкий клиент для 1С — это вынос многопользовательской 1С на сервер с доставкой рабочего стола на лёгкие клиенты: проще обновлять, безопаснее, дешевле на местах. Российская VDI-платформа закрывает все болевые точки 1С: уверенно работает в филиалах на слабом канале (а в экстремальном случае протокол вытягивал нагрузку даже на 50 кбит/с — как исключение, демонстрирующее запас), точно делит ресурсы между сессиями, держит отказоустойчивость бухгалтерии, защищает данные по ФСТЭК и заменяет ушедший Citrix. О том, из чего вообще состоит такая платформа, — в разборе российской системы виртуализации. Хотите посмотреть тонкий клиент для 1С на вашем сценарии — запросите демо-доступ.
