CEPH գործառնական փորձ

Երբ ավելի շատ տվյալներ կան, քան կարող են տեղավորվել մեկ սկավառակի վրա, ժամանակն է մտածել 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: Հետևաբար, տվյալների բաշխման մեջ էնտրոպիան չի նպաստում սխալների հանդուրժողականությանը: Նկատի ունեցեք նաև, որ ֆայլերի սերվերի համար անվճար RAM-ը զգալիորեն մեծացնում է արձագանքման արագությունը: Որքան շատ հիշողություն յուրաքանչյուր հանգույցում, և որքան շատ հիշողություն բոլոր հանգույցներում, այնքան ավելի արագ կլինի: Սա, անկասկած, կլաստերի առավելությունն է մեկ սերվերի և, առավել ևս, ապարատային NAS-ի նկատմամբ, որտեղ ներկառուցված է շատ փոքր քանակությամբ հիշողություն:

Սրանից հետևում է, որ CEPH-ը լավ միջոց է տասնյակ տուբերկուլյոզի համար տվյալների պահպանման հուսալի համակարգ ստեղծելու համար՝ հնացած սարքավորումներից նվազագույն ներդրումներով մասշտաբելու ունակությամբ (այստեղ, իհարկե, ծախսերը կպահանջվեն, բայց փոքր՝ համեմատած առևտրային պահպանման համակարգերի հետ):

Կլաստերների իրականացում

Փորձի համար վերցնենք շահագործումից հանված համակարգիչ Intel DQ57TM + Intel core i3 540 + 16 ԳԲ օպերատիվ հիշողություն: Մենք կկազմակերպենք չորս 2 TB սկավառակ RAID10-ի նման մի բանի մեջ, հաջող թեստից հետո կավելացնենք երկրորդ հանգույց և նույնքան սկավառակ:

Linux-ի տեղադրում. Բաշխումը պահանջում է հարմարեցնելու և կայուն լինելու ունակություն: Debian-ը և Suse-ը համապատասխանում են պահանջներին: Suse-ն ունի ավելի ճկուն տեղադրող, որը թույլ է տալիս անջատել ցանկացած փաթեթ. Ցավոք սրտի, ես չկարողացա հասկանալ, թե որոնք կարելի է դեն նետել՝ չվնասելով համակարգը։ Տեղադրեք Debian-ը՝ օգտագործելով debootstrap buster: Min-base տարբերակը տեղադրում է կոտրված համակարգ, որը չունի վարորդներ: Չափերի տարբերությունը ամբողջական տարբերակի համեմատ այնքան էլ մեծ չէ, որ անհանգստացնի։ Քանի որ աշխատանքն իրականացվում է ֆիզիկական մեքենայի վրա, ես ուզում եմ լուսանկարել, ինչպես վիրտուալ մեքենաներում: Այս տարբերակը տրամադրվում է կամ LVM-ի կամ btrfs-ի կողմից (կամ xfs, կամ zfs - տարբերությունը մեծ չէ): LVM snapshot-ները ուժեղ կողմ չեն: Տեղադրեք btrfs. Իսկ bootloader-ը գտնվում է MBR-ում: 50 ՄԲ սկավառակը FAT միջնորմով խառնելն անիմաստ է, երբ կարող եք այն մղել 1 ՄԲ բաժանման սեղանի տարածք և ամբողջ տարածքը հատկացնել համակարգի համար: Սկավառակի վրա վերցրեց 700 ՄԲ: Ես չեմ հիշում, թե որքան է SUSE-ի հիմնական տեղադրումը, կարծում եմ, որ այն մոտ 1.1 կամ 1.4 ԳԲ է:

Տեղադրեք CEPH: Մենք անտեսում ենք 12-րդ տարբերակը debian պահեստում և միանում ենք անմիջապես 15.2.3 կայքից: Մենք հետևում ենք «Տեղադրեք CEPH ձեռքով» բաժնի հրահանգներին՝ հետևյալ զգուշացումներով.

