Когато данните станат повече, отколкото побира един диск, е време да се замислим за RAID. В детството често чувах от възрастните: „един ден RAID ще изчезне, обектните хранилища ще завладеят света, а ти дори не знаеш какво е CEPH“ - затова първото нещо, което направих в самостоятелния си живот, беше да създам свой кластер. Целта на експеримента беше да се запозная с вътрешната структура на ceph и да разбера рамките на приложението му. Колко оправдано е внедряването на ceph в средния и малкия бизнес? След няколко години експлоатация и няколко необратими загуби на данни, се появи разбиране за нюансите, че не всичко е толкова ясно. Особеностите на CEPH създават пречки за широкото му разпространение, и заради тях експериментите стигнаха до задънена улица. По-долу е описано всичко, което преминах, получените резултати и направените заключения. Ще съм благодарен, ако знаещи хора споделят опит и разяснят някои моменти.
Забележка: коментаторите посочиха сериозни грешки в някои предположения, изискващи преразглеждане на цялата статия.
Стратегия CEPH
Кластерът CEPH обединява произволен брой K дискове с произволен размер и съхранява данни на тях, дублирайки всеки фрагмент (4 MB по подразбиране) зададен брой 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 DQ57TM + Intel core i3 540 + 16 ГБ ОП. Четири диска по 2 ТБ организираме в подобие на RAID10, след успешно изпитание ще добавим втори възел и още толкова диска.
Инсталираме Linux. Из дистрибуцията се изисква възможност за персонализация и стабилност. Debian и Suse отговарят на тези изисквания. Suse предлага по-гъвкав инсталатор, който позволява деактивирането на всякакви пакети; за съжаление, не успях да разбера кои могат да бъдат премахнати без вреда за системата. Инсталираме Debian чрез debootstrap buster. Опцията min-base инсталира неработеща система, в която липсват драйвери. Разликата в размера спрямо пълната версия не е толкова голяма, че да си заслужава усилието. Тъй като работата се извършва на физическа машина, бихме искали да правим снимки, както на виртуални машини. Тази възможност предоставя или LVM, или btrfs (или xfs, или zfs — разликата не е голяма). При LVM снимките не са силна страна. Инсталираме btrfs. И заредителя — в MBR. Няма смисъл да запълваме диска с 50 MB раздел FAT, когато можем да го вместим в 1 MB пространство в таблицата на разделите и всичкото пространство да е отделено за системата. Занимава 700 MB на диска. Не запомних колко е за базовата инсталация на SUSE — мисля, че беше около 1.1 или 1.4 GB.
Инсталираме CEPH. Игнорираме версия 12 в репозиторията на debian и се свързваме директно със сайта за 15.2.3. Следваме инструкциите от раздела „инсталираме CEPH ръчно“ с следните уточнения:
- Преди да свържете репозитория, е необходимо да инсталирате gnupg wget ca-certificates
- След свързването на репозитория, но преди инсталирането на клъстера, пропусната е инсталацията на пакетите: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- В момента на инсталиране на CEPH, по непонятни причини ще се опита да се инсталира lvm2. По принцип не ми е жал, но инсталацията завършва с грешка, така че CEPH също няма да се инсталира.
Този патч помогна:
cat <> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers 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. За всяка файлова система е необходим отделен екземпляр на услугата. Има опция „индекс“, която позволява да се създаде подобие на няколко файлови системи в една — също не е тествана.
ceph-mon — тази услуга съхранява картата на клъстера. В нея влиза информация за всички OSD, алгоритъм за разпределение на PG в OSD и, най-важното, информация за всички обекти (детайлите на този механизъм ми не са ясни: има каталог /var/lib/ceph/mon/.../store.db, в него се съдържа голям файл — 26MB, а в клъстера 105K обекта, което означава малко над 256 байта на обект. Смятам, че мониторът съхранява списък на всички обекти и PG, в които те са разположени). Повреждането на този каталог води до загуба на всички данни в клъстера. Оттук следва, че CRUSH показва как PG са разположени по OSD, а как обектите са разположени по PG — централизирано се съхраняват вътре в базата данни, каквото и да правят разработчиците, за да избегнат тази терминология. Следователно, на първо място, не можем да инсталираме системата на флашка в режим RO, тъй като в базата данни се извършва постоянно записване, необходим е допълнителен диск за тези нужди (вряд ли повече от 1GB); на второ място, е необходимо в реално време да имаме копие на тази база. Ако мониторите са няколко, отказоустойчивостта се осигурява автоматично, но в нашия случай мониторът е един, максимум — два. Има теоретична процедура за възстановяване на монитора на базата на данните от OSD, прибягвал съм до нея три пъти по различни причини, и трите пъти без никакви съобщения за грешки, както и без данни. За съжаление, този механизъм не работи. Или експлоатираме миниатюрен дял на OSD и събираме RAID за съхранение на базата данни, което определено ще доведе до влошаване на производителността, или отделяме поне два надеждни физически носителя, предпочитано USB, за да не заемат портове.
rados-gw — експортира обектно хранилище по протокол S3 и подобни. Създава множество пулове, не е ясно защо. Не съм експериментирал особено.
ceph-mgr — при инсталирането на тази услуга се активират няколко модула. Един от тях е неизключваемият autoscale. Той се стреми да поддържа правилното количество PG/OSD. Ако желаете да управлявате съотношението ръчно, можете да забраните мащабирането за всеки пул, но в такъв случай модулът пада с деление на 0, и статусът на клъстера става ERROR. Модулът е написан на Python, и ако коментирате необходимия ред в него, това води до деактивирането му. Не ми се занимава с детайлите.
Списък на използваните източници:
Изброяване на скриптове:
Инсталиране на системата чрез 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 < /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 <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers
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
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 < /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
