Как выбрать систему хранения файлов для компании: критерии, сравнение и чек-лист

Почему выбор СХД - это стратегическое решение, а не просто покупка дисков

Файловый сервер на 4 ТБ, собранный три года назад под отдел из 15 человек, упирается в потолок ровно тогда, когда компания начинает расти: проектная документация прибавляет 15-20% в год, появляются видеозаписи совещаний, дампы баз и выгрузки аналитики.

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

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

Масштаб эффекта виден на смежной области. В складских системах автоматизация отдельных операций сокращает ошибки комплектования на десятки процентов, а время обработки заказа на 20-40% в зависимости от исходного уровня организации. В файловом хранилище работает та же логика: снапшоты по расписанию, квоты на отделы, отчёты о росте и единая точка выдачи прав экономят десятки часов ручной работы в месяц.

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

Ключевые критерии выбора системы хранения данных

Требования фиксируют до разговора с поставщиком. Восемь параметров закрывают почти все случаи: полезная ёмкость с запасом на 2-3 года, число одновременных пользователей и профиль нагрузки, производительность в IOPS и мегабайтах в секунду, уровень отказоустойчивости, бюджет с учётом CAPEX и OPEX, совместимость с Active Directory и виртуализацией, требования безопасности и план масштабирования.

Объём и прогноз роста данных

Расчёт начинают с факта: сколько данных занято сейчас в каждом каталоге и как быстро растут самые крупные папки. Полезно снять фактическое потребление за последние 6-12 месяцев и получить реальный темп прироста в процентах вместо оценки на глаз.

К текущему объёму добавляют запас: 30-50% на два-три года при умеренном росте, 100% и больше при работе с видео, логами или научными данными. Практический пример: если занято 5 ТБ, планируют 8-10 ТБ полезной ёмкости.

Считают по полезному объёму после RAID, а не по сумме дисков. RAID 6 из восьми дисков по 8 ТБ даёт 48 ТБ сырого объёма и около 43 ТБ полезного, из которых часть уходит под снапшоты, метаданные и резервные копии. В ZFS и похожих файловых системах стоит держать свободными 10-20% пула, иначе падает скорость записи.

Сценарии роста просчитывают в трёх вариантах: 20%, 50% и 100% прироста данных за год. Если при каждом сценарии расходы на хранение растут быстрее выручки, требования пересматривают, а часть данных переводят в архивный класс или в облако.

Типичная ошибка на этом шаге - подобрать систему под текущий объём. Полку под 100% сегодняшних данных обычно расширяют через год, и это часто выходит дороже, чем сразу взять корпус с запасом отсеков. Как устроен жизненный цикл данных на дисках и во что упирается ресурс SSD, разобрано в материале про хранение данных в серверных системах.

Число пользователей и нагрузка

Пользователей делят на три группы, потому что требования у них разные. Офисные сотрудники работают с документами и таблицами: им хватает файлового доступа по SMB или NFS и канала 1 GbE, который даёт около 110 МБ/с на поток. Инженеры и разработчики тянут крупные файлы: образы, датасеты, видеоматериалы, поэтому нужен 10 GbE (около 1,1 ГБ/с) или 25 GbE (около 2,8 ГБ/с), иначе копирование занимает часы. Приложения и базы данных требуют блочного доступа с задержкой ниже миллисекунды, и файловый протокол для них плохой выбор.

Ориентиры по количеству: для 10-50 человек с документами достаточно NAS среднего уровня на 8-12 отсеков с сетью 10 GbE и массивом 20-40 ТБ; при 100 и больше активных пользователей с тяжёлыми файлами смотрят на системы с кэшем NVMe или на SAN; для 1С, PostgreSQL и кластеров виртуализации считают IOPS и задержку, а не терабайты.

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

Отказоустойчивость и резервное копирование

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

Уровень RAID подбирают по числу дисков и допустимому риску. RAID 1 даёт зеркало и теряет половину ёмкости. RAID 5 переживает отказ одного диска, но на массивах из больших HDD восстановление длится 10-20 часов, и второй отказ в это время ломает массив. RAID 6 переживает два отказа и подходит для дисков от 8 ТБ. RAID 10 даёт максимальную скорость записи и быстрое восстановление из зеркала, но оставляет половину ёмкости.

