RAID-массивы на NVMe +13





В данной статье мы расскажем про разные способы организации RAID-массивов, а также покажем один из первых аппаратных RAID-контроллеров с поддержкой NVMe.

Все разнообразие применений технологии RAID встречается в серверном сегменте. В клиентском сегменте чаще всего используется исключительно программный RAID0 или RAID1 на два диска.

В этой статье будет краткий обзор технологии RAID, небольшая инструкция по созданию RAID-массивов с помощью трех разных инструментов и сравнение производительности виртуальных дисков при использовании каждого из способов.

Что такое RAID?


Википедия дает исчерпывающее определение технологии RAID:
RAID (англ. Redundant Array of Independent Disks — избыточный массив независимых (самостоятельных) дисков) — технология виртуализации данных для объединения нескольких физических дисковых устройств в логический модуль для повышения отказоустойчивости и производительности.
Конфигурация дисковых массивов и используемые при этом технологии зависят от выбранного уровня RAID (RAID level). Уровни RAID стандартизированы в спецификации Common RAID Disk Data Format. Она описывает множество уровней RAID, однако самыми распространенными принято считать RAID0, RAID1, RAID5 и RAID6.

RAID0, или Stripes, — это уровень RAID, который объединяет два или более физических диска в один логический. Объем логического диска при этом равен сумме объемов физических дисков, входящих в массив. На этом уровне RAID отсутствует избыточность, а выход из строя одного диска может привести к потере всех данных в виртуальном диске.

Уровень RAID1, или Mirror, создает идентичные копии данных на двух и более дисках. Объем виртуального диска при этом не превышает объема минимального из физических дисков. Данные на виртуальном диске RAID1 будут доступны, пока хотя бы один физический диск из массива работает. Использование RAID1 добавляет избыточности, но является достаточно дорогим решением, так как в массивах из двух и более дисков доступен объем только одного.

Уровень RAID5 решает проблему дороговизны. Для создания массива с уровнем RAID5 необходимо как минимум 3 диска, при этом массив устойчив к выходу из строя одного диска. Данные в RAID5 хранятся блоками с контрольными суммами. Нет строгого деления на диски с данными и диски с контрольными суммами. Контрольные суммы в RAID5 — это результат операции XOR, примененной к N-1 блокам, каждый из которых взят со своего диска.
Хотя RAID-массивы повышают избыточность и предоставляют резервирование, они не подходят для хранения резервных копий.
После краткого экскурса по видам RAID-массивов можно переходить к устройствам и программам, которые позволяют собирать и использовать дисковые массивы.

Виды RAID-контроллеров


Существует два способа создать и использовать RAID-массивы: аппаратный и программный. Мы рассмотрим следующие решения:

  • Linux Software RAID.
  • Intel® Virtual RAID On CPU.
  • LSI MegaRAID 9460-8i.

Отметим, что решение Intel® работает на чипсете, из-за чего возникает вопрос, аппаратное это решение или программное. Так, например, гипервизор VMWare ESXi считает VROC программным и не поддерживает официально.

Linux Software RAID


Программные RAID-массивы в семействе ОС Linux — достаточно распространенное решение как в клиентском сегменте, так и в серверном. Все, что нужно для создания массива, — утилита mdadm и несколько блочных устройств. Единственное требование, которое предъявляет Linux Software RAID к используемым накопителям, — быть блочным устройством, доступным системе.

Отсутствие затрат на оборудование и программное обеспечение — очевидное преимущество данного способа. Linux Software RAID организует дисковые массивы ценой процессорного времени. Список поддерживаемых уровней RAID и состояние текущих дисковых массивов можно посмотреть в файле mdstat, который находится в корне procfs:

root@grindelwald:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid10] 
unused devices: <none>

Поддержка уровней RAID добавляется подключением соответствующего модуля ядра, например:

root@grindelwald:~# modprobe raid456
root@grindelwald:~# cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
unused devices: <none>

Все операции с дисковыми массивами производятся через утилиту командной строки mdadm. Сборка дискового массива производится в одну команду:

mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/nvme1n1 /dev/nvme2n1

После выполнения этой команды в системе появится блочное устройство /dev/md0, которое представляет из тебя виртуальный диск.

Intel® Virtual RAID On CPU


Intel® VROC Standard Hardware Key
Intel® Virtual RAID On CPU (VROC) — это программно-аппаратная технология для создания RAID-массивов на базе чипсетов Intel®. Данная технология доступна в основном для материнских плат с поддержкой процессоров Intel® Xeon® Scalable. По умолчанию VROC недоступен. Для его активации необходимо установить аппаратный лицензионный ключ VROC.

