Reechilibrare la adăugarea nodului ceph. Crearea unui cluster CEPH. Instalarea de software și crearea de cluster
Clusterul Ceph.
Se recomandă crearea unui cluster CEPH în conformitate cu documentația pentru proiect. Pe această pagină, oferim doar informații de instalare generalizate.
Clusterul CEPH trebuie localizat separat de VMManager. Conceptele "nodurilor" și "cluster" nu au nimic de-a face cu nodurile "vmmanager cluster".
Cerințe de sistem
Pentru a crea un cluster, este necesar următoarele:
- Servere fizice sau virtuale (minim - 5): un server cu date ( OSD.), un server pentru metadate ( MDS.) cel puțin două servere de monitorizare și un server administrativ (acesta este primul client);
- Toate serverele trebuie să fie cât mai aproape posibil unul altuia. De preferință într-un singur raft și într-un segment al rețelei;
- Pentru clusterul CEPH, este de dorit să se utilizeze o conexiune la rețea de mare viteză, atât între nodurile de cluster, cât și cu nodurile client;
- Toate serverele trebuie să fie instalate un sistem de operare.
Pregătirea nodurilor
Toate nodurile de cluster au nevoie de:
- A stabilit openssh.;
- Creați un utilizator CEPH:
- Creat utilizatorului pentru a atribui toate privilegiile:
După aceea, pe serverul administrativ, trebuie să creați taste SSH pentru a avea acces de la un server administrativ la toate nodurile de cluster:
- Creați un director / CEPH-Client și mergeți la acesta:
- Creați cheile SSH:
- În cazul în care nodurile de cluster nu sunt permise în DNS, trebuie să actualizați / etc / gazde. Șablonul fișierului corect este după cum urmează:
- Este convenabil să începeți o variabilă:
- Apoi copiați tastele ssh la nodurile de cluster după cum urmează:
- Editați fișierul de configurare ~ / .ssh / config. Șablonul fișierului corect este după cum urmează:
Instalarea de software și crearea de cluster
- Instalare ceph-imploy.:
- Crearea unui cluster: Pentru a face acest lucru, este necesar să se inițieze nodurile monitoarelor:
- Rețineți că, dacă doriți să utilizați un depozit CEPH cu un nod de cluster, aveți nevoie în fișierul de configurare CEPH (Ceph.Conf) Valoarea parametrului "OSD Crush Selectați" este implicit ("1") Schimbați la "0 ":
- Instalare ceph pe nodurile de cluster:
- Instalare pentru monitoarele de cluster:
- Obținerea cheilor de monitorizare a clusterului:
- Pregătirea depozitului (în cazul examinării, de exemplu, pe nodurile de depozitare de acolo disc gol / dev / sdb):
- Discuri de curățare / dev / sdb pe depozite. Toate datele privind discurile vor fi șterse :
- Pregătirea nodului metadatei:
În acest capitol, vom lua în considerare următoarele subiecte:
Prezentarea generală a performanței CEPH
Analiza performanței generale CEPH - nivel hardware
Setarea performanței CEPH - nivel de software
Codarea eliminării CEPH.
Crearea unui nivel al cache-ului CEF
Testarea CEPH de referință utilizând Bench Rados
Datele și informațiile păstrează întotdeauna tendința spre schimbare și creștere. Fiecare organizație, indiferent dacă este mică sau mare, se confruntă cu probleme de creștere a datelor în timp și de cele mai multe ori aceste probleme de creștere a datelor aduc și cu ele și probleme de performanță. În epoca actuală când lumea creează o cantitate mare Datele, organizațiile sunt forțate să caute soluții de stocare a datelor care sunt extrem de scalabile, distribuite, extrem de fiabile și, în plus, au performanțe bune pentru toate nevoile lor de încărcături.
Unul dintre cele mai mari avantaje ale CEPH este că are o arhitectură scalabilă, distribuită. Datorită naturii distribuite, toate încărcăturile primite sunt distribuite și atribuite întregului cluster de stocare, ceea ce face sistemul de stocare CEPH cu performanțe bune. Vă puteți imagina fișierele de date în sistemele tradiționale de stocare ca fiind foarte limitate în scalabilitate, cu o distribuție practic absentă și având doar un număr limitat de noduri și discuri de depozitare. În astfel de instalații tradiționale, problemele pot apărea cu performanța, deoarece volumele de date cresc și crește numărul de solicitări de utilizator.
În acest moment, când aplicațiile servesc cantități uriașe de clienți, acestea necesită sisteme de stocare de bază cu performanțe mai bune. O instalație tipică CEPH conține o varietate de noduri, fiecare nod conține mai multe OSD (dispozitiv de stocare a obiectelor). Deoarece CEPH este distribuit când datele sunt primite pentru salvare, acestea sunt distribuite pe mai multe noduri și OSD-uri în ele, oferind acumularea de productivitate a nodurilor multiple. În plus, sistemele tradiționale sunt limitate la anumiți indicatori de performanță atunci când adăugați un container suplimentar pentru ele, adică Nu primiți performanțe suplimentare, deoarece recipientul crește. În unele cazuri, picăturile de performanță pe măsură ce recipientul crește. În CEPH, nu veți vedea niciodată o reducere a performanței cu creșterea containerului ( Prim.per.: Câteva afirmații simple (în relație nu): De fapt, există limitări asociate cu anvelopele interconectate și interne ale nodurilor, și anume: lățimea totală de bandă a canalelor, latența și concurența lor pentru canalele de comunicare în sine. Cu toate acestea, într-adevăr, aceste probleme pot fi, de asemenea, rezolvate prin scalare). Cu o capacitate de creștere a sistemului de stocare CEPH, adică. Când adăugați noduri noi, umplute cu OSD, performanța întregului cluster mărește liniar, deoarece primim mai mulți cai de lucru OSD și adăugați procesoare, berbec și resursele de rețea împreună cu nodurile noi. Aceasta este ceea ce face ceph unic și o deosebește de alte sisteme de stocare.
Când vine vorba de performanță, echipamentul utilizat este important. Sistemele tradiționale de stocare funcționează foarte specific pe hardware-ul producătorului de brand, iar utilizatorii nu au nicio flexibilitate în ceea ce privește alegerea echipamentelor de bază pe baza nevoilor și cerințelor unice de volum de muncă. Pentru organizațiile care investesc într-o astfel de închidere pe sistemul de vânzări, este foarte dificil să depășească problemele create de echipament, dacă a încetat brusc să răspundă la sarcinile cu care se confruntă.
Pe de altă parte, CEPH nu este absolut atașată la producătorul de echipamente; Organizațiile nu mai sunt asociate cu producătorii tehnici și pot folosi gratuit orice hardware pentru alegerea lor, precum și cerințele bugetare și de performanță. Ei au controlul deplin asupra echipamentului lor și a infrastructurii care stau la baza acestuia.
Un alt avantaj al CEPH este că susține echipamentele eterogene, adică. Cefh poate lucra pe un cluster cu echipament dintr-o varietate de producători. Utilizatorii au voie să amestece mărci comerciale atunci când creează infrastructura CEPH. De exemplu, atunci când cumpărați echipament pentru CEPH, utilizatorii pot amesteca mijloace tehnice De la diverși producători, cum ar fi HP, Dell, IBM, Fujitsu, Super Micro și nici măcar echipament standard. Astfel, clienții pot obține economii de numerar excelente, obține echipamentul necesar, controlul complet și luarea deciziilor. ( Prim.per.: Nu reduceți problema întreținerii și întreținerii sistemului; Într-un sistem la scară largă, fluxul de echipamente și contacte cu producătorul pe problemele înlocuirii sale este o situație regulată; Ar trebui să evaluați diferența în timpul dvs. și costurile de bani pentru a contacta cu un furnizor / producător și multe astfel de}.
Alegerea hardware-ului joacă un rol important în productivitatea globală a sistemului de stocare CEPH. În timp ce clienții au dreptul deplin de a alege tipul de hardware pentru CEPH, acest lucru trebuie făcut cu o atenție deosebită, cu evaluarea relevantă a volumelor de muncă curente și semnificația lor în viitor.
Ar trebui să se țină cont de faptul că alegerea hardware-ului depinde în întregime de volumul de muncă pe care îl veți pune în grupul dvs., mediul și întreaga funcționalitate pe care o veți folosi. În această secțiune vom explora câteva reguli generale atunci când aleg echipament pentru clusterul dvs. CEPH. ( Prim.per: Informații suplimentare Conform recomandărilor selecției echipamentului, puteți ajunge pe pagina http://www.mdl.ru/solutions/put.htm?nme\u003dcephHHW, care este transferul autorului de recomandări hardware de la site-ul oficial al documentației CEPH .}
Unele componente CEPH nu sunt procesoare exigente. De exemplu, monitoarele CEPH sunt ușoare, deoarece servesc copii ale clusterului și nu servesc date despre clienți. În majoritatea cazurilor, procesorul cu un nucleu va putea să efectueze această lucrare. De asemenea, puteți lua în considerare versiunea demonului de monitor pe orice alt server într-un mediu care are resurse gratuite. Asigurați-vă că aveți astfel de resurse de sistem. Pe măsură ce RAM, mijloacele de rețea și spațiul pe disc sunt suficiente pentru demonii de monitorizare.
Demonii OSD CEPH poate necesita resurse semnificative de procesoare, deoarece acestea servesc datele clienților și, prin urmare, necesită o anumită prelucrare a datelor. Pentru nodurile OSD vor exista un procesor cu două nucleare. Din punctul de vedere al performanței, este important să înțelegeți modul în care veți utiliza OSD: în modul replicare sau ștergeți codul. Dacă utilizați OSD în modul de ștergere a codului, trebuie să luați în considerare utilizarea unui procesor cu patru nucleare pentru a elimina codul care necesită o cantitate mare de calcul. Dacă datele de cluster sunt restabilite, consumul de resurse de procesoare de către demonii OSD crește semnificativ.
Demonii MDS (serverele metadate) sunt și mai solicitante în ceea ce privește resursele procesoare comparativ cu MON și OSD. ei trebuie să-și redistribuie dinamic încărcătura, care se încarcă foarte mult procesoarele centrale; Ar trebui să luați în considerare utilizarea procesatorilor patru nucleari pentru CEPH MDS.
Monitorul și demonii de metadate trebuie să-și servească rapid datele, de aceea trebuie să aibă suficientă memorie pentru o muncă rapidă. În ceea ce privește performanța, volumul în 2 GB sau mai mult pentru o instanță demone este suficient pentru metadate și monitor. De regulă, OSD nu solicită RAM. Pentru sarcina de funcționare a nivelului mediu, 1 GB de memorie RAM este suficient de calculă pe baza unei instanțe de demon OSD; Cu toate acestea, în ceea ce privește performanța, cea mai bună alegere va fi de 2 GB pe daemonul OSD. Recomandările sugerează că utilizați un daemon OSD pentru un disc fizic. Dacă utilizați mai mult de un disc fizic pentru OSD, cerințele dvs. RAM ar trebui, de asemenea, să crească. De obicei, este o cantitate mai mare de memorie RAM buna alegereDeoarece atunci când operațiunile de recuperare, consumul de memorie crește semnificativ.
Toate nodurile de cluster trebuie să aibă interfețe de rețea dublă pentru două rețele diferite, și anume: pentru rețeaua Cluster și pentru rețeaua de clienți. Pentru un cluster de dimensiuni medii, câteva sute de terabyte trebuie să fie suficient de conexiuni de rețea 1g. Cu toate acestea, dacă dimensiunea clusterului este mare și servește o mulțime de clienți, trebuie să vă gândiți la utilizarea unei rețele 10G cu o lățime de bandă sau mai mult. În timpul recuperării, rețeaua joacă un rol important. Dacă aveți o conexiune de rețea bună 10g sau mai mult, clusterul dvs. va fi recuperat mai repede, altfel poate necesita ceva timp. În consecință, în ceea ce privește performanța, 10G sau mai mult rețeaua duplicată va fi o alegere bună. Un cluster bine conceput utilizează două rețele separate fizic, una pentru rețeaua de cluster (rețea internă) și cea de-a doua pentru rețeaua de clienți (rețea externă); Ambele rețele ar trebui să fie împărțite fizic într-un comutator de rețea; Setarea punctului de disponibilitate necesită o rețea dublă redundantă, așa cum se arată în figura de mai jos:
Selectarea unui dispozitiv de disc pentru clusterul de stocare CEPH are valori excelente în ceea ce privește performanța generală și valoarea totală a clusterului. Înainte de a lua o alegere finală a discului. Trebuie să înțelegeți sarcina totală și cerințele posibile de performanță. OSD (dispozitiv de stocare a obiectelor) CEPH constă din două părți diferite: jurnalul OSD și o parte a datelor OSD. Fiecare operațiune de înregistrare este un proces în două etape.
Atunci când unele OSD primește solicitările clientului pentru a salva obiectul, acesta înregistrează mai întâi obiectul din partea jurnalului și apoi același obiect scrie o parte din date înainte de a trimite o notificare confirmată clientului. Astfel, toate performanțele clusterului se rotește în jurul jurnalului OSD și partiția de date. Pentru reviste, se recomandă utilizarea SSD în ceea ce privește performanța. Când utilizați SSD, puteți obține o creștere semnificativă a lățimii de bandă prin reducerea timpului de înregistrare și a latenței la citire. În majoritatea mediilor, în care nu sunteți nedumerit de performanțe extreme. Puteți selecta setarea jurnalului și partiția de date de pe același disc. Cu toate acestea, dacă căutați o îmbunătățire semnificativă a performanței clusterului dvs. CEPH, merită în SSD pentru reviste.
Pentru a utiliza SSD ca bușteni, vom crea partiții logice pe fiecare SSD fizic, care va fi utilizat pentru a anunț jurnalele, astfel încât fiecare secțiune a jurnalului să respecte o secțiune de date OSD. Cu acest tip de instalare, trebuie să păstrați limitele SSD în minte, astfel încât să nu ieșiți dincolo de supraîncărcarea setului de bușteni. Efectuarea acestui lucru veți influența performanța generală. A obtine performanță bună SSD dvs. ar trebui să stocați nu mai mult de patru OSD pe fiecare disc SSD.
Partea întunecată a utilizării unui SSD pentru mai multe bușteni este că pierderea SSD care suportă multe jurnale va refuza toate OSD asociate cu acest SSD și vă puteți pierde datele. Cu toate acestea, puteți depăși această situație utilizând RAID 1 pentru reviste, care, totuși, va duce la o creștere a costului de stocare. În plus, costul unui SSD este de aproximativ 10 ori mai mare decât costul HDD. În consecință, dacă construiți un cluster cu SSD, acesta va duce la o creștere a costului unui gigabyte pentru clusterul dvs. CEPH.
Alegere sistemul de fișiere Este, de asemenea, un aspect al performanței clusterului. BTRFS este un sistem de fișiere mai modern, care poate înregistra un obiect cu o singură operație în comparație cu XFS și Ext4, care necesită două etape pentru a înregistra un obiect. BTRFS este un sistem de fișiere cu copiere la înregistrare (copy-on-write), adică Când scrieți un obiect de înregistrare, acesta poate înregistra simultan același obiect în secțiunea de date, oferind o creștere semnificativă a productivității ( Aproximativ. Per: La schimbarea datelor noi, aceste date sunt copiate mai întâi într-o zonă nouă. ). Cu toate acestea, la momentul scrierii acestui ghid, BTRFS nu a fost pregătit pentru uz industrial. Puteți întâmpina inconsecvența datelor în BTRFS.
Performanța oricărui sistem este măsurată prin testarea încărcării și a performanței. Rezultatele unor astfel de teste ne vor ajuta să decidem dacă setarea curentă necesită sau nu. Setarea performanței este procesul de corectare a locurilor de performanță înguste identificate ca urmare a testelor de performanță. Setarea performanței este un subiect foarte extins care necesită un studiu profund, toate fără excepție, indiferent dacă sunt interne sau externe cu privire la CEPH.
Abordarea recomandată de configurare a clusterului este începutul unui sondaj pe o parte a celor mai mici elemente până la nivelul utilizatorilor finali care utilizează datele serviciului de stocare. În această secțiune, vom discuta despre câțiva parametri. setări de performanță Din punctul de vedere al clusterului CEPH. Vom defini aceste setări în fișierul Setări Cluster Cluster, prin urmare, de fiecare dată când începeți orice demon CEPH, trebuie să respectați aceste setări. În primul rând, ne vom familiariza cu setările CEPH și cu diferitele lor secțiuni și apoi ne vom concentra pe setările de performanță.
Cele mai multe setări de configurare ale întregului cluster sunt definite în setările clusterului CEPH. Dacă nu ați modificat numele clusterului dvs. și locația fișierului de configurare pentru clusterul dvs., numele implicit va fi ceph.conf, și prin intermediul IT /etc/ceph/Chech.conf. Acest fișier de configurare are o secțiune generală, precum și mai multe secțiuni pentru fiecare tip de servicii. Fie la începerea fiecărui tip de servicii CEPH, adică. MON (monitoare), OSD (Dispozitive de stocare a obiectelor) și MDS (servere metadate), aceștia citesc setările definite în secțiunea generală, precum și în secțiunea specifică acestora.
Secțiunea generală este o secțiune definită; Toate instalațiile din această secțiune afectează toate demonii clusterului CEPH. Aici toate setările sunt definite ca fiind aplicate întregului cluster. Mai jos este un exemplu de instalații din această secțiune:
Rețeaua publică \u003d 192.168.0.0/24
Setările specificate în secțiune se aplică tuturor demonilor CEPH-MON din acest cluster CEPH. Setările specificate în această secțiune sunt suprascrie setările definite în secțiune. Mai jos este un exemplu de instalații din această secțiune:
MON IIILE SEMNICE \u003d CEPH-MON1
Setările specificate în secțiune se aplică tuturor demonilor CEPH-OSD din acest cluster CEPH. Setările specificate în această secțiune sunt suprascrie setările definite în secțiune. Mai jos este un exemplu de instalații din această secțiune:
OSD MKFS Type \u003d XFS
Instalațiile specificate în secțiune se aplică tuturor demonilor CEPH-MDS din acest cluster CEPH. Setările specificate în această secțiune sunt suprascrie setările definite în secțiune. Mai jos este un exemplu de instalații din această secțiune:
MDS cache dimensiune \u003d 250000
Setările specificate în secțiune se aplică tuturor clienților CEPH. Setările specificate în această secțiune sunt suprascrie setările definite în secțiune. Mai jos este un exemplu de instalații din această secțiune:
Cache rbd \u003d adevărat
Așa cum am menționat mai devreme, setarea de performanță este foarte specifică înconjurătoare. Miercuri a organizației dvs. și a infrastructurii instrumentului pentru clusterul CEPH este foarte diferită de alte organizații. Lucrurile pe care le-ați înființat în clusterul dvs. pot funcționa și nu pot funcționa în același mod în alte medii. În această secțiune, vom discuta câteva setări de performanță generale pe care le puteți configura mai precis pentru mediul dvs.
Este recomandat să utilizați două rețele separate fizic pentru clusterul dvs. CEPH. Fiecare dintre aceste rețele are destinul său propriu. În conformitate cu terminologia CEPH, aceste rețele sunt numite rețea publică (publice) și rețea de cluster (cluster):
Rețeaua publică se numește, de asemenea, un mediu de rețea al clienților care permite clienților să interacționeze cu clusterele CEPH și să acceseze clusterul pentru datele stocate acolo. Această rețea este evidențiată numai clienților, prin urmare, în această rețea nu se efectuează interacțiuni cu cluster intern. Ar trebui să definiți o rețea publică pentru a configura clusterul CEPH după cum urmează:
Rețeaua publică \u003d (rețea publică / Netmask)
Rețeaua publică \u003d 192.168.100.0/24
Rețeaua de cluster este, de asemenea, numită o rețea internă care este o rețea selectată pentru toate operațiile interne de cluster între nodurile CEPH. Din punctul de vedere al performanței, această rețea trebuie să aibă productivitate decentă În 10 GB sau 40 GB, deoarece această rețea este responsabilă pentru funcționarea unui grup de lățime de bandă mare, de exemplu, replicarea datelor, restaurarea, reechilibrarea și pentru testarea impulsurilor ceasului. Puteți defini o rețea de cluster după cum urmează:
Cluster Network \u003d (rețeaua de cluster / Netmask)
Un exemplu de definiție este prezentat mai jos:
Cluster Network \u003d 192.168.1.0 / 24
Dacă acest parametru este în locul său, iar clusterul CEPH funcționează, acesta stabilește definiția numărului maxim deschideți fișiere la nivelul sistemului de operare. Acest lucru ajută dispozitivul OSD (dispozitivele de stocare a obiectelor) să nu depășească descriptorii de fișiere. Valoarea implicită este 0; Puteți să o configurați în valoarea oricărui număr întreg de 64 de biți.
Să aruncăm o privire la un exemplu:
Fișierele max deschise \u003d 131072
Parametrii enumerați în această secțiune trebuie să fie definiți în secțiunea de fișiere a configurației clusterului dvs. CEPH.
Filestore Queue Max Ops: Acesta este numărul maxim de operațiuni pe care sistemul de fișiere le poate lua înainte de a bloca noi operații pentru a le atașa la coadă. Să aruncăm o privire la următorul exemplu:
Filestore Queue Max Ops \u003d 25000
Filestore Queue Max Bytes: Acesta este numărul maxim de octeți de operațiuni. Mai jos este un exemplu:
Filestore Queue Max Bytes \u003d 10485760
Filestore Queue comit max ops: Aceasta este valoarea maximă a operațiunilor care pot fi înregistrate (comitere) sistem de fișiere. Un exemplu pentru aceasta este următorul:
Filestore Queue comitere max ops \u003d 5000
Filestore Queue comiterea lui Max Bytes: Acesta este numărul maxim de octeți care pot fixa sistemul de fișiere. Aruncați o privire la următorul exemplu:
Filestore Queue comitere Max Bytes \u003d 10485760000
FilesStore Op Fire: Acesta este numărul de operații de sistem de fișiere (filet) care pot fi efectuate simultan. Mai jos este un exemplu:
Filestore Op Fire \u003d 32
Jurnalul Max Scrie Bytes: Acesta este numărul maxim de octeți pe care revista îl poate înregistra la un moment dat. În continuare urmează un exemplu:
Jurnalul Max Scrie Bytes \u003d 1073714824
Jurnal Max Scrierea intrărilor: Aceasta este valoarea maximă a elementelor pe care revista le poate înregistra la un moment dat. Iată un exemplu:
Jurnal Max scrie intrări \u003d 10000
Jurnalul Queue Max Ops: Aceasta este valoarea maximă a operațiunilor permise în coada de revistă la un moment dat. Exemplul său este:
Jurnalul Queue Max Ops \u003d 50000
Jurnalul Queue Max Bytes: Acesta este numărul maxim de octeți, a permis o coadă de reviste la un moment dat în timp. Aruncați o privire la următorul exemplu:
Jurnalul Queue Max Bytes \u003d 10485760000
OSD Max Scrierea dimensiunii: Aceasta dimensiune maximă În Megabytes, care OSD poate înregistra la un moment dat. Mai jos este un exemplu:
OSD Max Scrierea scrierii \u003d 512
OSD Client Mesaj Size Cap: Aceasta este dimensiunea maximă a datelor client din Megabytes, care este permisă în memoria RAM. Un exemplu este:
Mesaj de dimensiune a mesajului clientului OSD \u003d 2048
OSD Deep Scrub Stride: Aceasta este o dimensiune în octeți, care este citită de OSD atunci când efectuează curățenie profundă. Aruncați o privire la următorul exemplu:
OSD Deep Scrub Stride \u003d 131072
Subiecte OSD OS: Acesta este numărul de operațiuni de operațiuni utilizate de daemonul OSD CEPH. De exemplu:
Threads OSD OS \u003d 16
Fire de discuri OSD: Acesta este numărul de fluxuri de disc pentru a efectua operații intensive OSD similare cu recuperarea și curățarea (spălarea). Mai jos este un exemplu:
Fileu de disc OSD \u003d 4
OSD MAP Dimensiune cache: Aceasta este o dimensiune a cache-ului cardului OSD în Megabytes. Mai jos este un exemplu:
OSD MAP Dimensiune cache \u003d 1024
OSD Harta Cache BL Dimensiune: Aceasta este dimensiunea cardului OSD stocat în memorie în Megabytes. Un exemplu este:
OSD Harta Cache BL Dimensiune \u003d 128
Opțiuni de montare OSD XFS: ne permite să menținem opțiunile de montare a sistemului de fișiere XFS. În timpul montării OSD, se va monta cu parametrii de montare propuși. Aruncați o privire la următorul exemplu:
OSD Montare Opțiuni XFS \u003d "RW, NOTIME, INODE64, LOGBSIZE \u003d 256K, DELINAMLOG, ALOCSIZIZE \u003d 4M"
OSD Recovery OP Prioritate: Aceasta este instalarea priorității operațiunilor de recuperare a multor. Cu cât este mai mică valoarea cu cât este mai mare prioritatea de recuperare. Cele mai mari valori ale priorității de recuperare pot provoca probleme de degradare a productivității până când recuperarea este finalizată. Mai jos este un exemplu:
OSD Recovery OP Priority \u003d 4
Recovery OSD Max Activ: Acesta este numărul maxim de solicitări active de recuperare. Cu cât este mai mare valoarea, cu atât este mai rapid restaurarea, care poate afecta performanța globală a clusterului până la finalizarea recuperării. Mai jos este un exemplu:
Recovery OSD Max Active \u003d 10
OSD Max Bowfills: Acesta este numărul maxim de operațiuni pentru completarea OSD-urilor permise. Cu cât este mai mare valoarea, cu atât este mai rapid restaurarea, care poate afecta performanța globală a clusterului până la finalizarea recuperării. Mai jos este un exemplu:
OSD Max Backfills \u003d 4
Atribute extinse : Sunt, de asemenea, cunoscuți ca XATTR, care sunt foarte utile pentru stocarea metadatelor de fișiere. Unele sisteme de fișiere oferă un set limitat de octeți de stocare XATTR. În unele cazuri, atributele avansate bine definite pot ajuta sistemul de fișiere. Parametrii XATTR trebuie să fie utilizați cu sistemul de fișiere EXT4 pentru a obține o performanță bună. Mai jos este un exemplu:
Filestore XATTR Utilizați OMAP \u003d Adevărat
Interval de sincronizare a sistemului de fișiere : Pentru a crea un punct de completare consistent, sistemul de fișiere trebuie blocat de operațiile de înregistrare, precum și efectuarea SYNCF-urilor, care sincronizează datele de jurnal cu secțiunea de date și, astfel, eliberează jurnalul. Execuția mai frecventă a operațiunilor de sincronizare reduce cantitatea de date stocate în jurnal. În acest caz, revista devine incomprehensibilă. Setarea sincronizării rare permite sistemului de fișiere să combine înregistrările mici și putem obține o creștere a productivității. Următorii parametri determină intervalele minime și maxime de timp între două sincronizări:
Filestore Min Interval de sincronizare \u003d 10 Filestore Max Sync Interval \u003d 15
Coadă de sistem de fișiere. : Următoarele setări oferă dimensiunile coadă de sistem de fișiere. Aceste setări pot avea un efect minim de performanță:
Configurarea jurnalului OSD : Demons asistență OSD CEPH următoarele setări Jurnale:
Configurarea configurației OSD : Demons asistență OSD CEPH următoarele instalații Configurații OSD:
Configurarea recuperării OSD : Aceste setări trebuie utilizate atunci când preferați performanța de restaurare sau invers. Dacă clusterul dvs. CEPH este defect și este într-o stare de recuperare, nu puteți obține o performanță normală, deoarece OSD va fi ocupată de recuperare. Dacă încă mai preferați performanța peste restaurare, puteți reduce prioritatea recuperării, astfel încât OSD-ul să fie mai puțin ocupat cu restaurarea. De asemenea, puteți seta aceste valori dacă doriți recuperare rapidă Clusterul dvs. pentru a ajuta OSD să efectueze recuperarea mai rapidă.
Implementarea spațiului dispozitivului de blocare a blocului nu poate aplica avantajele paginilor Linux, astfel încât în \u200b\u200bversiunea CEPH 0,46, a fost introdus un nou mecanism de caching în dispozitivul de blocare a radosului, dispozitive blocate de stocarea autonomă autonomă fără probleme). CEPH implicit nu permite cache-ul RBD; Pentru a rezolva această caracteristică, ar trebui să actualizați secțiunea din fișierul de setare a clusterului CEPH la următorii parametri:
RBD cache \u003d TRUE: Permite cache-ul RBD.
Dimensiunea cache-ului RBD \u003d 268435456: Aceasta stabilește dimensiunea cache-ului RBD în octeți.
Cache rbd max murdar \u003d 134217728: Aceasta este limita datelor modificate în octeți; După o astfel de limită de descriere, datele vor fi resetate la serverul de stocare. Dacă această valoare este setată la 0, CEPH utilizează metoda de cache încrucișată (cache-ul de scriere). Dacă acest parametru nu este utilizat, mecanismul de cache implicit este prin cache.
Cache-ul RBD Max Dirty Age \u003d 5: Acesta este numărul de secunde în care datele modificate vor fi stocate în memoria cache înainte de a fi aruncate pe serverul de stocare.
În ultima secțiune vom discuta diferite setări pe care le puteți defini în fișierul de configurare al clusterului dvs. Acestea au fost sfaturi de reglare complet pe bază de ceph. În această secțiune, vom învăța o serie de tehnici de ajustare generală care vor fi configurate la nivelul sistemului de operare și la nivelul rețelei pentru infrastructura dvs.
Kernel pid max : Acesta este parametrul kernelului Linux care este responsabil pentru identificatorii maxim de identificatori de flux și procese. Partea principală a miezului Linux are o valoare relativ mică kernel.pid_max. Setarea acestui parametru cu o valoare mare pe nodurile CEPH oferă un OSD mai mare (dispozitiv de stocare a obiectelor), de exemplu, OSD\u003e 20 poate ajuta la generarea unui număr mai mare de fluxuri pentru o recuperare mai rapidă și rebalanțare. Pentru a aplica această opțiune, executați următoarea comandă cu drepturile de utilizator rădăcină:
# ECHO 41943033\u003e / proc / sys / kernel / pid_max
Cadre jumbo. : Cadrele Ethernet care au o lungime de peste 1.500 de octeți se numesc cadre Jumbo. Rezoluția cadru Jumbo Pentru toate interfețele de rețea, nodul dvs. Cluster CEPH trebuie să furnizeze o lățime de bandă de rețea mai bună și o îmbunătățire generală a performanței. Ramele Jumbo sunt configurate la nivelul sistemului de operare, dar interfața de rețea și comutatorul de rețea de bază trebuie să suporte cadrele Jumbo. Pentru a permite cadrele Jumbo, trebuie să configurați interfețele laterale ale comutatorului pentru a le primi și apoi continuați să setați la nivelul sistemului de operare. De exemplu, din partea sistemului de operare pentru rezolvarea cadrelor Jumbo pe interfața ETH0, executați următoarea comandă:
# Ifconfig eth0 MTU 9000
9000 octeți informatii utile este limita interfeței de rețea MTU; Pentru ca modificările să fie ireversibile, trebuie să actualizați și fișierul de configurare a interfeței de rețea, / etc / sysconfig / retea-script / IFCFG-ETH0, la MTU \u003d 9000.
disc Dead_ahead : Parametrul READ_AEAD accelerează operațiile de citire a discului prin pre-eșantion și descărcați-le la RAM. Setarea valorilor relativ ridicate de citire_ahead va beneficia de clienți atunci când efectuează operațiuni de citire secvențială. Puteți verifica valoarea setată în prezent Citiți_aead utilizând următoarea comandă:
# CAT / SYS / BLOCK / VDA / QUEUE / READ_AEAD_KB
Pentru a instala mai multă valoare pentru Read_aead, profitați de:
# Echo "8192"\u003e / sys / bloc / VDA / coadă / citit_aad_kb
De obicei, instalarea de către Read_aead este utilizată de clienții CEPH care utilizează RBD. Trebuie să modificați Read_aead pentru toate RBD marcate pentru această gazdă; De asemenea, asigurați-vă că utilizați numele corect al căii dispozitivului.
Tehnologiile de conservare a datelor și rezervările lor au existat timp de mai multe decenii. Una dintre cele mai populare metode de furnizare a datelor fiabile este replicare . Metoda de replicare include stocarea acelorași date în mai multe exemplare în diferite locuri fizice. Această metodă este bună atunci când vine vorba de productivitatea și fiabilitatea datelor, dar crește costul total al sistemului de stocare. Costul total al proprietății (TOC) utilizând metoda de replicare este destul de scump.
Această metodă necesită două ori mai mult spațiu de stocare pentru a oferi redundanță. De exemplu, dacă intenționați să stocați date 1PB cu un factor de replicare. Veți avea nevoie de spațiu de stocare fizic 2pb pentru a memora date replicabile 1pb. Astfel, costul gigaocitelor datelor sistemului de stocare reprodus este semnificativ crescut. Puteți ignora costul de stocare în clustere mici de stocare, vezi modul în care costul a lovit dacă construiți o soluție de stocare hiper-scalabilă bazată pe servere de stocare reproduse.
Într-o astfel de situație, metoda de codificare (codificarea ștergerii) ( Prim.per.: Corectarea erorilor drepte), vine ca un cadou. Acest mecanism utilizat atunci când este stocat atât pentru a proteja datele, cât și fiabilitatea acestora, care este absolut diferită de metoda de replicare. Acesta garantează siguranța datelor prin separarea fiecărui obiect de stocare la părțile mai mici numite porțiuni (bucată), expansiunea lor și codificarea cu bucățile de cifru și, în cele din urmă, să salveze toate aceste porțiuni în diferite zone ale eșecurilor clusterului CEPH.
Funcționalitatea codării WIP a fost introdusă în ediția Firefly CEPH și sa bazat pe o funcție matematică pentru a obține securitatea datelor. ( Prim.per.: În ediția lui Hammer a fost introdusă, chiar mai mult a crescut eficiența recuperării, ocuparea spațiului, variațiile numărului admisibil de eșecuri și personalizabilitatea acestora.), Conceptul general se rotește în jurul următoarei ecuații:
N \u003d k + m
Următoarele elemente explică acești termeni și numirea acestora:
k. : Acesta este numărul de porțiuni care trebuie separate, numite și bucăți de date.
m. : Acesta este un cod suplimentar adăugat la date pentru a asigura securitatea acestora, numită și o parte a codificării (codificarea piesei de codare). Pentru o percepție mai ușoară, îl puteți vedea ca un nivel de fiabilitate.
n. : Acesta este numărul total de piese create după procesul de codare a gripului.
Pe baza ecuației anterioare, fiecare obiect din piscina de codare a CEPH va persista ca k + M. Porțiuni și fiecare porțiune este salvată în OSD în setul curent. Astfel, toate porțiunile obiectului sunt distribuite pe tot parcursul clusterii CEPH, oferind un grad mai mare de fiabilitate. Acum, să explicăm niște termeni utili de frecare:
Restaurare : În timpul recuperării CEPH, avem nevoie de orice k. Porțiuni de la existente n. Porțiuni pentru recuperarea datelor
Nivel de fiabilitate : Când codificați, frecare ceph poate permite pierderi la m. Porțiuni
Comandă de codare (R) : Poate fi calculat prin formula r \u003d k / n Unde r.< 1
Spațiul de stocare necesar : Calculat ca. 1 / R.
De exemplu, ia în considerare piscina CEPH cu cinci OSD, care este creată utilizând regula de codificare Ruisia (3.2). Fiecare obiect stocat în această piscină va fi împărțit în următoarele porțiuni de date și cod:
N \u003d k + m prin analogie, 5 \u003d 3 + 2 în funcție de n \u003d 5, k \u003d 3 și m \u003d 2
Astfel, fiecare obiect va fi împărțit în 3 porțiuni ale datelor și vor fi adăugate două porțiuni ale codului de ștergere, oferind cinci porțiuni care vor fi salvate și distribuite pe cinci piscine de codare OSD prin frecare în cluster Ceff. În cazul refuzului de a construi un fișier original, vom avea nevoie de trei porțiuni din orice cinci porții pentru ao restabili. Astfel, putem transfera pierderea oricărui două OSD, deoarece datele pot fi restaurate utilizând trei OSD-uri.
Comandă de codare (R) \u003d 3/5 \u003d 0,6
Să presupunem că avem un fișier de 1 GB. Pentru a salva acest fișier în clusterul CEPH în puterea de partajare (3.5), veți avea nevoie de spațiu de stocare de 1.6 GB, care va furniza stocarea fișierelor care este rezistentă la defecțiunile a două OSD-uri.
În contrast, metoda de replicare, dacă același fișier este stocat în piscina reprodusă, atunci pentru rezistența la defecțiunea a două OSD CEPH va necesita replicarea cu dimensiunea 3, care necesită în cele din urmă spațiu de stocare de 3 GB pentru depozitarea fiabilă a fișierului de 1 GB. Astfel, atunci când utilizați funcționalitatea codificării răcirii, economisiți aproximativ 40% din costul stocării pentru a obține aceeași fiabilitate ca atunci când replicați.
Pula cu codificare de frecare necesită mai puțin meta la stocarea în comparație cu piscinele replicate; Cu toate acestea, astfel de economii în cantitatea de stocare se realizează datorită costului performanței, deoarece fiecare proces de codificare a stivului împarte fiecare obiect în mai multe porțiuni mai mici și mai multe porțiuni noi codificate sunt amestecate cu aceste porțiuni de date. În cele din urmă, toate aceste porțiuni sunt stocate în diferite zone ale eșecurilor Cluster Ceph. Toate acest mecanism necesită o putere mai ușoară de computere din nodurile OSD. În plus, în momentul recuperării, porțiunile de decodificare necesită, de asemenea, calcule semnificative. Astfel, vă puteți aștepta ca mecanismul de codificare a conjugării să fie oarecum mai lent decât mecanismul de replicare. Metoda de codificare a conjugării depinde în principal de opțiunea de utilizare și puteți obține rentabilitatea maximă a codării ștergării pe baza cerințelor datelor dvs.
Cu ajutorul codării ștergătoarelor, puteți stoca mai mult pentru bani mai mici. Depozitul de refrigerare poate fi o modalitate bună de a utiliza codarea WIP, deoarece este mai puțin frecventă atunci când citiți și scrieți operațiunile; De exemplu, seturi mari de date în care aceste imagini și genom sunt stocate pentru o lungă perioadă de timp fără citire și scriere sau unele tipuri de sisteme de arhivă în care sunt arhivate datele și accesul frecvent nu este făcut.
În mod obișnuit, astfel de poli de codare de stocare sunt construite într-un nivel cu stâlpi mai rapizi cu replicări și, dacă datele nu sunt utilizate într-un anumit timp (câteva săptămâni), ele pot fi mutate într-o piscină cu o codificare de rapidizare cu un cost mai mic în care Performanța nu este principalul criteriu.
Tragerea codificării este implementată prin crearea de piscine CEPH cu un tip de chestii; Fiecare astfel de piscină se bazează pe fișierul parametrilor de codare a alimentării, care determină caracteristicile codării ștergătoarelor. Acum vom crea un fișier de parametri de codare stimulând și un grup de codificare de umplutură pe baza acestuia:
Creați un fișier de parametri de codare WIP:
# CEPH OSD-Profilul de ștergere a codului de codificare a profilului EC-Profil RuletFailure-Domain \u003d OSD K \u003d 3 m \u003d 2
Efectuați o listă de fișiere de fișiere:
# CEPH ESD-Erasure-Profil LS
# CEPH Erasure-Profil-Profil Obțineți profilul EC-Profil # CEPH OSD-code-profil-profil-profil-profile de profil EC-Profil-defect-domeniu \u003d OSD K \u003d 3 m \u003d 2 # CEPH OSD Erasure-Profil LS EC-Profil # CEPH OSD-Erasure-Profilul de cod Obțineți directorul ec-profilului \u003d / USR / LIB64 / CEPH / Cod de ștergere K \u003d 3 m \u003d 2 plugin \u003d Jerasure Ruleset-Fai1Ure-Domain \u003d OSD Technique \u003d Reed_sol_van #
Comanda discutată în această secțiune va crea un fișier parametru de codare de stimulare numit profilul ec-profil cu caracteristicile k \u003d 3 și m \u003d 2, care, respectiv, sunt numărul de porțiuni de date și codificare. Astfel, fiecare subiect care trebuie salvat obiectul va fi împărțit în porțiuni 3 (k) ale datelor și 2 (m) vor fi adăugate, vor fi adăugate porțiuni de codare suplimentare, având un rezultat de porțiuni 5 (K + M) . În cele din urmă, aceste porțiuni 5 (k + m) sunt distribuite în diferite zone OSD de eșec.
Creați tipul de puls de frecare, care se va baza pe fișierul parametru al codului de ștergere, pe care l-ați creat 1 pas:
# CEPH Pool Pool Creați ec-piscină 16 16 Erasure EC-Profil
Verificați starea bazei dvs. nou create; Trebuie să găsiți că dimensiunea bazinului 5 (k + m), adică Dimensiunea rezultatului 5. În consecință, datele vor fi înregistrate în cinci OSD diferite:
# Ceph Dump | GREP -I EC-Pool # Cefh OSD Pool Creare EC-Pool 16 16 Ștergerea profilului EC Profilul "EC-Pool" Creat # # Ceph Dump | GREP -I Bool Pool 15 "EC-Pool" Dimensiune de ștergere 5 min_size 1 Crush_ruleset 3 Object_Hash Rjenkins Pg_num 16 PGP_NUM 16 Last_change 975 Proprietar 0 Steaguri Hashpspool Stripe_Width 4128 #
Acum avem o nouă piscină Ceph, care are tipul de ștergere. Acum trebuie să punem câteva date în această piscină, creând un fișier de exemplu cu un conținut aleatoriu și plasați-l în Pula de la Cercetător nou creat:
# Echo "Mona" Mona este acum Testarea Codului Erasure CEPH "\u003e Filel.txt # Cat Filel.txt Mona este acum Testarea Codului Erasure CEPH # Rados-Pp EC-Pool LS # Rados Pune-PP Obiect de piscină1 File1.txt # Rados - P Piscina LS Obiect1 #
Verificați cardul OSD pentru Piscina EC și Obiect1. Ieșirea acestei comenzi va face detaliile identificatorilor de ASD care pot fi ușor de înțeles în care sunt stocate porțiunile de obiecte. După cum se explică în 1 etapă, obiectul1 este împărțit în 3 (m) porțiuni de date și este completat de 2 (k) porțiuni codificate; În consecință, împreună cinci porții au fost depozitate în diverse OSD-uri pe tot parcursul clusterului CEPH. În această demonstrație, obiectul1 a fost salvat în cinci OSD, și anume OSD.7, OSD.6, OSD.4, OSD.8 și OSD.5.
# Ceph OSD MAP Obiect de piscină EC1 OSDMAP E976 Pool "EC-Pool" (15) Obiect "Obiect1" -\u003e PG 15.BAC5DEBC (15.C) -\u003e UP (P7) Acționează (P7) #
În momentul în care am instalat o piscină de frecare în clusterul CEPH. Acum, vom încerca în mod deliberat să distrugem OSD pentru a vedea cum se va comporta piscina de ștergere atunci când OSD este inaccesibil.
După cum se menționează în etapa anterioară, unele OSD pentru piscina de frecare sunt OSD.4 și OSD.5; Acum testăm fiabilitatea bazinului de frecare a distrugerii acestor OSD unul după altul.
Instruiți OSD.4 și verificați cardul OSD pentru Piscina EC și Obiect1. Trebuie să observați că OSD.4 se înlocuiește cu numărul aleator 2147483647, ceea ce înseamnă că OSD.4 nu mai este disponibil pentru această piscină:
# SSH CEPH-NODE2 SERVICE CEPH STOP OSD.5 # Ceph OSD MAP Obiect EC-Pool Object1 # SSH CEPH-NODE2 SERVICE CEPH STOP OSD.4 \u003d\u003d\u003d OSD.4 \u003d\u003d\u003d Oprirea CEPH OSD.4 pe CEPH-NODE2 .. .kill 4542 ... Termen Harta OSD Obiect EC-Pool Object1 OSDMAP E980 POO1 'EC-Pool "(15) Obiect" Obiect1 "-\u003e PG 15.BAC5DEBC (15.c) -\u003e UP (P7) Acționând (, P7) #
În mod similar, ieșiți un alt OSD, adică OSD.5 și să acorde atenție cardului OSD pentru Piscina EC și Obiect1. Trebuie să observați că OSD.5 se înlocuiește cu numărul aleator 2147483647, ceea ce înseamnă că OSD.5 nu mai este disponibil pentru această piscină:
# SSH CEPH-NODE2 serviciu CEPH STOP OSD.5 \u003d\u003d\u003d OSD.5 \u003d\u003d\u003d Oprirea Ceph OSD.5 Pe Cephh-Node2 ... Kill 5437 ... Terminat # # # Ceph OSD MAP Obiect de piscină CE1 OSDMAP E982 Piscină "EC-Pool" (15) Obiect "Obiect1" -\u003e PG 15.BAC5Debc (15.c) -\u003e UP (, P7; Actory (, P7)
Acum, piscina CEPH operează pe trei OSD, care este minimul necesar pentru acest bazin de instalare de frecare. După cum sa discutat deja mai devreme, orice trei porțiuni de cinci vor avea nevoie de fondul ecologic pentru serviciul de date. Acum avem doar trei porții, și anume, OSD.7, OSD.6 și OSD.8, și încă avem date disponibile.
# Rados-PP EC-Pool LS Obiect1 # Rados GET-PP EC-Pool Object1 / TMP / FILE1 # CAT / TMP / File1 Mona nu testează codarea Erasure CEPH
Astfel, codificarea de frecare oferă CEPH cu fonduri de fiabilitate și, în același timp, mai puțin spațiu de stocare este necesar pentru a asigura fiabilitatea.
Tragerea funcționalității de codare oferă avantaje semnificative ale fiabilității arhitecturii CEPH. Când CEPH determină inaccesibilitatea oricărui dintre zonele de defectare, începe operația de recuperare de bază. De-a lungul operației de recuperare, Pula Pula se reconstruiește prin decodificarea porțiunilor refuzate pe noul OSD și, la urma urmei, ele fac toate porțiunile disponibile automat.
În ultimii doi pași, discutați mai devreme, am dezactivat în mod intenționat OSD.4 și OSD.5. După un timp, acesta lansează recuperarea ceph și actualizarea porțiunilor pierdute la diverse OSD-uri. Când operațiunile de recuperare sunt finalizate, trebuie să verificați Piscina EC și Obiect1; Veți fi surprinși să vedeți noi identificatori, cum ar fi OSD.1, OSD.2 și OSD.3 și, astfel, grupul de frecare devine viabil fără intervenția administratorului.
# CEPH STAT OSDS OSDMAP E1025: 9 OSD: 7 Up, 7 în # # CEPH Hartă OSD EC-Pool Object1 OSDMAP E1025 Pool "EC-Pool" (15) Obiect "Obiect1" -\u003e PG 15.BAC5Debc (15.c) -\u003e UP (P7) care acționează (, p7)
Acesta este modul în care CEPH și codificarea ștergerii fac o combinație semnificativă. Funcționalitate Tragerea codificării sistemelor de stocare, cum ar fi CEPH, care sunt scalabile la nivelul petabetelor și mai mari, vor fi nelimitate de a oferi un raport eficient în valoare, o metodă de stocare fiabilă.
Ca și codarea de frecare, funcționalitatea cache-ului multi-nivel a fost introdusă și în Ediția Firefly CEPH și a fost una dintre cele mai discutate caracteristici ale Firefly CEPH. Caching-ul multi-nivel creează o piscină ceph care va fi construită pe partea de sus a celor mai rapide discuri, de obicei SSD. O astfel de piscină de caching trebuie plasată înainte de piscina obișnuită, replicată sau piscina cu puzzle, astfel încât toți clienții operațiunile de intrare / ieșire să fie mai întâi tratate cu piscină de caching; După aceasta, datele sunt resetate la fondurile de date existente.
Clienții beneficiază de performanțe de înaltă cache de cache, în timp ce datele sunt înregistrate în mod transparent în bazinele convenționale.
De regulă, memoria cache este construită pe partea de sus a discurilor SSD mai scumpe / mai rapide, astfel încât oferă clienților o performanță mai mare I / O. Piscina de caching are un nivel de stocare care se realizează pe discuri cu arbore cu un tip de replicare sau ștergere. Cu acest tip de instalare, clienții oferă o cerere I / O la piscina de cache și primesc răspunsuri instantanee la cererile lor, ci lectură sau înregistrare; Cel mai rapid nivel de cache servește cereri de clienți. După ceva timp, nivelul cache-ului își resetează toate datele privind nivelul principal de stocare, astfel încât acesta poate memora noile cereri de la clienți. Toate mișcările de date între nivelurile cache și de stocare sunt automat și transparente clienților. Caching-ul multi-nivel poate fi configurat în două moduri.
Când nivelul de cache a cefalei este configurat în modul de înregistrare, clienții CEPH scriu date în piscina de cache, adică în cea mai rapidă piscină și, prin urmare, primește instantaneu confirmarea. Pe baza politicii de evacuare / îndepărtare, pe care ați instalat-o pentru caching-ul dvs. cu mai multe niveluri, datele sunt mutate din nivelul cache al unui agent de caching multi-nivel. În timpul operațiunilor cititorului, datele sunt mutate de la nivelul de stocare la nivelul cachezei agentului de cauculare multi-nivel și apoi sunt furnizate clientului. Datele rămân la nivelul cache până când vor deveni inactivi sau până când își pierd relevanța.
Când nivelul CAZH CEPH este configurat să citească numai, funcționează numai pentru operațiile de citire a clienților. Operațiunile de înregistrare a clienților nu sugerează cache-ul multi-nivel, dimpotrivă, toate înregistrările clienților sunt efectuate la nivel de stocare. În timpul operațiunilor de citire a clientului, un agent de caching multi-nivel copiază datele solicitate de la nivelul de stocare la nivelul de cache. Pe baza politicii pe care ați creat-o pentru caching-ul dvs. cu mai multe niveluri, obiectele expirate sunt eliminate din acesta. O astfel de abordare este ideală atunci când sunt necesare mai mulți clienți pentru a citi volume mari de date similare.
Nivelul cache este implementat pe cele mai rapide discuri fizice, de obicei SSD, care oferă un nivel de cache rapidă peste piscinele tradiționale mai lente făcute pe discuri ax. În această secțiune vom crea două bazine separate, o piscină cache și o piscină obișnuită, care va fi utilizată în consecință ca nivel de cache și nivel de depozitare.
ÎN Capitolul 7. Funcționarea și întreținerea CEPH Am discutat despre procesul de creare a bazinelor CEPH pe anumite OSD (dispozitivele de stocare a obiectelor) prin schimbarea cardurilor de strivire (gestionate de hash-ul de replicare scalabil, replicarea controlată sub hashing scalabil). În mod similar, vom crea o piscină de la Casha care se va baza pe OSD.0, OSD.3 și OSD.6. Deoarece nu avem SSD-uri reale pentru o astfel de instalare, vom presupune că aceste OSD sunt SSD și creează o piscină de caching peste ele. Următoarea este o instrucțiune de creare a unei bazine de caching pe OSD.0, OSD.3 și OSD.6.
Afișați o listă cache-piscină. pentru conținut; Deoarece aceasta este o nouă piscină, nu ar trebui să aibă niciun conținut:
# Rados -p cache-piscină ls
Adăugați un obiect arbitrar în cache-piscină. Pentru a vă asigura că stochează obiecte în OSD corect:
# Rados-PP Pool-Pool Put Object1 / etc / Hosts
# Rados -p cache-piscină ls
Verificați cardul OSD pentru cache-piscină. și obiect1 . Dacă ați configurat Crush Catrut corect, obiectul1 trebuie să fie stocat în OSD.0, OSD.3 și OSD.6, deoarece dimensiunea replicării este de 3:
# CEPH OSD MAP WITH Pool Object1
Scoateți obiectul:
# Rados-PP-Pool-Pool RM Obiect1 # Rados -p cache-piscină LS # Rados-PP Pool-piscină Pune Obiect1 / etc / Hosts # Rados-Pp Piscină LS Obiect1 # Ceph OSD Harta Cache-Pool Object1 OSDMAP E1143 Piscină "Piscina de cache" (16) Obiect "Obiect1" -\u003e PG 16.BAC5DEBC (16.1C) -\u003e UP (P3) Acting (, P3) #
Obțineți Crush Crush Crush și decompila:
# Ceph OSD Getcroushmap -o Crosshmapdump # Crushtool -d Crushmapdump -o Crushmapdump-decompiled
Schimbați fișierul de card decompilați și adăugați următoarea secțiune după secțiune. root implicit. :
# Vim Crushmapdump-descompile Cache Root (ID -5 Alg Hash Hash 0 articol OSD.0 Greutate 0.010 item OSD.3 Greutate 0.010 item OSD.6 Greutate 0.010)
Creați regula de strivire adăugând următoarea secțiune după secțiune reguli. , Situată de obicei la sfârșitul fișierului. În cele din urmă, salvați fișierul cardului de strivire și părăsiți editorul:
Regula cache-piscină (seset 4 tip replicat min_size 1 max_size 10 pas luați cache etapa de cache Cleiflef FirstN 0 tip OSD emit)
Compilați și introduceți o nouă carte de strivire la clusterul CEPH:
# CRUSHTOOL -C CRUSHMAPDMP-decompiled -O Crosshmapdump-compilate # CEPH OSD SetCrushmap -i Crushmapdump-compilate
Deoarece a fost aplicată clusterul CEPH harta nouă. Zdrobiți, trebuie să verificați starea OSD pentru a vedea noua locație OSD. Veți găsi un nou segment de cache a rădăcinii:
# Ceph OSD Tree # Ceph OSD copac #D # Tip greutate Nume Up / Down Reweight -5 0.02998 Root Cache 0 0.009995 OSD.0 Up 1 3 0.009995 OSD.3 Up 1 6 0.009995 OSD.6 Up 1 -1 0.09 Root implicit -2 0.03 HOST CEPHH-NODE1 1 0.009995 OSD.1 Up 1 2 0.009995 OSD.2 Up 1 0 0.009995 OSD.O Up 1 -3 0.03 Host Cephh-Nod2 3 0.009995 OSD.3 Up 1 5 0.009995 OSD.5 Up 1 4 0.009995 OSD .4 Up 1 -4 0.03 gazdă CEPH-NODE3 6 0.009995 OSD.6 Up 1 7 0.009995 OSD.7 Up 1 8 0.009995 OSD.8 Up 1 #
Creați o nouă piscină și setați valoarea. crush_ruleset. egal 4 În consecință, va fi creată o nouă piscină pe discurile SSD:
# Ceph OSD Pool Creați cache-piscină 32 32 # Ceph OSD Set de piscină cache-piscină Crush_ruleset 4 # Ceph OSD Pool Set Cache-Pool Crush_ruleset 4 Set Pool 16 Crush_ruleset la 4 # Ceph Dump OSD | GREP -I Piscina de cache-piscină 16 "cache-piscină" Dimensiune reprodusă 3 min_size 1 Crush_ruleset 4 Object_Hash Rjenkins Pg_num 32 pgp_num 32 Last_change 1142 Proprietar 0 Steaguri Hashpspool Stripe_Width 0 #
Asigurați-vă că piscina este creată corect, adică Ar trebui să salveze întotdeauna toate obiectele pe OSD.0, OSD.3 și OSD.6:
În secțiunea anterioară, am creat o piscină bazată pe SSD; Acum vom folosi acest glonț ca un caching multi-nivel pentru o piscină cu o codificare de stimulare numită Ec-bazin pe care l-am creat înainte în acest capitol.
Următoarele instrucțiuni vă vor oferi un manual pentru a crea o cache multi-level cu modul de înregistrare și impunerea de suprapunere Ec-bazin :
Instalați o cache cu mai multe niveluri pentru a conecta bazinele de stocare cu bazine de cache. Sintaxa acestei comenzi: CEPH OSD Tier Adaugă
# Ceph OSD Adăugați cache-ul de cache ecologic
Setați modul caching pentru a scrie sau numai pentru citire. În această demonstrație, folosim scrisul și sintaxa pentru acest lucru va fi astfel CEPH OSD Tier CaChemode
# CEPH OSD Tier cache-mod cache-scris
Pentru a trimite toate solicitările clienților de la piscina standard la piscina de caucizare, setați suprapunerea (suprapunerea) și sintaxa pentru aceasta va fi următoarea Ceph OSD Set-Suprapunere
# CEPH OSD Set-Set-Overlay Cache-ul cu piscină ec-CAPE # CEPH OSD Adăugați piscina cache-piscină ecologică "cache-piscină" este acum (sau deja a fost) un nivel al "ec-piscine" # cache de nivel CHEPH OSD -MODE-Pool Set Set Set Cache-Mod pentru piscină "cache-piscină" pentru a scrie # Ceph OSD Set-Set-Overlay Pool Supralay pentru "ec-piscina" este acum (sau deja a fost) "cache-piscină "#
Când verificați detaliile bazinului, rețineți că Ec-bazin Are un nivel, Citit_Tier și Write_Tier setat la 16, care este identificatorul bazinului pentru cache-piscină. .
Similar cu cache-piscină. Instalațiile vor fi după cum urmează: TIER_OF este setat la 15 și cache_mode la valoarea de scriere; Toate aceste setări implică faptul că piscina de caching este configurată corect:
# Ceph Dump | Egrep -i "EC-Pool | cache-piscină" # Ceph Dump | EGREP -I "Piscina ecrep" Piscina cache "Piscina 15" EC-Pool "Size de ștergere Min_Size 5 1 3 Crush_Rauleset Object_hash Rjenkins Pg_num 16 PGP_NUM Last_change 16 1181 0 Proprietar Steaguri Hashpspool Tiers Citit_Tier 16 16 16 Marker_Tier Stripe_Width 4128 Pool 16" Cache -Pool "replicat dimensiune 3 min_size 1 crush_ruleset 4 obiecte_hash rjenkins pg_num 32 pg p_num 32 last_change 1181 Proprietar 0 Steaguri Hashpspool tier_of 15 cache_mode writeback Stripe_Width 0 #
Caching-ul multi-nivel are un număr de parametri de configurare; Ar trebui să configurați caching-ul multi-nivel pentru a seta politica pentru aceasta. În această secțiune, vom configura politicile de caching multiple:
Activați utilizarea urmăririi în setul pentru piscina de cauching; Cache-ul nivelului de producție multi-nivel utilizează filtrarea neclară (Bloom):
# CEPH OSD set de piscină cache-piscină hit_set_type floom
Faceți un Hit_set_count accesibil, care este numărul de hituri dintr-un set pentru salvarea într-o piscină în cache:
# Ceph OSD set de piscină cache-piscină hit_set_count 1
Faceți un Hit_set_Period accesibil, care este durata perioadei de lovire în setul în câteva secunde pentru piscina cache:
# CEPH OSD Pool Set Cache-Pool Hit_set_Period 300
Efectuați un țint_max_byte accesibil, care este numărul maxim de octeți, pentru a obține pe care un agent de caching multi-nivel începe să reseteze / evalueze obiectele din piscina cache:
# Ceph OSD set de piscină cache-piscină țintă_max_bytes 1000000 # set de piscină OSD Ceache-Pool Hit_set_type Bloom set Pool 16 hit_set_type la Bloom # Ceph OSD Pool Set Cache-Pool Hit_set_Count 1 Set Pool 16 Hit_set_Count la 1 # Ceph OSD Pool Setați cache-piscină Hit_Set_Period 300 Set Pool 16 Hit_Set_Period la 300 # Ceph OSD Set Pool Set Cache-Pool Targeljnax_bytes 10000000 Set Pool 16 Target_max_bytes la 10000000 #
Pune la dispoziție cache_min_flush_age și cache_min_evict_age, care sunt timp în secunde, după care un agent de caching multi-nivel începe să reseteze instalațiile învechite dintr-o piscină cache la nivelul de depozitare:
# CEPH OSD set de piscină cache-piscină țintă_max_objects 10000
Efectuați un dispozitiv de țintire accesibilă, care este numărul maxim de obiecte, pentru a obține pe care un agent de cache a multi-nivel începe să reseteze / evalueze obiectele din piscina cache:
# Set de piscine OSD cache-piscină cache_min_flush_age 300 # Ceph OSD set de piscină cache-piscină cache_min_evict_age 300 # Ceph OSD bazin set de piscină cache-piscină țintă_max_objects 10.000 Set Pool 16 Target_max_objects la 10.000 # Ceach Bool-Pool Cache_Min_Flush_age 300 Set Pool 16 cache_min_flush_age la 300 # CEPH OSD set de piscină cache-piscină cache_min_evict_age 300 Set Pool 16 cache_min_evict_age la 300 #
Faceți un cache_target_dirty_ratio accesibil, care este procentul obiectelor "neclare" (modificate) ale bazinului cache al cache-ului pentru a obține pe care un agent de cache a multi-nivel începe să le elibereze la nivelul de depozitare:
# CEPH OSD set de piscină cache-piscină cache_target_dirty_ratio0101
Efectuați un cache_target_full_ratio accesibil, care este procentul de obiecte de referință pentru cache non-modificate pentru a obține un agent de cache pe mai multe niveluri începe să le reseneze la nivelurile de depozitare:
# Cefh OSD set cache-piscină cache_target_full_ratio .02
Creați o dimensiune temporară de 500MB, pe care o folosim pentru a înregistra în Ec-bazin și care va fi în cele din urmă înregistrată în cache-piscină. :
# DD dacă \u003d / dev / zero de \u003d / tmp / file1 bs \u003d 1M număr \u003d 500
Următoarele instantanee afișează comenzile anterioare în secțiunea:
# CEPH OSD set de piscină cache-piscină cache_target_dirty_ratio .01 Setați piscina 16 cache_target_dirty_ratio la .01 # CEPH OSD Pool Set cache-piscină cache_targetl_full_ratio.02 Setați piscina 16 cache_target_full_ratio la .02 # # DD dacă \u003d / dev / zero de \u003d / TMP / File1 BS \u003d 1M Count \u003d 500 500 + 0 înregistrări în 500 + 0 înregistrează 524288000 octeți (524 MB) copiat, 1.66712 s, 314 MB / s #
La momentul timpului, am creat și configurați cache-ul multi-nivel. Apoi, îl testați. După cum sa explicat mai devreme, în timpul operației de înregistrare a clientului, datele par au fost scrise într-o piscină regulată, dar, de fapt, sunt scrise în piscina cache, ca rezultat al cărui clienții primesc un avantaj de la Fast I / O. Pe baza politicilor de cache cu mai multe niveluri, datele sunt mutate transparent din piscina cache la bazinul de stocare. În această secțiune, testăm instalarea cache-ului cu mai multe niveluri prin înregistrarea și observarea obiectelor în cache și nivelurile de depozitare:
În secțiunea anterioară, am creat un fișier de testare în dimensiune în 500MB Numed / TMP / FILE1; Acum vom pune acest fișier în Ec-bazin :
# Rados-Pp Pool Pout Object1 / Tmp / File11
În măsura în care Ec-bazin cached. cache-piscină. , File1 nu ar trebui înregistrată în Ec-bazin În primul stat. Ar trebui înregistrată în cache-piscină. . Răsfoiți fiecare piscină pentru a primi nume de obiect. Utilizați comanda dată pentru a urmări timpul și schimbarea:
# Rados-Pp ec-piscină LS # Rados -p cache-piscină LS # Date # Rados-PP Pool Pune Obiect1 / TMP / File1 # Rados-Pp EC-Pool LS # Rados -p Cache-Piscină LS Obiect1 # # Data Sun 14:14:58 EEST 2014 #
După 300 de secunde (am configurat cache_min_evict_age cu 300 de secunde), un agent de caching multi-nivel se va mișca obiect1 de cache-piscină. în Ec-bazin ; obiect1 va fi scos din cache-piscină. :
# Rados-PP-Piscina LS # Rados -P cache-piscină LS # data # data soarelui 14 02:27:41 EEST 2014 # Rados-Pag-Pool LS Obiect1 # Rados-PP Piscina este #
După cum sa explicat în extrădarea anterioară, datele se deplasează de la cache-piscină. în Ec-bazin După un anumit timp.
CEPH vine cu un program de testare de referință încorporat numit Bench Rados. folosit pentru a măsura depozitarea obiectelor CEPH. În această secțiune, vom folosi bancul Rados pentru a obține valorile de performanță ale clusterului nostru CEPH. Așa cum am folosit pentru nodurile virtuale CEPH cu o configurație scăzută, nu ar trebui să ne bazăm pe rezultate cu valori bune de performanță în bancul Rados pentru această demonstrație. Cu toate acestea, puteți obține valori bune de performanță atunci când utilizați echipamentul recomandat atunci când implementați CEPH cu o performanță configurată.
Sintaxa utilizării acestui instrument este: Rados Bench-PP.
Parametrii admisibili Pentru Bench Rados sunt următoarele:
P sau --Pool: numele Pula
T: Acesta este numărul de operațiuni simultane; Valoarea implicită 16.
No-Cleanup: Datele temporare înregistrate în piscina de date Rados Bench nu trebuie curățate. Aceste date vor fi utilizate pentru operațiile de citire atunci când sunt utilizate cu citiri consecutive sau aleatorie. Se aplică curățarea implicită.
Odată cu aplicarea sintaxei de mai sus a MV va executa acum câteva teste ale bancului Rados:
O înregistrare de testare de 10 secunde pe piscina de date va crea o ieșire ulterioară. Este important să rețineți că lățimea de bandă a benzii de ieșire (MB / S) Rados, care pentru instalarea noastră este de 13,412, ceea ce este un indicator foarte scăzut, deoarece avem un cluster virtual CEPH. Alte detalii pe care le urmăm sunt numărul total de înregistrări efectuate, volumul înregistrat, latența medie etc. Așa cum am folosit Flag-ul de curățare, datele înregistrate de date nu vor fi șterse și vor fi utilizate în operațiunile de tranziție și de lectură Rados Bench:
# Rados Bench-Pag Date 10 Scrieți -NO-Cleanup # Rados Bench -P Date 10 Scrieți - Nr-Cleanup Menținerea a 16-a scrieri de 4194304 Byets timp de până la 10 secunde sau 0 obiecte obiect prefix: Benchmark_Data_ceph-NODE1_26928 SEC CURON OPS A început finisat AVG MB / S CUR MB / S Ultimul Lat Avg Lat 0 16 16 0 0 0 - 0 1 16 16 0 0 0 - 0 2 15 18 3 4.88541 6 2.4189 2.12187 3 16 24 8 9.21183 20 3.31423 2.59351 4 16 25 9 8.04351 4 1.90747 2.51728 5 16 29 13 9.48749 16 5.37976 3.26326 6 16 29 13 8.02065 0 - 3.26326 7 16 33 19.07075 8 5.23925 3.3801 8 16 35 19.9441 8 3.31397 3.59352 9 15 39 24 10.0899 20 2.52773 3.98084 10 16 40 24 9.12944 0 - 3.98084 11 15 41 26 9.03055 4 4.05948 4.23526 Timpul total de funcționare: 12.227935 Total scrieri: 41 Dimensiune de scriere: 4194304 Lățime de bandă (MB / SEC): 13.412 Lățime de bandă STDDEV: 7.60183 Max lățime de bandă (MB / SEC): 20 min lățime de bandă (MB / SEC): 0 Latență medie: 4.61251 Latence STDDEV: 2.54733 Max Latency: 11.7108 min Latență: 1.17417 #
Efectuați testarea bazinului de date de citire secvențială:
# Rados Bench-PP 10 SEQ # Rados Bench-PP Date 10 SECV SEC CUR OPS a început Finalizat AVG MB / s Cur MB / s Ultimul LAT AVG LAT 0 12 12 0 0 0 - 0 1 15 21 6 23.7445 24 0.365323 0.517866 2 15 25 10 10 19.889 16 1.91165 0.947636 3 16 31 15 19.9216 20.832548 1.1234 4 16 36 20 19.8804 20 3.81842 1.623 5 16 41 25 19.9027 20 2.4696 1.94785 6 15 41 26 17.2372 4 1.4177 1.92746 Timp total Run: 6.807863 Total Citește: 41 Citiți Dimensiune: 4194304 Lățime de bandă (MB / SEC): 24.090 Latență medie: 2.48104 Max Latency: 6.38046 min Latență: 0.365323 #
Efectuați o șansă de testarea bazinului de date de referință aleatoriu:
# Rados Bench-PP 10 Randos Bench-PP 10 0 0 0 0 0 0 - 0 1 15 27 27.8596 28 0.Ac 1 15 27 27.8596 28 0.300826 0.468331 2 16 27 11 21.8062 16 0.237253 0.635548 3 16 34 18 23.6913 28 1.52991 1.18525 4 15 36 21 20.7954 12 3.7988. 47 23.0549 20 4.173 2.33454 9 16 69 53 23.1574 24 2.31493 2.294 10 2.45812 2.32087 11 4 73 69 24.32087 48 3.27041 2.3137 Timpul total: 11.206381 Total Citește: 73 Dimensiune citire: 4194304 Lățime de bandă (MB / SEC): 26.057 Latență medie: 2.38341 Max Latency: 5.19721 Min Latență: 0.188254 #
În acest fel, puteți dezvolta creativ opțiuni de testare bazate pe operații de scriere, citire și citire aleatorie pentru piscina dvs. CEPH. Rados Bench este o utilitate rapidă și ușoară a testelor de referință și o bună parte constă în faptul că vine cu Cef.
Configurarea performanței și testelor de referință vă va face clusterul CEPH al clusterului de nivel industrial. Ar trebui să efectuați întotdeauna o configurație fină a clusterului dvs. CEPH înainte de ao executa în producție utilizând o pregătire, dezvoltare sau testare ridicată. Stabilirea performanței Tematică extinsă și există întotdeauna spațiu pentru tuning în fiecare mediu. Trebuie să aplicați un set de instrumente de performanță pentru a măsura clusterul CEPH și, pe baza acestor rezultate, puteți efectua acțiunile necesare.
În acest capitol, am analizat cele mai multe setări pentru clusterul dvs. Ați învățat subiecte complexe, cum ar fi setarea de productivitate din punct de vedere atât echipamentele, cât și software-ul. Acest capitol conține, de asemenea, o explicație detaliată a caracteristicilor de codificare a codului de codificare a Fusion și multi-level cu discuție ulterioară a instrumentului de instrumente CEPH built-in pentru testarea de referință, banca Rados
Un post interesant pe Habré, descriind experiența gazdelor Web din First în încercările sale de a face un cluster CEPH și o descriere cinstită a tuturor unor părți semnificative a problemelor pe care le întâmpină în acest proces. Citirea utilă și rău pentru toți cei care consideră CEPH ca o soluție de clasă a întreprinderii.
Pe scurt, rularea despre lecții învățate:
* Procesul de "lecții de învățare" a durat aproximativ doi ani, până în prezent. Prima versiune a fost asamblată în toamna anului 2014.
* Nu toate serverele x86 "sunt la fel de utile". Cumpărat în mod specific sub clusterul de server sa dovedit a fi buggy.
Pentru a încerca o nouă arhitectură și a scăpa de deficiențele anterioare, a colectat o bancă de testare. Și aici sa dovedit interesant - serverele au fost cumpărate special pentru a construi prima versiune sa dovedit a fi "palis". Anvelopa sistemului Toate serverele au lucrat încet. Ca urmare, toate dispozitivele asociate cu punțile de nord și sud sunt cardurile IB conectate prin PCI-E, discuri, memorie - au funcționat încet. Aceasta a explicat majoritatea problemelor pe care le-am întâlnit. Ca un eșantion, au luat mai multe noduri gratuite, pe care de obicei executăm clienți VDS. Pentru cei. Caracteristicile aproape nu au fost diferite. Asamblat și lansat un cluster pe aceste mașini, a început să conducă teste. Totul zboară! ... a cumpărat noi servere bazate pe Xeon 2630 ...
* Departe de schema de recuperare a optimității în CEPH, necesitând ajustarea manuală.
Clusterul a fost cuplat cu sarcinile - când discurile sau nodul eșuează, a continuat să funcționeze. Cu toate acestea, fiecare dezechilibru sa transformat într-o situație critică. Când adăugați un nou disc netezită vârful de leasing utilizând greutăți. Greutatea este responsabilă pentru utilizarea unui anumit suport fizic. Instalare disc nou, Am pus greutatea 0 - discul nu este utilizat. După aceea, creștem greutatea treptată, iar suprafețele apar cu porțiuni mici. Dacă discul nu reușește, greutățile nu funcționează: ~ 1 TB Replica trebuie să fie "mirosiți" în funcție de discurile rămase imediat, iar Ceff ajunge la modul de înregistrare a datelor, descărcarea discurilor "goale".
* Reconstruirea clusterului CEPH în mișcare ridică o sarcină semnificativă pe servere și afectează aplicarea normală a aplicațiilor
* Pentru a construi un sistem hiper-converged în forma pură, atunci când aceleași servere sunt nodurile de depozitare și gazdele de virtualizare, CEPH sa dovedit a fi nepotrivită.
Cu o creștere a numărului de VD-uri, clusterul a început să funcționeze instabil și am transferat mașinile client la nodurile obișnuite. ...
După mai multe iterații, a devenit clar că situația nu se schimbă dramatic. Ei au decis să transfere clienții la noduri obișnuite și să desființeze clusterul.
Prima versiune de cluster nu a îndeplinit așteptările. Clienții cu care se confruntă frânele de disc și am plătit prea mult timp suport tehnic cluster.
* Un sistem dezechilibrat cu "pentru a salva" cu o capacitate mare de discuri SATA a devenit o problemă cu creșterea încărcăturii.
* Rețeaua distribuită înregistrări în depozit, fără localitate de date, simultan cu un cluster de încărcare ridicat pentru intrarea - răul.
* SSD în modul cache într-o serie de situații specifice, de exemplu, înlocuirea discului și a suprafeței ulterioare, funcționează prost.
Aproximativ 5 luni, sistemul a lucrat remarcabil, bucuros-ne și clienții. Deci, până când numărul clienților a atins valoarea critică. Discurile capabile de 4-8 tb încă ne-au urcat în lateral. Când umpleți jumătatea discului, sa transformat într-o sticlă de gât - un număr mare de fișiere aparținând diferitelor VD-uri au fost localizate pe un media fizic și a trebuit să servească un număr mare de clienți. Atunci când este în afara ordinii, dezechilibrul a trecut, de asemenea, greu - este necesar să redistribuie o cantitate mare de informații. SSD-cache în astfel de condiții nu a făcut față îndatoririlor ei. Mai devreme sau mai târziu, discul cache-ului a fost copleșit și a dat un semnal - de acum încolo că fac ceva, dar doar scriu o informație salvată pe un HDD lent. Discul HDD se confruntă cu o sarcină dublă în acest moment - procesează apeluri directe care sunt transmise de cache și scrie date salvate în memoria cache. Depozitul a funcționat bine până când cazul a atins modificarea configurației discului. Discarea discului sau adăugarea unui nou a încetinit lărgimea totală a repoziției.
* Codul CEPH de calitate scăzută, poate duce la probleme serioase cu distrugerea stocării datelor.
Utilizați CEPH LTS. Nu numărați ceea ce veți rostogoli o nouă versiune cu fiecare versiune. Actualizarea este o operație de stocare potențial periculoasă. Tranziția la noua versiune va duce la modificări ale configurilor și nu este un fapt că depozitul va câștiga după actualizare. Urmăriți bugfixele - sunt susținute din versiuni noi în cele vechi.
* Bug-urile pot distruge atât lucrarea clusterului ca întreg, cât și conținutul depozitului.
18 februarie 2016 Am întâlnit bug-ul critic al CEPH: În procesul de scădere a memoriei cache pe disc, a avut loc o înregistrare incorectă a blocului de date. Acest lucru a condus la deconectarea proceselor CEPH-OSD ale tuturor discurilor în care au fost păstrate replicile unității neprevăzute. Sistemul a fost imediat lipsit de trei discuri, ceea ce înseamnă toate fișierele plasate pe ele. Procesul de dezechilibru a început, dar nu a putut fi completat până la sfârșit - la urma urmei, toate cele trei copii ale cel puțin unui bloc de date (și fișierul corespunzător) au fost dispărute din sistem (și fișierul corespunzător) din care a început problema. Coerența instalației de depozitare a fost amenințată. Am eliminat manual blocurile eronate, am reluat procesele CEPH-OSD, dar a ajutat o vreme. Recordul eronat a fost repetat, echilibrarea a început din nou, iar depozitarea se prăbușește. ...
O căutare tensionată pe Internet a dat rezultatul - un bug închis în ultima în acel moment eliberarea ciocanului Ceph. Depozitul nostru este lansat versiunea anterioara - Licurici.
Avertizați clienții despre indisponibilitatea serverelor și au început să modernizeze. Comutat la un alt depozit, care a umplut bug-urile fixe, a efectuat actualizarea YUM, a reluat procesele CEPH - nu a ajutat. Eroarea este repetată. Localizarea sursei problemei - o intrare din memoria cache la depozitul principal - și a oprit complet cache-ul. Serverele clienților au câștigat, dar fiecare overlance sa întors în iad. Discurile nu au făcut față întreținerii echilibrării sistemului și a citirii clientului.
Rezolvăm problema drastic - cache SSD abandonată
* Pentru munca completă a clusterului CEPH, aveți nevoie de configurație AllFlash.
puneți unitățile SSD ca principal. A ajutat nodurile cu un număr mare de coșuri de disc, cumpărate prudent pentru clusterul de depozitare. Înlocuit treptat: Mai întâi au adăugat patru SSD-uri la coșurile goale rămase pe fiecare server, iar după echilibrarea datelor, acesta a început să înlocuiască HDD-urile vechi pe SSD unul câte unul. Au făcut după diagramă: Ștergeți discul, instalarea discului, echilibrarea datelor, îndepărtarea, instalarea, echilibrarea și așa mai departe într-un cerc, până când SSD a rămas în noduri. Înlocuit cu ...
Folosit industrial samsung Drives. 810 de dimensiune de 1 tb. Nu a folosit dimensiunea SSD mai mare, astfel încât să nu provoace situația "gâtului îngustă" atunci când o mulțime de date se află pe o medie fizică și, prin urmare, există un număr mare de apeluri.
Astfel, am înlocuit treptat toate unitățile pe SSD. Și a venit fericirea
Concluziile mele (care nu pot coincide cu concluziile autorilor postului original): CEPH în producție - experiență pentru persoanele cu ouă de fier. Surori plătește. Și bine, dacă doar de două ori. Și cu atât mai bine, dacă numai bani. Uitați de vacanțe cu familia și deconectați pe telefonul de noapte. Nu este pentru tine acum.
Celular - ceea ce este pe iPad și care este diferența
Du-te la televiziunea digitală: Ce să faci și cum să te pregătești?
Sondajele sociale lucrează pe Internet
Trimiterea de e-mail este blocată, cum să deblocați?
Savin a înregistrat un mesaj video către taiaturi
Meniu de tabele sovietice Care a fost numele joiului în cantinele sovietice
Cum se face în lista "Word" alfabetic: Sfaturi utile