Ta ei ole teile DRoook.

Seoses Rook'i kasvava populaarsusega on soov rääkida selle varjatud probleemidest ja takistustest, millega võite silmitsi seista.

Minust: Ceph administraatori kogemus alates versioonist hammer, kogukonna asutaja t.me/ceph_ru Telegramis.

Et mitte olla tühja juttu ajav, viitan vastu võetud Habr'i (hinnangute põhjal) postitustele Ceph'i probleemide kohta. Suurem osa probleemidest, millega seal silmitsi seisti, on ka mind puudutanud. Kasutatud materjalide lingid postituse lõpus.

Rook'i postituses ei mainita Ceph'i ilma põhjuseta — Rook on tegelikult Ceph, mis on pakitud Kubernetesesse, tähendades, et see pärib kõik selle probleemid. Alustame Ceph'i probleemidest.

Klastri haldamise lihtsustamine

Üks Rook'i eeliseid on Ceph'i mugav haldamine läbi Kubernetes.

Kuid Ceph sisaldab rohkem kui 1000 seadistamise parameetrit, samas kui Rook'i kaudu saame muuta vaid väiksemat osa neist.

Näide Luminouselt
> ceph daemon mon.a config show | wc -l
1401

Rook positsioneerib end kui mugav viis Ceph'i installimiseks ja uuendamiseks
Ceph'i installimisega ilma Rook'ita pole probleeme — ansible'i mängukava kirjutamine võtab 30 minutit, kuid uuendamisega on palju probleeme.

Tsitaat Krok'i postitusest

Näide: crush tunable'ite vale töö pärast uuendamist hummer'ilt jewel'ile

> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}

Kuid isegi väikeste versioonide vahel võivad esineda probleemid.

Näide: Uuendus 12.2.6, mis viib klastrit tervislikku erisse ja tinglikult katki PG.
ceph.com/releases/v12-2-8-released

Kas mitte uuendada, vaid oodata ja testida? Kuid me kasutame Rook'i ka selleks, et hõlbustada uuendusi.

Klastri hädaolukorra taastamise keerukus Rook'is.

Näide: OSD kukub, visates endale jalgade alla vigu. Kahtlete, et probleem on ühes konfigureerimise parameetris, soovite muuta konfi konkreetse deemoniga, kuid ei saa, kuna teil on Kubernetes ja DaemonSet.

Alternatiivi pole. ceph tell osd.Num injectargs ei tööta — OSD on ju maas.

Debugimise keerukus.

Mõnede seadistuste ja jõudluse testide jaoks on vajalik otse osd deemoniga pistikupessa ühenduda. Rook'i puhul peate esmalt leidma vajaliku konteineri, seejärel sisenema sellesse, avama debugimiseks vajalike tööriistade puudumise ja väga pettuma.

OSD järjestikuse tõstmise keerukus.

Näide: OSD kukub OOM-i pärast, algab ümberjaotamine, seejärel kukuvad järgmised.

Lahendus: tõstke OSD-d ükshaaval, oodake, kuni need täielikult klastrisse lülitatakse, ja tõstke järgmised. (Üksikasjad Cephi raportis. Katastroofi anatoomia).

Baremetal paigalduse korral toimub see lihtsalt käsitsi, Rooki ja ühe OSD-ga sõlme ei ole erilisi probleeme, probleeme tekib järjestikuste tõusudega, kui OSD-d on > 1 sõlmes.

Loomulikult on need lahendatavad, kuid me ju toome Rooki lihtsustamiseks, mitte keerukuse tekitamiseks.

Ceph daemonite piiride sobitamise keerukus

Baremetal Ceph installatsioonide puhul on klastrile vajalike ressursside arvutamine piisavalt kerge — valemid ja uuringud on olemas. Nõrkade CPU-de kasutamise korral peavad teil riskima tegeleda mitme jõudluse testimisega, õppida, mis on Numa, kuid see on ikkagi lihtsam kui Rookis.

Rooki korral lisandub teile mälupiiride, mida saab arvutada, küsimus CPU piiri seadmisest.

