CDP Operationele Database (COD) is een autonome transactiedatabase die wordt aangedreven door Apache HBase en Apache Phoenix. Het is een van de belangrijkste dataservices die draait op Cloudera Data Platform (CDP) Public Cloud. U hebt rechtstreeks toegang tot COD vanaf uw CDP-console. Met COD kunnen applicatieontwikkelaars nu profiteren van de kracht van HBase en Phoenix zonder de overhead die vaak gepaard gaat met implementatie en beheer. COD is eenvoudig aan te bieden en zelf te beheren, wat betekent dat ontwikkelaars binnen enkele minuten een nieuwe database-instantie kunnen inrichten en snel prototypes kunnen maken. Autonome functies zoals auto-scaling, auto-healing en auto-tuning zorgen ervoor dat u zich geen zorgen hoeft te maken over het beheer en de administratie van de database.
In deze blog zullen we delen hoe CDP Operational Database een hoge beschikbaarheid voor uw applicaties kan bieden wanneer ze op meerdere beschikbaarheidszones in AWS draaien.
Om volledig te begrijpen wat een Multi-AZ-implementatie betekent voor uw infrastructuur, is het van cruciaal belang om te herkennen hoe Amazon Web Services over de hele wereld is geconfigureerd en dus hoe het de redundantieservices biedt, ongeacht uw locatie. Zoals besproken in de officiële documentatie van Amazon, bestaat de AWS Cloud uit een aantal regio's, fysieke locaties over de hele wereld. Hoewel AZ-storingen niet officieel worden bijgehouden, hebben Cloudera-klanten gemeld dat ze 1-2 keer per jaar AZ-storingen hebben ondervonden. Multi-AZ stretch-implementaties zijn dus vereist om 99,95+% beschikbaarheid te bereiken.
Elke regio bestaat uit een aantal afzonderlijke fysieke datacenters, bekend als beschikbaarheidszones (AZ) . Elke AZ is een op zichzelf staande faciliteit met zijn eigen stroom-, connectiviteits- en netwerkmogelijkheden. De meeste regio's hebben elk 2-3 verschillende beschikbaarheidszones, die zorgen voor voldoende redundantie binnen een bepaalde regio (een AZ wordt weergegeven door een regiocode gevolgd door een letter-ID; bijvoorbeeld us-west-1a) .
Deze redundantie wordt echter alleen toegepast op de opslaglaag (S3) en bestaat niet voor virtuele machines die worden gebruikt voor uw database-instantie. Als iets ervoor zou zorgen dat de beschikbaarheidszone waar uw serverinstanties zich bevinden, uitvalt, zou uw database niet meer werken, omdat de volledige rekeninfrastructuur offline zou zijn.
Dit is waar Multi-AZ-implementatie van pas komt. Een Multi-AZ-implementatie betekent dat de rekeninfrastructuur voor de master- en regioservers van HBase wordt gedistribueerd over meerdere beschikbaarheidszones, zodat wanneer een enkele beschikbaarheidszone uitvalt, slechts een deel van de regioservers wordt beïnvloed en clients zullen automatisch overschakelen naar de resterende servers in de beschikbare AZ's. Evenzo zal de back-upmaster (ervan uitgaande dat de primaire master zich in de AZ bevond met een storing) automatisch de rol van de falende master overnemen, aangezien deze wordt geïmplementeerd in een afzonderlijke AZ van de primaire masterserver. Dit alles is automatisch en vereist geen installatie, geen beheer en geen acties vanuit een gebruikers- / administratief oogpunt. Het werkt gewoon om ervoor te zorgen dat een applicatie niet uitvalt door het verlies van een enkele AZ.
Demo
Nieuw aangemaakte COD-databases maken automatisch gebruik van alle geconfigureerde beschikbaarheidszones in de omgeving. Daarom is het cruciaal om de omgeving in te richten met de zones die we willen gebruiken.
We hebben bijvoorbeeld een omgeving met de volgende AZ's:us-west-1a, us-west-1b en us-west-1c. Wanneer we een COD-database implementeren, wordt deze automatisch geïmplementeerd op een multi-AZ-manier - er is niets aan te doen! Laten we een kijkje achter de schermen nemen en kijken wat er op de AWS-console staat.
COD zorgt ervoor dat worker-knooppunten gelijkelijk zijn verdeeld over geconfigureerde AZ's. (Masters en de Leader worden ook ingezet in verschillende AZ's om een hoge beschikbaarheid te bieden voor het ZooKeeper-quorum.)
Apache HBase heeft al ingebouwde failover-mogelijkheden, dus in het geval dat een AZ offline gaat, is het systeem al aanwezig om direct en automatisch de services van uw database voort te zetten.
Laten we voor wat meer plezier een eenvoudige HBase-laadtest uitvoeren tijdens onze tests. HBase heeft een ingebouwde load test tool die we kunnen gebruiken voor een langlopende schrijftest:
hbase ltt -write 10:1024:10 -num_keys 10000000
Laten we nu een AZ-storing simuleren en kijken wat er gebeurt. De eenvoudigste manier om dat te doen, is door een nieuwe netwerk-ACL toe te voegen die het in- en uitgaand verkeer van een bepaald subnet uitschakelt en vergelijkbare omstandigheden uitvoert als een echte AWS-storing.
In de eerste minuut zien we niets bijzonders op de statuspagina, omdat de database vanuit COD's perspectief nog steeds gezond is.
Maar merkte dat de klant geen vooruitgang meer boekte.
Binnen 10-20 seconden realiseert de Meester zich dat sommige Regio Servers dood zijn.
Als de storing de actieve master treft, schakelt HBase automatisch over naar de back-up die de rol na 10-20 seconden overneemt.
De storing duurt niet te lang, na 2-3 minuten en enkele voorbijgaande regiofouten kan de client weer vooruitgang boeken. Master moest de dode regio's overzetten naar live regioservers.
Om het einde van de storing te simuleren, laten we het maken van de netwerk-ACL ongedaan maken door deze te verwijderen. Regioservers maken weer verbinding met de Master.
Nu zijn we terug waar we oorspronkelijk begonnen. COD is volledig hersteld van de storing. In de schrijfverzoeken zien we twee drops:de eerste is wanneer de client overgaat naar de resterende live regioservers, de tweede iets later is wanneer de load balancer van HBase de regio's terugzet naar de opnieuw verbonden servers.
COD op HDFS
Object Storage in the Cloud is de standaard opslaglaag voor COD en verspreidt gegevens over 3 beschikbaarheidszones achter en zal achter de schermen opnieuw in evenwicht worden gebracht. HBase hoeft alleen wat huishoudelijk werk te doen (regio-overgang) om regio's te bedienen door de resterende servers, waardoor dit een relatief snelle operatie is.
Voor high-performance use-cases ondersteunt COD het gebruik van HDFS als onderliggende opslag. In dit implementatieparadigma configureren we automatisch HDFS-rackbewustzijn voor fouttolerantie door één blokreplica op een ander rack te plaatsen en de racks toe te wijzen aan beschikbaarheidszones. Dit zorgt voor databeschikbaarheid in het geval van een netwerkswitch of partitie binnen het cluster. Het gedrag in de bovenstaande demo lijkt dus sterk op wat u zou zien bij het implementeren van COD met HDFS.
Samenvatting
Multi-AZ-implementatie is cruciaal voor zeer beschikbare databases en nu ondersteunt COD het in AWS als technische preview achter de schermen zonder extra kosten. Het maakt uw operationele werklast robuuster en betrouwbaarder zonder extra configuratie. Het zal zowel algemeen beschikbaar zijn als binnenkort aanvullende cloudproviders (Microsoft, Google) ondersteunen.
Neem contact op met uw Cloudera-accountteam als u meer wilt weten over hoe u kunt migreren van uw implementatie van HBase naar CDP Operational Database in de openbare cloud of probeer het uit met de Cloudera Test Drive.