Configurar a replicação do cluster do Apache HBase em redes virtuais do Azure

Saiba como configurar a replicação do Apache HBase em uma rede virtual ou entre duas redes virtuais no Azure.

A replicação em cluster usa uma metodologia de envio de origem. Um cluster HBase pode ser uma origem ou um destino, ou pode cumprir ambas as funções ao mesmo tempo. A replicação é assíncrona. O objetivo da replicação é a consistência final. Quando a origem recebe uma edição para uma família de colunas quando a replicação está habilitada, a edição é propagada para todos os clusters de destino. Quando os dados são replicados de um cluster para outro, o cluster de origem e todos os clusters que já consumiram os dados são rastreados, para evitar loops de replicação.

Neste artigo, você configura uma replicação de origem-destino. Para outras topologias de cluster, consulte o guia de referência do Apache HBase.

A seguir estão os casos de uso de replicação do HBase para uma única rede virtual:

• Balanceamento de carga. Por exemplo, você pode executar verificações ou trabalhos do MapReduce no cluster de destino e ingerir dados no cluster de origem.
• Adicionando alta disponibilidade.
• Migração de dados de um cluster HBase para outro.
• Atualizar um cluster do Azure HDInsight de uma versão para outra.

A seguir estão os casos de uso de replicação do HBase para duas redes virtuais:

• Configuração da recuperação de desastres.
• Balanceamento de carga e particionamento do aplicativo.
• Adicionando alta disponibilidade.

Você pode replicar clusters usando scripts de ação de script do GitHub.

Pré-requisitos

Antes de começar este artigo, você deve ter uma assinatura do Azure. Consulte Obter uma avaliação gratuita do Azure.

Configurar os ambientes

Você tem três opções de configuração:

• Dois clusters Apache HBase em uma rede virtual do Azure.
• Dois clusters Apache HBase em duas redes virtuais diferentes na mesma região.
• Dois clusters Apache HBase em duas redes virtuais diferentes em duas regiões diferentes (replicação geográfica).

Este artigo aborda o cenário de replicação geográfica.

Para ajudá-lo a configurar os ambientes, criamos alguns modelos do Azure Resource Manager. Se preferir configurar os ambientes usando outros métodos, consulte:

• Criar clusters Apache Hadoop no HDInsight
• Criar clusters Apache HBase na Rede Virtual do Azure

Configurar duas redes virtuais em duas regiões diferentes

Para usar um modelo que cria duas redes virtuais em duas regiões diferentes e a conexão VPN entre as redes virtuais, selecione o seguinte botão Implantar no Azure .

Alguns dos valores codificados no modelo:

VNet 1

Property	valor
Localização	E.U.A. Oeste
Nome da VNet	<ClusterNamePrevix-vnet1>
Prefixo do espaço de endereço	10.1.0.0/16
Nome da sub-rede	sub-rede 1
Prefixo da sub-rede	10.1.0.0/24
Nome da sub-rede (gateway)	GatewaySubnet (não pode ser alterado)
Prefixo da sub-rede (gateway)	10.1.255.0/27
Nome do gateway	vnet1gw
Tipo de gateway	Vpn
Tipo de VPN de gateway	RouteBased
SKU do Gateway	Básica
Gateway IP	vnet1gwip

VNet 2

Property	valor
Localização	E.U.A. Leste
Nome da VNet	<ClusterNamePrevix-vnet2>
Prefixo do espaço de endereço	10.2.0.0/16
Nome da sub-rede	sub-rede 1
Prefixo da sub-rede	10.2.0.0/24
Nome da sub-rede (gateway)	GatewaySubnet (não pode ser alterado)
Prefixo da sub-rede (gateway)	10.2.255.0/27
Nome do gateway	vnet2gw
Tipo de gateway	Vpn
Tipo de VPN de gateway	RouteBased
SKU do Gateway	Básica
Gateway IP	vnet1gwip

Como alternativa, siga as etapas abaixo para configurar duas vnets e VMs diferentes manualmente

1. Criar duas VNET (rede virtual) em regiões diferentes
2. Habilite o emparelhamento na VNET. Vá para Rede virtual criada nas etapas acima, clique em emparelhamento e adicione link de emparelhamento de outra região. Faça isso tanto para a rede virtual.
3. Crie a versão mais recente do Ubuntu em cada VNET.

Configurar DNS

Na última seção, o modelo cria uma máquina virtual Ubuntu em cada uma das duas redes virtuais. Nesta seção, você instala o Bind nas duas máquinas virtuais DNS e configura o encaminhamento DNS nas duas máquinas virtuais.

Para instalar Bind, yon precisa encontrar o endereço IP público das duas máquinas virtuais DNS.

