勉強前イメージ
災害起こったときどうする？って計画のイメージ
オンプレとクラウドでサービスを作っておくとか、
クラウドの中でも別拠点での構築とかそんなイメージ
調査
Disaster Recovery とは
Disaster Recovery(ディザスタリカバリ) とは略してDRとも呼ばれます
日本語では災害復旧ともいわれます。
地震や津波などの天災や、テロ、不正侵入などによりシステムが壊滅的な状況になった際に復旧・修復することを指します。
Disaster Recovery で考えないといけないこと
Disaster Recovery を構築するには、メインのデータセンターやクラウド以外に別の地点でバックアップを取る必要があります。
また、復旧方式には3つポイントがあります
- RPO : Recovery Point Objective
- どの地点のデータまで戻すのか
- RTO : Recovery Time Objective
- いつまでに復旧させるのか
- RLO : Recovery Level Objective
- どの程度の業務レベルまで戻すのか
RPOとRTOに関しては こちら に詳細を記載しています
復旧レベルの例
| 復旧レベル | コスト | DR方式 | 概要 |
|---|---|---|---|
| RPO : 数週間 RTO : 数日 |
低 | テープメディアへのバックアップ | バックアップデータをDR倉庫へ運搬 |
| RPO : 1,2日 RTO : 数日 |
中 | 非同期バックアップ | バックアップデータをクラウドにコピー |
| RPO : 数時間 RTO : 数時間 |
中 | 非同期レプリケーション 手動フェイルオーバー |
本番システムと非同期でレプリを行い、手動でフェイルオーバーさせる |
| RPO : 数分 RTO : 数分 |
高 | 同期レプリケーション 自動フェイルオーバー |
本番システムと同期レプリを行い、自動でフェイルオーバーさせる |
| RPO : 数秒 RTO : 数秒 |
高 | システム同期 | どちらのシステムも本番として使用 |
- テープメディアへのバックアップ
バックアップデータをテープに保存して、DRの倉庫に運搬する方法
この方法ではコストは安いですが、復旧までに大幅な時間がかかり
24h365dayのシステムでは適していません。
- 非同期バックアップ
データを別のシステムにネットワーク経由でバックアップをとっておきます。
災害が発生した際は、バックアップからデータをとってきて本番のシステムに適応を手動で行います。
復旧までの手順などおいて置かなければいけません。
- 非同期レプリケーション, 手動フェイルオーバー
本番と同じようなシステムを別に用意しデータを追従しておき、万が一が起こったときには別のシステムの方を稼働させる方式。
手動でフェイルオーバーをしないといけないので夜中であればフェイルオーバーまでの時間がかかったりすることがあります
- 同期レプリケーション, 自動フェイルオーバー
本番と同じようなシステムを別に用意しデータを同期しておき、万が一が起こった際には自動で別システムに切り替わる方式。
これであれば数秒から数分で復旧し、データも同期しているのであまり遅延はありません。
ですが、システムを構築する際のテストが多くなったり、その上に新しいシステムを作る際には気をつけないと万が一のときに自動で切り替わらない可能性があります。
- システム同期
こちらは万が一の際でもシステムをほぼ落とさずに稼働し続ける方法。
本番のシステム、また別で用意したシステムをどちらも本番システムとし、片方落ちても片方で受けることができます。
しかしその分、2システム稼働させるのでコストは大きいですが、復旧までの時間は早いです。
勉強後イメージ
要件定義でよく考えないといけないもの....
そして自動フェイルオーバーって実際結構動かない！ってのもあるんじゃないかなと思う