Ontwerpen voor hoge beschikbaarheid
Pas geavanceerde OTP-principes toe om zeer beschikbare services te ontwerpen en implementeren die bestand zijn tegen storingen en operationeel blijven.
Ontwerpen voor hoge beschikbaarheid is een gratis Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen-les op CoddyKit. Dit is les 1 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat in totaal 4 lessen.
Hoge beschikbaarheid: altijd actief
Wat is hoge beschikbaarheid (HA)? Het gaat om het ontwerpen van systemen die blijven werken, zelfs wanneer onderdelen uitvallen. Erlang en OTP zijn vanaf de basis ontworpen om dit te bereiken.
Denk aan een kritieke dienst zoals een webwinkel. Als die uitvalt, gaan verkopen verloren! HA is erop gericht uitvaltijd tot een minimum te beperken, zodat je toepassing operationeel en toegankelijk blijft voor gebruikers.
Belangrijkste ontwerpprincipes voor HA
Hoge beschikbaarheid bereiken berust op verschillende belangrijke ontwerpprincipes:
- Redundantie: Meerdere onderdelen hebben die dezelfde taak kunnen uitvoeren.
- Fouttolerantie: De mogelijkheid om ondanks storingen te blijven werken.
- Automatisch herstel: Systemen die storingen detecteren en automatisch herstellen of overschakelen.
- Geen single point of failure (SPOF): Elk onderdeel elimineren waarvan een storing het hele systeem zou laten uitvallen.
Actief-passieve redundantie
Het actief-passief-patroon, ook wel Hot Standby genoemd, bestaat uit één primair (actief) component en één of meer secundaire (passieve) componenten.
Het actieve component verwerkt alle aanvragen. Als het uitvalt, neemt een passief component het over en wordt het nieuwe actieve component. Dit biedt redundantie en beperkt de downtime, maar het passieve component doet niets totdat het nodig is.
Actief-passief simuleren in Erlang
We kunnen een actief-passieve opstelling simuleren met Erlang-processen en monitors. Hier houdt een proces voor 'stand-by' toezicht op een 'primair' proces. Als het primaire proces stopt, neemt het stand-byproces het over. Dit is een vereenvoudigd voorbeeld van het wisselen van rollen.
Probeer deze code uit te voeren:
-module(ha_example).
-export([start/0, init/0, primary_loop/0, standby_loop/0]).
start() ->
Pid = spawn(?MODULE, init, []),
io:format("Started HA example with ~p~n", [Pid]),
Pid.
init() ->
% Simulate starting a primary and a standby
PrimaryPid = spawn(?MODULE, primary_loop, []),
StandbyPid = spawn(?MODULE, standby_loop, []),
io:format("Primary started: ~p~n", [PrimaryPid]),
io:format("Standby started: ~p~n", [StandbyPid]),
% Standby monitors Primary to detect its failure
monitor(process, PrimaryPid),
% Keep the init process alive to show output
receive
_ -> ok
end.
primary_loop() ->
io:format("Primary is active and processing requests...~n"),
timer:sleep(5000), % Simulate work
io:format("Primary is going down!~n"),
exit(primary_failure). % Primary fails
standby_loop() ->
receive
{'DOWN', _MonitorRef, process, _Pid, _Reason} ->
io:format("Standby detected Primary failure! Taking over...~n"),
% In a real system, the standby would now become active
% and potentially start its own workers or re-register globally.
become_active()
end.
become_active() ->
io:format("Standby is now the new Active!~n"),
% A real active process would now enter its main loop to handle requests
timer:sleep(infinity).Actief-actief voor schaalbaarheid
In een actief-actief-patroon zijn meerdere componenten gelijktijdig actief en delen ze de werklast. Dit biedt zowel redundantie als betere schaalbaarheid doordat taken worden verdeeld.
Als één actief component uitvalt, blijven de andere aanvragen verwerken, vaak met een lichte afname van de prestaties. Deze opstelling vereist zorgvuldig statusbeheer en load balancing om ervoor te zorgen dat aanvragen efficiënt worden verdeeld.
Statusreplicatie in HA-systemen
Een belangrijke uitdaging bij HA is het behouden van een consistente status tussen redundante componenten. Als een actief component uitvalt, moet de vervanger toegang hebben tot de meest recente informatie.
Mogelijke strategieën zijn:
- Replicatie: Statuswijzigingen kopiëren naar stand-by- of andere actieve componenten, bijvoorbeeld met Mnesia of aangepaste replicatielogica.
- Gedeelde opslag: De status opslaan in een zeer beschikbare externe database die toegankelijk is voor alle knooppunten.
- Stateless ontwerp: Componenten stateless maken, zodat elke instantie elke aanvraag kan verwerken zonder eerdere status nodig te hebben.
Single points of failure elimineren
Een Single Point of Failure (SPOF) is elk onderdeel van een systeem waarvan een storing ervoor zou zorgen dat het hele systeem niet meer werkt. Het identificeren en elimineren van SPOF's is essentieel voor HA.
Veelvoorkomende SPOF's zijn:
- Eén databaseserver.
- Eén netwerkswitch.
- Een centraal coördinatieproces zonder back-up.
Ontwerp je systeem met redundantie in elke kritieke laag, van hardware tot softwarecomponenten.
Levendigheid: heartbeats en gezondheidscontroles
Om automatisch herstel en automatische failover mogelijk te maken, moeten componenten kunnen detecteren of andere componenten nog actief en gezond zijn. Dit gebeurt met heartbeats en gezondheidscontroles.
- Processen kunnen periodiek berichten sturen met de tekst "Ik ben actief".
- Monitors kunnen procescrashes onmiddellijk detecteren, zoals in ons voorbeeld.
- Knooppunten kunnen andere knooppunten bewaken met
net_kernel:monitor_nodes/1voor de gezondheid van het hele cluster.
Een leider kiezen in een cluster
Soms is er zelfs in een actief-actief systeem één coördinator of "leider" nodig om een gedeelde bron te beheren of globale consistentie te garanderen. Als deze leider uitvalt, moet er een nieuwe worden gekozen.
Leidersverkiezing is het proces waarbij in een gedistribueerd systeem dynamisch een nieuwe leider wordt gekozen uit een groep mogelijke kandidaten. De Erlang-module global kan helpen met eenvoudige globale registratie, maar voor robuuste verkiezingsalgoritmen worden vaak aangepaste oplossingen of bibliotheken gebruikt.
Controle van HA-ontwerpprincipes
Bekijk een kritieke Erlang-service die is ontworpen voor hoge beschikbaarheid.
HA-ontwerp: belangrijkste punten
We hebben onderzocht hoe je zeer beschikbare Erlang OTP-systemen ontwerpt:
- We hebben de pijlers begrepen: redundantie, fouttolerantie, automatisch herstel en geen SPOF.
- We hebben de patronen actief-passief en actief-actief bekeken.
- We hebben statusreplicatie en consistentie besproken.
- We hebben kennisgemaakt met heartbeats en het concept van leidersverkiezing.
Door deze geavanceerde OTP-principes toe te passen, kun je robuuste, veerkrachtige toepassingen bouwen die operationeel blijven, zelfs bij storingen.
Leer Erlang met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Ontwerpen voor hoge beschikbaarheid” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen, waaronder “Ontwerpen voor hoge beschikbaarheid”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat in totaal 4 lessen.
Wat leer ik in “Ontwerpen voor hoge beschikbaarheid”?
Pas geavanceerde OTP-principes toe om zeer beschikbare services te ontwerpen en implementeren die bestand zijn tegen storingen en operationeel blijven. Je oefent met Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen te beginnen?
Ervaring vooraf is niet nodig. Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 1 van 4.
Hoe lang duurt de les “Ontwerpen voor hoge beschikbaarheid”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen?
Ja. Elke les over Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Ontwerpen voor hoge beschikbaarheid
- Patronen voor gedistribueerde consensus
- Praktijkvoorbeelden van Erlang OTP
- Backpressure- en loadregulatiepatronen