Configurer la réplication de cluster Apache HBase dans les réseaux virtuels Azure

Article
04/29/2024

Découvrez comment configurer la réplication Apache HBase dans un réseau virtuel ou entre deux réseaux virtuels dans Azure.

La réplication en cluster utilise une méthodologie par émission de données source. Un cluster HBase peut être une source, une destination ou jouer les deux rôles à la fois. La réplication est asynchrone. L'objectif de la réplication est une cohérence éventuelle. Quand la source reçoit une modification apportée à une famille de colonnes lorsque la réplication activée, cette modification est propagée à tous les clusters de destination. Quand les données sont répliquées d’un cluster à un autre, le cluster source et tous les clusters qui ont déjà utilisé les données font l’objet d’un suivi afin d’empêcher les boucles de réplication.

À l’aide de cet article, vous allez configurer une réplication source-destination. Pour d'autres topologies de cluster, consultez le Guide de référence d'Apache HBase.

Cas d’utilisation de la réplication HBase pour un seul réseau virtuel :

Équilibrage de charge : vous pouvez par exemple exécuter des analyses ou des travaux MapReduce sur le cluster de destination et ingérer des données sur le cluster source
Ajout de haute disponibilité
Migration de données d’un cluster HBase vers un autre
Mise à niveau d’un cluster Azure HDInsight d’une version vers une autre

Cas d’utilisation de la réplication HBase pour deux réseaux virtuels :

Configuration d’une récupération d'urgence
Équilibrage de charge et partitionnement de l’application
Ajout de haute disponibilité

Vous pouvez répliquer des clusters à l’aide de scripts d’action de script disponibles dans GitHub.

Prérequis

Avant de commencer cet article, vous devez disposer d’un abonnement Azure. Consultez Obtention d’un essai gratuit d’Azure.

Configurer les environnements

Il existe trois options de configuration :

Deux clusters Apache HBase dans un réseau virtuel Azure
Deux clusters Apache HBase dans deux réseaux virtuels différents dans la même région
Deux clusters Apache HBase dans deux réseaux virtuels différents dans deux régions distinctes (géoréplication)

Cet article présente le scénario de géoréplication.

Pour vous aider à configurer les environnements, nous avons créé des modèles Azure Resource Manager. Si vous préférez configurer les environnements en utilisant d’autres méthodes, consultez :

Configurer deux réseaux virtuels dans deux régions différentes

Pour utiliser un modèle qui crée deux réseaux virtuels dans deux régions différentes et la connexion VPN entre les deux, sélectionnez le bouton suivant Déployer sur Azure.

Voici quelques-unes des valeurs codées en dur dans le modèle :

Réseau virtuel 1

Propriété	Valeur
Emplacement	USA Ouest
Nom du réseau virtuel	<ClusterNamePrevix>-vnet1
Préfixe de l’espace d’adressage	10.1.0.0/16
Nom du sous-réseau	subnet 1
Préfixe du sous-réseau	10.1.0.0/24
Nom du sous-réseau (passerelle)	GatewaySubnet (non modifiable)
Préfixe du sous-réseau (passerelle)	10.1.255.0/27
Nom de la passerelle	vnet1gw
Type de passerelle	Vpn
Type de VPN de la passerelle	RouteBased
SKU de la passerelle	De base
Adresse IP de la passerelle	vnet1gwip

Réseau virtuel 2

Propriété	Valeur
Emplacement	USA Est
Nom du réseau virtuel	<ClusterNamePrevix>-vnet2
Préfixe de l’espace d’adressage	10.2.0.0/16
Nom du sous-réseau	subnet 1
Préfixe du sous-réseau	10.2.0.0/24
Nom du sous-réseau (passerelle)	GatewaySubnet (non modifiable)
Préfixe du sous-réseau (passerelle)	10.2.255.0/27
Nom de la passerelle	vnet2gw
Type de passerelle	Vpn
Type de VPN de la passerelle	RouteBased
SKU de la passerelle	De base
Adresse IP de la passerelle	vnet1gwip

Vous pouvez également suivre les étapes ci-dessous pour configurer deux réseaux virtuels différents et des machines virtuelles manuellement

