Высокопроизводительная SQL-платформа и надёжное SAN-хранение для федеральной сети ритейла

Проблема

В ритейле «узкие места» чаще всего проявляются не в средних сутках, а в пиках: распродажи, сезонные обновления ассортимента, массовые переоценки, закрытие дня/недели/месяца, рост онлайн-заказов и нагрузки на лояльность. У заказчика критичные процессы опирались на Microsoft SQL (операционные базы, аналитические витрины, интеграции), и со временем стали заметны типовые симптомы зрелой инфраструктуры:

• скачки задержек на дисковой подсистеме → рост времени отклика SQL, блокировки, «провалы» в пиковые часы;

• сжатое ночное окно для обслуживания (индексы, ETL, выгрузки, сверки) → операции не укладывались до открытия магазинов;

• долгие бэкапы/восстановления и риски по RTO/RPO из-за ограничений хранения;

• сложность прогнозируемого роста: увеличение объёма данных и параллельных транзакций требовало масштабирования, но без «пересборки» всей платформы.

Задача

Построить обновлённое «ядро» под SQL-нагрузки и корпоративные сервисы хранения, которое:

• дает стабильную производительность на случайных I/O (SQL data/log/tempdb) и не «проседает» на пиках;
  

• позволяет разнести нагрузки (базы данных продуктивной среды / журналы / бэкапы / сервисные тома) и управлять приоритетами;
  

• обеспечивает отказоустойчивость на уровне контроллеров, каналов и путей доступа (multipath, резервирование);
  

• ускоряет операции обслуживания и резервного копирования;
  

• масштабируется без смены архитектуры — добавлением ёмкости/полок и расширением пулов.

Решение

1) Вычислительная платформа под SQL: Dell PowerEdge R860

В качестве базы для «тяжёлых» SQL-нагрузок выбран Dell PowerEdge R860 — плотный 2U сервер на  с 4-мя процессорами, ориентированный на бизнес-критичные приложения и базы данных. Это позволило перейти от «упора в CPU/RAM» к предсказуемому запасу по вычислениям и памяти для параллельных запросов, кэша и обслуживания.

Что это дало по практике эксплуатации:

• запас по вычислениям под рост числа транзакций и отчётных запросов;

• возможность аккуратно выделить ресурсы под разные SQL-инстансы/задачи (боевые базы, витрины, техпроцессы);

• единая точка управления и стандартные процедуры обслуживания (iDRAC/OpenManage).

2) Три СХД Dell PowerVault ME5024 — «правильное» хранение для SQL и сервисных данных

Для устранения ограничений пропускной способности дисковой подсистемы  и разделения контуров хранения развернули подсистему на базе трёх Dell PowerVault ME5024.

Почему именно ME5024 (как класс решения):

• dual-active архитектура контроллеров и отказоустойчивость на уровне массива;
  

• 2U шасси на 24 диска 2.5", удобное для гибридных конфигураций (SSD под горячие данные + SAS/NL-SAS под ёмкость);
  

• поддержка SAN-подключений (FC/iSCSI/SAS) и расширения через 12Gb SAS-полки;
  

• механики, полезные в реальной жизни: thin provisioning, снимки, авто-tiering (до 3 уровней), RAID-варианты, в т.ч. ADAPT RAID для ускорения ребилдов.
  

Как применили 3 массива в архитектуре (логика проекта):

• ME5024 №1 — “SQL DATA”: высокоприоритетные тома под data-файлы боевых БД (минимизация latency, стабильные IOPS).
  

• ME5024 №2 — “SQL LOG / TEMP / SERVICE”: тома под журналы транзакций, tempdb и сервисные нагрузки, чтобы «шум» от обслуживания и пиков не влиял на данные.
  

• ME5024 №3 — “BACKUP / REPO / STAGE”: контур для быстрых бэкапов, staging и технологических копий (ускорение RTO и снижение влияния бэкапов на прод).

Такой подход даёт не просто «много дисков», а управляемую предсказуемость: разные профили I/O не мешают друг другу, а критичные базы получают стабильный приоритет.

3) Резервирование путей доступа и эксплуатационная надёжность

На уровне подключения реализовали отказоустойчивую схему доступа к томам: два независимых пути от сервера к контроллерам СХД (multipath), разнесение сетевых/host-каналов по разным портам и доменам, отдельные VLAN/сети хранения (в зависимости от выбранного протокола на площадке заказчика).
Это исключает «единую точку отказа» в связности и снижает риск деградации при отказе порта/линка/адаптера.

4) Миграция без остановки бизнеса<

Проект выполнили поэтапно:

• предпроектное обследование SQL-нагрузок (I/O профиль, “горячие” базы, окна обслуживания);

• развёртывание новой платформы и тесты производительности;

• перенос по группам: сначала сервисные и технологические БД, затем боевые базы с контрольными окнами;

• финальная стабилизация: настройка бэкапов, регламентов обслуживания, мониторинга latency/IOPS и ёмкости.

Результат

• Стабилизация производительности SQL в пиковые периоды: предсказуемые задержки хранения и меньше «шипов» по latency за счёт разнесения data/log/temp/backup по разным контурам.

• Сокращение ночных окон обслуживания: операции индексации/ETL и пакетные задания стали укладываться в регламент до начала рабочего дня.

• Быстрее бэкапы и восстановление: отдельный контур под backup/stage уменьшил влияние резервного копирования на прод и улучшил достижимость RTO.

• Упрощение масштабирования: рост объёмов и нагрузки покрывается расширением пулов и добавлением ёмкости без смены архитектуры.

• Надежность эксплуатации: отказоустойчивость на уровне контроллеров и путей доступа снижает риск простоя критичных контуров.