...

前提条件

• 複数の Virtualize サーバー。すべて同じバージョン (同じサービス パックを含む) であり、すべて Virtualize コマンド ライン (virtualizecli) のライセンスがあること。
• 複数の Virtualize インスタンスをホストするための複数のサーバー
• source address affinity persistence をサポートするロード バランサー
• ソース管理システムへのアクセス

ロード バランサーの構成

それぞれの Virtualize サーバーに向かうようロード バランサーを設定します。Parasoft CTP を使用している場合 (あるいは、Virtualize REST API によってアセットとやり取りする他の任意のツールを使用している場合)、さらに以下のセクションで説明する設定も行う必要があります。

以下の操作手順は任意のロード バランサーに適用できます。F5 Local Traffic Manager (LTM) を例として、これらの一般的なガイドラインが特定のロード バランサーでどのように実行されるかについて説明します。

Source Address Affinity Persistence の設定

このセクションでは、Parasoft CTP 用に source affinity persistence を設定する方法について説明します。Virtualize REST API によってアセットとやり取りする他のツールにも、同じ手法を適用できます。によってアセットとやり取りするツールであれば、同じ手法を適用できます。

source address affinity persistence は、CTP からのすべての呼び出しが同じノードに行くことを保証します。この session affinity は、"スティッキー セッション" としても知られます。

...

Priority-based Member Activation の使用

あらゆるソースからのすべての呼び出しが最初にメイン マシンに行くことを保証します (それが可能な場合)。この設定を行うには、1 番目のマシンを最高の優先度として設定します。たとえば、以下は Local Traffic Manager についての F5 ドキュメントに記載されているプール構成例です。

pool my_pool { lb_mode fastest min active members 2 member 10.12.10.7:80 priority 3 member 10.12.10.8:80 priority 3 member 10.12.10.9:80 priority 3 member 10.12.10.4:80 priority 2 member 10.12.10.5:80 priority 2 member 10.12.10.6:80 priority 2 member 10.12.10.1:80 priority 1 member 10.12.10.2:80 priority 1 member 10.12.10.3:80 priority 1 }

Virtualize の設定

Virtualize のロード バランシングの設定を開始する前に、変更が 1 個のノードにだけ反映されるようにロード バランサーを設定していることを確認してください。 

...

Virtualize クラスタでのデプロイは最終的に同期されます。リクエスト デプロイが送られると、1 つのサーバーがリクエストを処理してレスポンスを返します。ファイル システムは、クラスタ中の他のサーバーに、一致のために必要な変更を行うよう通知します。場合によっては、これには数秒かかることがあります。結果として、短い時間、別のサーバー上で発生したデプロイメントを一部のサーバーが認識していないという状況が発生する場合があります。

Parasoft Data Repository の設定

MongoDB をベースとする Parasoft Data Repository は、プライマリ データ リポジトリ (レプリケートしたいデータがあるデータ リポジトリ) を特定し、レプリカ セットを作成することによって、クラスタリングのために構成するべきです。それには、以下の操作を行います( この操作は、MongoDB ドキュメントからの内容を変更したものです。)。

1. レプリカ セットの一部にしたい Data Repository をすべて停止します。

2. プライマリ リポジトリ サーバーを起動します:

   Code Block
   language powershell
   ./bin/mongod --port 2424 --dbpath repositories

   repositories ディレクトリが存在しない場合は、作成する必要があります。

3. mongo シェルに接続し、管理データベースを作成します。

   Code Block
   language powershell
   ./bin/mongo --port 2424 use admin

4. 次のコマンドを実行して、管理ユーザーを作成します:

   Code Block
   language powershell
   db.createUser({user:"<username>",pwd:"<password>",roles:[{role:"root",db:"admin"}]});

   ユーザーが既に存在するためにコマンドが失敗した場合は、次のコマンドを実行します:

   Code Block
   language powershell
   db.grantRolesToUser('admin',[{role:"<role>"}])

5. プライマリ mongo サーバーを停止します。

6. キー ファイルを作成します。次の例は、基本的なコマンドを示しています:

   Code Block
   language powershell
   openssl rand -base64 741 > mongodb-keyfile chmod 600 mongodb-keyfile

7. キー ファイルをレプリカ セットの各メンバーにコピーします。

8. 次のコマンドを使用して、レプリカ セットの各メンバーを起動します:

   Code Block
   language powershell
   ./bin/mongod --replSet "rs0" --dbpath repositories --port 2424 --auth --keyFile <mongodb-keyfile>

9. プライマリ サーバーで、mongo シェルに接続し、問い合わせがあったらパスワードを入力します:

   Code Block
   language powershell
   ./bin/mongo localhost:2424/admin -u <admin_user> -p

10. 次のコマンドを実行して認証を確認します:

    Code Block
    language powershell
    use admin db.auth("<siteRootAdmin>", "<password>");

    シェルは 1 を返すはずです。

11. 次のコマンドを使用して、レプリカ セットを開始します:

    Code Block
    language powershell
    rs.initiate()

12.  次のコマンドを使用して、レプリカ セットの構成を確認します:

    Code Block
    language powershell
    rs.conf()

    プライマリ サーバーのホストが正しくない場合は、次のコマンドを使用してホストを変更します:

    Code Block
    language powershell
    cfg = rs.conf() cfg.members[0].host = "mongodb1.example.net:27017" rs.reconfig(cfg)

13.  セカンダリ サーバーごとに、プライマリ サーバーの mongo シェルで次のコマンドを実行します:

    Code Block
    language powershell
    rs.add("<secondary>:<port>")

追加情報

• CTP および Virtualize Desktop は、ライブ アセットを変更できます。ロード バランサーを介してノードがやり取りする場合、CTP と Virtualize はクラスタを単一サーバーとして扱います。CTP に送られるサーバー名 (Virtualize サーバーまたは localsettings.properties で設定される) は、すべてのノードで同じでなければなりません。
• クラスタ化された環境ではレコーディングはサポートされません。レコーディングは、アセットプロモーションの前に自分のステージング インフラストラクチャで実行するべきです。
• すべてのテスト対象アプリケーションのトラフィックは、ロード バランサーに送られ、設定によって適切にフィルタリングされます。バランサーに送られ、設定のスティッキー セッションを使って適切にフィルタリングされます (「Configuring Source Address Affinity Persistence」を参照)。
• 変更が 1 つのサーバーにのみ送信されるようにします。クラスタ中の 1 つのノードに構成/"change" メッセージを送るよう Virtualize サーバーのロード バランサーを設定するべきです。Virtualize サーバーのロードバランサーは、configuration/‘change’ メッセージをクラスター内の単一ノードに送信するように構成する必要があります。この設定は、Virtualize Desktop または CTP から送られる " 変更" を処理する ポート (デフォルトは 9080/9443) あるいはパス (/axis2 SOAP または /soavirt/api/REST) のために行うべきです。
• ステートフル アセットの一貫した動作を保証します。Virtualize サーバーのロード バランサーは、単一セッションのすべてのトラフィックを単一ノードに向かわせなければなりません。 
• ステートフル アセットのトラフィックは、1 つのノードにだけ送るべきです。複数のアセットがステータスを複数回変更しないよう、"最初に利用可能" モードでトラフィックを実行するべきではありません。
• ステートフル アセットがセッションをまたがってそのステータスを保持することを目的とする場合、ノードは同期データ ソース (つまりデータ リポジトリ) でステータスを格納する必要があります。ただし、「データ リポジトリの更新」と「更新された情報の後続のリクエスト」との間に遅延があることに注意してください。