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

Artigo
04/29/2024

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

A replicação de cluster usa uma metodologia de envio de origem. Um cluster HBase pode ser uma fonte, um destino ou pode atender a ambas as funções de uma vez. A replicação é assíncrona. A meta da replicação é a consistência eventual. Quando a origem recebe uma edição para uma família de coluna com replicação habilitada, essa 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, uma replicação de origem/destino será configurada. Para obter outras topologias de cluster, consulte o Guia de referência do Apache HBase.

Casos de uso de replicação de HBase para uma única rede virtual:

Balanceamento de carga. Por exemplo, é possível executar verificações ou trabalhos MapReduce no cluster de destino e ingerir de dados no cluster de origem.
Adicionar alta disponibilidade.
Migrar dados de um cluster de HBase para outro.
Atualizar um cluster HDInsight do Azure de uma versão para outra.

Casos de uso de replicação de HBase para duas redes virtuais:

Configurar uma recuperação de desastre.
Balanceamento de carga e particionamento do aplicativo.
Adicionar alta disponibilidade.

É possível replicar clusters usando os scripts 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

Há três opções de configuração:

Dois clusters do Apache HBase em uma rede virtual do Azure.
Dois clusters do Apache HBase em duas redes virtuais diferentes na mesma região.
Dois clusters do 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 facilitar a configuração dos ambientes, alguns modelos do Azure Resource Manager foram criados. Se você preferir configurar os ambientes usando outros métodos, consulte:

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 VNETs, selecione o botão Implantar no Azure a seguir.

Alguns dos valores embutidos em código no modelo:

VNet 1

Propriedade	Valor
Location	Oeste dos EUA
Nome da VNet	<ClusterNamePrevix>-vnet1
Prefixo de espaço de endereço	10.1.0.0/16
Nome da sub-rede	Sub-rede 1
Prefixo de 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 de gateway	Basic
IP do gateway	vnet1gwip

VNet 2

Propriedade	Valor
Localização	Leste dos EUA
Nome da VNet	<ClusterNamePrevix>-vnet2
Prefixo de espaço de endereço	10.2.0.0/16
Nome da sub-rede	Sub-rede 1
Prefixo de 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 de gateway	Basic
IP do gateway	vnet1gwip

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

Criar duas VNets (Redes Virtuais) em regiões diferentes
Habilite o emparelhamento em ambas as VNets. Acesse a rede virtual criada nas etapas acima, clique em Emparelhamento e adicione o link de emparelhamento de outra região. Faça isso para ambas as redes virtuais.
Crie a versão mais recente do UBUNTU em cada VNet.

Instalação do DNS

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

Para instalar ao Bind, você precisa localizar o endereço IP público das duas máquinas virtuais DNS.

Abra o Portal do Azure.
Abra a máquina virtual DNS selecionando Grupos de recursos > [nome do grupo de recursos] > [vnet1DNS]. O nome do grupo de recursos é o que você criar no último procedimento. Os nomes de máquina virtual DNS padrão são vnet1DNS e vnet2NDS.
Selecione Propriedades para abrir a página de propriedades da rede virtual.
Anote o endereço IP públicoe também verifique a endereço IP privado. O endereço IP privado será 10.1.0.4 para vnet1DNS e 10.2.0.4 para vnet2DNS.
Altere os servidores DNS das duas redes virtuais para usar servidores DNS padrão (fornecidos pelo Azure) para permitir o acesso de entrada e de saída para baixar pacotes para instalar o Bind nas etapas a seguir.

Para instalar o Bind, use o seguinte procedimento:

Use SSH para conexão com o 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 que você especificou ao criar o cluster na sua máquina virtual DNS.
Observação

Há uma variedade de maneiras para obter o utilitário ssh. No Linux, Unix e macOS, ele é fornecido como parte do sistema operacional. Se você estiver usando o Windows, considere uma das seguintes opções:
Para instalar o Bind, use os seguintes comandos da sessão SSH:
```
 sudo apt-get update -y
 sudo apt-get install bind9 -y
```

