Инфраструктура INTEKEY WMS

Каждое требование помечено уровнем:

Типоразмеры площадки

Конфигурации даны тремя типоразмерами. Выберите свой по фактическому профилю склада — все таблицы ниже используют эти обозначения.

Схема ниже нужна не для сведения, а потому что из неё следуют все требования документа.

Это тоже часть требований: перечисленное ниже не нужно закладывать в бюджет проекта.

3.1 Два контура: продуктивный и тестовый Обязательно

Заказчик выделяет две виртуальные машины — PROD и TEST — и предоставляет Intekey доступ к обеим. Это не «вторая копия для пользователей»: это инфраструктура процесса поставки обновлений. Обновления INTEKEY WMS ставятся нашим инструментом Intekey Deployer, и ему нужны оба контура.

Дополнительно TEST-контур используется для обучения персонала заказчика и для приёмки доработок, но основное его назначение техническое: без него поставка обновлений штатным способом невозможна.

Условия, обязательные для TEST-контура:

• TEST изолирован от PROD: отдельная виртуальная машина, отдельная база, отдельные учётные записи обмена.
• TEST подключается к тестовой базе 1С / ERP, а не к продуктивной — см. раздел 11.
• Периодически на TEST разворачивается обезличенная копия продуктивной базы, иначе проверка обновления не показательна.
• Печать с TEST направляется на выделенный принтер или в файл, чтобы «тестовые» этикетки не попадали в цех.

Оба контура должны быть доступны Intekey через защищённый туннель между инфраструктурами — см. раздел 16.

3.2 Сервер приложений Обязательно

3.3 Сервер базы данных Обязательно

• Блок random 8K, смешанная нагрузка 70 % чтение / 30 % запись.
• Задержка < 2 мс на указанном уровне IOPS. IOPS в отрыве от задержки критерием не являются: на большой глубине очереди высокие IOPS достигаются ценой задержки в десятки миллисекунд.
• Замер на целевой ОС Linux и на том томе и в той ёмкости, которые уйдут под базу, а не на временном разделе.
• Тестовый файл не менее 64 ГБ: на файле в 1–2 ГБ измеряется кэш накопителя и кэш операционной системы, а не диск.
• Прямой доступ в обход кэша ОС (--direct=1), длительность прогона не менее 300 секунд.

Проверочные команды приведены ниже — fio и штатная утилита PostgreSQL. Вывода этих трёх команд достаточно, чтобы Intekey подтвердил типоразмер.

# основной замер: random 8K, 70/30, 5 минут
fio --name=rnd8k --filename=/var/lib/postgresql/fiotest --size=64G \
    --bs=8k --rw=randrw --rwmixread=70 --ioengine=libaio --direct=1 \
    --iodepth=32 --numjobs=4 --group_reporting --runtime=300 --time_based \
    --percentile_list=50:95:99:99.9

# задержка одиночной операции
fio --name=lat --filename=/var/lib/postgresql/fiotest --size=64G \
    --bs=8k --rw=randread --ioengine=libaio --direct=1 \
    --iodepth=1 --numjobs=1 --runtime=60 --time_based

# фиксация коммита WAL — самый показательный тест для PostgreSQL
/usr/lib/postgresql/16/bin/pg_test_fsync

3.4 Совмещение и виртуализация Рекомендуется

• Для S и M сервер приложений и сервер БД допустимо разместить на одном физическом хосте, суммировав требования (для M это 16 потоков / 128 ГБ RAM / 1 ТБ NVMe). Часто это выгоднее двух хостов и быстрее — исчезает сетевая задержка между приложением и базой.
• Виртуализация (VMware, Proxmox, Hyper-V, KVM) допускается при условиях: CPU и RAM зарезервированы без overcommit, диск не thin-provisioned без гарантии IOPS, машина не мигрирует между хостами в рабочую смену.
• Снапшот виртуальной машины не является резервной копией базы — см. раздел 14.

3.5 Сеть между приложением и базой Обязательно

Причина в характере нагрузки: одна операция ТСД порождает десятки SQL-запросов, и лишние 5 мс на каждом запросе превращаются в лишние секунды на каждом сканировании.

