Как устроена система хранения данных: контроллеры, дисковые полки, кэш и интерфейсы | AdminWiki

Как устроена система хранения данных: контроллеры, дисковые полки, кэш и интерфейсы

18 сентября 2026 12 мин. чтения

Система хранения данных (СХД) объединяет накопители, контроллеры, кэш и интерфейсы в комплекс, который выдаёт серверам доступ к данным по блочным, файловым или объектным протоколам. Запрос от приложения проходит несколько уровней: файловая система или драйвер на сервере, транспорт (SAS, iSCSI, Fibre Channel), контроллер СХД, кэш, RAID-массив, физический носитель. Задержка растёт на каждом шаге, и тип хранилища определяет, на каком из них возникнет узкое место.

Базовая архитектура одинакова у настольного NAS на четыре диска и у стоечной СХД на тысячу накопителей. Различается масштаб: число контроллеров, объём кэша, количество дисковых полок, пропускная способность интерфейсов. Понимание этих узлов даёт ответ на практический вопрос: где упрётся нагрузка после её роста.

Ниже разобраны компоненты, путь данных, интерфейсы подключения и различия DAS, NAS и SAN на уровне устройства, а не рекламных формулировок.

Что такое СХД и из чего она состоит

СХД (система хранения данных) - комплекс аппаратных и программных средств, который централизованно хранит данные и выдаёт к ним доступ серверам и приложениям. Отдельный диск решает задачу ёмкости, а СХД решает задачу доступа: избыточность, кэширование, разграничение прав, снапшоты и репликация живут на уровне системы. Подробный разбор отличий СХД от диска и файлового сервера собран в материале про электронные системы хранения данных.

Базовый набор компонентов:

  • контроллеры, один или пара в отказоустойчивой конфигурации;
  • дисковые полки с накопителями HDD, SSD или NVMe;
  • кэш на DRAM или NVMe;
  • интерфейсы подключения: SAS, SATA, NVMe, Fibre Channel, Ethernet;
  • блоки питания с резервированием, системы охлаждения, датчики температуры;
  • ПО управления: RAID, тонкое выделение томов, снапшоты, репликация, мониторинг.

Архитектура системы хранения данных определяет, как эти блоки связаны между собой. Выделяют три схемы построения:

  • Монолитная. Контроллеры, диски и питание находятся в одном шасси. Ёмкость фиксирована на момент покупки, задержки минимальны, стоимость на терабайт высокая.
  • Модульная. Контроллерное шасси плюс полки расширения. Ёмкость растёт покупкой полок, контроллер остаётся общим ресурсом и постепенно превращается в узкое место.
  • Распределённая (SDS). Роли контроллера и хранилища распределены по серверам кластера, как в Ceph или vSAN. Масштабирование идёт узлами, требования к сети растут вместе с числом узлов.

Контроллер СХД: мозг системы

Контроллер СХД принимает запросы ввода-вывода, обслуживает дисковые полки, ведёт кэш, считает контрольные суммы RAID и представляет массивы серверам в виде томов или LUN. Потолок производительности задают процессор контроллера и объём NVRAM: когда CPU занят разбором очередей, задержки растут даже при свободных дисках.

Схемы резервирования контроллеров:

  • Active-active. Оба контроллера обслуживают нагрузку, каждый том закреплён за своим контроллером и при отказе переезжает на второй. Оборудование используется полностью.
  • Active-passive. Второй контроллер ждёт отказа основного. Схема проще, но половина ресурса простаивает.

Начальный уровень: один контроллер, 8-16 ГБ кэша, два порта 10 Гбит/с Ethernet под iSCSI, поддержка до 4-8 полок расширения. Enterprise-класс: пара контроллеров, 128-512 ГБ кэша с NVRAM-журналом, десятки портов Fibre Channel 32 Гбит/с, тысячи накопителей. Контроллер бывает встроенным в шасси СХД и внешним, когда его роль берёт на себя сервер с HBA и ПО уровня ОС: ZFS, Ceph, vSAN.

