Azure 仮想ネットワーク内で Apache HBase クラスターのレプリケーションを設定する

[アーティクル]
04/29/2024

Azure の 1 つの仮想ネットワーク内または 2 つの仮想ネットワーク間で Apache HBase レプリケーションを設定する方法について説明します。

クラスターのレプリケーションでは、ソースプッシュの手法が使用されます。 HBase クラスターは、ソースまたはターゲットになることも、両方のロールを同時に満たすこともできます。レプリケーションは非同期です。レプリケーションの目的は、最終的な一貫性です。レプリケーションが有効になった列ファミリに対する編集をソースが受け取ると、その編集はすべてのターゲットクラスターに伝達されます。クラスター間でデータがレプリケートされるときは、レプリケーションループを防止するために、ソースクラスターとそのデータの使用を既に完了しているすべてのクラスターが追跡されます。

この記事では、ソースとターゲット間のレプリケーションを設定します。他のクラスタートポロジについては、Apache HBase のリファレンスガイドを参照してください。

次に示すのは、単一の仮想ネットワークでの HBase レプリケーションの使用例です。

負荷分散。たとえば、ターゲットクラスターでスキャンや MapReduce ジョブを実行し、ソースクラスターでデータを取り込みます。
高可用性の追加。
HBase クラスター間のデータの移行。
Azure HDInsight クラスターのバージョンのアップグレード。

次に示すのは、2 つの仮想ネットワーク間での HBase レプリケーションの使用例です。

ディザスターリカバリーの設定。
アプリケーションの負荷分散とパーティション分割。
高可用性の追加。

クラスターは、GitHub のスクリプトアクションのスクリプトを使用してレプリケートできます。

前提条件

この記事を開始する前に、Azure サブスクリプションが必要です。 Azure 無料試用版の取得に関するページを参照してください。

環境を設定する

3 つの構成オプションがあります。

1 つの Azure 仮想ネットワーク内の 2 つの Apache HBase クラスター。
同じリージョンの 2 つの異なる仮想ネットワーク内の 2 つの Apache HBase クラスター。
2 つの異なるリージョンの 2 つの異なる仮想ネットワーク内の 2 つの Apache HBase クラスター (geo レプリケーション)。

この記事では、geo レプリケーションシナリオについて説明します。

環境を設定しやすくするために、複数の Azure Resource Manager テンプレートが用意されています。他の方法で環境を設定する場合は、次の記事を参照してください。

2 つの異なるリージョンに 2 つの仮想ネットワークを設定する

2 つの異なるリージョンの 2 つの仮想ネットワークと、その VNet 間の VPN 接続を作成するテンプレートを使用するには、次の [Deploy to Azure] ボタンを選択します。

テンプレートには、一部の値がハードコーディングされています。それらの値を次に示します。

VNet 1

プロパティ	値
場所	米国西部
VNet の名前	<ClusterNamePrevix>-vnet1
アドレス空間プレフィックス	10.1.0.0/16
サブネット名	subnet 1
サブネットのプレフィックス	10.1.0.0/24
サブネット (ゲートウェイ) 名	GatewaySubnet (変更不可)
サブネット (ゲートウェイ) プレフィックス	10.1.255.0/27
ゲートウェイ名	vnet1gw
ゲートウェイの種類	Vpn
ゲートウェイ VPN の種類	RouteBased
ゲートウェイ SKU	Basic
ゲートウェイの IP	vnet1gwip

VNet 2

プロパティ	値
場所	米国東部
VNet の名前	<ClusterNamePrevix>-vnet2
アドレス空間プレフィックス	10.2.0.0/16
サブネット名	subnet 1
サブネットのプレフィックス	10.2.0.0/24
サブネット (ゲートウェイ) 名	GatewaySubnet (変更不可)
サブネット (ゲートウェイ) プレフィックス	10.2.255.0/27
ゲートウェイ名	vnet2gw
ゲートウェイの種類	Vpn
ゲートウェイ VPN の種類	RouteBased
ゲートウェイ SKU	Basic
ゲートウェイの IP	vnet1gwip

または、次の手順に従って、2 つの異なる VNet と VM を手動でセットアップします

