Odnoklassniki estas la plej granda uzanto de Apache Cassandra sur la RuNet kaj unu el la plej grandaj en la mondo. Ni komencis uzi Cassandra en 2010 por stoki fotorangigojn, kaj nun Cassandra administras petabajtojn da datumoj sur miloj da nodoj, fakte ni eĉ evoluigis nian propran .
La 12-an de septembro en nia peterburga oficejo ni okazigos . La ĉefa preleganto de la evento estos la ĉefinĝeniero de Odnoklassniki Oleg Anastasyev. Oleg estas fakulo pri la kampo de distribuitaj kaj mistoleremaj sistemoj; li laboras kun Cassandra dum pli ol 10 jaroj kaj plurfoje. .
Antaŭ la renkontiĝo, ni parolis kun Oleg pri la misfunkciado de distribuitaj sistemoj kun Cassandra, demandis pri kio li parolos ĉe la renkontiĝo kaj kial indas ĉeesti ĉi tiun eventon.
Oleg komencis sian programadan karieron reen en 1995. Li evoluigis softvaron en bankado, teleentrepreno, kaj transporto. Li laboras kiel ĉefa programisto ĉe Odnoklassniki ekde 2007 en la platforma teamo. Liaj respondecoj inkluzivas evoluigi arkitekturojn kaj solvojn por altŝarĝaj sistemoj, grandaj datumstokejoj, kaj solvanta problemojn de portala efikeco kaj fidindeco. Li ankaŭ trejnas programistojn ene de la firmao.
- Oleg, saluton! En majo okazis , dediĉita al Apache Cassandra, la partoprenantoj diras, ke diskutoj daŭris ĝis malfrua nokto, bonvolu diri al mi, kiaj estas viaj impresoj pri la unua renkontiĝo?
Programistoj kun malsamaj fonoj de malsamaj kompanioj venis kun sia propra doloro, neatenditaj solvoj al problemoj kaj mirindaj rakontoj. Ni sukcesis fari la plej grandan parton de la renkontiĝo en diskutformato, sed estis tiom da diskutoj ke ni povis tuŝi nur trionon de la planitaj temoj. Ni multe atentis kiel kaj kion ni kontrolas uzante la ekzemplon de niaj realaj produktadservoj.
Mi interesiĝis kaj tre ŝatis ĝin.
- Juĝante laŭ la anonco, estos tute dediĉita al kulpotoleremo, kial vi elektis ĉi tiun temon?
Cassandra estas tipa okupata distribuita sistemo kun grandega kvanto de funkcieco preter rekte servado de uzantpetoj: klaĉo, malsukcesa detekto, disvastigo de skemaj ŝanĝoj, areto-vastiĝo/malgrandiĝo, kontraŭ-entropio, sekurkopioj kaj reakiro, ktp. Kiel en iu ajn distribuita sistemo, kiam la kvanto de aparataro pliiĝas, la verŝajneco de misfunkciadoj pliiĝas, do la funkciado de Cassandra produktadgrupoj postulas profundan komprenon de ĝia strukturo por antaŭdiri konduton en kazo de fiaskoj kaj operaciantaj agoj. Post uzi Cassandra dum multaj jaroj, ni , kiun ni pretas dividi, kaj ni ankaŭ volas diskuti kiel kolegoj en la butiko solvas tipajn problemojn.
— Kiam temas pri Kasandra, kion vi volas diri per kulpotoleremo?
Antaŭ ĉio, kompreneble, la kapablo de la sistemo postvivi tipajn aparatajn misfunkciadojn: perdo de maŝinoj, diskoj aŭ reto-konekteco kun nodoj/datumcentroj. Sed la temo mem estas multe pli larĝa kaj precipe inkluzivas reakiron de misfunkciadoj, inkluzive de misfunkciadoj, por kiuj homoj malofte estas pretaj, ekzemple operaciaj eraroj.
— Ĉu vi povas doni ekzemplon de la plej ŝarĝita kaj plej granda datumgrupo?
Unu el niaj plej grandaj aretoj estas la donacgrupo: pli ol 200 nodoj kaj centoj da TB da datumoj. Sed ĝi ne estas la plej ŝarĝita, ĉar ĝi estas kovrita de distribuita kaŝmemoro. Niaj plej okupataj aretoj manipulas dekojn da miloj da RPS por skribi kaj milojn da RPS por legado.
- Ŭaŭ! Kiom ofte io rompiĝas?
! Entute, ni havas pli ol 6 mil servilojn, kaj ĉiusemajne kelkaj serviloj kaj kelkaj dekoj da diskoj estas anstataŭigitaj (sen konsideri la paralelajn procezojn de ĝisdatigo kaj ekspansio de la maŝina floto). Por ĉiu tipo de misfunkciado, estas klaraj instrukcioj pri kio fari kaj en kiu ordo, ĉio estas aŭtomatigita kiam ajn eblas, do misfunkciadoj estas rutinaj kaj en 99% de kazoj okazas nerimarkite de uzantoj.
— Kiel vi traktas tiajn rifuzojn?
Ekde la komenco de la funkciado de Cassandra kaj la unuaj incidentoj, ni laboris pri la mekanismoj por sekurkopioj kaj reakiro de ili, konstruis disfaldigajn procedurojn, kiuj konsideras la staton de Cassandra-grupoj kaj, ekzemple, ne ebligas rekomenci nodojn. se perdo de datumoj eblas. Ni planas paroli pri ĉio ĉi ĉe la renkontiĝo.
— Kiel vi diris, ne ekzistas absolute fidindaj sistemoj. Por kiaj malsukcesoj vi prepariĝas kaj kapablas travivi?
Se ni parolas pri niaj instalaĵoj de Cassandra clusters, uzantoj nenion rimarkos se ni perdos plurajn maŝinojn en unu PK aŭ unu tuta PK (ĉi tio okazis). Kun la pliiĝo de la nombro da DC-oj, ni pensas pri komenci certigi funkciadon en la okazo de malsukceso de du DC-oj.
— Kion, laŭ vi, mankas al Kasandra rilate al kulpotoleremo?
Cassandra, kiel multaj aliaj fruaj NoSQL-butikoj, postulas profundan komprenon de ĝia interna strukturo kaj la dinamikaj procezoj okazantaj. Mi dirus, ke mankas al ĝi simpleco, antaŭvidebleco kaj observeblo. Sed estos interese aŭdi la opiniojn de aliaj kunvenaj partoprenantoj!
Oleg, koran dankon pro la tempo por respondi la demandojn!
Ni atendas ĉiujn, kiuj volas komuniki kun spertuloj en la fako de funkciigado de Apache Cassandra ĉe la renkontiĝo la 12-an de septembro en nia Sankt-Peterburga oficejo.
Venu, estos interese!
fonto: www.habr.com