Дисковые полки: масштабирование ёмкости

Дисковая полка - шасси с объединительной платой, корзинами для накопителей и модулями питания. Типовые форматы: 2U на 12 дисков 3,5 дюйма, 2U на 24 диска 2,5 дюйма, 4U на 60 или 84 диска 3,5 дюйма. Полка подключается к контроллеру и добавляет ёмкость без замены основного шасси.

Интерфейсы подключения полок:

  • SAS. Wide port объединяет четыре линии по 12 Гбит/с, суммарно 48 Гбит/с на порт. Накопители с двумя портами подключаются к двум контроллерам и получают два независимых пути.
  • Fibre Channel и NVMe-oF. Применяются там, где полки вынесены на большее расстояние или нужна минимальная задержка.

Ограничения. Контроллер поддерживает конечное число полок: обычно 4-8 в начальном сегменте и десятки в enterprise. SAS-домен строится на экспандерах, и пропускная способность цепочки делится между всеми полками. Восемь полок по 24 HDD работают через общий канал, поэтому последовательные операции упираются в него раньше, чем в диски. Горячая замена накопителей проходит без остановки системы, но обрыв кабеля в середине цепочки лишает дальние полки одного из двух путей.

Кэш СХД: ускорение доступа к данным

Кэш СХД - быстрая память между контроллером и дисками. Кэш чтения хранит горячие блоки, кэш записи принимает данные и подтверждает операцию ввода-вывода раньше, чем они лягут на носитель. Задержка DRAM измеряется десятками и сотнями наносекунд, время доступа к произвольному блоку на HDD - единицами миллисекунд. Разница достигает трёх-четырёх порядков.

Режимы кэша записи:

  • Write-back. Контроллер подтверждает запись после размещения блока в кэше. Быстрее, но требует защиты кэша от потери питания.
  • Write-through. Подтверждение идёт после записи на носитель. Медленнее, зато сбой контроллера не приводит к потере принятых данных.

Защита кэша: батарея или связка конденсаторов с flash-памятью (NVRAM). После сбоя питания контроллер восстанавливает журнал и дописывает блоки на диск. Если модуль защиты вышел из строя, прошивка часто автоматически переводит кэш в режим write-through, и производительность записи падает в разы.

Объёмы: 8-64 ГБ на контроллер в начальном сегменте, 128-512 ГБ и больше в enterprise. Второй уровень образует NVMe-кэш, он же tiering: горячие блоки переносятся на SSD, холодные остаются на HDD. Результат зависит от доли попаданий. При 95% попаданий в DRAM средняя задержка чтения падает до микросекунд, при 20% кэш почти не помогает и нагрузка уходит на диски.

Путь данных от приложения до физического носителя

Последовательность обработки одного запроса чтения:

  1. Приложение вызывает системный вызов и передаёт его файловой системе или драйверу блочного устройства.
  2. ОС формирует запрос ввода-вывода к тому или LUN и отправляет его по транспорту: локальному SAS, iSCSI поверх Ethernet или Fibre Channel.
  3. Контроллер СХД принимает команду, определяет LUN по идентификатору и проверяет кэш.
  4. При попадании данные возвращаются из DRAM, диски не задействованы.
  5. При промахе контроллер вычисляет физический адрес в RAID-массиве и читает нужные блоки с нескольких накопителей.
  6. Проверяются контрольные суммы, при необходимости данные восстанавливаются по чётности.
  7. Результат возвращается в кэш, затем по транспорту на сервер и в приложение.

Запись идёт теми же шагами с той разницей, что контроллер распределяет новые блоки по дискам, пересчитывает чётность и подтверждает операцию по политике кэша. Задержки складываются: передача по сети, очередь на контроллере, поиск на диске, возврат данных. Понимание цепочки позволяет найти узкое место измерением, а не заменой оборудования наугад. Как данные живут дальше, включая появление на носителе, миграцию между уровнями и вывод из эксплуатации, разобрано в статье про жизненный цикл данных в серверных системах.

