エンドツーエンドのハイ・アベイラビリティーとディザスターリカバリー
どこまで広く深くカバーしたいのか、それを実現できるソリューションはどれか
ディザスターリカバリー(DR)製品とハイ・アベイラビリティー(HA)製品は2つの異なる製品クラスに属し、総合すればデータとアプリケーションのアベイラビリティーのカテゴリに属すると考えているITプロフェッショナルの方が多いようですが、これは誤りです。
アベイラビリティー製品の世界は、総合的にみれば、アプリケーションとデータの100%継続的なアベイラビリティーの提供がほぼ可能となるようなより広範な範囲を含んでおり、HA製品もDR製品もカバーしていない、見過ごされることの多い重要なアベイラビリティーのギャップの橋渡しも含まれます。自社にとって現実的なHA/DRの目的を見出すにはアベイラビリティー製品の世界を良く理解するとともに、HA/DRの一般的な用語や標準、目的などを理解しておくことが必要です。そうした理解を自分のものにしてから、自組織のアベイラビリティーの目的達成を支援できるテクノロジーを調査することができるようになるのです。まずはこの世界を俯瞰し、次にテクノロジーを見てみましょう。
アベイラビリティーの世界をマッピングする
アベイラビリティー製品の世界をプロットするときは、復旧時間と復旧完全性を両軸とする2次元のグラフを使用することが多いようです。復旧時間を表す軸は、目標復旧時間(RTO: Recovery Time Objective)というラベルが付けられ、災害が発生してからデータや運用を復旧させるのに必要な最大時間に対する組織の目標を表します。RTO軸上における製品の位置は、その製品を使用した時に予想される復旧時間を表します。
RTO軸の一般的なマッピングは単に順位を示すにすぎません。たとえば、他のすべての項目が等しければ、ディスク・ベースの復旧はテープ・ベースの復旧よりも高速だということを示すことができます。しかしながらそのようにマッピングされているからといって、特定の企業のデータの復旧時間がわかるわけではありません。なぜなら同じ復旧方式と復旧テクノロジーを使用したとしても、1テラ・バイトのデータを保有する企業は、100テラ・バイトのデータを保有する企業よりもより高速に復旧できると思われるからです。
従来のアベイラビリティー製品を表す図のもう一つの軸は、一般的には目標復旧ポイント(RPO: Recovery Point Objective)というラベルが付けられています。ここでもこの軸上での製品の位置は、その製品が復旧ポイントをどの程度満たすことができるかを表しています。ただし、「復旧ポイント」という用語は混乱を招きかねません。もっとわかりやすい名前は「復旧完全性」でしょう。
RPOという用語を理解するには、組織のデータの追加、削除、更新を連続的なデータ・ストリームと考えると良いでしょう。組織のRPOとは、災害が発生したときにそのデータ・ストリーム上で戻らなければならない一番過去の目標時点になります。その時点以後にそのストリームで発生した更新は復旧できないため、「目標復旧ポイント」と呼ばれています。
HA製品は通常、この2次元のグラフ上の、復旧時間がゼロに近くてデータの喪失危険性がゼロに近い個所にプロットされます。これは誤解を招きかねず、場合によっては正しくありません。
HA製品の目的とするところは復旧を支援することではなく、そもそも復旧させる必要を回避しようとすることです。HA製品は冗長性を利用することで、あるレベルの障害が発生してもビジネス・システムをシャットダウンせずに済ませたり、オンライン・データを決定的に破壊してしまうことを避けたりするように設計されています。どの程度の保護を提供しているかは製品によって異なります。
HA製品を上手に適応させるには、図―1に示すように従来からあるアベイラビリティー製品の図に3つ目の軸、すなわちビジネス・システムの堅牢性を加える必要があります。しかしアベイラビリティー製品の世界を正確に表現するのはこれよりさらに複雑です。アベイラビリティー製品は、その提供する保護の範囲がそれぞれ異なります。たとえば、RAIDのようなテクノロジーは、単一のシステム・コンポーネントのみの堅牢性を改善するように設計されています。これに対してHAソリューションの一部は、ビジネス・システム全体の堅牢性、アベイラビリティー、復旧性に対応しています。
組織のアベイラビリティーの目標を設定することは簡単なことではありません。もちろんコストを無視すればあらゆる組織が目標復旧時間をゼロ、目標復旧完全性を100%とするでしょう。問題はコストを無視できないということです。他のすべての条件が同じであれば、RTO、RPO、堅牢性の目標を厳しく設定すればするほど、その目標を達成するためのソリューションにより多くの費用が必要となります。
現実的な復旧目標
アベイラビリティーの世界のディザスターリカバリーの部分だけを見ても、IBM iを使用しているほとんどの部門が強気の目標を立てています。Vision Solutions社が出資しているイニシアティブである情報アベイラビリティー協会(IAI: Information Availability Institute)が、IBM iとAIXを使用している部門の約2000人の技術専門家とエグゼクティブに2007年7月から2008年7月の間でアンケートを実施しました。その集計結果によると、IBM i使用部門のうち回答があった部門の約40%は、RTOを6時間以内に設定しているようです。しかも全体では、回答した部門のほぼ55%は、災害発生後12時間以内に運用を復旧するという目標を立てているようです。RTOに関するIAIの調査結果をまとめた棒グラフを図―2に示します。
復旧完全性の目標についても図―3の棒グラフに示すように厳しいものになっています。ご覧になっておわかりの通り、IBM i使用部門の約39%が、データが1件たりとも喪失することが一切ないことという目標を設定しています。さらに22%の部門が数分で復旧できるデータならリスクを覚悟すると回答し、さらに他の10%の部門は最高1時間までで復旧できるデータの喪失なら甘受すると回答しています。しかしながらこれらの目標を達成するのに必要なテクノロジーと方策を採用している組織は多くはありません。
「Vision Solutions社がスポンサー提供しているIAIの調査に参加した多くの企業は、非稼働時間を最小限にするための強気な目標復旧時間や目標復旧ポイントを達成したいと掲げていますが、その設定された目標を達成するのに適切なテクノロジーを備えていません。」と同社のマーケティング＆ビジネス開発担当上級副社長のエドワード・ヴェセリー氏は述べています。「ディザスターリカバリーとハイ・アベイラビリティーは関連がありますがその目的はまったく異なります。ディザスターリカバリーはデータのバックアップと復旧を可能にするものですが、ハイ・アベイラビリティーは稼働時間を最大化するためのシステムのスワップやフェイルオーバー機能なども含んでいます。一般的に、調査した企業では上記両エリアに対応するソリューションを採用するところが増えてきていますが、ディザスターリカバリー・ソリューションで壊滅的なデータの喪失から保護することに、より大きな焦点が当てられているようです。と同時に、データを任意の時点に復旧あるいは巻き戻すことを可能にした連続データ保護(CDP: Continuous Data Protection)などといった新しいテクノロジーにも注目が集まってきています。」
こうした数字をみると、目的を達成できそうにない準備状況にあるというヴェセリー氏の仮説も真実味を帯びます。IAIの調査に回答を寄せたIBM iを使用している部門のうち、自分たちのDR計画が完全でテスト済みであり、いつでも準備が整っていると回答した部門は15%以下でした。
本稿では以後、アベイラビリティーの目標を達成するのを支援するいくつかのテクノロジーを紹介します。
データ・リカバリー・ソリューション
データ・リカバリー・ソリューションにはテープ、ジャーナリング、CDPなどがあります。これらについてもう少し詳しく見ていきましょう。
テープ
テープがこの世に出てからもう数十年になりますが、バックアップ用メディアの最終手段として今でも広く使用されています。テープが唯一のバックアップ用メディアという組織はまだまだ多いようです。しかし、復旧時間、復旧完全性、そしてとくに堅牢性という3つのアベイラビリティーの測度においてテープは不十分といえます。
テープ・ドライブはここ数年でかなり高速になりましたが、データベースのサイズも格段に大きくなっています。その結果、大規模なデータセンターをテープから復旧させるのはまだまだ時間がかかる作業です。
同様に重要なのは、テープによるバックアップでは復旧完全性が保証できないことです。バックアップ・テープが作成されるのは一般的には夜間です。真夜中にバックアップが作成され、災害が翌日の午後11:59に発生したら、ほぼ丸1日分のデータを喪失することになります。
バックアップの頻度だけを考慮すると問題を過小評価することになります。たとえば、多くの企業ではバックアップ・テープをオンサイトで一晩保管し、翌朝別のサイトに輸送します。したがってテープ作成後、別のサイトに輸送されるまでの間にデータセンターに災害が発生すると、1日以上のデータが危険にさらされることになります。
さらに、災害はめったには起こりませんが、データの破損や誤操作による削除が発生する頻度は災害よりは高いです。その結果、多くの企業では最新のバックアップ・テープをオンサイトで保管していますから、この種のデータ喪失からの復旧を思い出す必要がないのです。テープは次の世代のテープが作成された時だけオフサイトに送付すれば良いのです。したがって、オフサイトのテープは最大で48時間前のものになることが多いようです。
さらにテープはあてになりません。業界の統計情報によれば、テープからデータを復旧しようとした場合の約1/4は完全に成功していません。したがって、オフサイトに保管してある最新のバックアップ・テープが48時間前のものだとすると、災害が発生した時点より72時間以内の時点には復旧できない組織があるかもしれないということです。
テープの信頼性はデータを復旧する時点のときだけ切実に感じられるというものではありません。データをテープに保存するのは通常毎日実施していますが、この作業自体も運用に支障をきたす恐れがあります。
かつてはバックアップ・ジョブの実行中はアプリケーションを停止しておかなければなりませんでした。稼働中にバックアップを保存する機能が登場したおかげで、この制約は今はありません。それでもバックアップ・ジョブはデータをディスク・ドライブからテープにできるだけ速くコピーします。今日の高速テープ・ドライブを使用するときは、その操作がディスクの入出力チャネルに対して負荷を与える可能性があります。その結果、バックアップ・ジョブの実行中にシステムの運用を継続することは可能ではありますが、実用的ではないかもしれません。
テープにはいろいろ欠点はあるものの、陳腐化したわけではありません。IAIの調査に回答したAIXおよびIBM iの使用部門の約79%は、依然としてデータ保護方法の1つにテープを使用しています。さらに、テープはディスクと比較すると低コストのメディアであり、しかも完全無欠のバックアップ戦略というものはないわけですから、テープは依然としてしばらくの間は少なくとも最後の砦として残るでしょう。
ジャーナリング
ジャーナリングは変更のあったすべてのデータの事後イメージ、およびオプションで使用できる事前イメージを取得しておくことで、テープの復旧完全性の弱点を補足することができます。テープからデータを復旧した後、ジャーナルを使用してデータファイルへの変更を進めて破損が起こった時点まで進めることができます。当然のことですが、ジャーナルが利用可能でなければ復旧はできません。しかし、主要なデータベースを破壊した災害はおそらくローカルのジャーナルも破壊している可能性が高いです。IBM iのリモート・ジャーナル機能はこの弱点を補うことができます。
リモート・ジャーナルはジャーナル・エントリをローカルの・ジャーナルに書き込むのと同時にリモートにあるジャーナルに書き込みます。リモート・ジャーナルを備えているシステムは、同じ災害で両方のシステムが被害を受けないように、プライマリー・システムから十分遠い場所に設置されます。
リモート・ジャーナル機能は、同期モードあるいは非同期モードのいずれでも動作します。同期モードは、リモート・ジャーナルへの書き込みがユーザーのトランザクションの一部であるため復旧の完全性が100%となります。この場合、書き込み操作は、ジャーナル・エントリがリモートシステム側に受理されその確認が戻ってくるまでは完了していないとみなされます。
同期リモート・ジャーナリング機能はもっとも厳しい復旧完全性の目標をサポートしていますが、ジャーナル・エントリを送信して確認を受け取るまでに必要な時間がアプリケーションの性能に悪影響を与える可能性があり、とくにネットワークが混雑しているときはその影響が大きくなるため、あまり使用されることはありません。
非同期モードはローカルのトランザクションとリモートのジャーナル・エントリ処理を分離します。その結果、エントリがリモート・ジャーナルに送信されている間、ユーザーは待たされることがありません。この方法では、ローカルとリモートのジャーナル書き込み操作の間で待ち時間が発生することになりますが、ローカルとリモートのサーバーの性能が適切でネットワークの帯域幅が十分であれば、非同期ジャーナル機能は100％近い復旧完全性をサポートすることができます。
連続データ保護
連続データ保護(CDP: Continuous Data Protection)とほぼ同等のテクノロジーであるデータ・ボールトはリモート・データ・ジャーナリングと似たような機能を実行します。これらの機能は運用データに適用された更新を捉え、それを2番目のシステムに伝送します。CDPはジャーナリングとは異なってオペレーティング・システムやDBMSの一部ではなく、独立系ソフトウェア・ベンダー(ISV)製のソフトウェアによって実行されます。
データ・ボールト、あるいはCDPの利点は、2番目のシステムに保存されたデータが通常は、特定の1つのオペレーティング・システム固有ではない単純なファイル構造を使用しているという点です。したがって、バックアップ・システムとプライマリー・システムが同じでなくてもかまわないのです。たとえば、低コストのLinuxやWindowsシステムをIBM iサーバーのデータ・ボールトとして使用することが可能です。
またCDPはスタンド・アロン製品として入手可能であり、一部のHA製品の1機能として提供されているものもあります。CDPがHAの機能として含まれているときは、セカンダリー・システムはプライマリー・システムと同じオペレーティング・システムを使用しなければなりません。ただし、ハードウェアのモデルやOSのバージョンまでは必ずしも一致していなくても良いようです。
CDPとデータ・ボールト・ソフトウェアには一般的に、必要に応じてバックアップ・システムからのデータの復旧を自動的に行う組み込み機能が含まれています。バックアップ・データの保存は、すべての組織のデータを復旧させるには不十分であることが一般的です。その代わりに、データの保存に必要な空間を節約するために、古いデータの更新はおそらく新しいバックアップ・テープがバックアップ・サイトに到着した時点で消去されることが多いようです。したがって災害発生後の復旧は通常最新のバックアップ・テープのデータを読み込むことから始まります。次に、読み込まれたデータは、データ・ボールトまたはCDPサーバーからのデータを使用して最新の状態になります。
データ・ボールトまたはCDPは連続的に発生する可能性があるので、ほぼ100%の復旧完全性を提供するか、または更新がバッチ処理されてスロー期間中などに一定間隔でバックアップ・システムに送信されます。
CDPはテープのバックアップや後述する堅牢性ソリューションが対応していないアベイラビリティーのギャップを埋めるものです。テープのバックアップはある特定の一時点、通常は一晩前のデータを復旧します。堅牢性ソリューションは、現在のデータをなにがなんでも守ろうとします。ただしいずれのソリューションも、任意の時点におけるデータを復旧することはできません。しかし任意の時点におけるデータを復旧することが一番頻繁に求められることなのです。
オペレーターやユーザーが誤ってデータやファイルを削除してしまうことはよくあることです。そしてデータは他の人為的ミスやハードウェア障害、悪意を持った行為で破損されてしまう場合もあります。理想的には、そのデータ項目が破損したり削除されたりする直前の状態に復旧できることが望ましく、CDPソフトウェアはそのための機能を提供します。
データ・ジャーナリングも、データが破損した直前の時点にデータをロールバックしたりロールフォワードさせたりできますが、組み込みのジャーナリング機能だけを使用すると、手間がかかりしかもエラーが発生しやすい作業となります。ただし、管理下にあるジャーナル復旧ソフトウェアがこの処理を自動化しかつ簡素化してくれます。
堅牢性ソリューション
堅牢性ソリューションの目的とするところは、復旧作業そのものを不要にすることです。復旧作業を不要にする代わりに、定期的保守や予期せぬ壊滅的な事象が発生したとしても、ビジネス・システムが運用を継続できることを保証しようというものです。堅牢性ソリューションがうまくいっている限りにおいては、究極のRTOとRPOをサポートしていることになります。つまり、ビジネス・オペレーションが決して停止せず、データも決して喪失しないのです。
RAIDなどといった一部の堅牢性ソリューションは、単一の脅威に対する保護のみを提供します。地理的に分散されたHAソリューションなどといったその他のテクノロジーは、データセンター全体を壊滅させるような災害に直面した場合も含めた何が起ころうと、ビジネス・システムを継続的に利用可能にしようとするものです。
おそらくこうした堅牢性テクノロジーを最低でも1つはすでに使用されていることでしょう。Power Systemsサーバー上で稼働しているIBM iは、今日市場で使用されているシステムの中でも最も信頼性のあるシステムの1つです。しかし信頼性が高いからといってアベイラビリティーが高いとは限りません。ハードウェア・サーバーが利用可能なときでも、ビジネス・システムが利用可能とは限りません。たとえば、ビジネス・データが破損されればサーバーはビジネスの運用をサポートできません。
さらに、サーバーの信頼性は平均故障時間だけを表しています。信頼性は、例えばハードウェアやオペレーティング・システムをアップグレードしなければならないときや、データベースを再構成しなければならない時の非稼働時間をなくすことはできません。つまり、サーバーの信頼性が高くても、その他の堅牢性テクノロジーを考慮する必要があるのです。
RAID
もっとも一般的な堅牢性テクノロジーは、もはや今では当たり前の世界になっていますが、RAIDです。RAIDはRedundant Arrays of Independent Disks (独立ディスクの冗長配列)の略で、それぞれのディスク配列の等価な位置にある各データ・ビットのパリティ値を計算します。いずれか1台のディスクに障害が発生した場合は、そのデータは通常パリティ値と他のディスク上にあるデータから再構成できます。この再構成処理はバックグラウンドで実行されます。処理速度は再構成が実行されている間は若干低下しますが、ユーザーはほとんど気づきません。
RAIDはデータのフルコピーを保存しているわけではないので、記憶域に対する要件も一般的には10~25%多く必要となるというものです。RAIDテクノロジーはここ数年で進歩しています。古いバージョンは複数台のディスクに障害が発生した場合にはデータを保護できませんでしたが、今はハイレベルのRAIDではこの脆弱性がなくなっています。
ハードウェアの堅牢性
個々のハードウェア・コンポーネントの障害に対する保護を提供するソリューションもあります。こうしたソリューションはここで紹介するにはあまりにもたくさんありますが、冗長内部電源や冗長ネットワーク・カードを使用したものもあります。
無停電電源装置
ハードウェアの堅牢性ソリューションと同様に、UPSは単一の非稼働事象すなわち電源喪失という事象に対してのみ対応します。UPSソリューションの防御の最前線は、バッテリーのバックアップです。バッテリーが供給する電力は有限ですから、システムを安全にシャットダウンさせるのに必要な時間が与えられるというだけのことです。
現代のUPSソリューションにはソフトウェアが添付されている場合がほとんどで、これを使用すると、ある一定時間以上電力が供給されない場合などといった特定の条件下で、自動的にシステムをシャットダウンすることができます。バッテリーを使用しているUPS製品を、UPSのバッテリーが消耗する前に電力を生成しはじめるバックアップ・ジェネレータで拡張することができます。
UPS製品を使用するときは、バッテリーを使用し続けると充電力が低下するということを覚えておいてください。したがって、バッテリーを製造元の使用に従って交換する必要があります。
ディスク・ミラーリング
ディスク・ミラーリングはディスク全体のビット単位のコピーを保持します。IBMのPower Systemsサーバー上では、Metro Mirror IBMストレージ・サブシステムまたは Global Mirror IBMストレージ・サブシステムでミラーリング機能が利用できます。またEMC Symmetrix外部ストレージ配列のEMC SRDF (Symmetrix Remote Data Facility)も、ミラーリング機能を提供しています。
ディスク・ミラーリングは同期でも非同期でも実行できます。ミラーリングされるディスク間の最大距離は、同期ジャーナリングの技術仕様で規定されています。たとえば、IBMはMetro Mirror製品で最大300 km(186マイル)の距離を規定しています。これは技術上の制約ではなく、実用上の制約です。同期ミラーリングされている2台のディスクの距離が離れすぎていると、アプリケーションの応答速度が実用に堪えないほどにまで低下する可能性があります。実際には、300 kmという限界距離は長すぎると考えるのが普通です。その結果、同期ミラーリングされているディスクは、同じ災害で両方のディスクが破壊されてしまうくらい近くに設置されていることが多いようです。
Global Mirrorは同期モードでも非同期モードでも動作します。非同期ミラーリングは距離の限界を取り除きます。ミラーリング機能はローカル・データの書き込みとは独立していますので、ミラー・ディスクがどんなに離れたところにあってもアプリケーションの性能に影響を与えることはありません。ただし、これはローカル・データへの書き込みとミラー・ディスクへの書き込みの間には遅延が発生するということを意味しています。したがって、災害が発生した場合はミラー・ディスクでは完全なデータの復旧が望めないかもしれません。
HAソフトウェア
HAソフトウェアもまた「論理複製」にクラス分けされ、2番目のシステム上にあるすべてのデータ、アプリケーション、システム・オブジェクトの完全な複製を保持しています。このバックアップ・システムは運用マシンと同じモデルである必要がないばかりか、オペレーティング・システムが同じレベルのバージョンである必要もありません。
HA製品は様々ですが、バックアップ・システム上で稼働しているソフトウェアは、一般的に運用システムのアベイラビリティーを監視することができ、必要に応じてバックアップ・システムへのフェイルオーバーを起動することができます。またHAソフトウェアは、たとえば、保守などでプライマリー･システムをオフラインにしなければならない時などに切り替えを手動で起動する機能も提供しています。
HAはそれがどのように導入されるかによって様々なレベルのアベイラビリティーを提供しています。たとえば、HAソフトウェアは2つの物理システムがあることを前提としておらず、同じサーバー上の2つのLPARパーティション間でデータを複製させることができます。この設定により、データベースの再構成やアプリケーション・ソフトウェアのアップグレード、あるパーティションのオペレーティング・システムのアップグレードなどといった種類の保守中でも、ビジネス・オペレーションを継続させることができます。ただし当然のことですが、物理的なサーバーがクラッシュしたり、保守のためにサーバーをシャットダウンさせたりする必要があるときは、ビジネス・オペレーションを継続させることはできません。
同じ建物や同じオフィスに設置されている2台の物理サーバー間で複製をすることで、上記のようなあらゆる場合でオペレーションを継続させることができますが、データセンターを破壊するような災害からオペレーションを保護することはできません。そのような場合は、両冗長サーバーとも破壊される可能性が高いです。HAソフトウェアはそのほとんどが任意の距離を置いて設置されたサーバー間での複製を可能にしています。したがって、主データセンターを襲った災害の影響を受けない場所に、完全に冗長なホット・スタンバイしているサーバーを設置することが可能です。
またHAソリューションは、最後の砦として依然としてテープを使用している場合に、テープ・バックアップの問題の1つを解決することができます。バックアップ・システムには運用データの完全な複製が含まれていますから、バックアップ・テープはバックアップ・システム上で作成することができ、実運用システムの負荷を低減させることができます。
クラスタリング
IBM iの世界では、クラスタリングはHAソフトウェアやディスクのミラーリングの代わりを務めるのではなく、これらを拡張するものと位置付けられています。実際、IBM iのクラスタリングは、HAの論理複製かまたはディスク・ミラーリングを使用してクラスタ内のデータの複製を維持しています。
クラスタリングがHAソフトウェア単体よりもすぐれている点は、実運用システムの健全性の監視が、「ハートビート・モニタリング」というクラスタリング技術を使用して実行されているという事実に基づいています。クラスタは実運用ノードのハートビートがないことを検知したら、クラスタ内のバックアップ・ノードへのフェイルオーバーを素早く起動することができます。
クラスタリングの問題点は、非常に高速なフェイルオーバーを数分あるいは1秒以内に実行するためにアプリケーションをクラスタ対応にしておかなければならないということです。今までのところクラスタリングの採用はゆっくり進んでいるので、アプリケーションをクラスタ対応にしていないアプリケーション・ベンダーがまだ多いようです。
分析して行動へ
問題はどのHAあるいはDRソリューションを実装すべきか、ということです。その答えは、場合によりけりということです。ある大手のオンライン・ブローカーは、システムが非稼働状態になると1時間につき数百万ドルの損失を被ることになる可能性があります。したがって、複数の冗長性を持つ地理的に分散されたクラスタ・ノードとクラスタ対応のアプリケーションにこだわります。この種のソリューションを採用するための費用は高くつきますが、こうした企業では非稼働時間で損失する金額の方がもっと多いのです。
同様に、銀行は銀行システムに対して100%の復旧完全性目標にこだわります。なぜなら、彼らにとってデータを喪失するということは、自社あるいは顧客のお金の追跡ができなくなることを意味しているからです。これとは対照的に、紙ベースの注文だけを受け取る、トランザクション量の少ない製造業者は、そのような厳しいRPOを満たすことのできない安価なアベイラビリティー・ソリューションを選択するかもしれません。
最適なアベイラビリティー・ソリューションの選択は企業によって異なります。たとえば、小売業社は、人事システムに対するRTO、RPO、堅牢性の目標とウェブ・ストアに対するRTO、RPO、堅牢性の目標とでは異なる目標を設定するでしょう。
つまり、アベイラビリティーに対する要件を慎重に分析する必要性からは逃れることはできず、その上でそうした要件を限られた予算内で満たすことのできる最適のソリューションを見つけなければならないのです。