1. Abra o portal do Azure.
2. Abra a máquina virtual DNS selecionando Grupos de recursos [nome do grupo de recursos] [vnet1DNS]>.> O nome do grupo de recursos é aquele criado no último procedimento. Os nomes de máquina virtual DNS padrão são vnet1DNS e vnet2NDS.
3. Selecione Propriedades para abrir a página de propriedades da rede virtual.
4. Anote o endereço IP público e verifique também o endereço IP privado. O endereço IP privado deve ser 10.1.0.4 para vnet1DNS e 10.2.0.4 para vnet2DNS.
5. Altere os Servidores DNS de ambas as redes virtuais para usar servidores DNS Padrão (Fornecidos pelo Azure) para permitir acesso de entrada e saída para baixar pacotes para instalar o Bind nas etapas a seguir.

Para instalar o Bind, use o seguinte procedimento:

1. Use SSH para se conectar ao endereço IP público da máquina virtual DNS. O exemplo a seguir se conecta a uma máquina virtual em 40.68.254.142:

   ssh sshuser@40.68.254.142
   

   Substitua sshuser pela conta de usuário SSH especificada ao criar a máquina virtual DNS.

   Nota

   Há uma variedade de maneiras de obter o ssh utilitário. No Linux, Unix e macOS, é fornecido como parte do sistema operacional. Se estiver a utilizar o Windows, considere uma das seguintes opções:

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

2. Para instalar o Bind, use os seguintes comandos da sessão SSH:

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

3. Configure Bind para encaminhar solicitações de resolução de nomes para seu servidor DNS local. Para fazer isso, use o seguinte texto como o conteúdo do /etc/bind/named.conf.options arquivo:

   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

   Substitua goodclients os valores na seção pelo intervalo de endereços IP das duas redes virtuais. Esta seção define os endereços dos quais esse servidor DNS aceita solicitações.

   Para editar esse arquivo, use o seguinte comando:

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

   Para guardar o ficheiro, utilize Ctrl+X, Y e, em seguida , Enter.

4. Na sessão SSH, use o seguinte comando:

   hostname -f
   

   Este comando retorna um valor semelhante ao seguinte texto:

   vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
   

   O icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net texto é o sufixoDNS para esta rede virtual. Guarde este valor, tal como é utilizado mais tarde.

   Você também deve descobrir o sufixo DNS do outro servidor DNS. Você precisa dele na próxima etapa.

5. Para configurar Bind para resolver nomes DNS para recursos dentro da rede virtual, use o seguinte texto como o conteúdo do /etc/bind/named.conf.local arquivo:

   // 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

   Você deve substituir o com o v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net sufixo DNS da outra rede virtual. E o IP do encaminhador é o endereço IP privado do servidor DNS na outra rede virtual.

   Para editar esse arquivo, use o seguinte comando:

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

   Para guardar o ficheiro, utilize Ctrl+X, Y e, em seguida , Enter.

6. Para iniciar Bind, use o seguinte comando:

   sudo service bind9 restart
   

7. Para verificar se a associação pode resolver os nomes dos recursos na outra rede virtual, use os seguintes comandos:

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

   Importante

   Substitua vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net pelo nome de domínio totalmente qualificado (FQDN) da máquina virtual DNS na outra rede.

   Substitua 10.2.0.4 pelo endereço IP interno do seu servidor DNS personalizado na outra rede virtual.

   A resposta é semelhante ao seguinte texto:

   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
   

   Até agora, você não pode procurar o endereço IP da outra rede sem o endereço IP do servidor DNS especificado.

Configurar a rede virtual para usar o servidor DNS personalizado

Para configurar a rede virtual para usar o servidor DNS personalizado em vez do resolvedor recursivo do Azure, use as seguintes etapas:

1. No portal do Azure, selecione a rede virtual e, em seguida, selecione Servidores DNS.

2. Selecione Personalizado e insira o endereço IP interno do servidor DNS personalizado. Por último, selecione Guardar.

3. Abra a máquina virtual do servidor DNS em vnet1 e clique em Reiniciar. Você deve reiniciar todas as máquinas virtuais na rede virtual para que a configuração DNS entre em vigor.

4. Repita as etapas para configurar o servidor DNS personalizado para vnet2.

Para testar a configuração de DNS, você pode se conectar às duas máquinas virtuais DNS usando SSH e executar ping no servidor DNS da outra rede virtual usando seu nome de host. Se não funcionar, use o seguinte comando para verificar o status do DNS:

sudo service bind9 status

Criar clusters Apache HBase

Crie um cluster Apache HBase em cada uma das duas redes virtuais com a seguinte configuração:

