Краткий ответ: какую систему хранения выбрать
Универсально лучшей системы хранения нет. DAS подходит для локального сервера с минимальной задержкой, NAS закрывает совместный файловый доступ по сети, SAN предоставляет централизованный блочный доступ для кластеров и критичных баз данных, HCI объединяет вычисления и распределенное хранилище в едином кластере виртуализации. Выбор определяют профиль I/O, требования к доступности, RPO/RTO, ожидаемый рост, сетевая фабрика и компетенции команды.
Решение нельзя принимать по цене дисков или паспортным IOPS. Нужно сравнивать системы на целевой нагрузке: с близким размером блока, соотношением чтения и записи, глубиной очереди и поведением при отказе узла. Ниже разобраны матрица выбора, архитектурные различия, производительность для баз данных и ВМ, стоимость владения и порядок внедрения.
Если нужно быстро сопоставить типы доступа к данным, используйте шпаргалку по объектному, блочному и файловому хранилищу. Базовые принципы DAS, NAS, SAN и HCI с примерами офисов и ЦОД разобраны в этом руководстве.
Быстрая матрица выбора по типу нагрузки
| Сценарий | Рекомендация | Когда рекомендация перестает быть оптимальной |
|---|---|---|
| Одиночный сервер приложений или выделенная СУБД | DAS | Нужен общий доступ с нескольких хостов или кластер высокой доступности |
| Общие папки, домашние каталоги, медиаданные | NAS | Нужен блочный datastore для кластера или критичные СУБД с низкой задержкой |
| Кластер ВМ и критичные базы данных | SAN или HCI | SAN не подходит без отдельной сети и компетенций, HCI не подходит при независимом росте CPU и емкости |
| Распределенная виртуальная среда с предсказуемым горизонтальным ростом | HCI | Слабая сеть, редкий рост, жесткие требования к независимому масштабированию слоев |
Матрица работает как первичный фильтр. Для каждого случая ниже указаны условия, при которых стоит выбрать другую архитектуру.
С чего начать выбор системы хранения: требования, нагрузка и ограничения
Как описать профиль I/O без предположений
Производительность описывают четырьмя показателями: IOPS, задержка, пропускная способность и характер операций. IOPS показывает число операций в секунду, но без размера блока и соотношения чтения и записи эта цифра бесполезна. Задержка на уровне массива влияет на время отклика СУБД и приложений. Пропускная способность важна для последовательного чтения больших файлов, резервного копирования и архивов.
Для СУБД и datastore виртуализации важнее всего задержка при записи и поведение в пиковой конкуренции. Журнал транзакций PostgreSQL или MySQL создает мелкие синхронные записи, поэтому критичны латентность и стабильность при fsync. Файловый архив на десятки терабайт чаще упирается в пропускную способность и время обхода метаданных.
Перед выбором соберите средние и пиковые значения: общий IOPS, процент чтения и записи, размер блока, глубину очереди на хост, число одновременных клиентов. Нагрузочные пики измеряйте в моменты закрытия периода, резервного копирования и массового запуска ВМ после отказа хоста.
Какие RPO, RTO и требования к доступности зафиксировать
RPO определяет допустимую потерю данных после сбоя. Если RPO 5 минут, нужна репликация с малым журналом или синхронная запись на вторую площадку. RPO 24 часа разрешает ночные резервные копии. RTO определяет, сколько времени есть на восстановление сервиса. База данных с RTO 15 минут требует заранее подготовленного восстановления из проверенного backup или standby-сервера.
Зафиксируйте, допустим ли простой при обслуживании контроллера или узла, как быстро должна подняться ВМ после отказа хоста, нужна ли синхронная репликация между площадками и как проверяется восстановление. Решение с двумя контроллерами не равно автоматическому failover без проверки multipathing, синхронизации кэша и таймаутов приложений.
Резервное копирование, репликация и snapshots решают разные задачи. Snapshot ускоряет откат внутри массива, но не защищает от выхода массива из строя или шифровальщика. Репликация сохраняет копию на другой системе или площадке, но логическую ошибку может реплицировать мгновенно. Backup создает независимую точку восстановления с проверкой целостности.
Почему сеть становится частью производительности хранилища
NAS, SAN и HCI зависят от сети сильнее, чем DAS. Для iSCSI и NFS важны пропускная способность, задержка, резервирование каналов, MTU и изоляция трафика. Подъем MTU до 9000 снижает накладные расходы на больших кадрах, но все коммутаторы и узлы должны поддерживать этот режим. Multipathing и агрегация повышают доступность, но не всегда увеличивают пропускную способность одного потока.
Ping 0.1 ms и 0.5 ms между хостом и массивом дают разное поведение при синхронной записи и кластерных блокировках. Для систем с низкой задержкой проектируйте отдельные VLAN для storage, management и VM migration, настройте flow control и не пропускайте хранилище через перегруженное ядро сети. DAS локального сервера проще: путь к диску не проходит через сетевой стек, но появляется единая точка отказа на уровне сервера.
Архитектура DAS, NAS, SAN и HCI: принципиальные различия
Принципиальное отличие: где находятся диски, какой протокол предоставляет доступ и как обеспечивается отказоустойчивость. Перед выбором полезно понимать уровни хранилища: диски, RAID, пул, файловая система, кэш, сеть и репликация. Их разбор есть в материале про архитектуру программного хранилища.
DAS: локальные диски и прямое подключение к серверу
DAS означает прямое подключение дисков к одному серверу без отдельной сети хранения. Это внутренние SATA/SAS/NVMe-диски, локальный RAID или ZFS, внешние SAS-полки JBOD. Данные видны только этому серверу, если он сам не публикует их по сети.
Сильные стороны DAS: короткий путь I/O, минимальная задержка, отсутствие отдельной сетевой фабрики, понятная диагностика. Ограничения: совместный доступ с нескольких хостов организовать сложно, высокая доступность требует репликации на уровне приложения, СУБД или ОС, а при выходе сервера из строя локальные диски недоступны.
DAS разумен для выделенного сервера 1С, PostgreSQL или лабораторного гипервизора с резервным копированием на внешнюю систему. Он не обслуживает кластер VMware с живой миграцией ВМ между хостами.
NAS: файловое хранилище по сети
NAS предоставляет файловый доступ по сети через SMB или NFS. Клиент видит общий каталог и файлы, права доступа и блокировки, а не блочное устройство. Диски находятся в NAS-сервере, файловая система управляется на его стороне.
NAS упрощает общие каталоги, пользовательские папки, архивы и медиаданные. Производительность зависит от сети, скорости обработки метаданных, версии протокола и параллельного доступа. Большое число мелких файлов на SMB может деградировать быстрее, чем последовательное чтение крупных медиафайлов.
SAN: централизованное блочное хранение
SAN предоставляет хостам блочные устройства LUN по выделенной сети хранения: Fibre Channel, iSCSI или NVMe-oF. Файловую систему или datastore создает потребляющая сторона: гипервизор форматирует LUN в VMFS, ОС создает ext4 или XFS. Система хранения отвечает за RAID, снапшоты, репликацию и отказоустойчивость, но не за файловую семантику и блокировки.
SAN требует проектирования фабрики, zoning, multipathing, мониторинга портов и таймаутов. При правильной настройке SAN предсказуемо обслуживает кластеры ВМ и критичные СУБД. Квалификация команды и стоимость коммутаторов, HBA и лицензий выше, чем у NAS.
HCI: объединение вычислений и хранения в одном кластере
HCI объединяет вычисления и хранилище в одинаковых узлах. Локальные диски каждого узла программно объединяются в распределенное отказоустойчивое хранилище, на котором работают виртуальные машины этого же кластера. Доступ к данным идет по внутренней сети между узлами.
Сильные стороны HCI: масштабирование добавлением узлов, единая консоль управления, локальность данных в пределах узла, автоматическая репликация при отказе. Ограничения: рост вычислительных ресурсов и емкости связан, сеть между узлами критична, требуется проверенная HCL и лицензии.
HCI оправдан, если команда регулярно добавляет ВМ, готова обслуживать распределенную систему и хочет сократить число разрозненных консолей хранения и серверов.
Сравнение производительности: виртуализация, базы данных и файловые сервисы
Системы хранения для баз данных: приоритет задержки и стабильной записи
Для СУБД приоритет: задержка записи журнала транзакций, предсказуемость при fsync, случайные чтения горячих страниц. Одна база с 20 000 IOPS и 60 процентами записи блоками 8K может требовать разных конфигураций: DAS с NVMe для выделенного сервера, SAN с FC или NVMe-oF для кластера СУБД, HCI с достаточным числом узлов и правильной политикой репликации для виртуализированной базы.
DAS рационален для выделенного сервера PostgreSQL или MySQL с репликой на втором сервере. SAN нужен, когда несколько хостов обращаются к общему блочному ресурсу или требуется снапшот на массиве с коротким RPO. HCI оправдан, если СУБД работает как ВМ внутри общего кластера и вы готовы подтвердить задержку на пике PoC-тестом.
Репликация СУБД, RAID, snapshots и backup решают разные задачи. RAID закрывает отказ диска, репликация СУБД защищает от отказа сервера, но не от логической ошибки, snapshot массива ускоряет откат, backup нужен для независимого восстановления.
Виртуализация: плотность ВМ, смешанный I/O и отказ хоста
Для VMware, Hyper-V и Proxmox важны общий datastore, живая миграция, поведение при boot storm и восстановление после отказа хоста. Общий datastore на SAN или NFS позволяет запустить ВМ на другом хосте, если исходный вышел из строя. DAS подходит для автономных хостов или платформ с репликацией на уровне ПО, где ВМ копируется на второй сервер.
SAN предоставляет блочный datastore с низкой задержкой и возможностью multipathing. NFS на NAS проще в настройке, подходит для VMware и Proxmox, но зависит от качества сети и настроек NFS-таймаутов. HCI в кластере виртуализации упрощает добавление узлов, но требует равномерного распределения нагрузки между узлами и резерва ресурсов.
Практические настройки массивов для VMware, Hyper-V и KVM с multipathing, VAAI и ODX разобраны в отдельной инструкции.
Файловые сервисы: пропускная способность, метаданные и права доступа
Для общих папок, архивов, пользовательских каталогов и медиа выбирают NAS или файловый сервер. Важны пропускная способность, обработка метаданных, ACL, квоты и версии файлов. Протокол SMB удобен для Windows-клиентов, NFS для Linux-серверов и гипервизоров.
Большое число мелких файлов создает нагрузку на метаданные и может ограничивать IOPS больше, чем емкость дисков. Для десяти миллионов файлов полезнее SSD под метаданные и достаточный объем ARC или кэша. Если файловый сервис должен обслуживать много одновременных клиентов, тестируйте реальный профиль: создание, чтение, удаление мелких файлов и параллельное чтение крупных.
Контейнеры и Kubernetes: где заканчивается локальное хранилище
В Kubernetes выбор хранилища определяют Persistent Volumes, CSI-драйверы, StatefulSet и режимы доступа RWO или RWX. Локальные тома подходят для приложений, которые сами реплицируют данные, например Kafka или Elasticsearch, но не дают переносимости подов. Сетевое блочное хранилище через iSCSI или CSI подходит для баз данных в контейнерах, файловое NFS для общих конфигураций и артефактов.
Рекомендации для ВМ, Kubernetes и контейнерных платформ с CSI и снапшотами разбирает этот материал.
Стоимость владения и эксплуатация: что сравнивать помимо цены дисков
Начальная стоимость: серверы, диски, сеть и лицензии
Начальную стоимость считают по полному составу: серверы, накопители, контроллеры, HBA или NIC, коммутаторы, кабели, лицензии, поддержка и монтаж. SAN обычно требует отдельную фабрику и специализированные коммутаторы. HCI включает программные лицензии и сертифицированную конфигурацию узлов. DAS и NAS кажутся дешевле, но легко недооценить резервирование контроллеров, цены лицензий и будущее расширение.
Сравнивайте не доллар за терабайт, а стоимость за IOPS при целевой задержке и стоимость отказоустойчивой конфигурации. Два сервера с локальными SAS-дисками без репликации дешевле, но не решают задачу высокой доступности.
Когда команда не готова обслуживать собственное железо, облачная инфраструктура переводит часть CAPEX в OPEX. Например, Timeweb Cloud позволяет арендовать серверы и хранилище без закупки оборудования.
Сложность администрирования и требования к команде
DAS требует понимания RAID или ZFS, замены дисков и мониторинга SMART. NAS добавляет права, SMB/NFS, квоты и снапшоты. SAN требует zoning, LUN mapping, multipathing, диагностики потерь в фабрике и прошивок. HCI добавляет управление узлами, сетевыми доменами, ребалансировкой и обновлениями кластера. Автоматизация снижает рутину, но не отменяет разбор отказных сценариев.
Масштабирование емкости и производительности
Scale-up добавляет диски или контроллеры в существующую систему. Scale-out добавляет узлы. Добавление дисков может не увеличить производительность контроллера или сети. Добавление HCI-узла увеличивает и емкость, и CPU, даже если проекту нужно только одно из двух.
Планируйте запас по емкости, IOPS, портам, питаниям и доменам отказа. При выборе HCI уточняйте минимальное число узлов, поведение при репликации и максимальную загрузку кластера при отказе одного узла.
Какую архитектуру выбрать для типовых сценариев
Один сервер приложений или выделенная база данных
Выбирайте DAS, если сервер один, приложение или СУБД реплицирует данные на второй сервер, команда небольшая, а задержка критична. Обязательные меры: RAID10 или ZFS mirror, резервные диски, IPMI-мониторинг, проверенное резервное копирование вне сервера. Если позже появится кластер из трех хостов с общим datastore, DAS не заменит централизованное хранилище.
Файловый сервер для отдела или компании
Для SMB или NFS берите NAS с резервным контроллером или отказоустойчивую пару. Настройте интеграцию с Active Directory или LDAP, ACL, квоты, snapshots и независимое резервное копирование. Для больших архивов используйте SSD под метаданные и быстрый сетевой канал 10 или 25 GbE.
Кластер виртуализации для критичных сервисов
Для критичных сервисов выбирайте между SAN, NFS на NAS и HCI. SAN подходит, когда нужен независимый рост вычислительного и дискового слоев, низкая задержка и отлаженные FC или iSCSI-процессы. NFS на NAS быстрее внедрять, он совместим с гипервизорами, но требует правильных таймаутов. HCI выбирают для стандартных узлов и горизонтального роста.
Проверьте поддержку выбранного протокола в вашей версии гипервизора. Не все функции VMware или Hyper-V одинаково работают на NFS, iSCSI и FC.
Рост инфраструктуры и переход к HCI
Признаки перехода к HCI: регулярное добавление ВМ, потребность в одинаковых узлах, одна команда эксплуатации, несколько разрозненных консолей. Стоп-факторы: редкий рост, необходимость наращивать CPU и емкость независимо, слабая сеть 10 GbE без резерва, неподтвержденная HCL.
Если инфраструктура растет умеренно, возможно, проще оставить SAN и отдельный парк серверов. HCI выгоден там, где операционные затраты на сопровождение распределенной системы ниже, чем на поддержку SAN плюс серверов.
Проектирование и проверка решения перед внедрением
Соберите метрики текущей среды и прогноз роста
Замените оценку «на глаз» данными. Снимайте не менее 7-14 дней, включая резервное копирование и пиковые периоды. Показатели: занятая и выделенная емкость, сжатие и дедупликация, средние и пиковые IOPS, latency на чтении и записи, throughput, read/write ratio, размер блока, число ВМ или клиентов, загрузка сетевых портов.
Прогноз роста считайте по фактической динамике: объем прирастает на 15 процентов в год или на 30 процентов после нового проекта. Для баз данных прогнозируйте рост IOPS и latency отдельно от емкости.
Спроектируйте отказоустойчивость по доменам отказа
Разберите отказ диска, контроллера, хоста, коммутатора, линка, стойки и площадки. Резервирование должно переживать вероятный сбой без потери данных и с приемлемым RTO. Для SAN настраивайте два контроллера, два пути, две фабрики или два коммутатора. Для HCI храните реплики на разных узлах и при необходимости в разных стойках.
Проверьте, что происходит при деградации: продолжает ли база данных писать, не залипает ли NFS, переключается ли multipathing за ожидаемое время.
Проведите пилот и тесты, близкие к production
PoC должен воспроизводить целевой гипервизор, СУБД или файловый протокол. Измерьте latency в нормальном состоянии и при отказе одного пути или узла, тест переключения контроллера, прохождение backup окна, восстановление ВМ и базы данных из резервной копии. Фиксируйте результаты вместе с версиями ПО, прошивок и конфигурацией.
Один синтетический бенчмарк не переносится на production. Используйте целевой размер блока, глубину очереди и соотношение чтения и записи.
Внедрение и миграция: пошаговый план без лишнего риска
Подготовьте конфигурацию, сеть и мониторинг
Подготовьте адресацию, VLAN, multipathing или агрегацию, синхронизацию времени, совместимые драйверы и прошивки. Настройте оповещения о задержках, заполнении и отказах дисков. Сетевое хранилище должно быть изолировано от клиентского трафика.
Включите журналирование, мониторинг емкости и производительности до миграции, чтобы видеть исходную картину. Подготовьте схему подключений и список версий ПО.
Если хранилище будет использоваться для виртуализации, проверьте совместимость гипервизора с версией прошивки массива, драйверами HBA и функциями multipathing.
Переносите данные поэтапно с возможностью отката
Перенос выполняйте поэтапно. Начните с некритичной нагрузки, проверьте целостность и скорость, затем переносите базы данных и ВМ. До начала создайте полную резервную копию и подтвердите восстановление. Snapshot исходного массива не заменяет backup.
Определите окно работ. Для баз данных используйте standby или репликацию, чтобы сократить простой. Для файловых сервисов подходит rsync или robocopy с повторным прогоном для измененных файлов. Подготовьте план отката: как вернуться на старое хранилище, если миграция не уложится в окно или появятся ошибки.
Проверьте восстановление после запуска
После запуска проверьте восстановление файла, ВМ и базы данных в тестовом окружении. Отключите один сетевой путь, один контроллер или узел в рамках допустимого теста и убедитесь, что сервис продолжает работать. Контролируйте latency, fill rate и ошибки в течение первой недели.
Актуализируйте документацию: схема подключений, VLAN, порядок восстановления, контакты и версии. Формальное окончание миграции без проверки восстановления создает ложное чувство защищенности.
Ошибки при выборе DAS, NAS, SAN и HCI
Выбор по максимальным IOPS без анализа задержки и профиля нагрузки
Число IOPS зависит от размера блока, очереди, соотношения чтения и записи, сжатия и дедупликации. Максимальные IOPS из спецификации получены на одном типе нагрузки. Ваша база данных с блоками 8K, 70 процентами записи и глубиной очереди 16 может показать в несколько раз меньше.
Сравнивайте системы на сценарии, близком к целевой нагрузке, а не по цифре из брошюры. Проводите замеры при деградации и после заполнения массива на 70-80 процентов.
Смешение резервного копирования, репликации и snapshots
Snapshots, репликация и backup не взаимозаменяемы. Snapshot позволяет быстро откатить изменения, но хранится на том же массиве. Репликация синхронно или асинхронно переносит изменения, включая логические ошибки, если они уже записаны. Backup создает независимую точку восстановления, которую можно развернуть после выхода массива из строя, шифровальщика или административной ошибки.
Правило простое: snapshot для отката, репликация для доступности, backup для восстановления.
Игнорирование совместимости и эксплуатационной документации
Проверяйте HCL или матрицы совместимости: гипервизор, версия прошивки массива, драйверы HBA или NIC, протоколы и функции multipathing. Неподдерживаемая комбинация может привести к периодическим потерям путей, падению производительности или сбоям при обновлении.
Сохраните схему, параметры сети, порядок восстановления и результаты приемочных тестов в базе знаний команды. Перед обновлением сверяйте официальную документацию и стенд.