RDP или локальный клиент 1С: что проверить до выбора

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

Чем RDP отличается от локального тонкого клиента 1С

В локальной схеме тонкий клиент запускается на компьютере пользователя и соединяется с информационной базой по поддерживаемому платформой способу. В варианте RDP пользователь сначала подключается к удалённому рабочему столу, а клиент 1С запускается уже на сервере сеансов. Для клиент-серверной базы отдельно работают кластер 1С и СУБД. Это не «один сервер вместо двух»: у каждой части своя нагрузка, журналы и причины задержек. Официальное описание платформы показывает тонкий клиент как отдельное клиентское приложение, а руководство по развертыванию — его подключение к кластеру 1С. Поэтому сравнивать нужно целые схемы, а не слово «тонкий» с буквами RDP. В технической схеме также укажите, где установлены тонкий клиент и драйверы печати: это быстро снимает путаницу при обращении в поддержку.

В RDP центральный сервер действительно выполняет работу настольных приложений и формирует удалённый сеанс; локальный компьютер выполняет работу своего клиента. Но из этого не следует, что RDP всегда медленнее или обязательно требует больше ресурсов в любом конкретном проекте. Имеют значение конфигурация, число одновременных сеансов, объём отчётов, профиль пользователя, графика и печать. Я сравниваю один и тот же набор операций в обеих схемах: вход, открытие нужной формы, формирование отчёта, проведение документа и печать. Иначе мы меряем впечатления, а не систему. Для предварительной оценки инфраструктуры обсудим размещение 1С, но решение всё равно должно опираться на ваш сценарий. В локальном варианте это не означает, что вся обработка происходит на ПК: в клиент-серверной базе существенная серверная работа остаётся на стороне кластера и СУБД. И наоборот, терминальный узел не заменяет сервер 1С. В схеме полезно прямо подписать, где запускается каждый компонент, чтобы не искать тормоза «на сервере вообще».

Как оценить нагрузку до выбора терминального сервера

В исходном черновике фигурировали 21 место, до 2 ГБ памяти на сеанс, 90 % CPU и затем 40 % CPU после смены схемы. Подтверждающих замеров, конфигурации оборудования, версии платформы и сценария нагрузки нет, поэтому эти цифры нельзя публиковать как результат реального проекта. Вместо легенды про «один удачный переезд» я предлагаю измеримый план. Сначала фиксируем число одновременно работающих людей и их типовые операции, затем повторяем одинаковый сценарий на локальном клиенте и через RDP. Записываем время отклика, загрузку CPU и памяти на терминальном сервере, кластере и СУБД, дисковую задержку и сетевые ошибки. Сравниваем одинаковые часы и одинаковый набор действий. Для каждого прогона запишите дату, версию платформы и конфигурации, число активных сеансов и точку запуска клиента. Без этих условий даже аккуратная таблица метрик превращается в несопоставимый набор чисел.

Для примера можно взять условный центр геодезических работ «Меридиан-ось» из исходного описания, но не приписывать ему несуществующие результаты. Пусть там жалуются на открытие картотеки и печать планов: сначала нужно выяснить, медленно ли открывается сама форма, ждёт ли запрос базу, строится ли отчёт на сервере или очередь печати задерживает задание. Профиль сеанса тоже учитывают по фактическому потреблению, а не по усреднённой цифре из чужого кейса. После измерений делают пилот на нескольких рабочих местах, проверяют обычный и пиковый день и только затем считают ресурсы для всех пользователей. Сервер не обязан быть мощным «на всякий случай»; он обязан выдерживать измеренную нагрузку с запасом на рост. Для удалённых пользователей отдельно учитывайте качество канала до RDP-узла и от него к кластеру. Высокая задержка на одном участке не доказывает нехватку CPU на другом. Зафиксируйте контрольное время хотя бы для нескольких одинаковых действий и повторите тест в то же время суток; замер без исходного состояния сравнивать не с чем. Если нужна диагностика размещения или обновления платформы, используйте настройку сервера 1С как отдельную задачу, а не как магическое лечение любой паузы.

• Повторить один сценарий в обеих схемах.
• Снять метрики клиента, RDS, кластера 1С и СУБД.
• Проверить печать и периферийные устройства.
• Провести пилот в период обычной нагрузки.

Какие лицензии проверить для 1С и RDS

Здесь часто смешивают два независимых набора прав. Для подключения к Windows Server через Remote Desktop Services нужны подходящие RDS CAL — на пользователя или на устройство. Microsoft описывает выбор модели в зависимости от того, кто и с каких устройств работает. Режим «На пользователя» не ограничивает число подключений с одного устройства: лицензия назначается пользователю, который может заходить с разных устройств. В рабочей группе Microsoft требует модель Per Device; для Per User нужны соответствующие условия доменной среды. Поэтому фраза «выберите На пользователя, чтобы ограничить подключения с одного компьютера» неверна. Проверяйте тип CAL, версию сервера, модель развертывания и фактический состав пользователей. Отдельно сверяйте условия лицензии с фактическим способом доступа, включая публикацию приложений и удалённые сеансы; один и тот же сценарий могут оценивать сразу по нескольким договорам.

