Parasoft Virtualize サーバーのクラスタをセットアップして、水平スケールとフォールト トレランスを実現できます。水平スケールは、一般的にパフォーマンス テストおよび継続的インテグレーション/継続的デリバリのためのクラウド ベースのインフラストラクチャを最適化するために使用されます。フォールト トレランスは、一般的にアップタイムを増加したり、ビジネスに不可欠なバックエンド システムの障害復旧を容易にしたりするために使用されます。

このセクションの内容:

要件

• 複数の Virtualize サーバー。サーバーは、同じサービス パック (該当する場合) を含め、まったく同じバージョンである必要があり、すべてサーバー ライセンスが必要です。
• 複数の 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 は、"スティッキー セッション" としても知られます。

以下のポートについて source address affinity persistence を有効化します:

• 9080 - Virtualize デフォルト HTTP コネクター (必須)
• 9443 - Virtualize デフォルト SSL コネクター (必須)
• 2424 - Data Repository (Data Repository がこのノードに存在する場合、必須)
• 9617 - ビルトイン イベント モニター プロバイダー サービス (Active MQ)
• 9618 - ビルトイン サーバー ヒット統計プロバイダー サービス
• 9619 - ビルトイン JDBC プロバイダーサービス

F5 Local Traffic Manager (LTM) では、[Match Across Services] および [Match Across Virtual Servers] オプションを有効にすることで、source address affinity persistence が設定されます。たとえば source address affinity persistence を F5 LTM で実装したい場合、デフォルトの source_addr プロファイルを使用するか、カスタム プロファイルを作成することができます。以下の表は、デフォルトの source_addr プロファイルの設定と値です。

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 個のノードにだけ反映されるようにロード バランサーを設定していることを確認してください。 

1. VirtualAssets プロジェクトとそのすべての関連内容 (.pmpdd、.pvadd、.pjcdd、VirtualAssets.xml、.git など) をクラスタ間で共有します。共有を同期するために、コミット後トリガーとして git fetch コマンドを使用することをお勧めします。
2. ネイティブフックまたはポーリングを使ってリフレッシュを有効にします。
   • GUI から: 
     1. Virtualize のメイン メニューから [ウィンドウ] > [設定] > [全般] > [ワークスペース] を選択します。
     2. [Refresh using native hooks or polling] オプションを有効にし、サーバーを再起動します。
        
   • コマンドラインから:
     1. <WORKSPACE>/.metadata/.plugins/org.eclipse.core.runtime/.settings/ ディレクトリにある org.eclipse.core.resources.prefs ファイルを開きます。

     2. refresh.enabled=true プロパティを追加します。例:
        

        eclipse.preferences.version=1 
        version=1
        refresh.enabled=true

     3. サーバーを再起動します。

3. クラスタのすべてのノードで起動コマンドに以下の Java オプションを追加します。
   
   -J-Dparasoft.auto.deploy.new=false
   
   
4. サーバーを再起動します。

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

Parasoft Data Repository の設定

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

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

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

   ./bin/mongod --port 2424 --dbpath repositories

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

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

   ./bin/mongo --port 2424 
   use admin

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

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

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

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

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

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

   openssl rand -base64 741 > mongodb-keyfile
   chmod 600 mongodb-keyfile

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

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

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

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

   ./bin/mongo localhost:2424/admin -u <admin_user> -p

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

    use admin 
    db.auth("<siteRootAdmin>", "<password>");

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

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

    rs.initiate()

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

    rs.conf()

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

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

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

    rs.add("<secondary>:<port>")

追加情報

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