Я рассматриваю возможность использования ceph в качестве распределенной файловой системы для моей самодельной MAID (массив простаивающих дисков).
Насколько я понимаю, Ceph ориентирован на использование кластера и равномерно распределяет данные по OSD (относительно карт CRUSH) и пытается использовать параллелизм операций чтения на разных узлах.
В моем случае мне не нужно максимизировать распространение и пропускную способность, в идеальном случае он должен заполнять первые N OSD (где N - коэффициент репликации) и только затем начинать заполнение следующих N OSD, чтобы минимизировать количество требуемых активных дисков для поиска смежных данных. .
Могу ли я каким-то образом добиться такого поведения, настроив количество групп размещения и карты CRUSH? Или, если это невозможно, могу я хотя бы заставить ceph перестать разбивать файлы на более чем один блок?
Я не думаю, что с ceph возможно что-то подобное тому, чего вы хотите достичь. Насколько я понимаю, ceph - это распределенная файловая система и что он обеспечивает высокую отказоустойчивость за счет репликации. Читайте здесь:
Сила ceph заключается в его масштабируемости и высокой доступности:
Масштабируемость и высокая доступность
В традиционных архитектурах клиенты общаются с централизованным компонентом (например, шлюзом, брокером, API, фасадом и т. Д.), Который действует как единая точка входа в сложную подсистему. Это накладывает ограничения как на производительность, так и на масштабируемость, в то же время создавая единую точку отказа (то есть, если централизованный компонент выходит из строя, вся система тоже выходит из строя).
Ceph устраняет централизованный шлюз, чтобы позволить клиентам напрямую взаимодействовать с Ceph OSD Daemons. Демоны Ceph OSD создают реплики объектов на других узлах Ceph для обеспечения безопасности и высокой доступности данных. Ceph также использует кластер мониторов для обеспечения высокой доступности. Чтобы устранить централизацию, Ceph использует алгоритм, называемый CRUSH.
Я пытаюсь подчеркнуть, что ceph создан для того, чтобы заботиться об использовании физического диска в кластерной среде таким образом, чтобы обеспечить большую устойчивость, высокую доступность и прозрачность. Не то, что вы ищете.
Если вас беспокоит производительность или дисковый ввод-вывод, есть опция, которая называется Первичная близость, который можно использовать, например, для определения приоритета дисков SAAS над SATA. Читать далее Вот и Вот.
Первичная близость
Когда клиент Ceph читает или записывает данные, он всегда связывается с основным OSD в действующем наборе. Для набора [2, 3, 4] osd.2 является основным. Иногда OSD не очень подходит для работы в качестве основного по сравнению с другими OSD (например, у него медленный диск или медленный контроллер). Чтобы предотвратить узкие места в производительности (особенно при операциях чтения) при максимальном использовании вашего оборудования, вы можете установить первичную привязку Ceph OSD, чтобы CRUSH с меньшей вероятностью использовал OSD в качестве первичного в действующем наборе.
ceph osd primary-affinity <osd-id> <weight>
Первичное сродство по умолчанию равно 1 (т.е. OSD может действовать как первичное). Вы можете установить основной диапазон OSD от 0 до 1, где 0 означает, что OSD НЕ МОЖЕТ использоваться в качестве основного, а 1 означает, что OSD может использоваться в качестве основного. Когда вес <1, маловероятно, что CRUSH выберет Ceph OSD Daemon в качестве основного.
Я знаю, что это не совсем ответ на все ваши вопросы, но может дать пищу для размышлений.
Подробности здесь: http://docs.ceph.com/docs/master/rados/operations/crush-map/#primary-affinity
И Вот хороший блог, объясняющий кластер ceph.