PDA

Просмотр полной версии : MIDSERVER ,REFSERVER



Hendehog
25.05.2016, 13:04
Приветствую.
Проясните пожалуйста мне следующее.
Есть сервак на нем REFSERVER (Справочники и отчеты).
Есть касса на ней MIDSERVER и wincash.
Так вот сегодня у нас были проблемы с загрузкой MIDSERVER , он останавливался при загрузке loadins reference и долго висел, потом отвисал и прогружался.
У меня есть подозрение, что он не грузился из-за глюков на стороне REFSERVER , т.к в менеджерскую я зайти тоже не мог (Ошибка отправки данных).
Теперь вопросы.
Неужели MIDSERVER на кассе не может отдельно работать и запускаться самостоятельно не завися от REFSERVER?
Можно ли как-то реализовать независимую автономную работу кассовых серверов чтобы они от внешних факторов так сказать не зависели и работали сами по себе?

SH
26.05.2016, 03:50
Неужели MIDSERVER на кассе не может отдельно работать и запускаться самостоятельно не завися от REFSERVER?
Может.


Можно ли как-то реализовать независимую автономную работу кассовых серверов чтобы они от внешних факторов так сказать не зависели и работали сами по себе?
Вообще, по умолчанию так и есть. Я предполагаю, что ваши проблемы были связаны с тем, что рефсервер был в сети, но тупил. Поэтому касса его видела, пыталась получить данные, ждала, но безрезультатно. Я думаю, если бы просто выключить реф, то мид запустился бы без проблем.

Hendehog
26.05.2016, 09:12
Может.


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

Интересно как в будущем уберечься от таких проблем? Может есть какая-то хитрая настройка таймаута? Если за столько не подключился , игнрировать рефсервер например? Хотя вряд ли, юсиэс же.

alkon132
29.05.2016, 11:56
Именно так и работает из коробки. В 99% процентов случаев - работает нормально. Если при включении кассового сервера у него нет связи с сервером верхнего уровня - он просто запустится в автономном режиме. И будет примерно раз в 10 минут проверять - а не появилась ли связь. Такой механизм вполне оправдан, т. к. мидсервер - автообновляемый модуль.


А вот если связь есть, но:
а) плохой канал
б) рефсервер чем-то сильно занят на данный момент
- то да, мид будет включаться долго.
Собственно проблемы в этом не вижу, всё вполне нормально. Ранее проблема была в том, что если мид и wincash физически на одном компьютере - wincash не запускался, т.к. стартовал он быстрее мида.
Данная проблема целиком и полностью исправлена в 7.5.5, существенно переработан батник запуска кассы.

Еще есть проблема - если кассовый сервер жестко выключить в момент синхронизации рабочих модулей - потом он без связи с рефом уже не включится. Но это сильно редкий случай.

Эркипер Сторехаусович
05.06.2016, 20:32
Это все решаемо в св-вах мидсервера на вкладке синхронизация. Нужно выставить только нужные галки , хотя при первом запуске после синхронизации нужно обновлять все коллекции на мидсервере. Мидсервер может работать автономно без связи с РЕФ сервером 3 суток.

Hendehog
06.06.2016, 08:18
Это все решаемо в св-вах мидсервера на вкладке синхронизация. Нужно выставить только нужные галки , хотя при первом запуске после синхронизации нужно обновлять все коллекции на мидсервере. Мидсервер может работать автономно без связи с РЕФ сервером 3 суток.

А только нужные это какие?

alkon132
06.06.2016, 08:51
Мидсервер может работать автономно без связи с РЕФ сервером 3 суток.
Что-то новенькое. Можно пруфлинк, откуда информация эта?

sibgaba
06.06.2016, 10:28
Я думаю что тут уважаемый Эркипер Сторехаусович что то перепутал, например с вирт ключами.
Есть объект который минимум пол года работает без связи с рефом (обмен на флешке), при этом бывает что флешку неделями не носят и все норм

Эркипер Сторехаусович
07.06.2016, 01:19
Что-то новенькое. Можно пруфлинк, откуда информация эта?

