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

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

Маршрут выглядит так: 1) замер нагрузки, 2) расчёт ёмкости, IOPS и пропускной способности, 3) выбор форм-фактора сервера и полки, 4) подбор HDD, SSD и NVMe, 5) выбор RAID-контроллера или HBA и интерфейсов, 6) проверка совместимости по HCL, 7) решение «готовая СХД или сборка». Ошибка на первых двух шагах обходится дороже всего: неверный расчёт ёмкости приводит к покупке лишних полок, а недооценка IOPS к тому, что массив не тянет базу данных на пике.

Пример: файловое хранилище на 100 ТБ с соотношением чтения и записи 70/30 и потребностью в 5000 IOPS требует совершенно разных конфигураций, если речь о холодном архиве или о рабочем каталоге с тысячами мелких файлов. В первом случае хватит HDD-пула, во втором без NVMe под метаданные и кэш средняя задержка вырастет в десятки раз.

Какие вопросы задать до выбора оборудования

Список вопросов, который стоит согласовать с командой и бизнесом до открытия прайс-листа:

• Объём сейчас и через 2-3 года. Считайте скорость роста данных, а не только текущий объём. Без своей статистики закладывайте 20-30% в год и держите запас по слотам.
• Профиль нагрузки. Последовательные потоки (медиа, бэкапы) или случайные блоки по 4-8 КБ (СУБД, виртуальные машины). Отдельно зафиксируйте read/write mix, например 70/30.
• Допустимая задержка. Для архива приемлемы 10-20 мс, для транзакционной базы нужны единицы миллисекунд и меньше.
• IOPS и пропускная способность. Конкретные цифры для выбора дисков и интерфейсов, а не пожелание «побольше».
• Снапшоты и репликация. Они занимают место и требуют ресурса на запись.
• Бюджет CAPEX и OPEX. Стоимость владения включает электричество, охлаждение, лицензии и поддержку.
• Кто обслуживает. Своя команда с опытом в Linux и ZFS или вендорский контракт с SLA 24/7.

Пример на контрасте: для хранилища бэкапов достаточно HDD-пула и сети 1 Гбит/с, потому что узкое место здесь в скорости восстановления, а не в IOPS. Для базы данных с 10 000 IOPS и задержкой до 1 мс нужны NVMe и сеть 25 или 100 Гбит/с, иначе диски будут простаивать в ожидании данных.

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

Типичные ошибки на старте проекта

• Покупка «на вырост» без расчёта IOPS. Сервер с 24 слотами и двумя HDD даёт меньше транзакций, чем 8 NVMe. Последствие: через полгода докупается полка, а бюджет уже израсходован.
• Ориентация только на объём. 100 ТБ на HDD и 100 ТБ на NVMe решают разные задачи. Последствие: база данных на медленных дисках и постоянные жалобы пользователей.
• Игнорирование роста данных. Пул, заполненный на 95%, деградирует: у ZFS растёт фрагментация и падает скорость записи. Держите 20-30% свободными.
• SATA SSD под интенсивную запись без учёта DWPD. Модель с ресурсом 0,3 DWPD в SLOG или под журнал СУБД выходит из строя за считаные месяцы.
• Нет запаса по слотам и портам. Все PCIe-слоты заняты, свободных разъёмов питания нет, добавить NVMe некуда.
• Полка куплена без проверки совместимости. Backplane не поддерживает нужное поколение PCIe, контроллер не видит диски в режиме IT.

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

Форм-факторы серверов и дисковых полок: что реально влезет в стойку

Форм-фактор определяет, сколько дисков поместится в корпус, сколько останется слотов расширения и как всё это охлаждать. В стойке 19 дюймов доступны высоты 1U, 2U и 4U, и каждая закрывает свой класс задач.

• 1U. Обычно 4 отсека LFF (3,5 дюйма) или 8-10 SFF (2,5 дюйма), 1-2 слота PCIe, маленькие вентиляторы с высокой частотой вращения. Подходит для узла с NVMe-зеркалом или для сетевых функций.
• 2U. 12 LFF или 24 SFF, 3-8 слотов PCIe, нормальное охлаждение. Универсальный вариант для виртуализации и небольших СУБД.
• 4U. 24-60+ отсеков LFF, место под полноразмерные карты и крупные вентиляторы. Сюда же относятся дисковые полки JBOD на 60 отсеков.

