В сети из 20 магазинов пропал канал до офиса. Центральный кластер работает, резервный ЦОД тоже. Но четыре кассы в одной точке не могут провести продажу: путь к базе оборвался на последней миле.
Второй ЦОД здесь не поможет. Чтобы магазин продолжил торговать, кассовая система должна работать с локальной базой, накапливать операции, а после восстановления канала — передавать их в офис без дублей.
Сервер сам по себе не добавит приложению такой режим. Поэтому сначала проверяют автономную работу кассовой системы, затем заказывают железо.
Два ЦОД не заменяют сервер в магазине
При проектировании розничной сети нужно отдельно проверить три ситуации:
- что произойдёт после остановки центрального сервера;
- продолжит ли сеть работать при недоступности центральной площадки;
- сможет ли отдельный магазин провести продажу без связи с офисом.
Одна и та же инфраструктура не обязана одинаково отрабатывать все три ситуации. Резервирование центрального контура защищает его компоненты, но ничего не говорит о поведении кассового приложения на изолированной точке.
В кейсе EFSOL два ЦОД обслуживали кассы, 1С, склад и интернет-магазин сети из более чем 20 точек. Это пример защиты центральной инфраструктуры розничной сети. Автономность конкретной кассы при обрыве последней мили нужно проверять отдельным испытанием.
Для закупки это два разных требования: центральный контур должен переживать свои отказы, а магазин — потерю связи с ним. Границы центральной защиты разобраны в материале про уровни отказоустойчивости 1С.
Сначала отключи канал на рабочей точке
До заказа 20 локальных серверов проведи испытание в одном магазине. Кассовое приложение должно обратиться к локальной базе, сохранить продажи и возвраты без офиса, а затем возобновить обмен.
Проверка укладывается в четыре действия:
- Отключить внешний канал магазина.
- Провести продажу и возврат.
- Восстановить связь.
- Сверить центральную базу: обе операции пришли один раз, статусы и суммы совпали.
Если система не проходит этот сценарий, покупать серверы рано. Железо даст локальные вычисления и диски, но не исправит логику обмена.
Методика выбора оборудования для 1С предписывает моделировать нагрузку на том же приложении, в том же режиме и с тем же числом серверов. Версии 1С, СУБД и операционной системы тоже должны совпадать. Одиночная модель занимает от одного до трёх дней, но даёт менее точный результат. Рабочая система точнее, хотя для проверки придётся привлечь пользователей.
Для пилота бери настоящий магазин в спокойные часы. Он покажет не только загрузку процессора, но и то, переживает ли прикладная система потерю связи.
Локальный узел обслуживает одну точку, а не всю сеть
Посчитаем магазин с четырьмя кассами и локальной базой до 200 ГБ. На узле работают СУБД, серверная часть приложения, обмен и мониторинг.
Память складывается так:
- 8 ГБ — операционная система;
- 16 ГБ — СУБД;
- 8 ГБ — приложение;
- 4 ГБ — обмен и мониторинг;
- 12 ГБ — файловый кэш.
Получается 48 ГБ. Ещё 16 ГБ оставляем под открытие смены, отложенный обмен и рост базы. Итого — 64 ГБ ECC RDIMM.
Это расчётная отправная точка, а не требование 1С. Если замеры пилота покажут пик выше 52–54 ГБ, бери платформу с расширением хотя бы до 128 ГБ. Иначе запас закончится после роста базы или обновления конфигурации.
Процессор считаем по одновременно занятой работе. Допустим, четыре кассовых сеанса, обмен и одна фоновая операция могут занять шесть потоков. При целевой загрузке 75% получаем:
6 ÷ 0,75 = 8 физических ядер
По методике 1С на итоговую скорость сильнее всего влияют процессор, дисковый массив и объём памяти. Поэтому восемь быстрых ядер здесь разумнее большого числа медленных: точке не нужно обслуживать десятки виртуальных машин.
Под ОС закладываем 100 ГБ, под базу — 200 ГБ, под журналы и временные файлы — ещё 100 ГБ. Рабочая потребность равна 400 ГБ.
Два NVMe по 960 ГБ в RAID1 дадут 960 ГБ доступного пространства. Если оставить 20% свободными, для данных останется 768 ГБ. Это почти двукратный запас к расчётным 400 ГБ.
Слово NVMe в коммерческом предложении ничего не говорит о задержках под смешанной нагрузкой. Для сравнения накопителей смотри результаты Storage Performance Council: SPC публикует проверяемые тесты с описанием конфигурации, не привязанные к одной платформе. Сравнивай близкие по классу и профилю нагрузки системы — результат массива из десятков накопителей не описывает пару дисков в магазине.
Центральный сервер считают по пику всей сети
В расчётной сети 20 магазинов по четыре кассы — всего 80 рабочих мест. Центральный контур принимает обмен, хранит сводную базу и обслуживает служебные системы.
Допустим, на сервере работают восемь виртуальных машин по 4 vCPU. Получаем 32 виртуальных процессора. При переподписке 2:1 им нужны 16 физических ядер. Добавляем 25% запаса:
16 × 1,25 = 20 ядер
Ближайшая конфигурация с запасом под гипервизор и пики обмена — 24 физических ядра.
Память считаем по ролям: восемь виртуальных машин по 8 ГБ требуют 64 ГБ, СУБД — ещё 64 ГБ, гипервизор — 16 ГБ. Всего 144 ГБ. С запасом 25% получается 180 ГБ, поэтому ставим 192 ГБ ECC RDIMM.
Методика 1С предлагает измерить загрузку модельной системы и линейно перенести результат на целевую. Если нагрузка имеет несколько выраженных пиков, каждый считают отдельно, а оборудование выбирают по максимальному результату.
Для пилота полезно захватить обычную работу, открытие смен и обмен после восстановления канала. Это не требование методики 1С, а сценарии конкретной расчётной сети, которые стоит проверить до закупки.
Последний пик легко пропустить. Пока магазин был без связи, локальная база копила операции. Когда канал вернулся, 20 точек могут почти одновременно отправить очереди в центр. Средняя загрузка за день такого всплеска не покажет.
Спецификация под задачу
Расчёт относится к сети из 20 магазинов по четыре кассы, локальной базе до 200 ГБ на точку и восьми служебным виртуальным машинам в центре.
В каждый магазин
- один процессор на 8 физических ядер с упором на частоту одного ядра;
- 64 ГБ ECC RDIMM с расширением минимум до 128 ГБ;
- 2 × 960 ГБ NVMe в RAID1;
- аппаратный или программный RAID с контролем состояния массива;
- 2 × 1 Гбит/с;
- два блока питания;
- корпус минимум с двумя свободными дисковыми отсеками;
- удалённое управление питанием и просмотр аппаратных событий.
Такой узел рассчитан на четыре кассы, локальную базу, обмен и мониторинг. Пара NVMe сохраняет работу при отказе одного накопителя, а свободные отсеки позволяют после замеров вынести журналы или резервные копии на отдельный массив.
Цена автономности — 20 дополнительных машин, которые придётся обновлять, наблюдать и ремонтировать. Если отказаться от локального узла, магазин останется зависимым от канала: повреждённый кабель сможет остановить продажи при исправном центральном сервере.
В центральный контур
- 24 физических ядра;
- 192 ГБ ECC RDIMM с возможностью расширения;
- отдельный RAID1 под гипервизор;
- RAID10 под базы и очередь обмена;
- не менее двух сетевых портов по 10 Гбит/с;
- два блока питания;
- дисковые отсеки и слоты памяти с запасом под удвоение объёма данных.
Число дисков для RAID10 нужно определить после пилотного замера задержек и объёма записи: опубликованные данные не содержат показателей IOPS для этой сети. Минимум — четыре накопителя, но это геометрия RAID10, а не подтверждение достаточной производительности. Перед заказом сравни конкретные массивы по тестам с опубликованной методикой.
Если сеть вырастет до 40 магазинов при прежнем профиле, расчётные 20 ядер превратятся в 40:
32 × 2 × 1,25 ÷ 2 = 40
Тогда понадобится двухпроцессорная платформа либо разделение СУБД, обмена и служебных машин между узлами.
Если центральная площадка не должна останавливаться при отказе сервера, одной машины недостаточно. Потребуется второй узел. Защита от потери всей площадки добавит второй ЦОД. Кейс EFSOL показывает работу двух площадок в сети из более чем 20 магазинов, но не заменяет расчёт твоей нагрузки.
Перед заказом проверь сервер, операционную систему, контроллеры, накопители и сетевые адаптеры по матрице производителя. Например, HPE публикует интерактивные матрицы поддержки и сертификации. Именно матрица, а не совпадение разъёмов, показывает, поддерживает ли HPE выбранный комплект.
Перед закупкой раздели требования письменно: магазин торгует без связи с офисом; центральный контур переживает отказ одного сервера; сеть продолжает работу после потери основной площадки. Для каждого требования проведи отдельное испытание. Тогда поставщик не сможет подменить автономность касс вторым ЦОД или выдать RAID1 за защиту всей площадки.
