Коли даних стає більше, ніж влазить на один диск, саме час подумати про RAID. У дитинстві часто чув від старших: «якось RAID відійдуть у минуле, об'єктні сховища заполонять світ, а ти навіть не знаєш, що таке CEPH», тому першим ділом у самостійному житті стало створення свого кластера. Метою експерименту було ознайомитися з внутрішнім пристроєм ceph та зрозуміти рамки його застосування. Наскільки виправдано впровадження ceph у середній бізнес, а у малий? Після кількох років експлуатації та пари незворотних втрат даних виникло розуміння тонкощів, що не так однозначно. Особливості CEPH створюють перешкоди його широкому поширенню, і через них експерименти зайшли в глухий кут. Нижче наводиться опис всіх пройдених кроків, отриманий результат та зроблені висновки. Якщо знаючі люди поділяться досвідом і пояснять деякі моменти, буду вдячний.
Примітка: коментарі вказали на серйозні помилки в деяких припущеннях, які вимагають перегляду всієї статті.
Стратегія CEPH
Кластер CEPH поєднує довільну кількість K дисків довільного розміру та зберігає дані на них, дублюючи кожен шматочок (4 МБ за замовчуванням) задане число N разів.
Розглянемо найпростіший випадок із двома однаковими дисками. З них можна або зібрати RAID 1, або кластер з N = 2 - результат вийде той самий. Якщо дисків три, і вони різного розміру, то зібрати кластер з N=2 легко: частина даних будуть на дисках 1 і 2, частина - на 1 і 3, а частина - на 2 і 3, тоді як RAID - ні (можна зібрати такий RAID, але це буде збоченням). Якщо дисків ще більше, то можливе створення RAID 5, CEPH має аналог — erasure_code, який суперечить раннім концепціям розробників, і тому не розглядається. RAID 5 передбачає, що є невелика кількість дисків і всі вони в хорошому стані. При відмові одного, інші повинні протриматися доти, доки не замінять диск і не будуть відновлені на нього дані. CEPH ж, при N>=3, заохочує використання старих дисків, зокрема, якщо тримати кілька хороших дисків для зберігання однієї копії даних, а дві-три копії, що залишилися, зберігати на великій кількості старих дисків, то інформація буде в безпеці, так як поки живі нові диски — проблем немає, а якщо один із них зламається, то одночасна відмова трьох дисків із терміном служби понад п'ять років, бажано, з різних серверів — подія вкрай малоймовірна.
У розподілі копій є тонкість. За замовчуванням мається на увазі, що дані поділяються на більше (по 100 на диск) груп розподілу PG, кожна з яких дублюється на якихось дисках. Припустимо, K = 6, N = 2, тоді при виході з ладу двох будь-яких дисків, гарантовано губляться дані, так як за теорією ймовірності, знайдеться хоча б одна PG, яка розташується саме на цих двох дисках. А втрата однієї групи унеможливлює всі дані в пулі. Якщо ж диски розбити на три пари і дозволити зберігати дані тільки на дисках всередині однієї пари, то такий розподіл також стійкий до відмови одного будь-якого диска, зате при відмові двох ймовірність втрати даних не 100%, а всього 3/15, і навіть при відмові трьох дисків – лише 12/20. Звідси, ентропія у розподілі даних сприяє відмовостійкості. Також зауважимо, що для файлового сервера вільна оперативна пам'ять значно збільшує швидкість відгуку. Чим більше пам'яті у кожному вузлі, і що більше пам'яті у всіх вузлах — то швидше. Це безперечно перевага кластера перед одиночним сервером і, тим більше, апаратним NAS-ом, куди вбудовують дуже малий обсяг пам'яті.
Звідси випливає, що CEPH - хороший спосіб з мінімальними вкладеннями зі застарілого обладнання створити надійну систему зберігання даних на десятки ТБ з можливістю масштабування (тут, звичайно, будуть потрібні витрати, але невеликі в порівнянні з комерційними СГД).
Реалізація кластера
Для експерименту візьмемо списаний комп'ютер Intel DQ57 + Intel core i3 540 + 16 ГБ ОЗУ. Чотири диски по 2 ТБ організуємо на зразок RAID10, після успішного випробування додамо другий вузол і ще стільки ж дисків.
Встановлюємо Linux. Від дистрибутива потрібна можливість кастомізації та стабільність. Під вимоги підходять Debian та Suse. У Suse більш гнучкий установник, що дозволяє відключити будь-який пакет; на жаль, я не зміг зрозуміти, які можна викинути без шкоди для системи. Ставимо Debian через debootstrap buster. Опція min-base встановлює неробочу систему, де бракує драйверів. Різниця в розмірі в порівнянні з повною версією не така велика, щоб морочитися. Оскільки робота ведеться фізичною машиною, хочеться робити снапшоти, як у віртуалках. Таку можливість надає або LVM, або btrfs (або xfs або zfs — різниця не велика). У LVM снапшоти – не сильна сторона. Ставимо btrfs. І завантажувач – у MBR. Немає сенсу засмічувати диск 50 МБ розділом із FAT, коли можна заштовхати його в 1 МБ область таблиці розділів і весь простір виділити під систему. Зайняло на диску 700 МБ. Скільки у базової установки SUSE не запам'ятав, здається, близько 1.1 або 1.4 ГБ.
Встановлюємо CEPH. Ігноруємо версію 12 у репозиторії debian та підключаємо прямо з сайту 15.2.3. Дотримуйтесь інструкцій з розділу «встановлюємо CEPH вручну» з наступними застереженнями:
- Перед підключенням репозиторію необхідно встановити gnupg wget ca-certificates
- Після підключення репозиторію, але перед встановленням кластера опущена установка пакетів: apt -y —no-install-recommends ceph-common
- У момент встановлення CEPH з незрозумілих причин намагатиметься встановити lvm2. В принципі, не шкода, але установка завершується збоєм, тому CEPH також не встановиться.
Допоміг цей патч:
cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <[email protected]> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Огляд кластера
ceph-osd – відповідає за зберігання даних на диску. Для кожного диска запускається мережна служба, яка приймає та виконує запити на читання чи запис до об'єктів. На диску створюється два розділи. Один з них містить інформацію про кластер, номер диска, а також ключі від кластера. Ця інформація об'ємом 1КБ створюється один раз при додаванні диска і більше ніколи не помічав, щоб змінювалася. На другому розділі немає файлової системи та зберігаються двійкові дані CEPH. Автоматична установка у попередніх версіях створювала xfs розділ розміром 100МБ для службової інформації. Я сконвертував диск у MBR і виділив всього на 16МБ – служба не скаржиться. Думаю, без проблем xfs можна було б замінити на ext. Цей розділ монтується в /var/lib/…, де служба зчитує інформацію про OSD, а також знаходить посилання на блоковий пристрій, де зберігаються двійкові дані. Теоретично, можна відразу допоміжні розмістити в /var/lib/…, а диск повністю виділити під дані. При створенні OSD через ceph-deploy автоматично створюється правило для монтування розділу /var/lib/…, а також призначаються права користувачеві ceph на читання потрібного блокового пристрою. При ручній установці це необхідно зробити самому, документації про це не сказано. Також бажано вказати параметр osd memory target щоб вистачило фізичної пам'яті.
ceph-mds. На низькому рівні CEPH – об'єктне сховище. Можливість блокового зберігання зводиться до збереження кожного блоку 4МБ у вигляді об'єкта. За тим же принципом працює файлове зберігання. Створюється два пули: один для метаданих, інший - для даних. Вони об'єднуються у файлову систему. У цей момент створюється якийсь запис, тому якщо видалити файлову систему, але зберегти обидва пули, то відновити її не вийде. Є процедура вилучення файлів по блоках, не тестував. За доступ до файлової системи відповідає служба ceph-mds. Для кожної файлової системи потрібний окремий екземпляр служби. Є опція «індекс», яка дозволяє створити подібність кількох файлових систем в одній – також не тестувалося.
сeph-mon – ця служба зберігає карту кластера. До неї входить інформація про всі OSD, алгоритм розподілу PG в OSD і, найголовніше, інформація про всі об'єкти (деталі цього механізму мені незрозумілі: є каталог /var/lib/ceph/mon/…/store.db, у ньому лежить великий файл - 26МБ, а в кластері 105К об'єктів, виходить трохи більше 256 байт на об'єкт, - я думаю, що монітор зберігає список всіх об'єктів та PG, в яких вони лежать). Пошкодження цього каталогу призводить до втрати всіх даних у кластері. Звідси і зроблено висновок, що CRUSH показує як PG розташовані OSD, а як об'єкти розташовані по PG - централізовано зберігаються всередині бази даних, як би розробники не уникали цього слова. Як наслідок, по-перше, ми не можемо встановити систему на флешку в режимі RO, так як в базу даних ведеться постійний запис, необхідний додатковий диск під ці (навряд чи більше 1 ГБ), по-друге, необхідно в реальному часі мати копію цієї бази. Якщо моніторів кілька, то стійкість до відмов забезпечується автоматично, але в нашому випадку монітор один, максимум - два. Є теоретична процедура відновлення монітора на основі даних OSD, що тричі вдавався до неї з різних причин, і тричі ніяких повідомлень про помилки, як і даних теж. На жаль, цей механізм не працює. Або ми експлуатуємо мініатюрний розділ на OSD і збираємо RAID для зберігання бази даних, що напевно дуже погано позначиться на продуктивності, або виділяємо хоча б два надійні фізичні носії, бажано USB, щоб порти не займати.
rados-gw - експортує об'єктне сховище за протоколом S3 та подібні. Створює безліч пулів, незрозуміло навіщо. Особливо не експериментував.
ceph-mgr — під час встановлення цієї служби запускаються кілька модулів. Один з них - не відключається autoscale. Він прагне підтримувати правильну кількість PG/OSD. За бажанням керувати співвідношенням вручну, можна заборонити масштабування для кожного пулу, але в такому випадку модуль падає з розподілом на 0, і статус кластера стає ERROR. Модуль написаний на пітоні, і якщо закоментувати в ньому потрібний рядок, це призводить до його відключення. Деталі ліньки згадувати.
Список використаних джерел:
Лістинги скриптів:
Встановлення системи через debootstrap
blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/
chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d """ -f 2`
cat << EOF > /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat << EOF >> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6
apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6Створення кластера
apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon
echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat << EOF > /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
#osd memory target = 2147483648
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF
ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status
# dashboard
apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1Додавання OSD (частина)
apt install ceph-osd
osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02 block
ceph-osd -i $osdnum --mkfs
#chown ceph:ceph /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnumРезюме
Головна маркетингова перевага CEPH – це CRUSH – алгоритм обчислення розташування даних. Монітори поширюють клієнтам цей алгоритм, після чого клієнти запитують потрібний вузол і потрібний OSD. CRUSH забезпечує відсутність централізації. Він є маленьким файлом, який можна хоч роздрукувати і повісити на стіну. Практика показала, що CRUSH не є вичерпною карткою. Якщо знищити і заново створити монітори, зберігши всі OSD і CRUSH, цього недостатньо відновлення кластера. Звідси зроблено висновок, що на кожному моніторі зберігаються деякі метадані про весь кластер. Незначний обсяг цих метаданих не накладає обмежень розмір кластера, але вимагає забезпечити їх збереження, що виключає економію диска рахунок установки системи на флешку і виключає кластери з менш, ніж трьома вузлами. Агресивна політика розробника щодо опціональних фіч. Далеко до мінімалізму. Документація на рівні: «за те, що є, вже дякую, але дуже, дуже мізерно». Можливість взаємодії зі службами на низькому рівні передбачена, але документація надто поверхово стосується цієї теми, тому скоріше ні, ніж так. Практично жодних шансів на відновлення даних із позаштатної ситуації.
Варіанти подальших дій: відмовитися від CEPH та скористатися банальним багатодисковим btrfs (або xfs, zfs), дізнатися нову інформацію про CEPH, яка дозволить експлуатувати його у зазначених умовах, спробувати як підвищення кваліфікації написати власне сховище.
Джерело: habr.com