標準のアクティブ/パッシブ構成のデータセンターからマルチリージョンストレッチクラスターへの移行

Confluent Platform には、複数のリージョンにまたがるクラスターの作成と管理に役立つさまざまな テクノロジーアーキテクチャ が用意されています。このチュートリアルでは、2 つのリージョンにまたがる従来型のアクティブ/パッシブ構成のデータセンターアーキテクチャをマルチリージョンストレッチクラスターに移行する方法について説明します。マルチリージョンストレッチクラスターでは、Multi-Region Clusters のフォロワーフェッチ、オブザーバー、レプリカ配置を利用できます。

チュートリアルの内容

このチュートリアルでは、リージョン間の同期に Replicator を使用する既存のアクティブ/パッシブ構成のクラスターを マルチリージョン ストレッチクラスターに移行する方法を説明します。Replicator は、ストレッチクラスターには必要ありません。ストレッチクラスターは実質的に、複数のリージョンにまたがって実行される単一のクラスターであるためです。

クライアントおよびレプリケーションの一時停止、クラスターの再構成、新しいクラスターのオンラインへの復帰について、さまざまなベストプラクティスおよび操作手順の説明が記載されています。ただし、コマンドおよび構成に関する詳細なガイダンスは含まれていません。これらの詳細情報については、「Multi-Region Clusters」および「チュートリアル: マルチリージョンクラスター」を参照してください。

まず、パッシブクラスターのリソースを解放することから始めます。すべてのコンシューマー、プロデューサーを一時停止し、レプリケーションを中止します。次に、解放したリソースを利用して、元のアクティブクラスターを実質的に拡張します。その過程でクラスターの構成を、「Multi-Region Clusters」に記載されている機能や特性を備えるマルチリージョンクラスターに変更します。

マルチリージョンクラスターへの移行を成功させるには、新しい環境で確実にすべてを正常に機能させるだけでなく、想定外の状況によりなんらかの問題が発生した場合に復旧する方法を用意することも重要です。そのため、ステップごとに ロールバック のセクションがあり、問題が発生した場合に以前の状態にロールバックする方法が記載されています。ロールバックは、問題が発生した場合にのみ実行し、そうでない場合にはこの手順は実行しないようにしてください。

移行前と移行後のアーキテクチャ

開始時点では、Replicator を使用して複数のクラスター間のデータを同期する 2 リージョンのアクティブ/パッシブアーキテクチャ であるものとします。

../_images/multi-dc-active-passive-before-mrc.ja.png

データセンター移行後の最終的な状態は、ストレッチ 2.5 リージョンのアクティブ/パッシブストレッチアーキテクチャ を使用する、マルチリージョンでラック認識のクラスターです。これは、マルチリージョンクラスターのチュートリアルの例 で示されていて、こちらの全体チュートリアル のデモで示されているのと同様の環境です。新しいデータセンター環境では、データの同期に Replicator が必要ではなくなります。

../_images/multi-region-topic-replicas.ja.png

以下の手順では、これらのデータセンター(DC)を使って説明します。

  • West(元のパッシブの DC)
  • East(元のアクティブの DC)
  • Central(新しいマルチリージョン構成の一部として追加された、新しいタイブレーカーの ZooKeeper DC)

前提条件

この手順の前提条件は次のとおりです。

  • アクティブ/パッシブ構成の 2 つの Confluent Platform クラスター
  • Confluent Enterprise バージョン 6.0.0 以降
  • 軽量の ZooKeeper ノードの役割のみを果たす追加のノード 1 つ
  • すべてのインスタンス間のネットワークレイテンシが 50 ミリ秒以内であること

このチュートリアルでは、$CONFLUENT_HOME を参照しています。これは Confluent Platform インストールディレクトリ内の etc/kafka を表しています。このパスを環境変数に設定するには、次の例のようにします。

export CONFLUENT_HOME=$HOME/confluent-7.1.1
PATH=$CONFLUENT_HOME/bin:$PATH

ステップ 1. すべてのコンシューマーとプロデューサーを一時停止する

