nkjmkzk.net

powered by Kazuki Nakajima

EC2でOracleのバックアップサイトを構築しマルチサイト運用を実現する

言わずもがな日本に大きなインシデントがあり、ITシステムにもシステム構成に変化が起きようとしているのを感じます。マルチサイト運用の必要性です。

  • 例えデータセンターであっても一カ所にデータ・システムを置いておくことへの危機感
  • 地理的な事情によって停電・節電でシステムの継続運用が難しくなっている状況
  • 長期的な影響が見込まれるなかで、サイトの移転を検討(移転先でも一カ所での運用は避けたい)

システムをメインサイトからバックアップサイトへと軽やかに切り替えるような仕組みがあれば、と思います。しかし切り替えたいと思い立ってすぐに切り替えられるものではありません。物理的にどうやってもすぐには移せないのは大量のデータです。100TBのデータを夕方までにアメリカに移したい!と思っても時既に遅し、です。高速ネットワークをもってしも、物流をもってしても不可能です。

なのでサイトを軽やかに切り替えるにはデータはあらかじめコピーしておき、その後継続的に同期し続けることが必要になります。つまりマルチサイト運用に不可欠な要素は「データ同期」と「切り替えの仕組み」だと考えています。

また、不可欠ではないものの、現実的な導入にあたってはコストの壁をクリアする必要があります。災害対策というのは皆必要性は認識しつつも、インシデント発生確率に対してかかる費用があまりに大きいため、多くのプロジェクトでは先送りされる項目でしょう。しかし今実際にインシデントが発生し、脅威はリアルになっています。そんな中、このコストの壁を乗り越えるためのソリューションが仮想サイト、つまりパブリッククラウドだと考えています。

まとめると、僕はマルチサイト運用を実現するには非常に重要な3つの要素があると整理しています。

マルチサイト運用に重要な3つの要素

  • データ同期
  • 切り替え
  • 仮想サイト

僕はすでに起こってしまった被害を復旧するような危機管理ソリューションをOracle製品に見い出すのは難しいと考えていますが、これから起こる事態に備えるリスク管理ソリューションをより現実的な形でパワフルに提案することはできると考えており、それに当面心血を注ごうと考えています。

それがEC2とOracle Databaseのレプリケーション機能(Data Guard)を組み合わせたバックアップサイトの構築です。

データ同期

Data Guardはデータベースをリアルタイムにレプリケートするための機能で、まさに今利用しているメインサイトのデータベースを、リモートのバックアップサイトに同期させるにうってつけの製品です。

切り替え

また、Data Guardは軽やかな切り替え機能を装備しています。不可避な停電に際し意図的にシステムをバックアップサイトに切り替え、そしてまたメインサイトに切り戻すことができます。必要に応じてシステムを稼動させるサイトを選択することができるのです。

仮想サイト

そしてこの構成を現実的にするのが仮想バックアップサイトであるパブリッククラウドです。特にEC2であれば世界中からバックアップサイトをクリック一つで選択し、スタンバイデータベースを作成することができます。しかもこれまでもっとも大きな障壁であったサーバ、ストレージ等をもう1セット購入するという初期設備導入費用「ゼロ」で。これは明らかにブレークスルーです。レプリケーション機能とパブリッククラウドが特に相性が良いことを示すユースケースの一つでしょう。

Data Guardとパブリッククラウドを組み合わせたバックアップサイト構成には下記のようなメリットがあります。

  • なんと言ってもバックアップサイトのH/W設備投資がゼロ。
  • 状況に応じてアクティブなサイトを切り替えられる。バックアップサイトでもすでに全プロセスが起動してスタンバっているため切り替えも高速。
  • 同期には低負荷のREDOログ転送が用いられるが、さらにこれを圧縮転送することが可能なため回線負荷を低減できる。
  • メインサイトでブロック破損が発生してしまった場合、バックアップサイトから正常なブロックが透過的に取得されて自動修復される。
  • 同期の中断/再開が可能なためインスタンスを必要最低限の時間だけ起動するといった鬼節約が可能
  • あくまでもバックアップサイトにパブリッククラウドを適用するため、未だパブリッククラウドを信用できないでいる人にも敷居が低い。(実際には僕は可用性はともかく、データの保全性はローカルサイトにユーザが構築するストレージよりも相当高いと思います。そういう意味でも適した使い方。)

グランドデザイン

しかしサイトごと切り替えるとなると、データベースだけ切り替えても目的は達成できません。関連するアプリケーションサーバも連動して切り替え、システムを利用するクライアントからのトラフィックを適切にルーティングする必要があります。

システム構成は環境によって多岐に渡るため決定版的な構成を提唱するのは難しいですが、データベースとアプリケーションサーバ、そしてユーザからのトラフィックが切り替える対象であると仮定すると次のようなアーキテクチャが考えられます。

  • データベースはData Guardによってレプリケート&切り替え。
  • アプリケーションサーバは同構成をバックアップサイトにあらかじめ用意し、コンテンツの更新が発生する場合はコンテンツをACFS(ASMクラスターファイルシステム)に格納してACFSのレプリケーション機能を擁してバックアップサイトのアプリケーションサーバへ同期する。
  • ユーザからのトラフィックは、社内DNSレコードを更新することによって、該当ドメインをバックアップサイトのIPアドレス体系に書き換える。DNSレコードの更新は、DNSをAWSが提供するRoute 53にしておくことでAPIを通じてデータベースとアプリケーションサーバの切り替えと連動する形で自動実行させることができる。インターネットではDNSレコードは伝播遅延が懸念されるが、社内用DNSであれば階層構造をとらなければクライアントに依らずリアルタイムに切り替えが行われる。

・通常時のトラフィック

 

・メインサイト停止時のトラフィック

可及的速やかにこのような対応を行う必要がある方、ご連絡ください。出来ること、出来ないことがありますが、全力でサポートさせていただきます。

kazuki.nakajima@oracle.com

 

without comments

Written by 中嶋 一樹

4月 7th, 2011 at 4:17 pm

Posted in Uncategorized

Tagged with , ,

Leave a Reply