データとサービスをアクセス可能にする：RPO、RTO、およびSLA計画

今日は、IT管理者、システムインテグレーター、実装コンサルタントなど、ITスペシャリストの観点からデータアクセシビリティの概念を明確にしようとします。 この記事が、適切なソフトウェアおよび/またはハードウェアソリューションの実装、およびサービスレベル契約（SLA）のビジネスケースを作成する際に読者に役立つことを願っています。

はじめに、2つの仮説を「記憶の結び目」として定式化しますが、その多くは非常によく知られています。

• RPO （回復ポイント目標）-許容されるデータ損失。 情報システムは、（内部的な手段であれ、サードパーティであれ）許容レベルを超える損失からデータを保護する必要があります。
  
  
  
  
• RTO （目標復旧時間）-許容されるデータ復旧時間情報システムは、（内部または外部を問わず）許容可能な期間内に作業を復元する機能を提供する必要があります。

多くの場合、このインジケータのペアは、時間軸に沿って1次元グラフとして表示されます。

しかし、このような1次元チャートでは、ビジネスが導く最も重要なものはありません-お金です！ ビジネスの要件に基づいて、RTOとRPOを計算する方法については、カットの下で教えます。









「ストーブから」、つまり時間軸に沿った直線から始めましょう。ここで、

• イベントポイントはシステムの誤動作を示します
• このポイントの左（つまり過去）は、ターゲットRPO値です
• 右側（つまり、将来）に、目標RTO値がマークされます

（ここでは、特定のシステムに対して特定の値が必要であるため、ターゲットについて説明しています。）





社内のすべてのシステムがそのように機能するのではなく、さまざまなニーズ/目標に対応していることは明らかです。 会社自体がお金を稼ぐ（そして使う）。 システム障害が発生した場合、会社は明らかにお金を失っています。 RTOとRPOのパフォーマンスは、これらの損失の許容範囲を示しています。



したがって、2番目の次元がスケジュールに導入されます-財務（ここでは、お金-$）：







このグラフから、時間の経過とともにサービスのダウンタイムのコストが増加することはすでに明らかです。システムが機能しない時間が長ければ長いほど、会社はより多くのお金を失います。



データ損失のコストについても同じことが起こります。データを失うほど（歴史的観点から）、この損失は企業にとってより高価になります。 そして、はい、野生生物のこれらのグラフは対称ではありません。



原則として、これらのコストは直線的に変化せず、これは写真に反映されています。 多くの場合、損失のコストが急激に増加し始めるときがあります。そのため、企業がシステム障害により多くの損失を被り、一部の企業は事業を再開できなかった非常に悲しい話です。



このような問題から保護するには、データの損失と障害からの回復を保護するシステムを実装する必要があります。 このようなシステムには独自のコストがあるため、グラフに表示することもできます（青で描画）。







グラフからわかるように、データ損失の場合のRPOとRTOが低いほど、サービスのダウンタイムが短くなり、保護ソリューションが提供され、そのような保護はより高価になります。

保護決定の損益分岐点を定義する

そして、ここでグラフ上の曲線の交点を観察します-これらのポイントを緑の矢印でマークしました。 これらは、保護システムと保護された情報システムのいわゆる損益分岐点です。 この点から離れると、高価な保護システムが得られます。そのコストは損失/ダウンタイムのコストを上回り、またはその逆です-安価な保護システムですが、許容できるレベルの損失を提供しません。



結論はそれ自身を示唆しているようです：それは損益分岐点に焦点を合わせており、必要な保護を提供するシステムを選択する必要があります。



実際、実際の生活のデータに焦点を合わせてこのようなグラフを作成すると、わずかに異なる状況が得られます。 特に、保護ソリューションのコストのグラフは実線ではなく、ポイントのセットになります。 さまざまな保護ソリューションは、グラフに沿って互いに隣接して並んでいませんが、それぞれ独自の「座標」を持っているため、別々のポイントを表しています。 （RTO）。



さらに、原則として、1つの特定の情報システム（IS）ではなく、会社の情報システム（つまり、インフラストラクチャ全体）のグループ（またはすべて）を保護するソリューションが求められています。 さらに、このような各ソリューションには、ダウンタイム/データ損失のコストの時間依存性の独自のグラフが存在する可能性が高いでしょう。



損益分岐点はもはやポイントではなく、エリアであることがわかります。





インフラストラクチャをより詳しく見て、各IPのグラフを作成し始めると、興味深い傾向が見られます。システムは類似したものでグループ化されています。 以下について。

さまざまなクラスのソリューションを検討します

これまで「保護」について説明してきましたが、それがどのような保護であるかを規定していませんでした：バックアップ、クラスター、その他の保護の種類？ 保護システムは異なり、分類できると言う価値があります。



下の図は、推奨されるターゲットRTO / RPOに応じたソリューションのおおよそのクラスを示しています。







もちろん、写真ではすべてが非常に概略的に示されています。 実際、ソリューションのタイプとポイントの形式の正確な値の間に明確な境界はありません。



