СХД для высоконагруженных баз данных: требования к IOPS и задержкам
Для OLTP-баз данных (Oracle, PostgreSQL, MS SQL) требуется СХД с поддержкой NVMe, задержкой менее 1 мс и IOPS от 50 000 до 500 000+. Ключевые параметры выбора: архитектура Active/Active, RAID TP, протокол Fibre Channel или NVMe-oF, кэш на контроллер от 256 ГБ. СХД NIMBUS «Молния» и «Гром» закрывают весь спектр нагрузок СУБД.
Когда база данных начинает «тормозить», первый подозреваемый — сервер. Но в 80% случаев узкое место находится именно в хранилище: недостаточно IOPS, слишком высокая latency, или контроллер СХД не справляется с пиковой нагрузкой. Для PostgreSQL, Oracle Database, MS SQL Server и 1С:Предприятие хранилище — это не просто место на диске. Это фундамент, от которого зависит время отклика каждой транзакции, каждого JOIN-запроса, каждого checkpoint-а.
На практике инженеры ЦОД выделяют три сценария «провала» СХД под СУБД: неверно выбранный тип дисков (HDD вместо NVMe), отсутствие достаточного кэша на запись и единственный контроллер без Active/Active. Разберём, как не попасть в каждый из этих сценариев — и какие конкретные параметры должна закрывать СХД для высоконагруженных баз данных.
Профили нагрузки СУБД: OLTP против OLAP
Прежде чем говорить о цифрах IOPS — нужно понять профиль нагрузки. OLTP (онлайн-транзакции: банковские системы, ERP, биллинг, 1С) работает с мелким блоком — 4–16 КБ — и генерирует сотни тысяч случайных операций чтения/записи. Здесь главное — задержка. OLAP (аналитика, DWH, BI) работает с крупным блоком — 64–512 КБ — и требует высокой пропускной способности: от 10 до 40 Гбайт/с. Здесь главное — throughput.
Смешанная нагрузка (СУБД + виртуализация + резервное копирование) — самый распространённый сценарий в корпоративных ЦОД. Именно для него создана гибридная архитектура «Гром»: горячие данные обслуживаются NVMe-кэшем, холодный tier уходит на SAS4, а «Юпитер» управляет tiering-ом автоматически без участия администратора.
Конкретные требования к IOPS для разных СУБД
Цифры без контекста — бесполезны. Ниже — реалистичные ориентиры для производственных инсталляций, которые мы используем при проектировании хранилищ.
| СУБД / Сценарий | Профиль I/O | Мин. IOPS (4–16 КБ) | Целевая latency | Рекомендуемая СХД NIMBUS |
|---|---|---|---|---|
| Oracle OLTP (100–300 сессий) | 70% чтение / 30% запись, случайный | 100 000 – 300 000 | < 500 мкс | «Молния» |
| PostgreSQL / MS SQL (средний бизнес) | 60% чтение / 40% запись, случайный | 50 000 – 150 000 | < 1 мс | «Молния» / «Гром» 230 |
| 1С:Предприятие (ERP, 500+ пользователей) | 80% чтение, мелкий блок | 30 000 – 80 000 | < 2 мс | «Гром» 220 / 230 |
| DWH / OLAP (аналитика, BI) | Последовательный, блок 64–512 КБ | 5 000 – 20 000 | < 10 мс | «Гром» 210 / 220 |
| ML / Big Data (обучение моделей) | Последовательное чтение, блок 256 КБ+ | 10 000 – 30 000 (пропускная способность приоритет) |
< 5 мс | «Молния» |
| SAP HANA (in-memory СУБД) | Случайный + последовательный | 200 000 – 500 000+ | < 200 мкс | «Молния» |
Почему latency важнее, чем просто IOPS
IOPS — это количество операций в секунду. Latency — время ответа на одну операцию. Для транзакционных СУБД именно latency определяет UX конечного пользователя: если база отвечает 5 мс вместо 0,5 мс, приложение работает в 10 раз медленнее субъективно, даже если IOPS-показатель достаточен. Почему? Транзакция не параллельна — она последовательна: запрос, подтверждение записи в WAL, commit. Каждый шаг ждёт ответа хранилища.
Именно поэтому для Oracle, PostgreSQL в режиме синхронной репликации или любой СУБД с fsync=on критичен показатель write latency. «Молния» от NIMBUS обеспечивает менее 200 мкс на запись за счёт NVMe-флеша, DRAM-кэша на контроллер до 1 ТБ и прямого пути данных без промежуточных прослоек. Это не маркетинговая цифра — это физика NVMe-устройств без интерфейсного overhead SAS/SATA.
Архитектура контроллера: почему Active/Active обязателен для СУБД
Представьте: ночной checkpoint Oracle занял весь I/O-канал одного контроллера Active/Passive СХД. Второй контроллер стоит в режиме ожидания. Всё приложение ждёт. В архитектуре Active/Active оба контроллера обслуживают LUN одновременно — нагрузка делится, очередь не растёт. При выходе одного узла из строя второй продолжает работу без переключения с простоем.
Обе платформы NIMBUS — «Гром» и «Молния» — построены на архитектуре Active/Active с двойными контроллерами. Дополнительно «Юпитер» поддерживает Metrocluster: синхронную репликацию между двумя СХД на разных площадках с RPO=0. Для банков и телеком-операторов это означает нулевую потерю транзакций при катастрофе на одной из площадок.
Протоколы подключения: FC против NVMe-oF против iSCSI
Выбор протокола напрямую влияет на latency и IOPS. Ниже — сравнение для серверов баз данных.
| Протокол | Типичная latency | Пропускная способность | Сценарий применения |
|---|---|---|---|
| NVMe-oF (RDMA/RoCE) | 50–150 мкс | До 100 Гбайт/с | Oracle RAC, SAP HANA, высоконагруженный ML |
| Fibre Channel 32G | 100–300 мкс | До 32 Гбайт/с на порт | Критические OLTP-СУБД, банки, телеком |
| iSCSI 25/100 GbE | 200–800 мкс | До 25 Гбайт/с | ERP, 1С, средний бизнес, разработка |
| NFS v4.1 / pNFS | 0,5–5 мс | До 20 Гбайт/с | OLAP, архивы, файловые СУБД |
«Молния» поддерживает NVMe-oF и Fibre Channel 32G одновременно — это даёт возможность строить гетерогенную инфраструктуру, где критические СУБД работают по NVMe-oF, а унаследованные приложения — по FC без смены коммутаторной инфраструктуры.
Защита данных и RAID для СУБД: почему RAID TP превосходит RAID 6
RAID 6 защищает от выхода из строя двух дисков — это стандарт 2010-х. В массивах с NVMe-дисками объёмом 30+ ТБ время восстановления после сбоя (rebuild) при RAID 6 занимает 24–72 часа — и в этот период массив уязвим. RAID TP (тройная чётность) защищает от одновременного выхода трёх дисков и радикально снижает риск второй потери данных во время rebuild.
ПО «Юпитер» реализует RAID TP нативно — без сторонних лицензий. Дополнительно доступны мгновенные снепшоты (до 1024 на том) для откатов после ошибок приложений, а не только для резервного копирования. Это важно для DBA: снепшот перед крупной миграцией данных или применением патча позволяет откатиться за секунды, не используя бэкап.
Практический сценарий: консолидация СУБД на платформе NIMBUS
Типичная задача: финтех-компания эксплуатирует 4 физических сервера с локальными SSD — Oracle Production, Oracle Dev/Test, PostgreSQL-кластер микросервисов и MS SQL для BI. Суммарно — 80 ТБ данных, пиковая нагрузка 200 000 IOPS, требование latency < 500 мкс для Oracle. Консолидация на одну «Молнию» с кэшем 1 ТБ и NVMe-oF-подключением по 100 GbE решает задачу целиком: каждая СУБД получает выделенный LUN с QoS-политиками «Юпитера», ресурсы не «съедают» друг друга, а Metrocluster на резервной площадке обеспечивает RPO=0 вместо ежечасных бэкапов.
FAQ
Сколько IOPS нужно для высоконагруженной СУБД Oracle или PostgreSQL?
Для OLTP с 100–300 активными сессиями — от 50 000 до 300 000 IOPS случайного доступа (блок 4–16 КБ). В пиках нагрузка может быть в 2–3 раза выше. СХД «Молния» от NIMBUS обеспечивает свыше 500 000 IOPS на массив — с запасом под любой пик.
Какая задержка допустима для транзакционных баз данных?
Профессиональный стандарт для OLTP — latency менее 1 мс при смешанной нагрузке. Для критических СУБД с синхронной репликацией (Oracle Data Guard, Patroni) цель — ниже 500 мкс. NVMe-массив «Молния» обеспечивает write latency менее 200 мкс благодаря прямому пути NVMe-oF и DRAM-кэшу до 1 ТБ на контроллер.
NVMe или SAS4 — что выбрать под корпоративную СУБД?
NVMe (СХД «Молния») — для критических OLTP с требованием latency < 500 мкс и IOPS > 200 000. SAS4 с NVMe-кэшем (СХД «Гром» 220/230) — оптимальный выбор для ERP, 1С:Предприятие и DWH, где важен баланс ёмкости и производительности при умеренном бюджете.
Как рассчитать кэш контроллера для СУБД?
Правило инженеров: кэш на контроллер должен покрывать «рабочий набор» (working set) горячих данных — обычно 5–15% от объёма активной БД. Для базы в 10 ТБ с рабочим набором 1–1,5 ТБ достаточен кэш 1 ТБ на контроллер — именно такой доступен на «Молнии». «Юпитер» управляет кэшем автоматически: холодные данные вытесняются на флеш-tier, горячие остаются в DRAM.
Нужен ли Fibre Channel, или iSCSI достаточно для СУБД?
Для OLTP-нагрузок свыше 100 000 IOPS и требованием latency < 500 мкс — Fibre Channel 32G или NVMe-oF обязательны. iSCSI на 25 GbE даёт latency 200–800 мкс и подходит для 1С, ERP и тестовых сред. «Молния» поддерживает оба типа подключения одновременно, что упрощает поэтапную миграцию без замены SAN-инфраструктуры.
Гром
система хранения данных
В реестре
Оптимально подходит для организаций среднего и крупного бизнеса, которым требуется надежное, масштабируемое и эффективное решение для хранения данных с возможностью адаптации к различным типам нагрузок
Молния
система хранения данных
В реестре
Решение премиум-класса для организаций, чей бизнес зависит от скорости обработки данных и требует инфраструктуры хранения с высокой пропускной способностью. Подходит для отраслей: телекоммуникации, финансы, госучреждения и производство