Уровни абстракции хранения данных

Уровни абстракции хранения данных определяют, в каком виде потребитель видит хранилище:

  • Физический. Накопители, сектора 512 байт (512e) или 4096 байт (4Kn), адреса LBA. Прямого доступа у приложений нет.
  • Блочный. Том или LUN, который сервер видит как обычный диск. С этим уровнем работают СУБД, гипервизоры и кластерные файловые системы, а размещение блоков и RAID остаются задачей контроллера.
  • Файловый. Файловая система (ext4, XFS, ZFS, NTFS) и сетевые протоколы NFS, SMB. Права, блокировки и метаданные держит сторона хранилища.
  • Объектный. Бакеты и ключи вместо каталогов, доступ по HTTP API, чаще всего S3. Метаданные расширяемые, ёмкость растёт почти линейно.

Уровень диктует нагрузка: база данных получает блочное устройство, общий файловый сервер - файловый доступ, архив неструктурированных данных - объектное хранилище. Один физический массив способен отдавать все три уровня одновременно, если контроллер это поддерживает.

Роль RAID и томов в пути данных

RAID объединяет физические диски в логический том с избыточностью. Контроллер СХД считает чётность или держит зеркала, а серверу показывает готовый LUN.

  • RAID 0. Чередование без защиты. Скорость максимальная, отказ одного диска теряет весь массив.
  • RAID 1. Зеркало из двух дисков. Чтение идёт с обоих, массив переживает отказ одного накопителя.
  • RAID 5. Чётность на N+1 дисках. Теряет ёмкость одного диска, переживает один отказ, но долго восстанавливается на больших накопителях.
  • RAID 6. Двойная чётность, переживает два одновременных отказа. Запись медленнее из-за двойного пересчёта.
  • RAID 10. Зеркала, объединённые в страйп. Высокая скорость записи и быстрое восстановление, полезная ёмкость 50%.

RAID защищает от отказа диска и не заменяет резервное копирование: ошибка оператора, шифровальщик или сбой контроллера уничтожают данные на всех дисках массива сразу. Тонкое выделение томов добавляет гибкость: LUN получает больше ёмкости, чем занято физически, а место расходуется по мере записи. Снапшоты фиксируют состояние тома на момент времени и позволяют откатить изменения без полного копирования.

Интерфейсы подключения СХД: SAS, SATA, NVMe, Fibre Channel

Интерфейс определяет потолок по пропускной способности и задержке. Сравнение по ключевым параметрам:

ИнтерфейсПропускная способностьОсобенностиТиповое применение
SATA6 Гбит/с, полудуплексОдин порт на диск, двух независимых путей нетNearline HDD, недорогие SSD, архив
SAS12 Гбит/с на линию, 22,5 Гбит/с в последних поколенияхПолный дуплекс, два порта, адресация через экспандерыEnterprise HDD и SSD, подключение полок
NVMe через PCIePCIe 4.0 x4 около 7,9 ГБ/с, PCIe 5.0 x4 около 15,7 ГБ/сЗадержка порядка 100 микросекунд и ниже, глубокая очередь командВысоконагруженные базы данных, кэш
Fibre Channel32 и 64 Гбит/сОтдельная фабрика, зонирование, предсказуемые задержкиSAN для виртуализации и СУБД
iSCSI10, 25, 100 Гбит/с EthernetБлочный доступ по TCP, дешевле FC, зависит от качества сетиSAN в среднем сегменте
NVMe over FabricsЗависит от транспорта: FC, RoCE, TCPСемантика NVMe поверх сети храненияНовые SAN и распределённые СХД