Créer deux réseaux virtuels dans différentes régions
Activez le peering dans les deux réseaux virtuels. Accédez au réseau virtuel créé dans les étapes ci-dessus, puis cliquez sur Peering et ajoutez un lien de peering d’une autre région. Faites-le pour les deux réseaux virtuels.
Créez la dernière version d’UBUNTU dans chaque réseau virtuel.

Configurer DNS

Dans la dernière section, le modèle crée une machine virtuelle Ubuntu dans chacun des deux réseaux virtuels. Dans cette section, vous installez Bind sur les deux machines virtuelles DNS puis configurez la redirection DNS sur les deux machines virtuelles.

Pour installer Bind, vous devez rechercher l’adresse IP publique des deux machines virtuelles DNS.

Ouvrez le portail Azure.
Ouvrez la machine virtuelle DNS en sélectionnant Groupes de ressources > [nom du groupe de ressources] > [vnet1DNS]. Le nom du groupe de ressources est celui que vous créez dans la dernière procédure. Les noms des machines virtuelles DNS par défaut sont vnet1DNS et vnet2NDS.
Sélectionnez Propriétés pour ouvrir la page des propriétés du réseau virtuel.
Notez l’adresse IP publique et vérifiez l’adresse IP privée. L’adresse IP privée doit être 10.1.0.4 pour vnet1DNS et 10.2.0.4 pour vnet2DNS.
Remplacez les serveurs DNS des deux réseaux virtuels par les serveurs DNS par défaut (fournis par Azure) pour autoriser l’accès entrant et sortant afin de télécharger les packages visant à installer Bind dans les étapes suivantes.

Pour installer Bind, procédez comme suit :

Utilisez SSH pour vous connecter à l’adresse IP publique de la machine virtuelle DNS. L’exemple suivant établit une connexion à une machine virtuelle dont l’adresse IP est 40.68.254.142 :
```
ssh sshuser@40.68.254.142
```
Remplacez sshuser par le compte d’utilisateur SSH que vous avez spécifié lors de la création de la machine virtuelle DNS.
Notes

Il existe plusieurs façons d’obtenir l’utilitaire ssh. Sur Linux, Unix et macOS, il est généralement fourni en tant que composant du système d’exploitation. Si vous utilisez Windows, envisagez l’une des options suivantes :
Pour installer Bind, utilisez les commandes suivantes à partir de la session SSH :
```
 sudo apt-get update -y
 sudo apt-get install bind9 -y
```

Configurez Bind afin de transférer les demandes de résolution de noms à votre serveur DNS local. Pour ce faire, utilisez le texte suivant comme contenu du fichier /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; };
};

Important

Remplacez les valeurs de la section goodclients par la plage d’adresses IP des deux réseaux virtuels. Cette section définit les adresses d’origine des demandes que ce serveur DNS accepte.

Pour modifier ce fichier, utilisez la commande suivante :

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

Pour enregistrer le fichier, appuyez sur Ctrl+X, O, puis Entrée.

À partir de la session SSH, utilisez la commande suivante :
```
hostname -f
```
Cette commande retourne une valeur semblable au texte suivant :
```
vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
```
Le texte icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net est le suffixe DNS de ce réseau virtuel. Enregistrez cette valeur, car vous en aurez besoin plus tard.