Configure o Bind para encaminhar solicitações de resolução de nome para seu servidor DNS local. Para fazer isso, use o seguinte texto como o conteúdo do arquivo /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

Substitua os valores na seção goodclients com o 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 salvar o arquivo, use Ctrl+X, Y e, em seguida, Enter.

Na sessão do SSH, use o comando a seguir:
```
hostname -f
```
Esse comando retorna um valor semelhante ao texto a seguir:
```
vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
```
O texto icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net é o sufixo DNS para essa rede virtual. Salve esse valor, pois ele será usado mais tarde.

Você também deve descobrir o sufixo DNS do outro servidor DNS. Você precisará disso na próxima etapa.
Para configurar o Bind para resolver nomes DNS para os recursos na rede virtual, use o seguinte texto como o conteúdo do arquivo /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

Substitua o v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net pelo sufixo DNS da outra rede virtual. E o IP de encaminhador é o endereço IP do servidor DNS na outra rede virtual.

Para editar esse arquivo, use o seguinte comando:
```
sudo nano /etc/bind/named.conf.local
```
Para salvar o arquivo, use Ctrl+X, Y e, em seguida, Enter.
Para iniciar o Bind, use o seguinte comando:
```
sudo service bind9 restart
```
Para verificar se o Bind pode resolver os nomes de recursos em sua rede virtual, use os seguintes comandos:
```
sudo apt install dnsutils
nslookup vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
```
Importante

Substituir 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 rede virtual.

A resposta aparece 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 verificar o endereço IP da rede sem o endereço IP do servidor DNS especificado.

Configurar a rede virtual para usar o servidor DNS personalizado

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

No portal do Azure, selecione a rede virtual e, em seguida, selecione Servidores DNS.
Selecione Personalizadoe insira o endereço IP interno do servidor DNS personalizado. Por fim, selecione Salvar.
Abra a máquina virtual do servidor DNS em vnet1 e, em seguida, clique em Reiniciar. Você deve reiniciar todas as máquinas virtuais na rede virtual para fazer com que configuração de DNS entre em vigor.
Repita a configuração de etapas do servidor DNS personalizado para vnet2.

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

sudo service bind9 status

Criar clusters do Apache HBase

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

