Configuración de la replicación de clústeres de Apache HBase en redes virtuales de Azure

Aprenda a configurar la replicación de Apache HBase en una red virtual o entre dos redes virtuales en Azure.

La replicación de clúster usa una metodología de inserción de origen. Un clúster de HBase puede ser un origen, un destino o cumplir ambos roles a la vez. La replicación es asincrónica. El objetivo de la replicación es la coherencia final. Cuando el origen recibe una modificación en una familia de columnas cuando la replicación está habilitada, la modificación se propaga a todos los clústeres de destino. Cuando se replican datos de un clúster a otro, se realiza un seguimiento del clúster de origen y de todos los clústeres que ya hayan consumido los datos para evitar bucles de replicación.

En este artículo, va a configurar una replicación de origen y destino. Para otras topologías de clúster, consulte la Guía de referencia de HBase Apache.

Los siguientes son casos de uso de replicación de HBase para una única red virtual:

• Equilibrio de carga. Por ejemplo, puede ejecutar exámenes o trabajos MapReduce en el clúster de destino e ingerir datos en el clúster de origen.
• Agregar alta disponibilidad.
• Migrar datos de un clúster de HBase a otro.
• Actualizar un clúster de Azure HDInsight de una versión a otra.

Los siguientes son casos de uso de replicación de HBase para dos redes virtuales:

• Configuración de la recuperación ante desastres.
• Equilibrio de carga y creación de particiones de la aplicación.
• Agregar alta disponibilidad.

Puede replicar clústeres mediante scripts de acción de script disponibles en GitHub.

Requisitos previos

Para comenzar a trabajar con este artículo, es preciso tener una suscripción a Azure. Consulte cómo obtener una evaluación gratuita de Azure.

Configuración de los entornos

Existen tres opciones de configuración:

• Dos clústeres de Apache HBase en una única red virtual de Azure.
• Dos clústeres de Apache HBase en dos redes virtuales diferentes de la misma región.
• Dos clústeres de Apache HBase en dos redes virtuales diferentes de dos regiones diferentes (replicación geográfica).

Este artículo trata sobre el escenario de replicación geográfica.

Para ayudar a configurar los entornos, hemos creado algunas plantillas de Azure Resource Manager. Si prefiere configurar los entornos mediante otros métodos, consulte:

• Creación de clústeres de Apache Hadoop en HDInsight
• Creación de clústeres de Apache HBase en Azure Virtual Network

Configuración de dos redes virtuales en dos regiones distintas

Para usar una plantilla que crea dos redes virtuales en dos regiones distintas y la conexión VPN entre ellas, seleccione el botón Implementar en Azure siguiente.

Algunos de los valores de la plantilla están codificados de forma rígida:

Red virtual 1

Propiedad	Value
Location	Oeste de EE. UU.
Nombre de red virtual	<ClusterNamePrevix>-vnet1
Prefijo del espacio de direcciones	10.1.0.0/16
Nombre de subred	subred 1
Prefijo de la subred	10.1.0.0/24
Nombre de subred (puerta de enlace)	GatewaySubnet (no se puede cambiar)
Prefijo de la subred (puerta de enlace)	10.1.255.0/27
Nombre de puerta de enlace	vnet1gw
Tipo de puerta de enlace	VPN
Tipo de VPN de la puerta de enlace	RouteBased
SKU de puerta de enlace	Básico
Dirección IP de puerta de enlace	vnet1gwip

Red virtual 2

Propiedad	Value
Location	Este de EE. UU.
Nombre de red virtual	<ClusterNamePrevix>-vnet2
Prefijo del espacio de direcciones	10.2.0.0/16
Nombre de subred	subred 1
Prefijo de la subred	10.2.0.0/24
Nombre de subred (puerta de enlace)	GatewaySubnet (no se puede cambiar)
Prefijo de la subred (puerta de enlace)	10.2.255.0/27
Nombre de puerta de enlace	vnet2gw
Tipo de puerta de enlace	VPN
Tipo de VPN de la puerta de enlace	RouteBased
SKU de puerta de enlace	Básico
Dirección IP de puerta de enlace	vnet1gwip

Como alternativa, siga estos pasos para configurar dos VNET y VM diferentes manualmente.

1. Creación de dos VNET (Virtual Network) en una región diferente
2. Habilite el emparejamiento en las dos VNET. Vaya a la red virtual creada en los pasos anteriores y, luego, haga clic en emparejamiento y agregue el vínculo de emparejamiento de otra región. Hágalo para la red virtual.
3. Cree la versión más reciente de UBUNTU en cada VNET.

Configuración de DNS

En la última sección, la plantilla crea una máquina virtual de Ubuntu en cada una de las dos redes virtuales. En esta sección, puede instalar Bind en las dos máquinas virtuales del DNS y, después, configurar el reenvío de DNS en ambas.

