SATA vs SAS vs NVMe: что выбрать

*СХД — это в данном случае система хранения данных, не путать с сетью хранения данных.

Выбор интерфейса хранения — это не «какой диск быстрее», а какой стек (шина + протокол + топология + контроллеры) даст нужную задержку, отказоустойчивость и масштабирование за адекватные деньги. Условно:

• SATA — про стоимость и ёмкость: «достаточно быстро» для холодных/умеренных нагрузок и недорогих SSD/HDD, но есть потолки по протоколу и очередям.

• SAS — про предсказуемую серверную инфраструктуру: большие полки, hot-swap “как надо”, multipath/dual-port, экосистема HBA/RAID/expander.

• NVMe (PCIe) — про минимальную задержку и максимум параллелизма, но часто упирается в платформу: PCIe-линии, слоты, бифуркацию, топологию и охлаждение.

Важно сразу развести понятия: носитель — это HDD или SSD. А интерфейс/протокол — это SATA/SAS/NVMe (то, как хост с носителем разговаривает и через что подключается).

Быстрый выбор

Если…

• Нужны максимальные IOPS и минимальная задержка (OLTP БД, key-value, очереди, плотная виртуализация, высоконагруженные сервисы) → смотрите NVMe (PCIe). Цель: низкая latency и хорошие «хвосты» p99/p999 (о них ниже).

• Нужна отказоустойчивость уровня “два пути до диска”, multipath, большие дисковые полки/JBOD, типичная энтерпрайз-СХД-экосистема → часто SAS (особенно для внешних полок и HA-паттернов).

• Нужно дёшево и ёмко (архив, бэкапы, медиа, логи, «холодные» данные) → часто SATA (HDD или SSD — по задаче).

• Смешанные сценарии → чаще всего лучший TCO даёт tiering:NVMe (hot) + SAS/SATA (warm/cold).

Важно: NVMe может быть «медленным» не из-за SSD, а потому что вы упёрлись в PCIe-топологию: линии/слоты/бифуркацию/свитчи/ретаймеры/NUMA. Это самая частая причина разочарования в «паспортной скорости».

Что именно мы сравниваем: шина, протокол, топология

SATA: Serial ATA + обычно AHCI

• SATA — это шина подключения, исторически заточенная под HDD.

• В большинстве серверных/ПК-сценариев поверх SATA используется AHCI (протокол/интерфейс команд для контроллера).

• У SATA есть потолок скорости линии: SATA 6 Gb/s — это уровень интерфейса (трансферная скорость спецификации), а не гарантированная «скорость файла». Сам факт 6 Gb/s зафиксирован в SATA Revision 3.0.На практике реальная полезная пропускная способность ниже из-за кодирования/накладных расходов и особенностей контроллера.

SAS: Serial Attached SCSI (модель SCSI)

• SAS — последовательное подключение в мире SCSI-модели (команды, адресация, домены, инфраструктура).

• SAS хорош не тем, что «всегда быстрее», а тем, что лучше масштабируется по топологии:expander (расширитель) позволяет вешать много устройств в одном SAS-домене и строить большие полки/JBOD.

• Почему SAS-контроллер видит SATA-диски, а SATA-контроллер SAS — нет:SAS-HBA/RAID умеет работать в SAS-домене и поддерживает туннелирование SATA-устройств (на бытовом уровне: «SAS знает, как говорить с SATA»), а SATA-контроллер не умеет использовать SCSI-модель и SAS-физику — поэтому «в обратную сторону» совместимости нет. К счастью просто так подключить SAS накопитель к SATA разъёму не получится - за счёт особенностей разъёмов.

NVMe: командный набор для SSD + модель очередей, чаще всего поверх PCIe

• NVMe — это не “тип разъёма”, а протокол/командный набор и модель очередей, рассчитанные на параллелизм SSD. Официальная база — NVMe Base Specification.

• Чаще всего NVMe-накопители подключаются по PCIe (в разных форм-факторах: M.2, U.2/U.3, EDSFF, AIC).

