Azure の 1 つの仮想ネットワーク内または 2 つの仮想ネットワーク間で Apache HBase レプリケーションを設定する方法について説明します。
クラスターのレプリケーションでは、ソース プッシュの手法が使用されます。 HBase クラスターは、ソースまたはターゲットになることも、両方のロールを同時に満たすこともできます。 レプリケーションは非同期です。 レプリケーションの目的は、最終的な一貫性です。 レプリケーションが有効になっているときに列ファミリに対する編集をソースが受け取ると、その編集はすべての宛先クラスターに伝達されます。 クラスター間でデータがレプリケートされるときは、レプリケーション ループを防止するために、ソース クラスターとそのデータの使用を既に完了しているすべてのクラスターが追跡されます。
この記事では、ソースとターゲット間のレプリケーションを設定します。 他のクラスター トポロジについては、Apache HBase のリファレンス ガイドを参照してください。
次に示すのは、単一の仮想ネットワークでの HBase レプリケーションの使用例です。
- 負荷分散。 たとえば、宛先クラスターでスキャンや MapReduce ジョブを実行し、ソース クラスターでデータを取り込みます。
- 高可用性の追加。
- HBase クラスター間のデータの移行。
- Azure HDInsight クラスターのバージョンのアップグレード。
次に示すのは、2 つの仮想ネットワーク間での HBase レプリケーションの使用例です。
- ディザスター リカバリーの設定。
- アプリケーションの負荷分散とパーティション分割。
- 高可用性の追加。
クラスターは、GitHub のスクリプト アクションのスクリプトを使用してレプリケートできます。
前提条件
この記事を開始する前に、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 接続を作成するテンプレートを使用するには、次の [Azure へのデプロイ] ボタンを選択します。
テンプレートには、一部の値がハードコーディングされています。それらの値を次に示します。
VNet 1
| プロパティ | 値 | 
|---|---|
| 場所 | 米国西部 | 
| VNet の名前 | <ClusterNamePrevix>-vnet1 | 
| アドレス空間プレフィックス | 10.1.0.0/16 | 
| サブネット名 | サブネット 1 | 
| サブネットのプレフィックス | 10.1.0.0/24 | 
| サブネット (ゲートウェイ) 名 | GatewaySubnet (変更不可) | 
| サブネット (ゲートウェイ) プレフィックス | 10.1.255.0/27 | 
| ゲートウェイ名 | vnet1gw | 
| ゲートウェイの種類 | VPN (バーチャルプライベートネットワーク) | 
| ゲートウェイ VPN の種類 | ルートベース | 
| ゲートウェイ SKU | ベーシック | 
| ゲートウェイの IP | vnet1gwip | 
VNet 2
| プロパティ | 値 | 
|---|---|
| 場所 | 米国東部 | 
| VNet の名前 | <ClusterNamePrevix>-vnet2 | 
| アドレス空間プレフィックス | 10.2.0.0/16 | 
| サブネット名 | サブネット 1 | 
| サブネットのプレフィックス | 10.2.0.0/24 | 
| サブネット (ゲートウェイ) 名 | GatewaySubnet (変更不可) | 
| サブネット (ゲートウェイ) プレフィックス | 10.2.255.0/27 | 
| ゲートウェイ名 | vnet2gw | 
| ゲートウェイの種類 | VPN (バーチャルプライベートネットワーク) | 
| ゲートウェイ VPN の種類 | ルートベース | 
| ゲートウェイ SKU | ベーシック | 
| ゲートウェイの 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 クラスターを開きます。 
- クラスター メニューの [スクリプト アクション] を選択します。 
- ページの上部にある [新規で送信] を選択します。 
- 次の情報を選択するか入力します。 - 名前: 「Enable replication」と入力します。
- Bash スクリプト URL: 「https://raw.githubusercontent.com/Azure/hbase-utils/master/replication/hdi_enable_replication.sh」と入力します。
- Head: このパラメーターが選択されていることを確認します。 他のノード タイプをオフにします。
- パラメーター: 次のサンプル パラメーターは、すべての既存のテーブルに対するレプリケーションを有効にし、ソース クラスターから宛先クラスターにすべてのデータをコピーします。
 - -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ファイルの既定の領域プロパティを確認します。
- 両方のクラスターへの読み取りと書き込みのアクセス権を持つ共通ユーザーがそこに存在する必要があります- たとえば、両方のクラスターに同じクラスター管理者ユーザー (例: admin@abc.example.com) がいる場合、そのユーザーを使用してレプリケーション スクリプトを実行できます。
- 両方のクラスターで同じユーザー グループを使用している場合は、新しいユーザーを追加するか、グループの既存のユーザーを使用できます。
- 両方のクラスターで異なるユーザー グループを使用している場合は、両方に新しいユーザーを追加するか、グループの既存のユーザーを使用できます。
 
- たとえば、両方のクラスターに同じクラスター管理者ユーザー (例: 
レプリケーション スクリプトを実行する手順
注
DNS が宛先クラスターのホスト名を正しく解決できない場合にのみ、次の手順を実行します。
- シンク クラスターのホスト IP & ソース クラスター ノードの /etc/hosts ファイル内のホスト名マッピングをコピーします。
- 宛先 (シンク) クラスターの /etc/hosts ファイルから、ヘッド ノード、ワーカー ノード、ZooKeeper ノードのホストと IP マッピングをコピーします。
- コピーされたエントリをソース クラスターの /etc/hosts ファイルに追加します。 これらのエントリは、ヘッド ノード、ワーカー ノード、ZooKeeper ノードに追加する必要があります。
              手順 1:ktutil を使用して、ユーザーの 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- または - --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 へのデプロイ] ボタン](media/apache-hbase-replication/hdi-deploy-to-azure1.png)