ZooKeeper アンサンブルは、1 つ以上の ZooKeeper ノードが失われても、データが失われることなく機能し続けるように設計されています。この復元力を効果的に利用すると、システムのダウンタイムなしで ZooKeeper ノードのメンテナンスを行うことができます。
ZooKeeper と Edge について
Edge では、ZooKeeper ノードにさまざまな Edge コンポーネントの場所と構成に関する構成データを格納し、各コンポーネントに構成の変更を通知します。本番環境システムでサポートされているすべての Edge トポロジでは、少なくとも 3 つの ZooKeeper ノードを使用します。
Edge 構成ファイルの ZK_HOSTS
プロパティと ZK_CLIENT_HOSTS
プロパティを使用して、ZooKeeper ノードを指定します。例:
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 のリーダーの選出に参加します。:observer
修飾子を ZK_HOSTS
とともに使用すると、そのノードがボーターではなくオブザーバー ノードであることを示すことができます。オブザーバー ノードはリーダーの選出に参加しません。
通常、複数の 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 インストールでは、いずれかのノードが「リーダー」に指定されます。他のすべての ZooKeeper ノードは「フォロワー」として指定されます。読み取りはどの ZooKeeper ノードからも行えますが、すべての書き込みリクエストはリーダーに転送されます。たとえば、新しい Message Processor が Edge に追加されたとします。この情報は ZooKeeper リーダーに書き込まれます。その後、すべてのフォロワーがデータを複製します。
Edge のインストール時に、各 ZooKeeper ノードをボーターまたはオブザーバーとして指定します。リーダーがすべてのボーター ZooKeeper ノードによって選出されます。リーダーを選出するための要件の 1 つは、機能する ZooKeeper ボーターノードが利用可能なクォーラムquorumがあることです。クォーラムとは、すべてのデータセンターでボーター ZooKeeper ノードの半分以上が機能することを意味します。
ボーターノードのクォーラムが利用できない場合は、リーダーを選出できません。このシナリオでは、ZooKeeper はリクエストを処理できません。つまり、再びクォーラムに達するまで、Edge Management Server に対してリクエストを行うことも、Management 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 以下にすることをおすすめします(1 つのデータセンターに 5 つ、もう 1 つのデータセンターに 4 つ)。その後、システム要件に必要な数のオブザーバー ノードを追加できます。
Zookeeper ノードの削除
Zookeeper ノードの削除が必要な理由は数多くあります。たとえば、ノードが破損した、ノードが誤った環境に追加されたなど、さまざまです。
このセクションでは、ノードが停止してアクセスできない場合に Zookeeper ノードを削除する方法について説明します。
Zookeeper ノードを削除するには:
- サイレント構成ファイルを編集し、削除する Zookeeper ノードの IP アドレスを削除します。
- Zookeeper の
setup
コマンドを再実行して、残りの ZooKeeper ノードを再構成します。/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper setup -f updated_config_file
- すべての Zookeeper ノードを再起動します。
/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper restart
- 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
- すべての 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
- すべての 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
- すべての 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
- すべての 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 ノードのタイプ(リーダー、ボーター、オブザーバ)を決定します。
- ZooKeeper ノードにインストールされていない場合は、
nc
をインストールします。sudo yum install nc
- ノードで次の
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
(リーダーではないボーター)のいずれかが表示されます。 - 各 ZooKeeper ノードで手順 1 と 2 を繰り返します。
概要
ZooKeeper アンサンブルのメンテナンスを行う最善の方法は、一度に 1 つのノードを実行することです。注意:
- ZooKeeper アンサンブルが引き続き機能するように、メンテナンス中にボーターノードのクォーラムを維持する必要があります。
- オブザーバー ノードを停止しても、クォーラムやリーダーの選出機能に影響はありません。
- クォーラムは、すべてのデータセンターのすべての ZooKeeper ノードで計算されます。
- 前のサーバーが動作可能になったら、次のサーバーにメンテナンスを進める。
nc
コマンドを使用して、ZooKeeper ノードを検査します。