Типы серверных дисков: HDD, SSD, NVMe — что и для чего

HDD vs SSD vs NVMe

Когда выбирают диски для сервера, вопрос обычно звучит просто: HDD или SSD, а может NVMe? И тут начинается бардак в терминах: в магазинах и спецификациях всё смешивают — тип накопителя, протокол, разъём, форм-фактор. Из-за этого люди покупают «NVMe», а потом выясняют, что в их сервере под это нет нужной корзины/PCIe-линий, или берут «M.2», а он оказывается… SATA, то есть по скорости и задержкам ближе к обычному 2.5" SSD.

Как не ошибиться? Есть четыре разных “слоя”, и каждый отвечает за своё:

• Тип накопителя (что внутри хранит данные): HDD — магнитные пластины (дёшево за ТБ, но медленно, особенно на операциях с большим количеством мелких файлов). SSD — флэш-память (быстрее и стабильнее по задержкам, но важно выбрать правильный класс по ресурсу записи).
• Протокол/интерфейс (как диск общается с сервером): SATA и SAS — традиционные интерфейсы. NVMe — современный протокол для SSD, который обычно работает поверх PCIe (даёт низкие задержки и высокий параллелизм).
• Форм-фактор и исполнение (как диск выглядит и куда ставится): 3.5" / 2.5" — привычные “корзинные” диски, часто hot-swap. M.2 — компактная плата (бывает SATA или NVMe, при этом разной размерности - 2240, 2280, 22110). U.2/U.3 — 2.5" формат для NVMe, удобно обслуживать и устанавливать, но нужна специальная "корзина". E1.S/E3.S (EDSFF) — современные дата-центровые форм-факторы под плотность и охлаждение.
• Платформа сервера (что реально поддерживается): backplane (корзина), HBA/RAID-контроллер, линии PCIe, охлаждение — это то, что может «разрешить» или «запретить» ваш выбор.

В статье разберём, как выбрать диски под ваши задачи (БД, виртуалки, файлы, бэкапы, логи, AI) так, чтобы совпали производительность, надёжность, сервисность и бюджет. Также объясним SATA vs SAS, покажем, где важны IOPS и latency, как читать TBW/DWPD, когда нужен PLP, и как не попасть в типовые ловушки совместимости.

Шпаргалка по выбору

Если у вас…

• Бэкапы / архив / холодные данные → чаще HDD (CMR), иногда + небольшой SSD под метаданные/кэш.
• Файловый сервер / контент → HDD или SSD: зависит от профиля доступа (много мелких файлов и random → тянет к SSD).
• Виртуализация / VDI → SSD (часто смешанный tier: NVMe SSD под «горячее», SAS\SATA SSD/HDD под «холоднее»).
• OLTP-БД / кэш / индексы → чаще NVMe (или очень хорошие SAS SSD).
• Логи / телеметрия / очереди → SSD с правильным ресурсом записи (DWPD/TBW, желательно PLP).
• AI/датасеты “читать много” → зависит от паттерна: часто NVMe, но иногда достаточно даже SATA SSD (если узкое место — сеть/CPU).

Главное правило: не покупайте NVMe «просто потому что быстрее». Если нагрузка упирается в сеть, CPU, блокировки в БД или настройки виртуализации — NVMe может дать меньше эффекта, чем ожидаете.

Как не ошибиться при быстром выборе

Если вы подбираете сервер «под задачу», не начинайте с “хочу NVMe”. Начните с трёх вещей: профиль I/O, ценность данных и требования к сервисности (hot-swap, фронт-доступ, быстрый ремонт). На практике это экономит бюджет: иногда правильнее взять меньше NVMe, но лучше по классу (PLP/DWPD, что это такое - расскажем дальше), и дополнить объёмными HDD под холодное хранение.

HDD в сервере: когда это лучшее решение

Что “внутри” HDD

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

CMR vs SMR:

• CMR (Conventional) — «обычная» запись дорожек: предсказуемее при перезаписи и в RAID.
• SMR (Shingled) — дорожки «внахлёст»: часто дешевле по €/ТБ, но может резко просаживаться по предсказуемости в RAID/rebuild и при постоянной перезаписи. Поддержка SMR фигурирует в экосистеме SATA как один из развивавшихся сценариев.

