大阪で開催されたdb tech showcaseでは富士通株式会社の杉山幸吉氏が登壇し、Symfowareの高信頼性を実現するための技術詳細を解説した。高信頼性の実現にはハードウェアの性能を引き出す技術やデータ圧縮技術など多様にあるものの、今回はサーバー切り替えを行うクラスタ方式とミラー方式に焦点が当てられた。ビジネスの継続で重要視されるデータ保護とシステムの継続には欠かせない技術だ。具体的にどのような仕組みで切り替えが行われるのか、実際に切り替えに要する時間はどのくらいか、実践的な内容に踏み込んで杉山氏は解説した。
クラスタ方式
まずはクラスタ方式。クラスタ方式ではデータベースサーバーが運用（本番）系と待機系に分かれるものの、データベース（ストレージ）は共有する。サーバーに何か問題が生じればサーバーを切り替える方式だ。このクラスタ方式では待機系の状態により、3通りに分類することができる。切り替え時間の長い順からウォームスタンバイ、ホットスタンバイ、高速ホットスタンバイとなる。
ウォームスタンバイから待機系でどのような処理が行われるか見て行く。運用系でシステムダウンが発生すると、クラスタソフトウェアがネットワークを切り替えた後、待機系が準備を開始する。切り替え処理はDBスペース情報の読み込み、OSに対する物理オープン、ログ読み込み、ダウンリカバリー（パラレルリカバリー）、共用バッファ準備、コネクション再接続が行われ、晴れて業務再開となる。これら一連の処理を行う場合、大規模なデータベースでは分単位の時間を要する。
このウォームスタンバイにおけるダウンリカバリー段階ではパラレルリカバリーという技術が用いられており、高速化のために並列化が行われているという。ログの読み込みやリカバリー用のスレッドなどが並列で処理され、リカバリー時間を短縮できるというわけだ。
より高速に切り替えできるのがクラスタ方式のホットスタンバイだ。こちらはウォームスタンバイにおけるDBスペースの読み込み、OSに対する物理オープン、共有バッファ準備をまとめて「プレオープン」としてシステムダウンの前に実施しておけるため、この部分が短縮できる。コネクション再接続もプレコネクションに代わり、高速化する。またダウンリカバリー段階ではパラレルリカバリーのほかにキャッシュリカバリー技術も加わり、さらに高速化される。ホットスタンバイはウォームスタンバイと比較してより短時間で業務再開にこぎつける。
さらに高速ホットスタンバイではホットスタンバイに比べてダウンリカバリー段階がより高速になる。ここで使われる技術はフラッシュトリートメントリカバリーと呼ばれている。通常運用時はネットワーク経由でトランザクションログを運用系から待機系のメモリに送信するようにしており、障害発生時には待機系に送られたメモリ上のログから読み込むため高速に切り替えできるようになっている。
ここまでがクラスタ方式となる。しかしクラスタ方式ではどうしても切り替えに伴うダウンリカバリー段階の処理は避けられない。また本当に障害が発生したことを確認するため「けっこう踏ん張る」のだそうだ。「踏ん張る」とは、障害が起きてもクラスタがOSなどに誤検知がないか等の問い合わせを行うために、すぐに障害と判断しない、切り替えないということだ。そのため高速ホットスタンバイでも切り替えには30秒程度を要する。ここがクラスタ方式の限界であり、30秒という切り替え時間を許容可能なシステム向けと言えるだろう。
一方、健全に動作しているシステムがもう一つあるので、異常検知すると、検知した方を切り捨て高速にもう一つのシステムに切り替えるのがミラー方式だ。
ミラー方式
より高速化するのであれば、ミラー方式となる。こちらはサーバーだけではなく、データベースもディスクも共用せず完全に正系と副系で二重化する。常にデータベースはミラーリングで同期がとれているため、システムダウン発生時にはクラスタ方式で行う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
