Petastore

Так вам ещё и быстрый обмен данными нужен? ИМХО, вам не на ЛОРе надо спрашивать, а у забугорных корпораций.

Так вам ещё и быстрый обмен данными нужен?

Быстрый - понятие относительное. Там где это оправданно имеются машинки заряженные SSD (16x в RAID10 и больше). Здесь вопрос в другом - как правильно организовать warehouse storage с LVM. Кто меня знает - я ярый противник LVM в принципе. Вот и хотелось услышать мнение знатоков «как правильно котиков готовить». Может мы делаем чего не так (что вполне вероятно)?

У меня 0 опыта сборки такого уровня хранилищ, но что видется возможным это: TrueNAS Scale RAID Z2 с жирными кэшами в RAM и NVMe, компрессия zstd, можно еще запихать туда QAT под zstd патчами. Посмотрел бы и твикнул планировщик io (под много дисков нужно multiqueue), но может умные дяди в TrueNAS уже продумали.

Быстрый - понятие относительное.

Ну, я бы при необходимости petastore первым делом про ленточные библиотеки бы подумал. Но, у вас производительность же.

А вот эта фигня не в ту сторону как раз?

Никак, тут что-то типа Hadoop’а нужно, если на бюджетном решении из сотен серверочков.

Там разве не настраивается stripe?

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

А вам точно нужно directly attached storage? Есть опыт поддержки петабайтных Ceph-кластеров.

По поводу отказоустойчивости этого дела - на таких масштабах одновременный отказ нескольких дисков (или отказ дополнительного диска во время восстановления) становится серьезной проблемой. На прошлой неделе было два клиента, у одного кластер 27 петабайт erasure coding 8+2, у другого 7 петабайт 6+3, и вылетело как раз 2 и 3 диска соответственно. Данные не потерялись, но, поскольку Ceph при восстановлении после таких серьезных повреждений блокирует операции чтения и записи, затрагивающие деградировавший PG, то был downtime. Помощь в обоих случаях свелась к оценке времени самовосстановления и рекомендации подождать.

То же самое применимо к другим кластерным хранилкам. Хорошее решение здесь только одно: SSD.

У Виталия Филиппова есть калькулятор надежности таких больших кластеров: https://yourcmc.ru/afr-calc/

По поводу медленного линейного чтения - надо настроить readahead примерно таким правилом udev:

KERNEL=="rbd[0-9]*", ENV{DEVTYPE}=="disk", ACTION=="add|change", ATTR{bdi/read_ahead_kb}="16384"

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

мне совсем не нравится то что я вижу: stripe unit of ~1MB

Мне это тоже не нравится. Линуксовый I/O с учетом readahead имеет типичный размер 64 или 128K. С таким страйпюнитом твой рейд превратился в linear. Если ты хочешь сделать широкий RAID, сделай stripe unit = 128 / количество датапартов, например stripe unit 16K, stripe width 128K, RAID6 8+2.

И чтение (всегда короткое по 8k, random across the board)

У тебя HDD и random read, оно всегда константно днище, 150-200 IOPS с одного физического устройства и с любого количества устройств в один поток - смотря в какой критерий ты уперся.

примерно 1PB directly attached storage

Идея хлам. Хотя если диски раскиданы по куче хостов, уже имеет вполне себе право на жизнь. Но один большой LVM на петабайт это такое себе.

А что такое голый lvm? А что мешало сделать lvcreate —type raid10 -m 1 -i 32 -I 8K?

А вам точно нужно directly attached storage?

В принципе - да. По многим причинам. Я возможно неправильно / не до конца дал все вводные: это условно архив архивов с «боевых» машинок (которые там держать становится нецелесообразно именно из соображений cost) куда ходят раз в пятилетку. Downtime не волнует вообще (если конечно это не дни / недели). Любая конкретно взятая вышедшая из строя деталюшка будет заменена в течении пары часов. Кластерный high-availability storage у нас тоже имеется, но мы оба понимаем что такой storage стОит в разы / на порядки дороже. Более того - с точки зрения бизнеса есть независимая копия тех же данных в другом датацентре (не exact копия, но информация та же).