Vous devez également déterminer le suffixe DNS de l’autre serveur DNS. Vous en aurez besoin à l’étape suivante.
Pour configurer Bind afin de résoudre les noms DNS pour les ressources au sein du réseau virtuel, utilisez le texte suivant en tant que contenu du fichier /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
};
```
Important

Vous devez remplacer v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net par le suffixe DNS de l’autre réseau virtuel. Et l’adresse IP de redirection est l’adresse IP privée du serveur DNS de l’autre réseau virtuel.

Pour modifier ce fichier, utilisez la commande suivante :
```
sudo nano /etc/bind/named.conf.local
```
Pour enregistrer le fichier, appuyez sur Ctrl+X, O, puis Entrée.
Pour démarrer Bind, utilisez la commande suivante :
```
sudo service bind9 restart
```
Pour vérifier que Bind peut résoudre les noms de ressources de l’autre réseau virtuel, utilisez les commandes suivantes :
```
sudo apt install dnsutils
nslookup vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
```
Important

Remplacez vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net par le nom de domaine complet (FQDN) de la machine virtuelle DNS de l’autre réseau.

Remplacez 10.2.0.4 par l’adresse IP interne de votre serveur DNS personnalisé dans l’autre réseau virtuel.

La réponse est similaire au texte suivant :
```
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
```
Pour l’heure, vous ne pouvez pas rechercher l’adresse IP à partir de l’autre réseau sans l’adresse IP spécifiée du serveur DNS.

Configurer le réseau virtuel pour utiliser le serveur DNS personnalisé

Pour configurer le réseau virtuel afin d’utiliser le serveur DNS personnalisé au lieu du programme de résolution récursive Azure, procédez comme suit :

Dans le portail Azure, sélectionnez le réseau virtuel, puis choisissez Serveurs DNS.
Sélectionnez Personnalisé, puis entrez l’adresse IP interne du serveur DNS personnalisé. Enfin, sélectionnez Enregistrer.
Ouvrez la machine virtuelle du serveur DNS dans vnet1, puis cliquez sur Redémarrer. Vous devez redémarrer toutes les machines virtuelles dans le réseau virtuel pour appliquer la configuration DNS.
Répétez les étapes pour configurer le serveur DNS personnalisé pour vnet2.

Pour tester la configuration DNS, vous pouvez vous connecter aux deux machines virtuelles DNS à l’aide de SSH, puis effectuez un test ping sur le serveur DNS de l’autre réseau virtuel à l’aide de son nom d’hôte. En cas d’échec, utilisez la commande suivante pour vérifier l’état DNS :

sudo service bind9 status

Créer des clusters Apache HBase

Créez un cluster Apache HBase dans chacun des deux réseaux virtuels avec la configuration suivante :

Nom du groupe de ressources : utilisez le même nom de groupe de ressources que vous avez créé pour les réseaux virtuels.
Type de cluster : HBase
Version : HBase 1.1.2 (HDI 3.6)
Emplacement : utilisez l’emplacement du réseau virtuel. Par défaut, vnet1 représente USA Ouest, et vnet2 correspond à USA Est.
Stockage : créez un nouveau compte de stockage pour le cluster.
Réseau virtuel (dans les paramètres avancés sur le portail) : sélectionnez l’élément vnet1 que vous avez créé dans la dernière procédure.
Sous-réseau : le nom par défaut utilisé dans le modèle est subnet1.

Pour garantir que l’environnement est correctement configuré, vous devez pouvoir effectuer un test ping sur le nom de domaine complet du nœud principal entre les deux clusters.

Charger les données de test

Lorsque vous répliquez un cluster, vous devez spécifier les tables à répliquer. Dans cette section, vous chargez des données dans le cluster source. Dans la section suivante, vous allez activer la réplication entre les deux clusters.

Pour créer une table Contacts et y insérer des données, suivez les instructions du Tutoriel Apache HBase : Bien démarrer avec Apache HBase dans HDInsight.

Notes

Si vous voulez répliquer des tables à partir d’un espace de noms personnalisé, vous devez vous assurer que les espaces de noms personnalisés appropriés sont également définis sur le cluster de destination.

Activer la réplication

Les étapes suivantes décrivent comment appeler le script d’action de script à partir du portail Azure. Pour savoir comment exécuter une action de script en utilisant Azure PowerShell et Azure Classic CLI, consultez Personnaliser des clusters HDInsight à l’aide d’une action de script.

Pour activer la réplication HBase à partir du portail Azure

Connectez-vous au portail Azure.
Ouvrez le cluster HBase source.
Dans le menu de cluster, sélectionnez Actions de script.
En haut de la page, sélectionnez Soumettre nouveau.
Sélectionnez ou saisissez les informations suivantes :
1. Nom : saisissez Activer la réplication.
2. URL du script Bash : entrez https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh.
3. Principal : Vérifiez que cette option est sélectionnée. Supprimez les autres types de nœuds.
4. Paramètres : les paramètres d’exemple suivants activent la réplication pour toutes les tables existantes, puis copient toutes les données du cluster source vers le cluster de destination :
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -copydata

Notes

Utilisez le nom d’hôte plutôt que le nom de domaine complet (FQDN) pour le nom DNS du cluster source et du cluster de destination.

Cette procédure pas à pas suppose que hn1 est le nœud principal actif. Examinez votre cluster pour identifier le nœud principal actif.
Sélectionnez Create (Créer). L’exécution du script peut prendre un certain temps, en particulier lorsque vous utilisez l’argument -copydata.

Arguments requis :

Nom	Description
-s, --src-cluster	Spécifie le nom DNS du cluster HBase source. Par exemple : -s hbsrccluster, --src-cluster=hbsrccluster
-d, --dst-cluster	Spécifie le nom DNS du cluster HBase de destination (réplica). Par exemple : -s dsthbcluster, --src-cluster=dsthbcluster
-sp, --src-ambari-password	Spécifie le mot de passe d’administrateur pour Ambari sur le cluster HBase source.
-dp, --dst-ambari-password	Spécifie le mot de passe d’administrateur pour Ambari sur le cluster HBase de destination.

Arguments facultatifs :

Nom	Description
-su, --src-ambari-user	Spécifie le nom d’utilisateur administrateur pour Ambari sur le cluster HBase source. La valeur par défaut est admin.
-du, --dst-ambari-user	Spécifie le nom d’utilisateur administrateur pour Ambari sur le cluster HBase de destination. La valeur par défaut est admin.
-t, --table-list	Spécifie les tables à répliquer. Par exemple : --table-list="table1;table2;table3". Si vous ne spécifiez pas de tables, toutes les tables HBase existantes sont répliquées.
-m, --machine	Spécifie le nœud principal sur lequel l’action de script s’exécute. La valeur doit être choisie en fonction du nœud principal actif. Utilisez cette option lorsque vous exécutez le script $0 comme une action de script à partir du portail HDInsight ou d’Azure PowerShell.
-cp, -copydata	Active la migration des données existantes sur les tables pour lesquelles la réplication est activée.
-rpm, -replicate-phoenix-meta	Active la réplication sur les tables système Phoenix. Utilisez cette option avec précaution. Nous vous recommandons de recréer des tables Phoenix sur les clusters de réplica avant d’utiliser ce script.
-h, --help	Affiche des informations sur l’utilisation.

La section print_usage() du script offre une explication détaillée des paramètres.

Une fois le déploiement de l’action de script terminé, vous pouvez utiliser SSH pour vous connecter au cluster HBase de destination, puis vérifier que les données ont été répliquées.

Scénarios de réplication

La liste suivante présente certains cas d’utilisation générale et la définition de leurs paramètres :

Activer la réplication sur toutes les tables entre les deux clusters. Ce scénario ne nécessite pas de copier ou de migrer les données existant dans les tables, et ne fait pas appel à des tables Phoenix. Utilisez les paramètres suivants :

-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password>
Activer la réplication sur des tables spécifiques. Pour activer la réplication sur table1, table2 et table3, utilisez les paramètres suivants :

-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"
Activer la réplication sur des tables spécifiques et copier les données existantes. Pour activer la réplication sur table1, table2 et table3, utilisez les paramètres suivants :

-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
Activer la réplication sur toutes les tables et répliquer les métadonnées Phoenix de la source vers la destination. La réplication des métadonnées Phoenix n’est pas parfaite. Utilisez-la avec précaution. Utilisez les paramètres suivants :

-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

Configurer la réplication entre des clusters ESP

Composants requis

Les deux clusters ESP doivent se trouver dans le même domaine. Vérifiez la propriété de domaine par défaut du fichier /etc/krb5.conf pour confirmer.
Il doit exister un utilisateur commun disposant d’un accès en lecture et en écriture aux deux clusters
1. Par exemple, si les deux clusters ont le même utilisateur administrateur de cluster (par exemple, admin@abc.example.com), cet utilisateur peut être utilisé pour exécuter le script de réplication.
2. Si les deux clusters utilisent le même groupe d’utilisateurs, vous pouvez ajouter un nouvel utilisateur ou utiliser un utilisateur existant du groupe.
3. Si le groupe d’utilisateurs utilisé par les deux clusters est différent, vous pouvez ajouter un nouvel utilisateur aux deux ou utiliser un utilisateur existant des groupes.

Étapes d’exécution du script de réplication

Notes

N’effectuez les étapes suivantes que si DNS ne parvient pas à résoudre correctement le nom d’hôte du cluster de destination.

Copiez le mappage du nom d’hôte et de l’adresse IP des hôtes du cluster récepteur dans les nœuds du cluster source /etc/fichier des hôtes.
Copiez le mappage des hôtes et des adresses IP du nœud principal, du nœud Worker et des nœuds ZooKeeper à partir du fichier /etc/hosts du cluster de destination (récepteur).
Ajoutez les entrées copiée au fichier /etc/hosts du cluster source. Ces entrées doivent être ajoutées aux nœuds principaux, aux nœuds Worker et aux nœuds ZooKeeper.

Étape 1 : Créez un fichier keytab pour l’utilisateur en utilisant ktutil. $ ktutil

addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
Demandez le mot de passe pour l’authentification, fournissez le mot de passe de l’utilisateur
wkt /etc/security/keytabs/admin.keytab

Notes

Veillez à ce que le fichier keytab soit stocké dans le dossier /etc/security/keytabs/ au format <username>.keytab.

Étape 2 : Exécutez une action de script avec l’option -ku

Fournissez -ku <username> sur les clusters ESP.

Nom	Description
`-ku, --krb-user`	Pour les clusters ESP, utilisateur Kerberos commun, qui peut authentifier le cluster source et le cluster de destination

Copier et migrer des données

Il existe deux scripts d’action de script distincts disponibles pour copier ou migrer des données une fois la réplication activée :

Script pour les petites tables (tables dont la taille est de quelques gigaoctets et dont la copie globale est censée durer moins d’une heure)
Script pour les tables volumineuses (tables dont la copie est censée durer plus d’une heure)

Vous pouvez suivre la même procédure que celle décrite dans la section Activer la réplication pour appeler l’action de script. Utilisez les paramètres suivants :

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

La section print_usage() du script offre une description détaillée des paramètres.

Scénarios

Copier des tables spécifiques (test1, test2 et test3) pour toutes les lignes modifiées jusqu’à présent (horodatage actuel) :

-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
Copier des tables spécifiques avec une plage horaire spécifiée :

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

Désactiver la réplication

Pour désactiver la réplication, utilisez un autre script d’action de script disponible dans GitHub. Vous pouvez suivre la même procédure que celle décrite dans la section Activer la réplication pour appeler l’action de script. Utilisez les paramètres suivants :

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

La section print_usage() du script offre une explication détaillée des paramètres.

Scénarios

Désactiver la réplication sur toutes les tables :

-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>
Désactiver la réplication sur les tables spécifiées (table1, table2 et table3) :

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

Notes

Si vous envisagez de supprimer le cluster de destination, veillez à le faire à partir de la liste des pairs du cluster source. Pour cela, vous pouvez exécuter la commande remove_peer '1' dans l’interpréteur de commandes hbase sur le cluster source. Si vous ne procédez pas ainsi, le cluster source risque de ne pas fonctionner correctement.

Étapes suivantes

Dans cet article, vous avez vu comment configurer la réplication Apache HBase dans un réseau virtuel ou entre deux réseaux virtuels. Pour plus d’informations sur HDInsight et Apache HBase, consultez les articles suivants :

Partager via

Configurer la réplication de cluster Apache HBase dans les réseaux virtuels Azure

Prérequis

Configurer les environnements

Configurer deux réseaux virtuels dans deux régions différentes

Configurer DNS

Configurer le réseau virtuel pour utiliser le serveur DNS personnalisé

Créer des clusters Apache HBase

Charger les données de test

Activer la réplication

Scénarios de réplication

Configurer la réplication entre des clusters ESP

Copier et migrer des données

Scénarios

Désactiver la réplication

Scénarios

Étapes suivantes

Commentaires

Ressources supplémentaires