Плотность NVMe ограничена не отсеками, а линиями PCIe. 24 NVMe в 2U требуют либо большого числа линий от процессора, либо PCIe-коммутаторов на backplane. Проверяйте, поддерживает ли backplane нужное поколение PCIe 4.0 или 5.0, а платформа разделение линий (bifurcation) на x4.

Сервер или дисковая полка: что выбрать

Практическое правило: пока дисков не больше 12-24 и они помещаются в корпус, отдельная полка не нужна. Как только требуется 24+ дисков или разделение вычислительных узлов и хранилища, берут JBOD-полку и подключают её по SAS.

Пример: сервер 2U на 12 LFF плюс полка 4U на 24 LFF дают 36 отсеков и возможность расширения без замены сервера. Для полки нужен RAID-контроллер или HBA с внешними портами и SAS-кабели подходящего поколения.

Совместимость полки и контроллера проверяют до заказа: не все HBA работают с конкретными моделями JBOD, а часть требует определённых версий прошивки. Как габариты и форм-факторы дисков влияют на плотность в ТБ на юнит, разобрано в материале «Габариты СХД и плотность хранения данных».

Ограничения стоек, питания и охлаждения

Чек-лист перед закупкой:

• Глубина стойки. Типичные значения 1000-1200 мм. Сервер глубиной 800 мм не встанет в шкаф на 600 мм вместе с кабелями.
• Нагрузка на полку. Полностью заполненная 4U-полка на 60 дисков весит 100 кг и больше, статическая нагрузка на направляющие ограничена.
• Мощность на юнит. Считайте пиковое потребление. Полка на 60 LFF с двумя блоками питания потребляет 800-1200 Вт.
• Тепловыделение. Переведите ватты в BTU/ч (1 Вт ≈ 3,41 BTU/ч) и сверьте с мощностью кондиционеров.
• Направление airflow. Front-to-back у большинства серверов; перегородки и пустые юниты ломают поток воздуха.
• Кабельная организация. Два SAS-кабеля, сеть, питание, KVM: запас по длине обязателен.

Вентиляторы 1U шумят на 60-70 дБА, 4U с крупными вентиляторами тише и эффективнее. Экономия на охлаждении приводит к троттлингу процессора и перегреву дисков, а работа при температуре выше 40 °C заметно сокращает срок службы HDD.

Типы накопителей HDD, SSD и NVMe для сервера: что и куда ставить

Разница в цене между HDD и NVMe за гигабайт достигает 20-50 раз, поэтому стратегия «всё на NVMe» редко оправдана. Рабочая схема: холодные данные и бэкапы на HDD, горячие данные и метаданные на NVMe, промежуточные задачи на SSD.

Ориентиры по подбору: для бэкапов, архивов и медиатеки хватает HDD, потому что нагрузка здесь последовательная. Для виртуализации и кэша подходят SATA или SAS SSD. Для баз данных, аналитики и высоких IOPS выбирайте NVMe. Где проходит граница, определяет расчёт, а не прайс-лист.

Как endurance и тип памяти влияют на выбор

Два SSD одинакового объёма могут отличаться по цене втрое, и причина в ресурсе записи. Показатель DWPD (drive writes per day) говорит, сколько раз за сутки можно перезаписать весь объём диска в течение гарантийного срока. TBW (terabytes written) показывает суммарный объём записи в терабайтах.

• 0,3 DWPD: потребительские и nearline-модели, только для чтения и лёгкой записи.
• 1 DWPD: read-intensive, подходят для кэша и пулов виртуализации со средней нагрузкой.
• 3 DWPD: mixed-use, оптимум для большинства серверных задач.
• 5-10 DWPD: write-intensive, для SLOG, журналов СУБД и интенсивной записи.

Тип памяти тоже имеет значение: TLC выдерживает больше циклов перезаписи и держит скорость, QLC дешевле и подходит для чтения и редко обновляемых данных. Пример из практики: SATA SSD с ресурсом 0,3 DWPD, поставленный в ZFS SLOG, выходит из строя за считаные месяцы, а сбой SLOG без резервирования приводит к потере последних записей.

Смешанные конфигурации: HDD + SSD + NVMe

Типовые схемы на ZFS и в системах с ярусным хранением:

• HDD-пул плюс кэш чтения L2ARC и лог записи SLOG на SSD.
• NVMe под метаданные (special vdev) или отдельный пул для СУБД, HDD под данные.
• Ярусное хранение: горячий слой на NVMe, тёплый на SSD, холодный на HDD.

Пример сборки: 12 HDD по 16 ТБ в RAIDZ2, 2 NVMe по 1,92 ТБ в зеркале под SLOG, 2 NVMe под метаданные. Кэш не заменяет расчёт IOPS: при случайной записи L2ARC почти не помогает, а SLOG ускоряет только синхронные операции. Перед закупкой проверьте, поддерживает ли backplane нужное число NVMe и работает ли bifurcation на выбранных слотах.

Расчёт ёмкости, IOPS и пропускной способности под реальную нагрузку

Расчёт делается один раз, но определяет стоимость всего проекта. Три цифры нужны до выбора железа: полезная ёмкость, IOPS под пиковую нагрузку и пропускная способность в МБ/с или ГБ/с.

Как считать полезную ёмкость с учётом RAID и резерва

Формула: полезная ёмкость = сырая ёмкость × коэффициент уровня RAID × (1 - резерв файловой системы и снапшотов).

Пример для 12 дисков по 16 ТБ:

• Сырая ёмкость: 192 ТБ.
• RAID 6 или RAIDZ2 теряют два диска: 160 ТБ.
• Резерв 20% на метаданные, снапшоты и деградацию: около 128 ТБ полезной ёмкости.
• RAID 10 из тех же дисков дал бы 96 ТБ, зато с вдвое большей скоростью записи.

Правило: планируйте минимум 20-30% свободного места, а для 100 ТБ данных закладывайте около 150 ТБ полезной ёмкости с учётом роста и снапшотов. Репликация удваивает требования, если копия лежит на том же массиве. Методика расчёта для бэкапов и архивов с политикой хранения и дедупликацией приведена в статье «Как рассчитать размеры систем хранения под бэкапы и архивы».

Как перевести нагрузку в IOPS и пропускную способность

IOPS = число дисков × IOPS одного диска × коэффициент RAID. Коэффициент учитывает штраф на запись: RAID 10 требует двух операций на запись, RAID 5 четырёх, RAID 6 шести.

Пример: 10 HDD 7.2K в RAID 6 при 150 IOPS на диск дают около 1500 IOPS на чтение и всего 250 IOPS на запись (1500 / 6). При соотношении 70/30 эффективная производительность составит примерно 1100 IOPS, чего мало для виртуальных машин и баз данных.

Чтобы получить 5000 IOPS на смешанной нагрузке, придётся собрать 40-50 HDD в RAID 10 либо поставить зеркало из двух NVMe, которые дают сотни тысяч IOPS и снимают вопрос полностью.

Пропускная способность считается так: число дисков × скорость одного диска. Десять HDD по 250 МБ/с выдают около 2,5 ГБ/с последовательного потока, и это больше, чем обеспечит сеть 10 Гбит/с (примерно 1,18 ГБ/с). Если хранилище подключено по 10 Гбит/с, ставить 24 NVMe бессмысленно: узким местом станет сеть.

Отдельно оцените рабочий набор: если горячие данные занимают 10-15% объёма и помещаются в NVMe-слой или кэш, средняя latency массива падает в разы, а требования к остальным дискам снижаются.

Считайте по пиковой нагрузке, а не по средней, и добавляйте запас 30-50%. Массив, загруженный на 80-90% возможностей, резко увеличивает задержку: очередь команд растёт, и даже быстрые диски отвечают медленно. Расчёты проверяют на стенде нагрузочными тестами (fio, vdbench) до подписания заказа.

RAID-контроллеры и интерфейсы подключения: как не создать узкое место

Контроллер и интерфейсы становятся узким местом раньше дисков. NVMe, подключённые через PCIe 3.0 x4, работают вдвое медленнее своих возможностей, а полка из 24 дисков на одном SAS-порту не выдаст суммарный поток.

Аппаратный RAID или HBA для ZFS

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

ZFS и другие файловые системы с собственной логикой резервирования требуют прямого доступа к дискам, поэтому нужен HBA в режиме IT (JBOD). Типичный пример: LSI или Broadcom HBA с 16 внутренними портами SAS 12G под пул из 16 дисков. Аппаратный RAID перед ZFS ставить нельзя: система не увидит реальные диски и не сможет контролировать целостность.