Целевые показатели фиксируют заранее. Для критичных сервисов берут RPO меньше 15 минут и RTO меньше часа: это означает снапшоты каждые 15 минут, репликацию и проверенный план восстановления. Для офисных файлов достаточно RPO в сутки и RTO в несколько часов. Ориентир по доступности: 99,9% даёт около 8,8 часа простоя в год, 99,95% - около 4,4 часа.

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

Бюджет: CAPEX и OPEX

Считают совокупную стоимость владения за 3-5 лет, а не цену коробки. CAPEX включает корпус, диски, контроллеры, сеть, лицензии. OPEX включает поддержку вендора, электроэнергию, охлаждение, трафик и время администратора.

Ориентировочные диапазоны: NAS для малого офиса от 100 тыс. руб. без дисков; SAN от 500 тыс. руб. за начальную конфигурацию с двумя контроллерами; облачное объектное хранилище 1,5-5 тыс. руб. в месяц за 1 ТБ с учётом класса и региона, плюс плата за операции и выгрузку данных.

Скрытые расходы редко попадают в первую смету. Массив мощностью 100 Вт за год съедает около 876 кВт·ч, то есть 5-8 тыс. руб. по тарифам 6-9 руб. за кВт·ч. Выгрузка 10 ТБ из облака обходится в десятки тысяч рублей. Обучение администратора под Fibre Channel или Ceph занимает недели. Простой в час на 50 сотрудниках стоит дороже, чем разница между двумя моделями NAS.

Сравнение цен и списка функций из демоверсии ничего не решает. Итог зависит от профиля нагрузки, качества каталогов и дисциплины процессов, поэтому расчёт делают под конкретный сценарий компании.

Производительность, совместимость и безопасность

Производительность измеряют в IOPS и мегабайтах в секунду, и эти числа расходятся. Жёсткий диск 7200 об/мин выдаёт 100-180 IOPS при задержке 5-10 мс. SATA SSD даёт 10-90 тыс. IOPS на случайных операциях. NVMe выходит на 300 тыс. IOPS и выше при задержке ниже 0,1 мс.

Файловому серверу важнее последовательная скорость, базам данных - случайные операции и задержка. Сеть становится узким местом быстрее, чем диски: один поток SMB поверх 1 GbE редко превышает 110 МБ/с, поэтому 10 GbE и агрегация каналов дают заметнее прирост, чем замена HDD на SSD.

Совместимость и безопасность закрывают на этапе требований. Проверяют поддержку Active Directory, LDAP и Kerberos, работу с VMware, Hyper-V и Proxmox, наличие CSI-драйвера для Kubernetes. По безопасности фиксируют шифрование данных на дисках (AES-256, SED), шифрование транспорта, разграничение прав по ролям, журнал доступа и поддержку неизменяемых снапшотов.

Сравнение вариантов: локальные дисковые массивы, NAS, SAN и облачные сервисы

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

Развёрнутое сравнение архитектур, включая HCI, уровни RPO и RTO и стоимость владения, собрано в статье про DAS, NAS, SAN и HCI.

Локальные дисковые массивы (DAS)

Локальные массивы подключают напрямую к серверу по SAS, SATA или NVMe. Задержка минимальна, потому что между приложением и дисками нет сети. Совместная работа нескольких серверов с одним массивом без кластерной файловой системы невозможна, поэтому DAS закрывает задачи одного узла.

Типовые сценарии: хранилище для СУБД на выделенном сервере, диски под бэкапы Veeam, временные данные и кэш, полки расширения JBOD. Стоимость стартует от 50 тыс. руб. за 10 ТБ полезного объёма, а на NVMe цена за терабайт вырастает в несколько раз.

Ограничения проявляются на горизонте двух-трёх лет: корпус и контроллер упираются в потолок отсеков, перенос данных на новый узел требует простоя. Как настроить SAS-полки и в каких задачах DAS выигрывает у NAS по задержкам, разобрано в руководстве по прямому подключению хранилищ DAS.

NAS (Network Attached Storage)

NAS отдаёт файлы по SMB и NFS, поддерживает Active Directory, снапшоты, квоты и встроенную репликацию. Это самый быстрый путь к общему хранилищу: корпус на 4-8 отсеков, диски, пара часов на настройку.

