Подключение к ИС "AITS-Прослеживаемость" для пользователей "Гедымин: Мясокомбинат"
Здесь Вы можете задать абсолютно любой вопрос представителям компании Golden Software of Belarus, Ltd

Удалённое подключение к базе через VPN

Сообщение lim » 23 янв 2015, 22:58

Вопрос к пользователям “Гедымина”. Использует ли кто подключение удалённых рабочих мест к базе данных через VPN, предоставляемый “Белтелекомом”?
http://beltelecom.by/business/business-solutions-networking/vpn
lim
Monster
 
Сообщения: 206
Зарегистрирован: 25 дек 2007

Re: Удалённое подключение к базе через VPN

Сообщение sysdba » 24 янв 2015, 12:53

Вы у себя тестирование той утилитой провели? Что она показывает на latency? На сколько больше, чем в локальной сети. Похоже, что именно в ней проблема.

И еще, загрузка идет две минуты, а дальнейшая работа с какой скоростью идет? Повторная загрузка сколько занимает?

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

ссылка по теме:

http://www.firebirdfaq.org/faq53/
sysdba
Monster
 
Сообщения: 1242
Зарегистрирован: 17 янв 2005

Re: Удалённое подключение к базе через VPN

Сообщение lim » 24 янв 2015, 16:02

В данном случае соединение не через интернет, а по оптоволокну на скорости 100 mbit.
Но в отличие от прямого соединения здесь есть промежуточные роутеры. Поэтому интересует, работает оно в принципе хоть у кого-нибудь?
Ну а с причинами буду разбираться с понедельника.
lim
Monster
 
Сообщения: 206
Зарегистрирован: 25 дек 2007

Re: Удалённое подключение к базе через VPN

Сообщение sysdba » 25 янв 2015, 17:21

разбирайтесь. тут, к гадалке не ходи, дело скорее всего в latency. Стоит понимать, что у каждого технического решения есть своя область предназначения и есть свои пределы. Протокол взаимодействия с базой данных не приспособлен для прямой работы через сети с большой latency, например internet или vpn.

Посмотим на Гедымин в части взаимодействия по сети клиента с сервером. На низовом уровне все сводится к обмену командами SQL между клиентской и серверной частями Firebird. Используемый протокол подразумевает массу мелких обменов сообщениями. Например:

1) открыть транзакцию -- пошло сообщение на сервер, сервер шлет ответ.
2) подготовить запрос -- пошло сообщение на сервер, сервер шлет ответ.
3) передать параметры, послать запрос на выполнение -- пошло сообщение на сервер, сервер шлет ответ.
4) получили блок записей, вывели на экран, понадобился следующий блок -- пошло сообщение на сервер,сервер шлет ответ.
5) в записи есть БЛОБы -- на каждый блоб шлем сообщение на сервер, сервер шлет нам часть его данных. Понадобилась следующая часть -- опять туда-сюда идут сообщения.
6) закрываем запрос -- сообщение на сервер и ответ.
7) комитим транзакцию -- сообщение на сервер и ответ.

Если latency большая, то на каждой посылке/ожидании возникает пауза.

Это именно та ситуация, которую вы и наблюдаете у себя. Пример, загрузка в локальной сети Гедымина занимает 20 сек. Из них 10 сек крутится код на компьютере, 10 сек уходит на сетевой обмен и загрузку данных. Пинг у вас показывает 1 мс на запрос. Пинг на удаленную подсеть показывает 7 мс, т.е. в семь раз больше. Таким образом загрузка Гедымина при подключении к серверу в удаленной подсети займет: 10 сек + 10 * 7 = 80 сек.

Цифры условные, но иллюстрируют влияние сети.

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

Вы задавали вопрос про работу через 100 Мбит сеть. Скорее всего вам никто ничего не ответит, потому что все клиенты которых я знаю, работают через ADSL и удаленные рабочие столы. Причем скорости в таком случае нужны минимальные. Один наш клиент начинал с 512 КБит и сейчас нарастил канал до 2 МБит. По такому каналу работает удаленное предприятие, порядка 10 одновременных рабочих мест.