• Есть и NVMe-oF (по сети), но здесь это важно только как направление для HA/масштабирования — без углубления.

Почему очереди важнее “паспортных MB/s”Последовательные MB/s показывают красивую цифру на бенчмарке, но в проде часто решает случайный доступ, конкуренция потоков и то, как устройство держит latency tails (p99/p999). Именно здесь NVMe обычно сильнее.

Производительность: где разница ощущается в реальных задачах

Метрики, которые реально имеют значение

• Latency (задержка): важна не только средняя, но и p99/p999 — «хвосты».Для БД и виртуализации пользователю больно не от средней задержки, а от редких «провалов» — когда часть операций внезапно становится в разы медленнее.

• IOPS и Queue Depth (QD):QD — это глубина очереди (сколько операций одновременно “в полёте”). NVMe спроектирован под высокую параллельность очередей, тогда как SATA/AHCI исторически хуже масштабируется в многопоточном random-IO.

• Sequential throughput (MB/s):критично для backup/restore, медиа, больших последовательных файлов. Здесь SATA может быть «достаточно», если нет требований по задержкам и многопоточному random-IO.

Почему «NVMe быстрее» не означает «NVMe всегда лучше»

• Если нагрузка последовательная и не latency-критичная, разница NVMe vs SATA/SAS может почти не влиять на бизнес-результат.

• Если платформа «узкая» (мало PCIe-линий, общий uplink на бекплейн, неправильная бифуркация), NVMe может работать как «дорогой SATA».

• Если важнее масштабируемость полок + multipath, SAS даст более прямой путь к HA-архитектуре.

3 практических сюжета

• Одна БД на одном сервере (OLTP): критичны p99/p999 и стабильная latency → NVMe обычно даёт наибольший эффект.

• Много VM (10–200 виртуалок): растёт конкуренция IO и QD → NVMe чаще выигрывает, но легко упереться в PCIe-топологию и перегрев.

• Объектное/backup-хранилище: доминируют sequential и ёмкость → SATA HDD/SSD часто рациональнее; NVMe — точечно как write-cache/hot-tier.

Частая ошибка: выбирать по «MB/s в спецификации» и игнорировать latency tails. В проде «хвосты» почти всегда важнее средних значений.

Надёжность и отказоустойчивость: неочевидные преимущества SAS и требования к NVMe

Почему SAS часто выбирают “за инфраструктуру”, а не “за скорость”

• Dual-port: два независимых порта на диске → два пути доступа (через два контроллера/пути), что упрощает multipath (мультипафинг — когда ОС/СХД видит несколько путей к одному LUN/диску и спокойно переживает отказ одной линии/контроллера).

• Expander + большие JBOD-полки: SAS-топология масштабируется по числу устройств и вариантов подключения, что типично для энтерпрайза.

• Предсказуемость экосистемы: HBA/RAID, прошивки, мониторинг, согласованные матрицы совместимости.

По поколению интерфейса: 24G SAS — актуальная ветка SAS-4, её обзор есть у SNIA.

NVMe: что нужно, чтобы «быстро и надёжно» стало реальностью

• PCIe-планирование: сколько линий у CPU, как разведены слоты/бекплейны, есть ли бифуркация (разделение x16 на несколько x4), где стоят ретаймеры/свитчи.

• NUMA/сокеты: в двухсокетных системах важно, к какому CPU «привязан» NVMe, иначе возможны лишние переходы через межпроцессорную связь (что добавляет задержку).

• HA для NVMe: чаще строится не «двумя портами на диске» (как в SAS-полках), а архитектурно — через софт-репликацию/кластер, RAID на уровне ОС, или (в развитии) NVMe-oF.

Важно: NVMe требует дисциплины по платформе и охлаждению. Без этого «самый быстрый SSD» легко превращается в источник нестабильности и троттлинга.

Совместимость и инфраструктура

Контроллеры и адаптеры

• SATA: onboard-SATA или SATA-HBA — обычно просто, но RAID/горячая замена зависят от режима и контроллера.

