このセクションでは、WebSphere Partner Gateway のインストール前に 考慮すべきいくつかの事項について説明します。適切な計画を立てることで、要件に適合した配置接続形態を決定できます。
システム・ダウン時間は、ビジネスの生産性および収益性に 深刻な影響を与えます。高可用性システムを構築すれば、システムが常に稼働しており、文書を受け取る準備のできている状態の、ハブ・コミュニティーを実現できます。標準的な高可用性環境では、システムは 99.9 パーセントの稼働時間を実現しています。システムによっては、99.999 パーセントを実現しているものもあります。可用性レベルは、システム障害、システムの過負荷、ネットワーク輻輳、およびネットワーク・アタックなどによって低下する場合があります。 可用性を最大化するには、システムに冗長性をもたせる必要があります。このためには、アーキテクチャー内の別個のサーバー上に、各論理機能 (Community Console、Receiver、および Document Manager) を 2 つ以上実装する必要があります。したがって、1 つのサーバー上に 3 つのコンポーネントをすべて置く場合は、冗長性を提供する別のサーバーが必要になります。各コンポーネントをユーザー自身のサーバー上に 別々に配置する場合は、冗長性を提供する合計 6 つのサーバーが必要になります。 さらに、災害時回復ロケーションに別のサーバー・セットを構築して、そのロケーションからシステムを稼働できるようにすることも考慮する必要があります。
高い可用性をもった WebSphere Partner Gateway を構築するには、それをサポートするインフラストラクチャー (ネットワーク、インターネット接続、および装置に入ってくる電力) も、高い可用性をもつ必要があります。高可用性は、MQ および RDBMS についてもあてはまります。これらのサポート・アプリケーションのいずれかに障害が 発生すると、実稼働環境にも障害が発生します。
WebSphere Partner Gateway は水平に拡張します。 これは、コンポーネントのインスタンスを追加すると、処理能力が高くなることを意味します。必要な実際の、サーバー数、特定コンポーネントのインスタンス、またはネットワーク機能は、次の要因によって異なります。
これらの要因が変化する場合は、コンポーネントの複数のインスタンスを追加することによって、WebSphere Partner Gateway を拡張できます。Receiver、Community Console、および Document Manager の各インスタンスは、独立して動作することができます。ただし、WebSphere Partner Gateway コンポーネントを冗長構成にする場合は、いくつかのことを考慮する必要があります。
WebSphere Partner Gateway を拡張する場合は、WebSphere MQ および RDBMS などの、サポート・インフラストラクチャーも拡張する必要があることに注意してください。
サーバーの構成が完了したら、システム・パフォーマンスをモニターして、要求に応じるために、いつ追加サーバーが必要なのか、また追加サーバーが必要かどうか を識別することが重要です。
データ・ストレージは、WebSphere Partner Gateway の前提条件であり、ユーザーの接続形態におけるキー・コンポーネントです。共用ストレージの要件をどのように 扱うかは、使用するストレージの要件および次の質問に対する答えによって異なります。
これらの領域でユーザーの要件が低い場合は、1 つ以上の WebSphere Partner Gateway コンポーネントが置かれているのと同じサーバーに、共用ストレージを実装することができます。そうでない場合は、WebSphere Partner Gateway とは別のサーバーに置く必要があります。 高可用性が必要な場合は、冗長性をもった NAS 製品の使用を考慮してください。この製品は、サーバーから独立して拡張することができます。RDBMS および WebSphere MQ を、NAS 上に置く必要はないことに注意してください。
WebSphere Partner Gateway は、標準的な機密保護機能のある環境内で 動作します。ただし、以下のことに注意する必要があります。
Community Console では、ロード・バランサーを使用する場合は、スティッキー・セッション (サーバー・アフィニティーとも呼ばれる) を使用可能にしておく必要があります。スティッキー・セッションを使用してロード・バランサーに指示を出し、構成された時間内に同じ IP アドレスからクライアント要求が送られてきた場合には、新規サーバーを選択せず、最後に指定されたのと同じサーバーにその要求が送信されるようにします。
Console は、1 つのセッションに対してブラウザーを介して送られてくるすべての要求が確実に同じサーバーに送られるようにするため、Cookie を使用します。スティッキー・セッションがオンになっていないと、Console からの各要求は、ロード・バランサーによって別のサーバーに送信される可能性があります。これは、問題の原因となります。例えば、Console はそのユーザーがログインしているとは見なしません。IP アドレス・レベルでスティッキー・セッションを使用可能にすると、Receiver も影響を受けるので、スケーリングに影響を与える可能性があります。ロード・バランサーは文書要求のたびに同じクライアント IP アドレスが使用されていることを認識するので、大量の文書を扱う参加者は文書を毎回同じ Receiver インスタンスに送信させることができます。別のオプションでは、Cookie の場合にのみスティッキー機能を使用可能にして、Receiver が影響を受けないようにすることができます。