karanasan sa pagpapatakbo ng CEPH

Kapag mayroong mas maraming data kaysa sa maaaring magkasya sa isang disk, oras na upang isipin ang tungkol sa RAID. Bilang isang bata, madalas kong marinig mula sa aking mga nakatatanda: "isang araw ang RAID ay magiging isang bagay ng nakaraan, ang pag-iimbak ng bagay ay pupunuin ang mundo, at hindi mo alam kung ano ang CEPH," kaya ang unang bagay sa aking malayang buhay ay gumawa ng sarili kong cluster. Ang layunin ng eksperimento ay upang makilala ang panloob na istraktura ng ceph at maunawaan ang saklaw ng aplikasyon nito. Gaano katuwiran ang pagpapatupad ng ceph sa mga medium-sized na negosyo at sa mga maliliit? Matapos ang ilang taon ng operasyon at ilang hindi maibabalik na pagkawala ng data, isang pag-unawa sa mga intricacies ang lumitaw na hindi lahat ay napakasimple. Ang mga kakaibang katangian ng CEPH ay nagdudulot ng mga hadlang sa malawakang pag-aampon nito, at dahil sa mga ito, ang mga eksperimento ay umabot sa isang dead end. Nasa ibaba ang isang paglalarawan ng lahat ng mga hakbang na ginawa, ang resulta na nakuha at ang mga konklusyon na ginawa. Kung ang mga taong may kaalaman ay nagbabahagi ng kanilang karanasan at nagpapaliwanag ng ilang mga punto, ako ay magpapasalamat.

Tandaan: Natukoy ng mga nagkokomento ang mga mabibigat na pagkakamali sa ilan sa mga pagpapalagay na nangangailangan ng rebisyon ng buong artikulo.

Estratehiya ng CEPH

Pinagsasama ng CEPH cluster ang isang di-makatwirang numero K ng mga disk na may di-makatwirang laki at nag-iimbak ng data sa mga ito, na nagdo-duplicate sa bawat piraso (4 MB bilang default) sa isang naibigay na numero ng N beses.

Isaalang-alang natin ang pinakasimpleng kaso na may dalawang magkaparehong disk. Mula sa kanila maaari kang mag-ipon ng RAID 1 o isang kumpol na may N=2 - ang resulta ay magiging pareho. Kung mayroong tatlong mga disk at ang mga ito ay may iba't ibang laki, kung gayon madaling mag-ipon ng isang kumpol na may N=2: ang ilan sa mga data ay nasa disk 1 at 2, ang ilan ay nasa disk 1 at 3, at ang ilan ay magiging sa 2 at 3, habang ang RAID ay hindi (maaari kang mag-ipon ng gayong RAID, ngunit ito ay isang perversion). Kung mayroong higit pang mga disk, posible na lumikha ng RAID 5; Ang CEPH ay may isang analogue - erasure_code, na sumasalungat sa mga unang konsepto ng mga developer, at samakatuwid ay hindi isinasaalang-alang. Ipinapalagay ng RAID 5 na mayroong maliit na bilang ng mga drive, na lahat ay nasa mabuting kondisyon. Kung ang isa ay nabigo, ang iba ay dapat manatili hanggang sa ang disk ay mapalitan at ang data ay maibalik dito. Ang CEPH, na may N>=3, ay hinihikayat ang paggamit ng mga lumang disk, lalo na, kung nagpapanatili ka ng maraming magagandang disk upang mag-imbak ng isang kopya ng data, at mag-imbak ng natitirang dalawa o tatlong kopya sa isang malaking bilang ng mga lumang disk, pagkatapos ay ang impormasyon ay magiging ligtas, dahil sa ngayon ang mga bagong disk ay buhay - walang mga problema, at kung ang isa sa mga ito ay masira, kung gayon ang sabay-sabay na pagkabigo ng tatlong mga disk na may buhay ng serbisyo na higit sa limang taon, mas mabuti mula sa iba't ibang mga server, ay isang lubhang hindi malamang. kaganapan.

