AWS上で、障害発生時にも超短時間で回復が可能なデータベースシステムを実現するには?

    mmr基本構成

     データベースのシステムダウンが生む、多大なリスクをご存知でしょうか。ITシステムの中心的存在であるデータベースの停止は、システム全体の停止につながりかねない重大な事態です。アメリカのある調査資料によると、システムが1時間ダウンすると、33パーセントもの企業が100万ドル〜500万ドル以上もの損失に見舞われると報告されています。これを日本円に換算すると1分間でおよそ180万円〜920万円もの金額になるのです。

    さらに、企業を襲う損失は金銭ばかりではありません。企業としての信頼失墜、将来的な機会損失にすらつながりかねない大事態といえるのです。

    Webサーバーであれば、複数のWebサーバーを横に並べて、障害が発生したサーバーはロードバランサーが素早く障害を察知し、それを「切り離す」ことで被害の拡大を防ぐこともできますが、データベースの場合はそうもいきません。何故ならデータベースは複数のサーバーへ処理を分散させるのではなく、一つのサーバーで集中管理を行う構成が今も一般的だからです。この場合障害があったサーバーを「切り離す」という手法が使えず、待機系へ「切り替える」ことにより、ダウンタイムの短縮を図る必要があります。ところが、データベースの切り替えには結構な時間がかかるというのが現実です。

    そこでサイオスでは「障害検知からフェールオーバー完了(待機系でのサービス再開)までを30秒以内で完了するデータベースシステムの実現」というゴールを設定し、可用性を向上するための一連の試みを、“Higher Availability“ ソリューションとしてご提案したいと考え、2016年から実検証を初めとする活動を展開してきました。

    HAクラスターのHAは、高可用性(High Availability)を実現するクラスターシステムのことですが、“Higher” Availabilityは、おそらく比較級の”Higher”からご推測の通り、従来のHAクラスターで提供するHAに比べて“より高い” 可用性を実現することを目指す、サイオスの造語です。

    昨年このブログでは、LifeKeeperのチューニングにより、いかに素早くノード障害やアプリケーション障害を検知し、フェールオーバーに要する時間を短縮できるかの検証結果を公開しました。

    “Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。(第1回)~リソース監視処理
    “Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。(第2回)~ノード監視処理
    “Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。(第3回)~その他の短縮方法を考える

    しかし、Higher Availabilityのゴールである、「障害検知からフェールオーバー完了(待機系でのサービス再開)までを30秒以内で完了する」という課題をクリアするためには、根本的な対応が必要ということもわかりました。

    監視対象であるDBMS自体は、フェールオーバー時に待機ノード上でいくつかのリカバリー処理を行った上で起動をしなければならず、これらの処理には(DBのサイズや障害発生時のワークロードにもよりますが)それなりの時間を要し、またそれらに要する時間はLifeKeeperのチューニングでコントロールできる部分ではないからです。

    フェールオーバーに要する時間

    そこで私たちが着目したのが、EnterpriseDB xDB マルチマスターレプリケーションです。これはDBサーバーが相互に表の同期(レプリケーション)を行い、どのDBサーバーにアクセスしても参照・更新が可能となるものです。

    mmr基本構成

     この仕組みを利用することで「障害発生時に、待機系でのDB起動をしなくても良い仕組み」が構築できるのではないかと考え、以下のようなLifeKeeperと組み合わせた構成を検討しました。

    待機系でのDB起動をしなくても良い仕組み

    本構成のポイントは以下の通りです。

    • 2台のサーバーにインストールされたEDB xDB MMRは単体で機能する
    •  クライアント(App/PC)はLK IPリソースによって保護された仮想IPへアクセスすることでEDB xDBへのアクセスを行う
    • データベース、およびxDBは各ノードで稼働しているが、仮想IPが活性化しているノードへのみクライアントからのアクセス(Read/Write)があるため、実質的なアクティブノードとなり、もう一台はスタンバイノードとして機能する
    • アクティブノードへの更新はxDB MMRの機能によりスタンバイノードへ同期される(Synchronized:10秒(デフォルト)

    検証構成

    実際にこの環境をオンプレのサーバー上で構成し、ノード障害を発生させたところ、

    • ノード監時間間隔短縮
      →4秒(ノード障害時の障害検出時間:4秒)
    • リソース監視インターバル短縮
      →10秒(アプリケーション障害検出インターバル)
    • ローカルリカバリー機能の無効化
    • IPリソースの切り替えのみでサービス再開

    つまり、障害発生からサービス復旧までは、目標の30秒以内よりもはるかに短い時間で完了することができました。

    Higher Availability DB(xDB MMR + LifeKeeper)on AWS EC2

    この後さらに、AWS EC2上で本構成(xDB MMR + LifeKeeper)を動かして、パフォーマンス測定を実施しました。

    システムの概要と構成

    システムの概要は以下の通りです。

    システム概要

     

    システム構成図

    また、オンプレでのテスト時と同様、xDB MMR + LifeKeeper(LK)構成は以下を特徴としています。

    • 2台のサーバーにインストールされたEDB xDB MMRは単体で機能します。
    • クライアント(App/PC)はLK IPリソースによって保護された仮想IPにアクセスすることでEDB xDBへのアクセスを行います。
    • データベース、およびxDBは各ノードで稼働していますが、仮想IPが活性化しているノードへのみクライアントからのアクセス(Read/Write)があるため、実質的なアクティブノードとなり、もう一台はスタンバイノードとして機能します。
    • アクティブノードへの更新はxDB MMRの機能によりスタンバイノードへ同期されます。(Synchronized;10秒(デフォルト)

    xDBMMR+LK構成

    環境構築手順

    次に、本環境を構築する手順をご説明します。

    ステップ1:AWS環境の構築

    SIOS Protection Suite Step by Step Guide【AWS編】に基づきAWSの環境を構築します。
    ダウンロード(資料請求)はこちらから:https://mk.sios.jp/BC_WP_AWS.html

    ガイドに記載の事項と異なる主な点は以下のとおりです。

    •  AWSデフォルトのノード名は長いので/etc/sysconfig/networkを修正し任意のノード名を設定(LK01,LK02,NAT1,NAT2,client1,client2)
    • LifeKeeperノード(LK01、LK02)ではENIは1つだけ設定(eth0)
      →Communication pathは1つのみ設定
      →LKのGUIでハートビートの冗長化チェックを外しGUIサーバアイコンの“warning”表示を回避
    • NAT1、NAT2、Windowsインスタンスはスタック起動時にパブリック IP アドレスを割り当ているので、ElasticIP割り当ては不要。ただし、スタックを起動する毎にIPアドレスが異なる。

    ステップ2:GUI環境の構築

    • PPAS、xDBのインストールおよび操作ツールはGUIが主となるため、LK01、LK02にデスクトップ環境とVNCをインストールし、WindowsサーバーからVNCビューアーで直接 LK01(LK02)にGUIでアクセスできる環境を構築します。
    • Node1,LK02hへのGUIおよびVNCサーバーのインストール
      1. GUI関連パッケージのインストール
       $ sudo yum groupinstall “Desktop” “Desktop Platform” “X Window System” “Fonts”
      2. VNCの導入
       $ sudo yum install tigervnc-server
      3. VNCアクセス用のユーザー作成
       $ sudo useradd vncuser
       $ sudo passwd vncuser
      4. VNCの設定ファイル”/etc/sysconfig/vncservers”の編集
      (ディスプレイ番号1にvncuserのアクセスをして1024×768の画面サイズで起動する場合)
       —–追加—-
           VNCSERVERS=”1:vncuser”
        VNCSERVERARGS[1]=”-geometry 1024×768 -nolisten”
       ————-
      5. vnc接続用のパスワード設定
       $ su – vncuser
       $ vncpasswd
       Passwd:
       Verify:
      6. vncの自動起動設定と起動
       $ su – root
       $ chkconfig vncserver on
       $ service vncserver start

    ステップ3:アプリケーション環境構築準備

    • EDB用user(enterprisedb)の作成(LK01、LK02)

      $ groupadd –g 1000 enterprisedb
      $ useradd –g 1000 –u 1001 –d /home/enterprisedb -s /bin/bash enterprisedb
      $ passwd enterprisedb

    • ユーザ環境変数の設定 (.bash_profileに追記)

      export PGDATA=/opt/PostgresPlus/9.5AS/data
      export PGDATABASE=edb
      export PGUSER=enterprisedb
      export PGPORT=5444
      export PATH=/opt/PostgresPlus/9.5AS/bin:.:$PATH
      alias edbplus=’/opt/PostgresPlus/9.5AS/edbplus/edbplus.sh’

    • LifeKeeper、PPASソフトウェアのアップロード(LK01、LK02)
      Windowsサーバーの任意のフォルダーにLKのインストールCDイメージ(sps902.img)およびPPASインストーラ(ppasmeta-9.5.0.5-linux-x64.tar.gz)をアップロードします。ローカルのPCからコピー&ペーストでアップロードできます。

    • LifeKeeperのインストール(LK01、LK02)
      「Step by Step Guide」 P.53を参考にインストールをします。

    ステップ4:CloudFormation

    • 構築したAWS リソース(検証環境)から AWS CloudFormation テンプレートを作成し、検証環境をCloudFormationのスタックとして起動できるようにします。
    • テンプレート作成は必須ではありませんが、ステップ3までに構築した環境をスタックとして起動することで、いつでもステップ5(Enterprisedb環境構築)から検証を開始できます。
    • Cloud Formerを起動する前に、修正を加えたインスタンス(Windows、LK01、LK02)からイメージの作成を行います。
    • 作成したテンプレートはS3バケットにセーブされます。
      詳細は以下のドキュメントを参照:
      http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-using-cloudformer.html
    • テンプレートが完成したら、スクリプトをエディタで開き “ImageId”: “ami-xxxxxxxx“の部分を新たに作成したAMIのIDで上書きします。
    • CloudFormationでスタックを起動したのちに、AWSコンソールでNAT1、NAT2の各インスタンスで「送信元/送信先の変更チェック」を無効としてします。
       「Step by Step Guide」 29ページ参照

    ステップ5:EnterpriseDB環境構築

    • WindowsインスタンスにRDPで接続し、VNCビューアーでLK01(LK02)に接続します。
    • terminalを開きrootユーザーとして作業を実施します。
    • インスタンスのデスクトップを直接操作し、PPASおよびxDBをインストールします。
    •  EDBのインストール
      • Postgre Plus Advanced Server(PPAS)および xDBをLK01とLK02でインストールします。
      • EDB社から製品をダウンロード時に使用したユーザー名、パスワードがインストール時に必要です。
      • PPASのインストールはGUIとテキストモードが選択可能です。
      • StackBuilderはGUIのみなのでX11の環境が必要です
      • Java 1.7以上の環境が必要です。
      • WindowsサーバーからVNC経由でLK01、LK02のデスクトップを表示します。
    • シングルパブリケーションサーバ構成
      • 最もシンプルな構成で、LK01ノードに設定したパブリケーションサーバーによりDBを同期します。(edb←→mmrnode)

    シングルパブリケーションサーバ構成

    ステップ6:LifKeeperの設定

    • EDBリソースを作成します。
    • IPリソースとEC2リソースを作成します。
    • EDBリソースとIP/EC2リソースの依存関係を定義します

    LKの設定

    ステップ7:/etc/default/LifeKeeperの修正

    • 物理サーバーでの検証時と同様に障害検出時間の短縮のための設定を実施
    • App障害検出時間の短縮
      • LKCHECKINTERVAL=30
    • ノード障害検出時間の短縮
      • LCMHBEATTIME=1
      • LCMNUMHBEATS=2

    動作確認

    1. ルートテーブルシナリオの動作確認

    まず、ルートテーブルシナリオの動作確認結果は下図のようになりました。

    ルートテーブルシナリオの動作確認

    2. APPリソース監視の確認

    PPAS、xDBプロセスを確認します。(PPASリソース、xDBリソース障害)

    • GenericARKでserviceコマンドによるステータス確認を実施するスクリプトを作成
      [running : exit 0]、[not running : exit 1]
    • restore/removeは行わずquickCheckのみを実施
    • 障害検知時に依存関係のあるIP/EC2リソースをフェールオーバーさせる

    検証結果

    以下のケースでIP/EC2リソースの切り替えが実施され、クライアントからのDBアクセスが速やかに復旧できることを確認しました。

    • コンソールからインスタンスを停止*1
    • Linuxのterminalからserviceコマンドでサービスを停止(PPAS、xDB)

    *1:shutdown strategyをSwitchover resourcesに変更

    AWS関連情報

    Amazon EC2の可用性向上について

    LifeKeeperやDataKeeperによるAmazon EC2上でのクラスター構成についてご紹介しています。

    AWS向け資料ダウンロードはこちら

    お問い合わせ先

    「もっと詳しい話を聞いてみたい。」「自分の持っている案件は対応できそうか?」といった場合は、下記までお気軽にお問い合わせください。

    https://mk.sios.jp/BC_Web_Free-entry_Inquiry.html