異なるリージョン内に 2 つの VNET (仮想ネットワーク) を作成します。
両方の VNET でピアリングを有効にします。上記の手順で作成した仮想ネットワークに移動し、[ピアリング] をクリックして別のリージョンのピアリングリンクを追加します。両方の仮想ネットワークに対して実行します。
各 VNET に最新バージョンの UBUNTU を作成します。

DNS をセットアップする

最後のセクションで、テンプレートは、2 つの仮想ネットワークのそれぞれの中に Ubuntu 仮想マシンを作成します。このセクションでは、2 つの DNS 仮想マシンに Bind をインストールし、2 つの仮想マシンで DNS の転送を構成します。

Bind をインストールするには、2 つの DNS 仮想マシンのパブリック IP アドレスを見つける必要があります。

Azure portal を開きます。
[リソースグループ] > <リソースグループ名> > [vnet1DNS] を選択して、DNS 仮想マシンを開きます。リソースグループ名は、最後の手順で作成する名前です。既定の DNS 仮想マシン名は、vnet1DNS と vnet2NDS です。
[プロパティ] を選択して、仮想ネットワークのプロパティページを開きます。
[パブリック IP アドレス] を書き留めます。さらに、[プライベート IP アドレス] を確認します。プライベート IP アドレスは、vnet1DNS では 10.1.0.4、vnet2DNS では 10.2.0.4 です。
既定の (Azure で提供されている) DNS サーバーを使用して受信および送信アクセスでパッケージをダウンロードして Bind をインストールできるように、次の手順で両方の仮想ネットワークの DNS サーバーを変更します。

Bind をインストールするには、次の手順に従います。

SSH を使用して、DNS 仮想マシンの パブリック IP アドレス にアクセスします。次の例では、40.68.254.142 の仮想マシンに接続します。
```
ssh sshuser@40.68.254.142
```
sshuser を、DNS 仮想マシンの作成時に指定した SSH ユーザーアカウントに置き換えます。
注意

ssh ユーティリティは、さまざまな方法で取得できます。 Linux、Unix、および macOS では、オペレーティングシステムの一部として提供されます。 Windows を使用している場合は、次のオプションのいずれかを検討してください。
Bind をインストールするには、SSH セッションから次のコマンドを使用します。
```
 sudo apt-get update -y
 sudo apt-get install bind9 -y
```
オンプレミスの DNS サーバーに名前解決要求を転送するように Bind を構成します。そのために、/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; };
};
```
重要

goodclients セクションの値を、2 つの仮想ネットワークの IP アドレス範囲に置き換えます。このセクションは、この DNS サーバーが受け入れる要求の転送元アドレスを定義します。

このファイルを編集するには、次のコマンドを使用します。
```
sudo nano /etc/bind/named.conf.options
```
ファイルを保存するには、Ctrl + X キー、Y キー、Enter キーの順に押します。
SSH セッションでは、次のコマンドを使用します。
```
hostname -f
```
このコマンドにより、次のテキストのような値が返されます。
```
vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
```
icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net テキストは、この仮想ネットワークの DNS サフィックス です。この値を保存します。これは後で使用します。

他の DNS サーバーの DNS サフィックスも見つけておく必要があります。次の手順で必要になります。
仮想ネットワークでリソースの DNS 名を解決するように Bind を構成するには、/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
};
```
重要

v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net を、別の仮想ネットワークの DNS サフィックスに置き換えます。フォワーダー IP は、他の仮想ネットワーク内の DNS サーバーのプライベート IP アドレスです。

このファイルを編集するには、次のコマンドを使用します。
```
sudo nano /etc/bind/named.conf.local
```
ファイルを保存するには、Ctrl + X キー、Y キー、Enter キーの順に押します。
Bind を起動するには、次のコマンドを使用します。
```
sudo service bind9 restart
```
Bind が他の仮想ネットワーク内のリソース名を解決できることを確認するには、次のコマンドを使用します。
```
sudo apt install dnsutils
nslookup vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net
```
重要

vnet2dns.v5ant3az2hbe1edzthhvwwkcse.bx.internal.cloudapp.net を、他のネットワーク内の DNS 仮想マシンの完全修飾ドメイン名 (FQDN) に置き換えます。