• Nome do grupo de recursos: use o mesmo nome do grupo de recursos que você criou as redes virtuais.
• Tipo de cluster: HBase
• Versão: HBase 1.1.2 (HDI 3.6)
• Local: use o mesmo local da rede virtual. Por padrão, vnet1 é West US e vnet2 é East US.
• Armazenamento: crie uma nova conta de armazenamento para o cluster.
• Rede virtual (a partir de Configurações avançadas no portal): Selecione vnet1 que você criou no último procedimento.
• Sub-rede: O nome padrão usado no modelo é subnet1.

Para garantir que o ambiente esteja configurado corretamente, você deve ser capaz de executar ping no FQDN do nó principal entre os dois clusters.

Carregar os dados de teste

Ao replicar um cluster, você deve especificar as tabelas que deseja replicar. Nesta seção, você carrega alguns dados no cluster de origem. Na próxima seção, você habilitará a replicação entre os dois clusters.

Para criar uma tabela de Contatos e inserir alguns dados na tabela, siga as instruções no tutorial do Apache HBase: Introdução ao uso do Apache HBase no HDInsight.

Nota

Se quiser replicar tabelas de um namespace personalizado, você precisa garantir que os namespaces personalizados apropriados também sejam definidos no cluster de destino.

Ativar a replicação

As etapas a seguir descrevem como chamar o script de ação de script do portal do Azure. Para obter informações sobre como executar uma ação de script usando o Azure PowerShell e a CLI Clássica do Azure, consulte Personalizar clusters HDInsight usando ação de script.

Para habilitar a replicação do HBase a partir do portal do Azure

1. Inicie sessão no portal do Azure.

2. Abra o cluster HBase de origem.

3. No menu do cluster, selecione Ações de script.

4. Na parte superior da página, selecione Enviar novo.

5. Selecione ou insira as seguintes informações:

   1. Nome: insira Habilitar replicação.
   2. URL do script Bash: digite https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh.
   3. Cabeçalho: Certifique-se de que este parâmetro está selecionado. Limpe os outros tipos de nó.
   4. Parâmetros: Os seguintes parâmetros de exemplo habilitam a replicação para todas as tabelas existentes e, em seguida, copiam todos os dados do cluster de origem para o cluster de destino:

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

   Nota

   Use hostname em vez de FQDN para o nome DNS do cluster de origem e de destino.

   Este passo a passo assume hn1 como headnode ativo. Verifique o cluster para identificar o nó principal ativo.

6. Selecione Criar. O script pode demorar um pouco para ser executado, especialmente quando você usa o argumento -copydata .

Argumentos necessários:

Nome	Descrição
-s, --src-cluster	Especifica o nome DNS do cluster HBase de origem. Por exemplo: -s hbsrccluster, --src-cluster=hbsrccluster
-d, --dst-cluster	Especifica o nome DNS do cluster HBase de destino (réplica). Por exemplo: -s dsthbcluster, --src-cluster=dsthbcluster
-sp, --src-ambari-senha	Especifica a senha de administrador do Ambari no cluster HBase de origem.
-dp, --dst-ambari-senha	Especifica a senha de administrador do Ambari no cluster HBase de destino.

Argumentos opcionais:

Nome	Descrição
-su, --src-ambari-usuário	Especifica o nome de usuário admin para Ambari no cluster HBase de origem. O valor padrão é admin.
-du, --dst-ambari-usuário	Especifica o nome de usuário admin do Ambari no cluster HBase de destino. O valor padrão é admin.
-t, --tabela-lista	Especifica as tabelas a serem replicadas. Por exemplo: --table-list="table1; Tabela 2; Tabela 3". Se você não especificar tabelas, todas as tabelas existentes do HBase serão replicadas.
-m, --máquina	Especifica o nó principal onde a ação de script é executada. O valor deve ser escolhido com base em qual é o nó principal ativo. Use esta opção quando estiver executando o script $0 como uma ação de script do portal HDInsight ou do Azure PowerShell.
-cp, -copydata	Permite a migração de dados existentes nas tabelas onde a replicação está habilitada.
-rpm, -replicate-phoenix-meta	Permite a replicação em tabelas do sistema Phoenix. Use esta opção com cuidado. Recomendamos que você recrie tabelas Phoenix em clusters de réplica antes de usar esse script.
-h, --ajuda	Exibe informações de uso.

A print_usage() seção do script tem uma explicação detalhada dos parâmetros.

Depois que a ação de script for implantada com êxito, você poderá usar o SSH para se conectar ao cluster HBase de destino e verificar se os dados foram replicados.

Cenários de replicação

A lista a seguir mostra alguns casos de uso gerais e suas configurações de parâmetro:

• Habilite a replicação em todas as tabelas entre os dois clusters. Esse cenário não requer cópia ou migração de dados existentes nas tabelas e não usa tabelas Phoenix. Use os seguintes parâmetros:

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

• Habilite a replicação em tabelas específicas. Para habilitar a replicação na tabela1, tabela2 e tabela3, use os seguintes parâmetros:

  -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"

• Habilite a replicação em tabelas específicas e copie os dados existentes. Para habilitar a replicação na tabela1, tabela2 e tabela3, use os seguintes parâmetros:

  -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

• Habilite a replicação em todas as tabelas e replique metadados Phoenix da origem ao destino. A replicação de metadados Phoenix não é perfeita. Use-o com cuidado. Use os seguintes parâmetros:

  -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

Configurar a replicação entre clusters ESP

Pré-requisitos

1. Ambos os clusters ESP devem estar lá no mesmo domínio (domínio). Verifique /etc/krb5.conf a propriedade realm padrão do arquivo para confirmar.
2. O usuário comum deve estar lá que tenha acesso de leitura e gravação a ambos os clusters
   1. Por exemplo, se ambos os clusters tiverem o mesmo usuário administrador de cluster (por exemplo, admin@abc.example.com), esse usuário poderá ser usado para executar o script de replicação.
   2. Se ambos os clusters usarem o mesmo grupo de usuários, você poderá adicionar um novo usuário ou usar o usuário existente do grupo.
   3. Se ambos os clusters usando grupos de usuários diferentes, você poderá adicionar um novo usuário para ambos usarem o usuário existente dos grupos.

Etapas para executar o script de replicação

Nota

Execute as seguintes etapas somente se o DNS não conseguir resolver corretamente o nome do host do cluster de destino.

1. Copie o cluster do coletor hospeda o mapeamento IP & hostname nos nós do cluster de origem /etc/hosts file.
2. Copie o nó principal, o nó de trabalho e o mapeamento de host e IP dos nós do ZooKeeper do arquivo /etc/hosts do cluster de destino (coletor).
3. Adicione entradas copiadas arquivo de origem cluster /etc/hosts. Essas entradas devem ser adicionadas aos nós principais, nós de trabalho e nós do ZooKeeper.

Etapa 1: Criar arquivo keytab para o usuário usando ktutilo . $ ktutil

1. addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
2. Pedir palavra-passe para autenticar, fornecer palavra-passe de utilizador
3. wkt /etc/security/keytabs/admin.keytab

Nota

Verifique se o arquivo keytab está armazenado na /etc/security.keytabs/ pasta no <username>.keytab formato.

Etapa 2: Executar ação de script com -ku a opção

1. Fornecer -ku <username> em clusters ESP.

Nome	Descrição
-ku, --krb-user	Para clusters ESP, usuário Kerberos comum, que pode autenticar clusters de origem e de destino

Copiar e migrar dados

Há dois scripts de ação de script separados disponíveis para copiar ou migrar dados após a habilitação da replicação:

• Script para tabelas pequenas (tabelas com alguns gigabytes de tamanho e a cópia geral deve ser concluída em menos de uma hora)

• Script para tabelas grandes (tabelas que devem levar mais de uma hora para serem copiadas)

Você pode seguir o mesmo procedimento descrito em Habilitar replicação para chamar a ação de script. Use os seguintes parâmetros:

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

A print_usage() seção do script tem uma descrição detalhada dos parâmetros.

Cenários

• Copie tabelas específicas (test1, test2 e test3) para todas as linhas editadas até agora (carimbo de data/hora atual):

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

  Ou:

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

• Copie tabelas específicas com um intervalo de tempo especificado:

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

Desativar a replicação

Para desabilitar a replicação, use outro script de ação de script do GitHub. Você pode seguir o mesmo procedimento descrito em Habilitar replicação para chamar a ação de script. Use os seguintes parâmetros:

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

A print_usage() seção do script tem uma explicação detalhada dos parâmetros.

Cenários

• Desative a replicação em todas as tabelas:

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

  ou

  --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>

• Desative a replicação em tabelas especificadas (tabela1, tabela2 e tabela3):

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

Nota

Se você pretende excluir o cluster de destino, certifique-se de removê-lo da lista de pares do cluster de origem. Isso pode ser feito executando o comando remove_peer '1' no shell hbase no cluster de origem. Caso contrário, o cluster de origem pode não funcionar corretamente.

Próximos passos

Neste artigo, você aprendeu como configurar a replicação do Apache HBase em uma rede virtual ou entre duas redes virtuais. Para saber mais sobre o HDInsight e o Apache HBase, consulte estes artigos:

• Introdução ao Apache HBase no HDInsight
• Visão geral do HDInsight Apache HBase
• Criar clusters Apache HBase na Rede Virtual do Azure