Добрый день, уважаемые коллеги по нелегкому труду.
Ситуация следующая - имеем несколько разрозненных серверов географически расположенных в разных точках. Основная конфигурация 1С - УТ 10.3 Есть задача собрать все БД в одной серверной для удобства администрирования. На одном объекте работает машина, выполняющая роль RDP сервера, сервера 1С и SQL соответственно. Так как перевозить RDP пользователей задача не быстрая, да и собственно планов таких нету - встаёт вопрос как будет работать связка MS SQL и Сервера 1С через интернет (VPN туннель). Конкретно по такой схеме работать не приходилось работать, но ранее был опыт работы по схеме  "Клиент - Интернет - Сервер 1С+MS SQL", и скорость работы была не очень, особенно учитывая что УТ 10.3 плохо оптимизированная для клиент-серверной архитектуры. На сколько я понимая большая чувствительность к пингу. Подскажите, относительно варианта  "Клиент - Интернет - Сервер 1С+MS SQL", вариант "Клиент - Сервер 1С - интернет - MS SQL сервер" как себя будет чувствовать? Был у кого то подобный опыт? Как можно оптимизировать такую схему работы? Может есть более действенные решения? Далее просто стоит подобная задача, но объекты географически вообще в разных регионах находятся, сейчас экспериментируем что бы понять на сколько это приемлемо.

только полевой эксперимент покажет приемлют ли это ваши юзеры.
а вообще между сервером 1с и СУБД стараются делать как можно меньше пути и как можно шире канал.

Так и не понял, почему нельзя поднять RemoteAPP.

ВебКлиент - Интернет - ВебСервер - Сервер 1С+MS SQL

(2) толстый клиент и хреновый тырнет - будет постоянно отваливаться

не зря же тонкий и веб-клиент существуют

(3) УТ 10-ка - какой такой веб-клиент? :-)

(3) > ВебКлиент - Интернет - ВебСервер - Сервер 1С+MS SQL

для УТ10.3 это фантастика. ну разве что сами перепишут типовую? для веба?

Ну так пусть будет сервер RDP, сервера 1С и сервер SQL в одном "географическом месте".
Если такой вариант технически не возможен, лучше так: Клиент - Интернет - Сервер 1С+MS SQL

(0) Вот вы и расскажете, что получится.

(0) плохо будет работать... банально потеря пакета и ожидание...

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

(0)>как будет работать связка MS SQL и Сервера 1С через интернет (VPN туннель)

работать будет неприемлемо хреново

(0) >  Есть задача собрать все БД в одной серверной для удобства администрирования

варианты: покупка нового железа, переход на стильную модную молодежную УТ11, перенос/переход/внедрение/обучение

первые несколько лет будет неудобно, потом привыкнете.

да. Админам однозначно будет удобнее всех админить в одном месте :)

крупные вендоры территориально распределенных БД и мощностей все равно ставят СУБД и Сервер1с рядом.
https://cloud.yandex.ru/solutions/1c

(0) работать не будет, централизуйте через РИБ

(12) только вот незадача, УТ10.3 невпихуема в облако крупных вендоров (конфа не той системы)

(0) переходите на 11 торговлю и пихайте ее в облако)

(14) это во фреш оно невпихуемо. а в кастомные облака яшки или других провайдеров - вполне.

(16) откуда инфа? что толстые формы в кастомных облаках вполне?

(17) толстый* клиент

(18) тоже хотел бы посмотреть как обычные формы в вебе работают

(16) пичаль еще в том, что в УТ10.3 еще торгобое оборудование всякое разное к клиенту прикручено, ну там сканеры/фиганеры и не дай божи кассы ККМ

в облаке они как себя чувствуют?

я хз как у ТС работа ведется в базах, может вполне устроит РИБ для такой задачи

(21) у ТС задача сделать админам удобно, как я понял

(5) (6) извиняюсь, не заметил

Из сообщения автора следует, что основная задача - это обеспечение удобства администрирования в одной серверной, а так у них ничего не тормозит(наверное). РИБ может устранить "разрозненность"?

