Терминальный сервер 1С или локальные версии?

Question

[N M]

Здравствуйте.

Исходные данные:
Сервер 1С предприятие с поднятым hyper-v ( E5-2667 v4 + 64 gb RAM)
MsSQL
Кол-во пользователей 7-9

Нужно ли поднимать терминальный сервер, при каких обстоятельствах он будет оправдан?
Или же ограничиться локальными версиями 1с на компьютерах у пользователей?

Answer 1

[AntHTML]

Зависит от ситуации. Что выгоднее гонять траффик по SQL или по RDP. Иногда при тяжелых базах бывает выгоднее организовать скоростное соединение между ТС и СБД, иногда и ЛВС это нормально вывозит. При до 10-15 юзерах, особенно на 1м свиче смысла нет, а если все на vpn или тп, то можно пропробывать

Comments

[nApoBo3]

Насколько я понимаю, при наличии сервера 1С Предприятия подключается к базе сам сервер, а не клиентское ПО. В таком сценарии использование RDP имхо не имеет смысла.

[AntHTML]

nApoBo3, сервер 1С это такая как бы прослойка.
Ну т.е. как бы да, он выполняет часть работы за сервер терминалов, производит некоторые операции и подготавливает данные для клиентов, а также сам обращается с СБД
Но всеравно остается вопрос что выгоднее гонять: данные между сервером и клиентом 1С по сети или гнать по сети картинку рабочего стола, а сервер и клиент 1С ставить на соседних машинах в серверной
В крупных организациях это может быть актуально, т.к. юзеры активно работающие с тяжелыми базами и файлами могут находиться далеко от сервера на не лучших каналах. И там иногда становится выгоднее прислать юзеру просто картинку, чем гнать весь поток данных туда-обратно.
В мелких - смысла нету: там базы не такие тяжелые и если 10 юзеров сидит на одном с сервером гигабитном свиче, то разницы они не заметят.
Поэтому: чем проще тем лучше

[АртемЪ]

nApoBo3, Имеет в некоторых случаях.

[nApoBo3]

AntHTML, я честно не могу представить себе ситуацию когда данные в графической форме( т.е. в виде RDP картинки ) будет занимать меньше чем в бинарной или текстовой.
Мне понятно почему плохо подключать файловую базу на каналах с высокой задержкой и низкой пропускной способностью.
Можно от часть понять почему плохо подключать SQL базу в такой конфигурации( хотя насколько я понимаю 1С SQL у них не бывает без сервера 1С предприятия ), подобную задачу решают реверс прокси. Плюс вероятно сервер 1С предприятия может получать из базы больше данных чем передает клиенту( например он проводит с ними какие-то вычисления или накладывает фильтры ).
Но чтобы к серверу предприятия доступ по RDP был быстрее?

Да, есть случаи когда RDP нужен не по причине производительности, но вы пишите от трафике, и вот именно это утверждение вызывает сомнения. ИМХО это просто традиция делать 1С через RDP.

Но если вы мне укажите на конкретный сценарий когда это будет оправдано, я готов принять вашу позицию.
За одно оставлю здесь АртемЪ, может он меня поправит.

[AntHTML]

nApoBo3, С сервером 1С особо разницы может и не будет. Смысл в том, что, как сказал АртемЪ, 1С и практически любая БД критична к пингам, а если пинги большие, то и транзакции будут подвисать отнимая время работы сервера и забивая канал доступа. Из-за чего у всех на вроде и неплохом сервере могут наблюдаться тормоза.
А RDP прекрасно параллелится, поэтому 1С моментально отработала запрос к БД и вывела картинку на сервере, а через сколько эта картинка дойдет до глаз пользователя ее уже не волнует, она занимается другой операцией.
Традиция делать 1С на ТС была в эпоху 7.7, когда она тормозила базы, сейчас подобие режима терминального сервера реализовано в связке 1С сервер - 1С тонкий клиент, из-за чего, при нормально написанной конфе, разница в скорости работы снижается

[nApoBo3]

AntHTML,
"1С и практически любая БД критична к пингам, а если пинги большие, то и транзакции будут подвисать отнимая время работы сервера и забивая канал доступа."

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

"А RDP прекрасно параллелится,"

Какое это имеет значение? Если сама 1С не параллелится, то параллельность RDP не будет иметь значения( да и параллельность RDP вызывает большие вопросы, вроде бы да, но это стоит в ресурсах ОЧЕНЬ дорого в расчете на одну сессию ).

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

Каким образов 1С сервер - 1С тонкий клиент является аналогом терминального сервера? Так знаете и VK какой-нибудь можно аналогом терминального сервера считать, да и вообще любое приложение которое обращается к api, а не напрямую к данным.
ИМХО 1С Сервера - 1С тонкий клиент с точки зрения производительности, за исключением отдельных случаев, когда пинг очень большой, а разработчик на отображение одного окна написал 100 запросов и не распараллелил их( а за такое нужно сразу много не хорошего делать ), разницы быть не должно.

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

Answer 2

[АртемЪ]

Зависит от ситуации.

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

Вообще связь тонкого клиента с сервером передает данных не больше чем RDP, а зачастую и меньше.
Канал широкий там не нужен. Но очень важен пинг.
Если пинг высокий работать будет проблемно, поэтому если сервер 1с где нибудь в ДЦ за пару тысяч км, то придется рядом терминал лепить.

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

Comments

[nApoBo3]

Т.е. пинг будет проблемой для работы не по RDP, но для RDP проблемой не будет?

[АртемЪ]

nApoBo3, Да, именно так.
На RDP пинг мало влияет.

[АртемЪ]

nApoBo3, Смотрите допустим пинг 100мс
Если мы работаем в РДП - реакция на наши движения будет приходить с задержкой 0,1секунды это заметно и неприятно, но не критично.

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

Answer 3

[Максим Гришин]

Локальные клиенты 1С и сервер 1С поблизости от сервера БД. RDP в такой ситуации ИМХО избыточен, даже если оставить в стороне вопрос лицензирования (честно покупать все лицензии для RDP дорого). Проблема будет обновлять клиенты, но для этого можно разместить клиент на сети и там его обновлять.
Терминальный сервер для работы в 1С оправдан, если требуется резервировать локальные данные пользователя, а также если нужно обеспечить необходимость удаленной работы. (По-моему так)

Answer 4

[Александр Черных]

Я за терминал для бухгалтерии, склада или что там еще. Есть проги подачи отчетности, есть почта, еще чтото. Удаленное управление. Бекапирование сразу и всего.
Кароче, этов опрос баланса затрат и удобства. Но если касса позволяет, я бы делал терминал

Answer 5

[Константин]

еще можно для 1с Тонкий клиент или публикация Web.

Answer 6

[VitalyChaikin]

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

Answer 7

[LollyFox]

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

Answer 8

[Максим Ярошевич]

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

Answer 9

[Сергей Булгаков]

попутный вопрос: а если не терминал, а RemoteApp?