Неправильно выбранная СХД приводит к тем же последствиям, что и недостаточное электропитание — остановке сервисов.
Но если отказ питания виден сразу, проблемы хранения проявляются постепенно: сначала — задержки запросов к БД, потом — тайм-ауты приложений, затем — недоступность сервиса. Разбираемся, как выбрать систему хранения до того, как она станет узким местом инфраструктуры.
Главная ошибка при выборе СХД
Типичный сценарий: «Нам предлагают два варианта — модель А или модель B, что посоветуете?» Проблема: сравнение начинается с железа, а не с задач.
Правильная последовательность: Бизнес-требования ↓ Анализ нагрузки ↓ Технические требования ↓ Выбор архитектуры ↓ Сравнение вендоров
Первый вопрос — не «какую СХД купить», а «зачем она нужна».
Типы данных и требования к хранению
Характер данных определяет архитектуру хранения.
| Тип данных | Особенность | Требование к СХД |
|---|---|---|
| БД (OLTP) | случайный доступ | высокие IOPS, низкая latency |
| Медиа, архивы | последовательный доступ | высокий throughput |
| Виртуализация | смешанная нагрузка | баланс IOPS и throughput |
| VDI | высокая утренняя нагрузка | пиковые IOPS |
Сжимаемость данных влияет на эффективность:
- Текстовые БД, логи — до 10:1
- Офисные документы — 3:1 – 5:1
- Медиафайлы, зашифрованные данные — практически не сжимаются
Метрики производительности
Три ключевых параметра определяют производительность СХД.
| Метрика | Что измеряет | Критично для |
|---|---|---|
| IOPS | операций в секунду | БД, виртуализация |
| Latency | задержка ответа | OLTP, высоконагруженные системы |
| Throughput | пропускная способность (МБ/с) | медиа, резервное копирование |
Пример:
- OLTP-БД: 50 000 IOPS, latency < 1 мс
- Файловый сервер: 500 МБ/с throughput, latency не критична
Важно: измерять нагрузку нужно месяц, а не день. Пики могут быть в 5-10 раз выше средних значений.
Требования к доступности
| Доступность | Простой в год | Применение |
|---|---|---|
| 99% (2 девятки) | 95 часов | некритичные системы |
| 99.9% (3 девятки) | 9.5 часа | стандартные бизнес-приложения |
| 99.99% (4 девятки) | 53 минуты | критичные БД, ERP |
| 99.999% (5 девяток) | 5 минут | финансовые системы |
RPO / RTO — показатели на каждый инцидент
RPO (Recovery Point Objective) — допустимая потеря данных:
- Резервное копирование раз в сутки → RPO = 24 часа
- Снапшоты каждый час → RPO = 1 час
- Синхронная репликация → RPO ≈ 0
RTO (Recovery Time Objective) — время восстановления сервиса:
- Восстановление из backup → RTO = несколько часов
- Переключение на реплику → RTO = минуты
- Метрокластер → RTO < 1 минута
Ключевые технологии СХД
Снапшоты
Моментальный снимок состояния данных без физического копирования.
Применение:
- Быстрое восстановление при ошибках
- Создание сред VDI
- Низкие RPO (снапшоты каждые 15-30 минут)
Важно: снапшоты не заменяют резервное копирование.
Дедупликация
Устранение дублирующихся блоков данных.
Эффективность зависит от типа данных:
- VDI — до 20:1
- Резервные копии — 10:1 – 15:1
- Активные БД — 2:1 – 3:1
Компрессия
Сжатие данных на лету.
Влияние на производительность:
- Inline (в момент записи) — дополнительная latency
- Post-process (отложенное) — без влияния на запись
Репликация
- Синхронная — данные записываются одновременно на обе СХД (применение: метрокластер <100 км, RPO ≈ 0, высокие требования к каналу связи)
- Асинхронная — периодическая передача изменений (применение: DR-площадка, RPO = интервал репликации, меньшие требования к каналу)
Thin Provisioning
Выделение дискового пространства по требованию.
Пример: Создан том 10 ТБ → физически выделено 2 ТБ → по мере заполнения выделяется больше. Риск: переподписка (oversubscription) может привести к исчерпанию места.
Метрокластер — географически распределённая отказоустойчивость
Два ЦОД на расстоянии <100 км работают как единая система.
ЦОД 1 ЦОД 2
[Серверы] ─┐ ┌─ [Серверы]
│ │
[СХД] ←───→ [СХД] (синхронная репликация)
│ │
[Единый датастор]
Преимущества:
- Автоматическое переключение при отказе площадки
- RTO < 1 минута
- RPO ≈ 0
- Без остановки виртуальных машин
Ограничение: latency между площадками <5 мс.
Расчёт производительности СХД
Для корректного сайзинга нужны данные за месяц:
- Средняя нагрузка (IOPS, throughput)
- Пиковая нагрузка
- Нагрузка резервного копирования
- Размер рабочего набора данных
Инструменты сбора метрик:
- Встроенные средства СХД
- Системы мониторинга хостов
- Специализированные утилиты
Типичные просчёты:
- Смотрят текущую нагрузку, а не пиковую
- Не учитывают резервное копирование
- Игнорируют рост данных на 2-3 года
Правильный подход: пиковая нагрузка + 30% запас + прогноз роста.
All-Flash vs гибридные СХД
| Параметр | All-Flash | Гибридные (HDD + SSD) |
|---|---|---|
| Производительность | Высокие IOPS | Средние IOPS |
| Задержки | Низкая latency | Средняя latency |
| Экономика | Высокая стоимость $/ТБ | Низкая стоимость $/ТБ |
| Применение | БД, виртуализация | Архивы, файловые сервисы |
Тренд: стоимость SSD снижается, граница между All-Flash и гибридными стирается. Для OLTP-БД и виртуализации All-Flash — стандарт.
Сетевая инфраструктура для СХД
| Протокол | Скорость | Применение | Особенность |
|---|---|---|---|
| FC | 16-32 Гбит/с | SAN | выделенная сеть |
| iSCSI | 10-100 Гбит/с | SAN | поверх Ethernet |
| NFS/SMB | 10-100 Гбит/с | NAS | файловый доступ |
| NVMe-oF | 25-100 Гбит/с | SAN | минимальная latency |
Главная ошибка: использование общей сети для iSCSI. Результат: конфликт трафика, задержки БД.
Правило: для блочного доступа — выделенная сеть.
Вендор vs интегратор vs SDS
| Модель | Преимущество | Недостаток |
|---|---|---|
| Вендорская СХД | готовое решение | привязка к производителю |
| SDS | гибкость железа | сложность внедрения |
| Самосбор | низкая стоимость | отсутствие поддержки |
Для критичных систем — вендорская СХД с поддержкой. Для некритичных нагрузок — SDS или самосбор.
Выбор системы хранения — инженерная задача, начинающаяся с анализа бизнес-требований.
Последовательность:
- Определить RPO/RTO
- Измерить текущую нагрузку (месяц)
- Рассчитать требуемые IOPS и throughput
- Выбрать архитектуру (All-Flash, гибридная, SDS)
- Сравнить вендоров по техническим требованиям
Главное: не железо выбирает задачи, а задачи определяют железо.
Частые вопросы
Как измерить текущую нагрузку на хранилище?
Собирать метрики минимум месяц через встроенные средства СХД, системы мониторинга хостов или специализированные утилиты. Важны пиковые значения, а не средние.
В чём разница между RPO и RTO?
RPO — допустимая потеря данных при аварии (часы). RTO — время восстановления сервиса после аварии (минуты/часы). RPO определяет частоту резервного копирования, RTO — архитектуру отказоустойчивости.
All-Flash или гибридная СХД?
Для БД и виртуализации — All-Flash (критична latency). Для архивов и файловых сервисов — гибридная (критична стоимость $/ТБ). Граница стирается с удешевлением SSD.