• Նախքան պահեստը միացնելը, դուք պետք է տեղադրեք gnupg wget ca-սերտիֆիկատներ
• Պահեստը միացնելուց հետո, բայց մինչև կլաստերը տեղադրելը, փաթեթների տեղադրումը բաց է թողնվում. apt -y --no-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 - պատասխանատու է սկավառակի վրա տվյալների պահպանման համար: Յուրաքանչյուր սկավառակի համար գործարկվում է ցանցային ծառայություն, որն ընդունում և կատարում է օբյեկտներին կարդալու կամ գրելու հարցումները: Սկավառակի վրա ստեղծվում են երկու բաժին: Դրանցից մեկը պարունակում է տեղեկատվություն կլաստերի, սկավառակի համարի և կլաստերի ստեղների մասին։ Այս 1 ԿԲ տեղեկատվությունը ստեղծվում է մեկ անգամ սկավառակ ավելացնելիս և երբեք չի փոխվել: Երկրորդ բաժինը չունի ֆայլային համակարգ և պահպանում է CEPH երկուական տվյալները: Նախորդ տարբերակներում ավտոմատ տեղադրումը ստեղծեց 100 ՄԲ xfs միջնորմ՝ սպասարկման տեղեկատվության համար: Սկավառակը փոխակերպեցի MBR-ի և հատկացրի ընդամենը 16 ՄԲ - ծառայությունը չի դժգոհում: Կարծում եմ՝ xfs-ը կարելի էր առանց խնդիրների փոխարինել ext-ով։ Այս բաժանումը տեղադրված է /var/lib/…-ում, որտեղ ծառայությունը կարդում է տեղեկատվություն OSD-ի մասին և նաև հղում է գտնում բլոկային սարքին, որտեղ պահվում են երկուական տվյալները: Տեսականորեն, դուք կարող եք անմիջապես տեղադրել օժանդակ ֆայլերը /var/lib/…-ում և տրամադրել ամբողջ սկավառակը տվյալների համար: Ceph-deploy-ի միջոցով OSD ստեղծելիս ինքնաբերաբար ստեղծվում է կանոն՝ բաժանումը /var/lib/…-ում տեղադրելու համար, և ceph օգտագործողին վերագրվում են նաև իրավունքներ կարդալու ցանկալի բլոկ սարքը: Եթե ​​դուք տեղադրում եք ձեռքով, դուք պետք է դա անեք ինքներդ, փաստաթղթերում սա չի ասվում: Ցանկալի է նաև նշել osd հիշողության թիրախային պարամետրը, որպեսզի բավարար ֆիզիկական հիշողություն լինի:

ceph-mds. Ցածր մակարդակում CEPH-ը օբյեկտների պահեստավորում է: Բլոկների պահպանման հնարավորությունը հանգում է նրան, որ յուրաքանչյուր 4 ՄԲ բլոկը պահվում է որպես օբյեկտ: Ֆայլերի պահպանումն աշխատում է նույն սկզբունքով։ Ստեղծվում է երկու լողավազան՝ մեկը մետատվյալների համար, մյուսը՝ տվյալների: Դրանք համակցված են ֆայլային համակարգի մեջ: Այս պահին ինչ-որ գրառում է ստեղծվում, այնպես որ, եթե ջնջեք ֆայլային համակարգը, բայց պահեք երկու լողավազանները, չեք կարողանա վերականգնել այն։ Ֆայլերը բլոկներով հանելու ընթացակարգ կա, ես չեմ փորձարկել։ Ceph-mds ծառայությունը պատասխանատու է ֆայլային համակարգ մուտք գործելու համար: Յուրաքանչյուր ֆայլային համակարգ պահանջում է ծառայության առանձին օրինակ: Կա «ինդեքս» տարբերակ, որը թույլ է տալիս ստեղծել մի քանի ֆայլային համակարգերի տեսք մեկում, որը նույնպես չի փորձարկվել:

Ceph-mon - Այս ծառայությունը պահում է կլաստերի քարտեզը: Այն ներառում է տեղեկատվություն բոլոր OSD-ների մասին, OSD-ներում PG-ների բաշխման ալգորիթմ և, ամենակարևորը, տեղեկատվություն բոլոր օբյեկտների մասին (այս մեխանիզմի մանրամասներն ինձ համար պարզ չեն. կա գրացուցակ /var/lib/ceph/mon/…/: store.db, այն պարունակում է մեծ ֆայլ՝ 26 ՄԲ, և 105K օբյեկտների կլաստերում, պարզվում է, որ յուրաքանչյուր օբյեկտի համար 256 բայթից մի փոքր ավելի է. կարծում եմ, որ մոնիտորը պահում է բոլոր օբյեկտների և PG-ների ցանկը, որոնցում դրանք գտնվում են): Այս գրացուցակի վնասը հանգեցնում է կլաստերի բոլոր տվյալների կորստի: Հետևաբար, եզրակացություն է արվել, որ CRUSH-ը ցույց է տալիս, թե ինչպես են PG-ները տեղակայված OSD-ի վրա, և ինչպես են օբյեկտները տեղակայված PG-ների վրա. դրանք կենտրոնացված են պահվում տվյալների բազայում, անկախ նրանից, թե որքանով են մշակողները խուսափում այս բառից: Արդյունքում, նախ, մենք չենք կարող համակարգը տեղադրել RO ռեժիմով ֆլեշ կրիչի վրա, քանի որ տվյալների բազան անընդհատ ձայնագրվում է, դրանց համար անհրաժեշտ է լրացուցիչ սկավառակ (1 ԳԲ-ից հազիվ ավելի), երկրորդ՝ անհրաժեշտ է ունենալ պատճենեք այս բազան իրական ժամանակում: Եթե ​​կան մի քանի մոնիտորներ, ապա սխալների հանդուրժողականությունը ապահովվում է ավտոմատ կերպով, բայց մեր դեպքում կա միայն մեկ մոնիտոր, առավելագույնը երկու: Կա OSD տվյալների հիման վրա մոնիտորը վերականգնելու տեսական ընթացակարգ, ես դրան դիմել եմ երեք անգամ տարբեր պատճառներով, և երեք անգամ սխալի հաղորդագրություններ չեն եղել, ինչպես նաև տվյալներ չեն եղել։ Ցավոք, այս մեխանիզմը չի գործում։ Կամ մենք աշխատում ենք OSD-ի վրա մանրանկարչական միջնորմ և հավաքում ենք RAID տվյալների բազան պահելու համար, ինչը, անշուշտ, շատ վատ կանդրադառնա կատարման վրա, կամ մենք տրամադրում ենք առնվազն երկու հուսալի ֆիզիկական մեդիա, գերադասելի USB, որպեսզի չզբաղեցնենք նավահանգիստները:

rados-gw - արտահանում է օբյեկտների պահեստավորում S3 արձանագրության և նմանատիպերի միջոցով: Ստեղծում է բազմաթիվ լողավազաններ, անհասկանալի է, թե ինչու: Ես շատ փորձեր չեմ արել:

ceph-mgr - Այս ծառայությունը տեղադրելիս մի քանի մոդուլներ են գործարկվում: Դրանցից մեկը ավտոմատ սանդղակն է, որը հնարավոր չէ անջատել: Այն ձգտում է պահպանել PG/OSD-ի ճիշտ քանակությունը: Եթե ​​ցանկանում եք ձեռքով կառավարել հարաբերակցությունը, կարող եք անջատել մասշտաբը յուրաքանչյուր լողավազանի համար, բայց այս դեպքում մոդուլը խափանում է 0-ի բաժանմամբ, և կլաստերի կարգավիճակը դառնում է ERROR: Մոդուլը գրված է 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-ի մասին, որոնք թույլ կտան աշխատել այն նշված պայմաններում, փորձել գրել ձեր սեփական պահեստը որպես առաջադեմ: վերապատրաստում.

Source: www.habr.com