10.2.0.4 を、他の仮想ネットワーク内のカスタム DNS サーバーの 内部 IP アドレス に置き換えます。

次のテキストのような応答が表示されます。
```
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
```
これまでは、DNS サーバーの IP アドレスを指定せずに他のネットワークの IP アドレスを検索することはできませんでした。

カスタム DNS サーバーを使用するように仮想ネットワークを構成する

Azure 再帰リゾルバーではなく、カスタム DNS サーバーを使用するように仮想ネットワークを構成するには、次の手順に従います。

Azure Portal で、仮想ネットワークを選択し、[DNS サーバー] を選択します。
[カスタム] を選択し、カスタム DNS サーバーの 内部 IP アドレス を入力します。最後に、 [保存] を選択します。
vnet1 の DNS サーバー仮想マシンを開き、[再起動] をクリックします。 DNS 構成が有効であることを確認するには、仮想ネットワーク内のすべての仮想マシンを再起動する必要があります。
手順を繰り返して、vnet2 のカスタムの DNS サーバーを構成します。

DNS 構成をテストするには、SSH を使用して 2 つの DNS 仮想マシンに接続し、他の仮想ネットワークの DNS サーバーをそのホスト名を使用して ping します。うまくいかない場合は、次のコマンドを使用して DNS の状態をチェックします。

sudo service bind9 status

Apache HBase クラスターを作成する

2 つの仮想ネットワークのそれぞれに、次の構成の Apache HBase クラスターを作成します。

リソースグループ名: 仮想ネットワークの作成時と同じリソースグループ名を使用します。
クラスターの種類: HBase
バージョン: HBase 1.1.2 (HDI 3.6)
場所: 仮想ネットワークと同じ場所を使用します。既定では、vnet1 は [米国西部]、vnet2 は [米国東部] です。
ストレージ: クラスター用の新しいストレージアカウントを作成します。
仮想ネットワーク(ポータルの [詳細設定]): 最後の手順で作成した vnet1 を選択します。
サブネット: テンプレートで使われる既定の名前は subnet1 です。

環境が正しく構成されていることを確認するには、2 つのクラスター間でヘッドノードの FQDN に ping できる必要があります。

テストデータの読み込み

クラスターをレプリケートする場合は、レプリケートするテーブルを指定する必要があります。このセクションでは、ソースクラスターにデータを読み込みます。次のセクションで、2 つのクラスター間のレプリケーションを有効にします。

Contacts テーブルを作成し、そのテーブルにいくつかデータを挿入するには、HDInsight の Apache HBase を使用する方法に関する Apache HBase チュートリアルの指示に従います。

注意

カスタム名前空間からテーブルをレプリケートする場合は、宛先クラスターでも適切なカスタム名前空間が定義されていることを確認する必要があります。

レプリケーションを有効にする

次の手順は、Azure Portal からスクリプトアクションのスクリプトを呼び出す方法を示しています。 Azure PowerShell と Azure クラシック CLI を使用したスクリプトアクションの実行については、スクリプトアクションを使用して HDInsight クラスターをカスタマイズする方法に関するページを参照してください。

Azure Portal から HBase レプリケーションを有効にするには

Azure portal にサインインします。
ソース HBase クラスターを開きます。
クラスターメニューの [スクリプトアクション] を選択します。
ページの上部にある [新規で送信] を選択します。
次の情報を選択するか入力します。
1. 名前: 「Enable replication」と入力します。
2. バッシュスクリプト URI: 「https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh」と入力します。
3. Head: このパラメーターが選択されていることを確認します。他のノードタイプをオフにします。
4. パラメーター: 次のサンプルパラメーターは、すべての既存のテーブルに対するレプリケーションを有効にし、ソースクラスターからデスティネーションクラスターにすべてのデータをコピーします。
-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password> -copydata

注意

ソースと宛先の両方のクラスター DNS 名に FQDN ではなくホスト名を使用します。

このチュートリアルでは、hn1 をアクティブなヘッドノードと見なしています。クラスターを確認してアクティブなヘッドノードを特定してください。
［作成］ を選択しますこのスクリプトの実行には、少し時間がかかます (特に -copydata 引数を使用する場合)。

必須の引数:

名前	説明
-s, --src-cluster	ソース HBase クラスターの DNS 名を指定します。例: -s hbsrccluster, --src-cluster=hbsrccluster
-d, --dst-cluster	デスティネーション (レプリカ) HBase クラスターの DNS 名を指定します。例: -s dsthbcluster, --src-cluster=dsthbcluster
-sp, --src-ambari-password	ソース HBase クラスターでの Ambari の管理パスワードを指定します。
-dp, --dst-ambari-password	デスティネーション HBase クラスターでの Ambari の管理パスワードを指定します。

省略可能な引数:

名前	説明
-su, --src-ambari-user	ソース HBase クラスターでの Ambari の管理ユーザー名を指定します。既定値は admin です。
-du, --dst-ambari-user	デスティネーション HBase クラスターでの Ambari の管理者ユーザー名を指定します。既定値は admin です。
-t, --table-list	レプリケートされるテーブルを指定します。例: --table-list="table1;table2;table3"。テーブルを指定しない場合は、すべての既存の HBase テーブルがレプリケートされます。
-m, --machine	スクリプトアクションを実行するヘッドノードを指定します。この値は、どちらがアクティブなヘッドノードであるかに基づいて選択する必要があります。このオプションは、HDInsight ポータルまたは Azure PowerShell からスクリプトアクションとして $0 スクリプトを実行する場合に使用します。
-cp, -copydata	レプリケーションが有効になっているテーブルの既存のデータの移行を有効にします。
-rpm, -replicate-phoenix-meta	Phoenix システムテーブルのレプリケーションを有効にします。このオプションは慎重に使用してください。このスクリプトを使用する前に、レプリカクラスターで Phoenix テーブルを再作成しておくことをお勧めします。
-h, --help	使用情報を表示します。

スクリプトの print_usage() セクションに、パラメーターの詳細な説明が用意されています。

スクリプトアクションが正常に実行された後、SSH を使用してデスティネーション HBase クラスターに接続して、データがレプリケートされたことを確認できます。

レプリケーションシナリオ

いくつかの一般的な使用例とそのパラメーターの設定を次に示します。

2 つのクラスター間ですべてのテーブルのレプリケーションを有効にする。このシナリオでは、テーブルの既存のデータのコピー/移行は不要であり、Phoenix テーブルは使用しません。次のパラメーターを使用します。

-m hn1 -s <source hbase cluster name> -d <destination hbase cluster name> -sp <source cluster Ambari password> -dp <destination cluster Ambari password>
特定のテーブルのレプリケーションを有効にする。 table1、table2、および 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"
特定のテーブルのレプリケーションを有効にし、既存のデータをコピーする。 table1、table2、および 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
ソースからデスティネーションに Phoenix メタデータをレプリケートして、すべてのテーブルのレプリケーションを有効にする。 Phoenix メタデータのレプリケーションは完璧ではありません。慎重に使用してください。次のパラメーターを使用します。

-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

ESP クラスター間のレプリケーションを設定する

前提条件

両方の ESP クラスターが同じ領域 (ドメイン) に存在する必要があります。確認するには /etc/krb5.conf ファイルの既定の領域プロパティを確認します。
両方のクラスターへの読み取りと書き込みのアクセス権を持つ共通ユーザーがそこに存在する必要があります
1. たとえば、両方のクラスターに同じクラスター管理者ユーザー (例: admin@abc.example.com) がいる場合、そのユーザーを使用してレプリケーションスクリプトを実行できます。
2. 両方のクラスターで同じユーザーグループを使用している場合は、新しいユーザーを追加するか、グループの既存のユーザーを使用できます。
3. 両方のクラスターで別のユーザーグループを使用している場合は、両方に新しいユーザーを追加するか、グループの既存のユーザーを使用できます。

レプリケーションスクリプトを実行する手順

注意

DNS が宛先クラスターのホスト名を正しく解決できない場合にのみ、次の手順を実行します。

シンククラスターのホスト IP & ソースクラスターノードの /etc/hosts ファイル内のホスト名マッピングをコピーします。
宛先 (シンク) クラスターの /etc/hosts ファイルから、ヘッドノード、ワーカーノード、ZooKeeper ノードのホストと IP マッピングをコピーします。
コピーされたエントリをソースクラスターの /etc/hosts ファイルに追加します。これらのエントリは、ヘッドノード、ワーカーノード、ZooKeeper ノードに追加する必要があります。