Параметры, которые реально важны

• Latency и random I/O (а не только MB/s): даже быстрый HDD остаётся «медленным» для множества мелких операций.
• URE/BER и риск rebuild: на больших объёмах выше шанс наткнуться на невосстанавливаемую ошибку чтения во время перестроения массива — поэтому «дешёвый HDD + большой RAID5» часто сюрприз.
• 512e/4Kn: вопрос совместимости (контроллер/ОС) и выравнивания.
• Hot-swap и Power Disable (PWDIS): часть дисков поддерживает “power disable” — полезно в ЦОД, но иногда вызывает «диск не стартует» в несовместимых корзинах/кабелях/переходниках.

Где HDD проигрывает неизбежно

• OLTP-БД, очереди, метаданные под высоким параллелизмом;
• высокая доля random I/O;
• «много мелких операций» (VM-диски, VDI, каталоги/индексы).

SATA vs SAS

Серверное хранилище — это не только «какой диск», но и как он подключён: backplane, HBA/RAID-контроллер, кабели, экспандеры, режим passthrough.

SATA — когда стоит выбирать

• массовый и дешёвый путь для HDD и части SSD;
• подходит для: бэкапов, архивов, умеренных файловых нагрузок, boot-дисков (если требования невысокие).Ограничения обычно проявляются в масштабировании и enterprise-топологии (когда важны сервисность на уровне шины и сложные сценарии подключения).

SAS и почему его любят в enterprise

SAS выбирают не только ради «абсолютной скорости», а ради эксплуатационных свойств: dual-port, multipath, экспандеры, удобная работа с полками/бэкплейнами и зрелая инфраструктура хранения. В отрасли обсуждается дальнейшая эволюция (например 24G SAS как технологический контекст).

Практика: что проверить в сервере

• Backplane: SATA-only или SAS/SATA (а иногда и tri-mode).
• Контроллер: RAID или HBA; нужен ли passthrough (для программных решений типа ZFS или Ceph - нужен).
• Кабели/коннекторы/корзины: и совместимость (включая нюансы питания и PWDIS).

Почему backplane и контроллер важнее, чем “какой диск”

Одинаковый SSD может вести себя по-разному в зависимости от того, стоит он за RAID-контроллером, HBA, экспандером, в какой корзине и в каком режиме работает backplane (SATA-only / SAS / tri-mode). Поэтому при подборе конфигурации всегда уточняйте модель сервера/шасси и тип корзины: это сразу отсекает несовместимые варианты (например, NVMe в корзину, где нет PCIe-линий).

SSD в сервере: когда “просто SSD” — ошибка

SSD — это контроллер + NAND + алгоритмы управления износом. Поэтому два SSD одинакового объёма могут вести себя радикально по-разному под одинаковой нагрузкой.

Что “внутри” SSD и почему это влияет на выбор

• NAND (TLC/QLC): QLC обычно дешевле, но чаще хуже по выносливости и поведению под записью; TLC обычно универсальнее.
• Контроллер: влияет на стабильность, latency и “tail latency”.
• DRAM-кэш или HMB: DRAM часто помогает с метаданными и устойчивостью производительности; HMB — компромисс через память хоста.
• SLC-кэш: ускоряет короткие записи, но при длинной записи может “закончиться” и скорость упадёт.
• Wear leveling / garbage collection / write amplification: профиль нагрузки определяет, насколько «дорого» (по износу) вы пишете данные.
• PLP (Power-Loss Protection): критично для БД/журналов/очередей; без PLP растут риски консистентности и восстановления после питания.

Ресурс записи: TBW/DWPD

• TBW — суммарный объём записи в гарантийных терминах.
• DWPD — сколько раз в день можно «полностью перезаписать диск» на гарантийном сроке.Важно: реальный износ зависит от профиля записи (случайная/последовательная, размер блоков, write amplification), поэтому «TBW из брошюры» нельзя переносить на любую нагрузку как калькулятор. Хорошая практика — закладывать запас и мониторить износ.

SSD для разных ролей