Популярные платформы: TrueNAS на ZFS, Synology DSM, QNAP QTS. Критерии при выборе: число отсеков, поддержка RAID 6 и горячего резерва, сеть 1/10/25 GbE, возможность подключить полку расширения, снапшоты и репликация на второй NAS. Для 10-50 сотрудников обычно достаточно 4-8 отсеков, 10 GbE и 20-40 ТБ с учётом запаса на рост.

Узкие места возникают в двух местах. Экономия на дисках приводит к медленному массиву и долгому восстановлению. Экономия на сети превращает быстрый массив в хранилище со скоростью 110 МБ/с. Планировать стоит сразу 10 GbE и диски класса NAS с ресурсом записи, рассчитанным на пять лет круглосуточной работы.

SAN (Storage Area Network)

SAN даёт блочный доступ по iSCSI или Fibre Channel. Система рассчитана на кластеры: два контроллера, многопутевой доступ (MPIO), тонкое выделение томов, снапшоты и репликация между площадками. Fibre Channel работает на 16 и 32 Гбит/с, iSCSI - поверх 10 и 25 GbE.

Сценарии: кластеры VMware vSphere и Microsoft Hyper-V, отказоустойчивые базы данных, почтовые серверы, системы с жёсткими требованиями к задержке. Стартовая конфигурация начинается от 500 тыс. руб., а требования к персоналу выше: нужны отдельная сеть хранения или выделенный VLAN, понимание зонирования, маскирования LUN и многопутевых конфигураций.

Ошибки здесь стоят дороже всего. Отсутствие MPIO превращает отказ одного пути в недоступность тома, а неверное зонирование оставляет кластер без дисков после перезагрузки коммутатора.

Облачные сервисы хранения

Облачные сервисы отдают данные через S3-совместимый API, часть провайдеров предлагает файловые протоколы через шлюзы. Оплата идёт по подписке: нет CAPEX, нет задачи менять диски, ёмкость меняется за минуты.

Минусы тоже конкретны: зависимость от интернет-канала, ежемесячные расходы, которые растут вместе с объёмом, вопросы соответствия требованиям к персональным данным и плата за выгрузку. Арендованная инфраструктура тянет за собой дополнительные компоненты: аутентификацию, управление ключами, внешние API. Отдельная статья расходов появляется, когда к хранилищу добавляют внешние сервисы, например доступ к моделям ИИ через агрегатор вроде AiTunnel для обработки данных, которые лежат рядом.

Гибридный сценарий закрывает слабые места обеих моделей: горячие данные держат на локальном NAS, архив, бэкапы и редко используемые файлы уходят в облако. Если компания арендует виртуальные машины и объектное хранилище, удобен провайдер с серверами, базами данных, Kubernetes и хранилищем в одном кабинете, например Timeweb Cloud: часть инфраструктуры остаётся под контролем, а ёмкость меняется без закупки дисков.

Ориентиры по выбору: малому бизнесу с общими документами достаточно NAS; среднему бизнесу с виртуализацией и базами данных нужен SAN или производительная NAS с блочным доступом; распределённым командам и стартапам подходит облако; для объёмов от 100 ТБ почти всегда выгоднее локальное решение с облачным архивом. Масштабирование оправдано тогда, когда рост нагрузки не требует пропорционального роста всех затрат и ручного труда администратора.

Как вписать СХД в существующую инфраструктуру

Интеграцию проверяют до закупки, потому что несовместимость обнаруживается уже после оплаты. Аутентификацию связывают с Active Directory или LDAP: общие права, группы, единый вход. Для NFS в Linux-парке проверяют работу с Kerberos и корректное сопоставление UID и GID, иначе права на файлы разъедутся между серверами.

Виртуализация предъявляет свои требования. VMware vSphere стабильно работает с NFS-датастором и блочными LUN, Hyper-V предпочитает SMB 3.0 с поддержкой прямого ввода-вывода, Proxmox умеет и NFS, и iSCSI, и Ceph. Для Kubernetes выбирают CSI-драйвер: NFS подходит для артефактов и конфигураций, Ceph RBD или Longhorn - для баз данных и stateful-нагрузок внутри кластера. Какое хранилище выбрать под объектные, блочные и файловые сценарии в Kubernetes, разобрано в статье про объектное, блочное и файловое хранилище.

