Edge for Private Cloud v. 4.17.09
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 アドレスを指定します。IP アドレスは、すべての ZooKeeper ノードで同じ順序でリストする必要があります。
マルチデータセンター環境では、すべてのデータセンターのすべての ZooKeeper ノードを一覧表示します。 - ZK_CLIENT_HOSTS - このデータセンターでのみ使用される ZooKeeper ノードの IP アドレスを指定します。IP アドレスは、データセンター内のすべての ZooKeeper ノードで同じ順序でリストする必要があります。
単一のデータセンターのインストールでは、これらは ZK_HOSTS で指定されたノードと同じです。マルチデータ センター環境では、各データ センターの Edge 構成ファイルに、そのデータ センターの ZooKeeper ノードのみをリストする必要があります。
デフォルトでは、すべての ZooKeeper ノードがボーターノードとして指定されます。つまり、すべてのノードが ZooKeeper リーダーの選出に参加します。ZK_HOSTS に「:observer」修飾子を追加すると、そのノードが投票者ではなくオブザーバー ノードであることを示すことができます。オブザーバー ノードはリーダーの選出に参加しません。
通常、「:observer」修飾子は、複数の Edge データセンターを作成する場合や、1 つのデータセンターに多数の ZooKeeper ノードがある場合に指定します。たとえば、2 つのデータセンターがある 12 ホストの Edge インストールでは、データセンター 2 のノード 9 の ZooKeeper がオブザーバーになります。
次に、データセンター 1 の構成ファイルで次の設定を使用します。
ZK_HOSTS="$IP1 $IP2 $IP3 $IP7 $IP8 $IP9:observer" ZK_CLIENT_HOSTS="$IP1 $IP2 $IP3"
データセンター
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 ノードによって選出されます。リーダーの選出に必要な要件は、機能している ZooKeeper ボーターノードのクォーラムが利用可能であることです。クォーラムとは、すべてのデータセンターにわたるすべてのボーター 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 のメンテナンスは、一度に 1 つのノードで実行すれば、完全に機能するアンサンブルでダウンタイムなしで実行できます。一度に 1 つの ZooKeeper ノードのみがダウンするようにすることで、リーダーを選出するために使用できるボーターノードのクォーラムが常に存在するようにできます。
複数のデータセンターでのメンテナンス
複数のデータセンターを使用する場合、ZooKeeper アンサンブルはデータセンターを区別しません。ZooKeeper アセンブリは、すべてのデータセンターのすべての ZooKeeper ノードを 1 つのアンサンブルとして表示します。
ZooKeeper がクォーラムを計算する際、特定のデータセンター内のボーターノードの場所は考慮されません。個々のノードがデータセンター間でダウンする可能性がありますが、アンサンブル全体でクォーラムが維持されている限り、ZooKeeper は機能し続けます。
メンテナンスに伴う影響
ZooKeeper ノード（ボーターノードまたはオブザーバー ノード）をメンテナンスのために停止しなければならない場合があります。たとえば、ノード上の Edge のバージョンをアップグレードする必要がある場合、ZooKeeper をホストしているマシンが失敗する場合、ネットワーク エラーなどの理由でノードが使用できなくなる場合があります。
ダウンしたノードがオブザーバー ノードの場合、ノードが復元されるまで ZooKeeper アンサンブルのパフォーマンスがわずかに低下することがあります。ノードがボーターノードの場合、リーダー選出プロセスに参加するノードが失われるため、ZooKeeper アンサンブルの存続可能性に影響する可能性があります。投票者ノードがダウンした理由に関係なく、利用可能な投票者ノードのクォーラムを維持することが重要です。
メンテナンス手順
ZooKeeper アンサンブルが機能していることを確認した後にのみ、メンテナンス手順を実行することを検討してください。これは、オブザーバー ノードが機能しており、メンテナンス中にクォーラムを維持するのに十分な投票者ノードが利用可能であることを前提としています。
これらの条件が満たされると、任意のサイズの ZooKeeper アンサンブルは、データの損失やパフォーマンスへの重大な影響なしに、任意の時点で単一ノードの損失を許容できます。つまり、一度に 1 つのノードであれば、アンサンブル内の任意のノードでメンテナンスを自由に実行できます。
メンテナンスの一環として、次の手順で ZooKeeper ノードのタイプ（リーダー、投票者、オブザーバー）を特定します。
- ZooKeeper ノードにインストールされていない場合は、nc をインストールします。
> 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 ノードを使用する Edge のスタンドアロン インストールでは、Mode は standalone に設定されます。 - 各 ZooKeeper ノードで手順 1 と 2 を繰り返します。
概要
ZooKeeper アンサンブルのメンテナンスを行う最適な方法は、1 つずつノードをメンテナンスすることです。注意事項:
- ZooKeeper アンサンブルの機能を維持するには、メンテナンス中にボーターノードのクォーラムを維持する必要があります。
- オブザーバー ノードを停止しても、クォーラムやリーダーを選出する機能には影響しません。
- クォーラムは、すべてのデータセンターのすべての ZooKeeper ノードで計算されます。
- 前のサーバーが稼働したら、次のサーバーのメンテナンスに進みます。
- nc コマンドを使用して ZooKeeper ノードを検査する