• Read-mostly: кэш, поисковые индексы — берём модели с упором на чтение и нормальной latency.
• Write-heavy: логи/метрики/журналы БД — нужен высокий DWPD/TBW, желательно PLP, и мониторинг износа.
• Boot-диски гипервизора: важнее предсказуемость, телеметрия и надёжность, чем пик скорости.

Бюджетные SSD

Бюджетные SSD хороши, когда их роль второстепенная: кэш, временные данные, dev/test, некритичные сервисы — и вы готовы менять накопитель «по износу». Но для БД, очередей и журналов правильнее выбирать SSD по DWPD/TBW и наличию PLP — это уже не “скорость”, а про риски простоя и восстановления.

NVMe: чем отличается от “SSD по SATA/SAS” на практике

NVMe — это протокол + PCIe, и вот что это даёт

NVMe проектировался под твердотельные накопители и высокую параллельность: множество очередей, низкие накладные расходы, эффективная работа в многопоточных сценариях I/O. Это отражено в спецификациях NVMe transport и механике команд.

Практически NVMe чаще даёт:

• больше IOPS при параллельной нагрузке;
• ниже latency;
• лучшее масштабирование при большом количестве потоков.

Форм-факторы NVMe в серверах

• M.2 (2280/22110): компактно, но в серверах часто упирается в охлаждение и сервисность (не всегда hot-swap).
• U.2/U.3 (2.5" hot-swap): распространённый серверный вариант, удобен в обслуживании.
• EDSFF (E1.S/E3.S): дата-центровые форм-факторы для высокой плотности и более правильной термодинамики/сервисности.

Подводные камни NVMe

• PCIe-бюджет: линии и версии PCIe; совместное использование с GPU/NIC.
• Tri-mode backplane/контроллеры: важно понимать, что поддерживает конкретная платформа.
• Термальный троттлинг: без airflow скорость будет нестабильной в проде.

NVMe — это ещё и про линии PCIe

В 1U/2U платформах линии PCIe часто делят сетевые карты, GPU и NVMe-корзины. Поэтому у NVMe-сборок два типичных фейла: (1) «взяли быстрые диски, но они работают не на x4/в другом слоте»; (2) «нагрузка упёрлась в сеть/CPU — прироста почти нет». Перед закупкой полезно зафиксировать: версии PCIe, количество линий, что занимает слоты, и есть ли термозапас по airflow.

Что выбрать под нагрузку

Интерфейсы и форм-факторы в сервере

Как собрать надёжную конфигурацию: 3 типовых рецепта

Рецепт A: Бюджетно для SMB

• HDD RAID под объём (файлы/архив/бэкап)
• SSD/NVMe под «быстрое» (БД/кэш) — если реально есть latency-чувствительная часть
• SMART/алерты, запасной диск (spare), понятный план замены

Рецепт B: Виртуализация 10–50 ВМ

• RAID10 или зеркала на SSD/NVMe под VM-диски
• отдельные boot-диски (или зеркалирование boot)
• контроль износа SSD и разнесение “шумной записи” (логи/темпы)

Рецепт C: БД + логи + бэкап

• NVMe под рабочий набор (данные/индексы)
• отдельный write-heavy SSD под WAL/журналы (желательно PLP)
• HDD под бэкапы/снапшоты/архив

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

• Какой профиль IO: random/sequential, read/write %, блоки 4K/64K?
• Нужен ли hot-swap и front-service?
• Есть ли SAS backplane/HBA или только SATA?
• Контроллер: RAID или HBA? Нужен passthrough?
• Поддержка 4Kn/512e контроллером и ОС?
• Для HDD: CMR или SMR (SMR — осторожно в RAID/перезаписи).
• Для SSD: какой класс по DWPD/TBW и соответствует ли вашей записи?
• Нужен ли PLP (БД/журналы/очереди — обычно да)?
• Есть ли у SSD DRAM или только HMB (и критично ли это для роли)?
• Где будут жить логи/временные файлы/кэши — они «съедают» ресурс?
• Для NVMe: достаточно ли PCIe-линий (слоты/бэкплейн/BIOS-режимы)?
• Термальные ограничения: особенно M.2/NVMe — есть ли airflow?
• План rebuild: сколько времени и какие риски на больших HDD?
• Мониторинг SMART/telemetry, политика замены, spare.
• Совместимость по питанию/сигналам (PWDIS может “выстрелить”).

Частые ошибки и мифы

• «NVMe всегда быстрее в реальном приложении» — не всегда: можно упереться в CPU, сеть, блокировки, настройки очередей.
• «Любой SSD подходит под БД» — нет: важны DWPD/TBW, стабильность latency и PLP.
• «SMR можно в RAID как обычный HDD» — часто нельзя/опасно по предсказуемости и rebuild.
• «Главное — MB/s из даташита» — для серверов чаще важнее latency и “хвосты” задержек.
• «Зачем переплачивать за "серверный" SSD, возьму обычный, там скорости те же, а стоит в 10 раз дешевле» — так можно делать, только отдавая себе отчёт в рисках - у обычных SSD надёжность значительно меньше, как по наработке на отказ, так и при сбоях по питанию (те самые DWPD/TBW и PLP).

Если хочется смотреть не только на обещания вендора, полезно заглядывать в публичные статистики по парку дисков. Например, Backblaze публикует регулярные отчёты по отказам и популяции накопителей. Это не «истина в последней инстанции» (у них свои условия), но хороший ориентир по реальному миру.

NVMe реально нужно?

NVMe обычно оправдан, если у вас одновременно:

• высокая доля random I/O;
• много параллельных потоков/ВМ/подов;
• важна latency (и особенно “tail latency”);
• “горячий набор” данных помещается в быстрый tier.

Если хотя бы половины нет — иногда правильнее SSD с SATA/SAS, а бюджет отдать в надёжность (PLP/DWPD) или резервирование/спары.

Где чаще всего “убивают” SSD

• логи + временные файлы + swap на одном SSD без расчёта DWPD/TBW;
• VDI/виртуалки без разнесения “шумных” VM и мониторинга износа;
• экономия на PLP для БД/очередей, где важнее стабильность, чем пик MB/s.

Как сформулировать запрос на подбор

Под задачу

• Задача: (виртуализация / БД / файловое / логи / AI / бэкап)
• Профиль I/O: random/sequential, доля чтения/записи, блоки (4K/64K), ожидаемый QD
• Объём данных: общий и “горячий набор” (hot set)
• SLA/риски: допустимый простой, критичность консистентности (нужен ли PLP)
• Эксплуатация: hot-swap обязателен? фронт-доступ?
• Ограничения: 1U/2U, сколько корзин, шум/энергия
• План роста на 12–24 месяца

У нас уже есть сервер

• Модель сервера/платформы: (точно)
• Тип корзины/backplane: SATA / SAS / tri-mode / есть ли NVMe-бэйи
• Контроллер: RAID или HBA? нужен ли passthrough?
• Слоты/PCIe: что уже стоит (NIC/GPU), версии PCIe, какие слоты свободны
• Цели по дискам: полезный объём / IOPS / приоритет latency или €/ТБ

Замена дисков в массиве

• Что стоит сейчас: тип дисков + интерфейс + форм-фактор + RAID уровень
• Что не устраивает: latency/IOPS/объём/частые rebuild/отказы
• Ограничения: нельзя менять контроллер/backplane?
• Требования: сохранить hot-swap/совместимость 4Kn/512e/boot

Вывод

• Сначала определите профиль IO и требования к latency/предсказуемости.
• Затем выберите тип носителя (HDD/SSD) и класс SSD по ресурсу записи.
• Потом проверьте интерфейс/топологию (SATA/SAS/NVMe, backplane, HBA/RAID).
• И только после этого — форм-фактор (2.5"/3.5"/M.2/U.2/U.3/E1.S/E3.S) с учётом сервисности и охлаждения.

Источники

• NVMe over PCIe Spec (PDF)
• NVMe spec index
• SATA 3.3: Power Disable (press release)
• Power Disable (WD tech brief)
• SSD Form Factors (SNIA)
• 24G SAS (Kioxia brief)
• Backblaze Drive Stats Q3 2025
• Backblaze Drive Test Data