Având în vedere popularitatea în creștere a Rook, vreau să discut despre capcanele și problemele care vă așteaptă.
Despre mine: Experiență în administrarea ceph din versiunea hammer, fondator al comunității pe Telegram.
Pentru a nu fi acuzat de subiectivism, voi face referire la postările acceptate pe Habr (judecând după rating) despre problemele cu ceph. M-am confruntat și eu cu cele mai multe probleme menționate în aceste postări. Linkurile către materialele folosite sunt la sfârșitul postului.
În postarea despre Rook menționăm ceph nu întâmplător - Rook este, în esență, ceph ambalat în kubernetes, ceea ce înseamnă că moștenește toate problemele sale. Să începem cu problemele ceph.
Simplificarea gestionării clusterului
Unul dintre avantajele Rook este confortul gestionării ceph prin kubernetes.
Cu toate acestea, ceph conține mai mult de 1000 de parametrii de configurare, în timp ce prin rook putem modifica doar o mică parte dintre aceștia.
Exemplu pe Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook se poziționează ca o modalitate convenabilă de a instala și actualiza ceph
Nu există probleme cu instalarea ceph fără Rook - playbook-ul ansible durează 30 de minute să se scrie, dar există o mulțime de probleme cu actualizarea.
Citat din postarea lui Krok
Exemplu: funcționarea incorectă a tunabilelor crush după actualizarea de la hummer la jewel
> ceph osd crush show-tunables
{
…
„straw_calc_version”: 1,
„allowed_bucket_algs”: 22,
„profile”: „unknown”,
„optimal_tunables”: 0,
…
}
Dar chiar și în cadrul versiunilor minore există probleme.
Exemplu: Actualizarea 12.2.6 care duce clusterul în stare de sănătate eronată și PG-uri condiționat corupte
Să nu ne actualizăm, să așteptăm și să testăm? Dar totuși folosim Rook pentru confortul actualizărilor printre altele.
Dificultatea recuperării în caz de dezastru a clusterului în Rook
Exemplu: OSD-ul cade generând erori. Suspectați că problema este unul dintre parametrii din configurare, vreți să schimbați configurația pentru un anumit daemon, dar nu puteți, pentru că aveți kubernetes și DaemonSet.
Nu există alternativă. ceph tell osd.Num injectargs nu funcționează - OSD-ul e căzut.
Dificultatea depanării
Pentru anumite setări și teste de performanță, este necesar să vă conectați direct la socket-ul daemonului osd. În cazul Rook, trebuie să găsiți containerul dorit, apoi să intrați în el, să descoperiți absența instrumentelor de depanare și să fiți foarte dezamăgit.
Dificultatea ridicării succesive a OSD-ului
Exemplu: OSD-ul cade din cauza OOM, începe rebalance-ul, după care cad următoarele.
Soluție: Ridicați OSD-ul pe rând, așteptați să se încadreze complet în cluster și ridicați următoarele. (Mai multe detalii în raportul Ceph. Anatomia dezastrului).
În cazul instalărilor baremetal, acest lucru se face simplu manual, iar în cazul Rook și cu un OSD pe nod problemele nu sunt mari, problemele cu ridicarea sequentială vor apărea dacă OSD > 1 pe nod.
Desigur, ele sunt rezolvabile, dar purtăm Rook pentru simplificare, iar ceea ce obținem este complicare.
Complexitatea stabilirii limitelor pentru demonii ceph.
Pentru instalările baremetal ceph este destul de ușor să se calculeze resursele necesare pentru cluster—există formule și cercetări disponibile. Când folosiți CPU-uri slabe, va trebui totuși să faceți o serie de teste de performanță, să învățați ce este Numa, dar totul este de fapt mai simplu decât în Rook.
În cazul Rook, pe lângă limitele de memorie care pot fi calculate, apare întrebarea stabilirii limitei CPU.
Și aici va trebui să depuneți eforturi cu testele de performanță. În cazul subevaluării limitelor, veți obține un cluster lent, iar dacă stabiliți unlimit, veți avea o utilizare activă a CPU-ului în timpul reechilibrului, ceea ce va influența negativ aplicațiile dvs. în kubernetes.
Probleme cu interacțiunea rețea v1.
Pentru ceph se recomandă utilizarea unei rețele de 2x10gb. Una pentru traficul clienților, cealaltă pentru nevoile de serviciu ale ceph (reechilibrare). Dacă folosiți ceph pe baremetal, atunci această separare este ușor de configurat, dar dacă utilizați Rook, separarea pe rețele vă va provoca probleme, deoarece nu orice configurație de cluster permite conectarea a două rețele diferite în pod.
Probleme cu interacțiunea rețea v2.
Dacă renunțați la separarea rețelelor, atunci în timpul reechilibrării traficul ceph va umple întreaga lățime de bandă și aplicațiile dvs. în kubernetes vor funcționa lent sau se vor opri. Puteți reduce viteza reechilibrării ceph, dar astfel, datorită reechilibrării prelungite, riscați ca al doilea nod să iasă din cluster din cauza discului sau OOM, iar acolo aveți deja o garanție de read only pe cluster.
Reechilibrare îndelungată — întârzieri lungi în aplicații.
Citat din postarea Ceph. Anatomia dezastrului.
Performanța clusterului de testare:
Operația de scriere de 4 Kbyte durează 1 ms, performanța este de 1000 de operații/secundă într-un singur fir.
Operația de dimensiune 4 Mbyte (dimensiunea obiectului) durează 22 ms, performanța este de 45 de operații/secundă.
Prin urmare, atunci când un domeniu din trei eșuează, clusterul se află pentru o vreme într-o stare degradată, iar jumătate dintre obiectele active sunt distribuite între diferitele versiuni, astfel că jumătate din operațiile de scriere vor începe cu o recuperare forțată.
Timpul de recuperare forțată este estimat aproximativ - operațiile de scriere în obiectul degradat.
Întâi citim 4 MB în 22 ms, scriem în 22 ms și apoi în 1 ms scriem 4 KB de date propriu-zise. În total, 45 ms pentru o operație de scriere în obiectul degradat pe SSD, când performanța normală a fost de 1 ms - o scădere a performanței de 45 de ori.
Cu cât procentajul obiectelor degradate este mai mare, cu atât devine tot mai îngrijorător.
Astfel, viteza de rebalansare este critică pentru funcționarea corectă a clusterului.
Setări specifice pentru serverele ceph
Ceph necesită uneori o ajustare specifică a gazdelor.
Exemplu: setările sysctl și aceeași JumboFrame, unele dintre aceste setări pot afecta negativ payload-ul dvs.
Necesitatea reală pentru Rook rămâne sub semnul întrebării
Dacă sunteți în cloud, aveți un stocaj de la furnizorul de cloud, ceea ce este mult mai convenabil.
Dacă vă aflați pe serverele proprii, gestionarea ceph va fi mai convenabilă fără kubernetes.
Închiriați servere de la un furnizor de găzduire de tip low cost? Atunci vă așteaptă multe probleme cu rețeaua, întârzierile și lățimea de bandă, ceea ce influențează evident ceph în mod negativ.
În total: Implementarea kubernetes și integrarea stocării sunt sarcini diferite, cu premise diferite și opțiuni de soluții diferite - amestecându-le, se face un trade-off posibil periculos în favoarea uneia sau alteia. Combinarea acestor soluții va fi foarte dificilă chiar și în etapa de proiectare, iar după aceea există perioada de exploatare.
Lista bibliografică:
Dar voi vorbiți despre Ceph... este el atât de bun?
Ceph. Anatomia unui eșec
Sursa: habr.com