Стандартная лицензия VROC позволяет создавать дисковые массивы с 0, 1 и 10 уровнями RAID. Премиальная версия расширяет этот список поддержкой RAID5.

Технология Intel® VROC в современных материнских платах работает совместно с Intel® Volume Management Device (VMD), которая обеспечивает возможность горячей замены для накопителей с интерфейсом NVMe.

Intel® VROC со стандартной лицензией Настройка массивов производится через Setup Utility при загрузке сервера. На вкладке Advanced появляется пункт Intel® Virtual RAID on CPU, в котором можно настроить дисковые массивы.

Создание массива RAID1 на двух накопителях
Технология Intel® VROC имеет свои «козыри в рукаве». Дисковые массивы, собранные с помощью VROC, совместимы с Linux Software RAID. Это означает, что состояние массивов можно отслеживать в /proc/mdstat, а администрировать — через mdadm. Эта «особенность» официально поддерживается Intel. После сборки RAID1 в Setup Utility можно наблюдать синхронизацию накопителей в ОС:

root@grindelwald:~# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md126 : active raid1 nvme2n1[1] nvme1n1[0]
      1855832064 blocks super external:/md127/0 [2/2] [UU]
      [>....................]  resync =  1.3% (24207232/1855832064) finish=148.2min speed=205933K/sec
      
md127 : inactive nvme1n1[1](S) nvme2n1[0](S)
      10402 blocks super external:imsm
       
unused devices: <none>

Отметим, что через mdadm нельзя собирать массивы на VROC (собранные массивы будут Linux SW RAID), но можно менять в них диски и разбирать массивы.

LSI MegaRAID 9460-8i


Внешний вид контроллера LSI MegaRAID 9460-8i
RAID-контроллер является самостоятельным аппаратным решением. Контроллер работает только с накопителями, подключенными непосредственно к нему. Данный RAID-контроллер поддерживает до 24 накопителей с интерфейсом NVMe. Именно поддержка NVMe выделяет этот контроллер из множества других.

Главное меню аппаратного контроллера
При использовании режима UEFI настройки контроллера интегрируются в Setup Utility. В сравнении с VROC меню аппаратного контроллера выглядит значительно сложнее.

Создание RAID1 на двух дисках
Объяснение настройки дисковых массивов на аппаратном контроллере является достаточно тонкой темой и может стать поводом для полноценной статьи. Здесь же мы просто ограничимся созданием RAID0 и RAID1 с настройками по умолчанию.

Диски, подключенные в аппаратный контроллер, не видны операционной системе. Вместо этого контроллер «маскирует» все RAID-массивы под SAS-накопители. Накопители, подключенные в контроллер, но не входящие в состав дискового массива, не будут доступны ОС.

root@grindelwald:~# smartctl -i /dev/sda
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-48-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               AVAGO
Product:              MR9460-8i
Revision:             5.14
Compliance:           SPC-3
User Capacity:        1,999,844,147,200 bytes [1.99 TB]
Logical block size:   512 bytes
Rotation Rate:        Solid State Device
Logical Unit id:      0x000000000000000000000000000000
Serial number:        00000000000000000000000000000000
Device type:          disk
Local Time is:        Sun Oct 11 16:27:59 2020 MSK
SMART support is:     Unavailable - device lacks SMART capability.

Несмотря на маскировку под SAS-накопители, массивы с NVMe будут работать на скорости PCIe. Однако такая особенность позволяет загружаться с NVMe в Legacy.

Тестовый стенд


Каждый из способов организации дисковых массивов имеет свои физические плюсы и минусы. Но есть ли разница в производительности при работе с дисковыми массивами?

Для достижения максимальной справедливости все тесты будут проведены на одном и том же сервере. Его конфигурация:

  • 2x Intel® Xeon® 6240;
  • 12x DDR4-2666 16 GB;
  • LSI MegaRAID 9460-8i;
  • Intel® VROC Standard Hardware Key;
  • 4x Intel® SSD DC P4510 U.2 2TB;
  • 1x Samsung 970 EVO Plus M.2 500GB.

Тестируемыми выступают P4510, из которых одна половина подключена к материнской плате, а вторая — к RAID-контроллеру. На M.2 установлена операционная система Ubuntu 20.04, а тесты будут выполняться при помощи fio версии 3.16.

Тестирование


