1. ホーム /
  2. クラウド /
  3. AWS上で、障害発生時にも超短時間で回復が可能なデータベースシステムを実現するには？

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

    mmr基本構成

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

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

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

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

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

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

    “Higher Availability” DBを目指して、LifeKeeperをチューニングしてみました。（第１回）～リソース監視処理
    “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は１つだけ設定（eth0）
      →Communication pathは１つのみ設定
      →LKのGUIでハートビートの冗長化チェックを外しGUIサーバアイコンの“warning”表示を回避
    • NAT１、NAT２、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

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

    • 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を参考にインストールをします。

    ステップ４：CloudFormation

    • 構築したAWS リソース（検証環境）から AWS CloudFormation テンプレートを作成し、検証環境をCloudFormationのスタックとして起動できるようにします。
    • テンプレート作成は必須ではありませんが、ステップ３までに構築した環境をスタックとして起動することで、いつでもステップ５（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ページ参照

    ステップ５：EnterpriseDB環境構築

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

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

    ステップ６：LifKeeperの設定

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

    LKの設定

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

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

    動作確認

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

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

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

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

    PPAS、ｘDBプロセスを確認します。（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

     

    SNSでもご購読できます。