すべてのコンシューマーとプロデューサーが一時停止されると、クラスター内のデータフローがなくなります。

データフローが存在する可能性のあるコンポーネントは次のとおりです。

  • ksqlDB クエリー
  • コネクター
  • アプリケーションプロデューサー
  • アプリケーションコンシューマー

ステップ 2. レプリケーションを一時停止する

  1. Replicator のコンシューマーラグが 0 であることを確認します。

    これは、すべてが同期されていることを確認するためです。プロデューサーとコンシューマーがオンラインの場合には、8 時間の許容範囲内でデータフローが停止されないため、この同期は不可能です。

  2. レプリケーションを停止します。

ちなみに

Multi-Region Clusters の環境では、Replicator は不要になります。

ロールバックする場合: Replicator を再開します。

ステップ 3. ZooKeeper ノード(Central DC)に Confluent Platform をインストールする

  • 後の手順で起動できるように、Confluent Platform パッケージとプロパティファイルを用意しておきます。

ロールバックする場合: タイブレーカーノードから ZooKeeper パッケージとプロパティファイルを削除します。

ステップ 4. DC West コンポーネントを正常に停止させる

DC West 環境(元のパッシブクラスター)上のすべてを、以下の順番で停止します。これらは削除しないでください。

  • ブローカー
  • ZooKeeper

ロールバックする場合: 上記のコンポーネントをすべて再起動します。

ステップ 5. DC West の既存のブローカーおよび ZooKeeper のデータディレクトリと log4j のバックアップを作成する

データディレクトリと log4j ログのバックアップコピーを作成します。

  1. data.dir ファイルを別の場所にコピーします。
  2. log4j のログを別の場所にコピーします。

ロールバックする場合: コピーしたファイルを削除します(ロールバックのアクションは必要ありません)。

ステップ 6. DC West のブローカーおよび ZooKeeper の Datadir フォルダーと log4j のログフォルダーを削除する

ZooKeeper とブローカーを新たに起動するため、これらのデータを削除します。

  • ZooKeeper のデータを削除します
  • ブローカーのデータを削除します

ちなみに

East DC ではこれら(拡張するクラスター)を削除しません。

ロールバックする場合: ステップ 4 で作成したバックアップファイルをコピーして、元の場所に貼り付けます。

ステップ 7. DC West と DC East のすべてのコンポーネントのプロパティファイルのバックアップを作成する

以下のコンポーネントについて、プロパティファイルのバックアップを作成します。

  • West の ZooKeeper
  • West のブローカー
  • East の ZooKeeper
  • East のブローカー

ロールバックする場合: コピーしたファイルを削除します(ロールバックのアクションは必要ありません)。

ステップ 8. 両方の環境のすべてのプロパティファイルを Multi-Region Clusters の構成に変更する

以下のコンポーネントについて、プロパティファイルに変更を加えます。

ブローカー(2 つのフィールドを追加し、1 つのフィールドを変更)

ブローカーのプロパティファイル($CONFLUENT_HOME/etc/kafka/server.properties のファイルなど)に以下の変更を加えます。

replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector
broker.rack=<region>
zookeeper.connect <- this should now include the new zookeepers

ZooKeeper

ZooKeeper のすべてのプロパティにターゲットのクォーラムがあることを確認しますたとえば、$CONFLUENT_HOME/etc/kafka/zookeeper.properties を更新します)。

server.<your-id-on-east-1>=<your-east-1>:2888:3888
server.<your-id-on-east-2>=<your-east-2>:2888:3888
server.<your-id-on-gtdc>=<your-gtdc-host>:2888:3888
server.<your-id-on-west-1>=<your-west-1-host>:2888:3888
server.<your-id-on-west-2>=<your-west-2-host>:2888:3888

ロールバックのオプション: ステップ 6 で作成したバックアップファイルをコピーして、元の場所に貼り付けます。

ステップ 9. East DC の 1 つの ZooKeeper をシャットダウンする