В первую очередь проверим задержки при работе с диском. Тест выполняется в один поток, размер блока 4 КБ. Каждый тест длится 5 минут. Перед началом для соответствующего блочного устройства выставляется none в качестве планировщика I/O. Команда fio выглядит следующим образом:

fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio  --iodepth=1 --loops=1000 --runtime=300  --rw=<mode> --filename=<blkdev>

Из результатов fio мы берем clat 99.00%. Результаты приведены в таблице ниже.
Случайное чтение, мкс Случайная запись, мкс
Диск 112 78
Linux SW RAID, RAID0 113 45
VROC, RAID0 112 46
LSI, RAID0 122 63
Linux SW RAID, RAID1 113 48
VROC, RAID1 113 45
LSI, RAID1 128 89
Помимо задержек при обращении к данным, хочется увидеть производительность виртуальных накопителей и сравнить с производительностью физического диска. Команда для запуска fio:

fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio  --loops=1000 --runtime=300  --iodepth=<threads> --rw=<mode> --filename=<blkdev>

Производительность измеряется в количестве операций ввода-вывода. Результаты представлены в таблице ниже.

Случайное чтение 1 поток, IOPS Случайная запись 1 поток, IOPS Случайное чтение 128 потоков, IOPS Случайная запись 128 потоков, IOPS
Диск 11300 40700 453000 105000
Linux SW RAID, RAID0 11200 52000 429000 232000
VROC, RAID0 11200 52300 441000 162000
LSI, RAID0 10900 44200 311000 160000
Linux SW RAID, RAID1 10000 48600 395000 147000
VROC, RAID1 10000 54400 378000 244000
LSI, RAID1 11000 34300 229000 248000
Легко заметить, что использование аппаратного контроллера дает увеличение задержек и просадку по производительности в сравнении с программными решениями.

Заключение


Использование аппаратных решений для создания дисковых массивов из двух дисков выглядит нерационально. Тем не менее, существуют задачи, где использование RAID-контроллеров оправдано. С появлением контроллеров с поддержкой интерфейса NVMe у пользователей появляется возможность использовать более быстрые SSD в своих проектах.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вы используете RAID-решения?

  • 28,6%Да, аппаратные решения40
  • 48,6%Да, программные решения68
  • 17,1%Нет24
  • 5,7%RAID не нужен8