• SAS: HBA (Host Bus Adapter) или RAID-контроллер; для смешанных сред — tri-mode (SAS/SATA/NVMe на одной платформе), но важно проверять поддержку конкретного бекплейна.

• NVMe: чаще всего «напрямую в PCIe» (M.2/U.2/EDSFF/AIC), иногда через бекплейн/рейзер. Здесь больше всего нюансов по линиям и топологии.

Backplane / корзины / кабели

• Корзина 2.5" не гарантирует поддержку NVMe. Она может быть разведена под SATA/SAS (в редких случаях - только SATA) и физически принимать «тот же размер», но без PCIe-линий до диска.

• U.2/U.3/NVMe-совместимость зависит от того, что именно заведено на бекплейн (SAS/SATA линии или PCIe линии) и как устроен uplink.

Как проверить до покупки:Попросите у вендора/интегратора схему бекплейна или спецификацию: поддерживаемые типы дисков, режимы (SAS/SATA/NVMe), требования к HBA/рейзеру и ограничения по числу NVMe-слотов.

Горячая замена (hot-swap)

• SATA: hot-swap возможен, но зависит от контроллера/режима (и иногда «работает, но с сюрпризами»).

• SAS: чаще всего это «родной» сценарий для серверных полок.

• NVMe: hot-swap возможен, но требует корректной платформы (бекплейн/ретаймер/firmware/поддержка в сервере). По ощущениям это не всегда так «просто и одинаково», как в SAS-полках.

RAID: железо vs софт

• Для SAS/SATA аппаратный RAID часто уместен (особенно если нужны батарейный/конденсаторный кеш, привычная эксплуатация, единый мониторинг).

• Для NVMe нередко выбирают software-RAID/репликацию/кластер — чтобы не сужать возможности NVMe и не упираться в особенности RAID-контроллера.

Узкие места, о которых забывают

• SATA/SAS: ограничение порта/контроллера/expander и oversubscription (много дисков делят общий uplink).

• NVMe: PCIe-слоты/линии/разделение x4/x8/x16, поколение PCIe, топология. Контекст по эволюции PCIe — у PCI-SIG (например, PCIe 6.0 как веха развития).

Частая ошибка: «поставили NVMe — но медленно». Корень проблемы чаще в том, что несколько дисков повешены на общий uplink, неверно настроена бифуркация, или NVMe сидит «не на тех линиях/не на том сокете».

Сводное сравнение

Экономика: как считать «дёшево/дорого» правильно

Чтобы не купить «самое быстрое» и потом переплатить за простои/переделки, удобно мыслить тремя метриками:

• $/GB — стоимость ёмкости.Почти всегда выигрывают SATA HDD (а среди SSD — часто SATA дешевле NVMe при сопоставимой ёмкости).

• $/IOPS — стоимость случайных операций.Здесь NVMe часто становится выгоднее, когда нагрузка реально упирается в IOPS/QD.

• $/predictability (tail latency) — сколько стоит предсказуемость задержки.Если ваш прод страдает от p99/p999 (таймауты БД, лаги VM, “подвисания” сервисов), переплата за более предсказуемое хранилище часто окупается быстрее, чем кажется.

Плюс неизбежные эксплуатационные вещи:

• Энергопотребление и охлаждение: плотные NVMe-конфигурации требуют хорошего airflow, иначе будет троттлинг и «плавающая производительность».

Нагрузка → что выбрать

Практические рекомендации по сценариям с примерами конфигураций

1) Виртуализация (10–200 VM)

Нагрузка: смешанный random-IO, конкуренция потоков, важны p99.Что выбирать: NVMe или гибрид.Почему: NVMe лучше держит параллелизм очередей и снижает latency.

Пример конфигурации:

• 2–4× NVMe SSD под datastore/горячие VM (в зависимости от плотности).

• SAS/SATA SSD/HDD как второй уровень под менее критичные VM/шаблоны/бэкапы.

• Если нужен “железный” RAID — чаще на SAS/SATA; NVMe — через software-RAID/кластер.

