Odnoklassniki er den største brukeren av Apache Cassandra på RuNet og en av de største i verden. Vi begynte å bruke Cassandra i 2010 for å lagre bildevurderinger, og nå administrerer Cassandra petabyte med data på tusenvis av noder, faktisk utviklet vi til og med våre egne .
Den 12. september på vårt St. Petersburg-kontor holder vi . Hovedtaleren for arrangementet vil være sjefsingeniøren til Odnoklassniki Oleg Anastasyev. Oleg er en ekspert innen distribuerte og feiltolerante systemer; han har jobbet med Cassandra i mer enn 10 år og gjentatte ganger .
På tampen av treffet snakket vi med Oleg om feiltoleransen til distribuerte systemer med Cassandra, spurte hva han ville snakke om på treffet og hvorfor det var verdt å delta på dette arrangementet.
Oleg begynte sin programmeringskarriere tilbake i 1995. Han utviklet programvare innen bank, telekom og transport. Han har jobbet som en ledende utvikler hos Odnoklassniki siden 2007 på plattformteamet. Hans ansvar inkluderer å utvikle arkitekturer og løsninger for høybelastningssystemer, store datavarehus og løse problemer med portalytelse og pålitelighet. Han utdanner også utviklere i selskapet.
- Oleg, hei! I mai fant sted , dedikert til Apache Cassandra, sier deltakerne at diskusjonene pågikk til sent på kvelden, vennligst fortell meg, hva er ditt inntrykk av det første møtet?
Utviklere med ulik bakgrunn fra ulike selskaper kom med sin egen smerte, uventede løsninger på problemer og fantastiske historier. Vi klarte å gjennomføre mesteparten av møtet i et diskusjonsformat, men det var så mange diskusjoner at vi bare klarte å berøre en tredjedel av de planlagte temaene. Vi la mye oppmerksomhet på hvordan og hva vi overvåker ved å bruke eksemplet med våre ekte produksjonstjenester.
Jeg var interessert og likte det veldig godt.
- Etter kunngjøringen å dømme, vil være helt viet til feiltoleranse, hvorfor valgte du dette emnet?
Cassandra er et typisk travelt distribuert system med en enorm mengde funksjonalitet utover å betjene brukerforespørsler direkte: sladder, feildeteksjon, forplantning av skjemaendringer, klyngeutvidelse/reduksjon, antientropi, sikkerhetskopiering og gjenoppretting, etc. Som i ethvert distribuert system, ettersom mengden maskinvare øker, øker sannsynligheten for feil, så driften av Cassandra-produksjonsklynger krever en dyp forståelse av strukturen for å forutsi atferd i tilfelle feil og operatørhandlinger. Etter å ha brukt Cassandra i mange år, har vi , som vi er klare til å dele, og vi ønsker også å diskutere hvordan kollegaer i butikken løser typiske problemer.
— Når det gjelder Cassandra, hva mener du med feiltoleranse?
Først av alt, selvfølgelig, systemets evne til å overleve typiske maskinvarefeil: tap av maskiner, disker eller nettverkstilkobling med noder/datasentre. Men selve emnet er mye bredere og inkluderer spesielt gjenoppretting fra feil, inkludert feil som folk sjelden er forberedt på, for eksempel operatørfeil.
— Kan du gi et eksempel på den mest belastede og største dataklyngen?
En av våre største klynger er gaveklyngen: mer enn 200 noder og hundrevis av TB med data. Men den er ikke den mest lastede, siden den er dekket av en distribuert cache. Våre travleste klynger håndterer titusenvis av RPS for skriving og tusenvis av RPS for lesing.
- Wow! Hvor ofte går noe i stykker?
! Totalt har vi mer enn 6 tusen servere, og hver uke erstattes et par servere og flere dusin disker (uten å ta hensyn til de parallelle prosessene med oppgradering og utvidelse av maskinparken). For hver type feil er det klare instruksjoner om hva som skal gjøres og i hvilken rekkefølge, alt er automatisert når det er mulig, så feil er rutine og i 99 % av tilfellene oppstår ubemerket av brukerne.
— Hvordan takler du slike avslag?
Helt fra begynnelsen av driften av Cassandra og de første hendelsene, jobbet vi med mekanismene for sikkerhetskopiering og gjenoppretting fra dem, bygde distribusjonsprosedyrer som tar hensyn til tilstanden til Cassandra-klynger og for eksempel ikke tillater at noder startes på nytt hvis datatap er mulig. Vi planlegger å snakke om alt dette på treffet.
— Som du sa, det finnes ingen absolutt pålitelige systemer. Hvilke typer feil forbereder du deg på og klarer å overleve?
Hvis vi snakker om installasjonene våre av Cassandra-klynger, vil brukerne ikke merke noe hvis vi mister flere maskiner i en DC eller en hel DC (dette har skjedd). Med økningen i antall DC-er, tenker vi på å begynne å sikre operabilitet ved feil på to DC-er.
— Hva mener du Cassandra mangler av feiltoleranse?
Cassandra, som mange andre tidlige NoSQL-butikker, krever en dyp forståelse av dens interne struktur og de dynamiske prosessene som skjer. Jeg vil si at det mangler enkelhet, forutsigbarhet og observerbarhet. Men det skal bli interessant å høre meningene til andre møtedeltakere!
Oleg, tusen takk for at du tok deg tid til å svare på spørsmålene!
Vi venter på alle som ønsker å kommunisere med eksperter innen drift av Apache Cassandra på møtet 12. september på vårt St. Petersburg-kontor.
Kom, det blir interessant!
Kilde: www.habr.com