Удаленный рабочий стол (RDP) -- это вовсе не "быстрый интернет для бедных", а самостоятельное решение, обладающее ключевыми преимуществами. Вот некоторые из них:

1) При работе напрямую обрыв сети означает потерю какой-то части данных, которые были внесены/изменены в незакомиченной транзакции. Более того, при обрыве, Гедымин автоматически закрывается. Пра работе через удаленный рабочий стол достаточно заново подключиться к сессии, на которую обрыв соединения никак не влияет.

2) Сетевой трафик на порядок-два меньше, чем при прямом соединении. Latency не имеет большого значения.

3) Нет необходимости в инстоляции Гедымина на каждом рабочем месте и дальнейшем поддержании актуальности версий. Нет конфликтов с антивирусами, играми и прочим ПО на каждом рабочем месте.

4) На рабочей станции может использоваться минимальное, устаревшее железо.

5) На рабочей станции может использоваться любая операционная система, имеющая RDP клиента. Linux -- пожалуйста, MacOS -- замечательно, Android -- без проблем.

6) Упрощается администрирование и управление правами пользователей. Можно задействовать стандартные механизмы Active Directory.

7) Сервер Firebird закрыт от прямого доступа.

8) Меньше затраты на аппаратную часть. Один мощный терминал сервер и двадцать простеньких рабочих станций обойдутся дешевле, чем двадцать достаточно мощных компьютеров, которые потребуются для комфортной работы Гедымина.

9) Упрощается апгрейд железа.

10) Можно запустить длительный процесс в офисе. Выключить рабочую станцию. Приехать домой. Подключиться с домашнего компьютера к удаленной сессии и посмотреть результат выполнения.

При желании список можно продолжить.
sysdba
Monster
 
Сообщения: 1242
Зарегистрирован: 17 янв 2005

Re: Удалённое подключение к базе через VPN

Сообщение lim » 31 янв 2015, 11:34

По vpn ситуация такая. На самом деле между двумя оконечными роутерами используется дополнительное оборудование (это другие роутеры и возможно что-то ещё). Замечено также, что при старте программы дольше всего идёт загрузка полей, а загрузка исследователя проходит сравнительно быстро. Кроме того, при запуске пинга с длиной пакета 64000, первая задержка 80-90мс, а последующие - 7мс. Похоже, что в первый момент в оборудовании происходят какие-то автонастройки окна TCP и других параметров и в результате получается большая задержка. Поэтому, если будут передаваться пакеты с переменным интервалом и переменной длиной, задержка будет весьма значительной, что и имеем в реальной ситуации.
Кстати, у знакомого есть несколько таких vpn сетей по области на скорости 5-10 мбит.
У них 1С 8-ой версии и клиент даже при такой скорости грузится быстро. Но, в 8-ой версии используется 3-х уровневая архитектура, т.е. есть ещё и свой сервер приложений, поэтому обмен данными между клиентом и сервером небольшой. Используется у них также ещё одна ценная фича - консолидация данных. С её помощью в центральную базу подливаются данные из периферийных баз.
Может быть, когда-нибудь всё это будет и в Гедымине? :wink:
lim
Monster
 
Сообщения: 206
Зарегистрирован: 25 дек 2007

Re: Удалённое подключение к базе через VPN

Сообщение sysdba » 01 фев 2015, 09:10

Еще раз повторю: у нас и на 2 мбит работают удаленные предприятия. Через рабочие столы.

Консолидация есть. Например, данные райгазов минской области консолидируются в головной бд. Заключайте договор на абонентское -- настроим и вам.
sysdba
Monster
 
Сообщения: 1242
Зарегистрирован: 17 янв 2005

Re: Удалённое подключение к базе через VPN

Сообщение sysdba » 01 фев 2015, 23:30

Раз уж зашла речь про консолидацию и удаленные подразделения, вот конкретный случай из нашей практики. Более десяти лет работаем мы с одним клиентом, название которого, всуе, лишний раз упоминать не стоит. Организация серьезная. Имеет подразделения в каждом рай- и областном центре Беларуси. Итого: более 120 шт.