Nome do grupo de recursos: use o mesmo nome de 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 que a rede virtual. Por padrão, vnet1 é Oeste dos EUA, e a vnet2 é Leste dos EUA.
Armazenamento: crie uma nova conta de armazenamento para o cluster.
Rede virtual (em 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 está configurado corretamente, você deve ser capaz de executar ping do FQDN do nó principal entre os dois clusters.

Carregar dados de teste

Ao replicar um cluster, é necessário especificar as tabelas a serem replicadas. 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 Contatos e inserir alguns dados na tabela, siga as instruções no tutorial Apache HBase: Comece a usar o Apache HBase no HDInsight.

Observação

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

Habilitar a replicação

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

Para habilitar a replicação de HBase no Portal do Azure

Entre no portal do Azure.
Abra o cluster HBase de origem.
No menu do cluster, selecione Ações de Script.
Na parte superior da página, selecione Enviar Novo.
Selecione ou insira as seguintes informações:
1. Nome: insira Habilitar a replicação.
2. URL do script de bash: Enter https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh.
3. Cabeçalho: verifique se esse parâmetro está selecionado. Desmarque os outros tipos de nós.
4. Parâmetros: os seguintes parâmetros de exemplo habilitam a replicação de todas as tabelas existentes e 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

Observação

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

Este passo a passo pressupõe o hn1 como cabeçalho ativo. Verifique seu cluster para identificar o nó de cabeçalho ativo.
Selecione Criar. O script pode demorar, especialmente quando o argumento -copydata for usado.

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-password	Especifica a senha de administrador para Ambari no cluster HBase de origem.
-dp, --dst-ambari-password	Especifica a senha de administrador para Ambari no cluster HBase de destino.

Argumentos opcionais:

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

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

Após a ação de script ser implantada com êxito, é possíve 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 geral e suas configurações de parâmetro:

Habilitar a replicação em todas as tabelas entre os dois clusters. Esse cenário não requer a cópia ou migração dos 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>
Habilitar a replicação em tabelas específicas. Use os parâmetros a seguir para habilitar a replicação em table1, table2 e table3:

-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"
Habilitar a replicação em tabelas específicas e copiar os dados existentes. Use os parâmetros a seguir para habilitar a replicação em table1, table2 e table3:

-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
Habilitar a replicação em todas as tabelas e replicar metadados Phoenix da origem para o destino. A replicação de metadados Phoenix não é perfeita. Use-a com atenção. 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

Ambos os clusters ESP devem estar no mesmo realm (domínio). Verifique a propriedade padrão do realm do arquivo /etc/krb5.conf para confirmar.
Deve haver um usuário comum que tenha acesso de leitura e gravação em 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 que já existe no grupo.
3. Se ambos os clusters usarem um grupo de usuários diferente, você poderá adicionar um novo usuário para usar o usuário já existente dos grupos.

Etapas para o script Executar Replicação

Observação

Execute as etapas a seguir somente se o DNS não puder resolver corretamente o nome do host do cluster de destino.

Copie o mapeamento de IP e nome de host dos hosts do cluster no arquivo /etc/hosts dos nós do cluster de origem.
Copie o nó de cabeçalho, o nó de trabalho e o host de nós do ZooKeeper e o mapeamento de IP do arquivo /etc/hosts do cluster de destino (sink).
Adicione o arquivo /etc/hosts do cluster de origem das entradas copiadas. Essas entradas devem ser adicionadas a nós de cabeçalho, nós de trabalho e nós do ZooKeeper.

Etapa 1: criar um arquivo keytab para o usuário usando ktutil. $ ktutil

addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
Solicite a senha para autenticação, forneça a senha do usuário
wkt /etc/security/keytabs/admin.keytab

Observação

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

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

Forneça -ku <username> em clusters ESP.

Name	Descrição
`-ku, --krb-user`	Para clusters ESP, usuário Kerberos comum, que pode autenticar os 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 replicação ser habilitada:

Script para tabelas pequenas (tabelas com apenas alguns gigabytes de tamanho, a cópia leva menos de uma hora para terminar)
Script para tabelas grandes (tabelas que devem levar mais de uma hora para copiar)

É possível 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 seção print_usage() do script fornece uma descrição detalhada dos parâmetros.

Cenários

Copiar tabelas específicas (test1, test2 e test3) para todas as linhas editadas até o momento (carimbo de 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
Copiar tabelas específicas com intervalo de tempo especificado:

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

Desabilitar a replicação

Para desabilitar a replicação, use outro script de ação de script do GitHub. É possível 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 seção print_usage() do script fornece uma explicação detalhada dos parâmetros.

Cenários

Desabilitar 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>
Desabilitar a replicação em tabelas específicas (table1, table2 e table3):

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

Observação

Se você pretender 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. Com falha, o cluster de origem pode não funcionar corretamente.

Próximas etapas

Neste artigo, você aprendeu a 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:

Compartilhar via

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

Pré-requisitos

Configurar os ambientes

Configurar duas redes virtuais em duas regiões diferentes

Instalação do DNS

Configurar a rede virtual para usar o servidor DNS personalizado

Criar clusters do Apache HBase

Carregar dados de teste

Habilitar a replicação

Cenários de replicação

Configurar a replicação entre clusters ESP

Copiar e migrar dados

Cenários

Desabilitar a replicação

Cenários

Próximas etapas

Comentários

Recursos adicionais