Лицензии платформы 1С — отдельный вопрос. Наличие RDS CAL не даёт права на клиентские лицензии 1С, и наоборот. До установки проверьте договоры и комплект поставки 1С, количество одновременно работающих клиентов, способ установки программных или аппаратных лицензий и правила конкретного продукта. Не универсализируйте совет «все лицензии ставятся только на терминальный сервер»: схема зависит от типа лицензии и конфигурации. В статье нельзя обещать, что одна лицензия 1С делится между несколькими людьми или что превышение само по себе «роняет RDP-сессии». Если лицензия не находится или достигнут лимит, фиксируйте текст ошибки и проверяйте распределение лицензий по документации 1С и условиям правообладателя. Для RDS нужна также настроенная роль лицензирования и выбранный режим на узле сеансов. Полезно не смешивать число заведённых учётных записей, число выданных лицензий и число одновременных подключений: это разные величины. По Microsoft Per User CAL назначается пользователю и может использоваться с разных устройств, а Per Device CAL относится к устройству; лицензии должны соответствовать версии Windows Server и условиям договора. Отчёт лицензирующего сервера помогает контролировать выдачу, но сам по себе не заменяет проверку прав организации.

Как проверить печать, профили и завершение сеансов

Печать в RDP не требует автоматически ставить универсальный драйвер всем подряд. Сначала выясните, включено ли перенаправление клиентских принтеров, допускает ли его политика организации, поддерживается ли конкретный принтер и как ведёт себя очередь при печати из нужной конфигурации. Microsoft документирует перенаправление как настраиваемую функцию сеанса; итоговое поведение зависит от политик. Для проверки распечатайте контрольный документ и план, сравните поля, шрифты, масштаб и время появления задания. Если печать нестабильна, проверяйте драйвер и очередь на сервере, клиенте и принт-сервере по цепочке. Не меняйте драйверы в рабочий день методом «а вдруг этот заработает»: это распространённый способ получить сразу несколько версий одной проблемы. Зафиксируйте, кто отвечает за очередь и драйвер: локальный пользователь, администратор RDS или специалист по печати. У общей жалобы часто несколько владельцев, а без этого задания ходят по кругу.

Профили пользователей и отключение неактивных сеансов настраивают исходя из сценария, а не ради красивого списка в консоли. Сначала определите, где хранятся настройки приложения и пользовательские данные, сколько места им нужно и что происходит при разрыве соединения. Затем проверьте вход нового пользователя, повторный вход, восстановление после обрыва и доступ к нужным папкам и устройствам. Тайм-ауты должны соответствовать регламенту работы: слишком короткий срок прервёт долгий отчёт, слишком длинный оставит ненужную сессию. Перед автоматическим завершением объясните пользователям, что сохранять документы нужно в самой 1С; завершение сеанса не заменяет сохранение данных и резервное копирование. Для проверки документации Microsoft используйте её именно для настроек Windows, а не как источник правил лицензирования 1С. Аналогично, условия поставки 1С не отвечают на вопрос, разрешено ли перенаправление принтера политикой Windows. Когда проблема появляется только у одного пользователя, сравните его профиль, назначенную очередь и настройки клиентского устройства с рабочим примером; так причина обычно локализуется быстрее, чем массовая переустановка клиента.

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

Как выбрать схему и не купить лишнее оборудование

Локальный тонкий клиент удобен, когда рабочие места можно централизованно поддерживать, пользователи работают на подходящих компьютерах, а печать и периферия исправны. RDP полезен, когда приложения и данные нужно держать в централизованной среде, клиентские устройства разнородны или требуется единая точка обслуживания. Это не рейтинг победителей. У RDP есть стоимость Windows Server, RDS CAL, ресурсов сеансового узла и сопровождения; у локальной схемы — требования к рабочим местам, обновлениям и поддержке клиентов. Сравнивайте полную стоимость владения, включая лицензии и обслуживание, и не записывайте стоимость пользовательских компьютеров в ноль только потому, что они уже стоят в офисе. В протоколе решения перечислите ответственного за обновление клиентов, резервное копирование и мониторинг. Это не бюрократия ради подписи: через месяц именно эти обязанности определят, останется ли пилот управляемым.

В клиент-серверной архитектуре 1С кластер содержит рабочие серверы и рабочие процессы; официальная документация описывает их распределение и настройку. При этом добавление процессов или второго узла само по себе не гарантирует ускорение: сначала выясняют, что ограничивает конкретную операцию, а потом меняют конфигурацию и повторяют тест. Я бы оформил решение коротким протоколом: исходные условия, схема подключения, лицензии, результаты замеров, проблемы печати и план отката. Для терминального варианта добавьте порядок восстановления профиля и узла сеансов. Для локального — порядок обновления тонкого клиента. Такой документ полезнее обещания «после переноса всё полетит». Ирония короткая: сервер не читает коммерческое предложение и не знает, что он должен летать. В RDP полезно отдельно проверить временный профиль Windows: если после входа пропадают настройки, это уже не симптом медленной базы. Для такой диагностики пригодится разбор временного профиля Windows. Если же отчёт долго формируется у всех, сопоставьте время выполнения и загрузку рабочих процессов кластера; ориентир по метрикам есть в материале о мониторинге сервера 1С.

• Сравнить одинаковые операции и нагрузку.
• Учесть лицензии обеих платформ.
• Проверить печать и периферию.
• Зафиксировать план пилота и отката.

Частые вопросы