Odnoklassniki är den största användaren av Apache Cassandra på RuNet och en av de största i världen. Vi började använda Cassandra 2010 för att lagra fotobetyg, och nu hanterar Cassandra petabyte med data på tusentals noder, faktiskt har vi till och med utvecklat våra egna .
Den 12 september på vårt kontor i St Petersburg håller vi . Huvudtalaren för evenemanget kommer att vara chefsingenjören för Odnoklassniki Oleg Anastasyev. Oleg är expert inom området distribuerade och feltoleranta system; han har arbetat med Cassandra i mer än 10 år och upprepade gånger .
På tröskeln till mötet pratade vi med Oleg om feltoleransen för distribuerade system med Cassandra, frågade vad han skulle prata om på mötet och varför det var värt att delta i detta evenemang.
Oleg började sin programmeringskarriär redan 1995. Han utvecklade mjukvara inom bank, telekom och transport. Han har arbetat som en ledande utvecklare på Odnoklassniki sedan 2007 i plattformsteamet. Hans ansvar inkluderar att utveckla arkitekturer och lösningar för högbelastningssystem, stora datalager och lösa problem med portalprestanda och tillförlitlighet. Han utbildar även utvecklare inom företaget.
- Oleg, hej! I maj ägde rum , tillägnad Apache Cassandra, säger deltagarna att diskussionerna pågick till sent på kvällen, snälla berätta för mig, vad är ditt intryck av den första träffen?
Utvecklare med olika bakgrund från olika företag kom med sin egen smärta, oväntade lösningar på problem och fantastiska historier. Vi lyckades genomföra det mesta av mötet i ett diskussionsformat, men det var så många diskussioner att vi bara kunde beröra en tredjedel av de planerade ämnena. Vi ägnade mycket uppmärksamhet åt hur och vad vi övervakar med exemplet med våra verkliga produktionstjänster.
Jag var intresserad och gillade det verkligen.
- Av tillkännagivandet att döma, kommer helt att ägnas åt feltolerans, varför valde du detta ämne?
Cassandra är ett typiskt upptaget distribuerat system med en enorm mängd funktionalitet utöver att direkt betjäna användarförfrågningar: skvaller, feldetektering, spridning av schemaändringar, klusterexpansion/reducering, anti-entropi, säkerhetskopiering och återställning, etc. Som i alla distribuerade system, när mängden hårdvara ökar, ökar sannolikheten för fel, så driften av Cassandra produktionskluster kräver en djup förståelse av dess struktur för att förutsäga beteende vid fel och operatörsåtgärder. Efter att ha använt Cassandra i många år har vi , som vi är redo att dela med oss av, och vi vill också diskutera hur kollegor i butiken löser typiska problem.
— När det gäller Cassandra, vad menar du med feltolerans?
Först av allt, naturligtvis, systemets förmåga att överleva typiska hårdvarufel: förlust av maskiner, diskar eller nätverksanslutning med noder/datacenter. Men själva ämnet är mycket bredare och inkluderar i synnerhet återhämtning från fel, inklusive fel som människor sällan är förberedda på, till exempel operatörsfel.
— Kan du ge ett exempel på det mest laddade och största dataklustret?
Ett av våra största kluster är presentklustret: mer än 200 noder och hundratals TB data. Men den är inte den mest laddade, eftersom den täcks av en distribuerad cache. Våra mest trafikerade kluster hanterar tiotusentals RPS för att skriva och tusentals RPS för läsning.
- Wow! Hur ofta går något sönder?
! Totalt har vi mer än 6 tusen servrar, och varje vecka byts ett par servrar och flera dussin diskar ut (utan att ta hänsyn till de parallella processerna för uppgradering och expansion av maskinparken). För varje typ av fel finns det tydliga instruktioner om vad som ska göras och i vilken ordning, allt är automatiserat när det är möjligt, så fel är rutinmässiga och i 99% av fallen uppstår obemärkta av användarna.
— Hur hanterar du sådana avslag?
Redan från början av driften av Cassandra och de första incidenterna arbetade vi med mekanismerna för säkerhetskopiering och återställning från dem, byggde utrullningsprocedurer som tar hänsyn till tillståndet för Cassandra-klustren och till exempel inte tillåter att noder startas om om dataförlust är möjlig. Vi planerar att prata om allt detta på mötet.
— Som du sa, det finns inga absolut pålitliga system. Vilka typer av misslyckanden förbereder du dig för och kan hantera?
Om vi pratar om våra installationer av Cassandra-kluster kommer användarna inte att märka något om vi förlorar flera maskiner i en DC eller en hel DC (detta har hänt). Med ökningen av antalet DC-enheter funderar vi på att börja säkerställa funktionsduglighet i händelse av ett fel på två DC.
— Vad tycker du att Cassandra saknar vad gäller feltolerans?
Cassandra, liksom många andra tidiga NoSQL-butiker, kräver en djup förståelse för dess interna struktur och de dynamiska processer som uppstår. Jag skulle säga att det saknar enkelhet, förutsägbarhet och observerbarhet. Men det ska bli intressant att höra andra mötesdeltagares åsikter!
Oleg, tack så mycket för att du tog dig tid att svara på frågorna!
Vi väntar på alla som vill kommunicera med experter inom området för drift av Apache Cassandra vid mötet den 12 september på vårt kontor i St. Petersburg.
Kom, det ska bli intressant!
Källa: will.com