ZooKeeper のメンテナンスについて

ZooKeeper アンサンブルは、1 つ以上の ZooKeeper ノードがダウンしても引き続き機能してデータ損失を回避するように設計されています。この復元力を効果的に利用すると、システム ダウンタイムなしで ZooKeeper ノードをメンテナンスできます。

ZooKeeper と Edge について

Edge では、ZooKeeper ノードが各種 Edge コンポーネントの場所と構成に関する構成データを保持し、さまざまなコンポーネントに構成の変更を通知します。本番環境システム用にサポートされているすべての Edge トポロジには、少なくとも 3 つの ZooKeeper ノードがあります。

ZooKeeper ノードを指定するには、Edge 構成ファイル内の ZK_HOSTS プロパティと ZK_CLIENT_HOSTS プロパティを使用します。次に例を示します。

ZK_HOSTS="$IP1 $IP2 $IP3"
ZK_CLIENT_HOSTS="$IP1 $IP2 $IP3"

ここで

• ZK_HOSTS には、ZooKeeper ノードの IP アドレスを指定します。すべての ZooKeeper ノードで、IP アドレスを同じ順序で列挙する必要があります。

  マルチ データセンター環境では、すべてのデータセンターのすべての ZooKeeper ノードを列挙します。

• ZK_CLIENT_HOSTS には、このデータセンターのみで使用される ZooKeeper ノードの IP アドレスを指定します。同じデータセンター内のすべての ZooKeeper ノードで、IP アドレスを同じ順序で列挙する必要があります。

  単一データセンター環境では、これらは ZK_HOSTS で指定したのと同じノードになります。マルチ データセンター環境では、各データセンターの Edge 構成ファイルで、そのデータセンターに属する ZooKeeper ノードのみを列挙します。

デフォルトでは、すべての ZooKeeper ノードは「ボーター」ノードとして指定されます。これは、すべてのノードが ZooKeeper の「リーダー」の選出に参加することを意味します。ZK_HOSTS で :observer 修飾子を付けて、そのノードがボーターではなく「オブザーバ」ノードであることを指定できます。オブザーバ ノードはリーダーの選出に参加しません。

複数の Edge データセンターを作成する場合、または単一のデータセンターに多数の ZooKeeper ノードがある場合は、通常 :observer 修飾子を指定します。たとえば、2 つのデータセンターからなる 12 ホストの Edge インストール構成で、データセンター 2 のノード 9 にある ZooKeeper がオブザーバであるとします。

この場合、データセンター 1 の構成ファイルでは次のように設定します。

ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer"
ZK_CLIENT_HOSTS="$IP1 $IP2 $IP3"

データセンター 2 では次のように設定します。

ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer"
ZK_CLIENT_HOSTS="$IP7 $IP8 $IP9"

以降のセクションで、リーダー、ボーター、オブザーバの各ノードについて詳しく説明し、ボーターノードとオブザーバ ノードの追加に関する考慮事項を示します。

リーダー、フォロワー、ボーター、オブザーバについて

マルチノード ZooKeeper 構成では、いずれか 1 つのノードが「リーダー」に指名されます。その他すべての ZooKeeper ノードは「フォロワー」になります。読み取りはどの ZooKeeper ノードからでも発生する可能性がありますが、すべての書き込みリクエストは常にリーダーに転送されます。たとえば、新しい Message Processor が Edge に追加されたとします。この情報は ZooKeeper リーダーに書き込まれます。その後、すべてのフォロワーがこのデータを複製します。

Edge のインストール時に、各 ZooKeeper ノードをボーターまたはオブザーバとして指定します。その後、ボーターとして指定されたすべての ZooKeeper ノードによってリーダーが選出されます。リーダー選出の要件の 1 つとして、機能する ZooKeeper ボーターノードの数が「クォーラム」（定数）に達していなければならないことがあります。クォーラムとは、すべてのデータセンターですべてのボーター ZooKeeper ノードの半数以上が機能していることを意味します。

ボーターノードのクォーラムが使用可能でない場合、リーダーは選出できません。このシナリオでは、ZooKeeper はリクエストを処理できません。つまり、再びクォーラムに達するまで、Edge Management Server に対してリクエストを行うことも、API リクエストを処理することも、Edge UI にログインすることもできません。

