Я пытаюсь найти самый простой способ выделить 24x локально подключенных SSD в качестве большого логического тома с низкоценными данными. Я использую их в качестве кэша горячей установки для данных, основное состояние которых (около петабайта) находится в S3, поэтому меня больше заботят производительность, сложность обслуживания и время простоя, чем потерянные данные. Ничто не будет задерживаться в горячем наборе данных более чем на пару дней, и все равно его легко воссоздать из S3.
Думаю, о RAID 5 не может быть и речи, я не собираюсь ждать ручной перестройки. Я склоняюсь к RAID 0, RAID 10 или .... может быть, это действительно случай для простого пула LVM без RAID вообще? Действительно ли я что-нибудь потеряю, выбрав этот относительно простой путь в данном случае?
В моем идеальном решении для каждого подкаталога (у меня есть один автономный набор данных для каждого подкаталога) / полностью хранится на одном диске (я могу разместить около 10 подкаталогов на каждом диске). Если диск вышел из строя, у меня будет временное отключение подкаталогов / наборов данных на этом диске, но легко рассуждать о наборе «эти наборы данных загружаются повторно и недоступны». Затем я просто перестроил недостающие наборы данных из S3 на новый диск. Я подозреваю, что LVM jbods (не уверены в правильном слове для этого?) Могут быть ближе всего к воспроизведению этого поведения.
Кажется, вы противоречите своим потребностям - «В моем идеальном решении каждый подкаталог (у меня есть один автономный набор данных для каждого подкаталога) / полностью содержался бы на одном диске» сообщает вам, что вам не нужны RAID, LVM или какая-либо технология абстракции - * конечно, решение этого - просто смонтировать каждый диск индивидуально. Недостатком здесь является то, что вы, вероятно, потратите впустую дисковое пространство, и если набор данных будет расти, вам нужно будет тратить больше времени на манипулирование им. (Я ожидаю, что вы знаете, что Unix может монтировать диски в произвольных местах дерева файловой системы, поэтому, если подумать, будет достаточно легко сделать диски видимыми в виде логической древовидной структуры)
Вы говорите о JBOD или RAID0. Если вы все же решите использовать комбинированное дисковое решение, RAID0 в большинстве случаев обеспечит лучшую производительность чтения, поскольку данные легко распределяются по дискам. RAID10 купит вам избыточность, которая вам не нужна. JBOD полезен для вас только в том случае, если у вас есть диски разных размеров, и вам лучше использовать LVM вместо этого, поскольку он может вести себя так же, но дает вам гибкость для перемещения данных.
Я могу видеть крайние случаи, когда LVM может помочь с отдельным диском, но в целом любой сценарий, вероятно, добавит больше сложности, чем дает здесь полезную гибкость, особенно с учетом первоначального утверждения о привязке наборов данных к дискам.
Где вы, возможно, захотите потратить некоторые усилия, так это на поиск наиболее подходящей файловой системы и параметров настройки.
Меня больше волнуют производительность, сложность обслуживания и время простоя, чем потерянные данные.
Максимальное увеличение производительности означает, что вам необходимо использовать ту или иную форму RAID-0, RAID10 или LVM. Сложность обслуживания исключает выполнение чего-то вроде сегментации диска по подкаталогам (как другой упоминает манипуляции с томами). Минимизация времени простоя означает, что вам нужно иметь некоторую форму избыточности, поскольку потеря одного диска приводит к отключению всего массива, который вам затем придется восстанавливать. Я прочитал это как «время простоя». Режим пониженной производительности на RAID-5, вероятно, также исключает RAID-5 из соображений производительности.
Итак, я бы сказал, что ваши варианты: RAID10 или RAID1 + LVM. LVM предлагает некоторые расширенные возможности управления размером тома, но многое из этого исчезнет, если вы все равно собираетесь зеркалировать его с помощью RAID-1. Согласно этой статье https://www.linuxtoday.com/blog/pick-your-pleasure-raid-0-mdadm-striping-or-lvm-striping.html RAID-0 предлагает лучшую производительность, чем LVM.
Более простая и беспроблемная установка - использовать программный массив RAID + XFS. Если и только если, вам не важны данные и доступность, вы можете использовать массив RAID0; в противном случае я настоятельно рекомендую вам использовать другую схему RAID. Обычно я предлагаю использовать RAID10, но он требует 50% емкости; для RAID-массива 24x 375 ГБ можно подумать о RAID6 или -gasp- даже RAID5.
Вышеупомянутое решение поставляется с множеством прикрепленных строк, наиболее важно представляя вам одноблочные устройства и пропуская любые разделы хранилища на основе LVM, что означает отсутствие возможности создания снимков. С другой стороны, распределитель XFS очень хорошо справляется с балансировкой между отдельными дисками в конфигурации RAID0.
Другие возможные решения:
используйте XFS поверх классического LVM поверх RAID0 / 5/6: устаревший том LVM в основном не влияет на производительность и позволяет вам как динамически разбивать отдельные блочные устройства, так и делать краткосрочные снимки (хотя и с очень высокой потерей производительности)
используйте XFS поверх тонкого LVM поверх RAID0 / 5/6: тонкий LVM позволяет создавать современные моментальные снимки с меньшим снижением производительности и другие полезности. При использовании с достаточно большим размером блока производительность хороша
рассмотрите возможность использования ZFS (в ее случае ZoL): особенно если ваши данные сжимаются, это может обеспечить значительное пространство и преимущества в производительности. Более того, поскольку ваша рабочая нагрузка кажется тяжелой для чтения, ZFS ARC может быть более эффективным, чем традиционный кеш страниц Linux.
Если ваши данные плохо сжимаются, но подходят для дедупликации, вы можете рассмотреть возможность вставки VDO между блочным устройством RAID и файловой системой.
Наконец, обратите внимание на то, что делает любой вид пула LVM, JBOD или ZFS. не означает, что потеря диска приведет к отключению только тех каталогов, которые находятся на таких дисках; скорее, все виртуальное блочное устройство становится недоступным. Чтобы иметь такую изоляцию, вам необходимо заложить файловую систему для каждого блочного устройства: это означает, что вы должны управлять различными точками монтирования и, что более важно, чтобы ваше хранилище не было объединено в пул (то есть: у вас может закончиться место на диске , а у остальных много свободного места).
Если вы действительно не заботитесь о данных, а только о их производительности и скорости восстановления службы, КОГДА она выходит из строя, а не во избежание сбоя, тогда, вопреки всем моим нормальным здравым суждениям, R0 будет в порядке.
Очевидно, что он не позволяет вам выбирать, какие данные будут отправляться, но это будет примерно так быстро, как я могу думать, да, он определенно выйдет из строя, но вы можете просто иметь сценарий, который удаляет массив R0, восстанавливает его и устанавливает его, не должно занимать больше минуты или около того, чтобы сделать максимум - вы даже можете запустить его автоматически, когда потеряете доступ к диску.
Один небольшой вопрос - вам нужна виртуальная машина 32 x vCPU с ядрами Skylake, они не делают ни одного сокета такого большого размера, поэтому ваша виртуальная машина будет разделена по сокетам, это может быть не так быстро, как вы ожидали, возможно, протестируйте производительность с помощью 32/24/16 ядер, чтобы увидеть, какое влияние будет нормальным, стоит хотя бы быстро попробовать.
Что касается максимальной производительности и сложности обслуживания, вы можете использовать передовые методы, перечисленные здесь [1] [2], в качестве краткого справочника о том, что следует учитывать при создании приложения, использующего облачное хранилище.