Комментарии (35):

  1. achekalin
    /#22192810

    А что с поддержкой VROC в ОС? Redhat да, а Debian/Proxmox? А в ESXi?

    • Firemoon
      /#22195422

      Руководство пользователя VROC говорит про Windows, SLES, RHEL, Ubuntu и ESXi.
      Хотя ESXi считает VROC программным решением и «не любит» его.

      На практике не проверял, но полагаю, что Debian и Proxmox должны поддерживать работу с VROC как и Ubuntu, они же все Debian-based.

  2. snvakula
    /#22192892

    Почему RAID не подходит для хранения резервных копий?

    • Yak52
      /#22192914 / +2

      Видимо имеется в виду рекомендация не использовать RAID 1 в качестве бэкапа, поскольку все изменения в рабочем файле «зеркалируются» на копию.

      • zer0nka
        /#22193018

        эм, а какую версию рейда тогда нужно использовать? ;-)

      • achekalin
        /#22193128

        Скорее, речь о том, что наличие «зеркала» — это замена бекапу. Это не замена, жто просто повышение надежности хранения на конкретном хранилище, а бекап должен создавать на другой, отдельный, носитель/хранилище.

        Так же, как не замена бекапу и наличие регулярно создаваемых снапшотов на том же хранилище.

        А по теме поста: брать LSI MegaRAID 9460-8i, который сам чуть не медленнее, чем SSD диски, означает добавлять звено, не ускорящее, а замедляющее работу — тут можно даже не тестировать. В лучшем случае контроллер стоит при этом перевести в режим «не кешируй» (там кеш — DDR4-2133, и это еще среди RAID-плат очень неплохо) и отключить всякие read ahead и writeback, т.е. привести вроде бы способную на многое (с HDD) железку к самому простому HBA, только умеющему писать параллельно на несколько носителей. Ну, и отгребать задержки, внесенные контроллером.

        С другой стороны, аппаратные контроллеры не всегда про скорость, они про надежность. Софтовые RAID — это отлично, но часть софта (тот же ESXi) все же не уважает их, и просто тихо игнорирует, либо видит как отдельные диски (ну, или все же VROC как-то подружился с ESXi?) Тут уже «шашечки или ехать»…

    • zer0nka
      /#22193012

      Тут наверно имеется в виду что если у тебя настроен рейд, то тебе все еще нужно делать бэкапы. Так как избыточность данных(рейд) и снапшот данных (бэкап) разные понятия.

    • Busla
      /#22193542

      Потому что опять статью заказали у копирайтера.

    • saboteur_kiev
      /#22194422

      Потому что райд это отказоустойчивость, а не резервирование.
      Если у тебя пользователь удалил файл или из-за логической ошибки в программе испортились данные, то raid тут не поможет. А вчерашний бэкап поможет.

      • snvakula
        /#22194806

        Почему RAID это обязательно отказоустойчивость?)
        Например, RAID0 совсем не про отказоустойчивость.
        И он (как и любой RAID, в принципе) вполне подходит для хранения бэкапов.
        Другой вопрос, что сам по себе RAID с рабочими данными не может заменить бэкапы (их нужно делать отдельно, но вполне возможно на другом RAID-e).

        • evgeniymx
          /#22194872

          RAID0 да, просто многие думают что «сделаю себе RAID1/5/10 — можно не делать бэкапы».
          У массивов совсем другие задачи решаются

        • melco
          /#22195798

          RAID0(stripe) для бэкапа будет менее надежным, чем JBOD или просто конкатенация. Выход одного из двух дисков даст потерю всех 100% бэкапов. Не придумал сценария, в котором бы RAID0 из NVMe дисков был бы хорош для бэкапа.

          • Elmot
            /#22210730

            Есть такой сценарий — когда надо писать бэкапы как можно быстрее. Собственно это примерна тот же паттерн, что мастеринг видео, где RAID0 и востребован.

            • melco
              /#22210746

              Для таких сценариев предусмотрен CoW (Copy on Write). Поддерживается в достаточно невзрачном виде на Linux LVM и в достаточно развитом на какой-нибудь ZFS.

    • evgeniymx
      /#22194868

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

      • Yuriy_krd
        /#22196856

        Потому что RAID это не про резервные копии, это про повышение отказоустойчивости.

        Или про повышение скорости чтения/записи (это про нулевой рейд).

      • Elmot
        /#22210858

        это про повышение отказоустойчивости.

        Если вы про аппаратный рейд, то не ведитесь на этот маркетинг. Аппаратный рейд контроллер — это точка отказа хуже самого плохого диска, потому что он один. Плавали, знаем. Лет 20 тому назад стоял у нас подобный контроллер, еще SCSI.
        Допустим лет 5 стоял некий контроллер, диски в рейде ротировались и на душе было тепло. В один непрекрасный день контроллер сдох. И через полчаса выясняется, что на подменный контроллер пролили воду на складе, вся линейка контроллеров 4 года назад снята с производства, вендора выкупили китайцы, новые контроллеры не совместимы по форматам дисков, а последний в мире такой же контроллер продается на уругвайском ебее. В Уругвае разгар карнавала.
        А был бы софт-рейд, можно было бы хоть на чем-то поднять массив и спасти данные.

        • evgeniymx
          /#22210896

          Мне кажется, что используя какую-то hardware raid железку, всегда надо иметь n+1 железку в резерве :) У Вас звезды сошлись — и одна железка умерла, и вторую затопили, и с производства сняли. Да, такие ситуации мне тоже бывали известны, а как же многонедельные ребилды RAID 5 массивов на хваленных LSI… было дело)

  3. drdead
    /#22192942

    Не раскрыта тема различных strip sizes и разницы между cached и direct IO на аппаратном контроллере. Так же различные сценарии их применения — билд-сервер, SQL, vSAN...


    Синтетические тесты с одним набором параметров, если честно, вообще не говорят ни о чём и не помогут в выборе решения под конкретную задачу (даже estimated решения не "натянуть" никуда).

  4. temask88
    /#22192992 / +1

    Хотя RAID-массивы повышают избыточность и предоставляют резервирование, они не подходят для хранения резервных копий.


    Сами то RAID-массивы отлично подходят для хранения, в том числе, резервных копий.
    Скорее всего имелось ввиду не заменяют или не являются резервными копиями.

  5. fshp
    /#22192994

    В sw raid1 у вас на 20% больше iops на запись чем у диска. Intel тут вообще на 35% быстрее оказался. Что ставит под сомнения все тесты.

  6. nApoBo3
    /#22192998 / +1

    Результаты тестов достаточно странные. Есть подозрение, что-то не так с настройками или аппаратным решением.
    У LSI Raid 0 случайное чтение значительно хуже чем на одном диске, а случайная запись на raid 0 хуже чем случайная запись на raid 1.
    Возможны диски были не в идентичном состоянии или например подключение контроллера LSI было к медленной шине.
    Опять таки в отдельных случаях случайная запись на raid на двух дисках более чем в два раза быстрее, чем случайная запись на диск, при том даже на raid 1. Наверно это можно было бы объяснить очень хитрой системой оптимизации записи у контроллера( или просто записью в кэш ), но на софтовом raid такого быть как бы не должно.

  7. werter78
    /#22193068

    Кому интересно, то можно организовать загрузку с софтового zfs рейда Proxmox-а на nvm с помощью refind, если нативная поддержка загрузки невозможна (привет старым брендовым серверам). NVM-диски подключаются через переходник m.2 -> pci-e (напр., aliexpress.ru/item/32951433342.html — есть в ДНС под именем orient c299e)
    Зы. Есть и такие варианты, как ASRock Ultra Quad M.2 Card и аналоги на Али (искать по фразе JEYI iHyper-Pro m.2 X16), но это если ваша матплата умеет «разваливать» x16 на x4+x4+x4+x4 (и некоторые китайские матплаты это умеют, кстати — xeon-e5450.ru в помощь)
    Зы2. How to get full NVMe support for all Systems with an AMI UEFI BIOS www.win-raid.com/t871f50-Guide-How-to-get-full-NVMe-support-for-all-Systems-with-an-AMI-UEFI-BIOS.html

    • nApoBo3
      /#22193536

      Есть аналогичные платы с собственным pci-e свичем. Правда ценник у них несколько не гуманный.

  8. shokedjobana
    /#22194156

    интересно было бы увидеть в сравнении Storage Spaces

  9. akrupa
    /#22194494

    Неплохо!
    Выводы коротко:
    Для RAID0 рулит Linux Soft RAID;
    Для RAID1 рулит VROC;
    LSI отстает везде.
    Но, только для 4k random R/W.

    Дополнительно добавлю, что грузиться с NVM-E вообще и NVM-E Linux Soft RAID в частности можно в Legacy/BIOS режиме, причем, даже на очень старом железе, где BIOS знать не знает, что такое NVM-E. Главное чтобы загрузчик (GRUB) знал, а его можно записать на SATA диск или массив из них, как, например, это сделано тут:
    habr.com/ru/post/492834

    • quartz64
      /#22195698

      Дополнительно добавлю, что грузиться с NVM-E вообще и NVM-E Linux Soft RAID в частности можно в Legacy/BIOS режиме

      Позанудствую немного: разместить корень на NVMe ? грузиться с NVMe.

      • Elmot
        /#22210754

        Сложить корень на NVMe RAID, а все свободные USB порты сервера утыкать идентичными USB свистками с загрузчиком. Пока рейд и хотя бы один свисток жив — загрузка возможна. От биоса ничего не требуется кроме умения грузиться с USB свистка.

  10. akrupa
    /#22194530

    Добавлю еще к вышесказанному, что у вас сами накопители явно являются узким местом. У них слишком высокие задержки, и очень плохое случайное чтение в 1 поток. Вот такие данные я получаю при использовании Linux Soft RAID1 из 2хSamsung SSD 970 EVO 500GB:
    fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio --iodepth=1 --loops=1000 --runtime=300 --rw=write --filename=/dev/vg_root/test
    write: IOPS=36.8k, BW=144MiB/s (151MB/s)(42.1GiB/300000msec)
    | 99.00th=[ 31], 99.50th=[ 37], 99.90th=[ 51], 99.95th=[ 60],

    fio --name=test --blocksize=4k --direct=1 --buffered=0 --ioengine=libaio --iodepth=1 --loops=1000 --runtime=300 --rw=read --filename=/dev/vg_root/test
    read: IOPS=50.5k, BW=197MiB/s (207MB/s)(57.8GiB/300000msec)
    | 99.00th=[ 22], 99.50th=[ 28], 99.90th=[ 45], 99.95th=[ 81],

  11. DenShark
    /#22195038

    Вопрос такой.
    При RAID 1 износ NVMe будет равномерный, ведь запись зеркальна, и на двух однотипных дисках будет идти идентично? Т.е. при «перетирании» одного диска, второй аналогично «состариться», и смерть дисков может быть условно синхронизирована?

    • dravor
      /#22195110

      ри RAID 1 износ NVMe будет равномерный, ведь запись зеркальна, и на двух однотипных дисках будет идти идентично? Т.е. при «перетирании» одного диска, второй аналогично «состариться», и смерть дисков может быть условно синхронизирована?

      Именно по этой причине хорошая рекомендация при проектировании рейда — это не делать его на дисках одной модели или как минимум не брать все из одной производственной партии.

      • quartz64
        /#22195686

        Именно по этой причине хорошая рекомендация при проектировании рейда — это не делать его на дисках одной модели или как минимум не брать все из одной производственной партии.

        Красивая рекомендация. Жаль, что никто из производителей СХД и RAID-контроллеров про неё не знает, а инженеры Adaptec и Broadcom (ранее LSI/Avago) дают противоположные рекомендации.

        Чтобы заново не писать, продублирую свой комментарий к другому посту о RAID из SSD:
        По моим наблюдениям (статистика обращений по гарантии и техподдержке почти за 10 лет, серверы и СХД) все эти опасения насчёт одновременного выхода из строя являются чем-то вроде старой городской страшилки. Это было с HDD и доходило до рекомендаций ставить в большие массивы диски непременно 3–4 разных моделей и от разных вендоров (!). Определённые основания такой фобии есть, они связаны с массовым отказом определённой моделей. Но, во-первых, последний очень громкий и действительно массовый случай был с Барракудами 7200.11 и это было 10 лет назад, во-вторых — не надо под серьёзный production собирать массивы из бытовых дисков, и в-третьих — не надо забывать про аксиому «RAID ? бэкап».
        Видимо с годами эта фобия перекочевала на SSD, но тут на практике вообще ничего не подтверждается. Да, SSD мрут, в том числе и серверные, и любых вендоров/моделей (есть обширная статистика Intel, Micron, Samsung, HGST, Toshiba), но за 10 лет я ни разу не наблюдал этого мифического случая «одновременного износа».

        • akrupa
          /#22195718

          Могу еще порекомендовать настроить мониторинг на уровень износа и по-достижении определенного % износа заменять один из дисков.
          В случае зеркала из 2хNVME по достижении 60% износа один из накопителей заменяется на новый. Далее накопители ротируются соблюдая правило, что минимум один из накопителей должен всегда иметь износ меньше 60%, когда как другой может быть любой. Ранее извлеченные накопители с >60% можно потом доносить, когда сдохнет тот, который остался в массиве.
          Возможны другие схемы ротации.

        • creker
          /#22195872 / +2

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

          Ну и хотелось бы увидеть, где же производители рекомендуют так не делать. Все, что говорят обычно в мануалах, это брать одинаковые диски. Только связано это в первую очередь с желанием не собрать кое как работающее нечто, когда в одном рейде диски с разными объемами диска, кэшей, скоростью вращения и прочим. При этом даже так оно будет нормально себе работать, иначе бы смысла в рейдах никакого не было.

          Вот dell спокойно рассуждает, что пихать в рейды можно какие угодно диски www.dell.com/support/article/ru-ru/sln283215/dell-enterprise-raid-and-physical-drive-replacement-faq-can-different-drives-be-used-in-a-raid?lang=en

  12. quartz64
    /#22195666

    Отметим, что через mdadm нельзя собирать массивы на VROC (собранные массивы будут Linux SW RAID)

    Это не так, см. документацию. Проверял на CentOS 8, последнем Debian и Arch — работает.
    Несмотря на маскировку под SAS-накопители, массивы с NVMe будут работать на скорости PCIe

    Не совсем. Контроллер работает с NVMe-накопителями, но потом презентует массив, как SAS (SCSI) устройство. В результате теряются все прелести протокола NVMe: оптимизированный набор команд, работа с очередями и т.д. В синтетических тестах с парой накопителей я наблюдал на контроллерах Broadcom задержку выше на 15—20% и нагрузку на процессор примерно на 10%.

    Полученным в статье результатам доверять не очень стоит, т.к. при тестировании стоило учесть следующие вещи (см. рекомендации в SNIA PTS):
    • Preconditioning
    • NUMA. Контроллер PCIe у нас живёт в процессоре, а их в данном случае два
    • Убедиться в стабильности результатов. Вместо одного раунда в 5 минут стоило провести десяток по 30–60 секунд, посмотреть на отклонение.
    • Помимо IOPS стоит обратить внимание на задержку (и её распределение) и нагрузку на процессор