CSA: アプリケーション サーバ、クラスタ、マルチキャスト メッセージング、およびロード バランサ(オンプレミスのみ)

ccppmop159
マルチキャスト メッセージング、ロード バランサ、およびセッション永続性(スティッキー セッション)をセットアップします。また、CSA を使用すると、スケーリングを行い、ディスクを共有し、ファイルをサーバに配布し、複数のアプリケーションまたはバックグラウンド サービス インスタンスを管理することができます。また、専用のレポート データベースを設定し、Oracle データベースのクラスタ化を実施して、Sun HotSpot JVM を調整することもできます。
2
クラシック PPM
のスケール
スケーリング
とは、実行するサービスおよびそれらを実行するコンピュータを決定する複雑なアクティビティを定義するものです。スケール アップまたはスケール ダウンを行う場合は、信頼性とパフォーマンスのバランスをとります。最も小規模な
クラシック PPM
インストールでも複数のコンピュータが関与しています。たとえば、インストールは通常、以下のように構成されます。
  • データベース用に 1 台、他のすべてに対してもう 1 台のサーバ。
  • クラシック PPM
    用に 1 台のコンピュータ(データベースを外部管理するグループが所有しているデータ センターに接続)。
中規模から大規模の
クラシック PPM
インストールの場合は、パフォーマンスと信頼性の要件に応じて、通常は、複数の専用コンピュータでサービスが重複して実行されます。
マルチキャスト メッセージング
クラシック PPM
では、クラスタ内で広範囲にマルチキャスト メッセージングを使用します。Beacon は、クラスタ内のすべての管理対象マシンで実行されるブートストラップ サービスです。Beacon は、各ボックス上の
クラシック PPM
サービスの管理およびモニタに使用されます。Beacon は、
クラシック PPM
アプリケーション サーバから配布されたパッチやアップグレードの適用にも使用されます。
Beacon サービスは、マルチキャストによる動的な検出メカニズムを採用しています。各 Beacon は 5 秒ごとに検出メッセージを送信し、クラスタ内でリッスンしているすべてのサーバにメッセージの存在を伝えます。
クラシック PPM
システム管理では、これらの Beacon 検出メッセージをリッスンし、それらのメッセージを使用してアクティブなクラスタ ノードを登録します。
クラシック PPM
システム管理は Beacon 検出メッセージを受信すると、Beacon のパスワードと自身のパスワードを照合します。照合に成功すると、
クラシック PPM
システム管理はそのサーバをサーバ リストに追加します。
また、
クラシック PPM
システム管理では、Beacon がアクティブかどうかを判断するために、10 秒ごとに直接、各 Beacon を ping します。ping は TCP (ユニキャスト)メッセージであるため、登録されている各 Beacon ごとに 1 つのメッセージがネットワーク経由で送信されます。マルチキャストの利点はここにあります。マルチキャスト メッセージはネットワーク経由で 1 回だけ送信され、関係者により複数回受信されます。これが(TCP ではなく) UDP の場合、メッセージはより軽量になります。ユニキャスト メッセージの場合は、ネットワーク経由で各関係者に 1 回ずつ送信する必要があります。したがって、マルチキャスティングは、Beacon のように動的に検出およびモニタするアプリケーションに最適です。
Beacon だけがマルチキャスティングを使用するサービスではありません。Beacon に加え、アプリケーション サーバやバックグラウンド サーバ内のキャッシュ管理サービスも、自身のメッセージをブロードキャストして、キャッシュの整合性を維持します。これらのメッセージには実データが含まれていません。常駐データが古くなり、データベースからの再ロードが必要になった場合にのみ、これらのメッセージはリモート サーバに情報を伝えます。このプロセスは、キャッシュのフラッシュと呼ばれています。クラスタ内の特定のサーバ上でキャッシュがフラッシュされるたびに、ネットワーク経由でメッセージが送信されます。その他のすべての app および bg サービスは、データのそれぞれのキャッシュをフラッシュすることを通知するメッセージを受信します。
クラシック PPM
では、セッション モニタ スレッドを使用して、異なるサーバ上のセッションが早期にタイムアウトにならないようにします。このスレッドは、アクティブ セッション ID を含むより長いメッセージと共に、5 分ごとにブロードキャストします。セッションが 1 つのサーバでアクティブでなくなった場合、すべてのサーバからそのセッションがフラッシュされます。セッションがアクティブな状態を保っている場合は、ユーザをログアウトしないように、他のすべてのサーバでもそのセッションの状態がアクティブと記録されます。
クラシック PPM
クラスタ内のサーバはマルチキャスト メッセージを送受信できる必要があります。標準のサブネットでは、このアクティビティは既定で許可されます。
ベスト プラクティスとして、同じサブネット内にすべてのサーバを保持します。別のサブネットを備えた別の場所でサーバを使用しなければならない場合は、それらの間にマルチキャスト ブリッジを作成します。
この方法は、余分な UDP トラフィックのように見えることがあります。しかし、データベース、レポート サーバ、アプリケーション サーバ、クライアントの間で伝送されるデータの量と比較すると、クラスタのメッセージングは些細な問題です。余分なトラフィックがネットワーク全体のトラフィックに対して占める割合はわずかです。多くの場合、人々はブロードキャストと聞くと、ネットワークに過負荷がかかると考えます。実は、すべてのネットワーク トラフィックはブロードキャストされているのです。サブネット上のすべての TCP (ユニキャスト)メッセージは、UDP (マルチキャスト)と同様に、サブネット内のすべてのノードに伝達されます。相違点は、TCP メッセージが UDP メッセージよりも 2 ~ 3 倍大きいことです。これは、TCP メッセージは到着が保証されているため、1 パケットあたり複数のハンドシェイクを必要とするためです。このプロセスは、TCP メッセージがより大きいことを意味します。さらに、
クラシック PPM
内のこれらのマルチキャスト メッセージは、平均的なデータベース リクエストと比較すると小さくなっています。高性能システム上では多数のアプリケーション サーバ、バックグラウンド サーバ、レポート サーバによって、毎秒何百ものデータベース リクエストが作成されています。5 秒間隔でサーバごとに送信される小さな UDP メッセージは、比較になりません。
Clarity
では、アーキテクチャに JGroups が導入されており、アプリケーション層内でのマルチキャスト メッセージングを制御します。以前までは、マルチキャストせずにアプリケーション層を実行できましたが、これからはバック グラウンド プロセス エンジンが更に関連するようになりました。これら 2 つのサービスが期待どおりに実行されない可能性があります。
Clarity
14.x および新しいリリースは、
Clarity
のクラスタ サービスが正しく通信できるように、通常、ルータのレイヤでマルチキャストをアクティブにする必要があります。
ロード バランサおよびセッション永続性 (スティッキー セッション)
クラシック PPM
では、ハードウェアまたはソフトウェアのロード バランサをサポートしています。
クラシック PPM
は完全にステートレスで、ラウンド ロビンやその他の分散モデルで機能するように設計されています。ただし、メモリとパフォーマンスの観点で最も効率的なのは、ユーザ セッションが 1 つのサーバに残っているときです。アプリケーション サーバをさらに追加することによって、パフォーマンスが向上します。
負荷分散環境では、セッション永続性が必要です。セッション永続性は、使用されるアルゴリズムやサーバに含まれているリソースの数に関係なく必要です。
例として、負荷分散アルゴリズムによって単一ユーザ セッションの個々の要求が 5 つのアプリケーション サーバにわたって分散されている状況を考えます。この場合、各サーバは、そのユーザ セッション データをロードしてキャッシュします。ユーザ セッションが 1 つのサーバにとどまるようにセッション永続性を有効にして使用する場合に比べて、5 倍のメモリを使用することになります。
ロード バランサでセッション永続性オプションを有効にすることを推奨します。
ソフト セッション永続性を使用するようにロード バランサを設定します。ソフト セッション永続性は、同じユーザ セッションからのリクエストを同じサーバに送信します。そのサーバが過負荷の状態になっているか、別のサーバがアイドル状態になっていると、過負荷のサーバからアイドル サーバにセッション維持性が移動されます。
クラシック PPM
はステートレスなので、このプロセスがサポートされます。さらに、過負荷のサーバが停止しても、それらのセッションは失われません。ロード バランサが、停止したサーバを正しく検出し、別のサーバにリクエストを転送するという前提で、それらのユーザ セッションは、新しいサーバで完全に利用可能となります。
ディスクの共有
クラシック PPM
クラスタでは、検索のインデックス付けのために複数の app および bg サービスで同じディスクを使用する必要があります。ファイルがデータベースに格納されていない限り、これらのサービスはドキュメントの保管にも同じディスクを使用する必要があります。
クラシック PPM
システム管理では、アプリケーションまたはバックグラウンド サービスを実行している各サーバで、[検索インデックス ディレクトリ]プロパティが確実に同じ共有ディスクをポイントするようにします。データベースにファイルを格納しない限り、[ファイル保存ディレクトリ]プロパティも、同じ共有ディスクをポイントする必要があります。
最も効果的にディスクを共有するには、Storage Area Network または Network Attached Storage ソリューションを使用します。また、UNIX NFS または Windows のファイル共有も許容可能です。
クラスタ内のサーバへのファイルの配布
更新されたファイルをクラスタ内のすべてのサーバに配布します。更新されたファイルには、UI テーマのカスタマイズや、ホット フィックス、パッチ、またはアップグレードのインストールによって更新されるアプリケーション サーバ上のファイルが含まれます。
[NSA ログ]をクリックし、nsa-ca.log を選択して配布のステータスを確認することもできます。完了すると、[ステータス]ウィンドウが閉じて、[親]ページが表示されます。[配布]ページに、最新の配布日付およびバージョンが表示されます。
以下の手順に従います。
  1. クラシック PPM
    システム管理(CSA)にログインします。
  2. [配布]を開き、[すべて配布]をクリックします。
    このオプションは、
    クラシック PPM
    ホーム ディレクトリ下に更新されたすべてのファイルを配布します。
  3. 1 台以上のリモート サーバを選択し、[配布]をクリックします。
