High Availability Session Store(HADB)の概要
さて、先日まででロードバランサ（負荷分散）の設定が完了しました。
ロードバランサの設定を行っただけでは、単一ノードの障害（H/W or S/W）が
発生した場合、Webアプリケーションを利用するエンドユーザは再度
ログインからしなければなりません。
そこで、今日は単一ノードの障害が発生した場合でも継続してWebアプリケーションを
利用できるように、セッション情報を共有し高可用性を実現できる環境を
構築しましょう。
SJS Application Server 9.1では高可用性を実現する為の手段として
下記の２通り存在します。
1. インメモリセッションリプリケーション
2. High Availability Session Store (HADB:高可用性データベース)
インメモリセッションリプリケーションの概要については、以前
GlassFish v2のインメモリセッションリプリケーションの概要で紹介していますので、
今日はインメモリセッションリプリケーションに比べ、さらに高い高可用性(99.999%)を実現する
High Availability Session Store (HADB:高可用性データベース)について説明します。
HADBとはそもそも何なんだ？何故エンタープライズ用にHADBが
組み込まれているんだ？そんな疑問に答えるためにHADBについて
下記にまとめてみたいと思います。
はじめに
SJS Application Server は、HADB(高可用性データベース)を使用して、HTTPセッションデータ
およびステートフルセッションビーン (SFSB) のセッションデータを格納します。
HADBの特徴
● 99.999%の高可用性
ー１年間で５分以下のダウンタイムを実現可能
● メンテナンス性が高い
ーハードウェア・ソフトウェア・OS・HADBのメインテナンス
バージョンアップ等にサービス停止を行わないで済む
● 高パフォーマンス
ーHADBのデータベースノードを追加すればするだけ
線形的にパフォーマンスが向上（スケール）する
ー並列処理を行う高パフォーマンスなデータベース
99.999%の高可用性
HADBはデータベースのデータにアクセスする際に、99.999%の
非常に高い可用性を実現します。そしてそれは年間のダウンタイムとして
計算するならば、１年間に５分以下しか停止しない事を意味しています。
これは、高い高可用性を実現する為に、特別に開発した、並行データベースで
現在提供されている一般的なH/Wシステム、ネットワーク回線で実現可能です。
参考:
IEEEに提出された99.999%の高可用性の証明論文
99.999%のWhite Paper
メンテナンス性
システム管理者は、H/W機器の増強(メモリ・CPU等)、ソフトウェアの追加、
OSの保守（パッチ適用等）、HADB自身のバージョンアップ等、様々な
作業を行う必要があります。このような作業を行う際もHADBでは
サービスを停止する事なく作業を行う事ができます。
パフォーマンス
HADBはリアルタイムの応答を返します。現行のハードウェア環境にHADBを
構築した環境で、HADB内の4つのレコードに対する更新(update)処理を
行った場合、95%の処理が 1ms 以下で終了します。
また、単一のレコードを読み込むトランザクションを実行した場合、
0.3 ms 以下で処理が終了します。
実際にUSでベンチマークテストを行った結果、読み込みテストに関しては
単一レコードの読み込みに秒間 30,000以上のトランザクションを完了し、
更新処理に関しても秒間 10,000以上のトランザクションを完了しました。
（※ 40CPUを使用した場合、primary keyに対する操作を実行）
また、スケーラビリティに関して、HADBを構成するノードを追加する毎に
線形的にパフォーマンスが向上します。つまり１度構成を組んだ後、
パフォーマンスの改善が必要と考えられる場合、システム管理者はノードを
追加する事でパフォーマンスを改善する事ができるようになります。
※ 最大で28ノードの構成が可能（内：アクティブノード:24、スペアノード:4)
※ HADBを使用する場合、セッションサイズがパフォーマンスに
大きく影響します。プログラムのセッションサイズを小さくするように
プログラムを作って下さい。
※ 上記パフォーマンスデータは過去にUSで行われた検証結果に基づき報告しています。
HADBの概要紹介はこの位にしておいて、実際にどのような動きをする
データベースなのか、より詳細に説明してみたいと思います。
HADBの詳細：
HADBは、データのフラグメント（断片化）とレプリケーション（複製）を
通してデータの高可用性を実現します。
下記の図のようにデータベース内に存在するすべてのテーブルは
分割され、フラグメント（断片化）と呼ばれる、ほぼ同サイズの
レプリカ（複製）が作成されます。
断片化は、ハッシュ関数に基づいて行われ、HADBの各ノード間に
データを均等に分散させる為に行われます。
HADBノードは、互いをミラー化する2つのData Redundancy Unit
(DRU:データ冗長ユニット) から構成されます。
上記で説明した各フラグメントは、それぞれ異なるDRU中に存在するノードに対して
2回保存されます。
一つは、「プライマリ」として使用され、そしてもう一つは
「ホットスタンバイ」として使用されます。
下記の図にでは、「プライマリ」用のフラグメントレプリカが白色で、
「ホットスタンバイ」用のフラグメントレプリカが赤色で示されています。
※ F1R0はフラグメント番号：１、レプリカ番号：０を表しDRU0に所属します。
※ F1R1はフラグメント番号：１、レプリカ番号：１を表しDRU1に所属します。
このように、データベース中に存在するデータの完全なコピーを
それぞれのDRUが保持し、単一ノードHADBノード障害に対する耐障害性や、
データの早急な復旧が保証されています。
仮に、プライマリのフラグメントレプリカ(F1R0)に対して内容が更新された場合は、
データベースのトランザクション処理の一部として更新ログが
ホットスタンバイフラグメントレプリカ(F1R1)に対して送られ、ホットスタンバイ
フラグメントレプリカ上でも更新されるようになります。
HADBに対する接続について
HADBに接続するクライアント（SJS Application Server 9.1との連携の為
ここでいうクライアントはApplication Serverになります）は下記の図に示す
ようにHADB中に含まれるどのノードに対しても接続が可能です。
言い換えれば、クライアントはHADBのノードAかノードBか、さらには
HADB中に含まれるどのノードに接続するかを気にする必要はありません。
また、どのDRU中に存在するかも気にしなくてよいのです。
これは、HADBが場所の透過性(location transparency)を提供しているためで、
クライアントは実際にデータがどのノードに保存されているのかを
知る必要はなく、データベースが自動的に保存されている
場所を検索してくれます。
そこで、クライアント(SJS Application Server)が複数存在する場合は、
クライアント毎に接続先のHADBノードを変更する事でワークロードが
より均等になり推奨されます。
耐障害性について
各HADBノードは必ず１つのミラーノードを持っています。フラグメントを説明した箇所で
示した図によると、「Node 0とNode 1」、「Node 2とNode 3」、「Node 4とNode5」
の組み合わせになっています。これらのHADBノードが何らかの理由により障害発生した場合、
ケースに応じて異なる動作を行います。その動作の違いについて下記に説明します。
障害発生ケース１（ノードの自己復旧成功の場合）：
DRU 1上に存在するノード(Node 1)に障害が発生した場合、まず初めに下記の図のように、
データベースの操作を引き続き行えるように、DRU 0上のミラーノード(Node 0)が
サービスを提供するようになります。
(参照：A. Mirror node takeover
※ DRU 0の一番上のノードのフラグメントレプリカが両方とも白色になっています。)
次に障害が発生したノード(Node 1)ではノードの自己復旧を試みるため、メモリもしくは
ハードディスクから再起動を試みます。(参照：B. Node Recovery attempt)
障害発生ノードの自己復旧が成功した場合、DRU 0上のノード(Node 0)に対して更新された
データが存在する為、DRU 1上のノード(Node 1)で保持している障害発生時の
データと一致していない可能性があります。そこで、自己復旧完了後、DRU 1上の
ノード(Node 1)はDRU 0上のノード(Node 0)から更新ログを受け取りデータの同期を試みます。
（参照：C. Copy log records）
仮に更新ログの内容がデータの同期を行うために十分な情報を持っていない場合、
ノードの復旧処理は失敗します。そのような場合、次はノード修理という操作が行われます。
復旧に失敗した場合、プライマリノード(Node 0)が保持するデータや更新ログのコピーを
全て取得しノード(Node 1)の再構築を行います。
● ミラーノードから障害ノードに対して全てのフラグメントレプリカのコピーの実施
● ミラーノードから障害ノードに対して全ての更新ログのコピーの実施
上記の操作は、ノード間のデータが同期されるまで行われます。
最後に、全てのデータが同期された後、障害発生前の状態に戻します。
(参照：D. Takeback: Normal operation resumes)
障害発生ケース２（ノードの自己復旧失敗の場合）：
上記のケースと異なり、自己復旧やノードの修理ができないような場合は、
（例：物理的なH/Wシステム障害等）異なる動作を行います。
HADBはスペアノード(Node 7)を代わりに使用して
障害発生したノード(Node 1)が持つ役割を全て引き継ぐようになります。
下記の図において、「Node 1」の自己復旧に失敗した場合、スペアノード(Node 7)が
起動し、「Node 0」より全てのフラグメントレプリカのコピーと更新ログを
取得しノード(Node 7)を構築し初めます。そして全てのデータの同期が完了した後、
「Node 0」のミラーノードとして「Node 7」が設定されます。
そして、それ以外のノード(Node 2,3,4,5,6)に対してノードのペアが変更された事を通知します。
手順
AではスペアノードのTake Overが実施され２つのプライマリフラグメントレプリカを
保持しています。
Bでは「Node 1」が自己復旧を試みますが、失敗します。
Cではレプリカデータとログが「Node 0」から、他のDRU(DRU 1)に存在するスペアノード
の「Node 7」に対してコピーされます。
Dでは「Node 0」と「Node 7」の組み合わせで通常のサービスが提供されています。
また、「Node 1」が復旧した場合は、DRU 1におけるスペアノードとして稼働します。
以上でHADBの全体的な動作概要を説明しました。
まだ、説明がたりない点もありますが、HADBの動作について理解
いただけましたか？
上記のように、HADBは提供するDBサービスをH/W障害等が発生した場合でも
継続して提供できるように、自己回復機能やスペアノードを利用する等して実現しています。
結果として、HADBを複数台のノードから構成する事で99.999%の高可用性を実現できる
ようになっています。
インメモリリプリケーションではHADBに比べ高可用性率は若干低下します。
そこで、ミッションクリティカルのシステムでは是非HADBの御使用を御検討ください。
Entry filed under: Application Server/GlassFish.
寺田 佳央 - Yoshio Terada 