Сравнение аппаратного и программного RAID для SQL Server, VMware и TrueNAS, вместе с командами настройки и порядком действий при отказе диска, приведено в статье «RAID-массивы 2026: полный гид по выбору и настройке». Какой уровень выбрать под конкретную нагрузку, разобрано в руководстве «Выбор и настройка RAID для серверов СУБД и виртуализации».

Пропускная способность дисковой полки и кабели

Пропускная способность полки ограничена интерфейсом и числом линий. Одна линия SAS 12G даёт около 1,2 ГБ/с, широкий порт из четырёх линий около 4,8 ГБ/с. SAS 24G вдвое быстрее на линию.

Пример: 24 HDD по 250 МБ/с в сумме дают 6 ГБ/с. Одного широкого порта SAS 12G не хватит, нужны два порта, SAS 24G или переход на NVMe.

SAS expander позволяет подключить 24 и больше дисков к одному HBA, но делит полосу между ними: пиковые операции нескольких дисков упираются в общий канал.

• Кабели должны соответствовать поколению: SFF-8643 и SFF-8644 для SAS 12G, для SAS 24G нужны кабели, рассчитанные на новую скорость.
• Внешние порты требуют кабелей правильной длины: длинные дешёвые кабели дают ошибки CRC и падение скорости.
• RAID-контроллеры греются и требуют обдува не менее 200 LFM. Без airflow начинается троттлинг и ошибки записи.
• NVMe-oF (через RDMA или Fibre Channel) переносит доступ к хранилищу в сеть и позволяет разнести вычисления и диски, но предъявляет высокие требования к задержке сети.

Готовая СХД или сборка на серверной платформе: что выбрать

Оба пути рабочие. Разница в том, кто отвечает за совместимость, производительность и поддержку: вендор или ваша команда.

Когда готовая СХД оправдана

Готовая система с вендорской поддержкой имеет смысл, когда:

• Есть жёсткие SLA и штрафы за простой, а поддержка нужна 24/7 с гарантированным временем реакции.
• Своей команды с опытом в хранении нет, и нанимать её дороже, чем платить за контракт.
• Отраслевые требования предписывают сертифицированное оборудование и вендорские отчёты.
• Нужны предсказуемая производительность, встроенный мониторинг и автоматическая замена дисков.

Цена вопроса: решения NetApp, Dell EMC, HPE и Pure Storage стоят в 2-5 раз дороже сопоставимой по железу сборки, а снапшоты и репликация часто лицензируются отдельно.

Когда сборка на серверной платформе выгоднее

Сборка на базе серверной платформы плюс TrueNAS, ZFS или Ceph выигрывает, когда бюджет ограничен, требования нестандартные, а в команде есть DevOps-инженеры. Стартап с 100 ТБ данных на сервере стандартного вендора с TrueNAS экономит 30-50% против готовой СХД того же класса и получает снапшоты, репликацию, сжатие и дедупликацию без лицензий.

Пример аппаратной основы: линейка Supermicro H15 на процессорах AMD EPYC 9006, до 256 ядер и 512 потоков, с расширенной памятью и пропускной способностью ввода-вывода. Вендор заявляет 1,7-кратный прирост производительности CPU от поколения к поколению, а сам портфель рассчитан на облачные, корпоративные, storage-, HPC- и AI-нагрузки. Платформы внутри линейки закрывают разные сценарии: Hyper, двухсокетный флагман с усиленным охлаждением, CloudDC на открытой спецификации OCP DC-MHS и высокоплотная 2U четырёхузловая GrandTwin. Системы рассчитаны на GPU следующего поколения, включая AMD Instinct, и соединяются сетями AMD Pensando. Заявленные цифры производительности проверяйте на своём стенде: у вендоров они измерены в идеальных условиях.

Если данные не критичны к задержке и объём растёт непредсказуемо, часть нагрузки разумно держать не на своём железе. Облачные диски и объектное хранилище, например у Timeweb Cloud, снимают вопросы закупки, охлаждения и замены дисков, а оплата идёт за фактическое потребление. Такой вариант удобен для dev- и staging-сред и для проектов с горизонтом планирования меньше года.

