Опит с CEPH

Когато има повече данни, отколкото могат да се поберат на един диск, е време да помислите за 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. Следователно ентропията в разпространението на данни не допринася за толерантността към грешки. Също така имайте предвид, че за файлов сървър свободната RAM значително увеличава скоростта на реакция. Колкото повече памет във всеки възел и колкото повече памет във всички възли, толкова по-бързо ще бъде. Това несъмнено е предимство на клъстер пред единичен сървър и още повече хардуерен NAS, където е вградено много малко количество памет.

От това следва, че CEPH е добър начин за създаване на надеждна система за съхранение на данни за десетки TB с възможност за мащабиране с минимални инвестиции от остаряло оборудване (тук, разбира се, ще са необходими разходи, но малки в сравнение с търговските системи за съхранение).

Реализация на клъстер

За експеримента нека вземем изведен от употреба компютър Intel DQ57TM + Intel core i3 540 + 16 GB RAM. Ще организираме четири 2 TB диска в нещо като 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-сертификати
• След свързване на хранилището, но преди инсталирането на клъстера, инсталирането на пакети е пропуснато: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• При инсталиране на 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 - отговаря за съхраняването на данни на диска. За всеки диск се стартира мрежова услуга, която приема и изпълнява заявки за четене или запис на обекти. На диска се създават два дяла. Един от тях съдържа информация за клъстера, номер на диска и ключове към клъстера. Тази информация от 1KB се създава веднъж при добавяне на диск и никога не е забелязвана промяна. Вторият дял няма файлова система и съхранява CEPH двоични данни. Автоматичната инсталация в предишни версии създаде 100MB xfs дял за сервизна информация. Преобразувах диска в MBR и разпределих само 16MB - услугата не се оплаква. Мисля, че xfs може да се замени с ext без проблеми. Този дял е монтиран в /var/lib/…, където услугата чете информация за екранното меню и също намира препратка към блоковото устройство, където се съхраняват двоичните данни. Теоретично можете незабавно да поставите помощни файлове в /var/lib/… и да разпределите целия диск за данни. Когато създавате OSD чрез ceph-deploy, автоматично се създава правило за монтиране на дяла в /var/lib/… и на потребителя на ceph също се присвояват права за четене на желаното блоково устройство. Ако инсталирате ръчно, трябва да направите това сами; документацията не казва това. Също така е препоръчително да посочите целевия параметър за паметта на osd, така че да има достатъчно физическа памет.

ceph-mds. На ниско ниво CEPH е обектно съхранение. Възможността за съхранение на блокове се свежда до съхраняване на всеки 4MB блок като обект. Съхранението на файлове работи на същия принцип. Създават се два пула: единият за метаданни, другият за данни. Те са обединени във файлова система. В този момент се създава някакъв вид запис, така че ако изтриете файловата система, но запазите и двата пула, няма да можете да го възстановите. Има процедура за извличане на файлове по блокове, не съм я тествал. Услугата ceph-mds отговаря за достъпа до файловата система. Всяка файлова система изисква отделен екземпляр на услугата. Има опция „индекс“, която ви позволява да създадете подобие на няколко файлови системи в една - също не е тествано.

Ceph-mon - Тази услуга съхранява карта на клъстера. Той включва информация за всички OSD, алгоритъм за разпространение на PG в OSD и, най-важното, информация за всички обекти (подробностите на този механизъм не са ми ясни: има директория /var/lib/ceph/mon/…/ store.db, той съдържа голям файлът е 26MB, а в клъстер от 105K обекта се оказва, че са малко над 256 байта на обект - мисля, че мониторът съхранява списък на всички обекти и PG, в които те се намират). Повредата на тази директория води до загуба на всички данни в клъстера. Оттук се стигна до заключението, че CRUSH показва как са разположени PG на OSD и как са разположени обектите на PG - те се съхраняват централно в базата данни, колкото и разработчиците да избягват тази дума. В резултат на това, първо, не можем да инсталираме системата на флашка в режим RO, тъй като базата данни се записва постоянно, за тях е необходим допълнителен диск (едва ли повече от 1 GB), второ, необходимо е да има копирайте в реално време тази база. Ако има няколко монитора, толерантността към грешки се осигурява автоматично, но в нашия случай има само един монитор, максимум два. Има теоретична процедура за възстановяване на монитор въз основа на OSD данни, прибягнах до нея три пъти по различни причини и три пъти нямаше съобщения за грешка, както и никакви данни. За съжаление този механизъм не работи. Или управляваме миниатюрен дял на OSD и сглобяваме RAID за съхранение на базата данни, което със сигурност ще има много лош ефект върху производителността, или разпределяме поне два надеждни физически носителя, за предпочитане USB, за да не заемат портове.

rados-gw - експортира съхранение на обекти чрез протокола S3 и други подобни. Създава много пулове, неясно защо. Не експериментирах много.

ceph-mgr - При инсталиране на тази услуга се стартират няколко модула. Един от тях е автоматичното мащабиране, което не може да бъде деактивирано. Стреми се да поддържа правилното количество PG/OSD. Ако искате да контролирате съотношението ръчно, можете да деактивирате мащабирането за всеки пул, но в този случай модулът се срива с деление на 0 и състоянието на клъстера става ГРЕШКА. Модулът е написан на Python и ако коментирате необходимия ред в него, това води до дезактивирането му. Твърде мързелив, за да си спомня подробностите.

Списък на използваните източници:

Инсталиране на CEPH
Възстановяване след пълна повреда на монитора

Списъци със скриптове:

Инсталиране на системата чрез 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, която ще ви позволи да го управлявате при определени условия, опитайте се да напишете собственото си хранилище като разширено обучение.

Източник: www.habr.com