Склад: терминалы сбора данных по Wi-Fi — почему сервер должен стоять на площадке

MAATRIX

Кладовщик подносит терминал сбора данных к паллете, сканирует штрихкод — и на короткое время экран показывает крутящийся значок вместо ответа. За этой паузой не мистика, а обычный сетевой запрос: ТСД по Wi-Fi спрашивает сервер WMS, что делать с этим кодом, и ждёт ответа, прежде чем кладовщик сможет сделать следующий шаг. Если сервер, который обрабатывает эти запросы, стоит не в серверной по соседству, а где-то в облаке за интернет-каналом, каждое такое сканирование проходит через внешнюю сеть — и на потоке из сотен операций в час эта разница накапливается в очереди у стеллажей и на упаковочных столах. Формулировка решения простая: сервер, обрабатывающий сканирования, должен физически находиться в локальной сети склада, а не за пределами площадки.

Как терминал сбора данных общается с сервером: цикл на каждое сканирование

ТСД — будь то промышленный Zebra, Honeywell или более бюджетный аналог на Android — сам по себе почти ничего не решает. Он читает штрихкод или RFID-метку, но не знает, куда положить товар, свободна ли ячейка, соответствует ли код текущему заданию сборщика. Всё это знает WMS — система управления складом, точнее её серверная часть с базой данных. Клиентское приложение на терминале при каждом скане отправляет запрос по Wi-Fi на сервер и ждёт ответа, прежде чем показать сборщику следующий шаг.

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

За одну складскую операцию терминал обычно делает не один запрос, а несколько:

• Приёмка. Скан короба, скан ячейки размещения, подтверждение количества — три-четыре обращения к серверу на одну позицию.
• Отбор (пикинг). Получение задания, скан ячейки, скан товара, подтверждение — цикл повторяется на каждую строку заказа, а в высокий сезон это могут быть сотни строк на одного сборщика за смену.
• Перемещение между зонами. Скан «откуда», скан «куда» — два запроса плюс проверка совместимости зоны хранения.
• Инвентаризация. Пересчёт ячейки с подтверждением расхождений — здесь запросов особенно много, потому что процесс идёт построчно.

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

Путь пакета до облака и обратно: из чего складывается задержка

Когда WMS-сервер стоит в облаке где-то в интернете, запрос от ТСД проходит длинную цепочку узлов, прежде чем дойдёт до места обработки: точка доступа Wi-Fi на складе, внутренний коммутатор и роутер, оборудование интернет-провайдера, магистральные узлы между провайдером склада и дата-центром, где стоит арендованный сервер, и только потом — сам сервер, который обрабатывает запрос и формирует ответ. Обратный путь пакет проходит той же дорогой в противоположном направлении.

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

Локальный сервер убирает почти всю эту цепочку. Запрос от ТСД идёт через точку доступа и коммутатор сразу на сервер, который стоит в той же локальной сети, — без выхода в интернет вообще. Остаётся только внутренняя сеть склада, где задержка определяется вашим же оборудованием, а не качеством канала до внешнего провайдера и загрузкой чужих магистральных узлов. Ориентировочные порядки задержек между разными типами соединений (локальная сеть, разные страны, разные провайдеры) собраны в отдельном справочном материале про задержку между локациями — конкретные цифры зависят от вашей сети и провайдера, но сам порядок разницы между «внутри одного здания» и «через интернет до другого дата-центра» иллюстративен и для складского сценария.

Почему это критично именно при высокой интенсивности операций

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

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

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

Архитектура: сервер в локальной сети склада плюс аренда в облаке для того, что не горит

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

Минимальный набор сервисов на локальном сервере выглядит примерно так:

services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_DB: wms
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - wms_data:/var/lib/postgresql/data
    secrets: [db_password]

  wms_backend:
    build: ./wms
    restart: unless-stopped
    depends_on: [db]
    ports: ["8080:8080"]   # доступен только во внутренней сети склада
    env_file: .env

  sync_worker:
    build: ./sync
    restart: unless-stopped
    depends_on: [db]
    environment:
      CLOUD_ENDPOINT: "https://backoffice.example-warehouse.ru"

volumes: { wms_data: }
secrets: { db_password: { file: ./secrets/db_password.txt } }

Второй уровень — арендованный сервер в облаке, который выполняет роль центрального узла, а не операционного: туда стекается сводная отчётность по остаткам, если у компании несколько складов, туда уходит резервная копия базы данных, оттуда идёт интеграция с 1С или другой ERP-системой, EDI-обмен с контрагентами и доступ владельца бизнеса к цифрам из любой точки. Это тот же паттерн, что и в случае с работой кассы ресторана без интернета — критичная к задержке операционка живёт локально, а всё, что можно синхронизировать раз в минуту или раз в час, спокойно живёт в облаке.

