Калі дадзеных становіцца больш, чым залазіць на адзін дыск, самы час задумацца аб 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 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 МБ падзелам з FAT, калі можна заштурхаць яго ў 1 МБ вобласць табліцы частак і ўсю прастору вылучыць пад сістэму. Заняло на кружэлцы 700 МБ. Колькі ў базавай усталёўкі SUSE - не запомніў, здаецца, каля 1.1 або 1.4 ГБ.
Усталёўваны CEPH. Ігнаруем версію 12 у рэпазітары debian і падлучальны прама з сайта 15.2.3. Прытрымліваемся інструкцыі з падзелу «ўсталёўваны CEPH уручную» з наступнымі агаворкамі:
- Перад падлучэннем рэпазітара неабходна ўсталяваць gnupg wget ca-certificates
- Пасля падлучэння рэпазітара, але перад усталёўкай кластара апушчана ўсталёўка пакетаў: apt -y -no-install-recommends install
- У момант усталёўкі 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