Представим запуск WMS на складе с 20 одновременными работниками и 200 тыс. SKU. Это условный пример: два числа еще не объясняют требование интегратора к двухсокетному серверу и 256 ГБ памяти. Для проверки спецификации нужен профиль операций, данных и подключений.
В статье разбираем, из чего состоит WMS-инфраструктура и как считать конфигурацию от задачи: числа SKU, операций в час, одновременных пользователей, а не от типового ценника.
Из каких компонентов состоит WMS-инфраструктура
В WMS выделяют логические роли СУБД и приложения, а пользовательский доступ зависит от продукта. Роли могут работать в отдельных ВМ или на выделенных машинах по требованиям поставщика. Физическое разделение не заменяет отказоустойчивость базы, приложения и хранения.
В базе хранятся SKU, ячейки, контрагенты и журнал операций. Поддерживаемый движок и версию задает WMS: это могут быть SQL Server, PostgreSQL или другие системы. Подтверждение задания с ТСД создает короткие транзакции, а отчеты конкурируют за ресурсы и блокировки. Для расчета измеряют их совместный профиль, а не только объем данных.
Приложение выполняет бизнес-логику, API, очереди и обмен с 1С, ERP, маркетплейсами и транспортными системами. У 1С:WMS учитывают процессы кластера 1С и фоновые задания. Для сервера 1С WMS проверяют производительность отдельного потока, параллельность и задержки интеграций. Количество сессий само по себе не определяет вычислительную нагрузку.
ТСД используют способ, поддерживаемый WMS и ОС устройства: мобильный клиент, web/API или терминальный доступ. RDS нужен только при подтвержденном сценарии. В этом случае отдельно рассчитывают ресурсы сессий, Windows Server CAL и RDS CAL. Для любых беспроводных клиентов проверяют складское покрытие и поведение при разрыве связи.
Совмещение ролей допустимо, если его поддерживает продукт и подтверждает тест. Изоляция ресурсов облегчает управление, но отказ единственной базы все равно может остановить операции. Для критичных процессов проверяют всю цепочку, включая общую платформу виртуализации и хранилище.
От чего зависит нагрузка
Параметры склада
Соберите число активных SKU и операции в пиковый час: приемку, отгрузку, инвентаризацию, перемещения и кросс-докинг. Добавьте сложность ячеечной адресации, волновую сборку, конвейеры и сортировщики. Эти параметры формируют профиль нагрузки: не все операции имеют одинаковую стоимость для СУБД.
SKU описывают каталог, но не стоимость операций. Укажите состав документов, частоту подтверждений и ограничения времени ответа. Границы профилей согласуйте по статистике склада и прогнозу роста, а не универсальным диапазонам SKU.
Параметры пользователей
Посчитайте максимальные одновременные сессии в загруженный час. Укажите сменность и режим 24/7, праздничные пики, подключение ТСД и весов. Важно различать подключенное устройство и активный поток операций.
BI-запросы и выгрузки в 1С и ERP проверяют совместно с операциями смены. Пиковый профиль включает инвентаризацию, сезон, отчетность и восстановление обмена после простоя.
Расчет объединяет данные, операции, сессии и интеграции: по этому профилю проверяют ресурсы спецификации.
Как считать конфигурацию сервера БД и сервера приложений
CPU и память подбирают по версии WMS/СУБД и пиковому тесту конкретного процессора. Универсального минимума 3 ГГц или восемь ядер нет. Разделите полный объем базы, активный набор и память ОС, СУБД и запросов. При активном наборе 300 ГБ и запасе 30% только для него требуется 390 ГБ. Меньшую RAM подтверждают тестом. При сравнении с серверами под СУБД оценивают задержки хранения и журналов, ресурс и защиту накопителей. NVMe RAID 10 и отдельные журналы выбирают по нагрузке. Сеть рассчитывают по обмену, репликации и бэкапам.
Для приложения проверьте масштабирование потоков, время ответа отдельных операций, фоновые задания и интеграции. И число ядер, и производительность одного ядра могут быть существенны. Объем памяти, диски и сеть определяют по измерению выбранной WMS. Резервные интерфейсы работают только при согласованной схеме сети и проверенном переключении.
Таблица задает программу проверки, а не обещает производительность по числу SKU. Исходные профили условны: их численные границы и параметры стенда согласуют по статистике склада. Для каждой строки фиксируют версию продукта, процессор, данные и критерии приемки.
Профиль склада | Ядра CPU | ОЗУ | Диски | Сеть |
|---|---|---|---|---|
Небольшой поток операций | По тесту операций | Активный набор + системные расходы | Задержки записи и журналов | По обмену и резервированию |
Совместный пик смены и интеграций | По параллельности и задержкам | По конкурентным запросам | Тест данных, журналов и отчетов | По пику обмена |
Волны сборки, отчеты, автоматика | По совмещенному пиковому тесту | По активному набору и росту | Проверка задержек и отказа | Репликация, обмен, восстановление |
Спецификация проверяема, если к каждому ресурсу приложен результат теста или расчет. Укажите не только среднюю скорость, но и p95/p99 времени ответа, условия одновременного запуска отчетов, обменов и складских операций. Прогноз роста храните отдельно от текущей нагрузки.
Отказоустойчивость и резервирование
Что закладывать в архитектуру
Для автоматического переключения SQL Server Availability Groups проверяют редакцию и версию, synchronous commit, готовность синхронизированной реплики и quorum. Поддерживаемая схема зависит от платформы. Для Patroni выбирают режим репликации и допустимую потерю записей. Асинхронное копирование не гарантирует нулевой RPO. Синхронные режимы оценивают вместе с доступностью записи при потере реплики. Испытание должно проверить также повторное подключение WMS и завершение незаконченных операций.
Резервирование приложения допускается по архитектуре продукта. Балансировщик или active-passive не обеспечивают непрерывность автоматически: проверяют хранение сессий, очереди, повтор операций и состояние интеграций. Обслуживание одного узла не должно нарушать согласованный сценарий работы склада.
RPO и RTO согласуют с владельцем процессов по допустимой потере заданий и времени восстановления. Режим 24/7 не задает универсальных 15 минут или двух часов. Проверьте восстановление базы и приложения из резервной копии, целостность остатков и заданий, сверку с внешними системами. Результат теста должен включать весь путь до возобновления операций.
Типичные ошибки расчета
- Расчет по средней смене. Измерьте сезонный пик и совмещение заданий. Сравните p95/p99 ответа с согласованным SLA.
- Память рассчитана по полному размеру базы. Определите активный набор и конкуренцию запросов. Недостаток памяти и дисковую нагрузку подтвердите телеметрией.
- Разделение ролей считают готовой HA. Проверьте отказ базы, приложения, хранения и общих узлов виртуализации.
- Wi-Fi оценивают по офисному тесту. Проверьте покрытие, помехи, roaming ТСД, емкость и QoS в складе. Отдельный SSID/VLAN не создает радиоресурс.
- Забыты интеграционные задания. Измерьте обмен с 1С, ERP и маркетплейсами, пакетную обработку и повтор после сбоя. Включите их в пиковый профиль.
Что предложить интегратору на сверку
Перед спецификацией согласуйте комплект доказательств. Шесть вопросов помогают проверить расчет без повторного подбора по общему прайс-листу:
Какие данные и операции использованы в тесте? Укажите активный набор, состав SKU и характер обращений.
Как воспроизведен пик? Покажите совместную нагрузку смены, автоматики, отчетов и обменов.
Какие показатели приняты? Запишите время ответа, ошибки и пропускную способность каждого критичного сценария.
Как учтен рост? Разделите увеличение данных, пользователей и интенсивности операций на согласованном горизонте.
Как проверено восстановление? Сопоставьте фактический результат с согласованными RPO/RTO.
Кто подтверждает приемку? Закрепите версии, условия стенда, метод теста и ответственность за отклонения.
Заключение
Выбор сервера для WMS начинается с профиля склада: активные SKU, состав операций, пиковые сессии и интеграции. Дальше выполните последовательную проверку:
- Согласуйте поддерживаемые версии и роли системы.
- Воспроизведите складской пик на выбранном стенде.
- Подберите CPU, память, хранение и сеть по измерениям.
- Проверьте доступ ТСД и поведение при разрыве связи.
- Испытайте отказ, восстановление и целостность операций.
- Зафиксируйте рост, критерии приемки и регламент.
Если выбран RDS-сценарий, терминальные серверы включите в расчет сессий и лицензий, а не добавляйте по умолчанию. Для мобильного клиента испытайте его на поддерживаемой модели ТСД и в рабочих проходах склада.
Передайте интегратору статистику, профиль данных и целевые показатели. Сопоставьте спецификацию с приемкой и согласованным ростом.