手順: 1ktutil を使用して、ユーザーの keytab ファイルを作成します。 $ ktutil

addent -password -p admin@ABC.EXAMPLE.COM -k 1 -e RC4-HMAC
認証のためのパスワードを要求し、ユーザーパスワードを指定します
wkt /etc/security/keytabs/admin.keytab

注意

keytab ファイルが /etc/security/keytabs/ フォルダーに <username>.keytab 形式で格納されていることを確認します。

手順 2-ku オプションを指定してスクリプトアクションを実行します

ESP クラスターで -ku <username> を指定します。

名前	説明
`-ku, --krb-user`	ESP クラスターに対しては、ソースクラスターと宛先クラスターの両方を認証できる共通 Kerberos ユーザー

データのコピーと移行

レプリケーションを有効にした後でデータをコピー/移行するスクリプトアクションのスクリプトは 2 つあります。

小さなテーブル向けのスクリプト (サイズが数ギガバイトであり、全部のコピーが 1 時間以内に完了することが予期されるテーブル)
大きなテーブル向けのスクリプト (コピー時間が 1 時間を超えることが予期されるテーブル)

「レプリケーションを有効にする」と同じ手順でスクリプトアクションを呼び出すことができます。次のパラメーターを使用します。

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

スクリプトの print_usage() セクションに、パラメーターの詳細な説明が用意されています。

シナリオ

特定のテーブル (test1、test2、および test3) の現在のタイムスタンプまでに編集されたすべての行をコピーする:

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

または:

-m hn1 -t "test1::;test2::;test3::" --replication-peer="<zookeepername1>;<zookeepername2>;<zookeepername3>:2181:/hbase-unsecure" -everythingTillNow
特定のテーブルの指定した時間範囲のデータをコピーする:

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

レプリケーションを無効にする

レプリケーションを無効にするには、GitHub にある別のスクリプトアクションのスクリプトを使用します。「レプリケーションを有効にする」と同じ手順でスクリプトアクションを呼び出すことができます。次のパラメーターを使用します。

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

スクリプトの print_usage() セクションに、パラメーターの詳細な説明が用意されています。

シナリオ

すべてのテーブルのレプリケーションを無効にする:

-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>
指定したテーブル (table1、table2、および table3) のレプリケーションを無効にする:

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

注意

宛先クラスターを削除しようとしている場合は、ソースクラスターのピアの一覧から削除するようにしてください。これを行うには、ソースクラスターの hbase シェルでコマンド remove_peer '1' を実行します。これが失敗する場合は、ソースクラスターが正しく機能していない可能性があります。

次のステップ

この記事では、1 つの仮想ネットワーク内または 2 つの仮想ネットワーク間で Apache HBase レプリケーションを設定する方法を説明しました。 HDInsight と Apache HBase の詳細については、以下の記事を参照してください。

次の方法で共有

Azure 仮想ネットワーク内で Apache HBase クラスターのレプリケーションを設定する

前提条件

環境を設定する

2 つの異なるリージョンに 2 つの仮想ネットワークを設定する

DNS をセットアップする

カスタム DNS サーバーを使用するように仮想ネットワークを構成する

Apache HBase クラスターを作成する

テストデータの読み込み

レプリケーションを有効にする

レプリケーションシナリオ

ESP クラスター間のレプリケーションを設定する

データのコピーと移行

シナリオ

レプリケーションを無効にする

シナリオ

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure 仮想ネットワーク内で Apache HBase クラスターのレプリケーションを設定する

前提条件

環境を設定する

2 つの異なるリージョンに 2 つの仮想ネットワークを設定する

DNS をセットアップする

カスタム DNS サーバーを使用するように仮想ネットワークを構成する

Apache HBase クラスターを作成する

テスト データの読み込み

レプリケーションを有効にする

レプリケーション シナリオ

ESP クラスター間のレプリケーションを設定する

データのコピーと移行

シナリオ

レプリケーションを無効にする

シナリオ

次のステップ

フィードバック

その他のリソース

テストデータの読み込み

レプリケーションシナリオ