Mini-ynterview mei Oleg Anastasyev: skuldtolerânsje yn Apache Cassandra

Mini-ynterview mei Oleg Anastasyev: skuldtolerânsje yn Apache Cassandra

Odnoklassniki is de grutste brûker fan Apache Cassandra op it RuNet en ien fan de grutste yn 'e wrâld. Wy begon Cassandra yn 2010 te brûken om fotowurdearrings op te slaan, en no beheart Cassandra petabytes oan gegevens op tûzenen knopen, yn feite hawwe wy sels ús eigen ûntwikkele NewSQL transaksje databank.
Op 12 septimber yn ús Sint-Petersburch-kantoar hâlde wy twadde gearkomste wijd oan Apache Cassandra. De haadsprekker fan it evenemint sil de haadyngenieur fan Odnoklassniki Oleg Anastasyev wêze. Oleg is in ekspert op it mêd fan ferdielde en fouttolerante systemen; hy hat mear dan 10 jier wurke mei Cassandra en ferskate kearen spruts oer de funksjes fan it brûken fan dit produkt op konferinsjes.

Oan 'e foarjûn fan' e gearkomste hawwe wy praat mei Oleg oer de fouttolerânsje fan ferdielde systemen mei Cassandra, fregen wêr't hy oer soe prate by de gearkomste en wêrom it wurdich wie om dit evenemint by te wenjen.

Oleg begûn syn programmearring karriêre werom yn 1995. Hy ûntwikkele software yn bankieren, telekom, en ferfier. Hy hat sûnt 2007 wurke as liedende ûntwikkelder by Odnoklassniki op it platfoarmteam. Syn ferantwurdlikheden omfetsje it ûntwikkeljen fan arsjitektuer en oplossingen foar systemen mei hege lading, grutte datapakhuzen, en it oplossen fan problemen fan portalprestaasjes en betrouberens. Hy traint ek ûntwikkelders binnen it bedriuw.

- Oleg, hallo! Yn maaie fûn plak earste gearkomste, wijd oan Apache Cassandra, de dielnimmers sizze dat diskusjes gie oant let nachts, fertel my asjebleaft, wat binne jo yndrukken fan 'e earste meetup?

Untwikkelders mei ferskate eftergrûnen fan ferskate bedriuwen kamen mei har eigen pine, ûnferwachte oplossingen foar problemen en geweldige ferhalen. It slagge ús om it grutste part fan 'e gearkomste yn in diskusjeformaat te fieren, mar d'r wiene safolle diskusjes dat wy mar in tredde fan 'e plande ûnderwerpen oanreitsje koenen. Wy hawwe in soad omtinken jûn oan hoe en wat wy kontrolearje mei it foarbyld fan ús echte produksjetsjinsten.

Ik wie ynteressearre en fûn it echt leuk.

- Te oardieljen nei de oankundiging, twadde gearkomste sil folslein wijd wêze oan skuldtolerânsje, wêrom hawwe jo dit ûnderwerp keazen?

Cassandra is in typysk drok ferspraat systeem mei in enoarme hoemannichte funksjonaliteit bûten it direkt tsjinjen fan brûkersoanfragen: roddel, deteksje fan mislearring, propagaasje fan skemawizigingen, klusterútwreiding / -reduksje, anty-entropy, backups en herstel, ensfh. Lykas yn elk ferspraat systeem, as it bedrach fan hardware tanimt, nimt de kâns op mislearrings ta, sadat de wurking fan Cassandra-produksjeklusters in djip begryp fan har struktuer fereasket om gedrach te foarsizzen yn gefal fan mislearrings en operatoraksjes. Nei it brûken fan Cassandra in protte jierren, wy hawwe wichtige ekspertize sammele, dy't wy ree binne om te dielen, en wy wolle ek beprate hoe't kollega's yn 'e winkel typyske problemen oplosse.

- As it giet om Cassandra, wat bedoele jo mei skuldtolerânsje?

Alderearst, fansels, it fermogen fan it systeem om typyske hardwarefouten te oerlibjen: ferlies fan masines, skiven of netwurkferbining mei knopen / datasintra. Mar it ûnderwerp sels is folle breder en yn it bysûnder omfettet herstel fan mislearrings, ynklusyf mislearrings dêr't minsken selden wurde taret, bygelyks, operator flaters.

- Kinne jo in foarbyld jaan fan it meast laden en grutste datakluster?

Ien fan ús grutste klusters is it kadokluster: mear dan 200 knopen en hûnderten TB oan gegevens. Mar it is net de meast laden, om't it wurdt dekt troch in ferspraat cache. Us drokste klusters behannelje tsientûzenen RPS foar skriuwen en tûzenen RPS foar lêzen.

- Wow! Hoe faak brekt wat?

Ja de hiele tiid! Yn totaal hawwe wy mear as 6 tûzen servers, en elke wike wurde in pear servers en ferskate tsientallen skiven ferfongen (sûnder rekken te hâlden mei de parallelle prosessen fan upgrade en útwreiding fan 'e masinefloat). Foar elk type mislearring binne d'r dúdlike ynstruksjes oer wat te dwaan en yn hokker folchoarder, alles wurdt automatisearre as it mooglik is, sadat mislearrings routine binne en yn 99% fan 'e gefallen foarkomme ûngemurken troch brûkers.

- Hoe geane jo om mei sokke wegeringen?

Fan it begjin fan 'e operaasje fan Cassandra en de earste ynsidinten hawwe wy wurke oan' e meganismen foar reservekopy en herstel fan har, boude ynsetprosedueres dy't rekken hâlde mei de steat fan Cassandra-klusters en, bygelyks, gjin knopen wurde opnij starte as gegevensferlies mooglik is. Wy binne fan plan om dit alles te praten op 'e gearkomste.

- Lykas jo sein hawwe, binne d'r gjin absolút betroubere systemen. Op hokker soarten mislearrings tariede jo jo op en kinne jo oerlibje?

As wy prate oer ús ynstallaasjes fan Cassandra klusters, brûkers sille net merken neat as wy ferlieze ferskate masines yn ien DC of ien hiele DC (dit is bard). Mei it tanimmen fan it oantal DC's tinke wy deroer om te begjinnen mei it garandearjen fan operabiliteit yn gefal fan in mislearring fan twa DC's.

- Wat fynst Cassandra mist yn termen fan skuld tolerânsje?

Cassandra, lykas in protte oare iere NoSQL-winkels, fereasket in djip begryp fan har ynterne struktuer en de dynamyske prosessen dy't foarkomme. Ik soe sizze dat it ûntbrekt oan ienfâld, foarsisberens en waarnimmberens. Mar it sil nijsgjirrich wêze om de mieningen fan oare dielnimmers oan 'e gearkomste te hearren!

Oleg, tige tank foar it nimmen fan de tiid om de fragen te beantwurdzjen!

Wy wachtsje op elkenien dy't wolle kommunisearje mei saakkundigen op it mêd fan it operearjen fan Apache Cassandra by de meetup op septimber 12 yn ús Sint-Petersburch-kantoar.

Kom, it sil ynteressant wêze!

Registrearje foar it evenemint.

Boarne: www.habr.com

Add a comment