Это решение для внутреннего пользования.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. Скорее о 4-5 вендорах, не более 10 моделей на каждого вендора.
Согласен, если говорить о поддержке гораздо более широкого перечня моделей и более широкого набора конечных образов систем, скорее всего, нужно будет смотреть в другую сторону.
Но данное решение хорошо вписывается в текущие потребности.
Это решение для внутреннего пользования. Список моделей ограничивается только тем, что нам требуется в данный момент.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. В начале статьи указано, что решение придется адаптировать под каждый новый сервер (новый вендор или новая модель с отличающимся функционалом). Как правило, это не чаще раза в год.
Не пробовал, но периодически, я смотрел продукты, которые выходили.
Я думаю, преимущества нашего решения:
1) В целом небольшая база кодовая база. Все решение вполне может поддерживать один человек. В любое время можно добавить новый функционал.
2) Из доступных продуктов не все могут обеспечивать полный перечень необходимых функций (обновление прошивок, настройка ilo/idrac, прочее).
Я думаю, это точно было бы не проще.
Все равно пришлось бы делать универсальный pxe-live образ, скрипты для взаимодействия с различными подсистемами и прочее.
Плюс, Ansible, вроде, появился в 2012. А я начал работать над моим решением приблизительно в это же время.
С дампом не все так просто. В дампе очень много служебной информации USB, USB-шина не позволяет лить информацию просто так, ибо облачает ее в свои спецификации. Также было стойкое ощущение, что прошивка не последняя и придется снова что-то делать.
Не майнили, но идеи были. Есть золотое правило: магазин должен продавать, так что мы кровно заинтересованы в том, чтобы оборудование работало для задач магазина.
Если бы я дружил с Windows, то, наверное, так бы и действовал, но увы, я с Windows – уверенный пользователь Excel.
Да, статистика есть. Благодаря полученным результатам по перепрошивке, научились снимать настройки со сканера, так что теперь можем гарантировать, что в магазине не будет проблем.
При закупке, руководствовались текущей задачей – продажей алкогольной продукции, и на тот момент она решалась успешно. Так что да, отчасти наследие.
1. Мы не работаем со сканером как с клавиатурой, нам нужно знать, какой тип штрихкода у нас на входе.
2. Сканер покупали достаточно давно, на тот момент задачи решались на USB без проблем. Насчет использования RS232 и внешних блоков питания. Это отчасти вопрос религий. Для внешнего блока питания требуется дополнительная розетка в ИБП, укладка проводов становится сложной, поскольку надо вести в два места. Оборудование на RS232 плохо дисковерится, надо знать, в какой порт включено устройство, иначе будет аффект на другие устройства (яркий пример – дисплей покупателя: если дисплею что-то не нравится, он начинает писать иероглифами), ну и так далее.
Изначально сканеры брали для продажи алкогольной продукции, это было более 5 лет назад. Речи про инверсный DM тогда не шло.
Годы поставок сканеров разные, в продуктивной среде у нас было как минимум 8 версий прошивок. Пришлось выравнивать. Также у нас есть процедура Patch Management, в соответствии с ней мы всегда работаем на последних версиях.
Мы стараемся использовать рекомендованные и опробованные библиотеки. Однако сталкивались с рядом трудностей на Angular. Часть кейсов мы решаем самостоятельно или используем преимущества поддержки вендора.
По поводу scope и scope_id возможно стоит сделать два запроса (но это решение прямое и в лоб – без погружения в задачу)
У нас используются различные вариации, а так же в ряде случаев для машинного взаимодействия
Одна из ярких альтернатив при использовании API-GW — связка Gravitee APIM + Gravitee Access Management. В целом можно сказать это комплексное решение.
Так же возможна связка APIGEE + Keycloak — для высоконагруженных проектов, где есть монетизация.
Опять же каждый решает сам по применимости к своему стеку и всегда есть альтернатива
Несомненно, каждый проект или продукт в праве выбирать, что ему необходимо и требуется. Очень распространённый кейс, когда keycloak используется в связке с AD или ADFS и сервисом дообогащения данных из других ИС
Нет такая проблема не возникала, т.к при первичной настройке мы использовали кластеризацию настроек и выделяли опытным путем подобранное количество ядер и памяти, а так же ряд других настроек оптимизированных для нашей инфраструктуры.
Мы используем два разных решения для балансировки нагрузки — для внутренних пользователей(локальная сеть) и внешних (доступ из публичных сетей). Это специализированные решения.
Возможно стоит более детально изучить проблемы на предмет тюнинга сетевого стека при использовании haproxy или иных.
Я планирую затронуть эти вопросы во второй части статьи, где будут технические детали развертывания кластера.
Есть множество вариантов почему возникает подобная проблема и основное влияние оказывает инфраструктура, в которой развернуто решение — контейнеры или ВМ и версии софта.
Спасибо за ваше постоянство!
Мы постоянно работаем над улучшением нашей механики замен. Но мы бы хотели добиться такого, чтобы замены вообще не требовались при комплектации заказов.
Спасибо за точное указание артикула товара, который вызывает постоянные проблемы. Мы уже передали эту информацию коллегам для исправления и проработки.
Про нашу WMS систему мы обязательно напишем отдельный пост! Спасибо за ваш интерес.
Как вы понимаете, размер базы данных не всегда единственный параметр, вызывающий проблемы с производительностью. Появление новых бизнес-требований заставляет задумывать об оптимизации. Например, когда необходимо сократить время ответа базы в несколько раз при формировании каких-то отчетов и выгрузок.
Исторически WMS система работала на территории склада, но со временем это стало создавать проблемы с поддержкой, когда количество складов стало увеличиваться. Поэтому все переехало в единый ЦОД и сейчас идет процесс построения геораспределенной серверной площадки, которая позволит перестать бояться неработающего ЦОДа.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. Скорее о 4-5 вендорах, не более 10 моделей на каждого вендора.
Согласен, если говорить о поддержке гораздо более широкого перечня моделей и более широкого набора конечных образов систем, скорее всего, нужно будет смотреть в другую сторону.
Но данное решение хорошо вписывается в текущие потребности.
Конечно, здесь речь не идет о поддержке абсолютно любого железа. В начале статьи указано, что решение придется адаптировать под каждый новый сервер (новый вендор или новая модель с отличающимся функционалом). Как правило, это не чаще раза в год.
Я думаю, преимущества нашего решения:
1) В целом небольшая база кодовая база. Все решение вполне может поддерживать один человек. В любое время можно добавить новый функционал.
2) Из доступных продуктов не все могут обеспечивать полный перечень необходимых функций (обновление прошивок, настройка ilo/idrac, прочее).
Все равно пришлось бы делать универсальный pxe-live образ, скрипты для взаимодействия с различными подсистемами и прочее.
Плюс, Ansible, вроде, появился в 2012. А я начал работать над моим решением приблизительно в это же время.
Да, статистика есть. Благодаря полученным результатам по перепрошивке, научились снимать настройки со сканера, так что теперь можем гарантировать, что в магазине не будет проблем.
При закупке, руководствовались текущей задачей – продажей алкогольной продукции, и на тот момент она решалась успешно. Так что да, отчасти наследие.
2. Сканер покупали достаточно давно, на тот момент задачи решались на USB без проблем. Насчет использования RS232 и внешних блоков питания. Это отчасти вопрос религий. Для внешнего блока питания требуется дополнительная розетка в ИБП, укладка проводов становится сложной, поскольку надо вести в два места. Оборудование на RS232 плохо дисковерится, надо знать, в какой порт включено устройство, иначе будет аффект на другие устройства (яркий пример – дисплей покупателя: если дисплею что-то не нравится, он начинает писать иероглифами), ну и так далее.
Годы поставок сканеров разные, в продуктивной среде у нас было как минимум 8 версий прошивок. Пришлось выравнивать. Также у нас есть процедура Patch Management, в соответствии с ней мы всегда работаем на последних версиях.
По поводу scope и scope_id возможно стоит сделать два запроса (но это решение прямое и в лоб – без погружения в задачу)
У нас используются различные вариации, а так же в ряде случаев для машинного взаимодействия
Так же возможна связка APIGEE + Keycloak — для высоконагруженных проектов, где есть монетизация.
Опять же каждый решает сам по применимости к своему стеку и всегда есть альтернатива
Мы используем два разных решения для балансировки нагрузки — для внутренних пользователей(локальная сеть) и внешних (доступ из публичных сетей). Это специализированные решения.
Возможно стоит более детально изучить проблемы на предмет тюнинга сетевого стека при использовании haproxy или иных.
Я планирую затронуть эти вопросы во второй части статьи, где будут технические детали развертывания кластера.
Есть множество вариантов почему возникает подобная проблема и основное влияние оказывает инфраструктура, в которой развернуто решение — контейнеры или ВМ и версии софта.
Мы постоянно работаем над улучшением нашей механики замен. Но мы бы хотели добиться такого, чтобы замены вообще не требовались при комплектации заказов.
Спасибо за точное указание артикула товара, который вызывает постоянные проблемы. Мы уже передали эту информацию коллегам для исправления и проработки.
Как вы понимаете, размер базы данных не всегда единственный параметр, вызывающий проблемы с производительностью. Появление новых бизнес-требований заставляет задумывать об оптимизации. Например, когда необходимо сократить время ответа базы в несколько раз при формировании каких-то отчетов и выгрузок.
Исторически WMS система работала на территории склада, но со временем это стало создавать проблемы с поддержкой, когда количество складов стало увеличиваться. Поэтому все переехало в единый ЦОД и сейчас идет процесс построения геораспределенной серверной площадки, которая позволит перестать бояться неработающего ЦОДа.