Есть опыт поддержки петабайтных Ceph-кластеров.

Нам однозначно есть о чём поговорить ;)

Данные не потерялись

Вот это, наверное, единственное чего хотелось бы добиться. В идеале чтобы даже выход из строя двух дисков одной пары не утаскивал за собой вообще всё (я готов жить с losses 10-20%).

Хорошее решение здесь только одно: SSD.

Я боюсь даже подумать сколько это может стоить…

По поводу медленного линейного чтения

Это как раз вообще не нужно - линейного чтения не будет никогда.

Собственно, давайте я переформулирую вопрос: как наиболее грамотно организовать такое хранилище? Я пока склоняюсь к нескольким HW RAID10, поверх которых LVM, и поверх этого XFS. Есть какие-то подводные камни о которых мне лучше знать «на берегу»?

ПыСы. Остальным господам что отозвались тоже огромное спасибо - почитал / переварил. И это не сарказм!! Purposely не буду никого cast’ать - не дай бог пропущу кого и человек расстроится на пустом месте…

Downtime не волнует вообще (если конечно это не дни / недели). Любая конкретно взятая вышедшая из строя деталюшка будет заменена в течении пары часов

Ты в курсе сколько реплицируется рейд на 10ТБ дисках скажем?

так стримеры вроде и шустрые бывают.

только вот у ТС

И чтение (всегда короткое по 8k, random across the board)

Ты в курсе сколько реплицируется рейд на 10ТБ дисках скажем?

Пусть будет сутки. Но это не downtime.

Кластерный high-availability storage у нас тоже имеется, но мы оба понимаем что такой storage стОит в разы / на порядки дороже.

На самом деле нет. За счет использования erasure coding (это такой распределенный RAID6) можно раза в полтора сэкономить на дисках по сравнению с предложенным вариантом с аппаратным RAID10. Более того, кластер будет автоматически увеличиваться (с точки зрения доступного места) при добавлении исков и уменьшаться при выходе из строя.

Ну и кстати: RAID10 с двумя копиями не дает достаточной надежности на петабайтных объемах.

Единственное «но»: любые многодисковые решения дают прирост IOPS только при наличии множества клиентов, читающих или пишущих данные независимо.

А для random-чтения по 8k, увы, HDD дают максимум 120 IOPS. Хочешь больше и у тебя данные читаются в несколько потоков - бери MACH.2 (это 2 SAS HDD по 9 TB в одном корпусе) или, как предлагалось, SSD.

Ну и кстати: RAID10 с двумя копиями не дает достаточной надежности на петабайтных объемах.

А точнее: у двух вышеупомянутых клиентов в такой конфигурации была бы потеря данных.

Ну и кстати: RAID10 с двумя копиями не дает достаточной надежности на петабайтных объемах.

Почему? Буквально с одной из первых ссылок про erasure coding:

«Erasure coding can provide the same level of data protection as mirroring (RAID 1), while using less storage capacity.»

Лично мой опыт - чем проще тем лучше и надежней, и с RAID5 я уже данные терял, причём в штатной ситуации и с приличным серверным железом.

А вот это вообще killer:

«Erasure coding also means that every read IO has to come from multiple nodes in the cluster.»

Но спасибо за наводку - есть о чём подумать теперь.

Erasure coding can provide the same level of data protection as mirroring (RAID 1), while using less storage capacity.

Все правильно. Вопрос в определении RAID1. Некоторые определяют его как «две зеркальные копии», а некоторые - как N копий. Аппаратные карточки, как правило, не умеют держать больше двух копий.

Ceph рекомендует держать три копии, что для твоих целей дорого. Повторяю: на таких масштабах двух копий недостаточно.

При настройке Erasure Coding в Ceph ты сам выбираешь, на сколько чанков разбить каждый кусок данных и сколько чанков информации для восстановления к ним добавить.

Т.е. если у тебя есть 10 серверов, то ты запросто можешь сделать схему 6+3, всего лишь с полуторным оверхедом, и выдерживать потерю двух серверов так, что никто даже не заметит, и потерю трех серверов с даунтаймом, но без потери данных. После этого Ceph автоматически размажет данные по оставшемуся железу.