CDP Operational Database (COD) är en autonom transaktionsdatabas som drivs av Apache HBase och Apache Phoenix. Det är en av de viktigaste datatjänsterna som körs på Cloudera Data Platform (CDP) Public Cloud. Du kan komma åt COD direkt från din CDP-konsol. Med COD kan applikationsutvecklare nu utnyttja kraften hos HBase och Phoenix utan de omkostnader som ofta är relaterade till driftsättning och hantering. COD är lätt att tillhandahålla och självhanterande, vilket innebär att utvecklare kan tillhandahålla en ny databasinstans inom några minuter och börja skapa prototyper snabbt. Autonoma funktioner som automatisk skalning, automatisk läkning och automatisk justering säkerställer att det inte finns någon hantering och administration av databasen att oroa sig för.
I den här bloggen kommer vi att dela hur CDP Operational Database kan leverera hög tillgänglighet för dina applikationer när de körs på flera tillgänglighetszoner i AWS.
För att till fullo förstå vad en Multi-AZ-distribution innebär för din infrastruktur är det viktigt att känna igen hur Amazon Web Services är konfigurerat över hela världen och därmed hur det tillhandahåller redundanstjänsterna oavsett var du befinner dig. Som diskuteras i Amazons officiella dokumentation består AWS Cloud av ett antal regioner, som är fysiska platser runt om i världen. Även om AZ-avbrott inte officiellt spåras, har Cloudera-kunder rapporterat att de har upplevt AZ-avbrott 1-2 gånger om året. Så, Multi-AZ-utbyggnader krävs för att uppnå 99,95+ % tillgänglighet.
Varje region består av ett antal separata fysiska datacenter, kända som tillgänglighetszoner (AZ) . Varje AZ är en fristående anläggning med sin egen kraft, anslutningsmöjligheter och nätverksmöjligheter. De flesta regioner har 2-3 olika tillgänglighetszoner vardera, vilket ger tillräcklig redundans inom en given region (En A-Ö representeras av en regionkod följt av en bokstavsidentifierare; till exempel us-west-1a) .
Denna redundans tillämpas dock endast på lagringslagret (S3) och finns inte för virtuella maskiner som används för din databasinstans. Om något skulle orsaka ett avbrott i tillgänglighetszonen där dina serverinstanser finns, skulle din databas sluta fungera, eftersom hela beräkningsinfrastrukturen skulle vara offline.
Det är här Multi-AZ-distribution kommer in. En Multi-AZ-distribution innebär att beräkningsinfrastrukturen för HBases huvud- och regionservrar distribueras över flera tillgänglighetszoner, vilket säkerställer att när en enskild tillgänglighetszon har ett avbrott kommer endast en del av regionservrarna att vara påverkas och klienter kommer automatiskt att byta över till de återstående servrarna i de tillgängliga A-Ö. På samma sätt kommer backup-mastern (förutsatt att den primära mastern var i A-Ö och hade ett avbrott) automatiskt att ta över rollen som den misslyckade mastern eftersom den är utplacerad i en separat A-Ö från den primära masterservern. Allt detta sker automatiskt och kräver ingen installation, ingen hantering och inga åtgärder ur användar-/administrativ synvinkel. Det fungerar helt enkelt för att säkerställa att en applikation inte drabbas av ett avbrott på grund av förlusten av en enda A-Ö.
Demo
Nyskapade COD-databaser kommer automatiskt att dra fördel av alla konfigurerade tillgänglighetszoner i miljön. Därför är det avgörande att skapa miljön med de zoner som vi skulle vilja använda.
Till exempel har vi en miljö med följande A-Ö:us-west-1a, us-west-1b och us-west-1c. När vi distribuerar en COD-databas distribueras den automatiskt på ett multi-AZ-sätt - det finns inget att göra! Låt oss kolla bakom kulisserna och se vad som finns på AWS-konsolen.
COD ser till att arbetarnoder är lika spridda över konfigurerade A-Ö. (Mästare och ledaren är också utplacerade i olika A-Ö för att ge hög tillgänglighet för ZooKeepers kvorum.)
Apache HBase har redan inbyggda failover-funktioner, så i händelse av att en A-Ö går offline är systemet redan på plats för att omedelbart och automatiskt fortsätta tjänsterna i din databas.
För att lägga till lite roligare, låt oss köra ett enkelt HBase-belastningstest under vår testning. HBase har ett inbyggt lasttestverktyg som vi kan använda för ett långvarigt skrivtest:
hbase ltt -write 10:1024:10 -num_keys 10000000
Låt oss simulera AZ-fel nu och se vad som händer. Det enklaste sättet att göra det är att lägga till en ny nätverks-ACL som inaktiverar in- och utgående trafik för ett givet undernät som utför liknande förhållanden som ett verkligt AWS-avbrott.
Under den första minuten ser vi inget särskilt intressant på statussidan, för ur COD:s perspektiv är databasen fortfarande frisk.
Men märkte att klienten har slutat göra framsteg.
Efter 10-20 sekunder inser mästaren att några av regionservrarna är döda.
Om avbrottet påverkar den aktiva mastern kommer HBase automatiskt att byta till backupen som tar över rollen efter 10-20 sekunder.
Felet tar inte för lång tid, efter 2-3 minuter och vissa övergående regionfel kan klienten göra framsteg igen. Master var tvungen att överföra de döda regionerna till levande regionservrar.
För att simulera slutet på avbrottet, låt oss ångra skapandet av nätverkets ACL genom att ta bort det. Regionservrar ansluter tillbaka till mastern.
Nu är vi tillbaka där vi ursprungligen började. COD har återhämtat sig helt från avbrottet. I skrivförfrågningarna kan vi se två droppar:den första är när klienten övergick till de återstående live regionservrarna, den andra något senare är när HBases lastbalanserare flyttade tillbaka regionerna till de återanslutna servrarna.
COD på HDFS
Objektlagring i molnet är standardlagringslagret för COD och sprider data över 3 tillgänglighetszoner bakom och kommer att balansera om bakom kulisserna. HBase behöver bara göra lite hushållning (regionövergång) för att betjäna regioner av de återstående servrarna vilket gör detta till en relativt snabb operation.
För användningsfall med hög prestanda stöder COD att använda HDFS som underliggande lagring. I detta implementeringsparadigm konfigurerar vi automatiskt HDFS-rackmedvetenhet för feltolerans genom att placera en blockreplik på ett annat rack och mappa racken till Availability Zones. Detta ger datatillgänglighet i händelse av ett nätverksswitchfel eller partition inom klustret. Så beteendet i demon ovan är väldigt likt det du skulle se när du distribuerar COD med HDFS.
Sammanfattning
Multi-AZ-distribution är avgörande för högt tillgängliga databaser och nu stöder COD det i AWS som teknisk förhandsvisning bakom kulisserna utan extra kostnad. Det gör din operativa arbetsbelastning mer robust och tillförlitlig utan extra konfiguration. Det kommer både att vara allmänt tillgängligt och stödja ytterligare molnleverantörer (Microsoft, Google) snart.
Kontakta ditt Cloudera-kontoteam om du är intresserad av att lära dig mer om hur du migrerar från din distribution av HBase till CDP Operational Database i det offentliga molnet eller ta det en sväng med Cloudera Test Drive.