大規模な IBM® WebSphere® Application Server クラスターは、フロントエンドの HTTP サーバーとプロキシー・サーバー、および要求をクラスター内で送信するロード・バランサーで構成されています。
制約事項: アプリケーション・サーバーのクラスターを作成および使用するには、
IBM WebSphere Application Server Network Deployment (ND) が必要です。これは、
IBM Rational® Asset Manager にバンドルされていません。
WebSphere Application Server は、垂直方向のスケーリングと水平方向のスケーリングの両方が可能です。専用のデータベース・サーバーとファイル・サーバーを使用してください。WebSphere Application Server をどの程度スケーリングできるか、および何台のサーバーを使用できるかは、サーバー要求のタイプと規模およびアセットの数によって決まります。
- IBM HTTP Server
- 最初の層は HTTP サーバーです。HTTP サーバーは、Web クライアントからの要求を処理し、静的コンテンツを提供する作業からアプリケーション・サーバーを解放します。IBM Rational Asset Manager アプリケーション、Rational Asset Manager ヘルプ・アプリケーション、Rational Asset Manager アセット・ベースの開発アプリケーションなどの補助アプリケーションを包括した 1 つの論理 URL を提供します。大規模な構成では、HTTP サーバーの前にキャッシュ・サーバーがデプロイされることに注意してください。
- ロード・バランサー
- ロード・バランサーは、負荷を多数のシステムに分散します。複数の HTTP サーバーがある場合、ロード・バランサーを使用する必要があります。中規模なデプロイメントでは、Edge Component のようなソフトウェア・ベースのロード・バランサーを使用します。多数の同時ユーザーをサポートする大規模なデプロイメントでは、ハードウェア・ベースのロード・バランサーを使用します。
- キャッシュ・プロキシー
- フォワード・キャッシング・プロキシー・システムは、クライアント用のアプリケーション・データをキャッシュに保管して、他のサーバー・システムの負荷を軽減します。
Rational Asset Manager サーバーでサポートする同時ユーザーの数が中規模である場合、フォワード・プロキシー・システムは 1 つのみで十分です。Rational Asset Manager サーバーで大規模数の同時ユーザーをサポートする場合、複数のプロキシー・システムが必要になることがあります。
- Application Server
- Rational Asset Manager EAR ファイルは、リポジトリーおよび Web アプリケーション・ファイルと、Web サービス・ファイルという 2 つの WAR ファイルから構成されています。クラスター内のすべての WebSphere Application Server インスタンスに Rational Asset Manager EAR ファイルをデプロイします。Rational Asset Manager には、ヘルプおよび IBM Rational Unified Process (RUP) の WAR ファイルも含まれます。これらの WAR ファイルは、デプロイする必要がありません。ヘルプおよび RUP のサポート機能に高可用性が必要でない場合は、これらを単一の WebSphere Application Server インスタンスまたは外部 WebSphere Application Server コンテナーにデプロイします。
- Rational Asset Manager アプリケーション
- Rational Asset Manager リポジトリーは検索およびデータの取得のために正規化され、データの検索、成果物の参照、およびアセットのダウンロードをより効率的に行うことができるように設計された方法でデータが保管されるようになっています。このために、すべての Rational Asset Manager サーバー・インスタンスが、アセット用のローカル索引を 1 つと、成果物用のローカル索引を 1 つ作成します。
これにより検索パフォーマンスが最適化され、データベースの負荷が軽減されてクラスター環境におけるスケーラビリティーが向上します。ローカル索引ディレクトリーは、ノード間で共用される索引よりもパフォーマンスが高い場合があります。
- データベース・
サーバー
- データベースのハードウェアを選択する際の最も重要な考慮事項となるのは、マシンのディスク数およびマシンが使用する RAID スキーマです。1 つの RAID アレイには、プロセッサーごとに最低でも 6 から 10 個のドライブが含まれる必要があります。メモリーも重要な項目ではありますが、1000 人のユーザーおよび 50,000 個のアセットがある場合に、データベース・サーバー構成のメモリーが 4 GB であっても 8 GB であっても大きな違いはありません。
- データベースのディスク・スペース要件は、アセットの数、アセットごとの成果物の数、チーム・スペースの数、ロールの数、レビューの数、アセット・タイプの数、ユーザーの数、サーバーのトランザクション量 (ユーザー・メトリック)、フォーラム・ディスカッションの量など、多くの要因によって異なります。
- ファイル・サーバー
- アセットは WebSphere Application Server インスタンス間で共用される必要があります。
同時アクセス可能なファイル・システムを使用してください。Rational Asset Manager がこれらのファイルにアクセスするのは、アップロード、ダウンロード、成果物の索引付けを行うとき、およびアセット・マニフェストの更新が必要になるような大幅な変更を Rational Asset Manager モデルに加えるときのみです。
クラスタリング・トポロジー
クラスタリングとは、マシンのグループを、1 台のマシンであるかのように参照できる論理エンティティーに結合することです。このセクションでは、さまざまなクラスター構成とそれぞれの主要な利点および欠点について説明します。
- 水平方向のクラスタリング
- 水平方向のクラスタリング (スケールアウトと呼ばれることもある) とは、物理的にマシンを追加して、クラスター・プールのパフォーマンスや容量を向上させることです。通常、水平方向のスケーリングでは、クラスター・アプリケーションの可用性は向上しますが、その反面、保守の必要性が増します。水平方向のクラスタリングによって、クラスター・アプリケーションの容量やスループットを向上させることができるため、ほとんどの場合は、このタイプのクラスタリングを使用します。
- 垂直方向のクラスタリング
- 垂直方向のクラスタリング (スケールアップと呼ばれることもある) とは、同一のマシンに WebSphere Application Server インスタンスを追加することです。垂直方向のスケーリングは、大規模な SMP サーバーでの未使用のリソースの活用に役立ちます。垂直方向のクラスタリングによって、複数の JVM プロセスを作成し、これらのプロセスすべてで、使用可能なすべての処理能力を使用することができます。
- 水平方向のクラスタリングと垂直方向のクラスタリングのハイブリッド
- ハイブリッド・クラスタリングは水平方向のクラスタリングと垂直方向のクラスタリングを組み合わせたものです。この構成では、異なるハードウェア構成が同一のクラスターのメンバーになっています。
大規模でより能力の高いマシンには複数の WebSphere Application Server インスタンスを配置し、小規模なマシンには水平方向のクラスタリングを適用して単一の WebSphere Application Server インスタンスを配置することができます。
- 垂直方向のクラスタリングを使用する場合には注意が必要です。ご使用の環境およびアプリケーションに何が適切かを判別する唯一の方法は、アプリケーション・サーバーの単一インスタンスをスループットおよびパフォーマンス用に調整し、それをクラスターに追加して、徐々に追加クラスター・メンバーを増やすことです。クラスターにメンバーを追加するごとに、パフォーマンスとスループットをテストします。垂直方向のスケーリング・トポロジーを構成する場合は、必ずメモリー使用量を慎重にモニターしてください。アドレス可能ユーザー・スペースの量や、マシンで使用可能な物理メモリーの量を超過しないようにしてください。
スケーラビリティー
スケーラビリティーとは、サイトをどの程度容易に拡張できるかを示します。Rational Asset Manager インストール済み環境でのユーザー数、アセット数、およびコミュニティー数は、増大する負荷に対応するために拡張可能である必要があります。一連の Rational Asset Manager ユーザーにチームや部門を追加したり、Rational Asset Manager に大量のヒストリカル・アセットをインポートしたりするなど、負荷の増大には多くの原因があります。
スケーラビリティーは、ご使用のアーキテクチャーの設計の推進要因となる考慮事項です。
システムにハードウェアを追加することによってスケーラビリティーが改善されても、パフォーマンスやスループットが向上しない場合があります。
スケールアップ (垂直方向のクラスタリング) とスケールアウト (水平方向のクラスタリング) のいずれを選択するかは、通常、好み、コスト、およびご使用の環境の特性を考慮して決定します。ただし、アプリケーションの対障害弾力性の問題は、どちらを選択するかの好みに影響を与える可能性があります。
- スケールアップでは、多くのプロセッサーと大量のアドレス可能ユーザー・スペース・メモリーを持つ少数のマシンに、垂直方向のスケーリングが実装されます。
この場合、ご使用の環境は少数の大規模マシンで構成されるため、重大な単一障害点 (SPOF) が存在することになります。
- スケールアウトでは、多数の小規模マシンが使用されます。このシナリオでは、1 台の小規模サーバーの障害によってアプリケーションが完全に停止することはほとんどありません。ただし、スケールアウトでは、より多くの保守作業が必要となります。
可用性
可用性とは、耐障害性または対障害弾力性とも呼ばれ、コンポーネントやシステムに障害が発生しても運用を継続させるシステムの性能のことです。
水平方向のスケーリングと垂直方向のスケーリングのいずれを使用するか、およびバックアップのロード・バランサー (つまり、ディスパッチャー) を使用するかどうかなど、アーキテクチャーに関する決定が Rational Asset Manager アプリケーションの可用性に影響を与える場合があります。
Rational Asset Manager 環境を構成するすべての共用リソース、ネットワーク、およびディスク・ストレージ・システムの可用性を考慮します。
耐障害設計では、アプリケーションまたはサーバーに障害が発生した場合に、クラスターの他のメンバーが引き続きクライアントにサービスを提供できます。
フェイルオーバーには、サーバー・フェイルオーバーとセッション・フェイルオーバーの 2 つのカテゴリーがあります。
サーバー・フェイルオーバーが発生すると、障害が発生したクラスター・メンバーでのセッションは失われますが (ユーザーは再度ログインする必要があります)、クライアントには引き続きサービスが提供されます。セッション・フェイルオーバーでは、クラスター・メンバーに障害が発生していないかのように、クラスターの他のメンバーによって既存のセッションが再開されます (ただし、最後のトランザクションは失われる場合があります)。
サーバー・フェイルオーバーに対処するように冗長インフラストラクチャーが構成されている場合は、Rational Asset Manager によってその冗長インフラストラクチャーがサポートされます。