от разработчиков в трекере.

---------- Добавлено в 00:11 ---------- Предыдущее сообщение было размещено в 00:08 ----------


Я думаю что тут уважаемый Эркипер Сторехаусович что то перепутал, например с вирт ключами.
Есть объект который минимум пол года работает без связи с рефом (обмен на флешке), при этом бывает что флешку неделями не носят и все норм

Абсолютно ничего не перепутал. Виртуальный ключ должен иметь доступ к серверу лицензирования , если более 3 суток нет доступа - беда придет. Эта информация актуальна для текущих версий 7.5.5. и 7.5.4 , если вы кипер годами не обновляете в ресторанах то старый механизм проверки лицензии может не совпадать с моими словами , но это уже не моя ошибка :)

---------- Добавлено в 00:16 ---------- Предыдущее сообщение было размещено в 00:11 ----------


А только нужные это какие?
решать вам , но если новые блюда и персонал не заводите то можно только "данные закрытых смен" оставить. Если заводите - добавляйте "данные справочников"

---------- Добавлено в 00:19 ---------- Предыдущее сообщение было размещено в 00:16 ----------



Еще есть проблема - если кассовый сервер жестко выключить в момент синхронизации рабочих модулей - потом он без связи с рефом уже не включится. Но это сильно редкий случай.

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

SH
07.06.2016, 15:06
Виртуальный ключ должен иметь доступ к серверу лицензирования , если более 3 суток нет доступа - беда придет.
Так речь в теме не про виртуальные ключи, а про обычные...

Эркипер Сторехаусович
07.06.2016, 16:59
Так речь в теме не про виртуальные ключи, а про обычные...
обычный ключ должен обеспечивать связь хотя бы раз в течение 3 суток мид <=> реф , виртуальный ключ: мид <=> сервер лицензирования. Так понятнее?

sibgaba
07.06.2016, 18:39
обычный ключ должен обеспечивать связь хотя бы раз в течение 3 суток мид <=> реф
Реальный объект. 7,5,3,260 (специально слазил к ним посмотреть)
3 кассы. все без связи с Реф. На каждой свой мид с физическим ключем, обмен данными через флешку.
Максимальный срок который кассы работали в автономе (без переноса данных на флешке) это 1 мес (когда человек который за это отвечает был в отпуске) кассы работали.
Сейчас регулярно происходят ситуации когда обмена нет по 3-5 дней.

Скажите, что я делаю не так?

Понимаю что 753 это не 754, но тоже не плохая версия.
И мне сильно не ясно для чего UCS могло бы ввести такое ограничение (3 дня без рефа) при наличии физического ключа

alkon132
07.06.2016, 19:23
А я всё-таки не вижу смысла спорить и еще раз прошу пруфлинк. Если разработчики на трекере так говорили - ткните пожалуйста носом в тикет на трекере.
Говорят, даже Александр Ильин иногда ошибается (сам не видел), но в данном случае - не верится.

sibgaba
07.06.2016, 20:03
Говорят, даже Александр Ильин иногда ошибается
Бывает такое. Я видел.

Эркипер Сторехаусович
07.06.2016, 23:18
Понимаю что 753 это не 754, но тоже не плохая версия.
И мне сильно не ясно для чего UCS могло бы ввести такое ограничение (3 дня без рефа) при наличии физического ключа

Физический ключ - лишь болванка. Лицензия прописывается на L.UCS , а значит можно 2 (и более) физически разным кассовым серверам прописать одинаковый код предприятия и ресторана , нагенерить СОС кодов и работать.

---------- Добавлено в 22:18 ---------- Предыдущее сообщение было размещено в 22:05 ----------


А я всё-таки не вижу смысла спорить и еще раз прошу пруфлинк. Если разработчики на трекере так говорили - ткните пожалуйста носом в тикет на трекере.
Говорят, даже Александр Ильин иногда ошибается (сам не видел), но в данном случае - не верится.

http://tracker.ucs.ru:8080/redmine/issues/78288
конкретно про 3 дня найти сейчас не могу , видимо мне по телефону/скайпу это сообщили.

