HBase MasterServer - dummies

Avviare una discussione sull'architettura HBase (Hadoop Database) descrivendo RegionServers invece del MasterServer potrebbe sorprendervi. Il termine RegionServer sembrerebbe implicare che esso dipende (ed è secondario) dal MasterServer e che pertanto è necessario prima discuterne il MasterServer. Come dice la vecchia canzone, però, "non è necessariamente così. "

I RegionServer dipendono dal MasterServer per determinate funzioni, ma non nel senso di una relazione master-slave per l'archiviazione e il recupero dei dati. Nell'angolo in alto a sinistra della figura, si noti che i client non puntano al MasterServer, ma puntano invece al cluster Zookeeper e ai RegionServer.

Il MasterServer non si trova nel percorso per l'archiviazione e l'accesso ai dati: questo è il lavoro del cluster Zookeeper e dei RegionServer. Dai un'occhiata alle funzioni principali di MasterServer, che è anche un processo software (o demone) come i RegionServer. Il MasterServer è lì per

• Monitorare i RegionServer nel cluster HBase: Il MasterServer mantiene un elenco di RegionServer attivi nel cluster HBase.

• Gestisce le operazioni dei metadati: Quando viene creata una tabella o vengono modificati i suoi attributi (impostazioni di compressione, impostazioni della cache, controllo delle versioni e altro) il MasterServer gestisce l'operazione e memorizza i metadati richiesti.

• Assegna regioni: Il MasterServer assegna le regioni a RegionServer.

• Gestisci il failover di RegionServer: Come per qualsiasi cluster distribuito, ci si augura che gli errori del nodo non si verifichino e si pianifichi comunque. Quando i server regionali non riescono, Zookeeper notifica il MasterServer in modo che le operazioni di failover e ripristino possano essere avviate.

• Supervisionare il bilanciamento del carico delle regioni tra tutti i RegionServer disponibili: È possibile ricordare che le tabelle sono composte da regioni distribuite uniformemente su tutti i RegionServer disponibili. Questo è il lavoro del thread di bilanciamento (o chore , se preferisci) che il MasterServer attiva periodicamente.

• Gestisci (e pulisci) le tabelle del catalogo: Due tabelle del catalogo delle chiavi sono utilizzate dal sistema HBase per aiutare un cliente a trovare una particolare coppia di valori chiave nel sistema.

  Il MasterServer fornisce la gestione di queste tabelle critiche per conto del sistema HBase globale.

• Cancella WAL: MasterServer interagisce con il WAL durante il failover di RegionServer e pulisce periodicamente i log.

• Fornisci un framework per coprocessore per osservare le operazioni principali: Ecco un altro nuovo termine per il tuo crescente glossario HBase. I coprocessori vengono eseguiti nel contesto di MasterServer o RegionServers. Ad esempio, un coprocessore osservatore MasterServer consente di modificare o estendere la normale funzionalità del server quando si verificano operazioni come la creazione di tabelle o l'eliminazione di tabelle. Spesso i coprocessori sono utilizzati per gestire indici di tabelle per applicazioni HBase avanzate.

Un coprocessore, che viene eseguito nel contesto di MasterServer o RegionServer (o entrambi), può essere utilizzato per migliorare la sicurezza, creare indici secondari e altro ancora. Puoi trovare ulteriori informazioni sui coprocessori in un blog della comunità HBase.

Come per tutte le tecnologie Hadoop open source, le operazioni di MasterServer probabilmente cambieranno nel tempo mentre la comunità di ingegneri lavora su innovazioni progettate per migliorare HBase. Al momento della stesura, tuttavia, ora avete un elenco abbastanza completo che funge da riferimento di alto livello per il MasterServer.

Infine, un altro punto importante da fare su HBase MasterServer: può e deve essere un MasterServer di backup in qualsiasi cluster HBase. È necessario che ci sia solo un MasterServer attivo in un dato momento, quindi il MasterServer di backup è a scopo di failover.

È possibile ricordare che il MasterServer non si trova nel percorso di accesso ai dati per i client HBase. Tuttavia, è possibile anche ricordare che il MasterServer è responsabile per azioni come il failover di RegionServer e il bilanciamento del carico. La buona notizia è che i client possono continuare a interrogare il cluster HBase se il master va giù, ma per le normali operazioni di cluster, il master non deve rimanere inattivo per un certo periodo di tempo.