Technical discussion みたいなのをやるときがあるんですが、それにあたって考えたあうとらいんの内容をおいておく。
いくつかの内容は公開するには適していなさそうだったので省いてます。
災害対策に関するディスカッション
- どのレベルの障害に対して対処を考えるのか
- 同一 region、別 AZ
- 別 region
- どのようなサービスに対する DR を検討するのか
- for Internet-facing
- for intranet-facing
- 大きく 2 つのやり方
- ASR
- Azure Backup + Cross-region restore
- リージョン障害とデータセンタ障害とラック障害
- Service Health を設定する
- Azure Status ページを見る
- リージョン障害やデータセンタ障害からの復旧報が出れば、切り戻しの判断は可能
- データセンタ障害に対するシステムの反応の違い
- 可用性セットを使っているシステム
- 場合によっては全断になる可能性
- 可用性ゾーンを利用しているシステム
- あるゾーンにある Azure VM が使えなくなるものの、リージョンとして生きていればシステムとしては縮退稼働できるはず
- ネットワーク系のコンポーネントは障害に強い構成になっているため、インターネットへの出口などは AZ 障害の影響を受けない
- ExpressRoute Gateway などは AZ 対応にする必要あり
- 可用性セットを使っているシステム
- (参考) 海外の Azure リージョンで過去にあった障害
- どちらの方法でも考える必要があること
- RPO と RTO と RLO
- replication の類はほとんど非同期なので RPO を 0 にすることはかなり難しい
- 同期型の場合には定常的な latency を避けられない
- AZ の要否
- 東日本、西日本で使ってるなら AZ は片方でしか使えない
- AZ が必須であれば East Asia か Southeast Asia を使う
- 海外になるので、地政学リスクは考える必要はある
- ネットワーク周りでも考慮事項は多い
- ネットワーク周りの構成
- 同一 IP アドレス空間 or 異なる IP アドレス空間
- 前者の場合には常時つないでおくことができない
- 後者の場合には IP アドレスの変更にミドルウェアが耐えられるかの確認が必要
- https://learn.microsoft.com/azure/site-recovery/azure-to-azure-network-mapping
- https://learn.microsoft.com/azure/site-recovery/site-recovery-retain-ip-azure-vm-failover
- https://learn.microsoft.com/azure/site-recovery/azure-vm-disaster-recovery-with-expressroute
- Load Balancer や Application Gateway などのネットワーク系コンポーネント
- どこまであらかじめ作っておくか
- Active-Active or Active-Standby
- Traffic Manager や Azure Front Door を利用した構成
- VNet 内部で、region にまたがる Load Balancer はサービスとして提供されていない
- 同一 IP アドレス空間 or 異なる IP アドレス空間
- AD サーバの冗長化
- DNS 周り
- AD とも絡むが、SPOF が生まれないように
- リソースが確保できるか
- 確実に起動させることが必要な場合には オンデマンド容量予約 を利用する
- Azure 東日本、西日本リージョンの違い
- RPO と RTO と RLO
- ASR
- AZ の要否
- 可用性ゾーンから可用性セットへの ASR も可能
- RTO SLA は 2h
- 場合によっては Azure Backup からの cross-region restore も検討
- サーバの種類による
- trigger の引き方
- best practice はないが、自動で trigger を引くと false positive がめんどい
- 例えば Azure VM のメンテナンスに伴う誤動作とか
- 10-30 sec かかることがある
- 例えば Azure VM のメンテナンスに伴う誤動作とか
- 再保護に時間がかかる
- best practice はないが、自動で trigger を引くと false positive がめんどい
- 復旧計画
- Azure Automation や PowerShell script を利用できる
- 順序付けとグルーピングができる
- https://learn.microsoft.com/azure/site-recovery/recovery-plan-overview
- https://learn.microsoft.com/azure/site-recovery/site-recovery-create-recovery-plans
- Pricing
- その他詳細
- Windows Server 系で、同一 Computer name が存在してはならない場合のケアがなされている
- Azure Backup の場合は自分で落とす必要がある
- Windows Server 系で、同一 Computer name が存在してはならない場合のケアがなされている
- AZ の要否
- Azure Backup
- region 内、AZ 跨いだ restore という手はある
- GRS で Backup とってからの cross-region restore という手も考えられる
- ASR と比べて時間は早められるかも
- ただ、復旧計画は作れない
- 一日複数回取ることも可能
- サーバが stateless に作られているのであれば手ではある
- Database 周りとかは replication しておく必要がある
- ASR も結局再起動される、という観点では変わらないが、RPO が大きく異なる
- ASR より若干安い
- Azure Site Recovery は -ASRReplica と書かれた Managed Disk が secondary region に作られる
- Pricing
- Azure Backup の仕組み上、まずは snapshot がとられて、後に vault に送られる
- snapshot の時点では LRS or ZRS
- vault になった時点で LRS or GRS
- 一日の更新量の目安は 200GB
Discussion