May kapitaganan ang pamamahagi ng mga kopya. Bilang default, ipinapalagay na ang data ay nahahati sa higit (~100 bawat disk) na mga grupo ng pamamahagi ng PG, na ang bawat isa ay nadoble sa ilang mga disk. Sabihin nating K=6, N=2, at kung may dalawang disk na mabigo, ang data ay garantisadong mawawala, dahil ayon sa probability theory, magkakaroon ng kahit isang PG na makikita sa dalawang disk na ito. At ang pagkawala ng isang grupo ay ginagawang hindi available ang lahat ng data sa pool. Kung ang mga disk ay nahahati sa tatlong pares at ang data ay pinapayagan na maimbak lamang sa mga disk sa loob ng isang pares, kung gayon ang pamamahagi na ito ay lumalaban din sa pagkabigo ng alinman sa isang disk, ngunit kung ang dalawang disk ay nabigo, ang posibilidad ng pagkawala ng data ay hindi 100 %, ngunit 3/15 lamang, at kahit na sa kaso ng pagkabigo tatlong disk - 12/20 lamang. Samakatuwid, ang entropy sa pamamahagi ng data ay hindi nakakatulong sa fault tolerance. Tandaan din na para sa isang file server, ang libreng RAM ay makabuluhang pinatataas ang bilis ng pagtugon. Kung mas maraming memory sa bawat node, at mas maraming memory sa lahat ng node, mas magiging mabilis ito. Ito ay walang alinlangan na isang bentahe ng isang kumpol sa isang solong server at, higit pa, isang hardware NAS, kung saan ang isang napakaliit na halaga ng memorya ay naka-built in.

Sinusunod nito na ang CEPH ay isang mahusay na paraan upang lumikha ng isang maaasahang sistema ng pag-iimbak ng data para sa sampu-sampung TB na may kakayahang mag-scale na may kaunting pamumuhunan mula sa lumang kagamitan (dito, siyempre, kakailanganin ang mga gastos, ngunit maliit kumpara sa mga komersyal na sistema ng imbakan).

Pagpapatupad ng cluster

Para sa eksperimento, kumuha tayo ng isang naka-decommission na computer na Intel DQ57TM + Intel core i3 540 + 16 GB ng RAM. Aayusin namin ang apat na 2 TB disk sa isang bagay tulad ng RAID10, pagkatapos ng matagumpay na pagsubok ay magdaragdag kami ng pangalawang node at ang parehong bilang ng mga disk.

Pag-install ng Linux. Ang pamamahagi ay nangangailangan ng kakayahang mag-customize at maging matatag. Natutugunan nina Debian at Suse ang mga kinakailangan. Ang Suse ay may mas nababaluktot na installer na nagbibigay-daan sa iyong i-disable ang anumang package; Sa kasamaang palad, hindi ko maisip kung alin ang maaaring itapon nang hindi nasisira ang sistema. I-install ang Debian gamit ang debootstrap buster. Ang opsyon na min-base ay nag-i-install ng sirang sistema na walang mga driver. Ang pagkakaiba sa laki kumpara sa buong bersyon ay hindi ganoon kalaki para mag-abala. Dahil ang gawain ay isinasagawa sa isang pisikal na makina, gusto kong kumuha ng mga snapshot, tulad ng sa mga virtual machine. Ang pagpipiliang ito ay ibinibigay ng alinman sa LVM o btrfs (o xfs, o zfs - ang pagkakaiba ay hindi malaki). Ang mga snapshot ng LVM ay hindi isang malakas na punto. I-install ang btrfs. At ang bootloader ay nasa MBR. Walang punto sa pag-cluttering ng 50 MB disk na may FAT partition kapag maaari mo itong itulak sa isang 1 MB partition table area at ilaan ang lahat ng espasyo para sa system. Kumuha ng 700 MB sa disk. Hindi ko maalala kung magkano ang pangunahing pag-install ng SUSE, sa tingin ko ito ay tungkol sa 1.1 o 1.4 GB.

I-install ang CEPH. Hindi namin binabalewala ang bersyon 12 sa debian repository at direktang kumonekta mula sa 15.2.3 site. Sinusunod namin ang mga tagubilin mula sa seksyong "Manu-manong i-install ang CEPH" kasama ang mga sumusunod na caveat:

• Bago ikonekta ang repositoryo, dapat mong i-install ang gnupg wget ca-certificates
• Pagkatapos ikonekta ang repository, ngunit bago i-install ang cluster, ang pag-install ng mga package ay tinanggal: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• Kapag nag-i-install ng CEPH, para sa hindi kilalang dahilan, susubukan nitong i-install ang lvm2. Sa prinsipyo, hindi ito isang awa, ngunit nabigo ang pag-install, kaya hindi rin mag-i-install ang CEPH.

  Nakatulong ang patch na ito:

  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
  

Pangkalahatang-ideya ng cluster