Para instalar Bind, debe encontrar la dirección IP pública de las dos máquinas virtuales del DNS.

1. Abra Azure Portal.
2. Abra la máquina virtual de DNS; para ello, seleccione Grupos de recursos > [nombre del grupo de recursos] > [vnet1DNS]. El nombre del grupo de recursos es el que creó en el último procedimiento. Los nombres predeterminados de las máquinas virtuales del DNS son vnet1DNS y vnet2NDS.
3. Seleccione Propiedades para abrir la página de propiedades de la red virtual.
4. Anote la dirección IP pública y compruebe también la dirección IP privada. La dirección IP privada debe ser 10.1.0.4 para vnet1DNS y 10.2.0.4 para vnet2DNS.
5. Cambie los servidores DNS de ambas redes virtuales para usar servidores DNS predeterminados (proporcionados por Azure) para permitir el acceso de entrada y de salida para descargar los paquetes para instalar Bind en los pasos siguientes.

Para instalar Bind, use el procedimiento siguiente:

1. Use SSH para conectarse a la dirección IP pública de la máquina virtual del DNS. En el ejemplo siguiente, se realiza una conexión a una máquina virtual en 40.68.254.142:

   ssh sshuser@40.68.254.142
   

   Reemplace sshuser por la cuenta de usuario SSH que especificó cuando creó la máquina virtual de DNS.

   Nota

   Existen diversas formas de obtener la utilidad ssh. En Linux, Unix y macOS, se proporciona como parte del sistema operativo. Si usa Windows, considere una de las opciones siguientes:

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

2. Para instalar Bind, use los comandos siguientes en la sesión de SSH:

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

3. Configure Bind para reenviar las solicitudes de resolución de nombre al servidor DNS local. Para ello, use el texto siguiente como contenido del archivo /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

   Reemplace los valores de la sección goodclients por el intervalo de direcciones IP de las dos redes virtuales. En esta sección se definen las direcciones desde las cuales el servidor DNS acepta solicitudes.

   Para editar el archivo, use el comando siguiente:

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

   Para guardar el archivo, use Ctrl+X, Y y, luego, Entrar.

4. En la sesión de SSH, use el comando siguiente:

   hostname -f
   

   Este comando devuelve un valor similar al siguiente texto:

   vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
   

   El texto icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net está en el sufijo DNS de esta red virtual. Guarde este valor, porque se utiliza más adelante.

   También deberá averiguar el sufijo DNS del otro servidor DNS. La necesitará en el paso siguiente.

5. Para configurar Bind a fin de resolver nombres DNS para recursos dentro de la red virtual, use el texto siguiente como contenido del archivo /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

   Debe reemplazar el valor v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net por el sufijo DNS de la otra red virtual. Y la dirección IP del reenviador es la dirección IP privada del servidor DNS de la otra red virtual.

   Para editar el archivo, use el comando siguiente:

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

   Para guardar el archivo, use Ctrl+X, Y y, luego, Entrar.

6. Para iniciar Bind, use el comando siguiente:

   sudo service bind9 restart
   

7. Para comprobar que Bind puede resolver los nombres de recursos en la otra red virtual, use los comandos siguientes:

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

   Importante

   Reemplace vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net por el nombre de dominio completo (FQDN) de la máquina virtual de DNS de la otra red.

   Reemplace 10.2.0.4 por la dirección IP interna del servidor DNS personalizado de la otra red virtual.

   La respuesta es similar al texto siguiente:

   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
   

   Hasta ahora, no podía buscar la dirección IP de la otra red sin especificar la dirección IP del servidor DNS.

Configuración de la red virtual para usar el servidor DNS personalizado

Para configurar la red virtual para que use el servidor DNS personalizado en lugar de la resolución recursiva de Azure, use los pasos siguientes:

1. En Azure Portal, seleccione la red virtual y, luego, seleccione Servidores DNS.

2. Seleccione Personalizar y escriba la dirección IP interna del servidor DNS personalizado. Por último, seleccione Guardar.

3. Abra la máquina virtual del servidor DNS en vnet1 y haga clic en Reiniciar. Debe reiniciar todas las máquinas virtuales de la red virtual para que la configuración de DNS surta efecto.

4. Repita los pasos para configurar el servidor DNS personalizado para vnet2.

Para probar la configuración de DNS, puede conectarse a las dos máquinas virtuales de DNS mediante SSH y hacer ping en el servidor DNS de la otra red virtual mediante su nombre de host. Si no funciona, utilice el siguiente comando para comprobar el estado del DNS:

sudo service bind9 status

Creación de clústeres de Apache HBase

Cree un clúster de Apache HBase en cada una de las dos redes virtuales con la siguiente configuración:

• Nombre del grupo de recursos: use el mismo nombre del grupo de recursos que cuando creó las redes virtuales.
• Tipo de clúster: HBase
• Versión: HBase 1.1.2 (HDI 3.6)
• Ubicación: seleccione la misma ubicación que la red virtual. De forma predeterminada, para vnet1 es Oeste de EE. UU. y para vnet2 es Este de EE. UU.
• Almacenamiento: cree una nueva cuenta de almacenamiento para el clúster.
• Red virtual (en Configuración avanzada en el portal): seleccione vnet1, la máquina virtual que creó en el último procedimiento.
• Subred: el nombre predeterminado que se utiliza en la plantilla es subnet1.

Para asegurarse de que el entorno está configurado correctamente, debe poder hacer ping en el FQDN del nodo principal entre los dos clústeres.

Carga de datos de prueba

Al replicar un clúster, debe especificar las tablas que quere replicar. En esta sección, va a cargar algunos datos en el clúster de origen. En la siguiente sección, habilitará la replicación entre los dos clústeres.

Para crear una tabla Contacts e insertar algunos datos en ella, siga las instrucciones que se indican en el tutorial de HBase sobre la introducción al uso de Apache HBase en HDInsight.

Nota

Si desea replicar tablas desde un espacio de nombres personalizado, debe asegurarse de que también se definen los espacios de nombres personalizados adecuados en el clúster de destino.

Habilitar replicación

En los pasos siguientes se describe cómo llamar al script de acción de script desde Azure Portal. Para información sobre la ejecución de una acción de script mediante Azure PowerShell y la CLI clásica de Azure, consulte Personalización de clústeres de HDInsight mediante la acción de scripts.

Para habilitar la replicación de HBase desde Azure Portal

1. Inicie sesión en Azure Portal.

2. Abra el clúster de HBase de origen.

3. En el menú de clúster, seleccione Acciones de script.

4. En la parte superior de la página, seleccione Enviar nuevo.

5. Seleccione o escriba la siguiente información:

   1. Nombre especifique Enable replication (Habilitar replicación).
   2. URL de script de Bash: escriba https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh.
   3. Principal: asegúrese de que este parámetro esté seleccionado. Borre los demás tipos de nodo.
   4. Parámetros: los siguientes parámetros de ejemplo permiten la replicación en todas las tablas existentes y copian todos los datos del clúster de origen al clúster 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 el nombre de host en lugar de FQDN para el nombre DNS del clúster de origen y de destino.

   En este tutorial se da por supuesto que hn1 es el nodo principal activo. Compruebe el clúster para identificar el nodo principal activo.

6. Seleccione Crear. El script puede tardar un poco en ejecutarse, especialmente cuando se usa el argumento -copydata.

Argumentos necesarios:

Nombre	Descripción
-s, --src-cluster	Especifica el nombre DNS del clúster de HBase de origen. Por ejemplo: -s hbsrccluster, --src-cluster=hbsrccluster
-d, --dst-cluster	Especifica el nombre DNS del clúster de HBase de destino (réplica). Por ejemplo: -s dsthbcluster, --src-cluster=dsthbcluster
-sp, --src-ambari-password	Especifica la contraseña de administrador de Ambari en el clúster de HBase de origen.
-dp, --dst-ambari-password	Especifica la contraseña de administrador de Ambari en el clúster de HBase de destino.

Argumentos opcionales:

Nombre	Descripción
-su, --src-ambari-user	Especifica el nombre de usuario de administrador de Ambari en el clúster de HBase de origen. El valor predeterminado es admin.
-du, --dst-ambari-user	Especifica el nombre de usuario de administrador de Ambari en el clúster de HBase de destino. El valor predeterminado es admin.
-t, --table-list	Especifica las tablas que se van a replicar. Por ejemplo: --table-list="table1;table2;table3". Si no se especifica unas tablas determinadas, se replican todas las tablas de HBase existentes.
-m, --machine	Especifica el nodo principal en el que se ejecuta la acción de script. El valor debe elegirse en función del nodo principal activo. Use esta opción si se está ejecutando el script $0 como acción de script desde el portal de HDInsight o Azure PowerShell.
-cp, -copydata	Habilita la migración de datos existentes en las tablas en las que está habilitada la replicación.
-rpm, -replicate-phoenix-meta	Habilita la replicación en las tablas del sistema Phoenix. Esta opción se debe utilizar con precaución. Se recomienda volver a crear tablas de Phoenix en clústeres de réplica antes de utilizar este script.
-h, --help	Muestra información de uso.

La sección print_usage() del script contiene una explicación detallada de los parámetros.

Una vez implementada correctamente la acción de script, puede usar SSH para conectarse al clúster de HBase de destino y comprobar que los datos se hayan replicado.

Escenarios de replicación

En la lista siguiente se muestran algunos casos de uso general y la configuración de parámetros:

