Banca dati operativa CDP (COD) è un database transazionale autonomo basato su Apache HBase e Apache Phoenix. È uno dei principali Data Services che gira su Cloudera Data Platform (CDP) Public Cloud. Puoi accedere a COD direttamente dalla tua console CDP. Con COD, gli sviluppatori di applicazioni possono ora sfruttare la potenza di HBase e Phoenix senza le spese generali che sono spesso legate all'implementazione e alla gestione. COD è di facile fornitura e autogestione, il che significa che gli sviluppatori possono eseguire il provisioning di una nuova istanza di database in pochi minuti e iniziare a creare prototipi rapidamente. Funzionalità autonome come la scalabilità automatica, la riparazione automatica e l'ottimizzazione automatica assicurano che non ci sia alcuna gestione e amministrazione del database di cui preoccuparsi.
In questo blog condivideremo in che modo il database operativo CDP può fornire un'elevata disponibilità per le tue applicazioni quando vengono eseguite su più zone di disponibilità in AWS.
Per comprendere appieno cosa sia una implementazione Multi-AZ significa per la tua infrastruttura, è fondamentale riconoscere come Amazon Web Services è configurato in tutto il mondo e quindi come fornisce i servizi di ridondanza, indipendentemente dalla tua posizione. Come discusso nella documentazione ufficiale di Amazon, il cloud AWS è composto da una serie di regioni, che sono posizioni fisiche in tutto il mondo. Sebbene le interruzioni AZ non siano ufficialmente monitorate, i clienti Cloudera hanno riferito di aver subito interruzioni AZ 1-2 volte l'anno. Pertanto, per ottenere una disponibilità superiore al 99,95% sono necessarie implementazioni estensibili Multi-AZ.
Ciascuna regione comprende un numero di data center fisici separati, noti come zone di disponibilità (AZ) . Ogni AZ è una struttura autonoma con le proprie capacità di alimentazione, connettività e rete. La maggior parte delle regioni ospita 2-3 diverse zone di disponibilità ciascuna, fornendo un'adeguata ridondanza all'interno di una determinata regione (una AZ è rappresentata da un codice regione seguito da una lettera identificativa; ad esempio, us-west-1a) .
Tuttavia, questa ridondanza viene applicata solo al livello di archiviazione (S3) e non esiste per le macchine virtuali utilizzate per l'istanza del database. Se qualcosa dovesse causare un'interruzione della zona di disponibilità in cui risiedono le istanze del server, il database cesserebbe di funzionare, poiché l'intera infrastruttura di elaborazione sarebbe offline.
È qui che entra in gioco la distribuzione Multi-AZ. Una distribuzione Multi-AZ significa che l'infrastruttura di calcolo per i server master e regionali di HBase è distribuita su più zone di disponibilità assicurando che quando una singola zona di disponibilità ha un'interruzione, solo una parte dei server regionali sarà interessati e i client passeranno automaticamente ai server rimanenti nelle AZ disponibili. Allo stesso modo, il master di backup (supponendo che il master primario fosse nella AZ in caso di interruzione) assumerà automaticamente il ruolo del master in errore poiché viene distribuito in una AZ separata dal server master primario. Tutto questo è automatico, non richiede nessuna configurazione, nessuna gestione e nessuna azione dal punto di vista utente/amministrativo. Funziona semplicemente per garantire che un'applicazione non subisca un'interruzione a causa della perdita di una singola AZ.
Demo
I database COD appena creati trarranno vantaggio automaticamente da tutte le zone di disponibilità configurate nell'ambiente. Pertanto è fondamentale allestire l'ambiente con le zone che vorremmo utilizzare.
Ad esempio, abbiamo un ambiente con le seguenti AZ:us-west-1a, us-west-1b e us-west-1c. Quando distribuiamo un database COD, viene distribuito automaticamente in modo multi-AZ:non c'è niente da fare! Controlliamo dietro le quinte e vediamo cosa c'è sulla console AWS.
COD assicura che i nodi di lavoro siano equamente distribuiti tra le AZ configurate. (I Master e il Leader sono anche distribuiti in diverse zone di disponibilità per fornire un'elevata disponibilità per il quorum di ZooKeeper.)
Apache HBase ha già funzionalità di failover integrate, quindi nel caso in cui una AZ vada offline, il sistema è già pronto per continuare istantaneamente e automaticamente i servizi del tuo database.
Per aggiungere un po' più di divertimento, eseguiamo un semplice test di carico HBase durante i nostri test. HBase ha uno strumento di test di carico integrato che possiamo utilizzare per un test di scrittura di lunga durata:
hbase ltt -write 10:1024:10 -num_keys 10000000
Simuliamo ora il guasto AZ e vediamo cosa succede. Il modo più semplice per farlo è aggiungere una nuova lista di controllo accessi di rete che disabilita il traffico in ingresso e in uscita di una determinata sottorete eseguendo condizioni simili a una vera interruzione di AWS.
Nel primo minuto non vediamo nulla di particolarmente interessante nella pagina di stato, perché dal punto di vista di COD il database è ancora integro.
Ma ho notato che il client ha smesso di fare progressi.
In 10-20 secondi, il Master si accorge che alcuni dei Region Server sono morti.
Se l'interruzione interessa il master attivo, HBase passerà automaticamente al backup che assumerà il ruolo dopo 10-20 secondi.
L'errore non richiede molto tempo, dopo 2-3 minuti e alcuni errori di regione transitori il client è in grado di fare nuovamente progressi. Il master ha dovuto trasferire le regioni morte ai server regionali attivi.
Per simulare la fine dell'interruzione, annulliamo la creazione dell'ACL di rete eliminandola. I server regionali si stanno riconnettendo al Master.
Ora siamo tornati al punto di partenza. COD si è completamente ripreso dall'interruzione. Nelle richieste di scrittura possiamo vedere due cali:il primo è quando il client è passato ai restanti server regionali attivi, il secondo leggermente più tardi è quando il sistema di bilanciamento del carico di HBase ha riportato le regioni ai server ricollegati.
COD su HDFS
Object Storage in the Cloud è il livello di archiviazione predefinito per COD e distribuisce i dati in 3 zone di disponibilità dietro le quinte e si riequilibrerà dietro le quinte. HBase deve solo eseguire alcune operazioni di pulizia (transizione di regione) per servire le regioni dai server rimanenti, rendendo questa operazione relativamente veloce.
Per casi d'uso ad alte prestazioni, COD supporta l'utilizzo di HDFS come storage sottostante. In questo paradigma di distribuzione, configuriamo automaticamente la consapevolezza del rack HDFS per la tolleranza agli errori posizionando una replica di blocco su un rack diverso e mappando i rack alle zone di disponibilità. Ciò fornisce la disponibilità dei dati in caso di guasto di uno switch di rete o di una partizione all'interno del cluster. Quindi, il comportamento nella demo sopra è molto simile a quello che vedresti durante l'implementazione di COD con HDFS.
Riepilogo
La distribuzione multi-AZ è fondamentale per i database ad alta disponibilità e ora COD la supporta in AWS come anteprima tecnica dietro le quinte senza costi aggiuntivi. Rende il carico di lavoro operativo più robusto e affidabile senza alcuna configurazione aggiuntiva. A breve sarà disponibile a livello generale e supporterà altri fornitori di servizi cloud (Microsoft, Google).
Contatta il team del tuo account Cloudera se sei interessato a saperne di più su come migrare dalla tua distribuzione di HBase al database operativo CDP nel cloud pubblico o fai un giro con Cloudera Test Drive.
