CDP Operational Database (COD) er en autonom transaktionsdatabase drevet af Apache HBase og Apache Phoenix. Det er en af de vigtigste datatjenester, der kører på Cloudera Data Platform (CDP) Public Cloud. Du kan få adgang til COD direkte fra din CDP-konsol. Med COD kan applikationsudviklere nu udnytte kraften i HBase og Phoenix uden de faste omkostninger, der ofte er relateret til implementering og administration. COD er nem at klargøre og selvadministrerende, hvilket betyder, at udviklere kan klargøre en ny databaseinstans inden for få minutter og begynde at skabe prototyper hurtigt. Autonome funktioner som auto-skalering, auto-healing og auto-tuning sikrer, at der ikke er nogen styring og administration af databasen at bekymre sig om.
I denne blog vil vi dele, hvordan CDP Operational Database kan levere høj tilgængelighed til dine applikationer, når de kører på flere tilgængelighedszoner i AWS.
For fuldt ud at forstå, hvad en Multi-AZ-implementering betyder for din infrastruktur, er det afgørende at genkende, hvordan Amazon Web Services er konfigureret over hele kloden, og dermed hvordan det leverer redundanstjenesterne uanset din placering. Som diskuteret i Amazons officielle dokumentation består AWS Cloud af en række regioner, som er fysiske steder rundt om i verden. Selvom AZ-udfald ikke spores officielt, har Cloudera-kunder rapporteret at have oplevet AZ-udfald 1-2 gange om året. Så, Multi-AZ-stræk-implementeringer er påkrævet for at opnå 99,95+ % tilgængelighed.
Hver region omfatter et antal separate fysiske datacentre, kendt som tilgængelighedszoner (AZ) . Hver AZ er en selvstændig facilitet med sin egen strøm, tilslutningsmuligheder og netværksmuligheder. De fleste regioner er hjemsted for 2-3 forskellige tilgængelighedszoner hver, hvilket giver tilstrækkelig redundans inden for en given region (En AZ er repræsenteret af en regionskode efterfulgt af en bogstavidentifikator; f.eks. us-west-1a) .
Denne redundans anvendes dog kun på lagerlaget (S3) og eksisterer ikke for virtuelle maskiner, der bruges til din databaseinstans. Hvis noget skulle forårsage, at tilgængelighedszonen, hvor dine serverforekomster opholder sig, skulle have et udfald, ville din database ophøre med at fungere, da hele computerinfrastrukturen ville være offline.
Det er her Multi-AZ Deployment kommer ind i billedet. En Multi-AZ Deployment betyder, at computerinfrastrukturen for HBase's Master og Region Servers er fordelt på tværs af flere Availability Zones, hvilket sikrer, at når en enkelt Availability Zone har et udfald, vil kun en del af Region Servere blive påvirket, og klienter vil automatisk skifte over til de resterende servere i de tilgængelige AZ'er. Tilsvarende vil backup-masteren (forudsat at den primære master befandt sig i AZ'en og have et udfald) automatisk overtage rollen som den fejlende master, da den er installeret i en separat AZ fra den primære masterserver. Alt dette er automatisk og kræver ingen opsætning, ingen styring og ingen handlinger fra et bruger-/administrativt synspunkt. Det virker ganske enkelt for at sikre, at en applikation ikke lider af en fejl på grund af tab af en enkelt AZ.
Demo
Nyoprettede COD-databaser vil automatisk drage fordel af alle konfigurerede tilgængelighedszoner i miljøet. Derfor er det afgørende at indrette miljøet med de zoner, vi gerne vil bruge.
For eksempel har vi et miljø med følgende AZ'er:us-west-1a, us-west-1b og us-west-1c. Når vi implementerer en COD-database, implementeres den automatisk på en multi-AZ-måde - der er ikke noget at gøre! Lad os tjekke bag kulisserne og se, hvad der er på AWS-konsollen.
COD sørger for, at arbejderknudepunkter er lige spredt på tværs af konfigurerede AZ'er. (Mestre og lederen er også indsat i forskellige AZ'er for at give høj tilgængelighed for ZooKeeper-kvorummet.)
Apache HBase har allerede indbyggede failover-funktioner, så i tilfælde af at en AZ går offline, er systemet allerede på plads til øjeblikkeligt og automatisk at fortsætte tjenesterne i din database.
For at tilføje lidt mere sjov, lad os køre en simpel HBase-belastningstest under vores test. HBase har et indbygget belastningstestværktøj, som vi kan bruge til en langvarig skrivetest:
hbase ltt -write 10:1024:10 -num_keys 10000000
Lad os simulere AZ-fejl nu og se, hvad der sker. Den nemmeste måde at gøre det på er at tilføje en ny netværks-ACL, som deaktiverer ind- og udgående trafik fra et givet undernet, der udfører lignende betingelser som en reel AWS-afbrydelse.
I det første minut ser vi ikke noget særligt interessant på statussiden, for fra CODs perspektiv er databasen stadig sund.
Men bemærkede, at klienten er holdt op med at gøre fremskridt.
På 10-20 sekunder indser mesteren, at nogle af regionsserverne er døde.
Hvis udfaldet påvirker den aktive master, vil HBase automatisk skifte til backup, som overtager rollen efter 10-20 sekunder.
Fejlen tager ikke for lang tid, efter 2-3 minutter og nogle forbigående regionsfejl er klienten i stand til at gøre fremskridt igen. Master var nødt til at overføre de døde områder til levende regionsservere.
For at simulere slutningen af afbrydelsen, lad os fortryde oprettelsen af netværkets ACL ved at slette den. Regionsservere opretter forbindelse tilbage til masteren.
Nu er vi tilbage, hvor vi oprindeligt startede. COD er kommet sig helt over afbrydelsen. I skriveanmodningerne kan vi se to fald:den første er, da klienten overgik til de resterende live regionsservere, den anden lidt senere er, da HBases load balancer flyttede regionerne tilbage til de genforbundne servere.
COD på HDFS
Object Storage in the Cloud er standardlagerlaget for COD og spreder data på tværs af 3 tilgængelighedszoner bagved og vil re-balancere bag kulisserne. HBase skal kun udføre noget husholdning (regionovergang) for at betjene regioner af de resterende servere, hvilket gør dette til en relativt hurtig operation.
Til højtydende anvendelsestilfælde understøtter COD brugen af HDFS som dets underliggende lager. I dette implementeringsparadigme konfigurerer vi automatisk HDFS-rackbevidsthed for fejltolerance ved at placere en blokreplika på et andet rack og kortlægge rackene til Availability Zones. Dette giver datatilgængelighed i tilfælde af en netværksswitchfejl eller partition i klyngen. Så adfærden i demoen ovenfor ligner meget, hvad du ville se, når du implementerer COD med HDFS.
Oversigt
Multi-AZ-implementering er afgørende for meget tilgængelige databaser, og nu understøtter COD det i AWS som teknisk preview bag kulisserne uden ekstra omkostninger. Det gør din operationelle arbejdsbyrde mere robust og pålidelig uden yderligere konfiguration. Det vil både være generelt tilgængeligt og snart understøtte yderligere cloud-udbydere (Microsoft, Google).
Kontakt dit Cloudera-kontoteam, hvis du er interesseret i at lære mere om, hvordan du migrerer fra din implementering af HBase til CDP Operational Database i den offentlige sky, eller tag det en tur med Cloudera Test Drive.