Практические ориентиры. Для баз данных и виртуализации берут NVMe или SAS SSD, чтобы интерфейс не ограничивал IOPS накопителей. Для файлового архива и резервных копий хватает SATA или SAS HDD. Fibre Channel выбирают там, где нужна изолированная сеть хранения и предсказуемая задержка, iSCSI даёт блочный доступ поверх обычной Ethernet-инфраструктуры при меньшем бюджете. Учтите арифметику: порт 10 Гбит/с пропускает около 1,2 ГБ/с, а полка из 24 HDD выдаёт последовательное чтение на 4-5 ГБ/с. Сеть легко становится узким местом раньше дисков.

DAS, NAS и SAN: различия на уровне устройства

Три аббревиатуры описывают способ подключения и тип доступа, а не класс оборудования.

  • DAS (Direct Attached Storage). Накопители подключены напрямую к серверу: SATA, SAS, PCIe. Доступ блочный, задержка минимальна, сеть не участвует. Массив обслуживает один сервер или один кластер с общим доступом к дискам, наращивать ёмкость для других систем нельзя.
  • NAS (Network Attached Storage). Устройство с собственной файловой системой, которое отдаёт файлы по NFS или SMB через Ethernet. Сервер видит каталоги, а не диски. Права, блокировки и снапшоты остаются на стороне NAS.
  • SAN (Storage Area Network). Отдельная сеть хранения, по которой серверы получают блочные LUN. Транспортом выступают Fibre Channel, iSCSI или NVMe-oF. Доступ управляется зонированием и маскированием LUN, отказоустойчивость обеспечивает многопутевой ввод-вывод (MPIO).

Ключевое различие лежит в уровне доступа и протоколе. NAS отдаёт файлы, SAN отдаёт блоки, DAS отдаёт блоки без сети. Тот факт, что современный NAS умеет работать iSCSI-таргетом, не превращает его в SAN: SAN подразумевает сеть хранения с разделением трафика, несколькими путями и отдельным управлением зонами. Сравнение по производительности, RPO/RTO и стоимости владения собрано в материале про выбор между DAS, NAS, SAN и HCI.

Когда выбирать DAS, NAS или SAN

КритерийDASNASSAN
Число серверов-потребителейОдин сервер или кластерМного, доступ по сетиМного, до сотен хостов
Тип доступаБлочныйФайловый (NFS, SMB), дополнительно блочный по iSCSIБлочный (FC, iSCSI, NVMe-oF)
ЗадержкаМинимальнаяЗависит от сети и протоколаНизкая при FC и NVMe-oF
Типовые задачиЛокальные диски, лаборатория, СУБД на выделенном сервереОбщие файлы, бэкапы, медиатека, инфраструктурные шерыВиртуализация, базы данных, кластеры
МасштабированиеОграничено корпусом и контроллером сервераПолками и кластером NASПолками и портами фабрики
Стоимость входаНизкаяСредняяВысокая: коммутаторы, HBA, лицензии

Ориентиры выбора. Один сервер с локальной нагрузкой закрывает DAS. Файловые шеры, бэкапы и совместная работа десятков пользователей требуют NAS. Виртуализация с десятками ВМ, СУБД с высокими IOPS и требование к RPO/RTO в минуты толкают к SAN. Границы размываются: гиперконвергентные системы раздают блочный доступ поверх Ethernet, а NVMe over Fabrics переносит семантику NVMe в сеть.

Как архитектура СХД влияет на производительность и надёжность

Каждый компонент отвечает за свою характеристику:

  • контроллер и его кэш определяют потолок IOPS и среднюю задержку;
  • дисковые полки и интерфейсы задают пропускную способность, важную для последовательных операций и репликации;
  • RAID и резервирование контроллеров, путей и питания определяют доступность.

