Mini-intervju s Olegom Anastasyevom: tolerancija grešaka u Apache Cassandri

Mini-intervju s Olegom Anastasyevom: tolerancija grešaka u Apache Cassandri

Odnoklassniki je najveći korisnik Apache Cassandra na RuNetu i jedan od najvećih na svijetu. Počeli smo koristiti Cassandru 2010. za pohranjivanje ocjena fotografija, a sada Cassandra upravlja petabajtima podataka na tisućama čvorova, čak smo razvili i vlastite NewSQL transakcijska baza podataka.
12. rujna u našem uredu u Sankt Peterburgu održat ćemo drugi susret posvećen Apaču Kasandri. Glavni govornik događaja bit će glavni inženjer Odnoklassniki Oleg Anastasyev. Oleg je stručnjak u području distribuiranih sustava otpornih na pogreške; s Cassandrom radi više od 10 godina i više puta govorio o značajkama korištenja ovog proizvoda na konferencijama.

Uoči meetupa, razgovarali smo s Olegom o toleranciji grešaka distribuiranih sustava s Cassandrom, pitali o čemu će pričati na meetupu i zašto se isplati prisustvovati ovom događaju.

Oleg je svoju programersku karijeru započeo 1995. Razvijao je softver u bankarstvu, telekomu i transportu. Od 2007. radi kao vodeći programer u Odnoklassniki u timu platforme. Njegove odgovornosti uključuju razvoj arhitekture i rješenja za visokoopterećene sustave, velika skladišta podataka i rješavanje problema performansi i pouzdanosti portala. Također obučava programere unutar tvrtke.

- Oleg, zdravo! U svibnju održao prvi susret, posvećenog Apache Cassandri, sudionici kažu da su se diskusije vodile do kasno u noć, recite mi, molim vas, kakvi su vaši dojmovi prvog susreta?

Programeri s različitim iskustvom iz različitih tvrtki došli su sa svojom vlastitom boli, neočekivanim rješenjima problema i nevjerojatnim pričama. Uspjeli smo veći dio meetupa provesti u formatu rasprava, no rasprava je bilo toliko da smo se uspjeli dotaknuti tek trećine planiranih tema. Veliku pozornost posvetili smo tome kako i što pratimo na primjeru naših stvarnih proizvodnih usluga.

Zanimalo me i jako mi se svidjelo.

- Sudeći po najavi, drugi susret će u potpunosti biti posvećen toleranciji grešaka, zašto ste odabrali ovu temu?

Cassandra je tipičan distribuirani sustav s velikom količinom funkcionalnosti izvan izravnog servisiranja korisničkih zahtjeva: ogovaranje, otkrivanje kvarova, širenje promjena sheme, širenje/smanjenje klastera, anti-entropija, sigurnosne kopije i oporavak, itd. Kao u svakom distribuiranom sustavu, kako se povećava količina hardvera, povećava se i vjerojatnost kvarova, tako da rad proizvodnih klastera Cassandra zahtijeva duboko razumijevanje njegove strukture kako bi se predvidjelo ponašanje u slučaju kvarova i radnji operatera. Nakon dugogodišnjeg korištenja Cassandre, mi prikupili značajnu stručnost, koje smo spremni podijeliti, a također želimo razgovarati o tome kako kolege u trgovini rješavaju tipične probleme.

— Kad je Cassandra u pitanju, što podrazumijevate pod tolerancijom na greške?

Prije svega, naravno, sposobnost sustava da preživi tipične kvarove hardvera: gubitak strojeva, diskova ili mrežne povezanosti s čvorovima/podatkovnim centrima. Ali sama tema je mnogo šira i posebno uključuje oporavak od kvarova, uključujući kvarove na koje su ljudi rijetko spremni, na primjer, pogreške operatera.

— Možete li navesti primjer najopterećenijeg i najvećeg klastera podataka?

Jedan od naših najvećih klastera je poklon klaster: više od 200 čvorova i stotine TB podataka. Ali nije najopterećeniji, jer je pokriven distribuiranim cacheom. Naši najprometniji klasteri obrađuju desetke tisuća RPS-a za pisanje i tisuće RPS-a za čitanje.

- Vau! Koliko često se nešto pokvari?

Da cijelo vrijeme! Ukupno imamo više od 6 tisuća poslužitelja, a svaki tjedan se mijenja par servera i nekoliko desetaka diskova (ne uzimajući u obzir paralelne procese nadogradnje i proširenja strojnog parka). Za svaku vrstu kvara postoje jasne upute što učiniti i kojim redoslijedom, sve je automatizirano kad god je to moguće, pa su kvarovi rutinski iu 99% slučajeva događaju se neprimjetno od strane korisnika.

— Kako se nosite s takvim odbijanjima?

Od samog početka rada Cassandre i prvih incidenata, radili smo na mehanizmima za sigurnosne kopije i oporavak od njih, izgradili smo procedure implementacije koje uzimaju u obzir stanje klastera Cassandre i, na primjer, ne dopuštaju ponovno pokretanje čvorova ako je moguć gubitak podataka. O svemu tome planiramo razgovarati na susretu.

— Kao što ste rekli, nema apsolutno pouzdanih sustava. Na koje se vrste neuspjeha pripremate i koje ste sposobni preživjeti?

Ako govorimo o našim instalacijama Cassandra klastera, korisnici neće primijetiti ništa ako izgubimo nekoliko strojeva u jednom DC-u ili jedan cijeli DC (ovo se događalo). S povećanjem broja DC-a razmišljamo o tome da počnemo osiguravati operativnost u slučaju kvara dva DC-a.

— Što mislite da Cassandri nedostaje u pogledu tolerancije na pogreške?

Cassandra, kao i mnoge druge rane NoSQL trgovine, zahtijeva duboko razumijevanje svoje unutarnje strukture i dinamičkih procesa koji se odvijaju. Rekao bih da mu nedostaje jednostavnosti, predvidljivosti i uočljivosti. Ali bit će zanimljivo čuti mišljenja ostalih sudionika sastanka!

Oleg, hvala ti što si odvojio vrijeme da odgovoriš na pitanja!

Čekamo sve koji žele komunicirati sa stručnjacima na području upravljanja Apache Cassandrom na susretu 12. rujna u našem uredu u Sankt Peterburgu.

Dođite, bit će zanimljivo!

Prijavite se za događaj.

Izvor: www.habr.com

Dodajte komentar