このページは Cloud Translation API によって翻訳されました。

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

Edge for Private Cloud v. 4.17.09

ZooKeeper アンサンブルは、サービスが失われても、データが失われることなく機能し続けるように設計されています。制限します。この復元力を効果的に活用して、VM 上でのメンテナンスをシステムのダウンタイムのない ZooKeeper ノード。

ZooKeeper と Edge について

Edge では、ZooKeeper ノードにアプリケーションの場所と構成に関する構成データ構成の変更をさまざまなコンポーネントに通知します。すべて本番環境システムでサポートされている Edge トポロジでは、少なくとも 3 つの ZooKeeper を使用するように指定する説明します。

ZK_HOSTS と ZK_CLIENT_HOSTS プロパティ（ ZooKeeper ノードを指定する Edge 構成ファイル。試験用

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

ここで

ZK_HOSTS - ホストの IP アドレスを指定します。 ZooKeeper ノード。すべての ZooKeeper ノードで同じ順序で IP アドレスをリストする必要があります。

マルチデータセンター環境では、すべてのデータセンターのすべての ZooKeeper ノードを一覧表示します。
ZK_CLIENT_HOSTS - IP アドレスを指定します。このデータセンターで使用される ZooKeeper ノードのみ。IP アドレスは、データセンター内のすべての ZooKeeper ノードで同じ順序にします。

単一データセンター環境では、これらのノードは ZK_HOSTS で指定したノードと同じになります。新しい複数のデータセンターがある場合、各データセンターの Edge 構成ファイルには、そのデータセンターの ZooKeeper ノード

デフォルトでは、すべての ZooKeeper ノードがボーターノードとして指定されます。つまり、ノードは全員が ZooKeeper リーダーの選出に参加します。コメントには、「:observer」修飾子と ZK_HOSTS をメモがボーターではなく、オブザーバー ノードであることを示します。オブザーバーノードはリーダーの選挙に参加すること

通常は、複数の 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 ノードでは、すべての書き込みリクエストがリーダーに転送されます。たとえば、新しいメッセージプロセッサが Edge に追加されます。この情報は ZooKeeper リーダーに書き込まれます。すべてのフォロワーデータを複製します

Edge のインストール時に、各 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 に追加する方法については、nodes のドキュメントをご覧ください。追加する場合 ZooKeeper ノードを使用する場合は、追加するノードのタイプ（ボーターまたは使用します。

1 つ以上のボーターノードがダウンした場合に備え、十分な数のボーターノードを用意する必要があります。 ZooKeeper アンサンブルが引き続き機能すること、つまりボーターノードのクォーラムが維持されることできます。ボーターノードを追加することでクォーラムのサイズが大きくなるため、投票者ノードのダウンを許容できます

ただし、ボーターノードを追加すると、書き込みパフォーマンスが低下する可能性があります。オペレーションでは、クォーラムでリーダーについて合意する必要があります。リーダーの決定にかかる時間ボーターノードの数に基づいており、ボーターノードを追加すると増加します。したがって、すべてのノードをボーターにすることはできません。

ボーターノードを追加するのではなく、オブザーバーノードを追加できます。オブザーバーノードの追加リーダー選択のオーバーヘッドを増やさずに、システム全体の読み取りパフォーマンスをオブザーバーノードは投票せず、クォーラムサイズに影響しません。そのため、オブザーバーノードがアンサンブルがリーダーを選出できるかどうかに影響はありません。ただし、オブザーバーが制限されているため、ZooKeeper アンサンブルの読み取りパフォーマンスが低下するデータリクエストに対応できるノードが少なくなります。

Apigee では、単一のデータセンター内のボーターを 5 人以下にすることをおすすめします。オブザーバーノードの数によって決まります2 つのデータセンターでは、 9 人（1 つのデータセンターに 5 人、もう一つのデータセンターに 4 人）を上回っています。あとはいくつでもオブザーバーノードを指定します。

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

ZooKeeper のメンテナンスは、完全に機能するアンサンブルに対してダウンタイムなしで実行できます。一度に 1 つのノードで実行されますダウンしている ZooKeeper ノードが 1 つだけであることを投票者ノードのクォーラムを常時確保して、います。

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

複数のデータセンターを使用する場合、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 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 ノードを検査する