[ОТВЕТИТЬ]
24.03.2015 08:47
Dim
 
т.е. привязать к нему место хранения, кассы и подчиненные сервера одновременно? раньше где-то слышал, что типа к СГО кассы привязывать нельзя.
24.03.2015 08:51
Mtirt
 
Если очень хочется - то можно. Просто надо это предусмотреть в лицензии.
Onesoft как-то описывал, что у него к СГО около 100 касс привязано.
Только подумай, что будет с конвертерами, и банковскими картами, если кассы и сервер физически в разных местах.
24.03.2015 09:03
Dim
 
кассы и сервер в одной подсети. просто не вижу смысла поднимать 2 сервера (СГО и СМ) в одной подсетке. на второй магазин заведу сервер магазина свой
24.03.2015 09:05
Dim
 
в лицензии: количество терминалов - 6, управление серверами - включено
24.03.2015 11:23
Павел Сосновских
 
Будет работать.
Должно даже в несколько уровней работать(суперСГО-СГО-СМ), кассы на любом уровне подключать можно, но, правда, никто не тестировал такие схемы под реальными нагрузками.
25.03.2015 05:21
Eugin_S
 
у меня к СГО 300 касс подключено, серверов магазинов нет вообще. 5 лет так работаем.
25.03.2015 07:52
Dim
 
интересует именно схема, когда с СГО подключены кассы и одновременно сервер магазина
25.03.2015 19:23
genyas
 
У меня три магазина к СГО подтянуты и еще 17 касс , к нему же . Полет нормальный .
29.05.2015 12:30
TEHb2
 
Цитата:
Eugin_S у меня к СГО 300 касс подключено, серверов магазинов нет вообще. 5 лет так работаем.
А не могли бы плюсы, минусы описать.
Сейчас тоже задумались над этим. Убрать УКМ-сервера в магазинах и всё привязать к СГО.
Я пока вижу нагрузку на сеть и сервер.
Из плюсов - сокращение лицензий.

Коли уж вы так долго работаете в таком режиме, то наверно знаете, с чем придется сталкиваться.
29.05.2015 12:46
Mtirt
 
А зачем вы хотите убирать УКм-сервера в магазинах?
Что вам это даст?
Кроме стоимости лицензий.
29.05.2015 14:52
Onesoft
 
Плюсы:
1. не нужна лицензия (экономия бабла);
2. не нужен сервер (экономия бабла);
3. не нужно апгрейдить на нём УКМ при накатывании новой версии/сервис-пака (экономия времени: существенный плюс при обновлении всей системы УКМ на СГО и всех кассах за одну ночь - теоретически достижима неограниченная масштабируемость);
4. не нужно обслуживать сервер и БД (быкап). (Который в случае дизастера надо поднимать из быкапа изолированно от касс, синхронизировать сначала с СГО, затем с кассами, дополнительно "подружив" журналы версий изменений данных).

В общем, как бы снижение стоимости владения - самой важной характеристики эффективности работы IT департмента.

Минусы:
1. количество условных каналов связи между СГО и кассами становится равным количеству касс в магазине, помноженному на три (ukmserver-канал между СГО и СМ и два MySQL-каналы - на IN и на OUT. А ещё бывают отдельные каналы на всякие онлайн-сервисы: подарочные карты, системы лояльности и т.п.). Плюс к этому вылезают "внутренние" каналы (контроль остатков, например). В общем, быть готовым к тому, что на СГО кроме ukmservice и apache2ukm больше ничего не будет работать - никакие серверы прайсчекеров, печати кассовых документов, транспорта данных и т.п. Ибо пул TCP/IP будет в дефиците;
2. товары, цены и весы теперь грузятся с СГО - возрастает нагрузка на интернет-канал;
3. из п.1 и п.2 так же следует, что существенно возрастает нагрузка на БД СГО. Высокопроизводительный storage, поиск оптимальных настроек MySQL. Необходимость поиска оптимальных настроек "Резерв каналов на экспорт/импорт". Цикл прогрузки данными всех касс увеличивается до нескольких минут (то есть, например, одноразовые дисконтные карты и суммовые купоны гасятся на всех кассах не сразу). В функционале "Клиенты" рекомендовано отказаться о репликации балансов карт - только "запросом к серверу".
4. перезаливка кассы в магазине требует ухищрений для скачивания дистрибутива кассы, например, использование http сервера на соседней кассе или поднимать локальный PXE сервер. Саму флешку, в принципе, можно залить на любом компе директора/зама/охранника;
5. перезалитая в магазине касса существенно дольше прогружает товары, цены, клиенты и их карты, дисконтные карты, стоп-листы и т.п. Выручает ухищрение типа заливки БД на виртуальной кассе в офисе, её архивирование 7z и пересылка по http на кассу в магазин. У нас это занимает максимум три часа на всю процедуру против шести часов прогрузки традиционным способом.
6. Ну и обновление касс несколько сложнее происходит: предварительная загрузка обновлений на кассы очередями по несколько касс (не всем скопом), да и после этого не гарантируется, что при запуске обновления скрипты обновления не захотят перезакачать пакеты обновления (напарывался на это неоднократно - тоже свой костыль пришлось сделать против этого).
7. Нагрузка на ЦП СГО по ukmserver и apache2ukm возрастёт: быть готовым к тому, что на СГО кроме ukmservice и apache2ukm больше ничего не будет работать - никакие серверы прайсчекеров, печати кассовых документов, транспорта данных и т.п.

