ミラー方式
より高速化するのであれば、ミラー方式となる。こちらはサーバーだけではなく、データベースもディスクも共用せず完全に正系と副系で二重化する。常にデータベースはミラーリングで同期がとれているため、システムダウン発生時にはクラスタ方式で行うDBスペース情報の読み込み、OSに対する物理オープン、共用バッファ準備、ダウンリカバリーといった処理は不要となり、より高速な業務再開が可能となる。
ミラー方式ではもうひとつ利点がある。副系にミラーリングを行うことは常時バックアップが行われていることにもなる。そこで正系を更新処理、副系を参照処理として負荷分散に活用することもできる。例えば副系で集計処理、あるいは本番データを持つテスト環境として利用することも可能だ。正系と副系があれば、データベースの保守作業も余裕をもって実施することもできる。
ミラー方式における異常監視と切り替えについてもう少し詳しく見ていこう。正常時は正系と副系でログデータがミラーリングされる。これはストリームで反映されている。基本的には正系の監視機能でSymfowareの異常を検知すると、副系の監視機能に通知されて切り替えが行われる。
正系がサーバーごとダウンした場合どうなるか。副系が正系の状態を取得できなくなると、副系からアプリケーションサーバーにあるGCM（Grand Connection Manager）に対して正系の状態判断がリクエストされ、GCMが正系ダウンと判断すると切り替え処理が行われる。もし正系と副系の間で通信障害が起きただけで正系が正常稼働しているなら、GCMは切り替え不要と判断して切り替えは行われない。
ミラー方式で行われるデータ同期はどのように処理されるか。アプリケーションがデータベースに更新を実行すると、正系にログデータが書き込まれる。もしログデータにCOMMITが含まれると、副系のログにも書き込まれる。副系のログに書き込まれたことが確認できるとアプリケーションにCOMMIT完了が通知されるという流れとなる。そのため、ミラー方式で切り替えが行われる場合、切り替えにかかる時間は1秒程度。ユーザーにサーバーのダウンや切り替えを意識させることはほぼないと言ってよさそうだ。
ミラー方式の技術を採用した実際の製品にFUJITSU Integrated System HA Database Readyがある。これはSymfoware技術を搭載した垂直統合型アプライアンスとなる。1台のアプライアンスの中にデータベースサーバーが複数稼働していて、常時ミラーリングを行っている。異常時には自動的に切り替えを行い、業務継続ができるようになっている。
***
クラスタ方式とミラー方式、いずれにしても万が一の切り札である。普段から頻繁に使う機能ではない。しかし災害やトラブルは予告なく発生する。いざという時に冷静かつ確実に対処できるようにするためにも、どのような機構で処理が進むのかは熟知しておいたほうがいいだろう。
関連URL
・FUJITSU Software Symfoware
・FUJITSU Integrated System HA Database Ready
