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.
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:
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
Location
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
Location
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
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.
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.
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.
Selecione Propriedades para abrir a página de propriedades da rede virtual.
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.
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:
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:
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.
Na sessão SSH, use o seguinte comando:
hostname -f
Este comando retorna um valor semelhante ao seguinte texto:
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.
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 v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net com o 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.
Para iniciar Bind, use o seguinte comando:
sudo service bind9 restart
Para verificar se a associação pode resolver os nomes dos recursos na outra rede virtual, use os seguintes comandos:
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.
Selecione Personalizado e insira o endereço IP interno do servidor DNS personalizado. Por último, selecione Guardar.
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.
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.
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
Cabeçalho: Certifique-se de que este parâmetro está selecionado. Limpe os outros tipos de nó.
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:
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.
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:
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:
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:
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.
O usuário comum deve estar lá que tenha acesso de leitura e gravação a ambos os clusters
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.
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.
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.
Copie o cluster do coletor hospeda o mapeamento IP & hostname nos nós do cluster de origem /etc/hosts file.
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).
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
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:
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:
O Azure HPC é um recurso de nuvem criado especificamente para a carga de trabalho HPC & AI, usando processadores de ponta e interconexão InfiniBand de classe HPC, para oferecer o melhor desempenho, escalabilidade e valor de aplicativos. O Azure HPC permite que os utilizadores desbloqueiem a inovação, a produtividade e a agilidade empresarial, através de uma gama altamente disponível de tecnologias de HPC ou IA que podem ser alocadas dinamicamente à medida que as suas necessidades empresariais e técnicas mud