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

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

Edge for Private Cloud v4.18.05

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 には、ZooKeeper ノードの IP アドレスを指定します。IP アドレスすべての ZooKeeper ノードで同じ順序で列挙する必要があります。
マルチデータセンター環境では、すべてのデータセンターのすべての ZooKeeper ノードを一覧表示します。
ZK_CLIENT_HOSTS には、このリソースで使用する ZooKeeper ノードの IP アドレスを指定します。データセンターのみ。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 ノードの追加ドキュメントで Edge に ZooKeeper ノードを追加する方法について説明します。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 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（リーダーではない投票者）ノード構成に応じて異なります。
注: 1 つの Edge スタンドアロンインストール環境では、 ZooKeeper ノードの場合、Mode は standalone に設定されます。
ZooKeeper ノードごとに手順 1 と 2 を繰り返します。

概要

ZooKeeper アンサンブルのメンテナンスを行う最善の方法は、1 つのノードで 1 つのノードを実行することです。あります。注意事項:

ZooKeeper が確実に実行されるよう、メンテナンス中もボーターノードのクォーラムを維持する必要があります。アンサンブルは機能を維持する
オブザーバーノードを停止しても、クォーラムまたはリーダー選出機能には影響しません。
クォーラムは、すべてのデータセンターのすべての ZooKeeper ノード間で計算されます。
前のサーバーが稼働状態になったら、次のサーバーのメンテナンスを続行する
nc コマンドを使用して ZooKeeper ノードを検査する