たとえば、現在、多くのバックアップソリューションは、バックアップからサービスを開始する技術を使用しています。 このテクノロジーを使用した可用性時間は、VMあたり平均で約2〜5分です。 そして、そのようなメトリックは、レプリカまたはクラスターのRTOの範囲内にあります。

クラスターについて少し

DRソリューション（および一般にデータの損失または回復から保護するためのほぼすべてのソリューション）のようなクラスターは、データ回復速度と失われるデータの量に関して独自の値を持っています。 したがって、これらはRTO / RPOのパフォーマンスにも関連付けられます。



たとえば、 HAクラスター（HA-高可用性）について言えば、 そのRTOはスイッチング時間に等しいことを意味します。 2つのノードのMSCSが30秒でDBMSを切り替えるとします。 つまり、このタイプのクラスターで提供できるターゲットRTOは30秒からです。



また、2分で動作するVMware HAを検討する場合（仮想マシン、そのゲストOS、およびアプリケーションの開始を考慮に入れて）？ これは、このソリューションが2分以上の目標RTO値を持つアプリケーションに適していることを意味します。



HAクラスター（および、それに応じたRPOの提供）の損失はどこですか？ サービスが上昇すると、わずかなデータ損失の可能性があります。 たとえば、DBMSがデータベースの状態をチェックし、その状態を誤って実行されたトランザクションにロールバックできる場合。 または、ファイルシステムが誤って保存されたバージョンのファイルなどに戻った場合など。



結論：たとえば、HA over HAのように、同じソリューションを重ねて構築する価値があるとは限りません。 これにより、インフラストラクチャが不必要に複雑になり、そのようなシステムの運用のサポートが複雑になります（そしてコストが増大します）。

2つのHAの前の例に。 アプリケーションに提供する必要がある実際のRTO値を決定しますか？ 2分を超える値の場合、VM内のサービスのHAクラスターのコストも意味がありません。

いくつかの要因に注目しましょう。

1. さまざまなアクセシビリティシステムがさまざまな問題を解決し、さまざまなリスクをカバーします（リスク管理は別の問題です）。 また、異なるクラスターでさえ、さまざまな潜在的な問題を解決し、相互に補完することができます。
   
   
   
   

   たとえば、メールサーバーのバックアップは除外されませんが、メールサーバー用のHAクラスターの使用を補完します。 クラスターは、物理サーバーの障害から保護し、バックアップサーバーへの高速切り替えを提供します。 ただし、クラスターは、データ損失（不要なリモートデータ、ハードウェア障害後にVMを起動できないなど）から保護しません。 これにはバックアップの使用が必要です。

2. クラスター自体を呼び出して、さまざまな障害から保護し、相互に補完することもできます。 たとえば、Micosoft Exchange DAG-cluster（HA）は、クラスターのコンピューティングノードの1つ（サーバー自体）の障害に対する保護を提供するだけでなく、データが他のノードに複製されるという事実によるサーバーディスクの障害の場合にも提供します。
   
   
   
   VMware vSphere HAを共有する利点は何ですか？ 保護をすばやく復元します。 1つのMS Exchangeノードを持つ1つのサーバーが単にシャットダウンした場合、最初にDAGが機能し、サービスを別のノードに切り替え、次にHA VMwareがクラスターのもう一方の肩に障害のあるサーバーをロードします。 これでシステムの準備が整いました。 （この例では、クラスターの1つの機能だけでなく、プラットフォーム自体の他のすべての利点のために仮想化の使用を検討します）。
   
   
   
   
3. 上記のチャートでも、アーカイブの決定に注意しました。 アーカイブの場合、RTOを考慮することは意味がありません。そのようなソリューションは古い履歴データを復元するために使用されるためです。 このような履歴データについては、RPOを提供する必要があります。 つまり、この場合、会社の現在の営業活動に使用されていないデータの深さと長期保存について話しているのです。

したがって、さまざまなソリューションを組み合わせて使用​​するのが適切です。 主なことは、賢明にアプローチし、ソリューションが適用される理由を理解することです。

私たちは正しく話し、書きます！ または、再びRTOとRPOについて

私はこれに焦点を当てたいと思います。なぜなら私自身は定期的に間違いを犯しているからです。

RTO≠リカバリ速度！

RPO≠失われたデータの量！

RTOとRPOは、満たすべき最大のフレームワークである情報システム（IS）の目標値です。 そして、これらの目標値は、私たち、ITスペシャリスト、ビジネス、またはむしろ関連するIPのビジネスオーナーに与えられますが、その逆はありません。



それは：

これは、インスタントリカバリのRTO機能が2分であることを意味するものではありません。

1日1回のバックアップが24時間のRPOであると想定することはできません。

すべては逆方向、つまりビジネスからのものであり、特にRTOについては次のように発表されます。

