Zookeeper er en distribueret klynge af servere, der samlet leverer pålidelige koordinations- og synkroniseringstjenester til grupperede applikationer. Helt sikkert kan navnet "Zookeeper" synes at være et mærkeligt valg, men når du forstår hvad det gør for en HBase-klynge, kan du se logikken bag den. Når du bygger og fejler distribuerede applikationer "det er en zoo derude", så du bør sætte Zookeeper på dit hold.
HBase-klynger kan være enorme og koordinere operationerne fra MasterServers, RegionServers, og klienter kan være en skræmmende opgave, men det er her Zookeeper kommer ind i billedet. Som i HBase kører Zookeeper-klynger typisk på billige x86-servere.
Hver enkelt x86-server kører en enkelt Zookeeper-softwareproces (herefter benævnt en Zookeeper-server), med en Zookeeper-server valgt af ensemblet som leder og resten af serverne er tilhængere. Zookeeper-ensembler styres af princippet om flertalsquorum.
Konfigurationer med en Zookeeper-server understøttes til test- og udviklingsformål, men hvis du vil have en pålidelig klynge, der kan tolerere serverfejl, skal du installere mindst tre Zookeeper-servere for at opnå et flertalsquorum.
Så, hvor mange Zookeeper-servere skal du bruge? Fem er det minimale anbefalede til produktion, men du ønsker virkelig ikke at gå med det minimale minimum. Når du beslutter dig for at planlægge dit Zookeeper-ensemble, skal du følge denne enkle formel: 2F + 1 = N hvor F er antallet af fejl, du kan acceptere i din Zookeeper-klynge, og N er det samlede antal Zookeeper-servere, du skal installere.
Fem anbefales, fordi en server kan lukkes for vedligeholdelse, men Zookeeper-klyngen kan stadig tolerere en serverfejl.
Zookeeper sørger for koordinering og synkronisering med det, den kalder znodes , som præsenteres som et katalogtræ og ligner de filstiavne, du vil se i et Unix-filsystem. Znodes gør gem data, men ikke meget at tale om - i øjeblikket mindre end 1 MB som standard.
Tanken her er, at Zookeeper gemmer znodes i hukommelse, og at disse hukommelsesbaserede znodes giver hurtig klientadgang for koordination, status og andre vitale funktioner, der kræves af distribuerede applikationer som HBase. Zookeeper replikerer znodes over ensemblet, så hvis servere fejler, er znode data stadig tilgængelig så længe et flertalsquorum af servere stadig er i gang.
En anden primær Zookeeper koncept vedrører, hvordan znode læser (versus skriver) håndteres. Enhver Zookeeper-server kan håndtere læsninger fra en klient, herunder lederen, men kun lederspørgsmålene atom znode skriver - skriver, at enten helt lykkes eller helt fejler.
Når en znode-skriveforespørgsel kommer til ledernoden, sender lederen skriveforespørgslen til følgeknuderne og venter derefter på, at et flertal af tilhængere skal anerkende znode-skrive komplet. Efter bekræftelsen udsteder lederen znode-skrivningen selv og rapporterer derefter den vellykkede færdiggørelsesstatus til klienten.
Znodes giver nogle meget kraftfulde garantier. Når en Zookeeper-klient (som en HBase RegionServer) skriver eller læser en znode, er operationen atom . Det lykkes enten fuldstændigt eller helt fejler - der er ikke nogen delvist læsning eller skrivning.
Ingen andre konkurrerende klienter kan medføre, at læsnings- eller skriveoperationen mislykkes. Derudover har en znode en adgangskontrolliste (ACL) tilknyttet den til sikkerhed, og den understøtter versioner, tidsstempler og underretning til klienter, når det ændres.
Zookeeper replikerer znodes på tværs af ensemblet, så hvis servere fejler, er znode-dataene stadig tilgængelige, så længe et flertalsquorum af servere stadig er i gang. Det betyder, at skriver til enhver znode fra enhver Zookeeper-server skal udbredes på tværs af ensemblet. Zookeeper-lederen styrer denne operation.
Denne znode write-tilgang kan medføre, at tilhængere falder bag lederen i korte perioder. Zookeeper løser dette potentielle problem ved at levere en synkroniseringskommando. Kunder, som ikke kan tolerere denne midlertidige manglende synkronisering i Zookeeper-klyngen, kan beslutte at udstede en synkroniseringskommando, før de læser znodes.
