Традиционная СХД перестаёт масштабироваться в тот момент, когда нужно больше, чем может одна система. Раньше решение выглядело так: купить более мощную СХД → заплатить в 2-3 раза больше. Сегодня другой путь: распределить данные по узлам → горизонтальное масштабирование.
Распределённые системы хранения (SDS) меняют подход к построению инфраструктуры хранения.
Что такое распределённое хранилище
SDS — программный слой, объединяющий диски нескольких серверов в единый пул хранения. Ключевое отличие от традиционной СХД:
- Данные распределены по узлам кластера
- Отказоустойчивость на программном уровне
- Масштабирование добавлением серверов
Архитектура распределённого хранилища
[Узел 1: CPU + RAM + Диски] ┐
[Узел 2: CPU + RAM + Диски] ├─ ПО SDS → Единый пул
[Узел 3: CPU + RAM + Диски] ┘ ↓
Распределение данных + Репликация/Erasure Coding
Функции управления реализует ПО, а не контроллеры СХД.
Технологии обеспечения отказоустойчивости
Репликация
Каждый блок данных копируется на несколько узлов. Пример (3 реплики): Запись данных → Узел 1 (оригинал) + Узел 2 (копия) + Узел 3 (копия).
- Преимущество: быстрое восстановление при отказе узла
- Недостаток: 3× избыточность (для хранения 100 ТБ нужно 300 ТБ)
Erasure Coding
Данные разбиваются на блоки с добавлением кодов коррекции. Схема 4+2: 4 блока данных + 2 блока контроля чётности → выдерживает отказ любых 2 узлов → избыточность 1.5× (для 100 ТБ нужно 150 ТБ).
Сравнение методов защиты
| Метод | Избыточность | Скорость записи | Скорость восстановления |
|---|---|---|---|
| Репликация (3×) | 3× | высокая | быстрое |
| Erasure Coding 4+2 | 1.5× | средняя | медленное |
| Erasure Coding 8+3 | 1.375× | низкая | очень медленное |
Выбор зависит от приоритета: производительность или экономия места.
Масштабирование распределённых систем
- Вертикальное — увеличение ресурсов узла (больше дисков, RAM). Ограничение: предел возможностей одного сервера.
- Горизонтальное — добавление узлов в кластер. Преимущество: практически неограниченное масштабирование.
Процесс горизонтального масштабирования
Исходный кластер (3 узла, 30 ТБ) ↓ Добавление узла (→ 4 узла) ↓ Ребалансировка данных ↓ Новая ёмкость (40 ТБ)
Данные автоматически перераспределяются по новой топологии.
Архитектуры распределённого хранения
Гиперконвергентная (HCI)
Вычисления и хранение на одних серверах.
- Применение: Виртуализация, VDI, филиалы
- Ограничение: масштабирование CPU и хранения совместно
Конвергентная
Отдельные узлы для вычислений и хранения, но в едином кластере. Применение: раздельное масштабирование вычислений и хранения, более гибкая архитектура.
Дезагрегированная
Хранилище полностью независимо от вычислений. Применение: объектное хранилище, медиаархивы, резервное копирование.
Требования к сетевой инфраструктуре
SDS критически зависит от сети — она становится шиной данных.
| Тип нагрузки | Скорость сети | Latency |
|---|---|---|
| Файловые сервисы | 10 GbE | <5 мс |
| Виртуализация | 25 GbE | <1 мс |
| БД (OLTP) | 25-100 GbE | <0.5 мс |
Важно: использовать выделенную сеть хранения. Совмещение с основной сетью приводит к конфликту трафика, деградации производительности БД и джиттеру latency.
Популярные платформы SDS
| Платформа | Тип доступа | Особенность |
|---|---|---|
| Ceph | блочный, файловый, объектный | универсальное решение |
| GlusterFS | файловый | распределённая ФС |
| VMware vSAN | блочный | интеграция с vSphere |
| Microsoft S2D | блочный | интеграция с Windows Server |
Российские решения часто используют Ceph или собственные разработки.
Когда SDS оправдан
- Горизонтальное масштабирование (>100 ТБ)
- Гиперконвергентная инфраструктура
- Поэтапное наращивание без больших CAPEX
- Использование стандартных серверов
- Требования импортозамещения
Когда SDS не подходит
- Критична минимальная latency (<0.3 мс)
- Небольшой масштаб (<20 ТБ)
- Отсутствует быстрая сетевая инфраструктура
- Нет экспертизы для настройки и поддержки
Для критичных OLTP-БД с жёсткими требованиями к latency традиционная All-Flash СХД может быть лучше.
Главная ошибка внедрения SDS
Типичный сценарий: «Поставим SDS, сэкономим на железе». Реальность:
- Сложность настройки
- Требования к сети
- Необходимость экспертизы
- Дополнительные лицензии
Правильный подход: SDS внедряется не для экономии, а для гибкости и масштабирования. Экономия возникает на масштабе (>50 ТБ), не на старте.
Метрики производительности SDS
| Метрика | Зависит от |
|---|---|
| IOPS | количество узлов, тип дисков, сеть |
| Latency | сеть, алгоритм отказоустойчивости |
| Throughput | пропускная способность сети |
Erasure Coding даёт больше latency, чем репликация (нужно собрать блоки).
Отказоустойчивость и восстановление
Сценарий отказа узла
Узел вышел из строя ↓ Система детектирует отказ ↓ Данные читаются с реплик ↓ Запускается ребалансировка ↓ Данные распределяются по оставшимся узлам
Время восстановления зависит от объёма данных на узле, пропускной способности сети и количества оставшихся узлов. Типично: 500 ГБ восстанавливается за 1-2 часа в сети 10 GbE.
Распределённые системы хранения меняют подход к построению инфраструктуры. Ключевые принципы:
- Горизонтальное масштабирование вместо вертикального
- Отказоустойчивость на уровне ПО
- Критическая зависимость от сети
- Гибкость выбора оборудования
SDS оправдан для масштабируемых инфраструктур, гиперконвергенции и поэтапного роста. Традиционная СХД остаётся выбором для критичных БД с минимальной latency, небольших инсталляций и когда важна простота эксплуатации.
Частые вопросы
В чём главное отличие SDS от традиционной СХД?
SDS — это ПО, распределяющее данные по дискам стандартных серверов. Традиционная СХД — специализированное железо с контроллерами. SDS масштабируется горизонтально (добавлением узлов), СХД — вертикально (более мощное железо).
Репликация или Erasure Coding?
Репликация быстрее, но избыточность 3×. Erasure Coding экономит место (1.5×), но медленнее и даёт большую latency. Для БД — репликация, для архивов — Erasure Coding.
Какая сеть нужна для SDS?
Минимум 10 GbE для файловых сервисов, 25 GbE для виртуализации. Критично: выделенная сеть хранения, latency <1 мс. Совмещение с основной сетью приводит к деградации производительности.