для вашего "реального объекта на 7.5.3.260" используется старый механизм лицензирования с привязкой к ID процессора.

SH
07.06.2016, 23:38
нагенерить СОС кодов
Ага, конечно... Ну то есть технически можно попробовать, а реально за каждый лишний сос-код больно бьют по рукам.

sibgaba
08.06.2016, 00:21
Идея с СОС кодами понятна.
Но реально за них спрашивают (может быть не со всех одинаково). Да, есть возможность "отписаться", но жить так в долгосрочной перспективе (6+ мес) ИМХО не реально...

Hendehog
08.06.2016, 14:16
Физический ключ - лишь болванка. Лицензия прописывается на L.UCS , а значит можно 2 (и более) физически разным кассовым серверам прописать одинаковый код предприятия и ресторана , нагенерить СОС кодов и работать.

---------- Добавлено в 22:18 ---------- Предыдущее сообщение было размещено в 22:05 ----------



http://tracker.ucs.ru:8080/redmine/issues/78288
конкретно про 3 дня найти сейчас не могу , видимо мне по телефону/скайпу это сообщили.

для вашего "реального объекта на 7.5.3.260" используется старый механизм лицензирования с привязкой к ID процессора.

Кстати коль на то пошло , к чему привязывается лицензия ? Вот предположим сгорело все к чертям. Ставим новый моноблок,и ключ, лицензия же слетит? К какому компоненту она привязана? Мак? ХДД?

vandy
08.06.2016, 14:31
И мне сильно не ясно для чего UCS могло бы ввести такое ограничение (3 дня без рефа) при наличии физического ключа

Это уже не баг, а фича.

Было такое у меня. и Задача была на трекере (http://tracker.ucs.ru:8080/redmine/issues/35497). Потом было обновление,в котором это устранили. (найду - напишу)
Сейчас на 7.5 есть в ФФ кассы более месяца без REF

sibgaba
08.06.2016, 14:42
Вот предположим сгорело все к чертям. Ставим новый моноблок,и ключ,
...и спокойно работаем. Ничего не слетит. Лицензия на MID привязана только к ключу.

Эркипер Сторехаусович
08.06.2016, 15:07
...и спокойно работаем. Ничего не слетит. Лицензия на MID привязана только к ключу.

тогда объясните мне , зачем в новых инишниках строки
LicenseCPUID=
?

А я знаю :)

sibgaba
08.06.2016, 15:31
тогда объясните мне...

А я знаю

Отлично что вы знаете. И что теперь будете делать с этим?

Эркипер Сторехаусович
09.06.2016, 12:52
Просто намекаю , что Ильин Александр в данном случае не прав , говоря "Лицензия на MID привязана только к ключу". Т.к. реально она привязана и к железу , если железо меняется то CPUID будет другой и нужно будет перегенерировать лицензию или использовать SOS-код или сбросить этот CPUID из Rk7.udb или вписать правильный CPUID в инишник :) Давайте закроем наш спор.

ffff
22.06.2016, 21:14
У меня 7.5.4.166 менял моноблоки на кассовых серверах, конфигурации отличались сильно,даже винда xp на win7 поменялась, просто папку перенес, сетевые настройки востановил, все заработало

sibgaba
23.06.2016, 11:34
просто папку перенес,
А сервер (MID) на моноблоке или на менеджерском компе?
Ну или по другому - в моноблоке ключ защиты был?

Rus75lan
24.06.2016, 10:25
У меня 7.5.4.166 менял моноблоки на кассовых серверах, конфигурации отличались сильно,даже винда xp на win7 поменялась, просто папку перенес, сетевые настройки востановил, все заработало
Подтверджаю.
Не раз переносили кассовые сервера с отдельным ключом на другое железо (меняли местами моноблоки, забирали в ремонт и тп.). Все решается только переносом папки и ключа на новый компьютер.

Эркипер Сторехаусович
24.06.2016, 22:47
Господа "просто переносящие папки" , сотрите значение параметра в инишнике LicenseCPUID=