Edge for Private Cloud v. 4.17.01
ZooKeeper アンサンブルは、1 つ以上の ZooKeeper ノードがダウンしても引き続き機能してデータ損失を回避するように設計されています。この復元力を効果的に活用して、VM 上でのメンテナンスを システムのダウンタイムのない 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 アドレス。IP アドレスは、
すべての ZooKeeper ノード。
マルチ データセンター環境では、すべてのデータセンターのすべての ZooKeeper ノードを列挙します。 - ZK_CLIENT_HOSTS～
このデータセンターのみで使用される ZooKeeper ノードの IP アドレスを指定します。IP
データセンター内のすべての ZooKeeper ノードで、同じ順序でアドレスをリストする必要があります。
単一データセンター環境では、これらのノードは ZK_HOSTS で指定したノードと同じになります。新しい 複数のデータセンターがある場合、各データセンターの Edge 構成ファイルには、 対象のデータセンターの ZooKeeper ノード
デフォルトでは、すべての ZooKeeper ノードは「ボーター」ノードとして指定されます。これは、すべてのノードが ZooKeeper の「リーダー」の選出に参加することを意味します。ZK_HOSTS に「:observer」修飾子を含めると、ノードがボーターではなく「オブザーバ」ノードであることを指定できます。オブザーバー ノードは リーダーの選出
通常は、複数の Edge データの作成時に「:observer」修飾子を指定します。 または、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 はリクエストを処理できません。つまり、エッジ管理サービスに対してリクエストを クォーラムが復元されるまで、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 ノードの追加ドキュメント で、さらに ZooKeeper ノードを Edge に追加する方法について説明します。ZooKeeper ノードを追加する際は、追加するノードのタイプをボーターとオブザーバのどちらにするかを検討する必要があります。
1 つ以上のボーターノードがダウンした場合に備え、十分な数のボーターノードを用意する必要があります。 ZooKeeper アンサンブルが引き続き機能すること、つまりボーターノードのクォーラムが維持されること できます。ボーターノードを追加することでクォーラムのサイズが大きくなるため、 投票者ノードのダウンを許容できます
ただし、ボーターノードを追加すると、書き込みパフォーマンスに悪影響を及ぼす可能性があります。 クォーラムでリーダーについて合意する必要があります。リーダーの決定に要する時間はボーターノードの数によって変わり、ボーターノードを追加するとその時間が長くなります。したがって、すべてのノードをボーターにすることはおすすめできません。
ボーターノードを追加するのではなく、オブザーバー ノードを追加できます。オブザーバ ノードを追加すれば、リーダー選出のオーバーヘッドが増えることなく、システム全体の読み取りパフォーマンスが向上します。オブザーバ ノードはリーダー選出に投票しないことから、クォーラム サイズに影響しないためです。そのため、オブザーバー ノードが アンサンブルがリーダーを選出できるかどうかに影響はありません。ただし、オブザーバ ノードがダウンするとデータ リクエストを処理するノードの数が少なくなるため、ZooKeeper アンサンブルの読み取りパフォーマンスが低下する場合があります。
単一のデータセンターでは、オブザーバ ノードの数に関係なく、ボーターノードの数を 5 つ以下に抑えることをおすすめします。2 つのデータセンターを使用する場合は、ボーターノードの数を 9 つ（一方のデータセンター内に 5 つ、もう一方のデータセンター内に 4 つ）以下に抑えることをおすすめします。あとはいくつでも オブザーバー ノードを指定します。
メンテナンスに関する考慮事項
ZooKeeper のメンテナンスは完全に機能するアンサンブルで行うことができます。一度に 1 つのノードでメンテナンスを行う場合、ダウンタイムはともないません。ダウンしている ZooKeeper ノードが 1 つだけであることを 投票者ノードのクォーラムを常時確保して、 います。
メンテナンス全体 複数のデータセンター
複数のデータセンターを使用する場合、ZooKeeper アンサンブルはデータセンターを区別しないことに注意してください。ZooKeeper アセンブリは、すべての ZooKeeper ノードを表示します。 複数のデータセンターを 1 つのアンサンブルとして 統合できます
特定のデータセンター内のボーターノードの場所は、ZooKeeper を実行する際に考慮されない クォーラム計算を行います。クォーラムが満たされている限り、データセンター全体で個々のノードがダウンしても それがアンサンブル全体で維持されているので、ZooKeeper は引き続き機能します。
メンテナンスの影響
ボーターノードでもオブザーバ ノードでも、ZooKeeper ノードをメンテナンスのために停止させなければならない状況はさまざまにあります。たとえば、ノード上の Edge のバージョンのアップグレード、 ZooKeeper をホストしているマシンで障害が発生するか、そのノードが他のいくつかの ネットワーク エラーなどの理由です。
停止するノードがオブザーバー ノードの場合は、 ノードが復旧するまで ZooKeeper アンサンブルのパフォーマンスを維持します。ノードがボーターの場合 アクセス元のノードが失われ、ZooKeeper アンサンブルの実行可能性に影響する リーダー選出プロセスに参加します。ボーターノードを停止する理由が何であれ、使用可能なボーターノードのクォーラムを確保することが重要です。
メンテナンス手順
メンテナンス手順は、ZooKeeper アンサンブルが機能することを確認した後に限って行ってください。これは、オブザーバー ノードが機能していて、十分な数のノードがあることを前提としています。 クォーラムを維持するために、メンテナンス中に使用可能なボーターノードの数が必要です。
これらの条件を満たしていれば、ZooKeeper アンサンブルはそのサイズにかかわらず、常に 1 つのノードの損失を許容できるため、データ損失やパフォーマンスへの重大な影響は発生しません。つまり、一度に 1 つのノードを対象とする限り、アンサンブルのどのノードでも自由にメンテナンスを行うことができます。
メンテナンスの一環として、次の手順に従って ZooKeeper ノードのタイプ（リーダー、ボーター、オブザーバ）を判別します。
- ZooKeeper ノードにインストールされていない場合は、nc をインストールします。
>sudo yum install nc - ノードで次の nc コマンドを実行します。
>echo stat |nc localhost 2,181
ここで、2181 は ZooKeeper ポートです。次の形式の出力が表示されます。
Zookeeper バージョン: 3.4.5-1392090、 ビルド日: 09/30/2012 17:52 GMT
クライアント: /a.b.c.d:xxxx[0](queued=0,recved=1,sent=0)
レイテンシ（最小/平均/最大）: 0/0/0
受信済み: 1
送信済み: 0
接続数: 1
未処理: 0
Zxid: 0xc00000044
モード: フォロワー
ノード数: 653
出力の [Mode] 行は、 ノードには、observer、leader、または follower（ リーダーなど）が使用されます。
注: ZooKeeper ノードが 1 つある Edge のスタンドアロン インストールでは、 [モード] が [スタンドアロン] に設定されている。 - ZooKeeper ノードごとにステップ 1 と 2 を繰り返します。
概要
ZooKeeper アンサンブルのメンテナンスを行う最善の方法は、1 つのノードで 1 つのノードを実行することです。 あります。注意事項:
- ZooKeeper が確実に実行されるよう、メンテナンス中もボーターノードのクォーラムを維持する必要があります。 アンサンブルは機能を維持する
- オブザーバ ノードを停止しても、クォーラムまたはリーダー選出機能には影響しません。
- クォーラムは、すべてのデータセンター内のすべての ZooKeeper ノードを基に計算されます。
- 前のサーバーが稼働状態になったら、次のサーバーのメンテナンスを続行する
- nc コマンドを使用して ZooKeeper ノードを調べる