Синхронизация между уровнями строится по паттерну отложенной очереди (outbox): каждая операция получает уникальный идентификатор сразу при создании, а фоновый воркер периодически отправляет накопившиеся записи в облако. Если интернет на складе временно пропал — для площадок на окраине города или в промзоне это не редкость — WMS продолжает работать автономно: приёмка, отбор и отгрузка идут по локальной сети, а синхронизация просто откладывается до восстановления канала.

Wi-Fi на складе: сеть, которая должна выдержать сотни терминалов одновременно

Локальный сервер снимает задержку до внешнего интернета, но не решает всё сам по себе — Wi-Fi-сеть склада тоже должна быть спроектирована под реальную нагрузку, а не собрана из бытовых роутеров, как иногда бывает на небольших площадках. Несколько моментов, которые стоит проверить отдельно от переноса сервера:

• Плотность и покрытие точек доступа. Металлические стеллажи создают мёртвые зоны и переотражения сигнала — точку доступа, которая отлично работает в пустом помещении, нужно проверять уже в заполненном складе. Обычная практика — обследование площадки (site survey) с реальными стеллажами, а не по чертежу пустого здания.
• Бесшовный роуминг. Сборщик перемещается между зонами покрытия разных точек доступа в течение смены. Если переключение происходит с разрывом сессии, ТСД теряет соединение на несколько секунд и иногда требует повторной авторизации — это сбивает темп работы сильнее, чем сама задержка до сервера. Точки доступа с поддержкой быстрого роуминга (802.11r/k/v) и единым контроллером решают проблему; бытовые роутеры без централизованного управления — нет.
• Отдельный VLAN и приоритизация трафика ТСД. Гостевой Wi-Fi, видеонаблюдение и терминалы сбора данных не должны делить один широковещательный домен без приоритетов. Выделенный VLAN под ТСД с QoS для трафика WMS снижает влияние остального сетевого трафика на скорость отклика сканеров.
• Проводной backbone между точками доступа. Соединение точек между собой по воздуху добавляет лишний сегмент и задержку на каждом хопе. Проводное подключение каждой точки к коммутатору надёжнее и предсказуемее, особенно на складе с десятками точек.
• Диапазон частот. 5 ГГц даёт меньше помех и обычно выше пропускную способность, но хуже проходит сквозь стеллажи и перекрытия — на больших складах часто используют оба диапазона на разных участках, подбирая по факту после обследования.

Плохо спроектированная Wi-Fi-сеть может свести на нет весь выигрыш от локального сервера: даже если сервер стоит в соседней комнате, разрывы соединения и мёртвые зоны создают свою собственную задержку, никак не связанную с расположением сервера. Смежная тема — снижение задержки на уровне сетевого канала в целом, она разобрана в материале про уменьшение задержки VPN-соединения до сервера: часть тех же принципов (минимизация числа сетевых хопов, приоритизация критичного трафика) применима и к внутренней сети склада.

С чего начать перенос WMS-сервера на площадку

Переход не требует замены всего сразу — разумнее двигаться поэтапно:

1. Проверьте, где сейчас физически обрабатываются запросы ТСД. Уточните у поставщика WMS, где стоит сервер сканирований — на площадке, в региональном дата-центре или в облаке, возможно, за рубежом. Это определяет масштаб задачи: перенести существующий бэкенд, развернуть его копию локально или выбрать другое решение.
2. Поставьте локальный сервер и разверните WMS-бэкенд с базой данных. Ресурсы для склада среднего размера обычно не требуют дорогого железа — нагрузка определяется количеством одновременных ТСД и интенсивностью сканирований, а не объёмом хранимых данных.
3. Проведите обследование Wi-Fi-сети под фактическую загрузку. С товаром на стеллажах, а не по пустому помещению — зоны мёртвого сигнала часто выявляются только на заполненном складе.
4. Настройте VLAN, QoS и роуминг между точками доступа. Отдельный сегмент под трафик ТСД с приоритетом для WMS-запросов и бесшовное переключение — без этого нагрузка от остального трафика склада будет мешать даже при локальном сервере.
5. Переведите ТСД на локальный адрес сервера. Приложение на терминалах должно обращаться к внутреннему IP локального сервера, а не к внешнему адресу в облаке — иначе весь перенос теряет смысл.
6. Настройте синхронизацию с арендованным облачным узлом. Для сводной отчётности, резервного копирования, интеграции с ERP и доступа к цифрам вне площадки — по паттерну отложенной очереди, описанному выше.
7. Прогоните тест под пиковой нагрузкой. Соберите на складе столько ТСД, сколько работает в самую загруженную смену, и проверьте отклик сервера и стабильность Wi-Fi именно в этот момент.

Частые вопросы