Критичные условия: PCIe-линии/слоты/бифуркация; охлаждение NVMe.

2) Базы данных (OLTP)

Нагрузка: низкая задержка, важны «хвосты» p99/p999.Что выбирать: NVMe (часто must-have).Почему: меньше latency, лучше параллелизм.

Пример конфигурации:

• Отдельный NVMe под WAL/журналы (если применимо) + NVMe под данные.

• Репликация/кластер для HA, а не ставка на «один RAID всё спасёт».

Критичные условия: стабильный терморежим (иначе троттлинг = ухудшение p99), NUMA-привязка в двухсокетных системах.

3) Файловое хранилище / NAS-подобное

Нагрузка: часто ёмкость + умеренный IOPS, важна масштабируемость по дискам и обслуживание.Что выбирать: SAS для полок/JBOD, либо SATA для ёмкости (в зависимости от HA и инфраструктуры).Почему: SAS удобен для больших дисковых доменов и HA-паттернов, SATA выигрывает по $/GB.

Пример конфигурации:

• Полка на SAS HBA + expander, диски SAS/SATA (по требуемой надёжности/классу).

• Небольшой NVMe-слой как кеш метаданных/горячих файлов — если есть эффект от ускорения.

Критичные условия: совместимость HBA/expander/кабелей и план роста числа дисков.

4) Бэкап/архив/логирование

Нагрузка: чаще последовательная запись/чтение, ёмкость и цена первичны.Что выбирать: SATA (HDD/SSD), иногда SAS (если это часть энтерпрайз-полки или нужны HA-паттерны).Почему: NVMe редко окупается как «всё хранилище»; лучше — точечно как буфер/кеш.

Пример конфигурации:

• SATA HDD под архив/backup-репозиторий.

• 1–2× NVMe как буфер под входящий поток/индексацию (если софт умеет).

Критичные условия: контроллер/режим hot-swap и политика обслуживания (запасные диски, мониторинг).

Чек-лист выбора перед покупкой

• Профиль нагрузки
• random или sequential, read/write, “смешанность” (70/30, 90/10).
• целевая latency и p99 (где это критично).

• Требования к HA
• нужен ли multipath и ожидание “два пути до диска” (часто ведёт к SAS-архитектуре),
• или HA будет на уровне кластера/репликации (часто ок для NVMe).

• Платформа и совместимость
• есть ли нужный backplane под NVMe (а не только “корзины 2.5”),
• поддержка HBA/RAID/tri-mode,
• для NVMe: PCIe-линии, слоты, бифуркация, ограничения по числу дисков на uplink.

• План роста на 6–18 месяцев
• сколько дисков/полок добавится и куда они физически подключатся,
• не появится ли oversubscription на expander/uplink или дефицит PCIe-линий.

• Термопакет
• airflow, требования к охлаждению, плотность NVMe, риск троттлинга.

• Обслуживание
• hot-swap (какой именно и в каких режимах),
• мониторинг, запасные диски, политика замены и тестирования.

Вывод

• SATA — когда важнее всего стоимость и ёмкость, а нагрузка не упирается в IOPS/latency. Потолки интерфейса (6 Gb/s в SATA Rev. 3.0) и накладные расходы нужно держать в голове.

• SAS — когда нужна масштабируемая дисковая инфраструктура, полки/JBOD, привычный hot-swap и HA-паттерны с multipath/dual-port; 24G SAS — актуальная эволюция SAS-4.

• NVMe (PCIe) — когда критичны минимальная задержка и параллелизм, но успех зависит от PCIe-планирования и терморежима; ориентир по протоколу — NVMe Base Spec (актуальные ревизии 2.2/2.3 и список спецификаций).

• Лучший TCO в смешанных задачах часто даёт tiering: NVMe для hot-слоя и SAS/SATA для ёмкости.

• Если «NVMe медленный» — сначала проверьте линии/слоты/бифуркацию/топологию/NUMA/охлаждение, а не меняйте SSD вслепую.