Минусов как бы больше, чем плюсов, но формула расчёта выгоды будет условно такой:
(плюсы * количество СМов) / (минусы * максимальное количество касс в магазине)

С точки зрения управления всем этим кассовым хозяйством схема "СГО-СМ-касса" более правильная. Но становится громоздкой, если касс в магазинах не много. Однозначно схема "СГО-касса" не годится для магазинов, где касс больше четырёх-пяти и если таких магазинов более сотни. Группировка касс в СМы позволяет экономить каналы обмена данными с СГО.
С другой стороны, у "Сервис Плюса" запланированы на этот год работы по исследованию "кластерного решения для СГО", что-нибудь типа объединения нескольких "UKM Object Server" с арбитратором в один "логический" СГО. Ну и со всеми вытекающими новыми плюсами: масштабируемость, отказоустойчивость. А после переноса хранилища БД СГО на какой-нибудь Percona XtraDB Cluster или MariaDB Galera Cluster и работа c "кластером СГО" через HAProxy с распределением нагрузки по нодам кластера БД - и остальные минусы становятся пренебрежимо малыми: повторное скачивание пакетов обновлений поверх предварительно скачанных - пофиксят, а прогрузку касс данными когда-нибудь реализуют с соседней кассы...

О нас:
310 касс в 149 магазинах работают напрямую с СГО. Ещё 37 касс в 16 магазинах пока работают через СМы (переводим кассы на СГО по мере выгорания СМов).
СГО (ukmservice, apache2ukm, транспорт обмена данными между ТС и УКМ): отдельный сервер Win2k8r2, 8 Гб RAM, 24 ядра CPU;
+ отдельно сервер БД (Percona Server 5.6.23-72.1): CentOS 7.0, 32 Гб RAM, 8 ядер CPU, 2 TB storage на SSD-RAID.
Всё это в ЦОДе. Каналы между ЦОД и кассами дублированы (резервированы разными провайдерами), ширина - не менее 1,6 (в подавляющем большинстве - 2) МБит/с. Для различных серверов отчётности, BI, информационных киосков, всяких выгрузок наружу и т.п. используются slave-реплики с БД СГО. Сервер прайс-чекеров, сервер печати кассовых документов - отдельные серверы в офисной серверной, неспешно ждут своего переезда в ЦОД.
В планах: "кластерное решение СГО". В более отдалённой перспективе - "кластерное решение СУБД" (успешно протестировано решение 3-node PXC на стенде с "лабораторной" нагрузкой).
31.05.2015 23:03
TEHb2
 
Цитата:
Mtirt А зачем вы хотите убирать УКм-сервера в магазинах?
Что вам это даст?
Кроме стоимости лицензий.
В том то и дело, что я особо не хочу. Но руководство интересуется. Для них цель ясная - сэкономить. То что это нагружается работой IT-отдел - это уже другой вопрос.
Поэтому хотелось бы разобраться.

Огромное спасибо, Onesoft.
В общем то, об этом я думал.
Нагрузка канала, но экономия лицензий.

До конца еще не представляю, как настроить это всё надо бдет. Да и привычные способы администрирования кажутся ближе.
Опции темы


Часовой пояс GMT +3, время: 03:47.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.