Разница в производительности SAS против SATA?

Не могу найти, что нигде не кажется.

Какова ожидаемая разница в производительности в сценарии бэкэнда хранилища, который сильно параллелизирован в доступе (например, SAN, хранилище хоста виртуализации и т. Д.) Между SAS и SATA, при прочих равных условиях?

Я думаю, что это сводится к влиянию NCQ (32 ограничения команд) на НАМНОГО более высокий предел выдающихся команд дисков SAS.

Мы рассматриваем замену некоторых дисков и имеем возможность перейти на SAS или SATA - все остальное на месте - и я ищу оценку с точки зрения производительности. Пожалуйста, игнорируйте все другие проблемы (надежность и т. Д.). Мне просто интересно, какое влияние SAS окажет на аналогичные диски (частота вращения и т. Д. Будут одинаковыми). Диски, которые мы имеем в виду, могут быть заказаны с обоими разъемами и - здесь есть идея использовать SATA для возможной переназначения позже. Разница в цене не очень большая, но это заставило меня задуматься о влиянии на производительность ...

Да, обширный набор команд SCSI является большим преимуществом использования его по SATA. из SAS ' Wiki :

SATA использует набор команд, который основан на наборе параллельных команд ATA, а затем расширен за пределы этого набора и включает в себя такие функции, как собственная очередь команд, горячее подключение и TRIM. SAS использует набор команд SCSI, который включает в себя более широкий спектр функций, таких как восстановление после ошибок, резервирование и восстановление блоков. Basic ATA имеет команды только для хранилища с прямым доступом. Однако команды SCSI могут передаваться через ATAPI [2] для таких устройств, как приводы CD / DVD.

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

Кроме того, SAS использует более высокое напряжение сигнализации, что позволяет использовать более длинные кабели по сравнению с SATA. Это важно при попытке подключить дополнительное хранилище к существующей сети SAN.

Вы упомянули NCQ, но вместо этого SCSI использует TCQ, который можно использовать в трех различных режимах, однако больший бонус imo в отношении распараллеленных установок - это возможность отправлять до 2 ^ 64 команд перед заполнением очереди. Протоколы, такие как iSCSI и Fibre Channel, ограничивают это прямо сейчас, но возможность для использования в будущем.

Я могу ответить только на эту часть, потому что я не знаю, даст ли вам возможность использовать SAS для пары новых дисков то же преимущество, что и для установки SAS.

Это поздний ответ, но я хотел бы добавить свое мнение.

С чисто скоростной точки зрения привод ближней линии (как рассматриваемый OP) будет работать практически одинаково как с интерфейсом SATA, так и с интерфейсом SAS. Несмотря на гораздо более низкую глубину NCQ ( 31 запись, а не TCQ 64K), этой ограниченной аппаратной очереди достаточно, когда она дополнена гораздо более глубокой программной очередью ввода-вывода, чтобы извлечь почти те же IOPS, которые можно получить с помощью TCQ на основе SAS ,

В любом случае, это не значит, что SAS не имеет практических преимуществ:

• гораздо лучшая поддержка для экспандеров
• поддержка двухканального интерфейса
• полнодуплексный режим
• намного более высокая максимальная скорость передачи сигналов (12 Гбит / с против 6 Гбит / с)

Однако, учитывая только производительность, печальная реальность заключается в том, что случайные значения IOPS механического диска настолько низки, что интерфейс практически не оказывает влияния, за исключением огромных дисковых массивов, которые иногда могут ограничить вашу скорость последовательной передачи ввода-вывода. Из-за того, что они учитывают задержку вращения (которая скрыта от ОС), убийственной функцией повышения производительности является NCQ / TCQ, и реализация SATA достаточно хороша в этом.

Некоторые более существенные различия появляются при рассмотрении дисков SAS более высокого уровня, которые не только предлагают диски с более высокой частотой вращения (10K и 15K), но и имеют некоторые интересные технологии объединения записей (например, технология кэширования носителей HGST), которые, к слову, медленно разлив в диски Enterprise-SATA также.

1 https://ata.wiki.kernel.org/index.php/Libata_FAQ :

Однако у стандарта ATA есть конструктивный недостаток. Предполагается, что тег NCQ представляет собой 32-разрядное растровое изображение (32-разрядное слово). Если утверждены все 32 тега, это приводит к значению (0xffffffff), которое является тем же значением, которое возвращается при считывании аппаратного регистра после горячего отключения оборудования, или имеет серьезный сбой. Таким образом, чтобы отличить это условие, libata искусственно ограничивает все конфигурации NCQ 31 тегами, а не 32.

Старый пост, но я хотел обновить его, так как никогда не упоминал о наиболее важных различиях с точки зрения производительности, которые заключаются в том, что SATA является только полудуплексом. Ожидайте огромную разницу в производительности при больших нагрузках с сочетанием чтения / записи. Определенно не подходит для SAN или виртуализации IMO.

Конечно, как указано выше, у SAS есть и другие преимущества. В наше время диски NL-SAS можно приобрести не намного дороже, чем SATA.