Рекомендуется На рабочих местах приёмки и контроля отгрузки — USB-сканер штрихкодов в режиме эмуляции клавиатуры.

• Рекомендуется резервный фонд ТСД 10–15 % от рабочего парка — на поломки, зарядку и потери.
• Рекомендуется защита не ниже IP54 и киоск-режим или MDM: терминал открывается сразу на экране WMS, посторонние приложения недоступны.
• Опционально для холодных зон — модели с рабочей температурой до −20 °C и подогревом окна сканера.

6.1 Рекомендуемые модели

Технических ограничений по производителям нет — подойдёт любой Android-терминал, отвечающий требованиям выше. Но есть ограничения эксплуатационные, сформированные опытом внедрений: по надёжности, поведению сканера в складских условиях и ремонтопригодности мы рекомендуем модели:

Терминалы других производителей допустимы, но их поведение в эксплуатации мы не подтверждаем практикой.

Обязательно Это главный технический риск проекта. Кладовщик работает на ходу, между металлическими стеллажами, заполненными товаром. Сигнал, уверенный на пустом складе, пропадает на заполненном.

Обязательно Радиообследование (site survey) на заполненном складе до запуска и повторно — после изменения схемы хранения или установки новых стеллажей. Обследование пустого склада результата не даёт.

Порты внутри контура заказчика

Значения расчётные, по типовому профилю складских операций. Для площадок класса L уточняются нагрузочным тестом на этапе пилота.

Ориентировочная оценка полосы внутри склада:

Для среднего склада — 30 ТСД и 20 АРМ — получается ≈ 60 Мбит/с.

Что работает без интернета

Полностью весь склад: приёмка, размещение, подбор, комплектация, контроль, отгрузка, перемещения, инвентаризация, печать этикеток и документов. Система размещена на площадке заказчика и от внешнего канала не зависит.

Что перестаёт работать

Требования к каналу

11.1 Интеграция с 1С поддерживается

INTEKEY WMS штатно интегрируется с 1С: «Управление торговлей», «ERP Управление предприятием», «Комплексная автоматизация», «Управление нашей фирмой», а также с отраслевыми и самописными конфигурациями. Отдельный коннектор покупать не нужно — обмен входит в состав системы.

Варианты обмена

Что требуется от заказчика Обязательно

Нагрузка. Пакет на 1 000 строк — 1–5 МБ. Регламентный обмен раз в 5–15 минут на канале незаметен. Для обмена «онлайн по событию» требуется RTT до сервера 1С менее 200 мс.

11.2 Прочие интеграции

Опционально Печать через FTP-принт-сервер и печать ZPL по HTTP поддерживаются, если такая схема уже используется у заказчика. Подходят Zebra, TSC, Honeywell, Godex, Proton и аналоги.

Рекомендуется Отдельная питающая линия для серверного оборудования. Учитывайте: при пропадании питания точки доступа гаснут раньше сервера — ТСД встанут первыми.

Обязательно

Рекомендуется

Журналы приложения и СУБД хранить не менее 30 суток и предоставлять по запросу при обращении в поддержку — без них разбор инцидента сводится к пересказу произошедшего.

16.1 Защищённый туннель между инфраструктурами Обязательно

Доступ поддержки Intekey организуется не набором персональных подключений к отдельным серверам, а одним защищённым туннелем между инфраструктурой заказчика и инфраструктурой Intekey. Технология выбирается по стандартам ИБ заказчика и возможностям его оборудования.

Туннель поднимается совместно на этапе подготовки площадки и проверяется с обеих сторон до начала опытной эксплуатации.

16.2 Доступ для Intekey Deployer Обязательно

16.3 Прочие требования безопасности Обязательно

Рекомендуется HTTPS с сертификатом заказчика или Let's Encrypt при наличии белого IP; интеграция аутентификации с Active Directory, если этого требует политика безопасности.

Сводная таблица для принятия решений по бюджету: слева — сэкономленное, справа — то, что заказчик увидит в эксплуатации.

Заполняется совместно до начала опытной эксплуатации.