この章では、Oracle Web Cacheを使用した高可用性ソリューションの構成方法と実装方法について説明します。
この章の項目は次のとおりです。
Oracle Web Cacheには、キャッシュ・ミスを送信するWebアプリケーション・サーバーまたはプロキシ・サーバーを構成できます。Oracle Web Cacheでは、通常、内部サイトにWebアプリケーション・サーバーを使用し、ファイアウォールの外側にある外部サイトにはプロキシ・サーバーを使用します。
この項では、次の概念について説明します。
オリジナル・サーバーの構成方法は、第2.11.2項を参照してください。
Oracle Web Cacheは、キャッシュ不可、失効またはキャッシュにないオブジェクトに対するリクエストを、オリジナル・サーバーに渡します。Oracle Web Cacheには、オリジナル・サーバーに対するリクエストのオーバーロードを防ぐために、急激な過負荷を回避する機能が備わっています。これにより、オリジナル・サーバーが処理する同時リクエスト数を制限できます。制限に達すると、後続のリクエストはキューに入れられます。キューが満杯になると、リクエストはOracle Web Cacheにより拒否され、リクエストを送信したクライアントにサイト・ビジー・エラーのページが表示されます。
ほとんどのWebサイトは、HTTPおよびHTTPSリクエストの負荷を共有する、複数のコンピュータ上で稼働する複数のオリジナル・サーバーによって運営されています。Oracle Web Cacheで処理できないリクエストは、すべてオリジナル・サーバーに渡されます。Oracle Web Cacheは、各オリジナル・サーバーで使用可能な許容量の割合である許容負荷容量を判断することで、オリジナル・サーバー間の負荷を均衡させます。Oracle Web Cacheでは、許容負荷容量が最も大きいオリジナル・サーバーにリクエストを送信します。許容負荷容量の合計は、次の数式によって計算されます。
(Capacity - Load) / Capacity
この計算式の詳細は、次のとおりです。
Capacity
は、オリジナル・サーバーが受け入れることのできる最大同時接続数を表します。
Load
は、現在使用されている接続数を表します。
複数のオリジナル・サーバーの許容負荷容量が同じである場合、Oracle Web Cacheはラウンドロビン法を使用してリクエストをそれらのオリジナル・サーバーに送信します。ラウンドロビン法とは、構成済サーバーのリストの中で1番目のオリジナル・サーバーが最初にリクエストを受け取り、2番目のオリジナル・サーバーが次のリクエストを受け取る、というようにしてリクエストを振り分けるものです。許容負荷容量が同じではない場合、Oracle Web Cacheでは、許容量が最も大きいオリジナル・サーバーにリクエストを送信します。
オリジナル・サーバーの負荷が同じ場合は、オリジナル・サーバーに対する容量が同じでない場合でも、Oracle Web Cacheはラウンドロビン法を使用します。したがって、容量が同じになるように構成されていない場合は、オリジナル・サーバーへのリクエストが均等に分散されているかを調べることが可能です。
サイトのロード・バランシングを構成するには、各オリジナル・サーバーの許容量を設定し、該当するオリジナル・サーバーをすべてマップする、サイトからサーバーへのマッピング・ルールを1つ作成します。
構成の詳細は、次を参照してください。
図3-1には、www.company.com:80
およびwww.server.com:80
という2つのサイトが示されています。サイトwww.company.com:80
は、アプリケーション・サーバーcompany-host1
およびcompany-host2
によってサポートされています。それぞれのWebアプリケーション・サーバーの許容量はともに50です。サイトwww.server.com:80
は、アプリケーション・サーバーserver-host1
、server-host2
およびserver-host3
によってサポートされています。各アプリケーション・サーバーの許容量はそれぞれ150、50、50です。
各Webアプリケーション・サーバーの初期の負荷が0であった場合、Oracle Web Cacheはwww.company.com:80
およびwww.server.com:80
へのリクエストを次の方法で分散します。
Oracle Web Cacheはラウンドロビン法を使用して、www.company.com:80
へのリクエストを2つのアプリケーション・サーバーに分散します。
Oracle Web Cacheはcompany-host1
およびcompany-host2
へのリクエストを、2つのアプリケーション・サーバーの負荷を等しく保持するように分散します。最初のリクエストは、company-host1
に送信されます。2番目のリクエストは、company-host1
が最初のリクエストをまだ処理中の場合、company-host2
に送信されます。3番目以降のリクエストは、許容負荷容量が最も大きいアプリケーション・サーバーに送信されます。
許容量が同じ場合、Oracle Web Cacheはラウンドロビン法を使用してリクエストを分散します。
Oracle Web Cacheは許容負荷容量のパーセンテージに基づいて、www.server.com:80
へのリクエストを3つのオリジナル・サーバーに分散します。
www.server.com:80
への最初のリクエストは、構成済リストの最初にリストされているserver-host1
に送信されます。2番目のリクエストはserver-host2
に送信されます。これは、server-host1
が最初のリクエストの処理中で許容負荷容量が99.3%であり、server-host2
の許容負荷容量が100%であるためです。3番目のリクエストはserver-host3
に送信されます。これは、server-host2
がリクエストの処理中で許容負荷容量が98%であり、server-host3
の許容負荷容量が100%であるためです。4番目のリクエストはserver-host1
に送信されます。これは、server-host2
およびserver-host3
がリクエストの処理中で許容負荷容量が98%であるためです。5番目のリクエストは、server-host1
に送信されます。これは、このサーバーの許容負荷容量が98.6%で、server-host2
およびserver-host3
の許容負荷容量よりも大きいためです。
許容量と負荷が同じでない場合、Oracle Web Cacheは許容負荷容量を使用してリクエストを分散します。新規リクエストが着信する前にリクエストが処理された場合は、3つのオリジナル・サーバーの負荷がすべて0(ゼロ)になる可能性があります。この場合、Oracle Web Cacheはラウンドロビン法を使用します。
キャッシュ・サポートが不要で、ハードウェア・ロード・バランサに対して安価なソリューションが必要な場合は、Oracle Web Cacheをソフトウェア・ロード・バランサとして専用に構成できます。このような構成モードは、小規模Webサイト、部門別WebサイトまたはテストWebサイトへのトラフィックの管理に役立ちます。詳細は、第3.4項を参照してください。
リクエストが指定された回数を連続で失敗すると、Oracle Web Cacheにより、そのオリジナル・サーバーに障害が発生したとみなされます。オリジナル・サーバーで障害が発生した場合、Oracle Web Cacheは、負荷を自動的に残りのオリジナル・サーバーに分散し、障害の発生したオリジナル・サーバーが再びオンラインになるまで、その稼働または停止状況をポーリングします。障害の発生したオリジナル・サーバーへの既存リクエストについては、エラーが発生します。新規リクエストは、他のオリジナル・サーバーに転送されます。障害の発生したサーバーが稼働状態に戻ると、Oracle Web Cacheはそのサーバーの許容負荷容量も含めて、リクエストのロード・バランシングを行います。
リクエストの失敗回数の構成の詳細は、第2.11.2項を参照してください。
図3-2にフェイルオーバー機能を示します。許容量50のserver-host3
に障害が発生すると、リクエストの75%はserver-host1
に配信され、25%はserver-host2
に配信されます。
特定サイトのユーザー・セッションをオリジナル・サーバーにバインドし、一定期間、状態を維持できるようにする機能を持つセッション・バインディングをサポートするように、Oracle Web Cacheを構成できます。この機能を使用するには、オリジナル・サーバー自体が状態を維持する(ステートフルである)必要があります。
セッション・バインディングを必要とするオブジェクトに対してリクエストがオリジナル・サーバーに転送されると、オリジナル・サーバーは、クライアントへのセッション情報をOracle Web Cache経由でセッションCookieまたは埋込みURLパラメータの形で含めることにより、ユーザー・セッションを作成します。Oracle Web CacheはパラメータまたはCookieの値を処理せず、情報を単にクライアントのブラウザに戻します。クライアントがセッション情報を後続のリクエストに含めると、Oracle Web Cacheは、ユーザー・セッションを作成したオリジナル・サーバーにリクエストを転送します。Oracle Web Cacheは、ユーザー・セッションをその特定のオリジナル・サーバーにバインドします。
図3-3に、Oracle Web Cacheがセッション・バインディングを使用するオブジェクトをサポートする仕組みを示します。
リクエストにおけるセッション・バインディングの動作ステップは、次のとおりです。
Oracle Web Cacheは、リクエストを初めて受信したときに、ロード・バランシング機能を使用してリクエストを転送するオリジナル・サーバーを決定します。この図の例では、アプリケーション・サーバーwww.server2.com
が選択されています。
リクエストされたオブジェクトにセッション・バインディングが必要な場合、オリジナル・サーバーは、Oracle Web Cacheを通じて、セッション情報をCookieまたは埋込みURLパラメータの形でクライアントに送り返します。
そのセッションの後続のリクエストについては、Oracle Web Cacheは、ロード・バランシングをバイパスして、セッションを確立したオリジナル・サーバーに送信します。この例では、アプリケーション・サーバーwww.server2.com
によって後続のリクエストが処理されます。
オリジナル・サーバーの構成方法は、第2.12項を参照してください。
キャッシュ・クラスタを構成する場合、セッション・バインディングを構成する際に「内部-トラッキング」メカニズム・オプションを選択しないでください。このオプションはキャッシュ・クラスタでは使用できません。他のメカニズムはキャッシュ・クラスタで使用できます。詳細は、第3.6.4項を参照してください。
注意:
|
キャッシュ・クラスタでは、Oracle Web Cacheの複数のシステム・コンポーネントが1つの論理キャッシュとして動作します。この論理キャッシュは、キャッシュ・クラスタ・メンバーと呼ばれます。キャッシュ・クラスタ・メンバーは、他のキャッシュ・クラスタ・メンバーがキャッシュしているキャッシュ可能なコンテンツをリクエストしたり、キャッシュ・クラスタ・メンバーに障害が発生したことを検出するために互いに通信する。
図3-4は、3つのキャッシュ・クラスタ・メンバーを持つOracle Web Cacheクラスタを示しています。この図に示されるように、クラスタ・メンバーは互いに通信するのみでなく、Webアプリケーション・サーバーやクライアントとも通信します。
Oracle Web Cacheでは、各キャッシュ・インスタンスの相対許容量によって、キャッシュされたコンテンツをキャッシュ・クラスタ・メンバーに分散します。実際には、特定のオブジェクトの所有権を持つキャッシュ・クラスタ・メンバーを割り当てます。このコンテンツは所有コンテンツと呼ばれます。
所有コンテンツに加えて、Oracle Web Cacheは、各クラスタ・メンバーのキャッシュ内にポピュラーなオブジェクトも保存します。このようなオブジェクトはオンデマンド・コンテンツと呼ばれます。オンデマンド・コンテンツを保存することで、Oracle Web Cacheはポピュラーなオブジェクトへのリクエストに素早く応答できるようになり、キャッシュ・ミスの回数も減ります。またWebアプリケーション・サーバーに送信されるリクエストの数も減ります。結果としてパフォーマンスが改善されます。
キャッシュ・クラスタは、クラスタの全メンバーと同期する単一の構成を使用します。この構成には、セキュリティ、セッション情報、キャッシュ・ルールなどの一般的な情報が含まれており、これらがクラスタの全メンバー間で同一になります。また、容量、管理用などのポート、リソース制限、ログ・ファイルなど、クラスタの各メンバーで異なるキャッシュ固有の情報も含まれています。
各メンバーは、キャッシュ・クラスタに追加される前に認証を受ける必要があります。認証では、追加されるOracle Web Cacheインスタンスの管理者ユーザー名とパスワードが、クラスタの管理者ユーザー名とパスワードと同じであることが必要です。
クラスタにキャッシュを追加すると、新しいクラスタ・メンバーのキャッシュ固有の情報がキャッシュ・クラスタの構成に追加されます。次に、この構成はOracle Web Cacheによってクラスタの全メンバーと同期されます。新しいメンバーを追加することは各Webキャッシュの相対許容量を変えることになるので、Oracle Web Cacheは容量についての情報を使用して、どのクラスタ・メンバーがどのコンテンツを所有するのかを再計算します。
他のクラスタ・メンバーの障害をキャッシュ・クラスタ・メンバーが検出した場合、残りのキャッシュ・クラスタ・メンバーは障害を起こしたメンバーのコンテンツ所有権を自動的に引き継ぎます。障害を起こしたキャッシュ・クラスタ・メンバーが再び使用可能になると、Oracle Web Cacheによって、コンテンツの所有権が再割当てされます。
Webキャッシュの1つをキャッシュ・クラスタから削除した場合、削除されたメンバーが所有していたコンテンツの所有権は残りのキャッシュ・クラスタ・メンバーに引き継がれます。さらに、削除されたメンバーに関する情報も構成から削除され、変更された構成内容が残りのキャッシュ・クラスタ・メンバーと同期されます。
キャッシュ・クラスタの場合、管理者は、無効化メッセージをすべてのキャッシュ・クラスタ・メンバーに伝播するか、各キャッシュ・クラスタ・メンバーに個別に送信するかを選択できます。
高可用性
Oracle Web Cacheでは、キャッシュ・クラスタの有無にかかわらず、可用性が最も高くパフォーマンスが最も優れたWebサーバーにキャッシュ・ミスがダイレクトされるようになっています。キャッシュ・クラスタがある場合、Oracle Web Cacheは、キャッシュの障害検出とフェイルオーバーをサポートします。あるWebキャッシュに障害が発生した場合、キャッシュ・クラスタの他のメンバーがその障害を検出し、障害の発生したクラスタ・メンバーのキャッシュ可能なコンテンツの所有権を引き継ぎます。
Webサイトのコンテンツを複数のキャッシュに分散させることにより、キャッシュ可能なコンテンツの容量と接続可能なクライアントの数が増加します。
複数のキャッシュをキャッシュ・クラスタ内に配置することで、より多くのCPUの処理能力が利用可能になります。複数のリクエストがパラレルに実行されるため、同時に処理可能なリクエスト数が増加します。
ネットワークのボトルネックによって、処理できるリクエストの数が制限されることがよくあります。複数のネットワーク・カードを持っているノードの場合でさえ、オペレーティング・システムの制限に遭遇することがあります。キャッシュを別々のノードに配置することで、より広いネットワーク帯域幅が使用可能になります。またリクエストの分散により、レスポンス時間も改善されます。
キャッシュ・クラスタを使用すると、Webアプリケーション・サーバーにルーティングされるリクエスト数が減少します。キャッシュからのコンテンツの取得は、(リクエストがクラスタ内の他のキャッシュにルーティングされる場合でも)Webアプリケーション・サーバーからコンテンツを実体化するよりも効率的です。
Webアプリケーション・サーバーの負荷削減
キャッシュ・クラスタ環境では、ポピュラーなオブジェクトは複数のキャッシュに保存されます。キャッシュに障害が発生した場合でも、リクエストされたキャッシュ可能なオブジェクトが、動作している他のクラスタ・メンバーのキャッシュに保存されている可能性があります。その結果、キャッシュに障害が発生した場合でも、Webアプリケーション・サーバーにルーティングする必要のあるキャッシュ可能なオブジェクトのリクエスト数は減少します。
障害の発生したキャッシュが動作可能な状態になった直後には、キャッシュされているオブジェクトはありません。複数の独立したキャッシュをクラスタ化せずに使用している環境の場合、回復したキャッシュはキャッシュ・ミスをWebアプリケーション・サーバーにルーティングする必要があります。キャッシュ・クラスタ環境では、回復したキャッシュはクラスタ内の他のキャッシュにキャッシュ・ミスをルーティングすることができるので、Webアプリケーション・サーバーにかかる負荷が軽減されます。
キャッシュ・クラスタはシステム・リソースの使用率を最大限にします。キャッシュ・クラスタ内の各キャッシュが異なるノードにある場合、1つのキャッシュが1つのノードにあるよりも、多くのメモリーが使用可能です。使用可能なメモリーが増えると、Oracle Web Cacheがキャッシュできるコンテンツの量が増えるため、Webアプリケーション・サーバーへのリクエストが減ります。
キャッシュ・クラスタの全メンバーに対してOracle Web Cacheが適用する無効化ルールは1セットのみであり、また、それによって、無効化リクエストをキャッシュ・クラスタの全メンバーに伝播するのがより容易になるため、クラスタ内のすべてのキャッシュにおけるキャッシュ・データの整合性が得られやすくなります。
キャッシュ・クラスタ・メンバー間のリクエストをサポートせずに、無効化リクエストの伝播および構成変更の同期を実行できるように、キャッシュ・クラスタを構成できます。詳細は、第3.6.7項を参照してください。
管理のしやすさ
キャッシュ・クラスタは、全メンバーに対して1つの構成が使用されるため、管理が容易です。たとえば、1セットのキャッシュ・ルールと1セットの無効化ルールを設定すれば、Oracle Web Cacheによってクラスタの各メンバーに構成が同期され、これらのルールがクラスタ全体に配布されます。
ハードウェア・ロード・バランサを使用できない環境では、次のオプションを構成することができます。
Oracle Web Cacheの特殊なモードを構成し、Oracle Web Cacheを、HTTP通信のソフトウェア・ロード・バランサまたはオリジナル・サーバーへのリバース・プロキシ専用に使用できます。このような構成モードは、次の作業に役立ちます。
小規模Webサイト、部門別WebサイトまたはテストWebサイトの管理
Oracle PortalまたはOracle Single Sign-Onを使用した、ハードウェア・ロード・バランサとアプリケーション間のDMZトラフィックの管理
このモードでは、コンテンツが一切キャッシュされず、次の機能もサポートされません。
圧縮: すべての圧縮設定が無視されます。
ESI: ESIコンテンツが組み立てられません。
キャッシュ階層: キャッシュ階層に2つのキャッシュを構成する場合、1つのキャッシュはロード・バランサとして構成できません。
単一のOracle Web Cacheサーバーをロード・バランサとして配置できます。ただし、この配置では、Oracle Web Cacheサーバーがアプリケーションのシングル・ポイント障害になります。かわりに、複数のOracle Web Cacheサーバーでキャッシュ・クラスタを構成し、オペレーティング・システムのロード・バランシング機能を併用できます。この項の前半で説明した許容量の変更に注意してください。
このモードでは、Oracle Web Cacheを構成して、ESIを使用するアプリケーションの前面または、他のOracle Web Cacheの前面に配置されているHTTP通信量のロード・バランシングが行えます。Oracle Web Cacheロード・バランサは、ESIコンテンツの処理や階層的なキャッシュに関与しません。たとえば、Oracle Portalの標準的な配置では、ESIアセンブリに使用される組込みのOracle Web Cacheがあります。このような構成では、ESIアセンブリに使用されるOracle Web Cacheをロード・バランサとして構成しないでください。
キャッシュや圧縮のサポートなど、その他のOracle Web Cache機能が必要な場合は、このモードを構成しないでください。かわりに、ハードウェア・ロード・バランサ、またはオペレーティング・システムのロード・バランシングのサポートを構成して、オリジナル・サーバーへのリクエストを管理するロード・バランシング機能を使用してください。
詳細は、次を参照してください。
一部のオペレーティング・システムではロード・バランシングがサポートされているため、Oracle Web Cacheの可用性(特にキャッシュ・クラスタにおける)を向上させることができます。
オペレーティング・システムが1つのキャッシュで障害を検出した場合は、自動IP引継ぎを使用して、クラスタ構成内の残りのキャッシュに負荷を分散します。リクエストは特定のホストではなく仮想IPアドレスに送信されるため、1つのホストにアクセスできない場合でもリクエストは処理されます。
さらに、一部のオペレーティング・システムは、受信リクエストのロード・バランシング機能を備えています。この場合、複数のノード上にあるキャッシュ間で受信リクエストの負荷を分散するように、オペレーティング・システムを構成できます。
ネットワーク・ロード・バランサでは、ハードウェア・ロード・バランサで提供されるファイアウォールやping URLなどの機能を使用できません。ただし、提供されない機能に対するニーズが満たされている場合は、ネットワーク・ロード・バランサの使用を検討できます。
第3.9項では、各オペレーティング・システムでのネットワーク・ロード・バランサの構成方法を説明します。
セッション・バインディングの詳細は、第3.2項を参照してください。
セッション・バインディングを構成するには、一連のセッション・バインディング・ルールを指定してサイトに適用します。デフォルトでは、サイトはデフォルトのルールを使用するように構成されます。デフォルト・ルールを使用するか、サイト用にカスタマイズされた別のルールを選択できます。
デフォルトのセッション・バインディング・ルールの値を変更する場合は、このルールが現在構成されているすべての名前付きサイトでセッション・バインディングが必要であることを確認してください。一部のサイトでセッション・バインディングが不要な場合は、デフォルト・ルールの値を変更せず、必要なサイトに対してセッション・バインディング設定を指定してください。
セッション・バインディングを構成するには、次の手順を実行します。
Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
「Webキャッシュ」メニューから、「管理」→「セッション構成」を選択します。
「セッション構成」ページが表示されます。
「サイト」リストから、カスタマイズされたセッション・バインディングを作成するサイトを選択します。
定義済サイトと一致しないリクエストのデフォルト設定を指定するには、「グローバル」を選択します。サイトにカスタマイズされたセッション・バインディングを指定しない場合は、「グローバル設定を使用」オプションをクリックして「グローバル」に指定する設定を適用できます。「グローバル」には、デフォルトで「セッション・バインディング無効化」が選択されています。このデフォルト設定を変更するには、「サイト」リストから「グローバル」を選択し、他のいずれかのセッション・バインディング設定を選択します。
「セッション定義」表でセッション定義を作成します。第2.12項を参照してください。
- グローバル設定を使用: 「サイト」リストの「グローバル」に構成したセッション・バインディング設定を適用するには、このオプションを選択します。
デフォルトでは、すべてのリクエストのセッション・バインディングが無効になります。「グローバル」には、デフォルトで「セッション・バインディング無効化」オプションが選択されています。最初にサイトを作成すると、デフォルトでは、グローバルのセッション・バインディング設定を使用するように設定されます。
- セッション・バインディング無効化: セッション・バインディングを無効にするには、このオプションを選択します。これはグローバル・サイトのデフォルト設定です。このデフォルト設定を変更するには、「サイト」リストから「グローバル」を選択し、他のいずれかのセッション・バインディング設定を選択します。
- Set-Cookieを使用したCookieに基づくセッション・バインディング: クライアントでCookieがサポートされ、オリジナル・サーバーでセッションの状態に1つ以上のCookieが使用される場合、このオプションを選択します。Oracle Web Cacheは、独自のCookieを使用してセッションをトラッキングします。このCookieは、ルーティング情報を含んでいて、Oracle Web Cacheとクライアントのブラウザとの間で維持されます。クライアント/サーバーのバインディングは、アプリケーション・サーバーがクライアントに送信する最初のCookieによって開始されます。
- セッションを使用したバインド: このオプションを選択して次の手順を実行し、特定セッションのバインディングを有効にします。
「セッション名」リストから、セッションを選択して特定セッションのバインディングを有効にします。
「セッション・バインディング方式」リストから、選択したセッション定義のバインディング方式を選択します。
- Cookieベース: クライアントがCookieをサポートしている場合に選択します。Oracle Web Cacheは、独自のCookieを使用してセッションをトラッキングします。このCookieは、ルーティング情報を含んでいて、Oracle Web Cacheとクライアントのブラウザとの間で維持されます。
- セッション・バインディングIAS: アプリケーションがOC4Jベースの場合に選択します。Oracle Web Cacheは、各リクエストのルーティング情報をOracle HTTP Server経由でOC4Jに転送します。
- 内部-トラッキング: クライアントがCookieをサポートせず、アプリケーションがOracle HTTP ServerベースでもOC4Jベースでもない場合に選択します。このオプションは、Oracle Web Cacheの以前のリリースとの下位互換性のために用意されています。Oracle Web Cacheはメモリー内にルーティング表を保持し、この表の各エントリによってセッションIDがオリジナル・サーバーにマップされます。ルーティング表は、クラスタ・ノード間では共有されません。このオプションを選択し、キャッシュ・クラスタ構成を使用する場合は、ロード・バランサ・レイヤーでもバインドを行う必要があります。
「適用」をクリックして変更を送信します。
Oracle Web Cacheを再起動します。第2.13項を参照してください。
Webサイトの可用性とスケーラビリティを高めるために、Oracle Web Cacheの複数のインスタンスをキャッシュ・クラスタのメンバーとして動作させるように構成することができます。キャッシュ・クラスタの詳細は、第3.3項を参照してください。
キャッシュ・クラスタを構成するには、複数のOracle Web Cacheインスタンスをキャッシュ・クラスタのメンバーとして構成し、クラスタのプロパティを指定します。
キャッシュ・クラスタに使用される構成は1つのみです。この構成がカレント・キャッシュ(クライアントのブラウザに接続されているキャッシュ)からすべてのクラスタ・メンバーに同期されます。この構成の中には、すべてのクラスタ・メンバーに共通する設定情報と、各クラスタ・メンバーのキャッシュに固有の設定情報があります。
この項では、すべてのキャッシュが同一のOracle WebLogic Serverに関連付けられている環境でキャッシュ・クラスタを構成する際に役に立つ次の項目について説明します。各項目ではFusion Middleware Controlを使用してクラスタを構成する方法が説明されており、すべてのキャッシュ・メンバーが同一のOracle WebLogic Serverを使用する必要があります。
また、クラスタの構成方法に関する次の情報を参照してください。
キャッシュが別のOracle WebLogic Serverに関連付けられている構成に対してキャッシュ・クラスタを構成する場合は、第3.7項の説明に従って、Oracle Web Cache Managerを使用してクラスタを構成します。
キャッシュ・クラスタはOracle Web Cacheの複数のインスタンスで構成されるため、キャッシュ・クラスタを設定するには、Oracle Web Cacheの複数のインスタンスが1つ以上のノードにインストールされている必要があります。各インスタンスは同一バージョンのOracle Web Cacheであることが必要です。また、クラスタ・メンバー間で、Oracle Web Cache管理者のパスワードと無効化ユーザーinvalidator
のパスワードが同じである必要があります。パスワードが異なる場合は、キャッシュのadmin
サーバーに接続して、第5.2項で説明されている手順に従って、管理者パスワードを変更してください。
この項では、構成を容易にするために、キャッシュ・クラスタとそのメンバーに対する主要な構成設定項目について説明します。
キャッシュ・クラスタのプロパティの設定時に、フェイルオーバーのしきい値を設定します。この設定は、他のキャッシュ・クラスタ・メンバーに障害が発生したとOracle Web Cacheがみなす、リクエストの連続失敗回数を示します。つまり、Oracle Web Cacheは、障害の発生したメンバーに対して一定の回数だけ連続してリクエストを再試行したあとに、そのキャッシュ・メンバーが停止しているとみなします。Oracle Web Cacheが再試行を許可されている回数を「フェイルオーバーのしきい値」といいます。
Oracle Web Cacheでは、次のような場合に、他のキャッシュ・クラスタ・メンバーへのリクエストが失敗したとみなします。
ネットワーク・エラーが発生した場合
HTTPレスポンスのステータス・コードが「500 内部サーバー・エラー」、「502 不正なゲートウェイ」、「503 - サービスが使用できません」、「504 - ゲートウェイ・タイムアウト」または100未満のいずれかである場合
Oracle Web Cacheでは、リクエストが失敗するたびに、そのクラスタ・メンバーのエラー・カウンタの数値が増えます。エラー・カウンタはクラスタ・メンバーごとに1つずつ保持されます。リクエストがクラスタ・メンバーによって正常に処理されると、Oracle Web Cacheでエラー・カウンタがリセットされます。
カウンタがフェイルオーバーのしきい値に達すると、Oracle Web Cacheはそのキャッシュ・クラスタ・メンバーに障害が発生したとみなします。このため、Oracle Web Cacheは残りのキャッシュ・クラスタ・メンバーの相対許容量を再計算します。次に、キャッシュのコンテンツの所有権を割り当てなおします。
キャッシュ・クラスタ・メンバーに障害が発生すると、Oracle Web Cacheはキャッシュ・クラスタ・メンバーのポーリングを開始します。ポーリングは、指定されたping URLにリクエストを送信することで行われます。キャッシュ・クラスタ・メンバーからのレスポンスの受信に成功すると、Oracle Web Cacheはそのキャッシュ・クラスタ・メンバーが使用可能になったとみなします。そして、すべてのキャッシュ・クラスタ・メンバーの相対許容量を再計算して、キャッシュのコンテンツの所有権を割り当てなおします。
キャッシュ・クラスタ・メンバーの構成時に、メンバーに適用する許容量を指定します。
Oracle Web Cacheでは、許容量が次の2通りの方法で使用されます。
他のすべてのキャッシュ・クラスタ・メンバーからこのキャッシュ・クラスタ・メンバーへの同時接続数を示す絶対許容量を設定する
この接続は、他のキャッシュ・クラスタ・メンバーから、所有コンテンツに対するリクエストを受信するために使用されます。接続数は、その他のクラスタ・メンバーの間で振り分けられます。たとえば、3つのキャッシュから構成されるクラスタにおいて、Cache_Aの許容量が50、Cache_Bから開くことのできるCache_Aへの接続数が25、Cache_Cから開くことのできるCache_Aへの接続数が25である場合について考えてみます。
他のキャッシュ・クラスタ・メンバーのキャッシュにデータがほとんど、あるいはまったく格納されていない場合には(そのクラスタ・メンバーが初めて起動されたとき、障害から回復したとき、無効化処理を実行した後など)、多くの接続が使用されます。この期間中、クラスタ・メンバーはリクエストの多くを他のメンバー、つまりコンテンツの所有者に送信します。多くの場合、このようなリクエストはオリジナル・サーバーへのリクエストよりも速く処理されます。接続数を多く設定すると、この期間中のパフォーマンスが向上し、キャッシュを完全にロードするまでの時間が短縮されます。キャッシュが完全にロードされると、使用される接続の数は少なくなります。未使用の接続に対してのオーバーヘッドはありません。
各キャッシュ・クラスタ・メンバーの相対許容量を設定する
各キャッシュ・クラスタ・メンバーの許容量は、アクティブなすべてのキャッシュ・クラスタ・メンバーの合計許容量と比較されます。許容量を設定すると、Oracle Web Cacheによって各クラスタ・メンバーに所有率が割り当てられます。所有率とは、各クラスタ・メンバーによって所有されるキャッシュ・コンテンツの割合を指します。この割合は、次の計算式で算出されます。
cluster_member_capacity
/
total_capacity_of_all_active_cluster_members
たとえば、キャッシュ・クラスタ・メンバーCache_Aの許容量が100、キャッシュ・クラスタ・メンバーCache_Bの許容量が300で、許容量の合計が400である場合、Cache_Aには25パーセントの所有率が割り当てられ、Cache_Bには75パーセントの所有率が割り当てられます。これは、Cache_Aがキャッシュ・コンテンツの25パーセントを所有することを意味しています。
相対許容量を計算する場合、Oracle Web Cacheはアクティブなクラスタ・メンバーの許容量に基づいて計算を行い、障害が発生しているとみなしたクラスタ・メンバーの許容量は計算に入っていない点に注意してください。
各キャッシュ・クラスタ・メンバーの初期許容量は、「最大着信接続数」の設定の10パーセントに設定します。
アプリケーションの必要許容量およびヒット率についてデータが蓄積されたら、許容量を微調整します。これらの2つの想定をキャッシュ・クラスタに適用したら、次の計算式を使用して、各クラスタ・メンバーの許容量を決めます。
着信通信量を、すべてのキャッシュ・クラスタ・メンバーに対して平等に配分します。
コンテンツの所有権を、すべてのキャッシュ・クラスタ・メンバーに対して平等に配分します。
次の計算式で、デフォルト値またはmax_incoming_connections
計算式の値の最大値を選択します。
max(default_value, (max_incoming_connections * (cacheable_misses%/100) * (number_of_caches - 1) / number_of_caches))
この計算式の詳細は、次のとおりです。
default_value
は次のとおりです。
本番環境の場合は100
テスト環境の場合は30
無効化のみのクラスタの場合は0
許容量が増えると、Oracle Web Cacheが必要とするファイル記述子の数も増えます。
無効化のみのクラスタの詳細は、第3.6.7項を参照してください。
max_incoming_connections
は、Fusion Middleware Controlの「リソース制限」ページにある「最大着信接続数」の設定です。
cacheable_misses%
は、Oracle Web Cacheで即座には処理されず、オリジナル・サーバーからコンテンツをフェッチした後にOracle Web Cacheで処理されたキャッシュ可能なオブジェクトに対するリクエストのパーセンテージです。
「キャッシュ可能ミス」の設定は、Fusion Middleware Controlの「WebCache統計」ページにあります。
たとえば、キャッシュ・クラスタが4つのメンバーで構成されているとします。最大着信接続数が1500、キャッシュ可能ミス率が30パーセントでOracle Web Cacheが実行されている場合、この構成に対する容量を算出する計算式は次のようになります。
(1500 * (30/100) * (4 - 1) / 4
この計算式の結果は337.5になります。端数を切り上げた338という値が、各キャッシュ・クラスタ・メンバーに対して入力する容量となります。
1500 * .3 * 3 / 4 = 337.5
クラスタ・メンバーに許容量0(ゼロ)を割り当てると、そのクラスタ・メンバーは、他のクラスタ・メンバーからのリクエストを受信しません。ただし、コンテンツの所有者である他のクラスタ・メンバーへのリクエストの転送は行います。すべてのクラスタ・メンバーに許容量0(ゼロ)を割り当てた場合は、クラスタ・メンバー間でリクエストが転送されません。許容量が0に設定されている場合でも、構成は同期可能で、Oracle Web Cacheは無効化リクエストをクラスタ・メンバーに自動的に伝播できます。
クラスタにキャッシュを追加するには、第3.6.1項で説明した条件を満たしている必要があります。
Fusion Middleware Controlを使用してクラスタにキャッシュ・メンバーを追加するには:
Oracle Web Cacheインスタンスについて、Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページが表示されます。
追加するキャッシュ・メンバーごとに、次の手順を実行します。
「追加」をクリックします。
「コンポーネント」フィールドに、キャッシュ・メンバーの名前を入力します。
「容量」フィールドには、デフォルト値が自動的に入力されます。この値は変更できます。許容量の詳細は、第3.6.2項を参照してください。
「フェイルオーバーのしきい値」フィールドに、他のキャッシュ・クラスタ・メンバーに障害が発生したとOracle Web Cacheがみなす、リクエストの連続失敗回数を入力します。
デフォルトの許容連続失敗回数は、5です。
このフィールドの詳細は、第3.6.2項を参照してください。
「pingのURL」フィールドに、キャッシュ・クラスタ・メンバーが、フェイルオーバーのしきい値に達したキャッシュ・クラスタ・メンバーとの通信を試みるときに使用するURLを入力します。
キャッシュ可能で、各キャッシュに確実に保存されているURLを使用してください。デフォルトは、キャッシュに格納される_oracle_http_server_webcache_static_.html
です。
「pingの間隔」フィールドに、クラスタ・メンバーが障害の発生したクラスタ・メンバーとの通信を試みる間隔(秒)を入力します。
ほとんどの場合、デフォルトの10秒が適切な間隔です。
「適用」をクリックします。
リクエストは元々は1つのキャッシュ・クラスタ・メンバーのみを経由してルーティングされますが、キャッシュ・クラスタでは、すべてのキャッシュ・クラスタ・メンバーが、セッションを確立したオリジナル・サーバーを判別できる必要があります。
第3.6.3項でプロパティを設定したOracle Web Cacheについて、セッション・バインディング方式がCookieベースまたはセッション・バインディングIASのセッション・バインディングを構成します。「内部-トラッキング」オプションはキャッシュ・クラスタでは機能しないため、使用しないでください。
Cookieベースの方式を使用するセッション・バインディングを構成する方法は、第3.5項を参照してください。
クラスタに変更を加えて変更を適用すると、Oracle Web Cacheによって新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。すべてのクラスタ・メンバーに影響を及ぼすような変更を加えた場合は、構成を同期し、クラスタ・メンバーを再起動する必要があります。
Fusion Middleware Controlを使用して、新しく追加したキャッシュ・メンバーからクラスタ内の他のキャッシュへ構成を同期するには:
第3.6.3項でプロパティを設定したOracle Web Cacheについて、Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。
「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページが表示されます。
クラスタ内の他のキャッシュ・メンバーを選択し、「同期化」をクリックします。
すべてのキャッシュ・メンバーを選択し、キャッシュでの操作開始時間をずらす間隔を選択し、「起動」をクリックします。
これで、キャッシュ・クラスタを使用する準備が整いました。
クラスタからキャッシュ・メンバーを削除する場合は、残りのクラスタ・メンバーがそのキャッシュをクラスタ内に含んでいないこと、および削除されたキャッシュがクラスタの一部とみなされないことを確認する必要があります。
Fusion Middleware Controlを使用してキャッシュをクラスタから削除するには:
クラスタから削除するキャッシュを除くOracle Web Cacheインスタンスについて、Fusion Middleware Controlで「Webキャッシュ・メンバー」ページにナビゲートします。第2.6.2項を参照してください。
「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページが表示されます。
削除するキャッシュを選択し、「削除」をクリックします。
クラスタ内の他のキャッシュ・メンバーを選択し、「同期化」をクリックします。
他のキャッシュが選択されている状態で、「再起動」をクリックします。
これで、クラスタ内の残りのすべてのキャッシュは、削除したキャッシュをクラスタの一部とみなさなくなります。ただし、削除されたキャッシュ自体は、依然としてクラスタの一部と認識しています。この状況は次のステップで修正されます。
クラスタから削除するキャッシュについて、Fusion Middleware Controlの「Webキャッシュ・メンバー」ページにナビゲートします。
「Webキャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページにキャッシュのすべてのメンバーが表示されます。
現在のキャッシュ以外のキャッシュを選択して、「削除」をクリックします。「クラスタ・メンバー」リストが現在のキャッシュのみになるまで、この手順を繰り返します。
「再起動」をクリックします。
構成および無効化リクエストの同期はすべてのキャッシュ・クラスタ・メンバー間でサポートするが、リクエストはキャッシュ・クラスタ・メンバー間で転送しないように、クラスタを構成できます。つまり、リクエストの処理中、各クラスタ・メンバーは個別のキャッシュとして機能し、ピア・クラスタ・メンバーからオブジェクトをリクエストしません。ただし、構成変更および無効化リクエストはクラスタ・メンバー間で同期できます。
この構成を使用すると、多数のキャッシュの管理が簡略化されます。この構成は、メンバーがファイアウォールによって分離されているクラスタで必要になる場合があります。たとえば、インターネットからイントラネットを分離するファイアウォールの両側に1つずつキャッシュを配置したクラスタを使用できます(1つのキャッシュへのインターネット通信、別のキャッシュへのイントラネット通信などのネットワーク設定については、別のマニュアルを参照してください)。
これらのキャッシュを1つのクラスタとして管理し、キャッシュ間でコンテンツを共有しないようにするには、次の手順を実行します。
この項では、すべての非関連キャッシュが別のOracle WebLogic Serverを使用している構成でキャッシュ・クラスタを構成する際に役に立つ次の項目について説明します。各項目ではOracle Web Cache Managerを使用してクラスタを構成する方法が説明されています。
また、クラスタの構成方法に関する次の情報を参照してください。
複数のキャッシュが同一のOracle WebLogic Serverに関連付けられている環境でキャッシュ・クラスタを構成するには、第3.6項の説明に従い、Fusion Middleware Controlを使用してクラスタを構成します。
Oracle Web Cache Managerを使用してキャッシュ・クラスタの設定を構成するには:
Oracle Web Cache Managerのナビゲータ・フレームで、「Properties」→「Clustering」を選択します。第2.7.2項を参照してください。
「Clustering」ページが表示されます。「General Cluster Information」セクションにフェイルオーバーおよび無効化の同期についてのクラスタ全体のデフォルト値が表示されます。「Cluster Members」表に現在のキャッシュ(接続しているキャッシュ)が唯一のクラスタ・メンバーとして表示されます。クラスタ・メンバーが1つのみの場合は、クラスタ情報が無視されます。
「Clustering」ページの「General Cluster Information」セクションで「Edit」をクリックします。
「Edit General Cluster Information」ダイアログ・ボックスが表示されます。
「フェイルオーバーのしきい値」フィールドに、他のキャッシュ・クラスタ・メンバーに障害が発生したとOracle Web Cacheがみなす、リクエストの連続失敗回数を入力します。
デフォルトの許容連続失敗回数は、5です。
このフィールドの詳細は、第3.6.2項を参照してください。
「pingのURL」フィールドに、キャッシュ・クラスタ・メンバーが、フェイルオーバーのしきい値に達したキャッシュ・クラスタ・メンバーとの通信を試みるときに使用するURLを入力します。
キャッシュ可能で、各キャッシュに確実に保存されているURLを使用してください。デフォルトは、キャッシュに格納される_oracle_http_server_webcache_static_.html
です。
「pingの間隔」フィールドに、クラスタ・メンバーが障害の発生したクラスタ・メンバーとの通信を試みる間隔(秒)を入力します。
ほとんどの場合、デフォルトの10秒が適切な間隔です。
「Propagate Invalidation」フィールドで「Yes」または「No」を選択して、キャッシュ・クラスタ・メンバーからの無効リクエストをすべて他のキャッシュ・クラスタ・メンバーと同期するかどうかを指定します。
「Submit」をクリックします。
「Clustering」ページの「Cluster Name」表に、現在のキャッシュのデフォルト値が表示されます。キャッシュを選択し、「Edit Selected」をクリックします。
「Edit Cluster Member」ダイアログ・ボックスが表示されます。
「Cache Name」フィールドに、Oracle Web Cacheインスタンスの名前を入力します。キャッシュ・クラスタ内の他のキャッシュと重複しない名前を入力する必要があります。
デフォルトでは、「Host Name」フィールドにはOracle Web Cacheがインストールされているノードのホスト名が表示されます。通常は、このフィールドを変更する必要がありません。
デフォルトでは、「Oracle Home」フィールドには、Oracle Web CacheがインストールされているOracleホームのファイル仕様が表示されます。通常は、このフィールドを変更する必要がありません。「Host Name」と「Oracle Home」の組合せはキャッシュ・クラスタ内で一意である必要があります。
「Capacity」フィールドに、Oracle Web Cacheで保持できる他のキャッシュ・クラスタ・メンバーからの同時着信接続数を入力します。
このフィールドの詳細は、第3.6.2項を参照してください。
「Submit」をクリックします。
これで、クラスタ内に1つのキャッシュ(現在のキャッシュ)が設定されました。ただし、クラスタ情報は、クラスタ内に複数のOracle Web Cacheシステム・コンポーネントが設定されるまで無視されます。
クラスタにキャッシュを追加するには、第3.6.1項で説明した条件を満たしている必要があります。
Oracle Web Cache Managerを使用してキャッシュをクラスタに追加するには:
ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページが表示されます。
「Clustering」ページの「Cluster Members」セクションで、「Add」をクリックします。
「Add Cache to Cluster」ダイアログ・ボックスが表示されます。
「Host Name」フィールドに、クラスタに追加するキャッシュのホスト名を入力します。
「Admin Port」フィールドに、クラスタに追加するキャッシュの管理ポートを入力します。
管理ポートは、管理リクエストのリスニング・ポートです。
「Protocol for Admin Port」フィールドで「HTTP」または「HTTPS」を選択して、HTTPまたはHTTPSクライアント・リクエストを受け入れます。
「Cache Name」フィールドにキャッシュの名前を入力します。キャッシュ・クラスタ内の他のキャッシュと重複しない名前を入力する必要があります。
「Capacity」フィールドに、Oracle Web Cacheで保持できる他のキャッシュ・クラスタ・メンバーからの同時着信接続数を入力します。
このフィールドの詳細は、第3.6.2項を参照してください。
「Submit」をクリックします。
これでキャッシュはクラスタの一部となり、「Cluster Member」表に表示されます。
さらにOracle Web Cacheインスタンスをキャッシュ・クラスタに追加するには、ステップ2から8を繰り返します。
キャッシュ・クラスタへのメンバーの追加が完了したら、「Apply Changes」をクリックします。
新しいキャッシュ・クラスタ・メンバーのキャッシュ固有情報がクラスタ構成に追加されます。
「Add」を選択して、Oracle Web Cacheインスタンスをさらにクラスタに追加できます。「Edit」を選択して、キャッシュ・クラスタ・メンバーの設定を変更できます。「Delete Selected」を選択して、現在のキャッシュ以外のキャッシュ・クラスタ・メンバーを削除できます。
リクエストは元々は1つのキャッシュ・クラスタ・メンバーのみを経由してルーティングされますが、キャッシュ・クラスタでは、すべてのキャッシュ・クラスタ・メンバーが、セッションを確立したオリジナル・サーバーを判別できる必要があります。キャッシュ・クラスタでセッション・バインディングを構成するには、Cookieベースのセッション・バインディング方式を選択します。この方式を設定すると、セッション情報をトラッキングするCookieが追加されます。これによって、すべてのクラスタ・メンバーがセッション情報を読み取ることができます。Oracle Web Cacheは、クライアントからの後続のリクエストにCookieが含まれるように、レスポンスにSet-Cookie
レスポンス・ヘッダーを含めます。Cookieによって情報が提供されるため、最初のリクエストを処理したキャッシュに関係なく、すべてのクラスタ・メンバーはバインディングを解決できます。
Cookieベースの方式を使用するセッション・バインディングを構成する方法は、第3.5項を参照してください。
クラスタに変更を加えて変更を適用すると、Oracle Web Cacheによって新しいキャッシュ・クラスタ・メンバーのキャッシュ固有の情報が構成に追加されます。すべてのクラスタ・メンバーに影響を及ぼすような変更を加えた場合は、構成を同期し、クラスタ・メンバーのキャッシュ・サーバー・プロセスを再起動する必要があります。
Oracle Web Cache Managerを使用して、構成を新しいクラスタ・メンバーに同期するには:
ナビゲータ・フレームで、「Operations」→「Cache Operations」を選択します。
「Cache Operations」ページが表示されます。「Operation Needed」列に、構成を同期すべきキャッシュが示されます。
構成をすべてのキャッシュ・クラスタ・メンバーに同期します。
「Operate On」フィールドで「All caches」を選択します。
「Interval」で「Immediate」を選択します(同期に他の間隔は使用できません)。
「Propagate」をクリックします。
(一度に1つのクラスタ・メンバーに構成を同期することもできます。その場合は、「Operate On」フィールドで「Selected cache」をクリックして、「Propagate」をクリックします)。
操作が完了すると、「Cache Operations」ページの「Operation Needed」列に再起動を必要とするクラスタ・メンバーが示されます。
すべてのクラスタ・メンバーを停止して再起動します。
「Operate On」フィールドで「All caches」を選択します。
キャッシュに対する操作を時間差をつけて開始するために「Interval」を選択し、「Restart」をクリックします。
(一度に1つのクラスタ・メンバーを再起動することもできます。その場合は、「Operate On」フィールドで「Selected cache」を選択して、「Restart」をクリックします。
操作が完了すると、「Cache Operations」ページの「Operation Needed」列に必要な操作がないことが示されます。これで、キャッシュ・クラスタを使用する準備が整いました。
クラスタからキャッシュを削除する場合は、残りのクラスタ・メンバーがそのキャッシュをクラスタ内に含んでいないこと、および削除されたキャッシュがクラスタの一部とみなされないことを確認する必要があります。
Oracle Web Cache Managerを使用してクラスタからキャッシュを削除するには:
クラスタから削除するキャッシュを除く、クラスタ内のキャッシュのOracle Web Cache ManagerのURLを入力します。
ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページの「Cluster Members」セクションで、クラスタから削除するキャッシュを選択して「Delete Selected」をクリックします。
Oracle Web Cache Managerのメイン・ウィンドウで、「Apply Changes」をクリックします。
変更内容を、残りのキャッシュ・クラスタ・メンバーに同期します。
ナビゲータ・フレームで「Operations」→「Cache Operations」を選択します。
「Operate On」フィールドで「All caches」を選択します。
「Interval」で「Immediate」を選択します
「Propagate」をクリックします。
変更内容が、削除されたクラスタ・メンバー以外の残りのすべてのクラスタ・メンバーと同期されます。
すべてのクラスタ・メンバーを再起動します。
「Cache Operations」ページの「Operate On」フィールドで「All caches」を選択します。
キャッシュに対する操作を時間差をつけて開始するために「Interval」を選択し、「Restart」をクリックします。
これで、クラスタ内の残りのすべてのキャッシュは、削除したキャッシュをクラスタの一部とみなさなくなります。ただし、削除されたキャッシュ自体は、依然としてクラスタの一部と認識しています。この状況を修正するには、次のステップを実行します。
クラスタから削除したキャッシュのOracle Web Cache ManagerのURLを入力します。
ナビゲータ・フレームで「Properties」→「Clustering」を選択します。
「Clustering」ページが表示されます。「Cluster Members」セクションには、引き続きクラスタの全メンバーが表示されます。
「Clustering」ページの「Cluster Members」セクションで、現在のキャッシュ以外の各キャッシュを選択して「Delete Selected」をクリックします。クラスタ・メンバー・リストが現在のキャッシュのみになるまで、操作を繰り返します。
Oracle Web Cache Managerのメイン・ウィンドウで、「Apply Changes」をクリックします。
ナビゲータ・フレームで「Operations」→「Cache Operations」を選択します。
キャッシュを選択して「Restart」をクリックします。
構成および無効化リクエストの同期はすべてのキャッシュ・クラスタ・メンバー間でサポートするが、リクエストはキャッシュ・クラスタ・メンバー間で転送しないように、クラスタを構成できます。つまり、リクエストの処理中、各クラスタ・メンバーは個別のキャッシュとして機能し、ピア・クラスタ・メンバーからオブジェクトをリクエストしません。ただし、構成変更および無効化リクエストはクラスタ・メンバー間で同期できます。
この構成を使用すると、多数のキャッシュの管理が簡略化されます。この構成は、メンバーがファイアウォールによって分離されているクラスタで必要になる場合があります。たとえば、インターネットからイントラネットを分離するファイアウォールの両側に1つずつキャッシュを配置したクラスタを使用できます(1つのキャッシュへのインターネット通信、別のキャッシュへのイントラネット通信などのネットワーク設定については、別のマニュアルを参照してください)。
これらのキャッシュを1つのクラスタとして管理し、キャッシュ間でコンテンツを共有しないようにするには、次の手順を実行します。
ハードウェアのロード・バランサを使用しない高可用性の概要は、第3.4項を参照してください。
単一のOracle Web Cacheサーバーをソフトウェア・ロード・バランサとして構成するには、次の手順を実行します。
次の場所にあるwebcache.xml
をテキスト・エディタで開きます。
(UNIX) ORACLE_INSTANCE/<instance_name>/config/WebCache/<webcache_name> (Windows) ORACLE_INSTANCE\<instance_name>\config\WebCache\<webcache_name>
ROUTINGONLY
属性をCACHE
要素に追加します。次に例を示します。
... <CACHE WCDEBUGON="NO" CHRONOSONPERNODE="NO" CAPACITY="301" VOTES="1" INSTANCENAME="instance_name" COMPONENTNAME="component_name" ORACLEINSTANCE="instance" HOSTNAME="web_cache_host_name" ORACLEHOME="directory" NAME="web_cache_name" ROUTINGONLY="YES"> ...
webcache.xml
を保存します。
次のコマンドを使用してOracle Web Cacheを再起動します。
opmnctl restartproc ias-component=component_name
この実行ファイルは次のディレクトリにあります。
(UNIX) ORACLE_INSTANCE/bin (Windows) ORACLE_INSTANCE\bin
Oracle Web Cache Managerで「Apply Changes」ボタンおよび「Cancel Changes」ボタンの下に表示される次のステータス・メッセージを確認して、Oracle Web Cacheがロード・バランサ・モードで実行されていることを確認します。
Web Cache running in Routing Only Mode with current configuration
Fusion Middleware Controlでは、同等の検証ステータスは提供されません。
第2.11.2項の説明に従って、オリジナル・サーバーを構成します。
アプリケーションの配置でセッションの振分けが必要な場合は、セッション・バインディングを有効化します。第2.12項を参照してください。
たとえば、図3-5に示すトポロジがあるとします。
このトポロジを構成するには、次の手順を実行します。
Oracle Web Cacheサーバーwebche-host
のIPアドレスをwww.app1.company.com
に登録します。
Oracle Web Cacheサーバーを次のように構成します。
指定したリスニング・ポートでHTTPリクエストおよびHTTPSリクエストを受信します。
HTTPリクエストおよびHTTPSリクエストを、指定したリスニング・ポートからWebアプリケーション・サーバーapp1-host1
およびapp1-host2
に送信します。
app1-host1
およびapp1-host2
にマップされている、www.app1.company.com
の仮想ホスト・サイト定義をマップします。
ハードウェアのロード・バランサを使用しない高可用性の概要は、第3.4項を参照してください。
一部のMicrosoft Windowsプラットフォームでは、ハードウェア・ロード・バランサのかわりに、オペレーティング・システムのMicrosoftネットワーク負荷分散(NLB)コンポーネントを使用できます。NLBはMicrosoftクラスタリング・テクノロジの一部で、次のプラットフォームで使用できます。
Windows 2000 Advanced Server
Windows 2000 Datacenter Server
Windows 2003(すべてのEdition)
ホストをクラスタとして構成し、オペレーティング・システムでロード・バランシングを使用できるように構成します。次に、キャッシュ・クラスタ内でOracle Web Cacheを実行するホストでNLBを構成します。各ホストで次の手順を実行します。
「スタート」→「設定」→「ネットワークとダイヤルアップ接続」を選択します。
ネットワーク・アダプタを選択します。次に、右クリックして「プロパティ」をクリックします。
「プロパティ」ダイアログ・ボックスで、「ネットワーク負荷分散」を選択します。次に、「プロパティ」をクリックします。
「ネットワーク負荷分散のプロパティ」ダイアログ・ボックスの「クラスタ パラメータ」タブで、次の手順を実行します。
「プライマリ IP アドレス」に、クラスタのすべてのメンバーが共有する仮想IPアドレスを入力します。
「サブネット マスク」に、仮想IPアドレスのサブネット・マスクを入力します。
「フル インターネット名」に、仮想IPアドレスのフル・インターネット名を入力します。
「ネットワーク アドレス」に表示された生成済アドレスをメモします。
「マルチキャスト サポート」で「有効」をチェックします。
オプションで、「リモート パスワード」を入力し、「リモート制御」を有効にします。
「ホスト パラメータ」タブを選択し、次の手順を実行します。
「優先順位」に、1〜32の間の整数を入力します。数字が小さいほど、優先順位は高くなります。優先順位を設定すると、ポートの規則によって負荷が分散されないリクエストを複数のホスト間で処理するためのデフォルトの優先順位が決まります(ポートの規則の構成方法の詳細は、ステップ6を参照)。
「クラスタの初期状態」で「アクティブ」をチェックします。この指定によって、Windows起動直後にこのホストがクラスタ配列に含まれます。
「専用 IP アドレス」に、このホストのIPアドレスを入力します。
「サブネット マスク」に、このホストのサブネット・マスクを入力します。
「ポートの規則」タブを選択し、次の手順を実行します。
「ポートの範囲」で、単一のポートの規則を使用して全クライアントのリクエストの負荷を分散するために、デフォルトのポートの範囲(1〜65535)を使用します。アプリケーションによって異なるプロトコル、フィルタのモード、またはアフィニティが必要な場合は、複数のポートの規則を使用します。
「プロトコル」で「TCP」を選択します。アプリケーションでUDPが必要なソフトウェアを使用する場合は、「両方」を選択します。
「フィルタのモード」で「複数ホスト」を選択します。
「アフィニティ」では、3つのオプションから1つを選択できます。「なし」を選択すると、すべてのホスト間ですべてのリクエストのロード・バランシングが行われます。「単一」を選択すると、特定のクライアントからのリクエストがすべて同じホストで処理されます。セッションの状態を維持する場合は、このオプションを使用します。「クラス C」を選択すると、TCP/IPクラスCアドレス範囲からのクライアントのリクエストがすべて同じホストで処理されます。
「負荷配分」では、ホストで処理する負荷のパーセンテージを入力するか、「均一」を選択します。
クラスタ内のすべてのホストで、ポートの規則が同一であることが必要です。
Microsoftネットワーク負荷分散の詳細は、次のサイトでMicrosoft社のドキュメントを参照してください。
http://www.microsoft.com