Apabila terdapat lebih banyak data daripada yang boleh dimuatkan pada satu cakera, sudah tiba masanya untuk memikirkan RAID. Sebagai seorang kanak-kanak, saya sering mendengar daripada orang tua saya: "suatu hari RAID akan menjadi perkara yang lepas, penyimpanan objek akan memenuhi dunia, dan anda tidak tahu apa itu CEPH," jadi perkara pertama dalam kehidupan bebas saya adalah untuk membuat kluster saya sendiri. Tujuan eksperimen adalah untuk membiasakan diri dengan struktur dalaman ceph dan memahami skop penggunaannya. Sejauh manakah wajar pelaksanaan ceph dalam perniagaan bersaiz sederhana dan dalam perniagaan kecil? Selepas beberapa tahun beroperasi dan beberapa kehilangan data yang tidak dapat dipulihkan, pemahaman tentang selok-belok timbul bahawa tidak semuanya begitu mudah. Keistimewaan CEPH menimbulkan halangan kepada penggunaannya yang meluas, dan kerana itu, eksperimen telah menemui jalan buntu. Di bawah adalah penerangan tentang semua langkah yang diambil, hasil yang diperoleh dan kesimpulan yang dibuat. Jika orang yang berpengetahuan berkongsi pengalaman mereka dan menerangkan beberapa perkara, saya akan berterima kasih.
Nota: Pengulas telah mengenal pasti ralat serius dalam beberapa andaian yang memerlukan semakan keseluruhan artikel.
Strategi CEPH
Kelompok CEPH menggabungkan nombor arbitrari K cakera dengan saiz arbitrari dan menyimpan data padanya, menduplikasi setiap bahagian (4 MB secara lalai) nombor yang diberikan N kali.
Mari kita pertimbangkan kes paling mudah dengan dua cakera yang sama. Daripada mereka anda boleh sama ada memasang RAID 1 atau kluster dengan N=2 - hasilnya akan sama. Jika terdapat tiga cakera dan ia mempunyai saiz yang berbeza, maka adalah mudah untuk memasang kluster dengan N=2: beberapa data akan berada pada cakera 1 dan 2, beberapa akan berada pada cakera 1 dan 3, dan beberapa akan pada 2 dan 3, manakala RAID tidak akan (anda boleh memasang RAID sedemikian, tetapi ia akan menjadi penyelewengan). Sekiranya terdapat lebih banyak cakera, maka adalah mungkin untuk mencipta RAID 5; CEPH mempunyai analog - erasure_code, yang bercanggah dengan konsep awal pembangun, dan oleh itu tidak dipertimbangkan. RAID 5 mengandaikan terdapat sebilangan kecil pemacu, semuanya berada dalam keadaan baik. Jika satu gagal, yang lain mesti bertahan sehingga cakera diganti dan data dipulihkan kepadanya. CEPH, dengan N>=3, menggalakkan penggunaan cakera lama, khususnya, jika anda menyimpan beberapa cakera yang baik untuk menyimpan satu salinan data, dan menyimpan baki dua atau tiga salinan pada sejumlah besar cakera lama, maka maklumat akan selamat, kerana buat masa ini cakera baru masih hidup - tidak ada masalah, dan jika salah satu daripadanya pecah, maka kegagalan serentak tiga cakera dengan hayat perkhidmatan lebih daripada lima tahun, sebaik-baiknya dari pelayan yang berbeza, adalah sangat tidak mungkin. peristiwa.
Terdapat kehalusan dalam pengedaran salinan. Secara lalai, adalah diandaikan bahawa data dibahagikan kepada lebih (~100 setiap cakera) kumpulan pengedaran PG, setiap satu daripadanya diduplikasi pada beberapa cakera. Katakan K=6, N=2, maka jika mana-mana dua cakera gagal, data dijamin akan hilang, kerana mengikut teori kebarangkalian, akan ada sekurang-kurangnya satu PG yang akan ditempatkan pada kedua-dua cakera ini. Dan kehilangan satu kumpulan menjadikan semua data dalam kumpulan tidak tersedia. Jika cakera dibahagikan kepada tiga pasang dan data dibenarkan disimpan hanya pada cakera dalam satu pasangan, maka pengedaran sedemikian juga tahan terhadap kegagalan mana-mana satu cakera, tetapi jika dua cakera gagal, kebarangkalian kehilangan data tidak 100%, tetapi hanya 3/15, dan walaupun dalam kes kegagalan tiga cakera - hanya 12/20. Oleh itu, entropi dalam pengedaran data tidak menyumbang kepada toleransi kesalahan. Juga ambil perhatian bahawa untuk pelayan fail, RAM percuma meningkatkan kelajuan tindak balas dengan ketara. Lebih banyak memori dalam setiap nod, dan lebih banyak memori dalam semua nod, lebih cepat ia akan berlaku. Ini sudah pasti kelebihan kluster berbanding pelayan tunggal dan, lebih-lebih lagi, NAS perkakasan, di mana jumlah memori yang sangat kecil terbina dalam.
Ini berikutan bahawa CEPH ialah cara yang baik untuk mencipta sistem storan data yang boleh dipercayai untuk puluhan TB dengan keupayaan untuk membuat skala dengan pelaburan minimum daripada peralatan lapuk (di sini, sudah tentu, kos akan diperlukan, tetapi kecil berbanding dengan sistem storan komersial).
Pelaksanaan kluster
Untuk percubaan, mari ambil komputer Intel DQ57TM + Intel core i3 540 + 16 GB RAM yang telah dinyahaktifkan. Kami akan menyusun empat cakera 2 TB menjadi sesuatu seperti RAID10, selepas ujian berjaya kami akan menambah nod kedua dan bilangan cakera yang sama.
Memasang Linux. Pengagihan memerlukan keupayaan untuk menyesuaikan dan menjadi stabil. Debian dan Suse memenuhi keperluan. Suse mempunyai pemasang yang lebih fleksibel yang membolehkan anda melumpuhkan sebarang pakej; Malangnya, saya tidak dapat mengetahui mana yang boleh dibuang tanpa merosakkan sistem. Pasang Debian menggunakan debootstrap buster. Pilihan min-base memasang sistem rosak yang tidak mempunyai pemandu. Perbezaan saiz berbanding versi penuh tidak begitu besar sehingga mengganggu. Oleh kerana kerja dijalankan pada mesin fizikal, saya ingin mengambil gambar, seperti pada mesin maya. Pilihan ini disediakan oleh sama ada LVM atau btrfs (atau xfs, atau zfs - perbezaannya tidak besar). Syot kilat LVM bukan titik kukuh. Pasang btrfs. Dan pemuat but berada dalam MBR. Tidak ada gunanya mengacaukan cakera 50 MB dengan partition FAT apabila anda boleh menolaknya ke dalam kawasan jadual partition 1 MB dan memperuntukkan semua ruang untuk sistem. Mengambil 700 MB pada cakera. Saya tidak ingat berapa banyak pemasangan SUSE asas, saya fikir ia adalah kira-kira 1.1 atau 1.4 GB.
Pasang CEPH. Kami mengabaikan versi 12 dalam repositori debian dan menyambung terus dari tapak 15.2.3. Kami mengikuti arahan dari bahagian "Pasang CEPH secara manual" dengan kaveat berikut:
- Sebelum menyambungkan repositori, anda mesti memasang gnupg wget ca-certificates
- Selepas menyambungkan repositori, tetapi sebelum memasang kluster, pemasangan pakej ditinggalkan: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Apabila memasang CEPH, atas sebab yang tidak diketahui, ia akan cuba memasang lvm2. Pada dasarnya, ia bukan sayang, tetapi pemasangan gagal, jadi CEPH tidak akan memasang sama ada.
Tampalan ini membantu:
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
Gambaran keseluruhan kluster
ceph-osd - bertanggungjawab untuk menyimpan data pada cakera. Untuk setiap cakera, perkhidmatan rangkaian dilancarkan yang menerima dan melaksanakan permintaan untuk membaca atau menulis ke objek. Dua partition dicipta pada cakera. Salah satu daripadanya mengandungi maklumat tentang kluster, nombor cakera dan kunci kepada kluster. Maklumat 1KB ini dibuat sekali apabila menambah cakera dan tidak pernah dilihat berubah. Partition kedua tidak mempunyai sistem fail dan menyimpan data binari CEPH. Pemasangan automatik dalam versi sebelumnya mencipta partition xfs 100MB untuk maklumat perkhidmatan. Saya menukar cakera ke MBR dan memperuntukkan hanya 16MB - perkhidmatan itu tidak merungut. Saya rasa xfs boleh digantikan dengan ext tanpa sebarang masalah. Partition ini dipasang dalam /var/lib/β¦, di mana perkhidmatan membaca maklumat tentang OSD dan juga mencari rujukan kepada peranti blok tempat data binari disimpan. Secara teorinya, anda boleh segera meletakkan fail tambahan dalam /var/lib/β¦, dan memperuntukkan keseluruhan cakera untuk data. Apabila mencipta OSD melalui ceph-deploy, peraturan dibuat secara automatik untuk melekapkan partition dalam /var/lib/β¦, dan pengguna ceph juga diberikan hak untuk membaca peranti blok yang diingini. Jika anda memasang secara manual, anda mesti melakukannya sendiri; dokumentasi tidak menyatakan perkara ini. Ia juga dinasihatkan untuk menentukan parameter sasaran memori osd supaya terdapat memori fizikal yang mencukupi.
ceph-mds. Pada tahap yang rendah, CEPH ialah penyimpanan objek. Keupayaan untuk menyekat storan adalah untuk menyimpan setiap blok 4MB sebagai objek. Storan fail berfungsi pada prinsip yang sama. Dua kumpulan dibuat: satu untuk metadata, satu lagi untuk data. Mereka digabungkan ke dalam sistem fail. Pada masa ini, beberapa jenis rekod dibuat, jadi jika anda memadam sistem fail, tetapi menyimpan kedua-dua kumpulan, anda tidak akan dapat memulihkannya. Terdapat prosedur untuk mengekstrak fail mengikut blok, saya belum mengujinya. Perkhidmatan ceph-mds bertanggungjawab untuk akses kepada sistem fail. Setiap sistem fail memerlukan contoh perkhidmatan yang berasingan. Terdapat pilihan "indeks", yang membolehkan anda membuat kemiripan beberapa sistem fail dalam satu - juga tidak diuji.
Ceph-mon - Perkhidmatan ini menyimpan peta kelompok. Ia termasuk maklumat tentang semua OSD, algoritma untuk mengedarkan PG dalam OSD dan, yang paling penting, maklumat tentang semua objek (butiran mekanisme ini tidak jelas kepada saya: terdapat direktori /var/lib/ceph/mon/β¦/ store.db, ia mengandungi fail yang besar ialah 26MB, dan dalam kelompok 105K objek, ternyata lebih sedikit daripada 256 bait setiap objek - Saya fikir monitor menyimpan senarai semua objek dan PG di mana mereka terletak). Kerosakan pada direktori ini mengakibatkan kehilangan semua data dalam kelompok. Oleh itu kesimpulan telah dibuat bahawa CRUSH menunjukkan cara PG terletak pada OSD, dan cara objek terletak pada PG - ia disimpan secara berpusat di dalam pangkalan data, tidak kira berapa banyak pembangun mengelakkan perkataan ini. Akibatnya, pertama, kami tidak boleh memasang sistem pada pemacu kilat dalam mod RO, kerana pangkalan data sentiasa direkodkan, cakera tambahan diperlukan untuk ini (hampir tidak lebih daripada 1 GB), kedua, adalah perlu untuk mempunyai salin dalam masa nyata pangkalan ini. Sekiranya terdapat beberapa monitor, maka toleransi kesalahan dipastikan secara automatik, tetapi dalam kes kami hanya terdapat satu monitor, maksimum dua. Terdapat prosedur teori untuk memulihkan monitor berdasarkan data OSD, saya menggunakannya tiga kali untuk pelbagai sebab, dan tiga kali tidak ada mesej ralat, serta tiada data. Malangnya, mekanisme ini tidak berfungsi. Sama ada kami mengendalikan partition kecil pada OSD dan memasang RAID untuk menyimpan pangkalan data, yang pastinya akan memberi kesan yang sangat buruk pada prestasi, atau kami memperuntukkan sekurang-kurangnya dua media fizikal yang boleh dipercayai, sebaik-baiknya USB, supaya tidak menduduki port.
rados-gw - mengeksport storan objek melalui protokol S3 dan seumpamanya. Mencipta banyak kolam, tidak jelas mengapa. Saya tidak banyak bereksperimen.
ceph-mgr - Apabila memasang perkhidmatan ini, beberapa modul dilancarkan. Salah satunya ialah autoscale yang tidak boleh dilumpuhkan. Ia berusaha untuk mengekalkan jumlah PG/OSD yang betul. Jika anda ingin mengawal nisbah secara manual, anda boleh melumpuhkan penskalaan untuk setiap kumpulan, tetapi dalam kes ini modul ranap dengan pembahagian sebanyak 0, dan status kluster menjadi RALAT. Modul ini ditulis dalam Python, dan jika anda mengulas baris yang diperlukan di dalamnya, ini membawa kepada pelumpuhannya. Malas nak ingat detail.
Senarai sumber yang digunakan:
Penyenaraian skrip:
Memasang sistem melalui 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 6Buat gugusan
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@rbd1Menambah OSD (bahagian)
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@$osdnumRingkasan
Kelebihan pemasaran utama CEPH ialah CRUSH - algoritma untuk mengira lokasi data. Monitor mengedarkan algoritma ini kepada pelanggan, selepas itu pelanggan meminta terus nod yang dikehendaki dan OSD yang dikehendaki. CRUSH memastikan tiada pemusatan. Ia adalah fail kecil yang anda boleh cetak dan gantung di dinding. Amalan telah menunjukkan bahawa CRUSH bukanlah peta yang lengkap. Jika anda memusnahkan dan mencipta semula monitor, menyimpan semua OSD dan CRUSH, maka ini tidak mencukupi untuk memulihkan kluster. Daripada ini disimpulkan bahawa setiap monitor menyimpan beberapa metadata tentang keseluruhan kluster. Jumlah kecil metadata ini tidak mengenakan sekatan pada saiz kluster, tetapi memerlukan memastikan keselamatannya, yang menghapuskan penjimatan cakera dengan memasang sistem pada pemacu kilat dan mengecualikan kluster dengan kurang daripada tiga nod. Dasar agresif pembangun berkenaan ciri pilihan. Jauh dari minimalism. Dokumentasi berada pada tahap "terima kasih atas apa yang kami ada, tetapi ia sangat, sangat kecil." Keupayaan untuk berinteraksi dengan perkhidmatan pada tahap rendah disediakan, tetapi dokumentasi menyentuh topik ini terlalu dangkal, jadi kemungkinan besar tidak daripada ya. Hampir tiada peluang untuk memulihkan data daripada situasi kecemasan.
Pilihan untuk tindakan selanjutnya: tinggalkan CEPH dan gunakan btrfs berbilang cakera cetek (atau xfs, zfs), dapatkan maklumat baharu tentang CEPH, yang akan membolehkan anda mengendalikannya di bawah syarat yang ditetapkan, cuba tulis storan anda sendiri sebagai lanjutan latihan.
Sumber: www.habr.com