Odnoklassniki je največji uporabnik Apache Cassandra v RuNetu in eden največjih na svetu. Cassandro smo začeli uporabljati leta 2010 za shranjevanje ocen fotografij, zdaj pa Cassandra upravlja s petabajti podatkov na tisočih vozliščih, pravzaprav smo celo razvili lastno .
12. septembra v naši pisarni v Sankt Peterburgu bomo imeli . Glavni govornik dogodka bo glavni inženir Odnoklassnikov Oleg Anastasyev. Oleg je strokovnjak na področju porazdeljenih sistemov in sistemov, odpornih na napake, s Cassandro sodeluje že več kot 10 let in večkrat .
Na predvečer srečanja smo se z Olegom pogovarjali o toleranci napak porazdeljenih sistemov s Cassandro, vprašali, o čem bo govoril na srečanju in zakaj se je vredno udeležiti tega dogodka.
Oleg je svojo programsko kariero začel leta 1995. Razvijal je programsko opremo v bančništvu, telekomunikacijah in transportu. Od leta 2007 dela kot vodilni razvijalec pri Odnoklassniki v ekipi platforme. Njegove odgovornosti vključujejo razvoj arhitektur in rešitev za visoko obremenjene sisteme, velika podatkovna skladišča ter reševanje problemov zmogljivosti in zanesljivosti portala. V podjetju tudi izobražuje razvijalce.
- Oleg, zdravo! V maju potekala , posvečeno Apache Cassandri, udeleženci pravijo, da so se razprave odvijale do pozne noči, prosim povejte mi, kakšni so vaši vtisi o prvem srečanju?
Razvijalci z različnimi ozadji iz različnih podjetij so prišli s svojo bolečino, nepričakovanimi rešitvami težav in neverjetnimi zgodbami. Večino srečanja nam je uspelo izpeljati v diskusijski obliki, vendar je bilo razprav toliko, da smo se lahko dotaknili le tretjine načrtovanih tem. Veliko pozornost smo namenili temu, kako in kaj spremljamo na primeru naših realnih proizvodnih storitev.
Zanimalo me je in zelo mi je bilo všeč.
- Sodeč po napovedi, bo v celoti posvečen toleranci napak, zakaj ste izbrali to temo?
Cassandra je tipičen zaseden porazdeljen sistem z ogromno funkcionalnosti, ki presega neposredno servisiranje uporabniških zahtev: ogovarjanje, zaznavanje napak, širjenje sprememb sheme, razširitev/zmanjšanje gruče, antientropija, varnostno kopiranje in obnovitev itd. Kot v vsakem porazdeljenem sistemu se z večanjem količine strojne opreme povečuje verjetnost okvar, zato delovanje proizvodnih grozdov Cassandra zahteva globoko razumevanje njihove strukture za predvidevanje obnašanja v primeru okvar in dejanj operaterja. Po večletni uporabi Cassandre smo , ki smo jih pripravljeni deliti, želimo pa se pogovoriti tudi o tem, kako sodelavci v trgovini rešujejo tipične težave.
— Ko gre za Cassandro, kaj mislite s toleranco napak?
Najprej seveda sposobnost sistema, da preživi tipične okvare strojne opreme: izgubo strojev, diskov ali omrežne povezave z vozlišči/podatkovnimi centri. Toda sama tema je veliko širša in vključuje zlasti okrevanje po okvarah, vključno z okvarami, na katere so ljudje redko pripravljeni, na primer napake operaterja.
— Ali lahko navedete primer najbolj obremenjene in največje podatkovne gruče?
Eden naših največjih grozdov je darilni grozd: več kot 200 vozlišč in na stotine TB podatkov. Ni pa najbolj obremenjen, saj ga pokriva porazdeljeni predpomnilnik. Naši najbolj obremenjeni grozdi upravljajo na desettisoče RPS za pisanje in na tisoče RPS za branje.
- Vau! Kako pogosto se kaj pokvari?
! Skupno imamo več kot 6 tisoč strežnikov, vsak teden pa zamenjamo nekaj strežnikov in nekaj deset diskov (brez upoštevanja vzporednih procesov nadgradnje in širitve strojnega parka). Za vsako vrsto okvare obstajajo jasna navodila, kaj narediti in v kakšnem vrstnem redu, vse je avtomatizirano, kadar je le mogoče, zato so okvare rutinske in se v 99% primerov zgodijo neopažene za uporabnike.
— Kako se soočate s takimi zavrnitvami?
Od samega začetka delovanja Cassandre in prvih incidentov smo delali na mehanizmih za varnostne kopije in obnovitev iz njih, zgradili postopke uvajanja, ki upoštevajo stanje grozdov Cassandra in na primer ne dovoljujejo ponovnega zagona vozlišč. če je možna izguba podatkov. O vsem tem nameravamo govoriti na srečanju.
— Kot ste rekli, absolutno zanesljivih sistemov ni. Na kakšne vrste neuspehov ste pripravljeni in jih lahko preživite?
Če govorimo o naših namestitvah gruč Cassandra, uporabniki ne bodo opazili ničesar, če izgubimo več strojev v enem DC ali enem celotnem DC (to se je zgodilo). Ob povečanju števila DC razmišljamo o tem, da bi začeli zagotavljati operativnost v primeru izpada dveh DC.
— Kaj mislite, kaj manjka Cassandri v smislu tolerance napak?
Cassandra, tako kot mnoge druge zgodnje trgovine NoSQL, zahteva globoko razumevanje svoje notranje strukture in dinamičnih procesov, ki se pojavljajo. Rekel bi, da ji manjka preprostosti, predvidljivosti in opazljivosti. Bo pa zanimivo slišati mnenja drugih udeležencev srečanja!
Oleg, najlepša hvala, ker ste si vzeli čas za odgovore na vprašanja!
Čakamo vse, ki želite komunicirati s strokovnjaki na področju delovanja Apache Cassandra na srečanju 12. septembra v naši pisarni v Sankt Peterburgu.
Pridite, zanimivo bo!
Vir: www.habr.com