Configurare la replica di cluster Apache HBase nelle reti virtuali di Azure

Informazioni su come configurare la replica Apache HBase in una rete virtuale o tra due reti virtuali in Azure.

La replica di cluster usa una metodologia con push dell'origine. Un cluster HBase può essere un'origine o una destinazione o può soddisfare entrambi i ruoli in una sola volta. La replica è asincrona. L'obiettivo della replica è la coerenza finale. Quando l'origine riceve una modifica a una famiglia di colonne con la replica abilitata, tale modifica viene propagata in tutti i cluster di destinazione. Quando i dati vengono replicati da un cluster a un altro, il cluster di origine e tutti i cluster che hanno già utilizzato i dati rilevati, per impedire i cicli di replica.

In questo articolo viene configurata una replica di destinazione di origine. Per altre topologie di cluster, vedere la guida di riferimento di Apache HBase.

Di seguito sono illustrati i casi d'uso della replica HBase per una singola rete virtuale:

• Bilanciamento del carico. È ad esempio possibile eseguire analisi o processi MapReduce nel cluster di destinazione e inserire i dati nel cluster di origine.
• Aggiunta della disponibilità elevata.
• Migrazione dei dati da un cluster HBase a un altro.
• Aggiornamento di un cluster Azure HDInsight da una versione a un'altra.

Di seguito sono illustrati i casi d'uso della replica HBase per due reti virtuali:

• Configurazione del ripristino di emergenza.
• Bilanciamento del carico e partizionamento dell'applicazione.
• Aggiunta della disponibilità elevata.

È possibile replicare i cluster tramite gli script di azione script di GitHub.

Prerequisiti

Prima di iniziare questo articolo, è necessario avere una sottoscrizione di Azure. Vedere Get an Azure free trial (Ottenere una versione di valutazione gratuita di Azure).

Configurare gli ambienti

Sono disponibili tre opzioni di configurazione:

• Due cluster Apache HBase in una rete virtuale di Azure.
• Due cluster Apache HBase in due reti virtuali diverse nella stessa area.
• Due cluster Apache HBase in due reti virtuali diverse in due aree diverse (replica geografica).

Questo articolo illustra lo scenario di replica geografica.

Per semplificare la configurazione degli ambienti, sono disponibili alcuni modelli di Azure Resource Manager. Se si preferisce configurare gli ambienti con altri metodi, vedere:

• Creare cluster Apache Hadoop in HDInsight
• Creare cluster Apache HBase nella rete virtuale di Azure

Configurare due reti virtuali in due aree diverse

Per usare un modello che riesca a creare due reti virtuali in due aree diverse e la connessione VPN tra le reti virtuali, selezionare il pulsante seguente Implementa in Azure.

Alcuni valori hardcoded nel modello:

Rete virtuale 1

VNet 2

In alternativa, seguire questa procedura per configurare due reti virtuali e macchine virtuali diverse manualmente

1. Creare due reti virtuali (Rete virtuale) in un'area diversa
2. Abilitare il peering in entrambe le reti virtuali. Passare a Rete virtuale creata nei passaggi precedenti, quindi fare clic sul peering e aggiungere il collegamento peering di un'altra area. Eseguire questa operazione per entrambe le reti virtuali.
3. Creare la versione più recente di UBUNTU in ogni rete virtuale.

Configurare il DNS

Nella sezione precedente il modello crea una macchina virtuale Ubuntu in ognuna delle due reti virtuali. In questa sezione si installa Bind nelle due macchine virtuali DNS e quindi si configura l'inoltro DNS nelle due macchine virtuali.

Per installare Bind, è necessario trovare l'indirizzo IP pubblico delle due macchine virtuali DNS.

1. Apri il portale di Azure.
2. Aprire la macchina virtuale DNS selezionando Gruppi di risorse > [nome gruppo di risorse] > [vnet1DNS]. Il nome del gruppo di risorse è quello creato nella procedura precedente. I nomi di macchina virtuale DNS predefiniti sono vnet1DNS e vnet2NDS.
3. Selezionare Proprietà per aprire la pagina delle proprietà della rete virtuale.
4. Annotare l'Indirizzo IP pubblico e verificare inoltre l'Indirizzo IP privato. L'indirizzo IP privato deve essere 10.1.0.4 per vnet1DNS e 10.2.0.4 per vnet2DNS.
5. Modificare i server DNS in modo che entrambe le reti virtuali usino i server DNS predefiniti (forniti da Azure) per consentire l'accesso in ingresso e in uscita ai pacchetti di download per poter installare Bind con i passaggi seguenti.

