Odnoklassniki është përdoruesi më i madh i Apache Cassandra në RuNet dhe një nga më të mëdhenjtë në botë. Ne filluam të përdorim Cassandra në 2010 për të ruajtur vlerësimet e fotografive, dhe tani Cassandra menaxhon petabytes të dhënash në mijëra nyje, në fakt, ne kemi zhvilluar edhe tonat .
Më 12 shtator në zyrën tonë në Shën Petersburg do të mbajmë . Folësi kryesor i ngjarjes do të jetë inxhinieri kryesor i Odnoklassniki Oleg Anastasyev. Oleg është një ekspert në fushën e sistemeve të shpërndara dhe tolerante ndaj gabimeve; ai ka punuar me Cassandra për më shumë se 10 vjet dhe në mënyrë të përsëritur .
Në prag të takimit, ne biseduam me Oleg për tolerancën e gabimeve të sistemeve të shpërndara me Cassandra, e pyetëm se për çfarë do të fliste në takim dhe pse ia vlente të merrte pjesë në këtë ngjarje.
Oleg filloi karrierën e tij të programimit në 1995. Ai zhvilloi softuer në banka, telekom dhe transport. Ai ka punuar si zhvillues kryesor në Odnoklassniki që nga viti 2007 në ekipin e platformës. Përgjegjësitë e tij përfshijnë zhvillimin e arkitekturave dhe zgjidhjeve për sisteme me ngarkesë të lartë, magazina të mëdha të të dhënave dhe zgjidhjen e problemeve të performancës dhe besueshmërisë së portalit. Ai gjithashtu trajnon zhvillues brenda kompanisë.
- Oleg, përshëndetje! Në maj u zhvillua , kushtuar Apache Cassandra, pjesëmarrësit thonë se diskutimet vazhduan deri në orët e vona të natës, ju lutem më tregoni, cilat janë përshtypjet tuaja nga takimi i parë?
Zhvilluesit me prejardhje të ndryshme nga kompani të ndryshme erdhën me dhimbjen e tyre, zgjidhje të papritura për problemet dhe histori të mahnitshme. Ne arritëm ta zhvillonim pjesën më të madhe të takimit në një format diskutimi, por pati aq shumë diskutime sa arritëm të preknim vetëm një të tretën e temave të planifikuara. Ne i kushtuam shumë vëmendje mënyrës dhe asaj që monitorojmë duke përdorur shembullin e shërbimeve tona reale të prodhimit.
Isha i interesuar dhe më pëlqeu shumë.
-Duke gjykuar nga njoftimi, do t'i kushtohet tërësisht tolerancës së gabimeve, pse zgjodhët këtë temë?
Cassandra është një sistem tipik i ngarkuar i shpërndarë me një sasi të madhe funksionaliteti përtej shërbimit të drejtpërdrejtë të kërkesave të përdoruesve: thashethemet, zbulimi i dështimeve, përhapja e ndryshimeve të skemës, zgjerimi/reduktimi i grupimeve, anti-entropia, rezervat dhe rikuperimi, etj. Si në çdo sistem të shpërndarë, me rritjen e sasisë së harduerit, gjasat për dështime rriten, kështu që funksionimi i grupeve të prodhimit Cassandra kërkon një kuptim të thellë të strukturës së tij për të parashikuar sjelljen në rast dështimesh dhe veprimet e operatorit. Pas përdorimit të Cassandra për shumë vite, ne , të cilin ne jemi gati ta ndajmë, dhe gjithashtu duam të diskutojmë se si kolegët në dyqan zgjidhin problemet tipike.
— Kur bëhet fjalë për Kasandrën, çfarë kuptoni me tolerancë ndaj gabimeve?
Para së gjithash, natyrisht, aftësia e sistemit për t'i mbijetuar dështimeve tipike të harduerit: humbja e makinave, disqeve ose lidhjes së rrjetit me nyjet/qendrat e të dhënave. Por vetë tema është shumë më e gjerë dhe në veçanti përfshin rikuperimin nga dështimet, duke përfshirë dështimet për të cilat njerëzit rrallë përgatiten, për shembull, gabimet e operatorit.
— A mund të jepni një shembull të grupit të të dhënave më të ngarkuar dhe më të madh?
Një nga grupimet tona më të mëdha është grupi i dhuratave: më shumë se 200 nyje dhe qindra TB të dhëna. Por nuk është më i ngarkuari, pasi mbulohet nga një cache e shpërndarë. Grupet tona më të ngarkuara trajtojnë dhjetëra mijëra RPS për shkrim dhe mijëra RPS për lexim.
- Uau! Sa shpesh prishet diçka?
! Në total, ne kemi më shumë se 6 mijë serverë, dhe çdo javë zëvendësohen disa serverë dhe disa dhjetëra disqe (pa marrë parasysh proceset paralele të azhurnimit dhe zgjerimit të flotës së makinës). Për çdo lloj dështimi, ka udhëzime të qarta se çfarë duhet bërë dhe në çfarë rendi, gjithçka automatizohet sa herë që është e mundur, kështu që dështimet janë rutinë dhe në 99% të rasteve ndodhin pa u vënë re nga përdoruesit.
— Si i trajtoni këto refuzime?
Që nga fillimi i funksionimit të Cassandra dhe incidentet e para, ne kemi punuar në mekanizmat për kopje rezervë dhe rikuperim prej tyre, kemi ndërtuar procedura vendosjeje që marrin parasysh gjendjen e grupimeve të Cassandra dhe, për shembull, nuk lejojnë rifillimin e nyjeve. nëse humbja e të dhënave është e mundur. Ne planifikojmë të flasim për të gjitha këto në takim.
— Siç thatë, nuk ka sisteme absolutisht të besueshme. Për cilat lloje dështimesh përgatiteni dhe jeni në gjendje të përballoni?
Nëse flasim për instalimet tona të grupimeve Cassandra, përdoruesit nuk do të vërejnë asgjë nëse humbim disa makina në një DC ose një DC të tërë (kjo ka ndodhur). Me rritjen e numrit të DC-ve, ne po mendojmë të fillojmë të sigurojmë funksionueshmërinë në rast të dështimit të dy DC-ve.
— Çfarë mendoni se i mungon Kasandrës për sa i përket tolerancës ndaj gabimeve?
Cassandra, si shumë dyqane të tjera të hershme NoSQL, kërkon një kuptim të thellë të strukturës së saj të brendshme dhe proceseve dinamike që ndodhin. Do të thosha se i mungon thjeshtësia, parashikueshmëria dhe vëzhgueshmëria. Por do të jetë interesante të dëgjosh mendimet e pjesëmarrësve të tjerë të takimit!
Oleg, faleminderit shumë që gjetët kohën për t'iu përgjigjur pyetjeve!
Ne presim të gjithë ata që duan të komunikojnë me ekspertë në fushën e funksionimit të Apache Cassandra në takimin e 12 shtatorit në zyrën tonë në Shën Petersburg.
Ejani, do të jetë interesante!
Burimi: www.habr.com