【書き途中】「Fusion Middleware Oracle WebLogic Serverクラスタの管理」について自分なりに整理する
参考URL（Oracle公式ドキュメント）：
なんというか・・・Oracleさん、難しいっす！
ということで、整理します。
6 クラスタのフェイルオーバーとレプリケーション
WebLogic Serverは、クラスタ内のサーバー障害を以下の2つの方法で検出します。「IPソケットを使用した障害検出」と「ハートビート」
【１】WebLogic Serverで障害を検出する仕組み
IPソケットを使用した障害検出:
クラスタ内のサーバー間でIPソケットを介して通信します。
サーバー同士がソケットを使ってデータを送受信している最中に、突然ソケットが閉じると、そのサーバーは「エラー」としてマークされます。
このエラー状態のサーバーに関連するサービスはJNDIネーミング・ツリーから削除されます。
IPソケットって？？？
ソケット 【socket】
概要 ソケット（socket）とは、受け口、軸受け、接合部、穴、へこみなどの意味を持つ英単語。ITの分野では物理的な接続端子を指す場合と、ソフトウェア間で通信する仕組みを指す場合がある。
接続端子のソケット
機械部品について言う場合は、電球の受け口の金具のように、機器に部品を装着するために設けられた凹んだ形状の端子や固定具のことを意味する。IT関連では、電子基板に半導体チップを装着して固定するために設けられた差込口のことをソケットということが多い。
ソケット通信 （BSDソケット/INETドメインソケット）
実行中のプログラム間でデータの送受信を行うための標準的な仕組みの一つにソケットと呼ばれる仕組みがある。
UNIX系OSの一種である「BSD」（Barkeley Software Distribution）で最初に用いられたことから「BSDソケット」とも呼ばれる。通信を行うプログラムが利用する標準的なインターフェースとしてUNIX系以外も含め多くのOSが対応している。
特定の通信相手（IPネットワーク上の場合はIPアドレスとポートの組み合わせ）と紐付いた通信端点をプログラム上に生成し、これを通じてコネクションの確立やデータの送受信、切断などの処理を行う。具体的な通信方式や通信相手の指定方式が複数用意されており、同じコンピュータ上の他のプロセスとも、TCP/IPなどを利用して他のコンピュータ上のプログラムとも通信できる。
ソフトウェア開発者にとっては、ソケットの仕組みに則ってプログラムを記述すれば、具体的な通信手段や手順の詳細を知らなくてもよく、通信相手の種類や仕様を調べて相手に合わせて通信を行うコードを記述する必要もない。
UNIX系OSでは、ソケットの仕組みを用いて同じコンピュータ上で動作するプロセス間のデータの受け渡し（IPC：プロセス間通信）を行う「UNIXドメインソケット」（IPCソケット）も提供される。ファイルシステムを介してプロセス同士が通信する手法で、ネットワークソケットと共通のコードで高速にIPCを行うことができる。
IPソケットの使用方法
IPソケットは、ネットワーク上の2つのプロセス間のIP通信を開始するために使用されます。Jythonを使用すると、IPサーバー（IPパケットの待機）またはIPクライアント（IPパケットの送信）の作成が大幅に単純化されます。
次の例は、ごく基本的なIPサーバーの実装を示しています。ここでは、クライアント・ソフトウェアからのデータを待機し、受け取った各パケットをファイルc:/temp/socketserver.logに書き込みます。サーバーがパケットSTOPSERVERを受け取ると、サーバーは停止します。
IPソケットとは、ネットワーク上の2つのプロセス間でデータを送受信するための通信機能のことです。
具体的には、以下のような役割があります。
サーバープロセスがクライアントからの接続要求を待ち受ける
クライアントプロセスがサーバーに接続する
接続が確立されたら、お互いにデータを送受信できる
プログラミングにおいては、この通信機能を抽象化した「ソケットAPI」を使って、ネットワーク通信を実現します。ソケットAPIを使えば、低水準の通信詳細を意識せずに開発できます。
例えば、サーバープログラムではソケットを作成し、クライアントの接続を待ち受けます。クライアントからの接続要求が来ると、新しいソケットが作成されデータの送受信ができるようになります。
つまり、IPソケットはプログラム同士がネットワーク経由で通信するための窓口のような役割を果たしています。Webブラウザ-Webサーバー間の通信など、ほとんどのネットワークアプリケーションで活用されている基本的な仕組みです。
WebLogic Serverのハートビート:
サーバー間で定期的にハートビートメッセージを送信し合います。
ハートビートメッセージが3回連続で受信されない場合、そのサーバーは「エラー」としてマークされ、関連するサービスが削除されます。
ハートビートって？？？
ハートビート（heartbeat）とは、心臓の鼓動、拍動、心拍という意味の英単語で、IT分野では、ネットワーク上で機器が外部に一定間隔で発する、自らが正常に動作していることを知らせる信号やデータをこのように呼ぶ。
【２】サーブレットとJSPのレプリケーションとフェイルオーバー
WebLogic Serverは、サーブレットとJSPのセッション状態を保持するために次の方法を提供します。
ハードウェア・ロード・バランサ:
ロード・バランシング・ハードウェアがリクエストを適切なサーバーにリダイレクトします。
セッション状態のレプリカを他のサーバーから取得します。
プロキシ・プラグイン:
WebサーバーとWebLogicプラグインを使用してリクエストを適切なサーバーにリダイレクトします。
セッション状態のレプリカをクラスタ内のサーバーから取得します。
【３】HTTPセッション状態のレプリケーション
セッション状態を保持するための3つの方法があります。
インメモリー・レプリケーション:
プライマリサーバーでセッション状態を作成し、クラスタ内の別のサーバーにそのレプリカを作成します。
障害が発生した場合、レプリカを使ってセッション状態を復元します。
JDBCベースの永続性:
ファイルベースまたはJDBCベースの永続性メカニズムを使用してセッション状態を保持します。
ワイド・エリア・ネットワーク(WAN)内でも使用できます。
Coherence*Web:
大量のセッション状態オブジェクトがある場合や既存のCoherenceクラスタを利用する場合に使用します。
【４】HTTPセッション状態のインメモリー・レプリケーションに関する条件
WebLogicプロキシプラグインを使用する場合
WebLogicプロキシプラグインは、WebLogic Serverクラスターにおける負荷分散と障害時の処理を行うものです。
具体的な機能は2つあります。
１. 負荷分散機能
クラスター内の各WebLogic Serverインスタンスの情報(IPアドレスなど)をプラグイン内に保持しています
受信したHTTPリクエストを、ラウンドロビン方式で各インスタンスに振り分けます
つまり、サーブレットやJSPが動作するWebLogicインスタンスへ適切に負荷を分散させます
ラウンドロビン（round robin）とは、総当たり戦、傘連判状、持ち回り、などの意味を持つ英単語。ITの分野では、複数の主体や対象を順繰りに（同じ順序で循環的に）指名したり割り当てたりすることを指す。
２.セッション情報の復旧機能
WebLogic Serverインスタンスで障害が発生した場合
そのインスタンスで維持されていたHTTPセッション情報を、別のインスタンスから探し出す
クライアントのHTTPセッションを維持し、継続して処理できるようにします
要するに、このプラグインが負荷分散とセッション情報の復旧を行うことで、WebLogicクラスターの可用性と信頼性が高まるという役割を果たしています。
セッション状態をインメモリーでレプリケートするためには、以下のサポートされたWebサーバーおよびプロキシ・ソフトウェアが必要です。
WebLogic ServerとHttpClusterServlet
ApacheとApache Server (プロキシ)プラグイン
Microsoft Internet Information ServerとMicrosoft-IIS (プロキシ)プラグイン
ロード・バランサを使用する場合
プロキシ・プラグインではなくロード・バランシング・ハードウェアを使用する場合、以下の2つの条件を満たす必要がある。
互換性のあるパッシブまたはアクティブなCookieの永続性メカニズム
パッシブCookie永続性
WebLogicサーバーがクライアントにセッション情報を含むCookieを送信
ロードバランサはこのCookieを使ってクライアントとWebLogicサーバーを紐付ける
アクティブCookie永続性
ロードバランサ自身がクライアントに独自のCookieを送信
ただし、WebLogicサーバーのCookieは変更してはならない
SSLの永続性にハードウェアが対応している必要
WebLogicサーバーとクライアント間の通信をSSL暗号化する場合がある
この暗号化/復号化をロードバランサ側で行う必要がある
ロードバランサは、WebLogicサーバーが挿入したプレーンテキストのCookieを使って、クライアントとサーバーを紐付ける
つまり、
ロードバランサはWebLogicサーバーが使うCookieとSSL通信を適切に処理できるよう構成されていなければならない
ということ。
これらが満たされないとセッション維持やセキュア通信ができなくなってしまう。
【５】クラスタ化されるサーブレットおよびJSPのプログラミング上の考慮事項
クラスタ環境におけるサーブレットおよびJSPのプログラミングでは以下の点を考慮する必要があります。
セッション・データのシリアライズ:
セッション・データはシリアライズ可能である必要があります。
シリアライズ可能でないオブジェクトはレプリケートされません。
setAttributeの使用:
セッション・オブジェクトの属性を変更する場合は、setAttributeメソッドを使用します。
putValueやremoveValueメソッドは非推奨です。
シリアライゼーションのオーバーヘッド:
シリアライズされるオブジェクトのサイズに比例してオーバーヘッドが発生します。
フレーム（ブラウザウィンドウまたはHTMLフレーム）からのセッション・データへのアクセス:
複数のフレームが同時にリクエストを送らないように設計します。
セッション・データを壊さないように注意します。
これらを防ぐために、以下のようなルールに従うことが推奨されています。
特定のフレームセットでは1つのフレームのみでセッションデータの作成・更新を行う
最初のフレームセットでセッションを作成し、他のフレームセットからはデータにアクセスするのみにする
シリアライズ（serialize）とは、複数の要素を一列に並べる操作や処理のこと。単にシリアライズといった場合には、プログラムの実行状態や複雑なデータ構造などを一つの文字列やバイト列で表現する「直列化」を指すことが多い。
【６】レプリケーション・グループの使用
WebLogic Serverは、セッション状態のレプリカを作成するためにレプリケーション・グループを使用します。
レプリケーション・グループの構成:
サーバーの優先セカンダリ・レプリケーション・グループを指定できます。
プライマリ状態のホストサーバーは、クラスタ内の他のサーバーをランク付けしてセカンダリ・セッション状態のホストを選択します。
【７】クラスタ化されたサーブレットとJSPへのプロキシ経由のアクセス
プロキシを使用して、クラスタ化されたサーブレットやJSPにアクセスする際のプロセスは以下の通りです。
プロキシ接続の手順:
HTTPクライアントがサーブレットをリクエストすると、HttpClusterServletがプロキシとして機能し、クラスタ内の適切なサーバーにリクエストを転送
上の例では、WebLogicサーバーAが、クライアントのサーブレット・セッションをホストするプライマリーとなる
サーブレット・セッション状態がクラスタ内のセカンダリWebLogic Serverにレプリケートされる（上の例では、サーバーBをセカンダリとして選択）
◆◆◆いったんここまで。以降は書きかけなので、また修正する◆◆◆◆
URL書換えを利用したセッション・レプリカの追跡
URL書換え技術を利用して、セッションIDをURLに埋め込むことで、セッションの一貫性を保ち、セッション・レプリカの追跡を行います。
プロキシ・フェイルオーバーのプロセス
ヘルスチェック：プロキシサーバは定期的にバックエンドサーバの状態を監視。
フェイルオーバー：バックエンドサーバがダウンした場合、プロキシサーバは他の稼働中のノードにトラフィックを転送。
セッション維持：セッションデータを共有することで、フェイルオーバー後もセッションが継続。
クラスタ化サーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス
ロードバランシングハードウェアを使用して、クラスタ化されたサーブレットやJSPにアクセスします。ハードウェアロードバランサは、リクエストをクラスタ内の最適なノードに分散します。
ロード・バランシング・ハードウェアを利用した接続
ロードバランサは、各リクエストをクラスタ内の最も適したサーバに分配し、負荷を均等にします。
ロード・バランシング・ハードウェアを利用したフェイルオーバー
ハードウェアロードバランサがサーバの状態を監視し、障害発生時にはリクエストを他の正常なサーバに自動的に転送します。
MAN/WAN内のクラスタ間でのセッション状態レプリケーション
広域ネットワーク(MAN/WAN)内で、セッション状態のレプリケーションを行い、クラスタ間でセッションの一貫性を維持します。
クラスタ間レプリケーションのネットワーク要件
低レイテンシ、十分な帯域幅、信頼性の高い通信が必要です。また、ネットワークの冗長性も重要です。
グローバル・ロード・バランサ
複数の地理的に分散したデータセンター間でトラフィックを分散するためのロードバランサ。
ローカル・ロード・バランサ
単一のデータセンター内でトラフィックを分散するためのロードバランサ。
レプリケーション
データの複製を複数のノードに保存し、データの可用性と信頼性を向上させます。
フェイルオーバー
システム障害時に自動的にバックアップシステムに切り替えるプロセスです。
クラスタ間レプリケーションの構成要件
レプリケーションチャネルの設定、データの一貫性、ネットワークの信頼性、適切なレプリケーション戦略。
クラスタ間でのセッション状態レプリケーションの構成
クラスタ間でセッションデータをリアルタイムに同期し、フェイルオーバー時にセッションを継続可能にする設定。
レプリケーション・チャネルの構成
データの複製を行うための通信路を設定し、効率的なデータ転送を実現します。
MANでのHTTPセッション状態のレプリケーション
都市域ネットワーク内でHTTPセッションの状態をレプリケートし、フェイルオーバーに備えます。
MAN内でのレプリケーション
都市域ネットワーク内でデータを複製し、高い可用性を確保します。
MANにおけるフェイルオーバーのシナリオ
都市域ネットワーク内での障害発生時に、迅速に他のノードへトラフィックを切り替えるシナリオ。
MANでのレプリケーション、ロード・バランサ、セッションの固定
都市域ネットワーク内でレプリケーションとロードバランサを利用し、セッションの一貫性を保持。
WANでのHTTPセッション状態のレプリケーション
広域ネットワーク内でHTTPセッションの状態をレプリケートし、クラスタ間でセッションを同期。
WAN内でのレプリケーション
広域ネットワーク内でデータを複製し、地理的に分散した環境で高可用性を実現。
WANにおけるフェイルオーバーのシナリオ
広域ネットワーク内で障害発生時に他の地理的に分散したノードへトラフィックを切り替えるシナリオ。
WANでのセッション状態レプリケーション用のデータベースの構成
広域ネットワーク内でセッション状態を保持するためのデータベースを構成し、一貫性と可用性を確保。
EJBとRMIのレプリケーションとフェイルオーバー
Enterprise JavaBeans (EJB) とRemote Method Invocation (RMI) のレプリケーションとフェイルオーバーを行い、高可用性を実現。
レプリカ対応スタブによるオブジェクトのクラスタリング
レプリカ対応スタブを使用して、オブジェクトのクラスタリングを行い、障害発生時のフェイルオーバーをサポート。
各種のEJBでのクラスタリング・サポート
ステートレス、ステートフル、エンティティなど、様々な種類のEJBのクラスタリングをサポート。
クラスタ化EJBHomes
EJBのホームインターフェースのクラスタリングを行い、高可用性とスケーラビリティを提供。
クラスタ化されたEJBObject
EJBのリモートオブジェクトをクラスタ化し、フェイルオーバー時の透過的な切り替えを実現。
ステートレス・セッションBean
状態を持たないセッションBeanで、フェイルオーバーが容易。
ステートフル・セッションBean
状態を持つセッションBeanで、セッション状態をレプリケートする必要があります。
ステートフル・セッションEJBのフェイルオーバー
セッション状態をクラスタ内でレプリケートし、フェイルオーバー時にセッションを維持。
エンティティEJB
データベースのエンティティを表すEJBで、データの一貫性と整合性を保つためにレプリケーションが必要。
エンティティBeanとEJBハンドルのフェイルオーバー
エンティティBeanの状態とハンドルをクラスタ内でレプリケートし、障害時にフェイルオーバーをサポート。
RMIオブジェクトのクラスタリング・サポート
RMIオブジェクトをクラスタリングし、障害時の透過的なフェイルオーバーを実現。
オブジェクト・デプロイメントの必要条件
クラスタリングをサポートするために、適切なデプロイメント設定が必要です。
他のフェイルオーバーの例外
特定のシナリオにおけるフェイルオーバーの課題や制限事項について理解し、対策を講じる必要があります。