Odnoklassniki este cel mai mare utilizator al Apache Cassandra de pe RuNet și unul dintre cei mai mari din lume. Am început să folosim Cassandra în 2010 pentru a stoca evaluări ale fotografiilor, iar acum Cassandra gestionează petaocteți de date pe mii de noduri, de fapt, am dezvoltat chiar și propriile noastre evaluări. .
Pe 12 septembrie, în biroul nostru din Sankt Petersburg vom ține . Vorbitorul principal al evenimentului va fi inginerul șef al lui Odnoklassniki Oleg Anastasyev. Oleg este expert în domeniul sistemelor distribuite și tolerante la erori, lucrează cu Cassandra de mai bine de 10 ani și în mod repetat. .
În ajunul întâlnirii, am discutat cu Oleg despre toleranța la erori a sistemelor distribuite cu Cassandra, am întrebat despre ce va vorbi la întâlnire și de ce merită să participi la acest eveniment.
Oleg și-a început cariera de programator în 1995. Dezvoltarea de software în domeniul bancar, telecomunicații și transport. Lucrează ca dezvoltator principal la Odnoklassniki din 2007 în echipa platformei. Responsabilitățile sale includ dezvoltarea de arhitecturi și soluții pentru sisteme cu încărcare mare, depozite mari de date și rezolvarea problemelor de performanță și fiabilitate a portalului. De asemenea, antrenează dezvoltatori în cadrul companiei.
- Oleg, salut! În luna mai a avut loc , dedicat lui Apache Cassandra, participanții spun că discuțiile au durat până noaptea târziu, vă rog să-mi spuneți ce impresii aveți despre prima întâlnire?
Dezvoltatorii cu medii diferite din diferite companii au venit cu propria lor durere, soluții neașteptate la probleme și povești uimitoare. Am reușit să conducem cea mai mare parte a întâlnirii într-un format de discuție, dar au fost atât de multe discuții încât am putut atinge doar o treime din subiectele planificate. Am acordat foarte multă atenție modului și ce monitorizăm folosind exemplul serviciilor noastre reale de producție.
M-a interesat și mi-a plăcut foarte mult.
- Judecând după anunț, va fi dedicat în întregime toleranței la greșeli, de ce ați ales acest subiect?
Cassandra este un sistem distribuit tipic ocupat, cu o cantitate uriașă de funcționalități dincolo de deservirea directă a solicitărilor utilizatorilor: bârfă, detectarea defecțiunilor, propagarea modificărilor schemei, extinderea/reducerea clusterului, anti-entropie, backup și recuperare etc. Ca în orice sistem distribuit, pe măsură ce cantitatea de hardware crește, probabilitatea defecțiunilor crește, astfel încât funcționarea clusterelor de producție Cassandra necesită o înțelegere profundă a structurii sale pentru a prezice comportamentul în cazul defecțiunilor și acțiunilor operatorului. După ce am folosit Cassandra de mulți ani, noi , pe care suntem gata să-l împărtășim și vrem, de asemenea, să discutăm despre modul în care colegii din magazin rezolvă problemele tipice.
— Când vine vorba de Cassandra, ce înțelegi prin toleranță la greșeală?
În primul rând, desigur, capacitatea sistemului de a supraviețui defecțiunilor hardware tipice: pierderea mașinilor, a discurilor sau a conectivității la rețea cu noduri/centre de date. Dar subiectul în sine este mult mai larg și include în special recuperarea din defecțiuni, inclusiv defecțiuni pentru care oamenii sunt rar pregătiți, de exemplu, erori ale operatorului.
— Puteți da un exemplu de cel mai încărcat și mai mare cluster de date?
Unul dintre cele mai mari clustere ale noastre este clusterul cadou: peste 200 de noduri și sute de TB de date. Dar nu este cel mai încărcat, deoarece este acoperit de un cache distribuit. Cele mai aglomerate grupuri ale noastre gestionează zeci de mii de RPS pentru scriere și mii de RPS pentru citire.
- Wow! Cât de des se rupe ceva?
! În total, avem peste 6 mii de servere și în fiecare săptămână sunt înlocuite câteva servere și câteva zeci de discuri (fără a lua în considerare procesele paralele de actualizare și extindere a parcului de mașini). Pentru fiecare tip de defecțiune, există instrucțiuni clare cu privire la ce trebuie făcut și în ce ordine, totul este automatizat ori de câte ori este posibil, astfel că defecțiunile sunt de rutină și în 99% din cazuri apar neobservate de utilizatori.
— Cum te descurci cu astfel de refuzuri?
Încă de la începutul funcționării Cassandrei și de la primele incidente, am lucrat la mecanismele de backup și de recuperare din acestea, am construit proceduri de implementare care țin cont de starea clusterelor Cassandra și, de exemplu, nu permit repornirea nodurilor. dacă pierderea datelor este posibilă. Plănuim să vorbim despre toate acestea la întâlnire.
— După cum ați spus, nu există sisteme absolut fiabile. Pentru ce tipuri de eșecuri te pregătești și poți supraviețui?
Dacă vorbim despre instalațiile noastre de clustere Cassandra, utilizatorii nu vor observa nimic dacă pierdem mai multe mașini într-un singur DC sau un întreg DC (așa s-a întâmplat). Odată cu creșterea numărului de DC, ne gândim să începem să asigurăm operabilitatea în cazul unei defecțiuni a două DC.
— Ce crezi că îi lipsește Cassandrei în ceea ce privește toleranța la greșeală?
Cassandra, la fel ca multe alte magazine NoSQL timpurii, necesită o înțelegere profundă a structurii sale interne și a proceselor dinamice care au loc. Aș spune că îi lipsește simplitatea, predictibilitatea și observabilitatea. Dar va fi interesant să auzim părerile altor participanți la întâlnire!
Oleg, îți mulțumesc foarte mult pentru timpul acordat pentru a răspunde la întrebări!
Îi așteptăm pe toți cei care doresc să comunice cu experți în domeniul operațiunii Apache Cassandra la întâlnirea din 12 septembrie în biroul nostru din Sankt Petersburg.
Haide, va fi interesant!
Sursa: www.habr.com