複数のアプリケーションまたはバックグラウンド サービス インスタンス
大容量の物理メモリを備えた大型コンピュータを使用している場合は、これらのマシンで複数の app および bg サービス インスタンスを実行します。
クラシック PPM
の観点から見ると、これは 2 つの異なるコンピュータ上でサービスを実行するのと違いはありません。複数のサービスによってパフォーマンスと信頼性が向上するという利点と共に、コンピュータのフル パワーを引き出すことができます。
CSA では、クローン アクションを提供して、複数のインスタンスを簡単に実現します。この操作により、目的の app または bg サービスのコピーが作成され、競合を避けるために使用可能なポートおよびサービス名が増加します。
サービスのクローンを作成した後は、元のサービスと同様に新規サービス インスタンスを開始、停止、または管理できます。
以下の手順に従います。
  1. CSA にログインします。
  2. [ホーム]を開き、[すべてのサービス]をクリックします。
  3. クローンを作成するサービス タイプのチェック ボックスをオンにして、[クローン]をクリックします。
  4. 必要に応じて、サービスを作成したサーバに移動し、クローンの設定を変更します。
専用外部データ ソースの設定
セカンダリ データベースを使用してレポートを実行するように
クラシック PPM
を設定できます。セカンダリ データベースが、実稼働
クラシック PPM
データベースと適切に同期されていることを確認してください。レポート データベースと実稼働データベースが十分に連携していないと、問題が発生することがあります。たとえば、レポートに含まれるユーザまたはインスタンス データがレポート データベースに存在しないという状況になります。
レポートが以下の手順で示すように設定されていると、レポートはレポート データベースに対してのみ実行されます。レポートに必要なユーザおよびセキュリティ テーブルなどのすべてのテーブルが同期される必要があります。実稼働データベース テーブルのサブセットを同期する場合は、レポートをサポートする正しいテーブルを選択してください。
以下の手順に従います。
  1. CSA にログインし、[ホーム]の[サーバ]をクリックします。
  2. 設定するサーバの[プロパティ]アイコンをクリックします。
  3. [データベース]サブタブをクリックします。
  4. [内部接続: Niku]セクションで、[新規外部接続]をクリックします。
  5. レポート データベース用に適切なプロパティを設定します。
    • ID
      後でこの接続を識別するために使用される ID を定義します。
    • サービス名
      レポート サーバ上の有効な TNS エントリ(Oracle)または ODBC エントリ(MS SQL Server)を参照します。
  6. 変更を保存します。
  7. [レポート]サブタブをクリックします。
  8. 以下のフィールドに入力します。
    • データベース ID
      レポートを実行するときに、データベース情報を取得するために使用される
      クラシック PPM
      データベース ID。この ID は、データベースの[
      サーバ: プロパティ
      ]ページで定義されたデータベース接続の ID に相当します。
      値:
      Niku およびシステム
      既定値:
      Niku
      必須:
      いいえ
  9. 変更を保存します。
  10. クラシック PPM
    クラスタ内のすべてのサーバに対して前の手順を繰り返します。
  11. クラスタ内のすべての
    クラシック PPM
    アプリケーション(app)および
    クラシック PPM
    バックグラウンド(bg)サービスを再起動します。
  12. クラスタ内のレポート サーバごとに以下の手順を実行します。
    1. 専用のレポート データベース サーバをポイントする適切な接続プロパティを使用して、TNS エントリ(Oracle)または ODBC エントリ(SQL Server)を作成します。
    2. 選択した名前が
      クラシック PPM
      システム管理での外部接続用のサービス名に一致することを確認します。
  13. レポートをインストールします。