特定のサービスでは、このサービスを提供するシステムに障害が発生した場合、このサービスのダウンタイムを5分（RTO-5分）以上許可せずに回復を保証する必要があります。 そのため、5分未満でシステムを利用できるソリューションが適しています。

またはRPOの場合：

データベースでは、DBMSに障害が発生した場合、障害が発生してから24時間を超えない期間、許容可能なデータ損失を伴う復旧を保証する必要があります。 したがって、1日に1回より頻繁に作成されるリカバリポイントからのベースの確実なリカバリを提供するソリューションが適しています。 同時に、24個のリカバリポイントを作成する1時間に1回のバックアップは、1ポイントのみを実行する1日1回のバックアップよりも多くのリカバリを保証します。

これが実際の例です

ビジネスが次のように発言するとします。 「これは非常に重要で重要なサービスであり、5分間以上アイドル状態にある場合、<そのような金額>-財務上の損失が発生し、30分のダウンタイム後-10倍になります！ そして、これは会社にとってもはや受け入れられません。」



次のような理由が考えられます。

「インスタントリカバリを使用すると、2分で技術的なリカバリプロセスが提供されます...」

しかし！ この場合、さらにいくつかのポイントを理解する必要があります。

1. まず、障害の瞬間を追跡する必要があります。
2. 障害の結果を特定します。すべてが壊れているか、何かが利用可能です。
3. 障害の原因を見つけるか、少なくとも問題をローカライズ（分離）することをお勧めします。火災が発生した場合は、同じインフラストラクチャに何かを復元する前に消火します。 ウイルスがデータを損なう場合、感染したサーバーをネットワークから切断し、復元されたサーバーにウイルスを送り込まないでください。
4. 次に、蘇生の方法を決定します（最適な回復手順：VMを再起動する、クラスターが別のノードに切り替わるのを待つ、またはバックアップから復元する）。
5. 回復を決定し、実際に回復を開始します。

これはすべて、全体的な回復時間に影響します。



したがって、さらに議論します。

「このサービスの監視を設定しました。通知は機能し、1〜2分で通知されます（ポケットから受信したSMSの電話を取得するか、新しい手紙でメールクライアントを開く必要があります）。 私はコンピューターに座り、ピンガヌサービスを利用してコンソールを開き、ハイパーバイザーとハードウェアが何であるかを確認します。 私は一次蘇生を実行します（車を再起動しようとします）。 このすべてに約15分を費やします。 迅速な蘇生処置が役に立たない場合、バックアップから回復します。 ただし、データはバックアップからさらに15〜20分間コピーされるため、2分でインスタントVMリカバリを使用してから、マシンのデータの実稼働へのオンライン転送を開始します。

ご覧のとおり、5分ではほとんど適合しません。



さて、2分の回復時間を持つHAクラスターが必要なのではないかと考えてみましょう。 ただし、すべてのタイプの障害に対する保護は提供されません：BSoDでのマシンの再起動は非常に可能性が高く、VMディスクも障害ポイントなどです。 したがって、追加の保護が必要です。 それで、私たちは議論を続けます：

「クラスターの場合、2分で回復します。 さらに、すでに推定したように（a）、バックアップから復元する場合は15 + 2分を費やし、2 + 15 + 2 = 19分だけで、残りは11分です。

その結果、IPビジネス所有者に対する回答は次のようになります。

「OK。 RTOは30分後に提供します。 「このサービスをクラスターに含めて、5分間のRTOを提供し、バックアップをセットアップして、より深刻な結果をもたらす障害から保護します。」

非常に重要です！ 最も重要なアドバイス：IP所有者の特定のターゲットに同意したら、同意します-必ず書面で彼との契約を記録し、彼とサービスレベル契約（SLA）に署名してください。

なぜこれを「アクセシビリティの概念」と呼ぶのですか？

「データリカバリとサービスリカバリ」を絶えず書いていることに気づきましたか？ ほとんどの場合、私は1つの文で一緒に書きます。 これらは相互に接続された2つのものであり、ほとんどの場合、お互いなしでは生きられません。



サービスを復元しましたが、同時にすべてのデータを失いました-これは受け入れられません。 データベースを復元しましたが、DBMSが起動せず、データを読み取ることができません-これは受け入れられません。 これが、データとサービスの両方の可用性について話している理由です。 RPOとRTOの両方が重要です-一緒に両方の可用性を提供します 。

障害発生後15分で、以前の全作業期間（最大1時間を含む）のデータを使用したサービスへのアクセスが復元されました。これは一般的な可用性に関するものです。

ここにそのような二元論があります;）一緒に、RTOとRPOの二重のペアは、障害が発生した場合にサービスとデータの可用性を確保するという点で、特定のISのまさにサービスレベル契約 （ SLA ）の重要な指標です。 そして、前述のとおり、IPの所有者（サービスの顧客）とあなた、IT部門（サービスプロバイダー）の間で対応する契約が締結されます。

---

関連リンク：

• バックアップのテストの重要性。
• お金についての詳細（ビジネス、ビジネス継続性、およびRTO / RPOとの適合性について）