(24) это конечно круто, главное, чтобы бизнес не страдал, из-за этого "удобства". А то получится постоянные фризы, а в регионах может и с инетом быть проблемы и все встает колом.

(25) Автор об этом пока умалчивает..

(20) У нас кассы и двумерные сканеры для маркировки. Кассы подтормаживают, но сейчас осталось только две удаленных. Со сканерами заколебались в режиме COM, перевели в клавиатурные. При сканировании частенько глючат служебные символы в ШК, но нам не критично - криптохвост из 44 символов не используем.

(27) "Со сканерами заколебались в режиме COM" - а что с ними не так? По мне так с ком намного удобнее работать

(19) никакого веба. толстый клиент. отриньте ассоциацию. облако - не значит что в вебе. облако - это аутсорс сервера.

(29) по факту такой же РДП получается

(28) в рдп неудобно пихать.

(31) там же вроде нормально проброска порта работает. Не помню, чтобы сталкивался с подобными проблемами. Были косяки, когда кабель от сканера в другие слота юсб пихали и номер ком порта слетал

(32) на самом деле есть проблемы с проброской, что с COM, что клавиатурным, если тырнет плохой и пинги большие. глючат в любом режиме

с клавиатурным прикол - для "маркировки" чувствителен к раскладке клавы, начинает "фигню писать" (если криптоёптахвост)

(33) вот тут точно дешевле нарисовать тонкий клиент, даже если это ут10.3 - дорисовать пару НУЖНЫХ форм.

(34) чтобы дорисовать пару нужных форм и приколхозить торгобое оборудование к этим нужным формам - тут вся мощь БСП и БПО потребуется. УТ10.3 треснет. и станет похожа на УТ11 :)

(35) да ну не. однажды, самолично колхозил торговое оборудование к древней торговой конфе - много не надо, если резать с умом, то популярные либы, типа ШтрихМ, встраиваются как обработка и один-два совсем общих модулей, типа строковых функций.

(36) ну т.е. облако, УТ10.3 и приколхозил ККМ через веб/тонкий клиент?

(37) звучит как рецепт для (0).

почему ты подумал что я так уже сделал? для меня это 3 отдельных опыта:
а) закинуть нетиповую 1сню в облачный провайдер;
б) сделать тонкий клиент к обычной конфе;
в) переделать ККМ на новый стандарт ФФД.

(38) с ККМ есть варианты, из облаков можно на ККМ по сети печатать чеки. реализации разные... ну т.е. не обязательно нативный драйвер ККМ 1С из БПО на клиент  тащить в старую конфу

реализации* не всмысле документы, а всмысле "отдельный веб-сервер для ККМ" или сторонние/самописьные решения для сетевой печати на ККМ

(38) "переделать ККМ на новый стандарт ФФД" - это я тоже делал, ничего особо сложного нет, но это не равно, приколхозить решение на управляемых формах для торгового оборудования в конфу на обычных формах.

>>как будет работать связка MS SQL и Сервера 1С через интернет (VPN туннель)

Хреново будет работать. Тут в локальной-то сети аккуратно сервер 1С и сервер БД разносят, делают между ними прямую гигабитную сеть. А он собрался интернет между ними пробросить. Ну-ну

(42) > аккуратно сервер 1С и сервер БД разносят, делают между ними прямую гигабитную сеть

это моветон уже. редко кто так делает сейчас

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

(43) в энтерпрайзе СУБД всегда на отдельных серверах крутится

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

(45) серваков будет несколько, но это не повод "разносить" скуль отдельно, сервер 1С отдельно, даже если кровавый энтерпрайз

(45) поэтому и разносят на несколько серверов, если 1 лег, юзверов перекидывает на следующий.

(47) и чем выделенный скуль на отдельной железке или даже несколько серверов (для репликации) помогут быстрее работать?

(48) тут вопрос не в скорости, а в стабильности и отказоустойчивости. Например, вы взяли и наружу свою 1ску вытащили, всякие http апишки сделали, а вас начали ддосить и положили вам сервак с кластером. А у вас там еще и скуль оказался, а может еще и терминальник))

