検索検索
English

〔Vol.4〕 データベース可用性のさらなる向上に挑む

【VOICEs - 技術解説インタビュー】HAクラスターソフトウェア「LifeKeeper for Linux v9.1」のリリースに伴い、極短時間での障害回復が可能なデータベース環境を目指す「Higher Availability」に関する技術情報が公開されます。その注目ポイントは？

テクノロジー2016年7月20日

目標は数分、数十分以上かかっていた切り替えを30秒～60秒以内に

― LifeKeeper for Linux v9.1（以下、v9.1）発表のタイミングで2つの情報が公開されます。その1つが、データベース可用性のさらなる向上を図るソリューションについてデザイン・検証した情報ということですが、そのねらいから教えてください。
五十嵐：データベースのさらなる可用性向上は、2016年度の製品戦略の柱となるテーマです。（ ⇒参考記事：「LifeKeeper戦略説明会2016を開催」）。金融機関や通信会社などのビジネス・社会基盤としての責務を果たす企業のシステム、または、ECサイトのように24時間止めずにオンラインで動き続ける要件を満たすシステムを開発・運用されるお客様からは、特にデータベースの可用性向上に対する要望が高まっています。

オポチュニティーロス（機会損失）の最小化や社会基盤を支える企業の信頼を守るために、LifeKeeperを提供する私たちだからこそ提示できる解決策はないか。そう考える中で追求してきたのが、データベースの可用性のさらなる向上です。この取り組みは、"より高いHA（High Availability）を目指そう"という意志を込めて「Higher Availability」と名付けています。

Webサーバーであれば分散処理によって仮に1台がダウンしても他の1台に切り替えることは比較的容易ですが、データベースは全体の整合性を図ることが重要なので、分散処理ではなく集中処理構成が前提です。その条件下で、いかに可用性を向上させるかが、ポイントになります。

小野寺：データベースのHAクラスター化には様々な方法がありますが、一般的なフェイルオーバー型HAクラスターでは切り替えに数分～数十分はかかります。例えば、データベースシステムのフェールオーバークラスターでは、本番機の障害を検知してから待機系ノードでデータベースを立ち上げ、ジャーナルファイルを用いてロールバック/ロールフォワードなどを行ってデータを引き継ぎ、IPアドレスを切り替え、サービスを再開するまでに数分から数十分を要します。

五十嵐：私たちの当面の目標は、これを30秒～60秒以内に切り替えるようにする、というものです。たしかにFault Tolerant（年間ダウンタイム5分以内ほど）構成や商用データベース製品の高価なオプション機能を採用すれば、短時間にすることもできますがその分、仕組みが大がかりになったりトータルコストがかさんだりするマイナス面も出てきます。

小野寺：そこでまずは、PostgreSQLとLifeKeeperを組み合わせたHAクラスター環境を構築し、それぞれのパラメーターを細かく調整することで切り替え時間を短縮できるか、ベンチマークをしています。そこで得られたベストプラクティスを技術情報として皆様と共有したいと考えています。


サイオステクノロジー BC事業企画部 BC事業企画グループ グループマネージャー 五十嵐久理（左）と、同グループ エバンジェリストの小野寺章（右）

PostgreSQLとLifeKeeperを連携させたソリューションをデザイン・検証

― なぜ、数あるDBの中からPostgreSQLを、LifeKeeperとの連携対象に選んだのでしょうか。
小野寺：いくつか理由があるのですが、PostgreSQLおよびその商用版であるEnterpriseDB（EDB）が市場で幅広いユーザー層を獲得していること、他の商用DBに比べて仕様がオープンになっていること、などが大きな理由です。

さらに、EnterpriseDB社から提供されている機能とLifeKeeperの連携で期待されるメリットにも注目しています。その機能とは、EnterpriseDBツールの一つである「xDB Replication Server」のことです。これはテーブル（表）単位でデータを複製する機能で、マスター・スレーブ構成でレプリケーションを行うシングルマスターレプリケーション（SMR）と、複数のマスターサーバーで構成するマルチマスターレプリケーション（MMR）の2つのレプリケーションに対応します。私たちが今回着目したのは、後者のMMRです。

xDB MMRとLifeKeeperを組み合わせ、2台以上のxDB MMRサーバーでシステムを構成します。xDB MMRによって一方のデータが更新されるともう一方のノードも、テーブル単位でデータが更新され、常にデータが同期されます。

― この仕組みにおいて、LifeKeeperの果たす役割は何でしょうか。
小野寺：xDB MMRサーバーの仮想化です。LifeKeeperを用いることでxDB MMRを構成する物理ノード全体が仮想化され、ユーザー側からはあたかも1つのデータベースを運用しているように見えます。

LifeKeeperのIPリソースは2台のxDB MMRサーバーのうちの１台に割り当てられ稼働系サーバーとして動作します。稼働系で実行される更新トランザクションはxDB MMRによって稼働系から待機系へ常に同期されているため、仮に稼働系ノードに支障が生じても、IPリソースを稼働系から待機系へ切り替えるだけでサービスが継続できます。データベースサーバー全体の切り替えではなく、IPリソースを割り当てるサーバーの切り替えで済みます。すなわちデータベースの立ち上げ、ロールバック/ロールフォワードなどは不要で、基本的にはIPアドレスの切り替えのみで済む、といった理由から、トータル数秒ほどでデータベースを切り替えることが可能ではないか、と期待しています。

xDBは、比較的新しい機能ということもあり、どのように設計するとよいか、パラメーターをいかに調整するか、など最善のパフォーマンスを引き出すための十分な検証が必要です。現在、EDBをサポートするLifeKeeperパートナー企業とともに共同で検証作業を進めているところです。その成果についてもホワイトペーパーなどでいずれ公開できればと考えています。

― EDBには、xDBのほかにも様々な可用性向上の仕組みを備えているようです。それらとLifeKeeperを連携させた試みも行われるのでしょうか。
小野寺：はい、xDB以外の機能についてもLifeKeeperとの連携を検討しています。
加えて、「Quick Service Protection（QSP）」（⇒連載第2回：「スクリプトレスでサービスの起動停止や監視を行うQuick Service Protection」）やGenericARKを用いたEDBの複数マスターサーバーの起動停止や監視状況把握、IPアドレス切り替えのトリガーとしての応用といった構想も温めています。

五十嵐：サイオスでは社会基盤を支えているという使命感を胸に、これからも主要なデータベース製品における可用性向上を通じて、皆様の課題解決のお役に立ちたいと考えています。

LifeKeeper for Linux v9.1で提供される、もう1つのソリューション「Dynamic Disaster Recovery」に関する情報は、次回記事で詳しく紹介する予定です。


記事の関連情報