Ja siin peate jõudluse testidega tõsiselt vaeva nägema. Kui seate piirid liiga madalaks, saate aeglase klastriga, kui määrate unlimi, põhjustate aktiivset CPU kasutamist uuesti tasakaalustamisel, mis avaldab negatiivset mõju teie rakendustele Kuberneteses.

Probleemid võrguühendusega v1

Cephi puhul soovitatakse kasutada 2x10Gb võrku. Üks kliendiliikluse jaoks ja teine cephi meditsiiniliste ülesannete (rebalance) jaoks. Kui kasutate cephi baremetal'is, on see jaotus lihtne seadistada, kuid Rook'i puhul võib see põhjustada probleeme, kuna kaugel ei ole iga klastrikonfiguratsioon võimaldada pod'ile kahte erinevat võrku.

Võrgus suhtlemise probleemid v2

Kui te ei soovi võrke jagada, siis rebalance'i käigus täidab ceph kogu kanalit ja teie rakendused Kubernetes'is võivad aeglustuda või kokku tõmmata. Cephi rebalance'i kiirus on võimalik vähendada, kuid pika rebalance'i tõttu tekib kõrgem risk, et teine node langeb kettatõrgete või OOM-i tõttu välja klastrist, mis toob endaga kaasa garanteeritud read only oleku klastris.

Pikk rebalance — pikad rakenduste viivitused

Tsitaat Cephi postitusest. Hädaolukordade anatoomia.

Testklastri jõudlus:

4 Kbyte kirjutamisoperatsioon võtab aega 1 ms, jõudlus 1000 operatsiooni/sekundi ühe lõime jooksul.

4 Mbyte (objekti suurus) operatsioon võtab aega 22 ms, jõudlus 45 operatsiooni/sekundi.

Seega, kui üks kolme domeeni ebaõnnestub, on klaster mõnda aega degradeerunud olekus ja pool kuumadest objektidest jaotub erinevatele versioonidele, hakkab pool kirjutamise operatsioonidest toimuma sundtaastumisega.

Sundtaastumise aeg arvutatakse ligikaudu — kirjutamise operatsioonid degradeerunud objektile.

Esmalt loeme 4 MB 22 ms jooksul, kirjutame 22 ms, ja seejärel kirjutame 1 ms 4 KB tegelikke andmeid. Kokku 45 ms ühe kirjutamise operatsiooni jaoks degradeerunud objekti puhul SSD-l, kui meie tavaline jõudlus oli 1 ms — jõudluse langus 45 korda.

Mida suurem on meie degradeerunud objektide protsent, seda hirmsamaks kõik muutub.

Selgub, et tasakaalustamise kiirus on klastrite nõuetekohase toimimise jaoks kriitilise tähtsusega.

Spetsiifilised serveri seaded ceph jaoks

ceph vajab mõnikord hosti spetsiifilist tuningut.

Näide: sysctl seaded ja samuti JumboFrame, mõned neist seadetest võivad teie payloadi negatiivselt mõjutada.

Rooki tegelik vajadus jääb küsimärgiks.

Kui olete pilves, on teil oma pilveteenuse pakkujalt salvestusruum, mis on oluliselt mugavam.

Kui olete oma serverites, siis on ceph-i haldamine mugavam ilma kuberneteseta.

Kas rendite servereid mõnes madalate hindadega hostimisteenuses? Siis ootab teid palju naljakaid hetki võrgu, selle latentsuse ja läbilaskevõimega, mis mõjutab ceph-i selgelt negatiivselt.

Kokku: Kubernetese rakendamine ja salvestussüsteemi rakendamine on erinevad ülesanded, erinevate sisendite ja erinevate lahenduste valikutega — nende segamine tähendab, et teete potentsiaalselt ohtlikku trade-off'i ühe või teise kasuks. Nende lahenduste ühitamine on isegi projekteerimise etapis väga keeruline, rääkimata kasutusperioodist.

Kasutatud kirjanduse nimekiri:

Post #1 Aga te ütlete Ceph... kas see on tõesti nii hea?
Post #2 Ceph. Katastroofi anatoomia

Allikas: habr.com