Система хранения данных (СХД) объединяет контроллеры, дисковые полки и программный слой, который отдаёт приложениям данные по блочному, файловому или объектному протоколу. Выбор начинается с вопроса: как приложение обращается к данным и какой профиль нагрузки у задачи.
Блочный доступ через iSCSI или Fibre Channel нужен базам данных и виртуализации. Файловый через NFS или SMB подходит для общих каталогов, бэкапов и медиафайлов. Объектный через S3 API выбирают для облачных приложений, архивов и больших объёмов неструктурированных данных.
Классов СХД пять: DAS, NAS, SAN, распределённые программно-определяемые системы (SDS и HCI) и облачные сервисы. Дальше решают объём, требуемые IOPS, latency и throughput, масштабируемость, отказоустойчивость и бюджет. Статья разбирает каждый класс, архитектуру, уровни RAID, расчёт производительности и схемы резервирования.
Что такое СХД и как выбрать класс хранилища под задачу
СХД состоит из контроллеров, кэша, полок расширения, путей доступа и программного слоя, который управляет данными. Отказоустойчивость массивов задают уровни RAID: RAID 5 и RAID 6 для ёмких архивов, RAID 10 для баз данных. Одна и та же нагрузка на разных классах даст разницу в задержках в десятки раз, а в стоимости владения в разы. Класс выбирают по типу доступа и профилю нагрузки, цена за терабайт вторична.
DAS, NAS, SAN: в чём разница и когда что применять
DAS (Direct-Attached Storage) подключается к серверу напрямую по SAS, SATA или NVMe. Минимальная задержка, низкая цена, простой запуск. Общего доступа между серверами нет, а масштабирование ограничено корпусом и контроллером. Типовые сценарии: отдельный сервер под файлы, локальный кэш, тестовый стенд.
NAS (Network-Attached Storage) отдаёт файлы по NFS или SMB. TrueNAS, OpenMediaVault и Synology закрывают общие каталоги, домашние директории, бэкапы и медиатеку. Настройка простая, snapshots и права доступа есть из коробки. Для транзакционных баз данных NAS подходит плохо: сетевой стек и файловые блокировки добавляют задержку и делают её непредсказуемой.
SAN (Storage Area Network) даёт блочный доступ по iSCSI, Fibre Channel или NVMe-oF. Массив виден серверу как локальные диски, поэтому SAN выбирают для PostgreSQL, MySQL, MS SQL и кластеров виртуализации. Fibre Channel даёт предсказуемую latency и изоляцию трафика, iSCSI дешевле и работает поверх Ethernet 10/25/100 Гбит/с.
Пример разницы. PostgreSQL на SAN с дисковым кэшем и очередью 128 держит тысячи транзакций в секунду при latency около 0,3 мс. Та же база на SMB-шаре упирается в единицы миллисекунд на операцию и теряет стабильность на пиках. Матрица выбора DAS, NAS, SAN и HCI с учётом RPO, RTO и стоимости владения собрана в практическом сравнении архитектур хранения.
Распределённые и программно-определяемые СХД (SDS, HCI)
Хранилище собирают из обычных серверов: Ceph, VMware vSAN, MinIO. Отказоустойчивость обеспечивает софт: данные реплицируются или кодируются между узлами, выход одного сервера не останавливает кластер. Такие системы растут вширь: новый узел добавляет и ёмкость, и производительность.
SDS выгоднее классической SAN при объёме от 100 ТБ, потребности в линейном масштабировании и готовности администрировать кластер силами своей команды. Для 10-20 ТБ и команды без опыта Ceph проще взять классический массив. HCI объединяет вычисления и хранение в одном узле: vSAN и Nutanix сокращают число компонентов, но привязывают инфраструктуру к гипервизору.
Алгоритм выбора между SDS и аппаратными контроллерами с расчётом TCO разобран в сравнении программно-определяемых и аппаратных СХД.
Облачные хранилища: S3, блочные и файловые сервисы
Облако закрывает три модели доступа: объектную (AWS S3, MinIO, Yandex Object Storage), блочную (диски для виртуальных машин) и файловую (сетевые шары). Плюсы: нет CAPEX, ресурсы растут по щелчку, железо и его отказоустойчивость на стороне провайдера. Минусы: egress-платежи за выгрузку данных, latency выше локальной, зависимость от провайдера и рост расходов на длинных горизонтах.
Гибридная схема закрывает обе задачи: горячие данные лежат на локальных NVMe, архив и бэкапы уходят в S3. Для старта без закупки железа подойдут облачные платформы вроде Timeweb Cloud: серверы, базы данных, хранилище и Kubernetes арендуются по подписке.
Различия объектного, блочного и файлового хранения с таблицей критериев и примерами для Kubernetes разобраны в отдельной статье.
| Класс | Доступ и протоколы | Типовой сценарий | Сильные стороны | Ограничения |
|---|---|---|---|---|
| DAS | Блочный: SAS, SATA, NVMe | Один сервер, локальные данные | Низкая latency, низкая цена | Нет общего доступа, плохо масштабируется |
| NAS | Файловый: NFS, SMB | Общие каталоги, бэкапы, медиа | Простота, snapshots, права доступа | Высокая latency для БД, ограниченный throughput |
| SAN | Блочный: iSCSI, Fibre Channel, NVMe-oF | Базы данных, виртуализация | Предсказуемая latency, multipath | Дорого, нужна экспертиза |
| SDS и HCI | Зависит от ПО: блочный, файловый, объектный | Кластеры Ceph, vSAN | Рост вширь, commodity-железо | Сложная эксплуатация, нужна команда |
| Облако | S3 API, блочные и файловые сервисы | Веб-приложения, архивы, разработка | Нет CAPEX, эластичность | Egress-платежи, latency, зависимость от провайдера |
Архитектура СХД: из чего состоит система и где возникают узкие места
Типовая СХД состоит из контроллеров, кэша, дисковых полок, внутренних интерфейсов и ПО. Узкое место прячется в любом звене: перегруженный SAS Expander, один путь доступа, переполненный write-кэш или полка с медленными HDD.
Контроллеры, полки и топологии подключения
Корпоративные массивы строят по схеме active-active: два контроллера видят одни диски и делят нагрузку. При отказе одного второй забирает LUN и продолжает работу. Системы с одним контроллером создают single point of failure: отказ платы останавливает доступ ко всем данным.
Дисковые полки подключают по SAS с двумя путями (dual-domain) или через сеть. Multipath I/O (dm-multipath, ALUA) даёт два и более независимых маршрута до LUN: обрыв кабеля или сбой порта не рвёт доступ. Внутри полки данные идут через backplane и SAS Expander. Дешёвые expander с общей шиной становятся узким местом при десятках дисков.
Интерфейсы различаются по скорости и цене: SATA до 6 Гбит/с на порт, SAS 12-24 Гбит/с, NVMe через PCIe с миллионами IOPS на устройство, сетевой NVMe-oF переносит блочный доступ в Ethernet или InfiniBand.
Кэширование и tiering: как ускорить СХД без замены дисков
Кэш сглаживает разрыв между быстрыми интерфейсами и медленными HDD. Read-кэш ускоряет повторные чтения, write-кэш собирает мелкие записи в крупные. Battery-backed или flash-backed кэш сохраняет данные при отключении питания; без защиты записи теряются вместе с содержимым кэша.
Tiering раскладывает данные по уровням: горячие блоки на NVMe, тёплые на SAS SSD, холодные на HDD. Автоматический tiering есть в Dell PowerStore, NetApp и HPE. В ZFS ту же задачу решают ARC (кэш чтения в RAM), L2ARC (SSD-кэш чтения) и SLOG (быстрый журнал синхронной записи).
Уровни RAID и схемы резервирования: RAID 5 vs RAID 6 vs RAID 10
RAID объединяет диски в один логический массив и защищает от отказа части носителей. Уровень выбирают по компромиссу между ёмкостью, скоростью и числом допустимых отказов.
RAID 5 vs RAID 6: когда одного диска на отказ уже недостаточно
RAID 5 хранит чётность на всех дисках и переживает отказ одного. Минимум три диска, полезная ёмкость N-1. RAID 6 добавляет вторую чётность, переживает два отказа, требует минимум четыре диска и оставляет N-2 ёмкости.
Проблема в rebuild. Для HDD на 8 ТБ и больше восстановление длится сутки и дольше, и всё это время массив работает без запаса по отказам. Чтение всей поверхности нагружает оставшиеся диски, вероятность второго отказа за время rebuild растёт. Практическое правило: RAID 6 для массивов из шести и более HDD, RAID 5 для небольших наборов SSD, где rebuild занимает минуты.
Запись в RAID 5 требует четырёх операций ввода-вывода на логический блок (чтение старых данных и чётности, запись новых), в RAID 6 их шесть. Это write penalty, который снижает скорость случайной записи в разы и учитывается при расчёте IOPS.
RAID 10: производительность против ёмкости
RAID 10 сочетает зеркалирование и чередование. Минимум четыре диска, полезная ёмкость 50%, отказ одного диска в каждой паре переживается. Rebuild быстрый, потому что копия берётся с зеркала, а не вычисляется. Случайные чтение и запись идут на все зеркала параллельно, поэтому RAID 10 даёт максимум IOPS.
Сценарии: PostgreSQL, MySQL, MS SQL, виртуализация, всё с высокой плотностью случайных операций. Цена: половина дисков уходит на зеркала, для архивов это дорого.
RAID - это не бэкап: почему резервирование дисков не спасает данные
RAID защищает от отказа диска и ничего больше. Удаление файла, ошибка приложения, шифровальщик, сбой контроллера, пожар в стойке уничтожают данные на всех дисках массива сразу. Для защиты нужны snapshots, репликация и резервные копии по правилу 3-2-1: три копии, два носителя, одна копия вне площадки.
Hot spare диск ускоряет rebuild, но не заменяет внешнюю копию. ZFS использует RAIDZ1, RAIDZ2 и RAIDZ3: аналоги RAID 5, RAID 6 и тройной защиты с проверкой контрольных сумм. Классический RAID имеет write hole: сбой питания во время записи чётности оставляет массив в несогласованном состоянии. Battery-backed кэш и copy-on-write в ZFS снимают эту проблему.
| Уровень | Минимум дисков | Полезная ёмкость | Отказов выдерживает | Производительность | Сценарий |
|---|---|---|---|---|---|
| RAID 0 | 2 | 100% | 0 | Максимум | Временные данные без ценности |
| RAID 1 | 2 | 50% | 1 | Высокая на чтение | Системные диски, небольшие базы |
| RAID 5 | 3 | N-1 | 1 | Хорошая на чтение, слабая на запись | Небольшие массивы SSD |
| RAID 6 | 4 | N-2 | 2 | Хорошая на чтение, слабая на запись | HDD-массивы от шести дисков, архивы |
| RAID 50 | 6 | N минус 1 диск в каждой группе | 1 в группе | Средняя | СХД среднего класса |
| RAID 60 | 8 | N минус 2 диска в каждой группе | 2 в группе | Средняя | Большие HDD-массивы |
| RAID 10 | 4 | 50% | 1 в каждой паре | Максимум для случайных операций | Базы данных, виртуализация |
Производительность и масштабируемость СХД: IOPS, latency, throughput
Производительность описывают три метрики: IOPS (операций в секунду), latency (задержка одной операции) и throughput (пропускная способность в МБ/с). Базы данных и виртуализация зависят от IOPS и latency, бэкапы и медиа упираются в throughput.
Характер нагрузки важнее объёма. Последовательное чтение с HDD даёт 150-250 МБ/с, а случайные операции упираются в 100-200 IOPS на диск. NVMe на тех же случайных операциях выдаёт сотни тысяч IOPS. Смешивать такие профили в одном пуле нельзя.
Как посчитать требуемые IOPS и пропускную способность
Формула: требуемые IOPS = число активных пользователей умножить на операции одного пользователя в секунду. Для 1С: 500 сотрудников × 8 операций = 4000 IOPS. Для PostgreSQL: 500 транзакций в секунду, по 10 чтений и 5 записей каждая, итого 7500 логических операций, из них 5000 чтений и 2500 записей.
К записи добавляют write penalty RAID: коэффициент 4 для RAID 5, 6 для RAID 6, 2 для RAID 10. Пример выше на RAID 6: 2500 записей × 6 = 15 000 физических операций, плюс 5000 чтений, итого около 20 000 IOPS должен выдержать массив. Ориентиры latency: NVMe 0,05-0,2 мс, SATA SSD 0,1-1 мс, HDD 5-15 мс. Когда массив не успевает, растёт queue depth и latency поднимается лавинообразно.
Scale-up vs scale-out: когда что выбирать
Scale-up: усилить контроллер, добавить полки, заменить диски на быстрые. Путь проще, но упирается в потолок контроллера и число портов. Scale-out: добавить узлы в кластер Ceph или vSAN, ёмкость и производительность растут почти линейно, вместе с ними растут сложность и требования к сети.
Практическое правило: до 100-200 ТБ на одной площадке scale-up дешевле по трудозатратам. Дальше и при потребности в геораспределении выгоднее scale-out. Для виртуальных машин проверяют поддержку VAAI, ODX и число очередей: массивы без offload-механизмов перекладывают лишнюю работу на гипервизор. Настройка массивов под VMware vSphere, Hyper-V и KVM с чек-листами и нагрузочными тестами разобрана в руководстве по дисковым массивам для виртуализации.
Отказоустойчивость и резервное копирование: RPO, RTO и правило 3-2-1
Целевые метрики защиты задают до выбора железа. RPO это допустимый объём потерянных данных по времени, RTO это допустимое время простоя. RPO 15 минут означает копии каждые 15 минут, RTO 4 часа означает, что сервис обязан подняться за четыре часа.
Snapshots и репликация: что выбрать под задачу
Snapshot фиксирует состояние тома за секунды и позволяет откатиться после неудачного обновления или порчи файлов. Живут snapshots внутри той же системы и от отказа всей СХД не защищают.
Репликация переносит данные на другую систему. Синхронная даёт RPO около нуля, но каждая запись ждёт подтверждения от второй площадки, latency растёт. Асинхронная не тормозит приложение, зато при аварии теряются последние минуты данных. Erasure coding в Ceph (схема 4+2) даёт накладные расходы 1,5x против 3x у тройной репликации, но требует больше вычислений при восстановлении.
Immutable backups и air gap: защита от ransomware
Шифровальщики ищут доступные бэкапы первым делом. Копия на NAS в том же домене шифруется вместе с рабочими данными. Защита строится на иммутабельности: WORM-хранилища и S3 Object Lock запрещают изменение или удаление объекта до истечения срока. Второй контур это air gap: физически отключённая лента или диск с копией.
Современная версия правила 3-2-1 выглядит как 3-2-1-1-0: три копии, два разных носителя, одна копия вне площадки, одна неизменяемая копия и ноль ошибок при проверке восстановления. Бэкап без проверенного restore копией не считается.
Программные vs аппаратные СХД: TrueNAS, ZFS, Ceph против вендорских решений
Хранилище собирают из серверов под управлением открытого ПО или покупают готовый массив с поддержкой. Разница в деньгах, скорости запуска и зоне ответственности.
TrueNAS и ZFS: практические сценарии и подводные камни
TrueNAS и ZFS дают snapshots, контрольные суммы, RAIDZ и репликацию без лицензий. ZFS проверяет целостность каждого блока и лечит повреждения по копиям. Требования к ресурсам высокие: около 1 ГБ RAM на 1 ТБ ёмкости, ECC-память желательна, дедупликация съедает ещё больше памяти и замедляет запись.
RAIDZ2 из восьми дисков по 16 ТБ даёт около 96 ТБ полезной ёмкости и переживает два отказа. Mirror-пулы быстрее и дороже: 50% ёмкости против 25% потерь у RAIDZ2. TrueNAS оправдан для файлового сервера, бэкапов, NFS и iSCSI под виртуализацию, когда команда готова следить за состоянием пулов и читать документацию.
Ceph и распределённые SDS: когда сложность оправдана
Ceph строится минимум из трёх узлов, каждый диск работает как отдельный OSD. Данные распределяются по CRUSH-карте, пулы отдают блочный (RBD), файловый (CephFS) и объектный (RGW, S3 API) доступ. Кластер переживает отказ узла и продолжает обслуживать запросы. Цена: три и более сервера, сеть 10-25 Гбит/с, мониторинг и инженер, который понимает состояние placement groups.
Ceph выбирают при объёмах от 100 ТБ, потребности в объектном хранилище и горизонтальном росте. Для 5-20 ТБ это лишняя сложность. OpenMediaVault и Unraid закрывают домашние задачи и малые офисы, но не дают отказоустойчивости уровня кластера без ручной настройки.
Вендорские массивы (Dell PowerStore, NetApp, HPE) продают SLA, горячую замену компонентов и поддержку 24/7. Для импортозамещения в России 2026 года актуальны «Русский Щит 500» и Kraftway Storage: пошаговая настройка и сравнение с интеграцией с Postgres Pro собраны в обзоре российских СХД.
| Решение | Стоимость | Сложность | Поддержка | Сценарий |
|---|---|---|---|---|
| TrueNAS и ZFS | Железо, ПО бесплатно | Средняя | Сообщество | Файлы, бэкапы, iSCSI, до сотен ТБ |
| Ceph | Железо и ФОТ инженера | Высокая | Сообщество и вендоры | От 100 ТБ, S3, блочный и файловый доступ |
| OpenMediaVault и Unraid | Железо, ПО бесплатно | Низкая | Сообщество | Дом, малый офис, до 50 ТБ |
| Dell PowerStore, NetApp, HPE | Высокая: CAPEX и поддержка | Низкая для эксплуатации | Вендор 24/7 | Базы данных, виртуализация, критичные сервисы |
| Облако (S3, блочные диски) | OPEX по подписке | Низкая | Провайдер | Веб-приложения, архивы, стартапы |
Бюджет, TCO и типовые ошибки при развёртывании СХД
Стоимость СХД не заканчивается ценой дисков. TCO за пять лет включает железо, лицензии, поддержку, оплату труда, электричество и место в стойке.
Как посчитать TCO и обосновать бюджет перед руководством
Формула: TCO = CAPEX (серверы, диски, СХД, сеть) + OPEX за пять лет (поддержка, лицензии, электричество, ФОТ) + стоимость риска простоя. Поддержка вендорского массива стоит 10-20% от цены железа в год. Стойка с массивом на 100 ТБ потребляет 1,5-3 кВт, за пять лет электричество даёт заметную сумму.
Пример на 100 ТБ полезной ёмкости. Собственная СХД на TrueNAS: сервер, диски и сеть около 1,5-2,5 млн рублей, дальше электричество и администрирование. Облако: 100 ТБ в S3 по условным $20 за ТБ в месяц = $24 000 в год. За три года облако дороже собственной сборки, зато без CAPEX и с мгновенным масштабированием. Оценивайте стоимость гигабайта с учётом IOPS, latency и SLA. Если работа с ИИ ограничивается доступом к моделям и не требует обучения на своих данных, дешевле арендовать API через агрегатор вроде AiTunnel, чем строить собственный парк GPU с быстрым хранилищем под инференс.
Чек-лист ошибок при проектировании и запуске СХД
- thin provisioning без мониторинга: пул переполняется, тома уходят в read-only;
- нет проверки HCL: диски и контроллеры вне списка совместимости дают отвалы и просадку производительности;
- single point of failure: один контроллер, один путь, одна линия питания;
- неверный RAID под нагрузку: RAID 5 под базу с интенсивной записью;
- один пул под все задачи: бэкап и база конкурируют за одни и те же диски;
- нет мониторинга SMART, температуры и состояния пулов;
- редкие scrub и отсутствие тестов восстановления;
- смешивание моделей и прошивок дисков в одном массиве;
- заполнение массива больше чем на 80%: производительность и rebuild деградируют;
- бэкап в той же сети и под той же учётной записью, что и рабочие данные;
- нет документации на схему подключения и порядок восстановления;
- покупка без запаса по ёмкости и портам на три года.
FAQ: частые вопросы по выбору СХД
NAS или SAN: что выбрать?
Файлы, бэкапы и медиа: NAS с NFS или SMB. Базы данных, виртуализация и кластеры: SAN с блочным доступом по iSCSI или Fibre Channel. Один сервер без общего доступа: DAS.
RAID 5 или RAID 6?
RAID 6 для HDD-массивов от шести дисков: rebuild долгий, и второй отказ за это время реален. RAID 5 допустим на небольших наборах SSD, где восстановление занимает минуты.
Сколько IOPS нужно для 1С?
Считайте по активным пользователям: 500 сотрудников × 8 операций = 4000 IOPS, плюс запас 30-50%. К записи добавьте write penalty RAID: коэффициент 4 для RAID 5, 6 для RAID 6, 2 для RAID 10.
Можно ли ставить SATA SSD в enterprise-СХД?
Для чтения и тёплых данных можно, но SATA SSD медленнее NVMe, а ресурс записи (DWPD) у потребительских моделей ниже. Под интенсивную запись берите SAS SSD или NVMe с показателем 1-3 DWPD и выше.
Нужна ли ECC-память при ZFS?
ZFS проверяет контрольные суммы и без ECC, но при сбое обычной памяти повреждённый блок может быть записан вместе с корректной контрольной суммой. ECC закрывает класс ошибок, которые ZFS не увидит. Для продакшена ECC желательна.
Чем snapshot отличается от бэкапа?
Snapshot живёт внутри той же СХД и откатывает быстро, но гибнет вместе с массивом. Бэкап это отдельная копия на другом носителе, часто вне площадки и с защитой от изменений. Для восстановления после ransomware нужны бэкапы, желательно immutable.