リリース 14.4 以前では、これらの手順を使用して、レポート、
クラシック PPM
ユニバース、および他のレポートの内容を BusinessObjects Enterprise レポート サーバにインストールできました。15.1 以降のリリースでは、データ ウェアハウス スキーマを使用する代わりに、またはそれを使用するのに加えて、これらの手順を使用して、レポートを実行するために並列トランザクション データベースをセットアップできます。この手順は、オン プレミス版の
Clarity
にデータ ソースを追加する場合に適用されます。たとえば、複製されたトランザクション スキーマ、外部データ ウェアハウス、または Oracle または MS SQL データベースに存在するサードパーティ アプリケーション スキーマを追加する場合です。
Oracle データベースの クラスタ化
クラシック PPM
では、単一の Oracle サーバの場合よりも高度なスケーラビリティ、冗長性、およびフェールオーバを提供するために Oracle クラスタを使用できます。
以下の手順に従います。
  1. 必要な場合は、既存の単一サーバ Oracle データベースを単一ノード インスタンスからエクスポートして、クラスタにインポートします。
  2. CSA にログインします。
  3. [ホーム]を開き、[サーバ]をクリックします。
  4. プロパティを編集するサーバの[プロパティ]アイコンをクリックします。
  5. [データベース]サブタブを選択します。
  6. データベース接続の以下のプロパティを編集します。
    • URL を指定
      選択済み。
    • JDBC URL
      完全修飾 Oracle クラスタ JDBC URL。この URL は完全な TNS 指定の前に付く接頭辞です。
      JDBC URL には、目的の RAC 設定が確立されている指定済み Oracle のホスト上の TNS エントリを参照する ServiceName パラメータが含まれている必要があります。
      例:
      jdbc:clarity:oracle://server:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      別の例:
      以下の DataDirect 構文で URL 自体に RAC サーバを埋め込みます。
      jdbc:clarity:oracle://server1:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(server2:1521;server3:1521);LoadBalancing=true
      SCAN リスナを備えた Oracle RAC サーバ:
      jdbc:clarity:oracle://oracscan:1521;ServiceName=serviceTNS;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true;AlternateServers=(oracscan:1521);FailoverMode=Select;ConnectionRetryCount=20;ConnectionRetryDelay=15;LoadBalancing=true"
      Oracle DataGuard:
      jdbc:clarity:oracle://PRIMARY_SERVER:1521;ServiceName=CLARITY_RW;AlternateServers=(PHYSICAL_STANDBY_SERVER:1521);ConnectionRetryCount=20;ConnectionRetryDelay=15;;BatchPerformanceWorkaround=true;InsensitiveResultSetBufferSize=0;ServerType=dedicated;supportLinks=true
      詳細については、以下のリソースを参照してください。
      RAC および DataGuard のセットアップ、SCAN、およびサービス セットアップに関する Oracle マニュアル。
      DataDirect Web サイト。DataDirect Connect for JDBC と Oracle Real Application Clusters (RAC) の連携に関する情報を検索します。
  7. 変更を保存します。
  8. データベース設定を検証するには、サーバごとにシステム ヘルス レポートを実行します。「ヘルス レポートの実行」を参照してください。
  9. Apache Tomcat アプリケーション サーバの場合は、
    クラシック PPM
    システム管理ですべてのサービスを再起動します。
