SATA M.2 накопители против PCI-E NVME — стоит ли переплачивать при покупке в домашний ПК
Содержание
Содержание
Без SSD-накопителей сложно представить современный компьютер. Они быстры и бесшумны, да и цена на них «не кусается» как несколько лет назад. На выбор представлена масса моделей, различающихся объемом, ресурсом и скоростью. Если с объемом и ресурсом ситуация однозначная — чем больше, тем лучше, то со скоростью устройства все далеко не так просто.
Принцип работы интерфейса
Накопители SATA M.2 и PCI-E NVME хоть и похожи внешне, но имеют важное различие в типе используемой шины. SATA M.2 использует для подключения шину SATA, которую также задействуют HDD-накопители.
PCI-E-накопители более разнообразны. Они могут различаться по количеству линий передачи данных и версии интерфейса. Под нужды накопителя используются напрямую линии PCI-E, что позволяет обойти ограничение пропускной способности шины SATA, которое составляет 600 МБ/с. Основная масса современных PCI-E-накопителей имеет ключ M разъема подключения, SATA в свою очередь универсальный B+M. Версий с единственным B ключом уже не встретить, беспокоиться о несовместимости не придется.
NVME (энергонезависимая память) в аббревиатуре устройства, обозначает наличие спецификации на протоколы доступа к SSD-накопителям, которые подключаются по шине PCI Express. Такие устройства оптимизированы для работы с современными многоядерными процессорами и обеспечивают более низкие задержки обработки запросов. Можно найти единичные экземпляры без этого стандарта, но они очень редко встречаются в продаже.
Характеристики записи/чтения в повседневных задачах
Максимальная пропускная способность шины SATA III составляет 600 МБ/с, что обеспечивает накопителям SATA M.2 показатели в среднем
560 МБ/с для чтения и
530 МБ/с для записи.
У NVME накопителей в свою очередь эти показатели могут достигать
3300 МБ/с при версии PCI-E 3.0×4.
В случае последней версии PCI-E 4.0х4 параметры чтения/записи могут достигать вовсе 5000 МБ/с и 4400 МБ/с. Ниже представлены результаты тестирования обоих типов накопителей.
Разница видна невооруженным глазом. Казалось бы, в соответствии с результатами тестов, приложения должны загружаться намного быстрее, но это не так. Основная масса выполняемых операций проходит с небольшими файлами, в том числе и загрузка ОС. И тут на первое место выходит не последовательная скорость чтения файлов, а скорость работы со случайными блоками, так как на них приходится большая часть дисковой активности накопителя. А с ней уже не наблюдается тотальное преимущество NVME перед SATA.
Вследствие этого скорость загрузки ОС и стандартных программ с NVME лишь немного выше, чем у SATA. В играх аналогичная ситуация — бывают отдельные проекты, где разница составляет более
5 секунд. Но общая масса проектов загружается с минимальной разницей в скорости. Так, где же можно увидеть эти заоблачные скорости от NVME-накопителя? Ответ — лишь в определенных сценариях. Например, при копировании крупного файла или при работе с видеоредакторами и прочими специализированными программами, использующими крупные массивы данных.
Нагрев и энергопотребление
Критический нагрев несвойственен накопителям типа SATA M.2. Для того чтобы перегреть такой SSD должны сложиться множество факторов: полное отсутствие обдува, продолжительные нагрузки, неудачное расположение и высокие температуры в помещении. Поэтому они не требуют дополнительных радиаторов для охлаждения.
В случае с NVME ситуация не такая позитивная. Компоненты обладают заметным тепловыделением. Особенно ярко это заметно при большой нагрузке на накопитель. Сочетание неудачного расположения разъема на плате в упор к горячей видеокарте, также может добавить поводов для беспокойства. Косвенно на этот нюанс намекают и сами производители. В продаже не встретить SATA-накопители с комплектным радиатором, в то время как NVME часто идут с этим девайсом.
Если же радиатора в комплекте нет, а температура высоковата, определенным выходом станет покупка отдельного радиатора на SSD-накопитель. Также в продаже можно встретить материнские платы с наличием радиатора в комплекте. Энергопотребление наряду с миниатюрным размером является одним из факторов, влияющих на нагрев накопителя. Потребление NVME-устройства может превышать SATA в несколько раз.
Одним из главных аргументов, при подборе комплектующих для домашнего компьютера, выступает цена. Тут нам не требуется каких-то заоблачных мощностей, а приоритет покупки сводится к соотношению цена/надежность. И в этом плане SATA-накопители являются идеальным вариантом. Они уже не так дороги, как несколько лет назад.
Да, говорить о полной замене HDD в качестве хранилища всего, пока рано. Но тенденция к этому есть, медленно и верно идет движение в эту сторону. За счет снижения стоимости памяти, используемой в производстве, мы можем приобрести по доступной цене емкий накопитель, что представить в недалеком прошлом было сложно. NVME-накопители превосходят SATA по производительности в несколько раз, и за эти скорости приходится платить, используем мы их или нет. Причем порой за цену NVME можно купить SATA-устройство с емкостью в два раза больше. Но и тут можно найти свои исключения из правил. Иногда попадаются устройства NVME дешевле SATA, при аналогичной емкости.
Это обусловлено используемым типом памяти и износоустойчивостью конкретных моделей.
Поддержка материнскими платами в 2020 году
В современных реалиях, даже у самых бюджетных плат имеется минимум один комбинированный разъем под оба интерфейса. Беспокоиться о том, что SATA-интерфейс не будет поддерживаться, нет оснований. Да, на рынке уже появляются устройства следующего поколения NVME, с поддержкой PCI-E 4.0. Но, как правило, в типичной компоновке PCI-E 4.0 занимает верхний слот, а нижний отдается под нужды SATA/PCI-E 3.0.
Рассмотрим несколько вариантов реализации слотов на примере новейших чипсетов AMD и Intel — B550 и Z490, соответственно. Asrock B550 Taichi имеет 2 разъема M.2, где верхний поддерживает PCI-E 4.0×4 или PCI-E 3.0×4, а нижний SATA или PCI-E 3.0×4.
В случае с Asus Tuf Z490-Plus Gaming мы видим и вовсе два слота поддерживающих SATA или PCI-E 3.0×4. В зависимости от модели могут возникать некоторые «подводные камни» при установке SSD, в виде отключения портов и т.п. Подробнее эти особенности будут рассмотрены в ближайших темах.
Говоря о дальнейшей перспективе, интерфейс PCI-E выглядит более выигрышным, нежели SATA. Пока будущая модернизация интерфейса SATA туманна, в то время как PCI-E все больше наращивает мощности в плане скорости. Но представить отказ производителей в поддержке SATA M.2, в ближайшие годы невозможно.
| Характеристика | SATA M.2 | PCI-E NVME |
| Скорость загрузки ОС, игр и программ (без специализированных задач) | Немного ниже (разница в пределах погрешности) | Чуть выше (разница в пределах погрешности) |
| Нагрев и энергопотребление | Ниже | Выше |
| Стоимость устройства с равноценным объемом (в общей массе) | Ниже | Выше |
| Поддержка материнскими платами в 2020 году | Хорошая | Отличная (более перспективный интерфейс в будущем) |
Подведем итоги. Несомненно, будущее за NVME накопителями — современный интерфейс и выдающиеся скорости, но эти плюсы нивелируются в текущих реалиях. Операционная система, стандартные программы и игры, банально пока не могут использовать весь потенциал такого типа накопителей.
Огромное преимущество PCI-E-устройства в синтетических тестах скорости над SATA, на практике, превращается в перевес в пару секунд, что можно списать на погрешность. И резонно возникает вопрос, стоит ли платить больше? Очевидно, что нет. Мы можем купить более дешевый и емкий накопитель SATA, который удовлетворит все наши потребности. Рассматривать же покупку NVME-накопителя в домашний ПК стоит в нескольких случаях: у вас уже занят слот с разъемом SATA, разница в цене аналогичных объемов минимальна, вы планируете в будущем использовать ПК для работы. Во всех остальных ситуациях присмотритесь к накопителям с SATA-интерфейсом нужного вам объема.
Выбор режима работы SATA (IDE, AHCI, RAID), NVMe
Содержание
Содержание
Идеальная сборка — это когда каждый компонент системы работает со 100% отдачей. Казалось бы, такая тривиальная задача, как подключение жесткого диска к материнской плате не должна вызвать особых затруднений. Подключаем HDD к соответствующему разъему, и, вуаля — в системе есть место для развертывания операционки и хранения файлов. Но не все так просто!
Чтобы познать дзен сборки и получить оптимальную по определенным параметрам (быстродействие, надежность и т. д.) систему, нужно обладать определенным пониманием логики работы современных протоколов и алгоритмов передачи данных, знанием режимов работы контроллера HDD на материнке и умениями в области их практического использования.
BIOS и UEFI — разница есть!
Прежде чем рассматривать режимы работы SATA, следует познакомиться и рассмотреть различия между BIOS (базовая система ввода/вывода) и UEFI (унифицированный интерфейс расширяемой прошивки), ведь именно с их помощью придется вносить изменения в конфигурацию системы.
BIOS-ом называют управляющую программу, «зашитую» в чип материнской платы. Именно она отвечает за слаженную работу всех подключенных к материнке устройств.
Начиная с 2012–2013 годов, большинство материнских плат снабжается UEFI — усовершенствованной управляющей программой, наделенной графическим интерфейсом и поддерживающей работу с мышью. Но, что называется «по старинке», оба варианта, на бытовом уровне, называют BIOS.
Даже неискушенному пользователю понятно, что причиной столь радикальной смены курса при создании UEFI стало не желание производителей «приблизить» интерфейс к конечному пользователю ПК, сделать его более удобным и понятным, а более веские причины.
Таким весомым аргументом стало ограничение на возможность работы с накопителями большого объема в изначальной версии BIOS. Дело в том, что объем диска ограничен значением, приблизительно равным 2,1 ТБ. Взять эту планку без кардинальных изменений управляющего софта было невозможно. К тому же БИОС работает в 16-битном режиме, используя при этом всего 1 МБ памяти, что в комплексе приводит к существенному замедлению процесса опроса (POST-опрос) устройств и началу загрузки из MBR области с установленной «осью».
UEFI лишена вышеперечисленных недостатков. Во-первых, расчетный теоретический порог объема дисковой подсистемы составляет 9,4 ЗБ (1 зеттабайт = 10 21 байт), а во-вторых, для загрузки операционки используется стандарт размещения таблиц разделов (GPT), что существенно ускоряет загрузку операционной системы.
Разметка жестких дисков
Как говорилось ранее, у стандартов BIOS и UEFI — различный подход к разметке области жесткого диска. В BIOS используется так называемая главная загрузочная запись (MBR), которая четко указывает считывающей головке HDD сектор, с которого нужно начать загрузку ОС.
В UEFI это реализовано иначе. В этом стандарте используется информация о физическом расположении таблиц разделов на поверхности HDD.
Как это работает?
Каждому разделу жесткого диска присваивается свой собственный уникальный идентификатор (GUID), который содержит всю необходимую информацию о разделе, что существенно ускоряет работу с накопителем. К тому же при использовании GPT риск потерять данные о разделе минимальны, поскольку вся информация записывается как в начальной области диска, так и дублируется в конце, что повышает надежность системы в целом.
Для понимания — при использовании MBR, информация о загрузочной области находится только в начале диска, в строго определенном секторе и никак не дублируется, поэтому, при ее повреждении, загрузить операционную систему с такого диска будет невозможно. Систему придется устанавливать заново.
Еще одно существенное отличие — при использовании «старого» BIOS и MBR на диске можно максимально создать четыре логических раздела. В случае необходимости создания их большего количества придется доставать свой шаманский бубен и прибегнуть к определенным действиям на грани магии и «химии». По сути, предстоит проделать трюк с одним из основных разделов. Сначала преобразовать его в расширенный, а затем создать внутри него нужное количество дополнительных разделов. В случае использования стандарта GPT все это становится неактуальным, поскольку изначально в ОС Windows, при использовании новой философии разметки HDD, пользователю доступно создание 128 логических разделов.
Что касается физической разбивки диска на логические разделы, то здесь нужно четко понимать задачи, под которые они создаются. Нужно приучить себя четко разделять данные пользователя и системные файлы. Исходя из этого, логических дисков в системе должно быть как минимум два. Один под операционку, второй под пользовательские данные.
Оптимальный вариант — иметь в ПК два физических диска. SSD объемом 120–240 ГБ под систему и быстрые игрушки и HDD под документы и файлы мультимедиа необходимого объема.
В некоторых случаях можно еще разделить том пользовательских данных на два раздела. В одном хранить важные файлы (те, что нужно сохранить любой ценой) и текущие, утрата которых не критична и их легко будет восстановить с просторов интернета (музыка, фильмы и т. д.). И, конечно же, приучить себя регулярно сохранять резервную копию раздела с важными данными (облачные хранилища, внешний HDD и т. д.), чтобы не допустить их потери.
Режимы работы SATA
Покончив с необходимым теоретическим минимумом, следует определиться с выбором режима работы контроллера HDD материнской платы и сферами их применения.
Сложно представить необходимость такого режима работы в составе современного ПК. Разве что в одной точке пространства и времени сойдутся найденный на антресоли старенький HDD с рабочей ОС и «самоткаными» эксклюзивными обоями рабочего стола, и безудержное желание сохранить их для потомков.
К выбору режима работы накопителя следует отнестись ответственно. Выбрать его нужно перед началом установки операционной системы! В противном случае, при его смене на уже установленной операционке, очень велика вероятность получения экрана смерти (BSOD) и отказа ПК работать.
Исправить ситуацию конечно можно, выполнив с десяток пунктов из многочисленных инструкций, коими пестрит интернет, но рациональней будет установка ОС заново, что называется с чистого листа, чем забивание «костылей» в надежде все починить.
Собирая систему важно не только правильно подобрать компоненты и подключить провода и шлейфы, также важно грамотно настроить ее конфигурацию, ведь быстродействие накопителей зависит не только от «железной» начинки, но и от способа управления ей.
NVMe-накопители: чем они хороши и как на них переходить. Часть первая
Представьте: в очередной раз ваш любимый вендор дисков рассказал, почему NVMe-накопители лучше, чем SAS и SATA. В вашем любимом издании написали, что вышла новая версия спецификации и появилось 5 новых стартапов, которые делают разные прикольные вещи. А вы, наконец, получили долгожданный бюджет на обновление и задумались: а что всё-таки стоит приобрести и какие подводные камни меня ждут?
Получается, всего 1 NVMe может заменить 4 SATA SSD (уровни задержек мы пока оставим в стороне).
Points scored
Звучит очень неплохо. Но значит ли это, что теперь вы сможете за тот же бюджет получить от storage-hungry приложения в 4 раза большую отдачу?
Скорее всего, нет. Для того, чтобы внедрить новые технологии с максимальной отдачей, нужно немного постараться:
правильно подобрать платформу,
решить задачи организации RAID и томов,
правильно настроить ОС и приложение.
Мы поставили уже несколько сотен лицензий на высокопроизводительный СХД и провели более 500 тестов — и далеко не всегда удавалось добиться положительного результата с первого раза.
Еще одним из плюсов NVMe стала возможность работы с накопителями, вынесенными за пределы сервера по высокопроизводительной фабрике, не замечая разницы между локальными и «удаленными» SSD. И, в отличие от SAS, такое решение прекрасно масштабируется до тысяч накопителей и сотен хостов.
Сегодня существуют продукты, которые могут экспортировать NVMe-накопители в сеть у различных вендоров:
Western Digital OpenFlex Data24
HPE J2000
GIGABYTE SF260-NF0/1
Подобные продукты становятся основой компонуемых систем хранения данных, которые значительно меняют подход к построению инфраструктуры ЦОД.
Итак, как правильно и безболезненно (почти) подойти к переходу на технологии NVMe?
Чаще всего дают совет начинать с задачи определения того, чего мы хотим добиться.
В теории, NVMe-накопители могут помочь нам сделать следующее:
увеличить производительность транзакционной системы и снизить время отклика,
снизить время обработки больших объемов данных,
увеличить плотность размещения виртуальных машин и десктопов,
увеличить плотность хранения больших объемов данных (да-да, мы можем хранить большие объемы на flash).
К решению обозначенных задач мы рекомендуем идти по пунктам.
Пункт 1. Изучение особенностей вашего приложения
Если вам требуется увеличить количество транзакций или пропускную способность, а ваше приложение имеет однопоточные компоненты, то, скорее всего, ничего не выйдет — NVMe показывает свое превосходство в указанных параметрах именно там, где к дискам создаются множество глубоких очередей. А вот уровни задержек снизятся практически при любом типе нагрузок.
Также стоит обратить внимание на то, какой стек системного ПО поддерживает ваше приложение: чем свежее ядра Linux, тем больше будет выхлоп. Идеально — чтобы ваше приложение поддерживало новые фреймворки, такие как io_uring или SPDK.
Надеюсь, что вы произвели предварительную работу и уже точно знаете, что проблема с производительностью где-то на стороне СХД. А если нет, то начните с изучения таких инструментов как systat, ebpf (использование для трассировки) и работы со счетчиками в Windows. Погуглите результаты тестов вашего приложения на быстрых хранилищах — если повезет, то вы сможете скорректировать свои ожидания.
Пункт 2. Настройка системного программного обеспечения
Общее правило здесь такое: чем свежее ядро, тем лучше.
Самые влиятельные компоненты, которые колоссально влияют на производительность — это файловая система, менеджер томов и RAID. К сожалению, популярные файловые ZFS и BTRFS могут забрать у вас достаточно большой процент производительности, особенно при «транзакционной» нагрузке. В итоге вы получите более высокую стоимость IOps. Для NVMe мы рекомендуем использовать XFS или F2FS.
Системные настройки
Для того чтобы увеличить общую производительность системы, минимально проиграв в энергосбережении, сделать нужно следующее:
В конфигурации BIOS сделать следующие настройки:
Для оптимизации работы системы нужно:
Поставить утилиту tuned и выполнить команду tuned-adm profile throughput-performance.
Нужно списать параметры в /etc/defaults/grub и выполнить команду grub-update.
Для того чтобы вы могли оценить влияние изменений мы проводили тесты на следующей системе:
Product Name: S2122-N24-4
2 CPU Intel® Xeon® Gold 6140 CPU: @2.30GHz
8 накопителей Western Ultrastar SN640 объемом 3.2TB
Операционная система: Ubuntu 20.04
Мы проводили тесты с использованием утилиты FIO 3.16 со следующими конфигурациями:
Глубина очереди не указана, так как мы изменяем ее в скрипте.
При тестах накопителей без RAID с глубиной очереди 16 мы получаем следующие показатели.
Производителность до настройки системы составляла 3778121,2 IOps. После выполнения тюнинга производительность увеличилась до 4137231,56 IOps Неплохой выхлоп! Уровни средних задержек также снизились пропорционально.
На нашем же RAID ситуация схожая:
Производительность до настройки, IOps
Производительность после настройки, IOps
Средняя задержка до настройки, нс
Средняя задержка после настройки, нс
Менеджер томов
Начиная с версии device mapper 4.2 в Linux появилась поддержка работы с множеством очередей. Эта опция позволяет очень серьезно увеличить производительность. По нашему опыту ограничение одного тома составляет около 2 000 000 IOps без использования этой опции и 50 000 000 IOps с использованием.
Проверить это можно следующим образом:
Multipath
При использовании двухпортовых накопителей или накопителей, подключенных через несколько путей фабрики, потребуется использовать ПО для мультипасинга.
В OS Linux за это отвечает DM-multipath. Также можно использовать нативный NVMe-multipath.
На dm-multipath достижение высокой производительности возможно при включении режима bio.
Сейчас в ядрах Linux поддерживается два режима обработки IO: Bio Request и Multi-Queue. Режим bio проще и рекомендуется при работе с NVMe. Хотя, конечно, сравнение работы различных multipath — вопрос отдельной статьи. Правильный параметр конфигурационного файла выглядит следующим образом:
features «2 queue_mode bio»
Драйверы NVMe
Современные ядра Linux поддерживают драйверы, работающие как в режиме прерываний, так и в режиме polling. Задается этот параметр при загрузке модуля.
При этом polling поддерживается в трех режимах: классический, адаптивный гибридный поллинг, с фиксированным параметром задержки.
Можно сделать так, чтобы этот параметр применялся по умолчанию:
В файл /etc/modprobe.d/nvme.conf пропишите строку
options nvme poll_queues=4
Мы рекомендуем использовать гибридный поллинг.
Для каждого namespace нужно прописать 0 в файл /sys/block/nvmeXnY/queue/io_poll_delay.
Что же можно ожидать?
На удивление, на нашем полигоне мы не обнаружили значимого результата. Год назад, на другой системе, где процессор был послабее, дисков больше, а в качестве операционки использовался CentOS, включение поллинга дало нам несколько дополнительных сотен тысяч IOPS, а на низкоинтенисвных нагрузках задержка снизилась на 25%. Так это эту рекомендацию оставляем на ваше усмотрение.
Сеть
Тонкая настройка сети — дело непростое, и опять же требует отдельной статьи поэтому мы оставим только пару простых рекомендаций: использовать Jumbo Frames и в случае использования сети от Mellanox не стесняться использовать утилиту mlnx_tune.
RAID
Организация дисков в массив на сегодня является самой сложной storage-проблемой.
RAID 10 «съедает» половину объема и половину производительности на запись при любом объеме, а более экономные RAID5 и RAID6 имеют ограничения как по производительности, так и по уровням задержек, а иногда — по количеству и типу подключаемых дисков.
На сегодняшний момент мы можем использовать следующие решения:
аппаратные трехрежимные решения от Broadcom, Microchip и Areca,
программный RAID в ОС Linux,
решение Intel® VROC.
Как вы можете увидеть в таблице, полученной от независимых исследователей, все эти решения имеют ограничения по максимальному уровню производительности. Именно поэтому мы решили разработать свой собственный программный RAID.
Опять таки, же на нашей системе мы тестировали MD RAID и Intel® VROC (они демонстрируют идентичные результаты в связи с тем, что в основе VROC лежит код mdraid) и получили следующие результаты:
echo 72 > /sys/block/md0/md/group_thread_cnt
Файловые системы с интегрированными функциями тома и RAID
Файловые системы типа ZFS и BTRFS имеют полный интегрированный стек, обеспечивающий все необходимые функции от дисков до интерфейса ФС. Но их архитектура на основе подхода CoW крайне негативно сказывается на производительности случайных операций и уровнях задержки — и мы не рекомендуем использовать их для работы с NVMe-накопителями.
SPDK
SPDK предлагает альтернативный путь работы с высокопроизводительными устройствами, но есть две проблемы.
Нет готового варианта RAID.
Тома не очень стабильны.
Так что этот подход мы рекомендуем только опытным компаниям.
Общие настройки блочной подсистемы
Убедитесь, что у ваших устройств выставлены следующие параметры:
Ещё можно выключить поддержку iostat для каждого накопителя.
Пункт 3. Правильно подобрать «железо»
Теперь перейдем к аппаратной конфигурации.
Наиболее часто узким местом при работе с высокопроизводительными накопителями являются CPU и шина PCIe. Начнем с CPU.
Здесь действует простое правило: нужно иметь одно дополнительное ядро дополнительно к нуждам приложения на один NVMe-накопитель.
Такой подход позволит как реализовать возможности накопителя, так и иметь достаточные ресурсы для работы вашего приложения.
А сколько нужно вашему приложению — помогут понять специальные сайзеры.
PCIe
Часто системы, ориентированные на обеспечение высокой плотности хранения, например, на основе накопителей форм-фактора Ruler, имеют переподписку по полосам PCle и шина ограничивает общую пропускную способность и, как следствие, количество операций ввода-вывода.
Мы столкнулись с такой особенностью при тестировании платформы Supermicro E1.S SuperMinute. Это система на 32 накопителя в формате EDSFF. Сервер Supermicro E1.S SuperMinute позволяет подключить 32 NVMe-накопителя. Накопители сгруппированы в слоты PCIe х16 по 4 шт. и подключаются в PCIe switch. PCIe switch подключается к процессорам по четырем шинам PCIe x8 на одну NUMA ноду (рис. 4). Из-за этого не получается достичь теоретической производительности при подключении всех 32 накопителей.
рис. 4
Лучшим соотношением объем/производительность для данной платформы будет использование 16 накопителей подключенных по схеме на рис. 5:
рис. 5
Если вам нужна производительность, то, конечно, стоит обратить внимание на то, как организован ваш сервер и EBOF.
Для начала посмотрим на сервер. В первую очередь обратим внимание на накопители и то, какими и какой производительности портами они обладают?
Максимальная производительность будет достигнута при обеспечении непосредственного подключения устройств к CPU — либо количество линий до «свитча» и от «свитча» будет соответствовать суммарному количеству на дисках.
При использовании EBOF нам нужно рассмотреть как архитектуру EBOF, так и сетевую инфраструктуру от контроллеров в EBOF до подключения адаптеров в серверах. Тут также нигде не должно возникать переподписок.
Особое внимание нужно уделить расположению накопителей на Numa nodes. Если ваше приложение способно это учитывать, то для достижения лучшего результата стоит правильно размещать массивы и тома на накопителях, которые «живут» на одной ноде.
Тестирование
Итак, вы закупили накопители и подобрали под них правильное железо, установили операционную систему и правильно ее настроили. Настало время провести тесты!
Делать это нужно, идя от меньшего к большему. Есть три ключевых принципа в проведении тестов:
Перед тем как начинать тесты, вы должны обозначить ожидания, и в случае несовпадения ожиданий и результатов предпринять меры по выяснению причин.
Тесты должны быть стабильно повторяемыми — результаты не должны отличаться при повторных запусках.
Тесты должны отражать реальную производительность системы.
Важным моментом является то, что накопители на основе NAND Flash должны быть должным образом подготовлены для удовлетворения критериям 2 и 3.
Мы рекомендуем ознакомиться со спецификацией SNIA SSS PTSE.
Все enterprise-накопители в спецификациях показывают данные, полученные в соответствии именно с этой методикой.
Итак, первый этап — ознакомиться со спецификацией и подсчитать ожидаемую производительность от вашего набора дисков. Затем — подготовить диски к тестам. После — запустить нагрузку и посмотреть результаты. Если есть проблемы, то разобраться в них и устранить.
Мы рекомендуем использовать утилиты Flexible IO tester или VDbench.
Есть типовые ошибки, которые допускают при тестировании дисков:
Отсутствие сдвига между потоками: все потоки читают один и тот же набор данных.
Неверно заданные сдвиги.
Неверно подобранные показатели количества потоков и глубины очереди. Для достижения максимальных показателей по количествам операций нужно указывать количество потоков равное количеству вычислительных ядер и глубину очереди 32-64 запроса.
Если ваша задача чувствительна к задержкам, то глубину очереди стоит уменьшить.
Использование буферизованных IO и некорректных io_engine.
Несоответствие размера блока задаче.
Если ваши диски не установлены локально в сервере, то стоит начать с тестов производительности сети между узлом и EBOF.
Отдельное внимание стоит уделить параметру, которые проявляют себя именно на системах, которые обеспечивают высокую производительность.
После того, как вы получите результаты на всех дисках и устраните узкие места, можно протестировать RAID и менеджер томов. Тут вам стоит полагаться на те же советы, что и при тестах диска, но при расчете ожидаемой производительности не забывать про RAID Penalty. Очень часто RAID тормозит, если в системе есть какие-то медленные диски, которые мы не исключили на предыдущем этапе. Используйте утилиту iostat.
Следующими по порядку идут уже тесты файловой системы и непосредственно тесты, имитирующие нагрузку приложений. В каждом случае есть свои рекомендации и особенности.
Также при тестировании решений следует увеличивать нагрузку для того чтобы понять, как система ведет себя при масштабировании. Особенно важно это проверять для дизагрегированных сред. Также можно увеличивать как глубину очереди, так и количество потоков, и контролировать не только среднии уровни задержек, но и задержки по персентилям.
И снова про RAID
В существующих RAID-решениях мы увидели явный недостаток, который мешает получить максимум от возможностей современных устройств. Именно поэтому мы решили разработать собственный RAID, исходя из следующего:
Мы хотим достичь максимальной возможной производительности от суммарной производительности устройств (при отсутствии других узких мест, конечно).
За основу мы берем RAID с parity, так как зеркалирование слишком дорого.
При этом мы хотим, чтобы RAID с parity как минимум не уступали по производительности R10.
Решение должно быть адаптировано к разным типам нагрузки — случайной или последовательной, для крупных и маленьких блоков, высокоинтенсивной и чувствительной к задержкам низкоинтенсивной нагрузке.
Простота настройки и управления.
И, самое главное, решение должно быть адаптировано к использованию с современным оборудованием на основе NVMf.
Мы наблюдаем серьезный рост спроса на решения для дизагрегированной инфраструктуры. И, конечно, при дизайне решения рассчитывали, что его будут использовать в рамках DIS.
Так как NVMe-накопители любят многопоточную запись, нам нужно было решить пару вопросов:
Быстро и эффективно рассчитывать контрольные суммы и восстанавливать данные — за это отвечает уже давно изобретенная нами схема расчета контрольных сумм на векторных регистрах (подробнее об этом можно прочитать в статье):
2. Обрабатывать запросы на запись и чтение с максимальной параллелизацией.
Проблема RAID-массивов с parity в том, что примерно в один момент времени в один страйп может прийти несколько запросов на изменение данных. А может еще происходить ребилд или инициализация массива! С одной стороны, нам нужно обрабатывать все запросы максимально эффективно, используя все вычислительные ядра, а с другой — не допускать искажения данных в стрипах с контрольными суммами. Блокировки тут — очень плохой вариант, ведь мы можем иметь сотни тысяч и даже миллионы запросов на запись в секунду. Именно поэтому мы придумали подход на основе lockless c динамическим маппингом потоков и страйпов.
Также мы полностью отказались от кэширования.
А для достижения высокой производительности на задачах потоковой операций записи для того, чтобы избегать постоянных read-modify-write мы разработали механизм объединения запросов для того, чтобы такие записи были полнострайповыми.
Управляется наш массив через cli, но скоро появится gRPC.
Так как движок RAIDIX ERA используется как внутри имеющихся СХД, так и совместно с решениями типа Openflex, мы разработали механизм Active-Active кластера, который со временем расширится до множества узлов.
О других особенностях перехода на NVMe расскажем во второй части статьи.