ceph-osd - ay responsable para sa pag-iimbak ng data sa disk. Para sa bawat disk, isang serbisyo sa network ang inilunsad na tumatanggap at nagsasagawa ng mga kahilingang magbasa o magsulat sa mga bagay. Dalawang partisyon ang nilikha sa disk. Ang isa sa mga ito ay naglalaman ng impormasyon tungkol sa kumpol, numero ng disk, at mga susi sa kumpol. Ang 1KB na impormasyong ito ay nilikha nang isang beses kapag nagdadagdag ng disk at hindi kailanman napansing nagbago. Ang pangalawang partition ay walang file system at nag-iimbak ng CEPH binary data. Ang awtomatikong pag-install sa mga nakaraang bersyon ay lumikha ng 100MB xfs partition para sa impormasyon ng serbisyo. Na-convert ko ang disk sa MBR at naglaan lamang ng 16MB - hindi nagrereklamo ang serbisyo. Sa tingin ko ang xfs ay maaaring mapalitan ng ext nang walang anumang problema. Naka-mount ang partition na ito sa /var/lib/…, kung saan nagbabasa ang serbisyo ng impormasyon tungkol sa OSD at nakakahanap din ng reference sa block device kung saan naka-imbak ang binary data. Sa teorya, maaari mong agad na ilagay ang mga auxiliary file sa /var/lib/…, at ilaan ang buong disk para sa data. Kapag gumagawa ng OSD sa pamamagitan ng ceph-deploy, awtomatikong nagagawa ang isang panuntunan upang i-mount ang partition sa /var/lib/…, at ang user ng ceph ay binibigyan din ng mga karapatan na basahin ang gustong block device. Kung manu-mano kang mag-install, dapat mong gawin ito sa iyong sarili; hindi ito sinasabi ng dokumentasyon. Maipapayo rin na tukuyin ang osd memory target parameter upang mayroong sapat na pisikal na memorya.

ceph-mds. Sa mababang antas, ang CEPH ay imbakan ng bagay. Ang kakayahang harangan ang imbakan ay bumababa sa pag-iimbak ng bawat 4MB na bloke bilang isang bagay. Gumagana ang imbakan ng file sa parehong prinsipyo. Dalawang pool ang ginawa: isa para sa metadata, ang isa para sa data. Ang mga ito ay pinagsama sa isang file system. Sa sandaling ito, ang ilang uri ng record ay nilikha, kaya kung tatanggalin mo ang file system, ngunit panatilihin ang parehong mga pool, hindi mo ito maibabalik. Mayroong isang pamamaraan para sa pagkuha ng mga file sa pamamagitan ng mga bloke, hindi ko pa ito nasubukan. Ang serbisyo ng ceph-mds ay responsable para sa pag-access sa file system. Ang bawat file system ay nangangailangan ng isang hiwalay na halimbawa ng serbisyo. Mayroong isang "index" na opsyon, na nagbibigay-daan sa iyo upang lumikha ng pagkakahawig ng ilang mga file system sa isa - hindi rin nasubok.

Ceph-mon - Ang serbisyong ito ay nag-iimbak ng mapa ng cluster. Kabilang dito ang impormasyon tungkol sa lahat ng OSD, isang algorithm para sa pamamahagi ng mga PG sa mga OSD at, higit sa lahat, ang impormasyon tungkol sa lahat ng mga bagay (ang mga detalye ng mekanismong ito ay hindi malinaw sa akin: mayroong isang direktoryo /var/lib/ceph/mon/…/ store.db, naglalaman ito ng isang malaking file ay 26MB, at sa isang kumpol ng 105K na mga bagay, lumalabas ito na higit sa 256 byte bawat bagay - Sa tingin ko ang monitor ay nag-iimbak ng isang listahan ng lahat ng mga bagay at ang mga PG kung saan sila ay matatagpuan). Ang pinsala sa direktoryong ito ay nagreresulta sa pagkawala ng lahat ng data sa cluster. Kaya't ang konklusyon ay iginuhit na ang CRUSH ay nagpapakita kung paano matatagpuan ang mga PG sa OSD, at kung paano matatagpuan ang mga bagay sa mga PG - ang mga ito ay nasa gitnang nakaimbak sa loob ng database, gaano man ang pag-iwas ng mga developer sa salitang ito. Bilang isang resulta, una, hindi namin mai-install ang system sa isang flash drive sa RO mode, dahil ang database ay patuloy na naitala, ang isang karagdagang disk ay kinakailangan para sa mga ito (halos higit sa 1 GB), pangalawa, kinakailangan na magkaroon ng isang kopyahin sa real time ang base na ito. Kung mayroong maraming mga monitor, kung gayon ang pagpapahintulot sa kasalanan ay awtomatikong sinisiguro, ngunit sa aming kaso mayroon lamang isang monitor, maximum na dalawa. Mayroong isang teoretikal na pamamaraan para sa pagpapanumbalik ng isang monitor batay sa data ng OSD, ginamit ko ito ng tatlong beses para sa iba't ibang mga kadahilanan, at tatlong beses na walang mga mensahe ng error, pati na rin walang data. Sa kasamaang palad, ang mekanismong ito ay hindi gumagana. Alinman ay nagpapatakbo kami ng isang maliit na partisyon sa OSD at nag-assemble ng isang RAID upang maiimbak ang database, na tiyak na magkakaroon ng napakasamang epekto sa pagganap, o naglalaan kami ng hindi bababa sa dalawang maaasahang pisikal na media, mas mabuti ang USB, upang hindi sakupin ang mga port.

