Odnoklassniki is de grootste gebruiker van Apache Cassandra op het RuNet en een van de grootste ter wereld. We begonnen Cassandra in 2010 te gebruiken om fotobeoordelingen op te slaan, en nu beheert Cassandra petabytes aan gegevens op duizenden knooppunten. Sterker nog, we hebben zelfs onze eigen .
Op 12 september houden we ons kantoor in St. Petersburg . De belangrijkste spreker van het evenement zal de hoofdingenieur van Odnoklassniki Oleg Anastasyev zijn. Oleg is een expert op het gebied van gedistribueerde en fouttolerante systemen; hij werkt al meer dan 10 jaar samen met Cassandra en herhaaldelijk .
Aan de vooravond van de bijeenkomst spraken we met Oleg over de fouttolerantie van gedistribueerde systemen met Cassandra, vroegen waar hij over zou praten tijdens de bijeenkomst en waarom het de moeite waard was om dit evenement bij te wonen.
Oleg begon zijn programmeercarrière in 1995. Hij ontwikkelde software voor het bankwezen, telecom en transport. Sinds 2007 werkt hij als toonaangevende ontwikkelaar bij Odnoklassniki in het platformteam. Zijn verantwoordelijkheden omvatten het ontwikkelen van architecturen en oplossingen voor systemen met hoge belasting, grote datawarehouses en het oplossen van problemen met de prestaties en betrouwbaarheid van portalen. Ook traint hij ontwikkelaars binnen het bedrijf.
- Oleg, hallo! In mei vond plaats , opgedragen aan Apache Cassandra, zeggen de deelnemers dat de discussies tot laat in de nacht doorgingen. Vertel me alstublieft, wat zijn uw indrukken van de eerste bijeenkomst?
Ontwikkelaars met verschillende achtergronden van verschillende bedrijven kwamen met hun eigen pijn, onverwachte oplossingen voor problemen en verbazingwekkende verhalen. We zijn erin geslaagd het grootste deel van de bijeenkomst in discussievorm te houden, maar er waren zoveel discussies dat we slechts een derde van de geplande onderwerpen konden bespreken. We hebben veel aandacht besteed aan hoe en wat we monitoren aan de hand van het voorbeeld van onze echte productiediensten.
Ik was geïnteresseerd en vond het erg leuk.
- Afgaande op de aankondiging, zal geheel gewijd zijn aan fouttolerantie. Waarom heb je voor dit onderwerp gekozen?
Cassandra is een typisch druk gedistribueerd systeem met een enorme hoeveelheid functionaliteit die verder gaat dan het rechtstreeks bedienen van gebruikersverzoeken: roddels, foutdetectie, verspreiding van schemawijzigingen, uitbreiding/reductie van clusters, anti-entropie, back-ups en herstel, enz. Zoals bij elk gedistribueerd systeem geldt dat naarmate de hoeveelheid hardware toeneemt, de kans op storingen toeneemt. Daarom vereist de werking van Cassandra-productieclusters een diep begrip van de structuur ervan om gedrag te voorspellen in geval van storingen en acties van operators. Na vele jaren Cassandra te hebben gebruikt, hebben wij , die we graag willen delen, en we willen ook bespreken hoe collega's in de winkel typische problemen oplossen.
— Wat bedoel je met fouttolerantie als het om Cassandra gaat?
In de eerste plaats natuurlijk het vermogen van het systeem om typische hardwarestoringen te overleven: verlies van machines, schijven of netwerkconnectiviteit met knooppunten/datacenters. Maar het onderwerp zelf is veel breder en omvat in het bijzonder het herstel na storingen, inclusief storingen waarop mensen zelden voorbereid zijn, bijvoorbeeld bedieningsfouten.
— Kun je een voorbeeld geven van het meest beladen en grootste datacluster?
Een van onze grootste clusters is het giftcluster: ruim 200 knooppunten en honderden TB aan data. Maar het is niet de meest geladen, omdat het wordt gedekt door een gedistribueerde cache. Onze drukste clusters verwerken tienduizenden RPS voor schrijven en duizenden RPS voor lezen.
- Wauw! Hoe vaak gaat iets kapot?
! In totaal hebben we meer dan 6 servers, en elke week worden een paar servers en enkele tientallen schijven vervangen (zonder rekening te houden met de parallelle processen van upgrade en uitbreiding van het machinepark). Voor elk type storing zijn er duidelijke instructies over wat te doen en in welke volgorde. Alles wordt waar mogelijk geautomatiseerd. Storingen zijn dus routine en gebeuren in 99% van de gevallen onopgemerkt door gebruikers.
– Hoe ga je om met zulke weigeringen?
Vanaf het allereerste begin van de werking van Cassandra en de eerste incidenten hebben we gewerkt aan de mechanismen voor back-ups en herstel daarvan, implementatieprocedures gebouwd die rekening houden met de status van Cassandra-clusters en bijvoorbeeld niet toestaan dat knooppunten opnieuw worden opgestart als gegevensverlies mogelijk is. We zijn van plan om dit allemaal te bespreken tijdens de meetup.
— Zoals u zei: er bestaan geen absoluut betrouwbare systemen. Op welke soorten mislukkingen bereidt u zich voor en kunt u hiermee omgaan?
Als we het hebben over onze installaties van Cassandra-clusters, zullen gebruikers niets merken als we meerdere machines in één DC of één volledig DC kwijtraken (dit is gebeurd). Met de toename van het aantal DC’s denken we erover om de inzetbaarheid te gaan garanderen bij uitval van twee DC’s.
— Wat denk je dat Cassandra mist op het gebied van fouttolerantie?
Cassandra vereist, net als veel andere vroege NoSQL-winkels, een diep inzicht in de interne structuur en de dynamische processen die plaatsvinden. Ik zou zeggen dat het eenvoud, voorspelbaarheid en waarneembaarheid mist. Maar het zal interessant zijn om de mening van andere deelnemers aan de bijeenkomst te horen!
Oleg, hartelijk dank dat je de tijd hebt genomen om de vragen te beantwoorden!
We wachten op iedereen die wil communiceren met experts op het gebied van het bedienen van Apache Cassandra tijdens de bijeenkomst op 12 september in ons kantoor in St. Petersburg.
Kom, het zal interessant zijn!
Bron: www.habr.com