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

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 テンプレートが用意されています。 他の方法で環境を設定する場合は、次の記事を参照してください。

• HDInsight で Apache Hadoop クラスターを作成する
• Azure Virtual Network での Apache HBase クラスターの作成

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 を手動でセットアップします

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

DNS をセットアップする

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

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

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

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

1. SSH を使用して、DNS 仮想マシンの パブリック IP アドレス にアクセスします。 次の例では、40.68.254.142 の仮想マシンに接続します。

   ssh sshuser@40.68.254.142
   

   sshuser を、DNS 仮想マシンの作成時に指定した SSH ユーザー アカウントに置き換えます。

   注意

   ssh ユーティリティは、さまざまな方法で取得できます。 Linux、Unix、および macOS では、オペレーティング システムの一部として提供されます。 Windows を使用している場合は、次のオプションのいずれかを検討してください。

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

2. Bind をインストールするには、SSH セッションから次のコマンドを使用します。

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

3. オンプレミスの 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 キーの順に押します。

4. SSH セッションでは、次のコマンドを使用します。

   hostname -f
   

   このコマンドにより、次のテキストのような値が返されます。

   vnet1DNS.icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net
   

   icb0d0thtw0ebifqt0g1jycdxd.ex.internal.cloudapp.net テキストは、この仮想ネットワークの DNS サフィックス です。 この値を保存します。これは後で使用します。

   他の DNS サーバーの DNS サフィックスも見つけておく必要があります。 次の手順で必要になります。

5. 仮想ネットワークでリソースの 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 キーの順に押します。

6. Bind を起動するには、次のコマンドを使用します。

   sudo service bind9 restart
   

7. 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 サーバーを使用するように仮想ネットワークを構成するには、次の手順に従います。

1. Azure Portal で、仮想ネットワークを選択し、[DNS サーバー] を選択します。

2. [カスタム] を選択し、カスタム DNS サーバーの 内部 IP アドレス を入力します。 最後に、 [保存] を選択します。

3. vnet1 の DNS サーバー仮想マシンを開き、[再起動] をクリックします。 DNS 構成が有効であることを確認するには、仮想ネットワーク内のすべての仮想マシンを再起動する必要があります。

4. 手順を繰り返して、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 レプリケーションを有効にするには

1. Azure portal にサインインします。

2. ソース HBase クラスターを開きます。

3. クラスター メニューの [スクリプト アクション] を選択します。

4. ページの上部にある [新規で送信] を選択します。

5. 次の情報を選択するか入力します。

   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 をアクティブなヘッド ノードと見なしています。 クラスターを確認してアクティブなヘッド ノードを特定してください。

6. ［作成］ を選択します このスクリプトの実行には、少し時間がかかます (特に -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 クラスター間のレプリケーションを設定する

前提条件

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

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

注意

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

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

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

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

注意

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

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

1. 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 の詳細については、以下の記事を参照してください。

• HDInsight での Apache HBase の使用
• HDInsight Apache HBase の概要
• Azure Virtual Network での Apache HBase クラスターの作成