Disaster Recovery

Azure Site Recoveryの情報はみなさんもうチェックされましたでしょうか?かなり前からSystem Centerに注目してやってきておりますがここにきてやっと「System Centerを使ってAzureを連携させることでハイブリッドクラウドの良さが活かせる」機能が発表されましたね。前からずっと「なんでできないんだろう、できたらいいのにな」と思ってましたので「やっと」という表現にさせてもらいます。それだけ待望でしたよ、ということで。 Twitterではリンク紹介してましたが、改めて。 - [Implementing Enterprise-Scale Disaster Recovery with Hyper-V Recovery Manager, Network Virtualization, and Microsoft System Center 2012 R2 | TechEd North America 2014 | Channel 9](http://blogs.technet.com/b/askpfeplat/archive/2014/05/13/how-to-clean-up-the-winsxs-directory-and-free-up-disk-space-on-windows-server-2008-r2-with-new-update.aspx) こちらにPowerPointのスライドも公開されています。 - http://video.ch9.ms/sessions/teched/na/2014/DCIM-B322.pptx ざっと内容を抜粋すると以下のような感じです。私の勝手な解釈も含まれてますので正確じゃないと思います。注意してください。 - 今までのHyper-V Recovery ManagerはSCVMMで管理されたオンプレミスからオンプレミスへの複製(Hyper-V Replica利用)とAzureからの自動化だった。 - 複製対象としてAzureが利用できる。同時に名称が変更になり、Azure Site Recoveryとなる。 - 複製間隔は最短30秒。 - ほんの数クリックで実環境に影響を与えずに構成でき、災害から回復可能となる。 - フェールオーバーでき、フェールバックできる。 - 仮想マシンは当初、VHD(X)のみ複製および同期され、仮想マシンは作成されない状態となる。これにより、コストを抑えられる。 - テストフェールオーバー、あるいはフェールオーバーした段階で仮想マシンが作成され、複製されているストレージのコピーと紐付けられ、起動される。 - テストフェールオーバー時には独立したネットワークに仮想マシンを配置し、同一ネットワーク上にテストクライアントを配置することで完全に独立した環境でフェールオーバー後のテストを実施できる。 - ネットワークはオンプレミスの仮想ネットワークとAzure上の仮想ネットワークを「Map」することで連携可能となる。 - フェールオーバー時には同時にフェールオーバーすべきグループや、グループ毎の依存関係(順番)を指定できる上、追加のステップ(例えば手動でメールを送信するようなタスク)も構成できる。 - リカバリアクションは以下の4つ テストフェールオーバー 本番環境には無影響で仮想マシンをAzure上にリカバリする。 - 仮想マシンは独立した環境に立ちあげられる。 - 予定されたフェールオーバー(Planned Failover) 本番環境で仮想マシンを停止し、差分を送った上でAzure上に仮想マシンを立ち上げる(データロス無し) - 本番環境の操作無しの予定されていないフェールオーバー(Unplanned Failover without primary site operatoins) 本番環境に到達できない場合に仮想マシンをAzure上で立ち上げる。 - データロスがおそらく発生する。 - 本番環境の操作有りの予定されていないフェールオーバー(Unplanned failover with primary site operations) 本番環境の仮想マシンのシャットダウンと差分送信を試みる。 - その上でAzure上で仮想マシンを立ち上げる。 - フェールバックも非常に簡単な操作。 ダウンタイムを少なくすることを優先するか、リソース消費を抑えることを優先するか選択可能。 - フェールオーバー時にはそのレポートをExcel形式でダウンロード可能。 - 複製およびフェールオーバー先は地理的に近い場所を選択可能。 ...

Exchange Team BlogにてExchangeのDAGのWitnessのみをWindows Azure上に配置するという話題が有りました。結論は「まだサポートされない」ということで残念ですが、将来的にサポートされるようになりそうな感じですね。 - [Database Availability Groups and Windows Azure - Exchange Team Blog - Site Home - TechNet Blogs](http://blogs.technet.com/b/exchange/archive/2013/08/07/database-availability-groups-and-windows-azure.aspx) DAGにかぎらずですが、きちんとスプリットブレイン状態を防ぎ、稼働しているマシンで稼働させ続けるためにはどうしても3拠点が必要になります。本文中では以下のように書かれています。 You need two well-connected datacenters, in which Exchange is deployed You need a third location that is connected via the network to the other two datacenters The third location needs to be isolated from network failures that affect the other two datacenters 過半数が稼働し通信できていないといけないので、例えば2拠点でDAGを組もうと思っても、結局Witnessをどちらに置くか、という話になり、Witnessが配置された方の拠点がだめになればDAGとしては停止してしまうわけです。で3拠点目があればその問題は解決するのですが、ネットワーク的に完全に分離されていて、安定しているような拠点でできれば地理的にも離れている…というような都合の良い拠点をすぐに用意するのは難しいわけです。そこでAzure上に配置可能ならかなりメリットが出てくる…という話なのですが、まだ無理なようですね。 今後に期待したい所です。