Sun HotSpot JVM の調整
この情報は、Sun HotSpot JVM を含む環境にのみ適用されます。
クラシック PPM
を設定およびメンテナンスする際に、Sun HotSpot JVM を適切に調整することは重要な作業の 1 つです。適切な調整はバックグラウンド サービスにとって重要ですが、クラスタ内で実行されるすべてのアプリケーション サービスにとってさらに重要です。この記事ではアプリケーションに重点を置いています。
Oracle の Web サイトで、これらの設定に関するドキュメントを参照してください。実装に基づいた JVM ヒープ サイズのサイジングについて、Broadcom Service パートナーに問い合わせることもできます。
HotSpot JVM の調整には多数のオプションを利用できます。
ベスト プラクティス:
少なくとも以下の値を使用してください。
  • 最大ヒープ
    -Xmx<size>m
    最大ヒープの設定により、ローカル オペレーティング システムが Java VM に割り当てる最大メモリが決定します。ローカル オペレーティング システムは、起動直後は最大量のメモリを割り当てませんが、プロセスの実行状況に合わせてそれを割り当てることができます。ベスト プラクティスとして、小規模なインストールの場合でも、値を 2048m (2 GB)以上に設定してください。パフォーマンスを向上させ、メモリ不足エラーを減らすには、大きなデータ セット用にこの値を 4 GB または 8 GB に設定します。たとえば、-Xms1024m -Xmx4096m にします。
  • 最小ヒープ
    -Xms<size>m
    アプリケーションの増強に伴ってヒープを拡大する場合に、VM によって努力が無駄になるのを避けるために、最小ヒープの設定は重要です。可能な限り実情に近い最小のヒープを指定します。アプリケーションが通常 1.2 GB の RAM を使用している場合は、最小ヒープを 1200m に設定します。最小および最大のヒープ サイズを同一に設定できます。これによって、VM ガベージ コレクタに対する作業がより容易になります。また、これらの設定により、JVM プロセスが、起動時にオペレーティング システムの最大ヒープを割り当てるようになります(この方がより一貫性があります)。この処理では、サーバでの実際のメモリ割り当て所要量を測定する必要があります。
  • パラレル ガベージ コレクタ
    - XX: +UseParallelGC
    パラレル ガベージ コレクタは、2 つ以上の CPU を搭載しているサーバに対してお勧めします。パラレル ガベージ コレクタは、すべてのサーバ上に安全に設定できます。2 つ未満の CPU を搭載しているサーバはこの設定を無視します。
  • New 領域の比率
    -XX:NewRatio=<size>
    HotSpot VM は、メモリ内のオブジェクトの生存期間に基づいて、New 領域と Old 領域にオブジェクトを分離します。短期的なオブジェクトは、New (または Eden)領域にとどまる傾向にあり、他の場所に移動する前に収集されます。長期的なオブジェクトは Old (または Tenured)領域にマイグレートされます。New 領域の比率設定では、New 領域の明示的なサイズを実際に定義するのではなく、Old 領域と New 領域との比率を定義します。-XX: NewRatio=3 の設定は、1 対 3 の比率に翻訳され、New 世代のサイズは Old 世代の 1/3 になります。
    クラシック PPM
    などのサーバ側アプリケーションのように、多数の短期的な一時オブジェクトが迅速に作成および破棄されるアプリケーションでは、平均より大きな New 領域が必要となります。そのようにしないと、Old 領域に空きがある一方で、New 領域がオーバフローしてしまいます。New 領域の比率の既定値は、プラットフォームによって異なります。
    クラシック PPM
    での問題の発生を回避するために、プラットフォームにかかわらず、New 領域の比率として 1 対 2 を設定します(
    XX:NewRatio=2
    )。
  • Permanent 領域の最大サイズ
    -XX:MaxPermSize=<size>m
    New 領域と Old 領域に加え、Permanent 領域という名前の 3 番目の領域があります。この領域には、永続オブジェクト(主として Java クラス定義)が存在します。この領域は、アプリケーションの使用量ではなく、アプリケーションのサイズにより拡大します。アプリケーションにロードされるクラスが多いほど、Permanent 領域のサイズが大きくなります。既定の設定値 64m では小さすぎることが判明しています。Apache Tomcat の場合、この領域に対する既定の
    クラシック PPM
    設定値は 256m です。