Per installare Bind, usare la procedura seguente:

1. Usare SSH per connettersi all'indirizzo IP pubblico della macchina virtuale DNS. L'esempio seguente consente la connessione a una macchina virtuale all'indirizzo 40.68.254.142:

   ssh sshuser@40.68.254.142
   

   Sostituire sshuser con l'account utente SSH specificato durante la creazione della macchina virtuale DNS.

   Nota

   È possibile ottenere l'utilità ssh in diversi modi. In Linux, Unix e macOS, viene fornito come parte del sistema operativo. Se si usa Windows, prendere in considerazione una delle opzioni seguenti:

   • Azure Cloud Shell
   • Bash in Ubuntu su Windows 10
   • Git (https://git-scm.com/)
   • OpenSSH (https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH)

2. Per installare Bind, usare i comandi seguenti dalla sessione SSH:

    sudo apt-get update -y
    sudo apt-get install bind9 -y
   

3. Configurare Bind per inoltrare le richieste di risoluzione dei nomi al server DNS locale. A questo scopo, usare il testo seguente come contenuto del file /etc/bind/named.conf.options:

   acl goodclients {
       10.1.0.0/16; # Replace with the IP address range of the virtual network 1
       10.2.0.0/16; # Replace with the IP address range of the virtual network 2
       localhost;
       localhost;
   };
   
   options {
       directory "/var/cache/bind";
       recursion yes;
       allow-query { goodclients; };
   
       forwarders {
           168.63.129.16; #This is the Azure DNS server
       };
   
       dnssec-validation auto;
   
       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { any; };
   };
   

   Importante

   Sostituire i valori nella sezione goodclients con l'intervallo di indirizzi IP delle due reti virtuali. Questa sezione definisce gli indirizzi da cui il server DNS accetta le richieste.

   Per modificare questo file, usare il comando seguente:

   sudo nano /etc/bind/named.conf.options
   

   Per salvare il file, usare CTRL+X, Y e quindi INVIO.

4. Dalla sessione SSH usare il comando seguente:

   hostname -f
   

   Il comando restituisce un valore simile al testo seguente:

   vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
   

   Il testo icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net è il suffisso DNS per la rete virtuale. Salvare questo valore, perché verrà usato in un secondo momento.

   È inoltre necessario individuare il suffisso DNS dell'altro server DNS, perché sarà necessario nel passaggio successivo.

5. Per configurare Bind per la risoluzione dei nomi DNS per le risorse nella rete virtuale, usare il testo seguente come contenuto del file /etc/bind/named.conf.local:

   // Replace the following with the DNS suffix for your virtual network
   zone "v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net" {
           type forward;
           forwarders {10.2.0.4;}; # The Azure recursive resolver
   };
   

   Importante

   È necessario sostituire v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net con il suffisso DNS dell'altra rete virtuale. Inoltre, l'indirizzo IP della riga forwarders è l'indirizzo IP privato del server DNS nell'altra rete virtuale.

   Per modificare questo file, usare il comando seguente:

   sudo nano /etc/bind/named.conf.local
   

   Per salvare il file, usare CTRL+X, Y e quindi INVIO.

6. Per avviare Bind, usare il comando seguente:

   sudo service bind9 restart
   

7. Per verificare che Bind riesca a risolvere i nomi delle risorse nell'altra rete virtuale, usare i comandi seguenti:

   sudo apt install dnsutils
   nslookup vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
   

   Importante

   Sostituire vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net con il nome di dominio completo (FQDN) della macchina virtuale DNS nell'altra rete.

   Sostituire 10.2.0.4 con l'indirizzo IP interno del server DNS personalizzato nell'altra rete virtuale.

   La risposta visualizzata sarà simile al testo seguente:

   Server:         10.2.0.4
   Address:        10.2.0.4#53
   
   Non-authoritative answer:
   Name:   vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
   Address: 10.2.0.4
   

   Fino ad ora, non è possibile cercare l'indirizzo IP dall'altra rete senza l'indirizzo IP del server DNS specificato.

Configurare la rete virtuale per usare il server DNS personalizzato

Per configurare la rete virtuale per usare il server DNS personalizzato invece del resolver ricorsivo di Azure, seguire questa procedura:

1. Nel portale di Azure selezionare la rete virtuale e quindi selezionare Server DNS.

2. Selezionare Personalizzato e immettere l'indirizzo IP interno del server DNS personalizzato. Infine, selezionare Salva.

3. Aprire la macchina virtuale del server DNS in vnet1 e fare clic su Riavvia. È necessario riavviare tutte le macchine virtuali nella rete virtuale per rendere effettiva la configurazione DNS.

4. Ripetere i passaggi di configurazione del server DNS personalizzato per vnet2.

Per testare la configurazione DNS, è possibile connettersi alle due macchine virtuali DNS tramite SSH ed eseguire il ping del server DNS dell'altra rete virtuale usando il relativo nome host. Se non funziona, usare il comando seguente per controllare lo stato del servizio DNS:

sudo service bind9 status

Creare i cluster Apache HBase

Creare un cluster Apache HBase in ognuna delle due reti virtuali con la configurazione seguente:

• Nome gruppo di risorse: usare lo stesso nome di gruppo di risorse creato per le reti virtuali.
• Tipo di cluster: HBase
• Versione: HBase 1.1.2 (HDI 3.6)
• Località: usare la stessa località della rete virtuale. Per impostazione predefinita, vnet1 è Stati Uniti occidentali e vnet2 è Stati Uniti orientali.
• Archiviazione: creare un nuovo account di archiviazione per il cluster.
• Rete virtuale (da Impostazioni avanzate sul portale): selezionare la vnet1 creata nella procedura precedente.
• Subnet: il nome predefinito usato nel modello è subnet1.

Per verificare che l'ambiente sia configurato correttamente, provare a effettuare il ping dell'FQDN del nodo head tra i due cluster.

Dati del test di carico

Quando si esegue la replica di un cluster, è necessario specificare le tabelle da replicare. In questa sezione, alcuni dati verranno caricati nel cluster di origine. Nella sezione successiva si abiliterà la replica tra i due cluster.

Per creare una tabella Contatti e inserire alcuni dati nella tabella, seguire le istruzioni in Esercitazione su Apache HBase: Iniziare a usare un esempio di Apache HBase in HDInsight.

Abilitare la replica

La procedura seguente illustra come chiamare lo script di azione script dal portale di Azure. Per informazioni su come eseguire un'azione script tramite Azure PowerShell e l'interfaccia della riga di comando classica di Azure, vedere Personalizzare i cluster HdInsight usando l'azione script.

Per abilitare la replica di HBase dal portale di Azure

1. Accedere al portale di Azure.

2. Aprire il cluster HBase di origine.

3. Dal menu del cluster scegliere Azioni script.

4. Nella parte superiore della pagina selezionare Invia nuova.

5. Selezionare o immettere le seguenti informazioni:

   1. Nome: immettere Abilitazione replica.
   2. URL dello script Bash: Immettere https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh.
   3. Head: assicurarsi che questo parametro sia selezionato. Deselezionare gli altri tipi di nodo.
   4. Parametri: i parametri di esempio seguenti abilitano la replica per tutte le tabelle esistenti e quindi copiano tutti i dati dal cluster di origine al cluster di destinazione:

   -m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -copydata

   Nota

   Usare il nome host invece di FQDN per il nome DNS del cluster di origine e di destinazione.

   Questa procedura dettagliata presuppone hn1 come nodo head attivo. Controllare il cluster per identificare il nodo head attivo.

6. Seleziona Crea. L'esecuzione dello script può richiedere tempo, in particolare se si usa l'argomento -copydata.

Argomenti obbligatori:

Argomenti facoltativi:

La sezione print_usage() dello script contiene una spiegazione dettagliata dei parametri.

Dopo aver distribuito correttamente l'azione script, è possibile usare SSH per connettersi al cluster HBase di destinazione e verificare che i dati siano stati replicati.

Scenari di replica

L'elenco seguente illustra alcuni casi di utilizzo generale e le relative impostazioni dei parametri:

• Abilitare la replica su tutte le tabelle tra i due cluster. Questo scenario non richiede la copia o la migrazione dei dati esistenti nelle tabelle e non usa le tabelle Phoenix. Usare i parametri seguenti:

  -m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password>

• Abilitare la replica su tabelle specifiche. Per abilitare la replica in table1, table2 e table3, usare i parametri seguenti:

  -m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3"

• Abilitare la replica in tabelle specifiche e copiare i dati esistenti. Per abilitare la replica in table1, table2 e table3, usare i parametri seguenti:

  -m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3" -copydata

• Abilitare la replica in tutte le tabelle e replicare i metadati di Phoenix dall'origine alla destinazione. La replica dei metadati phoenix non è perfetta. Usarla con cautela. Usare i parametri seguenti:

  -m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -t "table1;table2;table3" -replicate-phoenix-meta

Configurare la replica tra cluster ESP

Prerequisiti

1. Entrambi i cluster ESP devono trovarsi nella stessa area di autenticazione (dominio). Controllare la /etc/krb5.conf proprietà dell'area di autenticazione predefinita del file per confermare.
2. L'utente comune deve essere presente chi ha accesso in lettura e scrittura a entrambi i cluster
   1. Ad esempio, se entrambi i cluster hanno lo stesso utente amministratore del cluster ,ad esempio admin@abc.example.com, tale utente può essere usato per eseguire lo script di replica.
   2. Se entrambi i cluster usano lo stesso gruppo di utenti, è possibile aggiungere un nuovo utente o usare un utente esistente dal gruppo.
   3. Se entrambi i cluster usano un gruppo di utenti diverso, è possibile aggiungere un nuovo utente per entrambi gli utenti esistenti dai gruppi.

Passaggi per l'esecuzione dello script di replica

Passaggio 1: Creare il file keytab per l'utente usando ktutil. $ ktutil

1. addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
2. Richiedere la password per l'autenticazione, specificare la password utente
3. wkt /etc/security/keytabs/admin.keytab

Passaggio 2: Eseguire un'azione script con -ku l'opzione

1. Fornire -ku <username> nei cluster ESP.

Copia e migrazione dei dati

Sono disponibili due script di azione script distinti per la copia o la migrazione dei dati dopo aver abilitato la replica:

• Script per tabelle di piccole dimensioni (tabelle con dimensioni di pochi gigabyte per cui si prevede che la copia completa richieda meno di un'ora)

• Script per tabelle di grandi dimensioni (tabelle per cui si prevede che la copia richieda più di un'ora)

È possibile eseguire la stessa procedura descritta in Abilitare la replica per chiamare l'azione script. Usare i parametri seguenti:

-m hn1 -t <table1:start_timestamp:end_timestamp;table2:start_timestamp:end_timestamp;...> -p <replication_peer> [-everythingTillNow]

La sezione print_usage() dello script contiene una descrizione dettagliata dei parametri.

Scenari

• Copiare tabelle specifiche (test1, test2 e test3) per tutte le righe modificate finora (timestamp corrente):

  -m hn1 -t "test1::;test2::;test3::" -p "<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow

  Oppure:

  -m hn1 -t "test1::;test2::;test3::" --replication-peer="<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow

• Copiare tabelle specifiche con un intervallo di tempo specificato:

  -m hn1 -t "table1:0:452256397;table2:14141444:452256397" -p "<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure"

Disabilitare la replica

Per disabilitare la replica, usare un altro script di azione script disponibile in GitHub. È possibile eseguire la stessa procedura descritta in Abilitare la replica per chiamare l'azione script. Usare i parametri seguenti:

-m hn1 -s <source hbase cluster name> -sp <source cluster Ambari password> <-all|-t "table1;table2;...">

La sezione print_usage() dello script contiene una spiegazione dettagliata dei parametri.

Scenari

• Disabilitare la replica in tutte le tabelle:

  -m hn1 -s <source hbase cluster name> -sp Mypassword\!789 -all

  oppure

  --src-cluster=<source hbase cluster name> --dst-cluster=<destination hbase cluster name> --src-ambari-user=<source cluster Ambari user name> --src-ambari-password=<source cluster Ambari password>

• Disabilitare la replica in tabelle specifiche (table1, table2 e table3):

  -m hn1 -s <source hbase cluster name> -sp <source cluster Ambari password> -t "table1;table2;table3"

Passaggi successivi

In questo articolo si è appreso come configurare la replica Apache HBase all'interno di una rete virtuale o tra due reti virtuali. Per altre informazioni su HDInsight e Apache HBase, vedere questi articoli:

• Introduzione ad Apache HBase in HDInsight
• Panoramica di Apache HBase di HDInsight
• Creare cluster Apache HBase nella rete virtuale di Azure