Комментарии 26
Насколько мне известно, Ceph не гонится за маленькими кластерами, наоборот он сделан для хранения петабайт данных (в частности в CERN несколько кластеров суммарным объёмом 35Пб).
В докторской диссертации Sage Weil можно ознакомиться с мотивацией и архитектурой системы (документ от 2007 года):
https://ceph.com/wp-content/uploads/2016/08/weil-thesis.pdf
Так же не могу не отметить, что поддержка такой системы в продакшене требует команды квалифицированных инженеров.
Ну, я знаю установку из нескольких кластеров по 1,5PB каждый. Было решено не корячить один гигантский, а делать несколько фиксированного размера (емнип 3-4 кластера)
В Авито сейчас кластер размером около 7Пб, полёт более-менее нормальный, насколько я могу судить со своей колокольни.
Тачки были на 24 диска. Диски по 6TB. Решили делать Erasure Coding 10+2. Вот и сделали кластера по 12 тачек. Соображения: при временном выходе диска/тачки из строя сеф не начнёт перебалансировать, т.к. число тачек равно числу реплик. Плюс, т.к. конфигурация кластера у каждого PD в памяти, не хотелось иметь слишком большой кластер. Плюс нам дали всего лишь гигабитную сетку.
Ну и, если что-то случается серьезное, то таком весь кластер встаёт. Лучше, чтобы встал один из трёх небольших, чем один большой. (К чести сказать, раком встаёт он редко, в половине случаев по нашей вине, и потом всегда удавалось восстановить).
А ещё, данные переливались с другого кластера (не CEPH), и на первом этапе нам дали всего 12 тачек. Нужно было на них залить, чтобы освободить следующие. Если же потом расширять этот кластер, то пришлось бы балансировать все, а на гигабитной сетке это было бы ещё недели ожидания.
у ногих есть вопросы к автору
Под требования подходят Debian и Suse. У Suse более гибкий установщик, позволяющий отключить любой пакет; к сожалению, я не смог понять, какие можно выкинуть без ущерба для системы. Ставим Debian через debootstrap buster. Опция min-base устанавливает нерабочую систему, в которой не хватает драйверов.
дальше можно не читать. Это не опыт эксплуатации. Извините.
А теперь пару пунктов:
* 2 сервера для 2 копий это мало. Работать будет, но не очень хорошо. Нужно минимум 3 хоста. Тогда не будет потери данных.
* Без NVMe для журналов работать будет, но очень медленно.
Так что, если у вас кластер из 4х NVMe SSD то и двух адаптеров по 40GbE может быть мало.
Мне вас больно читать. С появлением bluestore использовать btrfs стало ещё более bleeding edge чем было. Не надо вам файловой системы. Совсем не надо. А надо LVM и bluestore.
> cat /var/lib/ceph/osd/ceph-0/type
bluestore
btrfs только под системные файлы. А с какой целью OSD использует LVM я пока не понял.
Ох… Настолько не знать цеф… Как вы думаете, где у вас хранится rocksdb?
В моём случае создано только основное устройство, поэтому rocksdb хранится на нём.
# file /var/lib/ceph/osd/ceph-0/block
/var/lib/ceph/osd/ceph-0/block: symbolic link to /dev/disk/by-partuuid/d8cc3da6-02
# file /dev/disk/by-partuuid/d8cc3da6-02
/dev/disk/by-partuuid/d8cc3da6-02: symbolic link to ../../sdb2
# file /dev/sdb2 -s
/dev/sdb2: data
В чём я ошибся?
Из вашего описания я не понял, что вы используете отдельное устройство, я думал, что вы испольузете btrfs в режиме filestore.
LVM ставится как зависимость для ceph-osd, потому что использование LVM вместо gpt для разметки физического диска — это сейчас самый продакшен-вариант для Ceph'а.
получается установить lvm только в раздел диска.
loop1
`-loop1p1part
`-ceph--7e5c2d8a…
Иначе возникает ошибка --> RuntimeError: Cannot use device (/dev/loop1). A vg/lv path or an existing device is needed
При ручной разметке диска в lmv проблем не возникает.
В той же инструкции в разделе «длинный путь», используется xfs и ссылка на блочное устройство.
Какую цель преследует продакшн-вариант: предполагается изменять на ходу размеры osd или размазывать на несколько дисков?
Какую цель преследует продакшн-вариант: предполагается изменять на ходу размеры osd или размазывать на несколько дисков?
Никакой из них:
предполагается изменять на ходу размеры osdозначает постоянную перебалансировку кластера.
размазывать на несколько дисков
означает постоянную перебалансировку кластера и падение производительности на уровне OSD.
А вы не используйте loop. Если у вас нет лишних дисков, сделайте файлы и экспортируйте по iscsi, а потом примонтируйте обратно. У вас появятся честные /dev/sda, sdb и т.д. и ceph-ansible (надеюсь, вы им делали?) сможет всё подцепить как надо.
LVM нужен для того, чтобы не страдать разделами. VG всегда можно deactivate. Удалить же /dev/sda1 если у вас enclosure неудачно переподкнула диск из-за таймаутов без ребута сервера будет невозможно.
… А ещё, если вы всё-таки взорвали кластер сожрав всё-всё-всё место и у вас ceph-osd не может стартануть, потому что нужно выделить 512кб на OSD для rocksdb, а их нет, то у вас остаётся аварийный вариант докинуть места в VG. А вот если у вас partition или полный диск, то ой.
Короче, в продакшене надо использовать LVM.
Удалить же /dev/sda1 если у вас enclosure неудачно переподкнула диск из-за таймаутов без ребута сервера будет невозможно.
вроде ж через dmsetup можно?
Однажды пришлось использовать, когда отключили ISCSI LUN +multipath. Диски давно отключены, multipath перезапущен и никого не видит, а lsblk показывает один оставшийся диск из 4 из отключенного lun.
Опыт эксплуатации CEPH