Сетевые требования фиксируют цифрами: 10 или 25 GbE для файлового доступа, отдельный VLAN для iSCSI, отключение энергосбережения на портах, MTU 9000 для крупных последовательных операций, агрегация каналов для отказоустойчивости. Проверяют не только пропускную способность, но и задержку: она чувствительнее к ошибкам настройки, чем скорость.

Перед полным переходом запускают пилот на 2-4 недели: часть отделов или резервные копии переносят на новую систему и снимают метрики. Смотрят не на синтетические тесты, а на реальные операции: открытие больших файлов, выкладку сборок, время ночного бэкапа, поведение при отказе одного диска. Тест восстановления из копии проводят до того, как он понадобится в аварии.

Типичные ошибки при выборе системы хранения и как их избежать

• Выбор под текущий объём. Массив заполняется за год, расширение идёт внепланово и дороже. Решение: считать ёмкость с запасом 30-50% и три сценария роста (20%, 50%, 100%).
• Надежда только на RAID. Массив переживает отказ диска, но не удаление файлов и не шифровальщика. Решение: отдельные копии на другом носителе плюс неизменяемые снапшоты.
• Недооценка сложности администрирования. SAN, Ceph и Fibre Channel требуют компетенций, которых в команде может не быть. Решение: посчитать время администратора в TCO или выбрать NAS с понятной поддержкой.
• Отсутствие тестов производительности и восстановления. Бэкап, который ни разу не восстанавливали, не считается бэкапом. Решение: пилот на 2-4 недели и учебное восстановление до запуска.
• Экономия на сети. Быстрые диски на канале 1 GbE дают 110 МБ/с. Решение: закладывать 10 GbE сразу.
• Расчёт без OPEX. Электроэнергия, охлаждение, трафик, поддержка вендора и обучение меняют картину за 5 лет. Решение: считать TCO на 3-5 лет.
• Оценка требований по короткому периоду. Несколько месяцев повышенной нагрузки не показывают реальный темп роста данных. Решение: брать данные минимум за год и учитывать сезонность.

Чек-лист вопросов перед покупкой или развёртыванием СХД

1. Сколько данных занято сейчас и какой прогноз на 2-3 года по трём сценариям роста?
2. Сколько одновременных пользователей и какие приложения создают нагрузку в пиковые часы?
3. Какой уровень отказоустойчивости нужен: какие RTO и RPO допустимы для каждой группы данных?
4. Как будет устроено резервное копирование, где хранятся копии и когда последний раз проверяли восстановление?
5. Каков бюджет в терминах CAPEX и OPEX на 3-5 лет, включая электроэнергию, поддержку и обучение?
6. Совместимо ли решение с Active Directory, виртуализацией и Kubernetes без дополнительных шлюзов?
7. Какие требования по шифрованию, разграничению прав, журналированию и неизменяемым снапшотам?
8. Есть ли возможность пилотного тестирования и сколько времени займёт вывод системы из эксплуатации?
9. Что входит в поддержку и SLA: сроки реакции, поставка дисков, обновления прошивок?
10. Как происходит масштабирование: добавление отсеков, полок, узлов и во сколько это обойдётся на следующем шаге?

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

Итог: как принять взвешенное решение

Алгоритм выбора укладывается в шесть шагов:

1. Собрать требования по критериям: ёмкость с запасом, пользователи, IOPS и задержка, RTO и RPO, безопасность, совместимость.
2. Сравнить DAS, NAS, SAN и облако по таблице выше и отбросить варианты, не проходящие по задержке или протоколу доступа.
3. Посчитать TCO на 3-5 лет с электроэнергией, поддержкой, обучением и временем администратора.
4. Провести пилотное тестирование на реальной нагрузке и учебное восстановление из копии.
5. Убедиться, что есть план масштабирования на два шага вперёд и понятная схема резервного копирования.
6. Зафиксировать решение и точку пересмотра требований, например через 12 месяцев или при росте данных на 50%.

Цель выбора - снизить операционную сложность и обеспечить предсказуемую работу сервисов, а не сэкономить на стартовой смете. Требования к хранилищу меняются вместе с бизнесом, поэтому раз в год полезно сверять фактические темпы роста данных с расчётными. Пошаговый алгоритм подбора с протоколами NFS, SMB и iSCSI и сравнением TrueNAS, OpenMediaVault и Unraid приведён в разборе критериев выбора СХД в 2026 году.