Edge for Private Cloud v4.18.05
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 ノードを追加しなければならない場合があります。Edge に ZooKeeper ノードを追加する方法は、ZooKeeper ノードの追加に関するドキュメントに記載されています。ZooKeeper ノードを追加する際は、追加するノードのタイプがボーターとオブザーバのどちらであるかを考慮する必要があります。
1 つ以上のボーターノードがダウンしても ZooKeeper アンサンブルが引き続き機能できる（ボーターノードのクォーラムが使用可能である）ように、十分な数のボーターノードを用意してください。ボーターノードを追加するとクォーラムのサイズが大きくなるため、より多くのボーターノードの障害を許容できます。
ただし、ボーターノードを追加すると、書き込みパフォーマンスに悪影響が及ぶ可能性があります。書き込み操作では、クォーラムがリーダーについて合意しなければならないためです。リーダーを決定するのにかかる時間はボーターノードの数に応じるため、ボーターノードを追加すると、決定時間が長くなります。したがって、すべてのノードをボーターにすることはおすすめできません。
ボーターノードを追加する代わりに、オブザーバ ノードを追加できます。オブザーバ ノードを追加すれば、リーダー選出のオーバーヘッドが増えることなく、システム全体の読み取りパフォーマンスが向上します。オブザーバ ノードはリーダー選出に投票しないことから、クォーラム サイズに影響しないためです。したがって、オブザーバ ノードがダウンしても、アンサンブルはリーダーを選出できます。ただし、オブザーバ ノードがダウンするとデータ リクエストを処理するノードの数が少なくなるため、ZooKeeper アンサンブルの読み取りパフォーマンスが低下する場合があります。
単一のデータセンターでは、オブザーバ ノードの数に関係なく、ボーターノードの数を 5 つ以下に抑えることをおすすめします。2 つのデータセンターを使用する場合は、ボーターノードの数を 9 つ（一方のデータセンター内に 5 つ、もう一方のデータセンター内に 4 つ）以下に抑えることをおすすめします。その上で、システム要件に応じて必要な数だけのオブザーバ ノードを追加できます。
メンテナンスに関する考慮事項
ZooKeeper のメンテナンスは完全に機能するアンサンブルで行うことができます。一度に 1 つのノードでメンテナンスを行う場合、ダウンタイムはともないません。常に 1 つの ZooKeeper ノードだけをが停止するようにすれば、リーダーを選出するために使用可能なボーターノードのクォーラムを確保できます。
複数のデータセンターでのメンテナンス
複数のデータセンターを使用する場合、ZooKeeper アンサンブルはデータセンターを区別しないことに注意してください。ZooKeeper グループはすべてのデータセンターのすべての ZooKeeper ノードを 1 つのアンサンブルとしてとらえます。
ZooKeeper がクォーラムを計算する際に、ボーターノードの場所がどのデータセンターかは考慮されません。データセンターで個々のノードがダウンしても、アンサンブル全体でクォーラムが確保されている限り、ZooKeeper は引き続き機能します。
メンテナンスにともなう影響
ボーターノードでもオブザーバ ノードでも、ZooKeeper ノードをメンテナンスのために停止させなければならない状況はさまざまにあります。たとえば、ノード上の Edge のバージョンをアップグレードする必要がある場合、ZooKeeper をホストしているマシンで障害が発生した場合、あるいはネットワーク エラーといった他の理由でノードが使用不可になった場合などです。
停止するノードがオブザーバ ノードであれば、ノードを復元するまで ZooKeeper アンサンブルのパフォーマンスがわずかに低下することが見込まれます。停止するノードがボーターノードの場合は、リーダー選出プロセスに参加するノードを失うことから、ZooKeeper アンサンブルの実行可能性に影響する可能性があります。ボーターノードを停止する理由が何であれ、使用可能なボーターノードのクォーラムを確保することが重要です。
メンテナンス手順
メンテナンス手順は、ZooKeeper アンサンブルが機能することを確認した後に限って行ってください。オブザーバ ノードが機能すること、メンテナンス中にクォーラムを確保できるだけの数のボーターノードがあることが、メンテナス手順を行う前提条件となります。
これらの条件を満たしていれば、ZooKeeper アンサンブルはそのサイズにかかわらず、常に 1 つのノードの損失を許容できるため、データ損失やパフォーマンスへの重大な影響は発生しません。つまり、一度に 1 つのノードを対象とする限り、アンサンブルのどのノードでも自由にメンテナンスを行うことができます。
メンテナンスの一環として、次の手順に従って ZooKeeper ノードのタイプ（リーダー、ボーター、オブザーバ）を判別します。
- nc が ZooKeeper ノードにインストールされていない場合は、次のコマンドを使用してインストールします。
sudo yum install nc
- ノード上で次の nc コマンドを実行します。
echo stat | nc localhost 2181
ここで、2181 は ZooKeeper ポートです。次の形式の出力が表示されます。
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 ノードを基に計算されます。
- メンテナンスを完了したサーバーが運用可能になってから、次のサーバーでメンテナンスを続けます。
- ZooKeeper ノードを調べるには、
ncコマンドを使用します。