たとえば、単一データセンター環境では次のようになります。

• 3 つの ZooKeeper ノードをインストールしました。
• すべての ZooKeeper ノードがボーターです。
• クォーラムは「2 つの機能するボーターノード」になります。
• 使用可能なボーターノードが 1 つしかない場合、ZooKeeper アンサンブルは機能しません。

2 つのデータセンターのインストールでは次のようになります。

• データセンターごとに 3 つの ZooKeeper ノードをインストールしました。したがって、ノードの合計は 6 つです。
• データセンター 1 には 3 つのボーターノードがあります。
• データセンター 2 には 2 つのボーターノードと 1 つのオブザーバ ノードがあります。
• クォーラムは両方のデータセンターの計 5 つのボーターに基づくため、クォーラムは「3 つの機能するボーターノード」になります。
• 使用可能なボーターノードが 2 つ以下の場合、ZooKeeper アンサンブルは機能しません。

ボーターノードまたはオブザーバ ノードの追加に関する考慮事項

システム要件によっては、Edge インストール環境にさらに ZooKeeper ノードを追加しなければならない場合があります。ZooKeeper ノードを Edge に追加する方法については、ZooKeeper ノードの追加のドキュメントをご覧ください。ZooKeeper ノードを追加する際は、追加するノードのタイプをボーターとオブザーバのどちらにするかを検討する必要があります。

1 つ以上のボーターノードがダウンしても ZooKeeper アンサンブルが引き続き機能できる（ボーターノードのクォーラムが満たされる）ように、十分な数のボーターノードを用意してください。ボーターノードを追加するとクォーラムのサイズが大きくなるため、より多くのボーターノードの障害を許容できます。

ただし、ボーターノードを追加すると、書き込みパフォーマンスに悪影響が及ぶ可能性があります。書き込みオペレーションでは、クォーラムがリーダーについて合意しなければならないためです。リーダーの決定に要する時間はボーターノードの数によって変わり、ボーターノードを追加するとその時間が長くなります。したがって、すべてのノードをボーターにすることはおすすめできません。

ボーターノードを追加する代わりに、オブザーバ ノードを追加できます。オブザーバ ノードを追加すれば、リーダー選出のオーバーヘッドが増えることなく、システム全体の読み取りパフォーマンスが向上します。オブザーバ ノードはリーダー選出に投票しないことから、クォーラム サイズに影響しないためです。したがって、オブザーバ ノードがダウンしても、アンサンブルはリーダーを選出できます。ただし、オブザーバ ノードがダウンするとデータ リクエストを処理するノードの数が少なくなるため、ZooKeeper アンサンブルの読み取りパフォーマンスが低下する場合があります。

単一のデータセンターでは、オブザーバ ノードの数に関係なく、ボーターノードの数を 5 つ以下に抑えることをおすすめします。2 つのデータセンターを使用する場合は、ボーターノードの数を 9 つ（一方のデータセンター内に 5 つ、もう一方のデータセンター内に 4 つ）以下に抑えることをおすすめします。そのうえで、システム要件に応じて必要な数のオブザーバ ノードを追加できます。

ZooKeeper ノードの削除

ノードが破損した場合や間違った環境に追加された場合など、ZooKeeper ノードの削除が必要な理由は数多くあります。

このセクションでは、ダウンしていて到達できない ZooKeeper ノードを削除する方法について説明します。

ZooKeeper ノードを削除するには:

1. サイレント構成ファイルを編集し、削除する ZooKeeper ノードの IP アドレスを削除します。
2. ZooKeeper の setup コマンドを再度実行し、残りの ZooKeeper ノードを再構成します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper setup -f updated_config_file

3. すべての ZooKeeper ノードを再起動します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper restart

4. Management Server ノードを再構成します。

   /opt/apigee/apigee-service/bin/apigee-service edge-management-server setup -f updated_config_file
   /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart

5. すべての Router を再構成します。

   /opt/apigee/apigee-service/bin/apigee-service edge-router setup -f updated_config_file
   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

6. すべての Message Processor を再構成します。

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor setup -f updated_config_file
   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

7. すべての Qpid ノードを再構成します。

   /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server setup -f updated_config_file
   /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart

