Zookeeper er en distribuert klynge av servere som samlet gir pålitelige koordinerings- og synkroniseringstjenester for grupperte applikasjoner. Ganske vist kan navnet "Zookeeper" synes å være et merkelig valg, men når du forstår hva det gjør for en HBase-klynge, kan du se logikken bak den. Når du bygger og feilsøker distribuerte applikasjoner "det er en zoo der ute," så du bør sette Zookeeper på laget ditt.
HBase-klynger kan være enorme og koordinere operasjonene til MasterServers, RegionServers, og klienter kan være en skremmende oppgave, men det er her Zookeeper går inn i bildet. Som i HBase kjører Zookeeper-klynger vanligvis på billige x86-servere.
Hver enkelt x86-server kjører en enkelt Zookeeper-programvareprosess (heretter kalt en Zookeeper-server), med en Zookeeper-server valgt av ensemblet som leder og resten av serverne er etterfølgere. Zookeeper-ensembler styres av prinsippet om flertalsquorum.
Konfigurasjoner med en Zookeeper-server støttes for test- og utviklingsformål, men hvis du vil ha en pålitelig klynge som kan tåle serverfeil, må du distribuere minst tre Zookeeper-servere for å oppnå flertalsquorum.
Så, hvor mange Zookeeper-servere trenger du? Fem er minimum anbefalt for produksjon, men du vil virkelig ikke gå med det minste minimum. Når du bestemmer deg for å planlegge din Zookeeper-ensemble, følg denne enkle formelen: 2F + 1 = N hvor F er antall feil du kan akseptere i Zookeeper-klyngen din, og N er det totale antallet Zookeeper-servere du må distribuere.
Fem anbefales fordi en server kan slås av for vedlikehold, men Zookeeper-klyngen kan fortsatt tolerere en serverfeil.
Zookeeper sørger for koordinering og synkronisering med det som kalles znodes , som presenteres som et katalogtreet og ligner filbanenavnene du vil se i et Unix-filsystem. Znodes gjør lagre data, men ikke mye å snakke om - for øyeblikket mindre enn 1 MB som standard.
Tanken her er at Zookeeper lagrer znodes i minnet, og at disse minnebaserte znodes gir rask tilgang til klienten for koordinering, status og andre vitale funksjoner som kreves av distribuerte applikasjoner som HBase. Zookeeper replikerer znodes over ensemblet, så hvis servere feiler, er znode data fortsatt tilgjengelig så lenge et flertalsquorum av servere fortsatt er oppe.
En annen primær Zookeeper-konseptet omhandler hvordan znode leser (versus skriver) håndteres. Enhver Zookeeper-server kan håndtere leser fra en klient, inkludert lederen, men bare lederproblemene atom znode skriver - skriver at enten helt lykkes eller helt mislykkes.
Når en znode-skriveforespørsel kommer til ledernoden, sender lederen skriveforespørselen til følgesnøtene og venter deretter på at et flertall av tilhengerne vil anerkjenne znode-skrive-komplett. Etter bekreftelsen utsteder lederen znode-skriveren selv og rapporterer deretter den vellykkede ferdigstillingsstatusen til klienten.
Znodes gir noen svært kraftige garantier. Når en Zookeeper-klient (for eksempel en HBase RegionServer) skriver eller leser en znode, er operasjonen atom . Det lykkes enten helt eller helt - det finnes ingen delvis lest eller skriver.
Ingen andre konkurrerende klienter kan føre til at lese- eller skriveoperasjonen mislykkes. I tillegg har en znode en tilgangskontrollliste (ACL) tilknyttet den for sikkerhet, og den støtter versjoner, tidsstempler og varsling til klienter når det endres.
Zookeeper replikerer znodes over ensemblet, så hvis servere feiler, er znode data fortsatt tilgjengelig så lenge et flertalsquorum av servere fortsatt er oppe. Dette betyr at skriver til hvilken som helst znode fra hvilken som helst Zookeeper-server må forplanteres over ensemblet. Zookeeper-lederen administrerer denne operasjonen.
Denne znode skrive-tilnærmingen kan føre til at etterfølgere faller bak lederen i korte perioder. Zookeeper løser dette potensielle problemet ved å gi en synkroniseringskommando. Klienter som ikke kan tolerere denne midlertidige mangelen på synkronisering i Zookeeper-klyngen, kan bestemme seg for å utstede en synkroniseringskommando før de leser znoder.
