Video: Burgers' Zoo over dierenverzorging in RTL programma Bedrijf in Beeld 2024
Zookeeper is een gedistribueerd cluster van servers dat samen betrouwbare coördinatie- en synchronisatiediensten biedt voor geclusterde applicaties. Toegegeven, de naam "Zookeeper" lijkt in eerste instantie misschien een vreemde keuze, maar als je begrijpt wat het voor een HBase-cluster doet, kun je de logica achter deze cluster zien. Wanneer u gedistribueerde applicaties bouwt en debugt, is het 'een dierentuin daarbuiten', dus u moet Zookeeper in uw team opnemen.
HBase-clusters kunnen enorm zijn en coördineren van de operaties van de MasterServers, RegionServers en clients kan een ontmoedigende taak zijn, maar dat is waar Zookeeper in beeld komt. Net als in HBase draaien Zookeeper-clusters doorgaans op goedkope x86-servers.
Elke individuele x86-server voert één Zookeeper-softwareproces uit (hierna een Zookeeper-server genoemd), waarbij één Zookeeper-server door het ensemble als leider wordt gekozen en de rest van de servers volgelingen zijn. Dierenverzorgende ensembles worden beheerst door het principe van een meerderheidsquorum.
Configuraties met één Zookeeper-server worden ondersteund voor test- en ontwikkelingsdoeleinden, maar als u een betrouwbare cluster wilt die serverfouten kan tolereren, moet u ten minste drie Zookeeper-servers implementeren om een meerderheidsquorum te bereiken.
Dus, hoeveel Zookeeper-servers heeft u nodig? Vijf is het minimum aanbevolen voor productie gebruik, maar je wilt echt niet met het absolute minimum gaan. Wanneer u besluit uw Zookeeper-ensemble te plannen, volgt u deze eenvoudige formule: 2F + 1 = N waarbij F het aantal fouten is dat u in uw Zookeeper-cluster kunt accepteren en N het totale aantal Zookeeper-servers is dat u moet implementeren.
Vijf wordt aanbevolen omdat één server kan worden uitgeschakeld voor onderhoud, maar de Zookeeper-cluster kan nog steeds één serverfout verdragen.
Zookeeper biedt coördinatie en synchronisatie met wat het znodes noemt, die worden gepresenteerd als een mappenboom en lijken op de bestandspadnamen die u zou zien in een Unix-bestandssysteem. Znodes doen gegevens opslaan, maar niet veel om over te spreken - momenteel minder dan 1 MB standaard.
Het idee hier is dat Zookeeper znodes in het geheugen opslaat en dat deze geheugengebaseerde znodes snelle clienttoegang bieden voor coördinatie, status en andere essentiële functies die vereist zijn door gedistribueerde applicaties zoals HBase. Zookeeper kopieert znodes in het ensemble, dus als servers falen, zijn de znode-gegevens nog steeds beschikbaar zolang een meerderheid van het aantal servers nog steeds actief is.
Een ander primair Zookeeper-concept betreft de manier waarop znode leest (versus schrijft) wordt afgehandeld. Elke Zookeeper-server kan overweg met reads van een client, inclusief de leader, maar alleen de leader-problemen atomic znode schrijft - schrijft dat deze volledig zijn geslaagd of volledig falen.
Wanneer een znode-schrijfverzoek arriveert bij het leader-knooppunt, zendt de leider het schrijfverzoek uit naar de volgknooppunten en wacht dan op een meerderheid van volgers om znode-schrijven voltooid te bevestigen. Na de bevestiging verzendt de leider zelf de znode-write en rapporteert vervolgens de succesvolle voltooiingsstatus aan de klant.
Znodes bieden enkele zeer krachtige garanties. Wanneer een Zookeeper-client (zoals een HBase RegionServer) een znode schrijft of leest, is de bewerking atomic . Het slaagt of volledig of mislukt volledig - er zijn geen gedeeltelijke lees- of schrijfbewerkingen.
Geen enkele andere concurrerende client kan ervoor zorgen dat de lees- of schrijfbewerking mislukt. Bovendien heeft een znode een toegangscontrolelijst (ACL) die is gekoppeld aan de beveiliging, en deze ondersteunt versies, tijdstempels en kennisgeving aan clients wanneer deze verandert.
Zookeeper kopieert znodes in het ensemble, dus als servers falen, zijn de znode-gegevens nog steeds beschikbaar zolang een meerderheid van het aantal servers nog steeds actief is. Dit betekent dat het schrijven naar een willekeurige znode vanaf elke Zookeeper-server over het ensemble moet worden verspreid. De Zookeeper-leider beheert deze bewerking.
Deze znode-schrijfbenadering kan ertoe leiden dat volgers voor korte periodes achter de leider blijven. Zookeeper lost dit potentiële probleem op door een synchronisatieopdracht te geven. Cliënten die dit tijdelijke gebrek aan synchronisatie binnen het Zookeeper-cluster niet kunnen tolereren, kunnen besluiten om een sync-opdracht uit te voeren voordat znodes worden gelezen.