1 つの ZooKeeper を East DC に移動させる必要があります。そのため、1 つの ZooKeeper をシャットダウンして、新しい Central DC(タイブレーカー)に移動します。

ロールバックする場合: 対象の East の ZooKeeper を以前のプロパティで再起動します。

ステップ 10. Central DC(タイブレーカー)で 1 つの ZooKeeper を起動する

クラスターの正常な実行状態を維持するため、新しい Central DC で、Multi-Region Clusters の構成を使用して 1 つの ZooKeeper を起動します。次に、East DC の 2 つの ZooKeeper インスタンスのローリング再起動を実行します。

重要

この段階で、以下のように 3 つすべての ZooKeeper のすべての情報がそれぞれの zookeeper.properties ファイルに設定された状態で、各 ZooKeeper が再起動されています。

server.<your-id-on-east-1>=<your-east-1>:2888:3888
server.<your-id-on-east-2>=<your-east-2>:2888:3888
server.<your-id-on-gtdc>=<your-gtdc-host>:2888:3888

ZooKeeper はお互いの情報がないとクラスターに参加しません。そのため、それぞれの ZooKeeper プロパティファイルの情報が一致している必要があります。

ロールバックする場合: この ZooKeeper を正常にシャットダウンさせます。

ステップ 11. West DC で 2 つの ZooKeeper を起動する

West のサーバー 1、2 で 2 つの ZooKeeper インスタンスを起動します。その後、すべての ZooKeeper の情報を含む更新済みの構成を使用して、先ほどの 3 つすべての ZooKeeper インスタンスのローリング再起動を実行します。

それぞれの zookeeper.properties ファイルにこのような構成が含まれている必要があります。

server.<your-id-on-east-1>=<your-east-1>:2888:3888
server.<your-id-on-east-2>=<your-east-2>:2888:3888
server.<your-id-on-gtdc>=<your-gtdc-host>:2888:3888
server.<your-id-on-west-1>=<your-west-1-host>:2888:3888
server.<your-id-on-west-2>=<your-west-2-host>:2888:3888

ロールバックする場合: これら 2 つの ZooKeeper を正常にシャットダウンさせます。

ステップ 12. West DC で 4 つのブローカーを起動する

West のサーバー 1 ~ 4 で 4 つのブローカーを起動します。

これまで正常に機能していたプロパティはすべてそのまま維持し、以下の構成のみを変更します。

replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector
broker.rack=<region>
zookeeper.connect <- this should now include the new Zookeepers
broker.id <- this has to be unique since you are adding new brokers.

ロールバックする場合: これらのブローカーを正常にシャットダウンさせます。

ステップ 13. East DC のブローカーのローリング再起動を実行する

これらのプロパティを更新して、既存の East DC のブローカーを再起動します。

replica.selector.class=org.apache.kafka.common.replica.RackAwareReplicaSelector
broker.rack=<region>
zookeeper.connect <- this should now include the new Zookeepers

これらのブローカーの broker.id は変更しないよう注意してください。これらはそのままにする必要があります。

ロールバックする場合: プロパティを変更して元の構成に戻し、ローリング再起動を実行します。

ステップ 16. すべてのコンポーネントが正常に機能することを確認する

ZooKeeper のログをチェックして、すべて正常に実行されていることを確認します。

ステップ 17. Multi-Region Clusters の機能を使用するようにトピックの構成に変更を加える

マルチリージョンの機能を使用するようにトピックの構成に変更を加える方法については、マルチリージョンクラスターのチュートリアルの「レプリカ配置」に記載されている例を参照してください。

ステップ 18. クラスターのバランス調整を行う

confluent-rebalancer ツール を使用し、以前の配置に基づいてクラスターのバランス調整を開始するか、または Self-Balancing Clusters を有効にします(Confluent Platform 6.0.0 以降のクラスターの場合)。

ステップ 19: コンシューマーアプリケーションをアップデートする

最後に、追加のプロパティ client.rack を使用してコンシューマーアプリケーションを徐々にアップデートすることができます。