Минус сборки очевиден: совместимость, прошивки, замену дисков и мониторинг обеспечивает ваша команда. Без отлаженного процесса деградация массива останется незамеченной до отказа.

Совместимость, жизненный цикл и поддержка платформы

Оборудование живёт 3-5 лет, и всё это время его нужно обслуживать. Проверка совместимости до закупки дешевле, чем поиск подходящего диска после того, как модель сняли с производства.

Как проверять совместимость до закупки

1. Откройте HCL вендора и убедитесь, что выбранные диски, контроллеры и модули памяти есть в списке для конкретной модели сервера.
2. Сверьте версии прошивок BIOS, BMC и контроллеров: часть комбинаций работает только с определёнными ревизиями.
3. Проверьте, поддерживает ли backplane нужное поколение PCIe и работает ли bifurcation для NVMe.
4. Уточните сроки поставки и наличие запасных частей: диски и блоки питания должны быть доступны весь срок эксплуатации.
5. Запросите тестовый образец или стенд и прогоните нагрузочные тесты перед покупкой партии.

Пример: платформа Supermicro H15 рассчитана на AMD EPYC 9006 и GPU AMD Instinct, но конкретная конфигурация NVMe зависит от backplane и версии BIOS. Если проверка не пройдена, закупка преждевременна.

Планирование жизненного цикла и масштабирования

Запас закладывают по четырём параметрам: слоты дисков, порты PCIe, мощность блока питания и свободные юниты в стойке. Сервер с 24 слотами вместо 12 позволяет удвоить ёмкость без замены корпуса и контроллера. Модульный подход DCBBS (Data Center Building Block Solutions) и открытая спецификация OCP DC-MHS упрощают добавление узлов и полок внутри одной линейки.

Отдельно планируют замену дисков: при равномерной нагрузке HDD живут 5-7 лет, SSD в кэше могут потребовать замены раньше. Учитывайте EOL платформы: после снятия с поддержки обновления прошивок прекращаются, а совместимость с новыми версиями ОС не гарантируется. Экономия на запасе по слотам и питанию оборачивается преждевременной заменой всего сервера.

Чек-лист выбора сервера и дисковой полки для системы хранения

1. Профиль нагрузки определён. Известны тип операций, соотношение чтения и записи, допустимая задержка.
2. Ёмкость рассчитана. Учтены накладные расходы RAID, снапшоты и рост на 2-3 года, свободно 20-30%.
3. IOPS и пропускная способность посчитаны с запасом 30-50% от пиковой нагрузки.
4. Форм-фактор выбран. Сервер и полки влезают в стойку по глубине, мощности и охлаждению.
5. Накопители подобраны по задачам и ресурсу. Для кэша и журналов модели с DWPD 3 и выше.
6. Контроллер и интерфейсы проверены. HBA в режиме IT для ZFS, пропускной способности SAS или PCIe хватает с запасом.
7. Совместимость подтверждена по HCL и тестами на стенде, а не только по спецификации.
8. Сравнение готовой СХД и сборки сделано по стоимости владения за 3-5 лет, а не по цене закупки.
9. План масштабирования и поддержки есть. Понятно, кто обслуживает массив и как быстро поставляются диски.

Критерии готовности к закупке

Заказ можно оформлять, когда требования согласованы с бизнесом, расчёты подтверждены тестами на стенде, совместимость проверена по HCL, бюджет утверждён с учётом OPEX, а план поддержки зафиксирован. Если хотя бы один пункт закрыт на словах, например совместимость NVMe с backplane не проверена, закупка преждевременна.

Что делать после закупки

1. Обновите прошивки BIOS, BMC, контроллеров и дисков до согласованных версий и зафиксируйте их.
2. Настройте RAID или HBA: для ZFS массив создаётся средствами файловой системы, контроллер работает в режиме IT.
3. Проведите burn-in: прогоните диски нагрузкой, чтобы выявить ранние отказы.
4. Разметьте пулы по расчёту и оставьте запас на снапшоты.
5. Замерьте реальные IOPS, задержку и пропускную способность (fio или аналоги) и сравните с планом.
6. Настройте мониторинг: SMART, состояние пулов, температуру, очередь команд. Без него деградация диска останется незамеченной.
7. Задокументируйте конфигурацию: модели, прошивки, схему подключения и порядок замены диска.

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