Jump to content 日本-日本語

サーバー  >  HP Integrity NonStop サーバー 

HP NonStopサーバーの災害対策-1

HP Integrity NonStop サーバー

アドバンテージ
コンテンツに進む
システム担当者様が抱える悩みを解決!HP NonStopソリューションセミナー開催中!!

HP NonStop サーバーの災害対策 HP NonStop サーバーの災害対策

なぜHP NonStopサーバーは911テロ当日に復旧できたか?
――HP NonStopサーバー災害対策のメカニズムを探る

HP NonStopサーバーの災害対策-1
  HP NonStopサーバーの災害対策-2
 
ITソリューション
事業継続・災害対策
 

「アメリカの強さ」を示した災害対策システム

100年以上の歴史を持ち、世界で4番目に大きい商品取引所であるNYBOT(ニューヨーク商品取引所)。コーヒーやココア、砂糖といったいわゆるコモディティを扱う同取引所は、2001年のアメリカ同時多発テロ事件により文字通り「壊滅」し、取引停止を余儀なくされました。しかしNYBOTでは、事前に準備した災害対策プランに基づき、ニューヨーク郊外のロングアイランドに設置されたバックアップ・システムへの移行を直ちに実施。事件当日の午後8時にはすでにバックアップ・システムの稼働準備が整っていたといいます。立会所のスペースや電話回線の不足により実際の取引再開には1週間ほどを要したものの、システム面では災害対策のお手本とも言えるきわめてスムーズな対応を見せました。いわば「アメリカの強さ」を示したこの事例は、NYBOTが1995年から運用を開始したHP NonStopサーバーによる災害対策システムのたまものです。  

HP NonStopサーバーの災害対策は、世界各国の金融機関、通信事業者などで70年代から広く導入されています。とりわけイギリスの金融機関では歴史的にテロ対策のニーズが高く、それに応えるかたちでHP NonStopサーバーの災害対策も完成度を高めてきました。その結果、災害対策としては世界的にもオンリーワンの地位を確立しています。国内でも20年前から都市銀行に導入されているほか、大手コンビニエンスチェーンのPOSシステム、大手家電メーカーの受発注システムなどの災害対策システムを実現しています。

図1:国内大手コンビニエンスチェーンでの導入事例
  図1:国内大手コンビニエンスチェーンでの導入事例
[拡大画像を表示] このリンクをクリックすると、新しいウィンドウが開きます
図1は、国内大手コンビニエンスチェーン(以下、CVS)に導入されたHP NonStopサーバーによる災害対策システムの構成図です。このCVSでは、元々UNIXサーバーで構築されたPOSシステムが運用されていましたが、高負荷時にはセンター側のホストで注文の取りこぼしが発生したり、災害対策が手つかずであったりという課題を抱えていました。そこでHP NonStopサーバーによる災害対策システムを導入し、国内約数千店と取引先約数百社、そして西日本と東日本にデータセンターを置くPOSシステムを新たに構築。負荷分散を実現しつつ業務継続性の確保を実現しました。
では、こうした第一級の災害対策システムは、実際にどのようなアーキテクチャによって実装されているのでしょうか。以下では、その背後のメカニズムにスポットを当てます。

災害対策システムの運用形態

図2:災害対策システムの運用形態
  図2:災害対策システムの運用形態
一般に災害対策システムは、右図の3種類の運用形態のいずれかをとります。

NYBOTでも用いられていたのが、1)の「Active-Standby型」です。この形態では、現用系とほぼ同規模の待機系を遠隔地にも用意します。待機系は通常時には稼働させず、現用系のダウン時に切り替えて使用します。

一方、2)の「Active-Active型(共有式)」では、待機系でも同一の業務を運用します。いずれか片方のダウン時には、もう一方が縮退運転することで肩代わりします。つまり、災害対策と同時に負荷分散も実現するモデルです。このActive-Active型では、双方で同じ業務を運用するため、それぞれのデータをいかに同期させるかがポイントとなります。

最後の3)「Active-Active型(非共有式)」は、2つのシステムで別々の業務を運用し、現用と待機の2つの役割を相互に担う仕組みです。この場合、共有式のようにデータの同期を考慮する必要がないため実装が容易で、かつ資産も有効活用できます。

レプリケーションの実現方法

いずれの形態においても、災害対策システムの要となるのが、データの「レプリケーション」(コピー)の実現方法です。

図3:レプリケーションの実現方法
  図3:レプリケーションの実現方法
1)の「リアルタイム逐次反映型」は、現用系で更新されたデータ内容を、待機系にもリアルタイムに送信します。とはいえ、遠く離れた待機系のデータ更新を確認しながら処理を進める方法(完全同期型)では、高いパフォーマンスは得られません。そこで、現用系へのデータ更新が終わるとアプリケーションは直ちに次の処理に進み、待機系へのデータ更新はバックグラウンドで実行します。この場合、現用と待機の間ではわずかな時間(例えば数秒)のデータ内容のズレが生じますので、待機系に保存されているデータは厳密な意味での最新版ではありません。しかし、災害対策によってアプリケーション性能が損なわれない点がメリットです。

一方、2)の「リアルタイム完全同期型」は、待機系へのデータ更新をアプリケーション側で確認しながら次の処理に進む方法です。1)に比べるとパフォーマンスは低下しますが、現用と待機のデータ整合性を完全に保証でき、障害時の切り替え後にもデータの不整合が起きることはありません。市場取引や決済など、厳格な整合性が求められる用途に適しています。

最後の3)「バッチ更新型」は、例えば1日に数回のバッチ処理により現用から待機へと更新内容をコピーする方法です。3種類のアプローチのうち、ネットワークやシステムのコストをもっとも低く抑えられる方法です。データ更新処理の頻度が少ない用途や、必ずしも最新のデータでなくても大きな問題とならない用途(情報提供サイトなど)に向いています。

このように災害対策システムにおけるレプリケーションは、つねに「パフォーマンス」と「データ整合性」のトレードオフとなります。通常運用時のパフォーマンスを損ねることなく、いかにして業務上求められる整合性を維持するかがポイントです。

  次のページへ

ご相談窓口

電話 電話
エンタープライズ向け製品の
ご購入前のご相談
03-5749-8279
09:00-19:00(月曜 - 金曜)
10:00-17:00(土曜)
※日曜、祝祭日、5月1日、年末年始など日本ヒューレットパッカード(株)の休業日を除く
Webからのお問い合わせ Webサイト
各種製品・サービスの
ご購入について

※機器のお見積については、代理店、または弊社営業にご相談下さい。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。

Executive Briefing Center


印刷用画面へ印刷用画面へ
プライバシー ご利用条件・免責事項