Distributed Systems

Het Fundament onder Kubernetes, Etcd en Kafka

In een moderne cloud-native infrastructuur draait vrijwel niets meer op één enkele server. Om schaalbaar en feilloos te blijven functioneren bij hardware-storingen, draaien kritieke componenten (zoals Kubernetes clusters, databases en message brokers) in gedistribueerde clusters over meerdere machines heen. Hier ontstaat echter een razend ingewikkeld computertechnisch vraagstuk: **Het Consensus Probleem**. Hoe zorg je ervoor dat een cluster van vijf onafhankelijke servers het rotsvast met elkaar eens is over de status van de data, zelfs als het netwerk plotseling uitvalt, kabels worden doorgeknipt of servers herstarten?

Decennialang werd dit opgelost met het complexe *Paxos* algoritme, dat zo berucht ingewikkeld was om te begrijpen en te implementeren dat het bijna als magie werd beschouwd. In 2014 introduceerden computerwetenschappers een elegant alternatief: **Raft**. Raft is ontworpen met één hoofddoel voor ogen: begrijpbaarheid. Vandaag de dag is Raft het kloppende hart achter legendarische infrastructuur-tools zoals etcd (de database van Kubernetes), HashiCorp Consul en CockroachDB.

De Drie Rollen in een Raft Cluster

Een Raft-cluster bestaat uit een aantal nodes (meestal een oneven aantal, zoals 3, 5 of 7 om ‘split brain’ scenario’s te voorkomen). Op elk willekeurig moment heeft elke node binnen het cluster exact één van de volgende drie rollen:

  • Leader (Leider): Alle inkomende schrijf-verzoeken (writes) van clients worden verwerkt door de Leader. De Leader is verantwoordelijk voor het doorsturen van deze wijzigingen naar alle Followers. Er kan in een Raft-term slechts één actieve Leader zijn.
  • Follower (Volger): Passieve nodes die simpelweg wachten op instructies en hartslagen (heartbeats) van de Leader. Als de Leader sterft, kunnen Followers promoveren tot kandidaat.
  • Candidate (Kandidaat): Een tijdelijke rol die een node aanneemt wanneer hij merkt dat de Leader niet meer reageert, om stemmen te werven voor het leiderschap.

Leidersverkiezingen (Leader Election)

Raft maakt gebruik van een sterk gesynchroniseerd timingsmechanisme op basis van ‘Heartbeats’ en gerandomiseerde timeouts. Followers verwachten periodiek een lege heartbeat-berichtje van de Leader. Als een Follower dit gedurende een ‘Election Timeout’ (bijv. tussen 150 en 300 milliseconden, willekeurig gekozen per node om botsende verkiezingen te voorkomen) niet ontvangt, concludeert hij dat de Leader dood is.

De node promoveert zichzelf tot **Kandidaat**, verhoogt de term-counter (het kiesnummer), en stuurt een verzoek om stemmen naar alle andere nodes in het cluster. Als de kandidaat de meerderheid van de stemmen ontvangt, kroont hij zichzelf tot de nieuwe **Leader** en begint hij direct met het rondsturen van hartslagen om zijn dominantie te bevestigen.

Log Replicatie en Veiligheid

Zodra de Leader een schrijf-verzoek ontvangt van een client (bijv. “Zet X op 5”), voegt hij dit toe aan zijn lokale logboek. Vervolgens stuurt hij dit log-item via een AppendEntries RPC naar alle Followers. Pas wanneer een *meerderheid* (quorum) van de servers bevestigt dat ze het item veilig in hun logboek hebben geschreven, verklaart de Leader de transactie als **Committed**. De Leader past de wijziging toe op zijn state machine en stuurt het succesbericht terug naar de client. Bij de eerstvolgende heartbeat krijgen ook de achterlopende of tijdelijk uitgevallen nodes de opdracht om de committed logs toe te passen, waardoor het hele cluster 100% consistent blijft.

Raft garandeert dat geen enkele committed transactie ooit verloren gaat, zelfs niet bij het uitvallen van meerdere nodes tegelijk. Het begrijpen van dit soort consensus-algoritmen tilt je begrip van cloud-infrastructuur naar een hoger niveau. Lees meer over cloud-architectuur op Computable.

 

Volgende:Distributed Tracing en OpenTelemetry: End-to-End Request Monitoring

Platform Engineering: Het Bouwen van een Self-Service Internal Developer Platform (IDP)

Platform Engineering: De Evolutie Voorbij DevOps en de Opkomst van IDP’s
Kennisbank overzicht

Geverifieerd door MonsterInsights