| Oracle® TimesTen In-Memory Database Scaleoutユーザーズ・ガイド リリース18.1 E98636-05 |
|
 前 |
 次 |
この章では、メンバーシップ・サービスを設定する方法について説明します。
TimesTen Scaleoutのメンバーシップ・サービスを使用すると、インスタンス間の通信と連携を中断する、インスタンス間のネットワーク障害が検出された場合でも、グリッドは一貫した方法で動作できます。
TimesTen Scaleoutのメンバーシップ・サービスによって、次のことが実行されます。
インスタンス・ステータスの追跡。これにより、インスタンスは相互の通信を維持できます。
通信障害が修正された後のネットワーク・パーティション・エラーからのリカバリ。
グリッドは、1つのプライベート・ネットワークを介して通信する複数のホストに存在するインスタンスの集合です。メンバーシップ・サービスは、アクティブになっているインスタンスを認識します。各インスタンスは、起動するとき、図3-1に示すように、メンバーシップ・サービス内のメンバーシップ・サーバーに接続してそれ自体を登録します。いずれかのメンバーシップ・サーバーに障害が発生した場合、障害が発生したメンバーシップ・サーバーに接続していたインスタンスは、使用可能なメンバーシップ・サーバーのいずれかに透過的に再接続します。
各インスタンスは、アクティブ・インスタンス・リストを問い合せることができるように、いずれかのメンバーシップ・サーバーへの永続接続を維持します。メンバーシップ・サーバーとインスタンスの間のネットワークが停止している場合、ネットワークが修正されてメンバーシップ・サーバーとの通信が復元されるまで、インスタンスは実行を拒否します。
図3-2は、グリッド内のデータ・インスタンスが相互に接続する方法を示しています。各データ・インスタンスは、グリッド内の他のすべてのデータ・インスタンスに接続します。また、この例の各データ・インスタンスがいずれかのメンバーシップ・サーバーとの永続接続を維持する方法も示しています。
データ・インスタンスは別のインスタンスへの接続を失った場合、そのメンバーシップ・サーバー上のアクティブ・インスタンス・リストを問い合せて、失われたインスタンスが稼働しているかどうかを確認します。失われたインスタンスが稼働している場合、データ・インスタンスはそのインスタンスとの接続を再確立しようとします。それ以外の場合、不要な遅延を回避するために、失われたインスタンスへの接続の確立はこれ以上試行されません。
失われたインスタンスが再起動すると、メンバーシップ・サービスにそれ自体を登録し、グリッド内の他のすべてのインスタンスに対して、起動していることを事前に通知します。グリッドの残りのインスタンスとの同期が適切である場合、リカバリされたインスタンスは、再度、アプリケーションからのトランザクションを処理するために使用されます。
図3-3では、host1データ・インスタンスが稼働していません。host2データ・インスタンスがhost1データ・インスタンスとの通信を試みると、壊れた接続が検出されます。host2データ・インスタンスがメンバーシップ・サーバー上のアクティブ・インスタンス・リストを問い合せると、host1データ・インスタンスがアクティブ・インスタンス・リストにないことが通知されます。host1データ・インスタンスは、再起動すると、メンバーシップ・サービスに再度それ自体を登録し、このグリッド内のアクティブ・インスタンスのリストに含められます。
ネットワーク・パーティション・エラーによって、単一のグリッドに含まれるインスタンスが2つのサブセットに分割されます。ネットワーク・パーティション・エラーが発生した場合、インスタンスの各サブセットはインスタンスの他のサブセットと通信できません。
図3-4は、メンバーシップ・サービスがない場合、アプリケーションがインスタンスの一方のサブセットにアクセスでき、インスタンスの切断されたサブセットにはアクセスできないために、ネットワーク・パーティションによって、アプリケーション問合せに対して矛盾した結果が返されることを示しています。インスタンスの一方のサブセットに対して実行された更新は、もう一方のサブセットには反映されません。アプリケーションがhost1データ・インスタンスに接続すると、問合せによって、host1およびhost3データ・インスタンスの結果が返されます。ただし、host2およびhost4データ・インスタンスに常駐するデータは、2つのサブセット間に接続がないため、使用できません。
ネットワーク・パーティションが発生した場合、メンバーシップ・サービスによって解決策が提供されます。図3-5は、4つのインスタンスと3つのメンバーシップ・サーバーがあるグリッドを示しています。ネットワーク通信エラーにより、グリッドが2つのサブセットに分割され、host1およびhost3がhost2およびhost4を認識したり、これらと通信できなくなりました。また、ms_host1メンバーシップ・サーバーは他の2つのメンバーシップ・サーバーと通信できません。
グリッドのステータスを管理するためにメンバーシップ・サービスが適切に動作するには、作成された全部のサーバーのうち、過半数のアクティブなメンバーシップ・サーバーが相互に通信して適切に動作できる必要があります。あるメンバーシップ・サーバーに障害が発生すると、他のサーバーは、過半数が使用可能であるかぎり、リクエストの処理を続行します。
次に例を示します。
3つのメンバーシップ・サーバーで構成されたメンバーシップ・サービスは、1つのメンバーシップ・サーバー障害を処理できます。
5つのメンバーシップ・サーバーで構成されたメンバーシップ・サービスは、2つのメンバーシップ・サーバー障害を処理できます。
6つのメンバーシップ・サーバーで構成されたメンバーシップ・サービスでは、3つのメンバーシップ・サーバーは過半数ではないため、2つのみの障害は処理できます。
|
ノート: メンバーシップ・サーバーの数を構成するとき、メンバーシップ・サービスとして機能するメンバーシップ・サーバーを常に奇数個作成するようにしてください。メンバーシップ・サーバーの数が偶数であるとき、ネットワーク・パーティション・エラーが発生すると、グリッドの各サブセットには同じ数のメンバーシップ・サーバーが存在する可能性があり、その場合はいずれの側にも過半数のサーバーが存在しません。したがって、ネットワーク・パーティション化されたグリッドの両方が機能しなくなります。 |
残りのメンバーシップ・サーバーの数が過半数に必要な数を下回る場合、残りのメンバーシップ・サーバーは、少なくとも過半数のメンバーシップ・サーバーが実行されるまで、すべてのリクエストを拒否します。また、メンバーシップ・サービスと通信できないデータ・インスタンスがすべてのトランザクションを実行できません。障害の問題を調査し、障害が発生したメンバーシップ・サーバーを再起動する必要があります。
通信障害のため、ms_host1メンバーシップ・サーバーは、他の2つのメンバーシップ・サーバーを認識できません。認識しているメンバーシップ・サーバーでは過半数を構成するために十分でないため、ms_host1メンバーシップ・サーバーはhost1およびhost3データ・インスタンスからの着信リクエストをこれ以上受け入れることができません。また、障害が発生したメンバーシップ・サーバーが再起動されるまで、host1およびhost3データ・インスタンスはすべてのトランザクションを実行できません。
ネットワーク・パーティションが存在するかどうかを確認するには、デーモン・ログで、メンバーシップ・サーバーとの接続を失っている要素に関するエラーを確認します。
グリッドが2つに分割される原因となった接続エラーを解決した後、すべてのメンバーシップ・サーバーは再接続し、メンバーシップ情報を同期化します。図3-5の例では、ms_host1メンバーシップ・サーバーがメンバーシップ・サービスに再び参加します。その後、host1およびhost3データ・インスタンスもアクティブ・インスタンスとしてこのグリッドに再び参加します。
Apache ZooKeeperは、分散システムの情報を維持したり複数のホストのサービスを調整する、サード・パーティのオープンソースの集中管理サービスです。TimesTen Scaleoutは、Apache ZooKeeperを使用して、すべてのインスタンスのステータスを追跡したりグリッド内でアクティブなインスタンスの一貫したビューを提供するメンバーシップ・サービスを提供します。
TimesTen Scaleoutでは、グリッドのメンバーシップ・サービスとして機能するApache ZooKeeperをインストールおよび構成することが必要です。グリッド内の各メンバーシップ・サーバーは、Apache ZooKeeperサーバーです。
|
ノート: メンバーシップ・サーバーはZooKeeperサーバーであるため、http://zookeeper.apache.orgにある、ZooKeeperサーバーの使用および管理方法に関するApache ZooKeeperのドキュメントを参照してください。 |
2番目のグリッドを作成する場合は、同じZooKeeperサーバーを使用して、そのグリッドのメンバーシップ・サービスとして機能させることができます。ただし、すべてのZooKeeperサーバーはTimesTen Scaleoutのメンバーシップ・サービスとしてのみ機能します。
本番環境のZooKeeperサーバーの場合は、次のようにすることをお薦めします。
個別のホストで、奇数のレプリケートされたZooKeeperサーバーを構成します。メンバーシップ・サービスに3つ以上のZooKeeperサーバーを使用します。n個のZookeeperサーバーがある場合は、過半数である(n/2+1)個のZooKeeperサーバーが動作している必要があります。ZooKeeperサーバーの数が多いほど信頼性が高くなります。
インスタンス用に使用されているホストとは別のホストをメンバーシップ・サーバーに使用することをお薦めします(ただし必須ではありません)。ZooKeeperサーバーとインスタンスを別々のホストに配置すると、ホストに障害が発生しても、インスタンスと1つのメンバーシップ・サーバーの両方が失われることはありません。
ZooKeeperサーバーがシングル・ポイント障害の影響を受けないようにします。たとえば、独立した物理ラック、電源およびネットワークの場所を使用します。
Zookeeperサーバーは、データ・インスタンスと同じ物理インフラストラクチャを共有できます。たとえば、データ・インスタンスが2つの物理ラックに分散されている場合は、これらの同じ2つのラックでZookeeperサーバーをホストできます。
たとえば、アクティブおよびスタンバイ管理インスタンス、2つのデータ領域グループ(それぞれ3つのデータ・インスタンスを持つ)、グリッド内に構成された3つのZooKeeperサーバーでグリッドを構成します。データ・ラックが2つある場合、ホストを編成する最善の方法は次のとおりです。
ラック1に1つの管理インスタンス、ラック2にその他の管理インスタンスを配置します。
ラック1に2つのZooKeeperサーバー、ラック2に3つ目のZooKeeperサーバーを配置します。
ラック1にデータ領域グループ1のデータ・インスタンスのホスト、ラック2にデータ領域グループ2のデータ・インスタンスのホストを配置します。
このようにすると、ラック2が電源またはイーサネット接続を失った場合、ラック1に過半数のZooKeeperサーバーがあるため、このグリッドは動作を継続します。ラック1で障害が発生した場合は、過半数のZooKeeperサーバーを失い、ZooKeeperサーバーをリカバリする必要があります。グリッドは、過半数の構成されたZooKeeperサーバーが動作していないため、動作しません。
メンバーシップ・サーバーを提供する各ホストで、TimesTen固有のApache ZooKeeperディストリビューション(TimesTenインストールのinstallation_dir/tt18.1.4.1.0/3rdpartyディレクトリにあるZooKeeper TARファイル)をインストールします。
|
重要:
|
メンバーシップ・サーバーのいずれかとして動作する各ホストでZooKeeperインストール用のディレクトリを作成します。ZooKeeperディストリビューション・ファイルを任意の名前のディレクトリにインストールできます。
すでにTimesTen Scaleoutがインストールされているホストで、installation_dir/tt18.1.4.1.0/3rdpartyにあるapache-zookeeper-3.5.8-bin.tar.gz ZooKeeperファイルを各ホスト上の目的のディレクトリにコピーします。
標準のオペレーティング・システムのtarコマンドを使用して、メンバーシップ・サーバーとして使用する各ホストの目的の場所に、提供されたApache ZooKeeperディストリビューションを解凍します。
Linuxでの次の例では、Apache ZooKeeperインストールをzkdirディレクトリ(現在のディレクトリのサブディレクトリ)に解凍します。host1上のTimesTen Scaleoutインストールは/swdir/TimesTen/tt18.1.4.1.0にあります。
ms1_hostメンバーシップ・サーバーで、zkdirディレクトリを作成します。
% mkdir -p zkdir
host1上のinstallation_dir/tt18.1.4.1.0/3rdpartyディレクトリにあるapache-zookeeper-3.5.8-bin.tar.gzファイルを、ms1_host上に作成したzkdirディレクトリにコピーします。
% tar -C zkdir -xzvf /swdir/TimesTen/tt18.1.4.1.0/3rdparty/apache-zookeeper-3.5.8-bin.tar.gz
[...TAR OUTPUT...]
|
ノート: TimesTen Scaleoutが提供するZooKeeperディストリビューションのバージョンは、installation_dir/18.1.4.1.0/3rdpartyディレクトリに提供されるTARファイルの名前に表示されます。たとえば、この例のapache-zookeeper-3.5.8-bin.tar.gzファイルは、提供されたApache ZooKeeperディストリビューション・バージョンが3.5.8であることを示しています。 |
各Apache ZooKeeperサーバーをグリッドのメンバーシップ・サーバーとして機能するように構成するには、メンバーシップ・サーバーをホストしている各ホスト上で、次の構成ファイルを構成する必要があります。
zoo.cfg構成ファイル: レプリケート・モードでは、各メンバーシップ・サーバーにzoo.cfg構成ファイルがあります。zoo.cfg構成ファイルは、メンバーシップ・サービスに関与するすべてのメンバーシップ・サーバーを識別子、各メンバーシップ・サーバーはDNS名(またはIPアドレス)およびポート番号で識別されます。
各メンバーシップ・サーバー上のzoo.cfg内のすべての構成パラメータは、クライアント・ポートを除きまったく同じである必要があります。クライアント・ポートは、メンバーシップ・サーバーごとに異なる場合があります(異なることは必須ではありません)。各メンバーシップ・サーバーが別々のホストで実行されている場合は、クライアント・ポートを同じにすることができます。
zoo.cfgファイルをApache ZooKeeperインストールの/confディレクトリに配置します。たとえば、apache-zookeeper-3.5.8-bin.tar.gzファイルを各メンバーシップ・サーバー上の/swdir/zkdirディレクトリに解凍した場合は、zoo.cfgファイルを次のディレクトリに配置します。
/swdir/zkdir/apache-zookeeper-3.5.8-bin/conf/zoo.cfg
myid構成ファイル: この特定のメンバーシップ・サーバーを識別する番号を提供します。各メンバーシップ・サーバーは一意の番号で識別されます。たとえば、5つのサーバーがある場合は、一意の整数1、2、3 4および5ので識別される必要があります。
この番号は、server.xパラメータのxによるzoo.cfgファイル内のホストの定義に対応します。すべてのzoo.cfgファイルには、すべてのメンバーシップ・サーバーのリストが必要です。たとえば、5つのメンバーシップ・サーバーがある場合は、zoo.cfgファイルにserver.1、server.2のように構成されます。
各ホストのmyid構成ファイルには、そのサーバーの整数を含む1つの行があります。たとえば、2番目のメンバーシップ・サーバーはserver.2としてzoo.cfgで識別され、そのmyid構成ファイルには2を含む1行があります。
myid構成ファイルは、メンバーシップ・サーバーのApache ZooKeeperデータ・ディレクトリ内のテキスト・ファイルです。データ・ディレクトリの場所は、zoo.cfgファイルでdataDirパラメータで構成されています。たとえば、/swdir/zkdir/3.5.8/dataをデータ・ディレクトリとして構成した場合、myidテキスト構成ファイルは次のように配置されます。
/swdir/zkdir/apache-zookeeper-3.5.8-bin/data/myid
表3-1は、zoo.cfgファイルでよく使用される構成パラメータを示しています。
表3-1 zoo.cfg構成パラメータ
| パラメータ | 説明 |
|---|---|
|
|
|
|
メンバーシップ・サーバーをリーダーに接続する必要がある期間のタイムアウト(ティック)。最適なパフォーマンスを得るには、これを推奨設定の |
|
|
リーダーからメンバーシップ・サーバーが期限切れになる制限。この制限(ティック)は、リクエストを送信してから応答を受信するまでの許容される時間を指定します。最適なパフォーマンスを得るには、これを推奨設定の |
|
|
ZooKeeperデータ、スナップショットおよびトランザクション・ログを格納するためのデータ・ディレクトリの場所を決定し、作成します。 トランザクション・ログが書き込まれるディレクトリを作成する場合は、トランザクション・ログを不揮発性記憶域に書き込むことがパフォーマンスにとって重要となります。一貫して優れたパフォーマンスを実現するには、トランザクション・ログ専用のデバイスを確保することがキーとなります。ビジー状態のデバイスにトランザクションを記録すると、パフォーマンスに悪影響を及ぼします。 |
|
|
クライアント接続をリスニングするポート。デフォルトはポート |
|
|
|
|
|
古いスナップショットおよび対応するApache ZooKeeperトランザクション・ログのパージをトリガーする間隔(時間)。自動パージを有効にするには、正の整数(1以上)に設定します。デフォルトは0です。これを1に設定することをお薦めします。 |
|
|
サーバーがクライアントにネゴシエーションを許可する最小セッション・タイムアウト(ミリ秒)。デフォルトは、 |
|
|
サーバーがクライアントにネゴシエーションを許可する最大セッション・タイムアウト(ミリ秒)。デフォルトは、 |
|
|
各メンバーシップ・サーバーの構成は、 このパラメータは、レプリケート・モードでメンバーシップ・サーバーを実行するために必要です。 xは、メンバーシップ・サーバー上の
各サーバー名の後に2つのポート番号を定義します。
本番環境では、各メンバーシップ・サーバーを異なるホスト上に構成する必要があります。この場合、規則は、次のように同じポート番号を割り当てることなどです。 server.1=system1:2888:3888 server.2=system2:2888:3888 server.3=system3:2888:3888 ただし、テスト環境では、同じホスト上にすべてのメンバーシップ・サーバーを配置する場合があります。この場合は、すべてのメンバーシップ・サーバーに異なるポートを構成する必要があります。 |
|
|
指定したZookeeperの4文字単語のコマンドを有効にします。 |
インストールされているすべてのメンバーシップ・サーバーは、レプリケート・モードで実行する必要があります。レプリケート・モードでメンバーシップ・サーバーを実行するには、tickTime、initLimitおよびsyncLimitパラメータを含めて、メンバーシップ・サーバーごとに2つのポート番号を使用してホスト名を指定する必要があります。
|
ノート: レプリケート・モードの詳細は、http://zookeeper.apache.orgを参照してください。
その後、ドキュメントの「Getting Started」 > 「Running Replicated ZooKeeper」の項を参照してください。 |
次の例は、DNS名がms_host1、ms_host2、ms_host3であるホストにインストールされている3つのメンバーシップ・サーバーが存在するzoo.cfgメンバーシップ・サーバー構成ファイルを示しています。3つのすべてのメンバーシップ・サーバーは、レプリケート・モードで実行するように構成されています。
# The number of milliseconds of each tick tickTime=250 # The number of ticks that the initial synchronization phase can take initLimit=40 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=12 # The directory where you want the ZooKeeper data stored. dataDir=/swdir/zkdir/apache-zookeeper-3.5.8-bin/data # The port at which the clients will connect clientPort=2181 # Every hour, keep the latest three Apache ZooKeeper snapshots and # transaction logs and purge the rest autopurge.snapRetainCount=3 autopurge.purgeInterval=1 # The minimum and maximum allowable timeouts for Apache ZooKeeper sessions. # Actual timeout is negotiated at connect time. minSessionTimeout=2000 maxSessionTimeout=10000 # The membership servers server.1=ms_host1:2888:3888 server.2=ms_host2:2888:3888 server.3=ms_host3:2888:3888 # Enabled Zookeeper four-letter-words commands 4lw.commands.whitelist=stat, ruok, conf, isro
|
ノート: Apache ZooKeeperインストールの/confディレクトリにあるzoo_sample.cfgという名前のzoo.cfgファイルのパラメータの一部を説明するサンプル・ファイルがあります。ただし、TimesTen Scaleoutの推奨パラメータまたは設定のすべてが示されているわけではありません。zoo_sample.cfgは、参照用としてのみ使用してください。 |
この例では、それぞれがメンバーシップ・サーバーである3つのホストにmyidテキスト・ファイルを作成します。各myidテキスト・ファイルには1行が含まれ、ここには、zoo.cfgファイルで構成されているメンバーシップ・サーバーの1つに対応するサーバーID (整数)が含まれます。サーバーID、は構成ファイルのserver.x=エントリの数字xです。myidテキスト・ファイルは、各メンバーシップ・サーバー上のデータ・ディレクトリ内に配置する必要があります。データ・ディレクトリの場所は、/swdir/zkdir/apache-zookeeper-3.5.8-bin/dataです。
そのメンバーシップ・サーバーのms_host1上の/swdir/zkdir/apache-zookeeper-3.5.8-bin/dataディレクトリにmyidテキスト・ファイルを作成します。myidテキスト・ファイルには、値1が含まれています。
そのメンバーシップ・サーバーのms_host2上の/swdir/zkdir/apache-zookeeper-3.5.8-bin/dataディレクトリにmyidテキスト・ファイルを作成します。myidテキスト・ファイルには、値2が含まれています。
そのメンバーシップ・サーバーのms_host3上の/swdir/zkdir/apache-zookeeper-3.5.8-bin/dataディレクトリにmyidテキスト・ファイルを作成します。myidテキスト・ファイルには、値3が含まれています。
メンバーシップ・サーバーが起動すると、ZooKeeperデータ・ディレクトリのmyidファイルに構成されている整数によってどのサーバーであるかが識別されます。
zkServer.shシェル・スクリプトを使用してメンバーシップ・サーバーを起動する前に、最大Javaヒープ・サイズを設定して、ZooKeeperをファイル・システムにスワップするかどうかを決定する必要があります。Java最大ヒープ・サイズは、使用可能な実メモリーの容量よりも大きくしないでください。zkEnv.shシェル・スクリプトを編集して、最大Javaヒープ・サイズを4GBに設定するJVMFLAGS環境変数を含む新しい行を追加します。起動時に、zkServer.shシェル・スクリプトはzkEnv.shシェル・スクリプトを取得して、この新しい環境変数を含めます。
ZooKeeperシェル・スクリプトは、ZooKeeperサーバーの/binディレクトリにあります。たとえば、各メンバーシップ・サーバー上の/swdir/zkdirディレクトリにapache-zookeeper-3.5.8-bin.tar.gzファイルを解凍した場合、zkEnv.shおよびzkServer.shシェル・スクリプトは/swdir/zkdir/binディレクトリに配置されます。
次の例では、zkEnv.shシェル・スクリプトを編集し、zkEnv.shスクリプト内のZOOKEEPER_PREFIXの行の後にJVMFLAGS=Xmx4g構成を追加します。
ZOOBINDIR="${ZOOBINDIR:-/usr/bin}"
ZOOKEEPER_PREFIX="${ZOOBINDIR}/.."
JVMFLAGS=-Xmx4g
各サーバーでzkServer.sh startシェル・スクリプトを実行して、各メンバーシップ・サーバーを起動します。
% setenv ZOOCFGDIR /swdir/zkdir/apache-zookeeper-3.5.8-bin/conf % /swdir/zkdir/apache-zookeeper-3.5.8-bin/bin/zkServer.sh start
各メンバーシップ・サーバー上でzkServer.sh statusコマンドを実行して、各メンバーシップ・サーバーのステータスを確認できます。
% /swdir/zkdir/apache-zookeeper-3.5.8-bin/bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /swdir/zkdir/apache-zookeeper-3.5.8-bin/conf/zoo.cfg
Mode: { leader | follower }
メンバーシップ・サーバーが実行されていない場合、レプリケート・モードでない場合、または過半数が実行されていない場合は、次のエラーが表示されます。
ZooKeeper JMX enabled by default Using config: /swdir/zkdir/apache-zookeeper-3.5.8-bin/conf/zoo.cfg Error contacting service. It is probably not running.
さらに、ruok ZooKeeperコマンドを使用して、メンバーシップ・サーバーが非エラー状態で実行されているかどうかを確認できます。サーバーが実行中の場合、このコマンドはimokを返します。それ以外の場合、レスポンスはありません。ネットワーク内のマシンから、次を実行します。
% echo ruok | nc ms_host1 2181 imok
パフォーマンスおよび接続されているクライアントに関する統計の場合は、stat ZooKeeperコマンドを使用します。ネットワーク内のマシンから、次を実行します。
% echo stat | nc ms_host1 2181
メンバーシップ・サーバーが起動された後、グリッドを作成できます。メンバーシップ・サーバーを認識するグリッドの作成方法の詳細は、メンバーシップ・サービス・クライアントとしてのグリッドの構成を参照してください。
グリッドは、各メンバーシップ・サーバーへの接続方法を理解している必要があります。そのため、すべてのメンバーシップ・サーバーの詳細を示すグリッドを作成する際に、ttGridAdminユーティリティにZooKeeperクライアント構成ファイルを指定する必要があります。接尾辞が.confであれば、ZooKeeperクライアント構成ファイルの名前には、任意の接頭辞を使用できます。
ZooKeeperクライアント構成ファイルは、連携してメンバーシップ・サービスを提供するすべてのメンバーシップ・サーバーを指定します。クライアント構成ファイル内には、各メンバーシップ・サーバーのDNS (またはIPアドレス)およびクライアント・ポート番号を指定するServersパラメータを含む1つの行があります。これらのホストの構成情報は、次のようにする必要があります。
各メンバーシップ・サーバー上の個別のzoo.cfgファイルそれぞれで、server.xパラメータで指定されたものと同じDNS (またはIPアドレス)を使用します。
各メンバーシップ・サーバー上の個別のzoo.cfgファイルそれぞれでclientPortパラメータで指定されたものと同じクライアント・ポート番号を指定します。
この例では、ZooKeeperクライアント構成ファイルとしてmembership.confファイルを使用します。次の例では、3つのメンバーシップ・サーバーをサポートする3つのホストがあり、ms_host1はクライアント・ポート2181、ms_host2はクライアント・ポート2181、ms_host3はクライアント・ポート2181をリスニングします。
Servers ms_host1!2181,ms_host2!2181,ms_host3!2181
グリッドは、グリッドの作成時にZooKeeperクライアント構成ファイルを入力パラメータとして指定したため、これらのメンバーシップ・サーバーに到達する方法を認識しています。詳細は、グリッドの作成を参照してください。
グリッドを作成するときにttGridAdminコマンドにZooKeeperクライアント構成ファイルを指定すると、ZooKeeperクライアント構成ファイルは必要なくなり、破棄できます。
