Seoses Rooki kasvava populaarsusega tahaksin rääkida selle lõksudest ja probleemidest, mis teid teel ootavad.
Minust: Kogemus haamri versioonist tsefi administreerimisel, kogukonna asutaja telegrammis.
Et mitte olla alusetu, viitan Habri poolt aktsepteeritud postitustele (hinnangu järgi otsustades) cephi probleemide kohta. Nendes postitustes puutusin kokku ka enamiku probleemidega. Lingid kasutatud materjalile on postituse lõpus.
Rooki käsitlevas postituses mainime tsefi põhjusega – Rook on sisuliselt kubernetesesse mähitud tsef, mis tähendab, et see pärib kõik oma probleemid. Alustame tsefi probleemidega.
Klastrite haldamise lihtsustamine
Üks Rooki eeliseid on tsefi haldamise lihtsus kuberentese kaudu.
Kuid ceph sisaldab konfigureerimiseks rohkem kui 1000 parameetrit, samal ajal saame vankri kaudu redigeerida neist vaid vähemust.
Näide Luminous'is
> ceph deemon mon.a config show | wc -l
1401
Vanker on mugav viis cephi installimiseks ja värskendamiseks
Ilma Rookita cephi installimisega probleeme pole - ansible playbook kirjutatakse 30 minutiga, kuid värskendamisega on palju probleeme.
Tsitaat Kroki postitusest
Näide: crush tunables ei tööta korralikult pärast hummerilt kalliskiviks värskendamist
> ceph osd crush show-tuunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profiil": "teadmata",
"optimal_tunables": 0,
...
}
Kuid isegi väiksemates versioonides on probleeme.
Näide: värskendus 12.2.6 toob klastri tervisevea olekusse ja tinglikult katki PG
Ärge värskendage, oodake ja testige? Kuid tundub, et me kasutame Rooki muu hulgas värskenduste mugavuse huvides.
Katastroofi taastamise klastri keerukus Rookis
Näide: OSD kukub ja jalgade juures on vigade lööve. Kui kahtlustate, et probleem on ühes konfiguratsiooni parameetritest, soovite konkreetse deemoni konfiguratsiooni muuta, kuid te ei saa seda teha, kuna teil on kubernetes ja DaemonSet.
Alternatiivi pole. ceph tell osd.Num injectargs ei tööta - OSD valetab.
Silumisraskused
Mõned seadistused ja jõudlustestid nõuavad otseühendust deemoni osd-pesaga. Rooki puhul peate esmalt leidma soovitud konteineri, seejärel minema sellesse, leidma silumiseks puuduoleva tööriista ja olema väga ärritunud.
OSD järjestikuse tõstmise raskused
Näide: OSD langeb OOM-is, algab tasakaalu taastamine, misjärel langevad järgmised.
Lahendus: tõstke OSD-d ükshaaval, oodake, kuni see on täielikult klastris kaasatud, ja tõstke järgmised. (Täpsemalt Cephi raportis. Katastroofi anatoomia).
Paljas paigalduse puhul tehakse seda lihtsalt käsitsi, Rooki ja ühe OSD puhul sõlme kohta erilisi probleeme pole, alternatiivse tõstmisega tekivad probleemid, kui OSD > 1 sõlme kohta.
Muidugi saab neid lahendada, kuid me kasutame Rooki asjade lihtsustamiseks, kuid keerukamaks muutmiseks.
Raskused tsefdeemonite piiride valimisel
Cef-i paljaste paigaldamisel on üsna lihtne arvutada klastri jaoks vajalikke ressursse - on olemas valemid ja uuringud. Kui kasutate nõrka protsessorit, peate siiski läbima mõned jõudlustestid, et teada saada, mis on Numa, kuid see on siiski lihtsam kui Rook.
Rooki puhul on teil lisaks arvutatavatele mälupiirangutele küsimus protsessori limiidi määramise kohta.
Ja siin peate jõudlustestidega kõvasti tööd tegema. Kui alandate limiite, saate aeglase klastri, kui määrate unlimi, saate uuesti tasakaalustamise ajal aktiivse CPU kasutuse, mis mõjutab teie rakendusi kubernetes halvasti.
Võrgustikuprobleemid v1
Cephi jaoks on soovitatav kasutada 2x10GB võrku. Üks kliendiliikluse jaoks, teine tseph-teenuse vajaduste jaoks (taasbalanss). Kui elate cephiga baremetalil, siis on see jaotus hõlpsasti seadistatav, kui elate koos Rookiga, siis võrkude järgi jagamine põhjustab teile probleeme, kuna mitte iga klastri konfiguratsioon ei võimalda teil podisse kahte erinevat võrku toita. .
Võrgustikuprobleemid v2
Kui keeldute võrkude eraldamisest, ummistab tsef-liiklus ümber tasakaalustamisel kogu kanali ja teie rakendused kubernetes aeglustuvad või jooksevad kokku. Saab küll vähendada tsef-i tasakaalustamise kiirust, kuid siis tekib pika tasakaalustuse tõttu kõrgendatud oht, et teine sõlm kukub klastrist ketaste või OOM-i kaudu välja ja juba on klastris garanteeritud ainult lugemine.
Pikk tasakaalustamine – pikad rakenduse viivitused
Tsitaat Cephi postitusest. Katastroofi anatoomia.
Testi klastri jõudlust:
4 KB suurune kirjutamisoperatsioon võtab aega 1 ms, jõudlus on 1000 lõimes 1 toimingut sekundis.
4 MB (objekti suurus) toiming võtab aega 22 ms, jõudlus on 45 toimingut sekundis.
Järelikult, kui üks domeen kolmest ebaõnnestub, on klaster mõnda aega halvenenud olekus ja pooled kuumad objektid on jaotatud erinevate versioonide vahel, siis pooled kirjutustoimingud algavad sunnitud taastamisega.
Arvutame sunnitud taastamise aja ligikaudu - kirjutame toimingud halvenenud objektile.
Kõigepealt loeme 4 ms jooksul 22 MB, kirjutame 22 ms ja seejärel kirjutame 1 ms jooksul 4 KB tegelikke andmeid. Kokku 45 ms ühe kirjutustoimingu kohta SSD-l halvenenud objektile, kui standardne jõudlus oli 1 ms – jõudluse langus 45 korda.
Mida suurem on lagunenud objektide protsent, seda hullemaks kõik läheb.
Selgub, et klastri korrektseks tööks on kriitilise tähtsusega tasakaalu taastamise kiirus.
Spetsiifilised serveri seaded cephi jaoks
ceph võib vajada spetsiifilist hosti häälestamist.
Näide: sysctl-i sätted ja sama JumboFrame, mõned neist sätetest võivad teie kasulikku koormust negatiivselt mõjutada.
Rooki tegelik vajadus jääb küsitavaks
Kui olete pilves, on teil pilveteenuse pakkuja salvestusruum, mis on palju mugavam.
Kui olete oma serverites, on cephi haldamine mugavam ilma kubernetesita.
Kas rendite servereid mõnest odavast hostimisest? Siis saate võrguga, selle viivituste ja ribalaiusega palju nalja, mis mõjutab selgelt tsefi negatiivselt.
Kokku: Kuberente juurutamine ja salvestusruumi juurutamine on erinevad ülesanded erinevate sisendite ja erinevate lahendusvõimalustega – nende segamine tähendab võimaliku ohtliku kompromissi tegemist ühe või teise nimel. Neid lahendusi on väga raske kombineerida isegi projekteerimisetapis ja veel on aega.
Kasutatud kirjanduse loend:
Aga sa ütled, Ceph... kas ta on tõesti nii hea?
Ceph. Katastroofi anatoomia
Allikas: www.habr.com