• Habilitar la replicación en todas las tablas entre los dos clústeres. En este escenario no es necesario copiar o migrar datos existentes de las tablas y no se usan tablas de Phoenix. Use los parámetros siguientes:

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

• Habilitar la replicación en tablas específicas. Para habilitar la replicación en table1, table2 y table3, use los parámetros siguientes:

  -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 la replicación en tablas específicas y copiar los datos existentes. Para habilitar la replicación en table1, table2 y table3, use los parámetros siguientes:

  -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 la replicación en todas las tablas y replicar metadatos de Phoenix del origen al destino. La replicación de metadatos de Phoenix no es perfecta. Úsela con precaución. Use los parámetros siguientes:

  -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

Configuración de la replicación entre clústeres de ESP

Requisitos previos

1. Ambos clústeres de ESP deberían estar allí en el mismo dominio kerberos (dominio). Compruebe la propiedad de dominio kerberos predeterminada del archivo /etc/krb5.conf para confirmar.
2. El usuario común debería estar ahí, quien tenga acceso de lectura y escritura a ambos clústeres
   1. Por ejemplo, si ambos clústeres tuviera el mismo usuario administrador del clúster (por ejemplo: admin@abc.example.com), ese usuario se podrá usar para ejecutar el script de replicación.
   2. Si ambos clústeres usaran el mismo grupo de usuarios, podrá agregar un nuevo usuario o usar un usuario existente del grupo.
   3. Si ambos clústeres usaran un grupo de usuarios diferente, podrá agregar un nuevo usuario para que ambos usen un usuario existente de los grupos.

Pasos para ejecutar el script de replicación

Nota

Realice los pasos siguientes solo si el DNS no pudiera resolver el nombre de host correctamente del clúster de destino.

1. Copie la asignación de IP y nombre de host de los hosts del clúster de destino en el archivo /etc/hosts de los nodos del clúster de origen.
2. Copie el nodo principal, el nodo de trabajo y el host de nodos de ZooKeeper y la asignación de IP del archivo /etc/hosts del clúster de destino (receptor).
3. Agregue el archivo /etc/hosts del clúster de origen de entradas copiadas. Estas entradas se deberían agregar a los nodos principales, los nodos de trabajo y los nodos de ZooKeeper.

Paso 1: crear archivo keytab para el usuario mediante ktutil. $ ktutil

1. addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
2. Pedir contraseña para autenticarse, proporcionar la contraseña de usuario
3. wkt /etc/security/keytabs/admin.keytab

Nota

Asegúrese de que el archivo keytab se almacene en la carpeta /etc/security/keytabs/ con el formato <username>.keytab.

Paso 2: ejecutar acción de script con la opción -ku.

1. Proporcione -ku <username> en clústeres ESP.

Nombre	Descripción
-ku, --krb-user	En el caso de los clústeres ESP, los usuarios de Kerberos común, que pueden autenticar clústeres de origen y destino

Copia y migración de datos

Hay dos scripts de acción de script independientes para copiar o migrar datos después de habilitar la replicación:

• Script para tablas pequeñas (tablas que tienen unos cuantos gigabytes de tamaño y se espera que una copia general finalice en menos de una hora)

• Script para tablas grandes (tablas que se espera que tarden más de una hora en copiarse)

Puede seguir el mismo procedimiento que se describe en Habilitar replicación para llamar a la acción de script. Use los parámetros siguientes:

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

La sección print_usage() del script contiene una descripción detallada de los parámetros.

Escenarios

• Copiar tablas específicas (test1, test2 y test3) con todas las filas editadas hasta ahora (marca de tiempo actual):

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

  O:

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

• Copiar tablas específicas con un intervalo de tiempo especificado:

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

Deshabilitar replicación

Para deshabilitar la replicación, use otro script de acción de script de GitHub. Puede seguir el mismo procedimiento que se describe en Habilitar replicación para llamar a la acción de script. Use los parámetros siguientes:

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

La sección print_usage() del script contiene una explicación detallada de los parámetros.

Escenarios

• Deshabilitar la replicación en todas las tablas:

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

  or

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

• Deshabilitar la replicación en las tablas especificadas (table1, table2 y table3):

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

Nota

Si piensa eliminar el clúster de destino, asegúrese de quitarlo de la lista del mismo nivel del clúster de origen. Esto puede ejecutando el comando remove_peer '1' en el shell de HBase en el clúster de origen. Si se produce un error, es posible que el clúster de origen no funcione correctamente.

Pasos siguientes

En este artículo, ha aprendido a configurar la replicación de Apache HBase en una red virtual, o entre dos redes virtuales. Para más información sobre HDInsight y Apache HBase, consulte estos artículos:

• Introducción a HBase Apache en HDInsight
• Introducción a Apache HBase de HDInsight
• Creación de clústeres de Apache HBase en Azure Virtual Network