Кейс EFSOL: как обеспечить рознице 24/7 работу без простоев с помощью отказоустойчивой инфраструктуры в двух ЦОД для касс, 1С, склада и онлайн-канала
Задача и причина
Задача
Перед командой стояла задача обеспечить непрерывность критичных для бизнеса процессов и убрать любые сценарии, при которых клиент может остаться без обслуживания на кассе или потерять заказ в онлайне:
- исключить простой магазинов и формирование очередей за счет постоянной доступности касс и учетной системы;
- сохранить удовлетворенность покупателей — никакого «торможения» УС, корректная работа системы лояльности;
- поддерживать актуальные остатки товаров в режиме online — единая картина по всей сети и складу;
- обеспечить целостность ночных обменов между служебными сервисами без влияния на дневной контур.
Причина
Триггером проекта стали ограничения действующей архитектуры учетной системы и риски, которые они несли для бизнеса:
- учетная система располагалась на локальном сервере в одной физической локации — отказ оборудования или инцидент на площадке (электропитание, охлаждение, человеческий фактор) означал полную остановку контура;
- резервное копирование было настроено, однако восстановление учетной системы из бэкапа занимает время — до нескольких часов;
- этот простой напрямую конвертировался в недоступность 1С и касс, остановку обслуживания покупателей в магазинах и срыв обработки заказов в онлайн‑канале — то есть в прямую потерю выручки и лояльности клиентов.
Этапы внедрения
В рамках обследования выявлены критические точки и предложено комплексное решение — геораспределенный отказоустойчивый кластер с парой узлов в каждом из двух независимых ЦОД EFSOL (ЦОД‑1 и ЦОД‑2). На уровне инфраструктуры использован стандартный стек Microsoft — Windows Server Failover Cluster, AD, IIS, TS Broker. На стороне магазинов добавлен резервный канал связи на базе LTE.
Проект реализован поэтапно по модели, типовой для миграций критичных систем розницы. Каждый шаг закрывал свой класс рисков и завершался формальным критерием готовности: это позволило переходить на новый контур без «больших переключений», на которых обычно и случаются сбои.
Этап 1. Обследование действующей инфраструктуры
На входе мы инвентаризируем серверы, базы, обмены, каналы связи и оборудование в торговых точках, а также собираем статистику инцидентов и окон недоступности за последние 6–12 месяцев. Параллельно проводим интервью с владельцами бизнес‑процессов: какие операции «должны жить всегда», какое окно простоя еще допустимо, какие потери дает минута недоступности кассы. Результат этапа — карта зависимостей сервисов, перечень единичных точек отказа и зафиксированные с бизнесом целевые показатели RTO и RPO.
Этап 2. Проектирование целевой архитектуры
На основе данных обследования формируется техническое решение: распределение ролей между двумя ЦОД, схема SQL‑кластера и кластера 1С, балансировка IIS, выбор механизмов синхронизации данных, план IP‑адресации и DNS, регламент резервных каналов связи на торговых точках. Документ согласуется с клиентом — фиксируем не только архитектуру, но и сценарии отказов: что и в какой последовательности должно произойти при потере одного из ЦОД, как переключаются пользователи, как ведут себя обмены и кассы.
Этап 3. Прототип в тестовом контуре
До любых действий в продуктиве собираем уменьшенную копию целевой схемы в изолированном тестовом окружении. На прототипе проверяем ключевые сценарии: автоматический failover SQL, поведение кластера 1С при потере узла, переключение пользовательских сессий через TS Broker, корректность работы IIS‑фермы и AD при отключении одного из ЦОД. Здесь же отрабатываются регламенты администраторов и шаблоны мониторинга — то, чем команда будет пользоваться каждый день после внедрения.
Этап 4. Пилот на ограниченном периметре
На пилот выводится часть бизнес‑контура — несколько торговых точек и тестовая база 1С — параллельно с действующей системой. В этом режиме мы получаем реальный профиль нагрузки, отлавливаем расхождения с тестом, проверяем работу резервных LTE‑каналов в магазинах и проводим первые «учения»: контролируемое отключение узла, измерение фактического времени переключения, оценка влияния на кассовые операции. Пилот закрывается отчетом, в котором сравниваются плановые и фактические RTO/RPO, и согласованным планом миграции остальной сети.
Этап 5. Миграция в продакшен
Перевод всей сети на новый контур выполняется волнами и в технологических окнах с минимальной активностью — как правило, в ночное время и в выходные. На каждом окне мигрируется фиксированный пул сервисов: переносятся базы 1С на кластер SQL, переключаются терминалы Клеверенс, перенастраиваются обмены, обновляются маршруты и DNS‑записи, активируются резервные LTE‑каналы в торговых точках. Для каждого окна заранее определен план отката, а до открытия магазинов выполняется чек‑лист функционального тестирования: продажа на кассе, проведение возврата, печать чека, прохождение онлайн‑заказа от приема до сборки.
Этап 6. Передача в эксплуатацию и регулярные учения
После выхода в продуктив система передается в сопровождение с полным комплектом документации, схем и регламентов — что делать при выходе из строя любого узла, как проверять синхронность данных, как переводить нагрузку в одном ЦОД и возвращать ее обратно. Включается мониторинг доступности всех ролей кластера и каналов связи с алертингом по приоритетам, настраиваются ежедневные задания резервного копирования с регулярной проверкой восстановления. Минимум раз в квартал команда проводит запланированные учения по отказу: имитируется потеря одного ЦОД, замеряются фактические RTO/RPO, при необходимости обновляются регламенты.
Такая последовательность шагов — от обследования до учений — позволяет переводить розничную сеть на отказоустойчивый контур без шоковых переключений, с заранее проверенным поведением каждого компонента и понятным сценарием действий в нештатных ситуациях.
Особенности кластерной схемы
Все ключевые роли реализованы как кластер с парой узлов в разных ЦОД. Ниже — состав:
- SQL‑серверы — единое хранилище данных, синхронизированное между ЦОД‑1 и ЦОД‑2; кластер Microsoft SQL Server с единым виртуальным IP и базой данных. При сбое основного узла запросы автоматически переводятся на узел во втором ЦОД.
- Серверы 1С:Предприятия — отказоустойчивый кластер 1С:Предприятия.
- Веб‑сервер (IIS) — ферма IIS с узлами в обоих ЦОД, с балансировкой между ними.
- Терминальный сервер — терминальные серверы в обоих ЦОД. Служба распределителя терминальных сессий (TS Broker) обеспечивает переключение пользовательских сессий между узлами.
- Контроллеры домена — две виртуальные машины — по одной в каждом ЦОД — с распределенными ролями AD. Аутентификация и групповые политики продолжают работать при отказе любого узла.
- Маршрутизаторы — кластерные пары маршрутизаторов с разнесением устройств по ЦОД‑1 и ЦОД‑2 и дублирующими сетевыми соединениями между дата‑центрами.
Дополняющие элементы
- Канал на точках продаж — Основной интернет‑канал в каждой точке + резервный LTE‑канал с регламентом действий для персонала.
- Регламент обменов — Ночные обмены между служебными сервисами разнесены по окнам и приоритетам, чтобы не пересекаться с операциями онлайн‑магазина.
Мониторинг и резервное копирование — контроль доступности всех ролей кластера и каналов связи с алертами. Ежедневные задания backup с регулярной проверкой восстановления.
Результат
Проведена комплексная модернизация ИТ‑инфраструктуры. Цель «Исключить простои компании» достигнута: снижены риски потери выручки и лояльности клиентов, сокращены трудозатраты на сопровождение учетной системы и инфраструктуры за счет уменьшения количества потенциальных точек отказа.
Ключевые показатели:
- Доступность критичных сервисов — 1С, касс и системы лояльности — находилась на уровне 98–99% и сопровождалась заметными простоями. После внедрения целевая доступность выросла до 99,9%+, что означает не более примерно 8 часов недоступности в год.
- Восстановление после инцидентов занимало часы и требовало ручного разбора ситуации. После проекта время восстановления сократилось до 10 минут благодаря автоматическому переключению на резервный контур.
- Потеря данных могла достигать целого дня, поскольку восстановление зависело от последней резервной копии. После внедрения RPO сократился до минуты за счет общего кластерного хранилища и журналирования.
- Раньше магазины были связаны с центральной инфраструктурой только через один канал, и сбой связи мог остановить работу точки. После каждая точка получила основное подключение и резервный LTE-канал.
- Защита от отказа дата-центра отсутствовала, так как вся система зависела от одной площадки. После проекта был реализован геокластер между двумя ЦОД с автоматическим переключением при отказе одного из них.
- Остатки товаров обновлялись с задержкой из-за обменов. После внедрения данные по остаткам стали актуальными в real-time по всей сети и складу.
- Поддержка инфраструктуры требовала большого количества ручных операций и высоких трудозатрат. После сопровождение проекта упростилось за счет типовой архитектуры, централизованного мониторинга и снижения числа потенциальных точек отказа.
Источники изображений:
Изображение взято из личного архива ООО «ЭР Софт»
Выбор редакции
Публикации, которые получают больше внимания и попадают в Сюжеты РБК
Рекомендации партнеров: