Odnoklassniki er den største bruger af Apache Cassandra på RuNet og en af de største i verden. Vi begyndte at bruge Cassandra i 2010 til at gemme fotovurderinger, og nu administrerer Cassandra petabytes af data på tusindvis af noder, faktisk udviklede vi endda vores egen .
Den 12. september i vores St. Petersborg kontor holder vi . Hovedtaleren for begivenheden vil være chefingeniøren for Odnoklassniki Oleg Anastasyev. Oleg er ekspert inden for distribuerede og fejltolerante systemer; han har arbejdet med Cassandra i mere end 10 år og gentagne gange .
På tærsklen til mødet talte vi med Oleg om fejltolerancen af distribuerede systemer med Cassandra, spurgte, hvad han ville tale om ved mødet, og hvorfor det var værd at deltage i denne begivenhed.
Oleg begyndte sin programmeringskarriere tilbage i 1995. Han udviklede software inden for bank, telekommunikation og transport. Han har arbejdet som en førende udvikler hos Odnoklassniki siden 2007 på platformsteamet. Hans ansvar omfatter udvikling af arkitekturer og løsninger til højbelastningssystemer, store datavarehuse og løsning af problemer med portalens ydeevne og pålidelighed. Han uddanner også udviklere i virksomheden.
- Oleg, hej! I maj fandt sted , dedikeret til Apache Cassandra, siger deltagerne, at diskussionerne fortsatte til sent på aftenen. Fortæl mig venligst, hvad er dit indtryk af det første møde?
Udviklere med forskellig baggrund fra forskellige virksomheder kom med deres egen smerte, uventede løsninger på problemer og fantastiske historier. Vi formåede at gennemføre det meste af mødet i et diskussionsformat, men der var så mange diskussioner, at vi kun var i stand til at berøre en tredjedel af de planlagte emner. Vi var meget opmærksomme på, hvordan og hvad vi overvåger ved at bruge eksemplet med vores rigtige produktionstjenester.
Jeg var interesseret og kunne virkelig godt lide det.
- At dømme efter meddelelsen, vil udelukkende være afsat til fejltolerance, hvorfor valgte du dette emne?
Cassandra er et typisk travlt distribueret system med en enorm mængde funktionalitet ud over direkte at betjene brugeranmodninger: sladder, fejlregistrering, udbredelse af skemaændringer, klyngeudvidelse/-krympning, anti-entropi, sikkerhedskopiering og gendannelse osv. Som i ethvert distribueret system, når mængden af hardware stiger, øges sandsynligheden for fejl, så driften af Cassandra produktionsklynger kræver en dyb forståelse af dets struktur for at forudsige adfærd i tilfælde af fejl og operatørhandlinger. Efter at have brugt Cassandra i mange år, har vi , som vi er klar til at dele, og vi vil også gerne diskutere, hvordan kollegaer i butikken løser typiske problemer.
— Når det kommer til Cassandra, hvad mener du så med fejltolerance?
Først og fremmest, selvfølgelig, systemets evne til at overleve typiske hardwarefejl: tab af maskiner, diske eller netværksforbindelse med noder/datacentre. Men selve emnet er meget bredere og omfatter især genopretning fra fejl, herunder fejl, som folk sjældent er forberedt på, for eksempel operatørfejl.
— Kan du give et eksempel på den mest belastede og største dataklynge?
En af vores største klynger er gaveklyngen: mere end 200 noder og hundredvis af TB data. Men den er ikke den mest indlæste, da den er dækket af en distribueret cache. Vores travleste klynger håndterer titusindvis af RPS til skrivning og tusindvis af RPS til læsning.
- Wow! Hvor ofte går noget i stykker?
! I alt har vi mere end 6 tusinde servere, og hver uge udskiftes et par servere og flere dusin diske (uden at tage højde for de parallelle processer med opgradering og udvidelse af maskinflåden). For hver type fejl er der klare instruktioner om, hvad der skal gøres og i hvilken rækkefølge, alt er automatiseret når det er muligt, så fejl er rutine og i 99% af tilfældene opstår ubemærket af brugerne.
— Hvordan håndterer du sådanne afslag?
Helt fra begyndelsen af driften af Cassandra og de første hændelser arbejdede vi på mekanismerne til sikkerhedskopiering og gendannelse fra dem, byggede implementeringsprocedurer, der tager højde for Cassandra-klyngernes tilstand og for eksempel ikke tillader genstart af noder hvis datatab er muligt. Vi planlægger at tale om alt dette på mødet.
— Som du sagde, er der ingen absolut pålidelige systemer. Hvilke typer fiaskoer forbereder du dig på og er i stand til at overleve?
Hvis vi taler om vores installationer af Cassandra-klynger, vil brugerne ikke bemærke noget, hvis vi mister flere maskiner i en DC eller en hel DC (dette er sket). Med stigningen i antallet af DC'er tænker vi på at begynde at sikre operabilitet i tilfælde af fejl på to DC'er.
— Hvad tror du, Cassandra mangler i forhold til fejltolerance?
Cassandra kræver, ligesom mange andre tidlige NoSQL-butikker, en dyb forståelse af dens interne struktur og de dynamiske processer, der forekommer. Jeg vil sige, at det mangler enkelhed, forudsigelighed og observerbarhed. Men det bliver interessant at høre andre mødedeltageres meninger!
Oleg, mange tak fordi du tog dig tid til at besvare spørgsmålene!
Vi venter på alle, der ønsker at kommunikere med eksperter inden for drift af Apache Cassandra ved mødet den 12. september på vores kontor i St. Petersborg.
Kom, det bliver interessant!
Kilde: www.habr.com