rados-gw - nag-e-export ng imbakan ng bagay sa pamamagitan ng S3 protocol at katulad nito. Lumilikha ng maraming pool, hindi malinaw kung bakit. Hindi ako masyadong nag-eksperimento.

ceph-mgr - Kapag ini-install ang serbisyong ito, maraming mga module ang inilunsad. Ang isa sa mga ito ay autoscale na hindi maaaring i-disable. Nagsusumikap itong mapanatili ang tamang dami ng PG/OSD. Kung gusto mong kontrolin ang ratio nang manu-mano, maaari mong huwag paganahin ang pag-scale para sa bawat pool, ngunit sa kasong ito ang module ay nag-crash na may dibisyon ng 0, at ang cluster status ay nagiging ERROR. Ang module ay nakasulat sa Python, at kung magkomento ka ng kinakailangang linya dito, hahantong ito sa hindi pagpapagana nito. Masyadong tamad na alalahanin ang mga detalye.

Listahan ng mga mapagkukunang ginamit:

Pag-install ng CEPH
Pagbawi mula sa isang kumpletong pagkabigo sa monitor

Mga listahan ng script:

Pag-install ng system sa pamamagitan ng 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

Gumawa ng cluster

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

Pagdaragdag ng OSD (bahagi)

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

Buod

Ang pangunahing bentahe sa marketing ng CEPH ay CRUSH - isang algorithm para sa pagkalkula ng lokasyon ng data. Ibinabahagi ng mga monitor ang algorithm na ito sa mga kliyente, pagkatapos ay direktang hinihiling ng mga kliyente ang nais na node at ang nais na OSD. Sinisiguro ni CRUSH na walang sentralisasyon. Ito ay isang maliit na file na maaari mo ring i-print at isabit sa dingding. Ipinakita ng pagsasanay na ang CRUSH ay hindi isang kumpletong mapa. Kung sisirain mo at muling likhain ang mga monitor, pinapanatili ang lahat ng OSD at CRUSH, hindi ito sapat upang maibalik ang kumpol. Mula dito ay napagpasyahan na ang bawat monitor ay nag-iimbak ng ilang metadata tungkol sa buong kumpol. Ang maliit na halaga ng metadata na ito ay hindi nagpapataw ng mga paghihigpit sa laki ng cluster, ngunit nangangailangan ng pagtiyak ng kanilang kaligtasan, na nag-aalis ng mga pagtitipid sa disk sa pamamagitan ng pag-install ng system sa isang flash drive at hindi kasama ang mga cluster na may mas mababa sa tatlong node. Ang agresibong patakaran ng developer tungkol sa mga opsyonal na feature. Malayo sa minimalism. Ang dokumentasyon ay nasa antas ng "salamat sa kung ano ang mayroon kami, ngunit ito ay napaka, napakakaunti." Ang kakayahang makipag-ugnayan sa mga serbisyo sa mababang antas ay ibinibigay, ngunit ang dokumentasyon ay masyadong mababaw sa paksang ito, kaya mas malamang na hindi ito kaysa sa isang oo. Halos walang pagkakataon na mabawi ang data mula sa isang emergency na sitwasyon.

Mga opsyon para sa karagdagang aksyon: abandunahin ang CEPH at gamitin ang mga banal na multi-disk btrfs (o xfs, zfs), alamin ang bagong impormasyon tungkol sa CEPH, na magpapahintulot sa iyo na patakbuhin ito sa ilalim ng tinukoy na mga kondisyon, subukang isulat ang iyong sariling imbakan bilang advanced pagsasanay.

Pinagmulan: www.habr.com