8. すべての Postgres ノードを再構成します。

   /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server setup -f updated_config_file
   /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

メンテナンスに関する考慮事項

完全に機能するアンサンブルに対して ZooKeeper のメンテナンスを行うことができます。一度に 1 ノードずつ行えば、ダウンタイムは発生しません。一度に 1 つの ZooKeeper ノードのみを停止させることで、リーダーの選出に使用可能なボーターノードのクォーラムを確保できます。

複数のデータセンターでのメンテナンス

複数のデータセンターを使用する場合、ZooKeeper アンサンブルはデータセンターを区別しないことに注意してください。ZooKeeper グループはすべてのデータセンターのすべての ZooKeeper ノードを 1 つのアンサンブルとしてとらえます。

ZooKeeper がクォーラムを計算する際に、ボーターノードの場所がどのデータセンターかは考慮されません。複数のデータセンターで個々のノードがダウンしても、アンサンブル全体でクォーラムが確保されている限り、ZooKeeper は引き続き機能します。

メンテナンスに伴う影響

ボーターノードでもオブザーバ ノードでも、ZooKeeper ノードをメンテナンスのために停止させなければならない状況はさまざまにあります。たとえば、ノード上の Edge のバージョンをアップグレードする場合、ZooKeeper をホストしているマシンで障害が発生した場合、ネットワーク エラーなどの他の理由でそのノードが使用できなくなった場合などが挙げられます。

停止するノードがオブザーバ ノードの場合は、そのノードを復帰させるまでの間、ZooKeeper アンサンブルのパフォーマンスがわずかに低下することが予想されます。停止するノードがボーターノードの場合は、リーダー選出プロセスに参加するノードが失われるため、ZooKeeper アンサンブルの実行可能性に影響する可能性があります。ボーターノードを停止する理由が何であれ、使用可能なボーターノードのクォーラムを確保することが重要です。

メンテナンス手順

メンテナンス手順は必ず、ZooKeeper アンサンブルが機能することを確認してから実施してください。オブザーバ ノードが機能することと、メンテナンス中にクォーラムを確保できるだけの数のボーターノードがあることが、手順の前提条件となります。

これらの条件を満たしていれば、ZooKeeper アンサンブルは、そのサイズに関係なく、データ損失やパフォーマンスへの重大な影響なしに一度に 1 つのノードの損失を許容できます。つまり、一度に 1 つのノードを対象とする限り、アンサンブルのどのノードでも自由にメンテナンスを行うことができます。

メンテナンスの一環として、次の手順に従って ZooKeeper ノードのタイプ（リーダー、ボーター、オブザーバ）を判別します。

1. nc が ZooKeeper ノードにインストールされていない場合は、次のコマンドを使用してインストールします。

   sudo yum install nc

2. ノードで次の nc コマンドを実行します。ここで、2181 は ZooKeeper ポートです。

   echo stat | nc localhost 2181

   次のような出力が返されます。

   Zookeeper version: 3.4.5-1392090,
   built on 09/30/2012 17:52 GMT
   Clients: /a.b.c.d:xxxx[0](queued=0,recved=1,sent=0)
   Latency min/avg/max: 0/0/0
   Received: 1
   Sent: 0
   Connections: 1
   Outstanding: 0
   Zxid: 0xc00000044
   Mode: follower
   Node count: 653

   出力の Mode 行に、そのノードの構成に応じて observer、leader、follower（リーダーではないボーター）のいずれかが表示されます。

3. ZooKeeper ノードごとにステップ 1 と 2 を繰り返します。

概要

ZooKeeper アンサンブルでの最適なメンテナンス方法は、一度に 1 つのノードでメンテナンスを行うことです。次の点に注意してください。

• ZooKeeper アンサンブルを機能させ続けるには、メンテナンス中にボーターノードのクォーラムを確保する必要があります。
• オブザーバ ノードを停止しても、クォーラムまたはリーダー選出機能には影響しません。
• クォーラムは、すべてのデータセンター内のすべての ZooKeeper ノードを基に計算されます。
• メンテナンスが完了したサーバーを運用に復帰させてから、次のサーバーのメンテナンスに移ります。
• ZooKeeper ノードを調べるには、nc コマンドを使用します。