Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

ディザスタトレラント(耐災害)クラスタの構築法・後編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
ディザスタトレラント(耐災害)クラスタの構築法・後編
ディザスタトレラント(耐災害)クラスタの構築法・後編
地域災害に対応するMetrocluster
大規模広域災害まで対応できるContinentalclusters

大規模広域災害まで対応できるContinentalclusters

HPが提供する3つめのソリューションであるContinentalclustersは、数100km〜数1000km離れたサイト間でのDTクラスタ構築を実現する。例えば米国西海岸と東海岸、もしくはニューヨークと東京といった規模でのフェイルオーバーが可能となる(図2)。

図2:Continentalclusterのネットワーク構成
図2:Continentalclustersのネットワーク構成
  こうした長距離のネットワーク接続では遅延の発生が避けられないため、Extended Campus ClusterやMetroclusterのように1つのServiceguardクラスタを構成することはできない。そこでContinentalclusterでは、サイトごとに個別のクラスタを設け、「クラスタからクラスタへのフェイルオーバー」を行う。またクラスタ・ロックは利用せず、ディザスタ発生時には両サイトの運用担当者が連絡を取り合うことでスプリット・ブレインの発生を防ぎ、手動でフェイルオーバーを開始する。

Continentalclustersでは、各サイトのクラスタがそれぞれ独立しているため、両サイト全体を1つのサブネットとしたり遅延を200ms以下に抑えたりする必要がない。よってダークファイバ接続は不要で、IPネットワークであればどのような種類の回線でも利用可能だ。FibreChannelもFC-IPコンバータを通じてIPネットワークで収容する。ストレージ間のミラーリング方法としては、Metroclusterと同様にCA XPおよびCA EVA、EMC SRDFをサポートし、さらにOracleデータベースのレプリケーション機能(Standby DBやData Guard)も使える。ちなみにContinentalclustersにおいてOracle RACを利用する際は、それぞれのサイトで個別のRACを構成し、「RACからRACへ」のフェイルオーバーを行うことになる。

Continentalclustersも国内外での導入実績が多い。例えば国内では、小売大手のユーザがContinentalclustersによるDTクラスタを2002年に構築している。この事例では、HP SuperdomeおよびHP StorageWorks Disk Array XP512で構成されたSAP R/3システムを、数100km離れた国内2か所のデータセンターに設置。それぞれのXP512の間ではContinuous Access XPによるミラーリングを実施している。これにより、ディザスタ発生時には数時間以内で業務を継続できる体制を整えた。


ディザスタリカバリは「IT以外」が肝要

鬼山 浩樹氏
  日本ヒューレット・パッカード ITコンサルティング本部 シニアコンサルタント
鬼山 浩樹氏
以上、本特集ではディザスタリカバリ・システムの技術的側面にフォーカスして説明した。だが、「ITシステムの継続」と「業務の継続」の間には大きな隔たりがある。その点について、日本ヒューレット・パッカード ITコンサルティング本部 シニアコンサルタントの鬼山 浩樹氏は「ITシステムは意外と早い時期に復旧できるが、業務の復旧には時間がかかることが多い。本来のディザスタリカバリには、業務プロセスを含めた全社規模的な対策が必要となる」と説明する。

鬼山氏が特に強調するのは、「ディザスタ発生から業務復旧までのプロセス化の必要性」である。「きちんとプロセス化しておかないと、ディザスタ発生時に『とりあえず集まって議論する』という事態になりがち。こうした『考える時間』を極力なくすのがディザスタリカバリのポイントだ。二次災害を起こさないためにも、誰がどこにいて何をすべきかを明確に定義すべき」であるという。鬼山氏は、ディザスタリカバリ体制構築のポイントとして、以下の点を挙げる。

  • 議論の時間を最小にする
  • プロセスを文書化する
  • 属人性(担当者への依存性)を排除する
  • 適切な変更管理(業務プロセスの変更への対応)を実施する
  • 定期的な確認や訓練を実施する

また鬼山氏は、同氏がこれまで経験した「ディザスタ発生の現場」の実情をもとに次のように提言する。「フェイルオーバー時には何らかのトラブルが発生するものと考えた方がよい。よってトラブル時の対処ルールをあらかじめ決めておく必要がある。通常は、ハードウェアやデータベースなどのインフラ部分よりも、アプリケーション部分に想定外のトラブルが発生しやすい。そのため、アプリケーションのDR分析(災害対策化すべきポイントの洗い出し)を実施し、フェイルオーバーに耐えるシステムの構築に注力すべき。また災害時には、各拠点の状況が掴めずに混乱しがちになるので、30分おきに状況報告するなどの連絡網を設けておくことが重要になる」

以上、本特集ではディザスタリカバリ・システム構築のための技術と方法論を概観した。「テクノロジ」と「業務プロセス」は、企業の業務継続性を支える両輪であることがご理解いただけたはずだ。

トップへ 戻る    

その他のコラム(特集)もお読み下さい

 
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。
印刷用画面へ
プライバシー ご利用条件・免責事項