| Oracle Fusion Middleware Oracle Web Cache管理者ガイド 11g リリース1(11.1.1) B56248-02 |
|
 前 |
 次 |
この章では、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でサポートされ、それぞれの容量は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キャッシュ」メニューから、「管理」→「クラスタ」を選択します。
「クラスタ」ページにキャッシュのすべてのメンバーが表示されます。
現在のキャッシュ以外のキャッシュを選択して、「削除」をクリックします。「クラスタ・メンバー」リストが現在のキャッシュのみになるまで、この手順を繰り返します。
「再起動」をクリックします。
構成および無効化リクエストの同期はすべてのキャッシュ・クラスタ・メンバー間でサポートするが、リクエストはキャッシュ・クラスタ・メンバー間で転送しないように、クラスタを構成できます。つまり、リクエストの処理中、各クラスタ・メンバーは個別のキャッシュとして機能し、ピア・クラスタ・メンバーからオブジェクトをリクエストしません。ただし、構成変更および無効化リクエストはクラスタ・メンバー間で同期できます。
この構成を使用して、多くのキャッシュの管理を簡素化できます。これは、メンバーがファイアウォールで分けられているクラスタで必要になる可能性があります。たとえば、イントラネットとインターネットを分けるファイアウォールの両側に2つのキャッシュを配置するクラスタを構成できます。(そのようなネットワーク設定(片方のキャッシュにインターネット・トラフィックを送信し、もう一方にイントラネット・トラフィックを送信する設定)は、このドキュメントでは対象範囲外です。)
これらのキャッシュを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は、レスポンス内にSet-Cookieレスポンス・ヘッダーを含めます。これにより、クライアントからの後続リクエストにその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」をクリックします。
構成および無効化リクエストの同期はすべてのキャッシュ・クラスタ・メンバー間でサポートするが、リクエストはキャッシュ・クラスタ・メンバー間で転送しないように、クラスタを構成できます。つまり、リクエストの処理中、各クラスタ・メンバーは個別のキャッシュとして機能し、ピア・クラスタ・メンバーからオブジェクトをリクエストしません。ただし、構成変更および無効化リクエストはクラスタ・メンバー間で同期できます。
この構成を使用して、多くのキャッシュの管理を簡素化できます。これは、メンバーがファイアウォールで分けられているクラスタで必要になる可能性があります。たとえば、イントラネットとインターネットを分けるファイアウォールの両側に2つのキャッシュを配置するクラスタを構成できます。(そのようなネットワーク設定(片方のキャッシュにインターネット・トラフィックを送信し、もう一方にイントラネット・トラフィックを送信する設定)は、このドキュメントでは対象範囲外です。)
これらのキャッシュを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
