Комментарии 39
А что с поддержкой VROC в ОС? Redhat да, а Debian/Proxmox? А в ESXi?
Руководство пользователя VROC говорит про Windows, SLES, RHEL, Ubuntu и ESXi.
Хотя ESXi считает VROC программным решением и «не любит» его.
На практике не проверял, но полагаю, что Debian и Proxmox должны поддерживать работу с VROC как и Ubuntu, они же все Debian-based.
Хотя ESXi считает VROC программным решением и «не любит» его.
На практике не проверял, но полагаю, что Debian и Proxmox должны поддерживать работу с VROC как и Ubuntu, они же все Debian-based.
Почему RAID не подходит для хранения резервных копий?
Видимо имеется в виду рекомендация не использовать RAID 1 в качестве бэкапа, поскольку все изменения в рабочем файле «зеркалируются» на копию.
эм, а какую версию рейда тогда нужно использовать? ;-)
Никакую. Резервирование, которым является RAID ≠ бэкапирование. То-есть бэкапы, при наличии рейда, делать всё равно обязательно. Рейд не спасёт вас от программных и/или аппаратных ошибок и нарушения, в результате действия этих ошибок, консистентности данных. Рейд, это про то, что-б горячие данные были доступны в случае выхода из строя одного или нескольких, в зависимости от типа рейда, дисков.
Скорее, речь о том, что наличие «зеркала» — это замена бекапу. Это не замена, жто просто повышение надежности хранения на конкретном хранилище, а бекап должен создавать на другой, отдельный, носитель/хранилище.
Так же, как не замена бекапу и наличие регулярно создаваемых снапшотов на том же хранилище.
А по теме поста: брать LSI MegaRAID 9460-8i, который сам чуть не медленнее, чем SSD диски, означает добавлять звено, не ускорящее, а замедляющее работу — тут можно даже не тестировать. В лучшем случае контроллер стоит при этом перевести в режим «не кешируй» (там кеш — DDR4-2133, и это еще среди RAID-плат очень неплохо) и отключить всякие read ahead и writeback, т.е. привести вроде бы способную на многое (с HDD) железку к самому простому HBA, только умеющему писать параллельно на несколько носителей. Ну, и отгребать задержки, внесенные контроллером.
С другой стороны, аппаратные контроллеры не всегда про скорость, они про надежность. Софтовые RAID — это отлично, но часть софта (тот же ESXi) все же не уважает их, и просто тихо игнорирует, либо видит как отдельные диски (ну, или все же VROC как-то подружился с ESXi?) Тут уже «шашечки или ехать»…
Так же, как не замена бекапу и наличие регулярно создаваемых снапшотов на том же хранилище.
А по теме поста: брать LSI MegaRAID 9460-8i, который сам чуть не медленнее, чем SSD диски, означает добавлять звено, не ускорящее, а замедляющее работу — тут можно даже не тестировать. В лучшем случае контроллер стоит при этом перевести в режим «не кешируй» (там кеш — DDR4-2133, и это еще среди RAID-плат очень неплохо) и отключить всякие read ahead и writeback, т.е. привести вроде бы способную на многое (с HDD) железку к самому простому HBA, только умеющему писать параллельно на несколько носителей. Ну, и отгребать задержки, внесенные контроллером.
С другой стороны, аппаратные контроллеры не всегда про скорость, они про надежность. Софтовые RAID — это отлично, но часть софта (тот же ESXi) все же не уважает их, и просто тихо игнорирует, либо видит как отдельные диски (ну, или все же VROC как-то подружился с ESXi?) Тут уже «шашечки или ехать»…
Тут наверно имеется в виду что если у тебя настроен рейд, то тебе все еще нужно делать бэкапы. Так как избыточность данных(рейд) и снапшот данных (бэкап) разные понятия.
Потому что опять статью заказали у копирайтера.
Потому что райд это отказоустойчивость, а не резервирование.
Если у тебя пользователь удалил файл или из-за логической ошибки в программе испортились данные, то raid тут не поможет. А вчерашний бэкап поможет.
Если у тебя пользователь удалил файл или из-за логической ошибки в программе испортились данные, то raid тут не поможет. А вчерашний бэкап поможет.
Почему RAID это обязательно отказоустойчивость?)
Например, RAID0 совсем не про отказоустойчивость.
И он (как и любой RAID, в принципе) вполне подходит для хранения бэкапов.
Другой вопрос, что сам по себе RAID с рабочими данными не может заменить бэкапы (их нужно делать отдельно, но вполне возможно на другом RAID-e).
Например, RAID0 совсем не про отказоустойчивость.
И он (как и любой RAID, в принципе) вполне подходит для хранения бэкапов.
Другой вопрос, что сам по себе RAID с рабочими данными не может заменить бэкапы (их нужно делать отдельно, но вполне возможно на другом RAID-e).
RAID0 да, просто многие думают что «сделаю себе RAID1/5/10 — можно не делать бэкапы».
У массивов совсем другие задачи решаются
У массивов совсем другие задачи решаются
RAID0(stripe) для бэкапа будет менее надежным, чем JBOD или просто конкатенация. Выход одного из двух дисков даст потерю всех 100% бэкапов. Не придумал сценария, в котором бы RAID0 из NVMe дисков был бы хорош для бэкапа.
Потому что RAID это не про резервные копии, это про повышение отказоустойчивости.
Например, если в RAID1 диски разных партий, то вероятность что оба диска выйдут из строя одновременно меньше, а если выйдет один из строя, то у Вас будет время на то, чтобы вставить новый диск в массив, провести синхронизацию и работать дальше.
А если, например, у Вас в рейде висит 2 диска из одной партии и оба с браком, то высока вероятность их одновременного выхода из строя и, соответственно, чревато частичной или даже полной потерей данных.
Помимо RAID надо всегда иметь холодную копию данных, которая делается с нужным временным интервалом и за пределы сервера, если есть такая возможность.
Например, если в RAID1 диски разных партий, то вероятность что оба диска выйдут из строя одновременно меньше, а если выйдет один из строя, то у Вас будет время на то, чтобы вставить новый диск в массив, провести синхронизацию и работать дальше.
А если, например, у Вас в рейде висит 2 диска из одной партии и оба с браком, то высока вероятность их одновременного выхода из строя и, соответственно, чревато частичной или даже полной потерей данных.
Помимо RAID надо всегда иметь холодную копию данных, которая делается с нужным временным интервалом и за пределы сервера, если есть такая возможность.
Потому что RAID это не про резервные копии, это про повышение отказоустойчивости.
Или про повышение скорости чтения/записи (это про нулевой рейд).
это про повышение отказоустойчивости.
Если вы про аппаратный рейд, то не ведитесь на этот маркетинг. Аппаратный рейд контроллер — это точка отказа хуже самого плохого диска, потому что он один. Плавали, знаем. Лет 20 тому назад стоял у нас подобный контроллер, еще SCSI.
Допустим лет 5 стоял некий контроллер, диски в рейде ротировались и на душе было тепло. В один непрекрасный день контроллер сдох. И через полчаса выясняется, что на подменный контроллер пролили воду на складе, вся линейка контроллеров 4 года назад снята с производства, вендора выкупили китайцы, новые контроллеры не совместимы по форматам дисков, а последний в мире такой же контроллер продается на уругвайском ебее. В Уругвае разгар карнавала.
А был бы софт-рейд, можно было бы хоть на чем-то поднять массив и спасти данные.
Мне кажется, что используя какую-то hardware raid железку, всегда надо иметь n+1 железку в резерве :) У Вас звезды сошлись — и одна железка умерла, и вторую затопили, и с производства сняли. Да, такие ситуации мне тоже бывали известны, а как же многонедельные ребилды RAID 5 массивов на хваленных LSI… было дело)
Прошу прощения за некропост, но, попадал в свое время в абсолютно аналогичную ситуацию. Только контроллер на замену не удалось найти совсем.
Решилось сборкой массива вручную при помощи ПО для восстановления данных. И, слава богам, встроенный кэш работал в режиме write-through.
С тех пор я аппаратные RAID контроллеры не использую в своих проектах совсем. Как и встроенные в материнскую плату. И то, и то — точка отказа. Только программные массивы.
Даже все имеющиеся LSI SAS RAID контроллеры в SAS HBA ( Initiator/Target режим) перепрошил.
Решилось сборкой массива вручную при помощи ПО для восстановления данных. И, слава богам, встроенный кэш работал в режиме write-through.
С тех пор я аппаратные RAID контроллеры не использую в своих проектах совсем. Как и встроенные в материнскую плату. И то, и то — точка отказа. Только программные массивы.
Даже все имеющиеся LSI SAS RAID контроллеры в SAS HBA ( Initiator/Target режим) перепрошил.
Не раскрыта тема различных strip sizes и разницы между cached и direct IO на аппаратном контроллере. Так же различные сценарии их применения — билд-сервер, SQL, vSAN...
Синтетические тесты с одним набором параметров, если честно, вообще не говорят ни о чём и не помогут в выборе решения под конкретную задачу (даже estimated решения не "натянуть" никуда).
Хотя RAID-массивы повышают избыточность и предоставляют резервирование, они не подходят для хранения резервных копий.
Сами то RAID-массивы отлично подходят для хранения, в том числе, резервных копий.
Скорее всего имелось ввиду не заменяют или не являются резервными копиями.
В sw raid1 у вас на 20% больше iops на запись чем у диска. Intel тут вообще на 35% быстрее оказался. Что ставит под сомнения все тесты.
Результаты тестов достаточно странные. Есть подозрение, что-то не так с настройками или аппаратным решением.
У LSI Raid 0 случайное чтение значительно хуже чем на одном диске, а случайная запись на raid 0 хуже чем случайная запись на raid 1.
Возможны диски были не в идентичном состоянии или например подключение контроллера LSI было к медленной шине.
Опять таки в отдельных случаях случайная запись на raid на двух дисках более чем в два раза быстрее, чем случайная запись на диск, при том даже на raid 1. Наверно это можно было бы объяснить очень хитрой системой оптимизации записи у контроллера( или просто записью в кэш ), но на софтовом raid такого быть как бы не должно.
У LSI Raid 0 случайное чтение значительно хуже чем на одном диске, а случайная запись на raid 0 хуже чем случайная запись на raid 1.
Возможны диски были не в идентичном состоянии или например подключение контроллера LSI было к медленной шине.
Опять таки в отдельных случаях случайная запись на raid на двух дисках более чем в два раза быстрее, чем случайная запись на диск, при том даже на raid 1. Наверно это можно было бы объяснить очень хитрой системой оптимизации записи у контроллера( или просто записью в кэш ), но на софтовом raid такого быть как бы не должно.
Кому интересно, то можно организовать загрузку с софтового 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
Зы. Есть и такие варианты, как 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
интересно было бы увидеть в сравнении Storage Spaces
Неплохо!
Выводы коротко:
Для 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
Выводы коротко:
Для 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
Добавлю еще к вышесказанному, что у вас сами накопители явно являются узким местом. У них слишком высокие задержки, и очень плохое случайное чтение в 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],
Вопрос такой.
При RAID 1 износ NVMe будет равномерный, ведь запись зеркальна, и на двух однотипных дисках будет идти идентично? Т.е. при «перетирании» одного диска, второй аналогично «состариться», и смерть дисков может быть условно синхронизирована?
При RAID 1 износ NVMe будет равномерный, ведь запись зеркальна, и на двух однотипных дисках будет идти идентично? Т.е. при «перетирании» одного диска, второй аналогично «состариться», и смерть дисков может быть условно синхронизирована?
ри RAID 1 износ NVMe будет равномерный, ведь запись зеркальна, и на двух однотипных дисках будет идти идентично? Т.е. при «перетирании» одного диска, второй аналогично «состариться», и смерть дисков может быть условно синхронизирована?
Именно по этой причине хорошая рекомендация при проектировании рейда — это не делать его на дисках одной модели или как минимум не брать все из одной производственной партии.
Именно по этой причине хорошая рекомендация при проектировании рейда — это не делать его на дисках одной модели или как минимум не брать все из одной производственной партии.
Красивая рекомендация. Жаль, что никто из производителей СХД и RAID-контроллеров про неё не знает, а инженеры Adaptec и Broadcom (ранее LSI/Avago) дают противоположные рекомендации.
Чтобы заново не писать, продублирую свой комментарий к другому посту о RAID из SSD:
По моим наблюдениям (статистика обращений по гарантии и техподдержке почти за 10 лет, серверы и СХД) все эти опасения насчёт одновременного выхода из строя являются чем-то вроде старой городской страшилки. Это было с HDD и доходило до рекомендаций ставить в большие массивы диски непременно 3–4 разных моделей и от разных вендоров (!). Определённые основания такой фобии есть, они связаны с массовым отказом определённой моделей. Но, во-первых, последний очень громкий и действительно массовый случай был с Барракудами 7200.11 и это было 10 лет назад, во-вторых — не надо под серьёзный production собирать массивы из бытовых дисков, и в-третьих — не надо забывать про аксиому «RAID ≠ бэкап».
Видимо с годами эта фобия перекочевала на SSD, но тут на практике вообще ничего не подтверждается. Да, SSD мрут, в том числе и серверные, и любых вендоров/моделей (есть обширная статистика Intel, Micron, Samsung, HGST, Toshiba), но за 10 лет я ни разу не наблюдал этого мифического случая «одновременного износа».
Могу еще порекомендовать настроить мониторинг на уровень износа и по-достижении определенного % износа заменять один из дисков.
В случае зеркала из 2хNVME по достижении 60% износа один из накопителей заменяется на новый. Далее накопители ротируются соблюдая правило, что минимум один из накопителей должен всегда иметь износ меньше 60%, когда как другой может быть любой. Ранее извлеченные накопители с >60% можно потом доносить, когда сдохнет тот, который остался в массиве.
Возможны другие схемы ротации.
В случае зеркала из 2хNVME по достижении 60% износа один из накопителей заменяется на новый. Далее накопители ротируются соблюдая правило, что минимум один из накопителей должен всегда иметь износ меньше 60%, когда как другой может быть любой. Ранее извлеченные накопители с >60% можно потом доносить, когда сдохнет тот, который остался в массиве.
Возможны другие схемы ротации.
Это рекомендация, которая работает прекрасно и сегодня. Только недавно у нас была закуплена партия сегейтов корпоративных как раз под рейды 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
Ну и хотелось бы увидеть, где же производители рекомендуют так не делать. Все, что говорят обычно в мануалах, это брать одинаковые диски. Только связано это в первую очередь с желанием не собрать кое как работающее нечто, когда в одном рейде диски с разными объемами диска, кэшей, скоростью вращения и прочим. При этом даже так оно будет нормально себе работать, иначе бы смысла в рейдах никакого не было.
Вот 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
Отметим, что через 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 стоит обратить внимание на задержку (и её распределение) и нагрузку на процессор
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RAID-массивы на NVMe