Первоначально, только головной офис использовал программу. Перефирийный учет велся вручную. Бумажные отчеты поступали в Минск, где специально обученные люди вводили их в БД.

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

1) большинство районов подключались в сеть через модемы и телефонные линии на скорости 32-56 Кбит\сек.
2) там, где была доступна связь с большей скоростью, все протоколы, кроме почты, были прикрыты снаружи, провайдером.
3) головной офис подключался в интернет через модем на скорости 56 КБит\сек. соединение было непостоянным.
4) сервер головного офиса обслуживал и другие задачи, через которые периодически перезагружался.

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

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

Использование протокола электронной почты (SMTP) позволило организовать асинхронный обмен данными.

Такая система успешно проработала лет шесть.

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

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

Решение:

1) в головном офисе устанавливается выделенный компьютер под сервер терминалов. Для комфортной работы объем памяти рассчитывается по формуле 1 Гб на коннект + 4 Гб на ОС. Т.е. 16 Гб хватит для 12 одновременных подключений. Память быстрая, DDR4. Процессор мощный, но недорогой, например Intel Core i7-4790K -- 4 ядра, 8 нитей с hyperthreading, 4 ГГц. Жесткий диск не играет особой роли. Лучше поставить два дешевых по 0.5-1Гб и объединить их в зеркало встроенным RAID контроллером материнской платы. Общая стоимость компьютера в пределах 800-1000 USD.

2) если число коннектов увеличится, то дешевле (и надежнее) установить второй (третий, четвертый...) терминал сервер, чем изначально приобретать один, но очень мощный. Например, два сервера обойдутся в 1600-2000 USD, а один двухпроцессорный -- 4000-5000 USD.

3) под базу данных (она у клиента небольшая по нашим меркам, 2-3 Гб) отдельный сервер. Четырехядерный i5 или i7, 16-32 Гб ОЗУ, DDR4, 4 винта SATA3, собранных в два зеркала. Одно для ОС, файла подкачки и временного каталога. Второе -- для размещения базы данных. Встроенного в материнскую плату RAID контроллера будет вполне достаточно. Не забываем, что сервер базы данных обязательно должен быть оснащен мощным, проверенным источником бесперебойного питания с обратной связью -- пропало электричество надолго, бесперебойник аккуратно выключает сервер. Ориентировочная стоимость без ИБП -- 800-1000 USD.

4) при настройке зеркал обязательно указываем размер страйпа 8К. Такой же размер кластера указываем при форматировании дисков. Файловая система строго NTFS.

5) один из терминал серверов можно использовать для хранения архивных копий БД. Не забываем периодически переписывать архивы на внешние диски, которые надежно хранить в другом помещении или даже здании.
sysdba
Monster
 
Сообщения: 1242
Зарегистрирован: 17 янв 2005

Re: Удалённое подключение к базе через VPN

Сообщение alex » 02 фев 2015, 06:43

sysdba писал(а):2) если число коннектов увеличится, то дешевле (и надежнее) установить второй (третий, четвертый...) терминал сервер, чем изначально приобретать один, но очень мощный. Например, два сервера обойдутся в 1600-2000 USD, а один двухпроцессорный -- 4000-5000 USD


Если принять в расчёт стоимость серверной винды, то начиная с третьего сервера терминалов вариант с одной двухпроцессорной машиной получится дешевле.
alex
Monster
 
Сообщения: 218
Зарегистрирован: 19 янв 2005

Удалённое подключение к базе через VPN

Сообщение warnermit » 26 дек 2018, 05:25

Параметры подключения к базе SQL храняться в файле users.usr который находится по пути КаталогИБ/usrdef/. Для того чтобы извлечь из него строку подключения поищи в нете есть программки для расшифровки этого файла.
warnermit
Newbie
 
Сообщения: 2
Зарегистрирован: 22 дек 2018

Вернуться в Прочее
cron