(48) быстрее, возможно, и не помогут работать, но надежнее наверняка. Ещё один весомый аргумент - безопасность доступа. Или на сервер БД будет щемиться сервер СП 1с под одной системной записью из заранее определенного места, или 100500 различных юзеров кто откуда

(49) и пароль стандартный например Qwerty123, например? и еще и терминальник для 100500 пользователей! кошмар. срочно скуль на отдельный сервер для надежности и стабильности :)

(51) да я конечно утрирую, но скорость иногда не главный параметр.

можно и разнеся добиться приемлемой скорости работы, зато сделать более защищенной систему.

(49) > тут вопрос не в скорости

конечно. на личном примере. была классическая трех (зачеркнуто) двух звенка. ERP 2.4 на 100 пользователей ох.евала и тормозила безбожно

решили проблему покупкой нового супержелеза (один сервер, ибо кластер и стабильность нынче дорого), но с вагоном памяти и оптанами (которые и как память и как диски работать умеют)

а надежность и отказоустойчивость другими мероприятиями решается.


пользователи пока отстали с "гавно эта ваша 1С" и пока щастливы

(54) когда у тебя будет энтерпрайз, датацентры и вот это всё, залюбишься доказывать безопасникам, что на сервер БД нужно установить много чего и пустить туда много кого

(55) вдруг энтерпрайз, а я уставший (доказывать безопасникам)

"тупой" разговор на тему воронежских разработчиков СУБД

ЕRP 2.5 на 100-200 юзверей в пике это уже не энтерпрайз, или еще ларек с функциональностью КОРП?

(56) а что поделать? Не все в мире кустарно-ларёчной разработки живут

(55) у нас на сервере нет никого из пользователей, разве что админы иногда заходят. жопа наружу не торчит (ЭДО не считаем и прочую отчетность)

все щасливы

и да, был опыт ж0пу наружу выставлять через промежуточную самописьную базу 1С/по совместительству прокся/API и "токены для сервисов". Сервер 1С наружу ж0пой не светил

(59) А эта промежуточная база была в том же кластере где и рабочая база?

(60)  промежуточная опубликованная на апаче на отдельном компе, который не жалко :)

(0) Через инет толстый клиент УТ10.3 работает хреново. Даже на хорошем выделенном канале.

Я бы делал.
Вариант 1. Настроить РДП на новом месте, установить тестовую УТ и потребовать пользователей проверить доступ, работу печать и т.д.
После чего выгнать из старого РДП перенести базу, запустить всех в новую.

Вариант 2. РИБ. Развернуть базу на новом месте и перетаскивать неспеша.

ИМХО проще удаленно админить раз в несколько дней чем постоянно по инету СКЛ трафик гонять.

(61) а что вы так?) А как же скорость?) Надо было все на одной машинке, чтобы было быстро, модно, молодежно=)

(61) у вас же там пароль был явно не qwerty12345 так что чего бояться?)

(64) еще раз. на одной железке мощной производительность выше, чем "разносить". чтобы не проипать данные - много разных способов организационных

вопрос доступности для юзверей - тоже вопрос решаемый. если не ритейл и 24/7, то быстро поднятый сервер упавшим не считается :)

разный уровень нищеты

ну вот с кластером и отказоустойчивостью (репликацией) развлекался в далеком 2012 году еще на платформе 8.2. всё по-взрослому в энтерпрайзе :) даже "аварии" моделировали. если вдруг, когда тогда и что делать и кто блин виноват

за 1.5 года ни разу ничего не отвалилось и эта "ваша" отказоустойчивость и доступность не пригодилась. повезло наверное. сервера HP на гарантии почти новые тогда были

(63) да это просто и не взлетит. СП 1с на СКЛ бомбит много-много маленьких платформенных запросиков. Плюс 1сник не получит ссылочные представления перед выводом, и вот на скуль полетели сотни select для получения представлений ссылок. Если к этому всему добавится задержка от интернета, то получится мегатормоз

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

(68) обсуждение сферических ERP в вакууме

нет причин кончать