メンバーシップ・サービスとしてのApache ZooKeeperの使用方法

Apache ZooKeeperは、分散システムの情報を維持したり複数のホストのサービスを調整する、サード・パーティのオープンソースの集中管理サービスです。TimesTen Scaleoutは、Apache ZooKeeperを使用して、すべてのインスタンスのステータスを追跡したりグリッド内でアクティブなインスタンスの一貫したビューを提供するメンバーシップ・サービスを提供します。

TimesTen Scaleoutでは、グリッドのメンバーシップ・サービスとして機能するApache ZooKeeperをインストールおよび構成することが必要です。グリッド内の各メンバーシップ・サーバーは、Apache ZooKeeperサーバーです。

ノート:

メンバーシップ・サーバーはZooKeeperサーバーであるため、ZooKeeperサーバーの使用および管理方法については、Apache ZooKeerのWebサイトを参照してください。

2番目のグリッドを作成する場合は、同じZooKeeperサーバーを使用して、そのグリッドのメンバーシップ・サービスとして機能させることができます。ただし、すべてのZooKeeperサーバーはTimesTen Scaleoutのメンバーシップ・サービスとしてのみ機能します。

本番環境のZooKeeperサーバーの場合は、次のようにすることをお薦めします。

• 個別のホストで、奇数のレプリケートされたZooKeeperサーバーを構成します。メンバーシップ・サービスに3つ以上のZooKeeperサーバーを使用します。n個のZookeeperサーバーがある場合は、過半数である(n/2+1)個のZooKeeperサーバーがアクティブである必要があります。ZooKeeperサーバーの数が多いほど信頼性が高くなります。

• インスタンス用に使用されているホストとは別のホストをメンバーシップ・サーバーに使用することをお薦めします(ただし必須ではありません)。ZooKeeperサーバーとインスタンスを別々のホストに配置すると、ホストに障害が発生しても、インスタンスと1つのメンバーシップ・サーバーの両方が失われることはありません。

• ZooKeeperサーバーがシングル・ポイント障害の影響を受けないようにします。たとえば、独立した物理ラック、電源およびネットワークの場所を使用します。

• Zookeeperサーバーは、データ・インスタンスと同じ物理インフラストラクチャを共有できます。たとえば、データ・インスタンスが2つの物理ラックに分散されている場合は、同じこれら2つのラックでZookeeperサーバーをホストできます。

  たとえば、グリッドを、アクティブおよびスタンバイ管理インスタンス、3つのデータ領域グループ(それぞれ2つのデータ・インスタンスを含む)、3つのZooKeeperサーバーで構成します。データ・ラックが3つある場合、ホストを編成する最良の方法は次のとおりです。

  • ラック1に1つの管理インスタンス、ラック2にその他の管理インスタンスを配置します。

  • 別のラックに各ZooKeeperサーバーを配置します。

  • ラック1にデータ領域グループ1のデータ・インスタンスのホスト、ラック2にデータ領域グループ2のデータ・インスタンスのホスト、ラック3にデータ領域グループ3のデータ・インスタンスのホストを配置します。

  このようにすると、ラックのどれかが電源やそのイーサネット接続を失った場合でも、ZooKeeperサーバーがまだ過半数に達しているため、このグリッドは引き続き機能します。グリッドは、過半数の構成されたZooKeeperサーバーが動作していないため、動作しません。

• ZooKeeperサーバーへの認証済アクセスに使用する、インスタンスのユーザー名とパスワードを構成します。『Oracle TimesTen In-Memory Databaseセキュリティ・ガイド』のメンバーシップ・サービスのアクセス制御を参照してください。

ノート:

ZooKeeperサーバーのベスト・プラクティスの詳細は、Apache ZooKeerのWebサイトを参照してください。