ASRと呼ばれるAzureでのDRソリューションがあるがその前にそもそも
DRについて色々前提が必要
システムだけ切り替えてもビジネスと紐づかない切替になったり
人がDRできないので切替後まわらないので意味ないってケースを多数みてきた
なのでデータだけ遠隔地に保管というのが大半の案件な気がする
わかりやすい例がECサイト
サイトを切り替えても在庫保管してある場所、梱包する人、配送する人、配送するトラックや道が壊れていたらビジネスとして成立していないので
DR対策しても意味ないでしょ的なのが・・・
あるとすればWEBの表示のみで知らせるといった感じかな・・・
・データだけで良いのか？システム全体まで必要なのか？
Azureの場合データだけならGRSやAzureBackupを利用したペアリージョンコピー
システム全体ならRPO/RTOに応じてセカンダリリージョンでウォームスペア、ホットスペアを利用するというのが基本方針
- 災害発生時の再デプロイ:この方法では、アプリケーションは災害時に一から再デプロイされます。 これは、復旧時間が保証されている必要のない、重要性の低いアプリケーションに適しています。
- ウォーム スペア (アクティブ/パッシブ) : 2 番目のホストされるサービスは別のリージョンに作成され、ロールは最小容量を保証するようにデプロイされます。ただし、このロールは運用環境のトラフィックを受信しません。 この方法は、リージョン間にトラフィックを分散するように設計されていないアプリケーションに有用です。
- ホット スペア (アクティブ/アクティブ) :アプリケーションは複数のリージョンで運用負荷を受信するように設計されています。 各リージョンのクラウド サービスは、ディザスター リカバリーのために必要な容量よりも大きい容量で構成されている場合があります。 また、クラウド サービスは災害およびフェールオーバー時に必要に応じてスケールアウトする可能性があります。 この方法は、アプリケーション設計にかなりの投資を必要としますが、大きな利点があります。 たとえば、復旧時間が短いことが保証されていること、すべての復旧場所で連続してテストを実行できること、容量を有効に使用できることなどです。
※MS公式サイトより
・ホットスペアのアーキテクチャ
・ウォームスペアのアーキテクチャ例
・DRの対象について
そもそもどのサービスに対するDRをするのか？
OS、ストレージ、DBが主だがそもそもどれ？
・チェックリスト
・物理レイヤに対するDR
→ ホスト障害 : サービスヒーリング
→ ラック障害 : 可用性セット
→ データセンタ障害 : ゾーン冗長
→ ゾーン障害 : ゾーン冗長
→ リージョン障害 : Azure Site Recovery (ASR)
・DR先について
GRSは積極的な活用すべきだがペアリージョンにしかされない
日本の場合は東京、大阪のみなので距離が近すぎる・・・
香港とシンガポールとか強制的に国をまたぐような場合もあり・・・
データベースの同期が基本読み取りのみなので実際の障害時を想定した切り替えは作りこむ必要がありそう
ASRを設定するにあたって最低限必要なもの
→ プライマリ リージョン : ストレージアカウント
→ セカンダリ リージョン : Recovery Service コンテナ、VNET、Automation アカウント大まかな仕組み
→ Site Recoveryを有効にしたVMに、モビリティ サービス拡張機能が自動的にインストールされる
→ モビリティ サービスがDiskへの書き込みをプライマリ リージョンにあるBlobストレージへ継続的にキャッシュする
→ Blobストレージのデータは、セカンダリ リージョンのReplica Diskへ継続的に転送される（HTTPS送信）
→ セカンダリ リージョン側で処理された後、クラッシュ整合性復旧ポイントが5分間隔に生成される
→ Replica DiskからDisk/VMを作成する
ディスクだけレプリケーションしておきフェイルオーバ時にそのディスクでVMを作成してくれるイメージ、GRSと違って任意のリージョン選択が可能
・復旧対象
・テストフェイルオーバ
設定後に気軽に試せる
・フェイルオーバの実行
・フェイルバック
・整合性
→ クラッシュ整合性 : ディスクのスナップショットベースでメモリは対象外（5分間隔固定）
→ アプリケーション整合性 : ディスク＋メモリ＋トランザクションのスナップショット (1~12時間の間で1時間単位で間隔を指定）
・復旧ポイント
・複数VM同時レプリケーション
レプリケーショングループ ソースの性能に影響があるらしい・・・
まとめてのフェイルオーバは復旧計画を作成しておく
・暗号化
ASRは、CMKによるSSEと、ADE(Windows/Linux)のどちらディスク暗号化もサポート
また、レプリケートをVPN経由でも可能らしい
・ASRのサポート
・制限に注意
出来ないことに注意
→ OSディスクは最大4TB、データディスクは最大32TB/64本まで
→ 一時ディスク、ZRS、共有ディスク、Ultra Disks、書き込みアクセラレータは非サポート
→ 記憶域スペースダイレクトは非サポート（記憶域スペースはサポート）
→ インターネット Load Balancerは非サポート（内部ロード バランサーは復旧計画のAzure Automation スクリプトで紐づけ可能）
→ Azure CLIでのデプロイはサポートしていないという・・・
・CRRとの違い
CRRは単一サーバの復旧を目指すイメージでASRはシステム全体
→ RPOが違う（代表的なRPOは、ASRは5分、CRRは1日）
→ 復旧先リージョンの選択肢が違う（ASRは任意のリージョン、CRRはペアリージョン固定）
→ 復旧のプロセスが違う（ASRは事前に復旧先VNET等を指定、CRRはリストア時に指定）
→ 1つの操作で復旧できるVM数が違う（ASRは複数VMをまとめて可能、CRRは1台ずる）
→ 可用性セットやオンデマンド容量予約へのサポートが違う（ASRは色々サポートしているが、CRRはリストア時に制約が多い）
・DR発動について
自動ではフェイルオーバしないため誰かが実行する必要がある（作りこみは可能らしい）
最初に書いたがDR発動する場合で全員死んでるかもしれないんで・・・
切り替えても意味ないじゃん的・・・もあるえる・・・
やはり回せる人、管理する人ごとＤＲしてないと・・
さらに、東日本がつぶれたら西日本に全部切り替えますってなったら
AZの数からしてリソースないんじゃないか・・・
結論これ！？
コメント