Числа помогают оценить баланс. Один HDD 7200 об/мин выдаёт порядка 75-100 случайных IOPS, поэтому 24 таких диска в RAID 6 дают около 2000-2400 IOPS, а двойная чётность забирает часть производительности на запись. Один SATA SSD выдаёт десятки тысяч случайных IOPS, один NVMe - сотни тысяч. Если после перехода на SSD прирост исчез, узкое место переехало на контроллер или сеть. Проверяйте это измерением: счётчики задержки и глубины очереди на контроллере показывают насыщение точнее, чем загрузка дисков.

Надёжность строится на устранении единых точек отказа: два контроллера, два пути к каждой полке, два блока питания, резервные каналы сети хранения. Восстановление массива после отказа диска занимает часы, а на накопителях 16 ТБ и больше может превышать сутки, и всё это время массив работает с пониженной избыточностью. Скорость восстановления и поведение системы в этот период стоит проверять заранее. Классификацию СХД, расчёт IOPS и схемы резервирования разбирает статья про СХД в 2026 году.

Типичные ошибки при проектировании СХД

  • Малый кэш под случайную нагрузку. Кэш на 8 ГБ не удержит рабочее множество базы данных на сотни гигабайт, доля попаданий упадёт, и вся нагрузка уйдёт на диски.
  • SATA в нагруженной системе. Полудуплексный интерфейс без второго порта не даёт построить два независимых пути, а очередь команд уступает SAS и NVMe.
  • Один контроллер в проде. Отказ контроллера останавливает доступ ко всем данным, даже если диски исправны.
  • RAID 5 на больших дисках. Время восстановления растёт вместе с ёмкостью, а второй отказ в этот период приводит к потере массива.
  • Отсутствие мониторинга. Без отслеживания SMART, состояния батареи кэша, температуры и очередей отказ приходит неожиданно.
  • Смешивание нагрузок. Бэкап и база данных на одних дисках конкурируют за шпиндели, задержки растут у обеих задач.
  • Забытая сеть. При iSCSI гигабитный канал и отсутствие MPIO сводят на нет возможности массива.
  • Непроверенный сценарий отказа. Отключение кабеля и контроллера на тестовом стенде показывает реальное поведение системы, а не заявленное в спецификации.

Практические сценарии: как применить знания при выборе СХД

Виртуализация, 50 виртуальных машин. Профиль нагрузки смешанный, пики приходятся на старт ВМ и на бэкапы. Нужен блочный доступ с нескольких хостов, поэтому подходит SAN: массив с двумя контроллерами, SAS SSD или NVMe, RAID 10, кэш записи с NVRAM, подключение по 32 Гбит/с FC или 25 Гбит/с iSCSI, MPIO и минимум два коммутатора. Запас по IOPS считают от суммы профилей ВМ с коэффициентом на пики.

Файловый сервер на 100 пользователей. Основная нагрузка - открытие документов и бэкапы. Достаточно NAS: 12-24 nearline HDD в RAID 6, SSD под метаданные и журнал, 10 или 25 Гбит/с Ethernet, снапшоты по расписанию и репликация на второй NAS. Ёмкость планируют с запасом 20-30% на снапшоты и рост данных.

Домашняя лаборатория на TrueNAS. Роль контроллера берёт на себя ОС с ZFS, диски подключаются через HBA в режиме прямого доступа, аппаратный RAID не используется. Схема: RAIDZ2 на 6-8 дисках, отдельный NVMe под SLOG и L2ARC, 10 Гбит/с Ethernet, регулярные снапшоты и отправка копий на второй пул. Программные и аппаратные подходы сравниваются в статье про выбор аппаратной или программной СХД.

Перед покупкой зафиксируйте ответы на четыре вопроса: сколько хостов обращаются к данным одновременно, какие IOPS и задержка нужны в пике, какой объём данных вырастет за три года и какой RPO/RTO допустим. Эти цифры определяют тип доступа, интерфейс, уровень RAID и запас по контроллеру. Дальше остаётся проверить конфигурацию на стенде: снять метрики задержки, провести восстановление массива и смоделировать отказ пути.

Поделиться:
Сохранить гайд? В закладки браузера