【Azure for ITPro】Active Directory ドメインコントローラーを VM Role にインストールすることがお勧めできない理由
※2011年1月18日時点では VM Role はベータ版です。正式なリリース時には仕様が変更されることがありますのでご注意ください。
はやく訳さなければと思いつつ、2月近く経過してしまいました。すんません。
MSDN ブログに以下の記事が投稿されています。
VM Role ベータ版がリリースされたことを受け、インフラ担当SEにとって新たな興味が発生しました。それは、「はたしてクラウド上にActive Directory を展開することができるのか？」ということです。確かにクラウド上にドメインコントローラーを立ち上げることができれば、とても便利に思えます。
Windows Azure 上に展開したインスタンスから Active Directory を利用する方法として考えられるテクノロジーは3種類考えられます。
- Active Directory Federation Service 2.0 を使用してクレームベース認証を行う
※ADFS 2.0 の詳細については以下のサイトをご覧ください
ハイブリッド & プライベート クラウド TechCenter - Windows Azure Connect を使用して、Azure 上のインスタンスをオンプレミスのActive Directory ドメインに参加させる
※本件に関し、小澤さんが素晴らしい記事を書いてくださっています
VM Role を Active Directory ドメインに参加 « SE の雑記 - VMRole に Active Directory をインストールしてしまう
既存の Active Directory 資源を有効活用するという意味では前者2つが有力ですが、「もっとシンプルに考えたいのっ！」という方には3番目も魅力的です。
では、本当に3番目の方式（VM Role + DC）はやっても安全なのでしょうか？
結論から先に書いてしまうと、タイトルにも書かれているとおり NG（の線が濃厚） です。理由は、ハードウェアや OS が故障した際に、それまで Active Directory に加えられた変更が消えてしまうから...。
ここで「え？消えちゃうの？」と思った方もいらっしゃるかと思います。そうなんです、消えてしまいます。Windows Azure 関係のドキュメントを呼んでいると、次のような表現をよく目にします。
a server instance running in Windows Azure does not persist state
これは、VM Role インスタンスの外部に用意された Winodws Azure Storage などのストレージに保存されていない情報は「Reimage」や「インスタンスの移動」によって消えてしまいます。消える＝永続的でない ので「not persist state」と表現されています。これは仕様です。既に Windows Azure をテストしている方はイヤというほどご存知のことかと思いますが、これから勉強を始める方や「VM Role ならオンプレミスと同じでしょ？」と勘違いされている方は十分に気を付けてください。Hyper-V と同じ動作をすると期待していると、痛い目に合ってしまいます。
VM Role が展開されるまでのプロセスを "ごく簡単に" 示すと以下の通りです。
- VHD を作成して Winodws Azure Storage（blob）にアップロードする
- VM Role 用のサービス構成を作成する。このとき、使用する VHD（Azure Storageにアップロードされたもののうちいずれか1つ）を指定する
- サービスを展開すると、2.で指定したイメージ上にサービスが展開される
- ※より詳細なプロセスは以下をご参照ください
Introduction to the VM Role Development Process（すんません英語です）
About the VM Role Deployment Lifecycle（こちらも英語です）
この状態でしばらく VM Role インスタンスを使用し続けたとしましょう。当然、さまざまな変更が VM Role インスタンスの VHD に書き込まれます。VHD に Active Directory がインストールされている場合でも同様です。ドメインコントローラーに加えられた変更点は、VHD 内に蓄積されます。
Windows Azure 上のインスタンスには「Reboot」と「Reimage」という2つの操作が用意されています。
- Reboot（再起動）－ VM Role に書き込まれた変更は消えることなく、単にインスタンスの「再起動」だけが行われます。
- ReImage（再構築）－ 現在のVHDが削除され、再び Azure Storage に保存してある VHD から構成しなおされます。当然、VM Role に書き込まれた非永続的なデータは無くなります。
ここで、Azure のハードウェアに障害が発生したとしましょう。ハードウェアはもう使用できません。当然ながら、VM Role インスタンスにアクセスすることだってできません。
優秀な Windows Azure の Fabric Controller は、出来るだけ迅速にこれまでと同じ環境を再構築しようと試みます。どうするか...ReImage と同様の処理が行われるわけですね。当然ながら、これまで VM Role インスタンスに直接加えられた変更は消えてなくなります。
・
・
さて、Active Directory に慣れている方は、きっとこう思うはずです。
「消えてなくなるのは DC を1台しか展開していないからじゃんか！」
正しいですね。では、Active Directory 2台以上の構成で構築した場合を考えてみます。
複数台構成を考える場合、2種類の考え方があります。
- 同じ VM Role インスタンスを2つ構成する
- 異なる VM Role インスタンスを2つ構成する
前者は、構成ファイルに展開するインスタンス数を指定することで、全く同じ環境を2つ以上構成することができます。図にすると、以下のようなイメージです。
これならば、サーバーが1つ死んでももう1つのサーバーが生きているから安心！....ではないですよね...。同じサーバーを複数立ち上げても、Active Directory の利用者から見れば 1台のサーバーに見えてしまいます。その結果どういうことが起こるかといえば、Active Directory への変更点が、どのインスタンスに書き込まれるのかがわからなくなります。2台のインスタンスは、あくまでも1台のサーバーに見えるように動作していますから、Active Directory が誇る「複製」を行いようがありません。これでは、サーバーが死んだらどうしよう...なんてレベルではなく、そもそも運用にさえなりません。
では後者はどうでしょう？クラウド上に2台の異なる Active Directory サーバーを展開し、両者を複製メンバーとする..という構成です。オンプレミスと同じです。
DNS さえきちんと構成しておけば、片方のサーバーが死んでしまった場合には、残されたサーバーだけで運用ができます。さらに、死んでしまったサーバーが Fablic Controller で復元されれば、自動的に生きているサーバーから複製がはじまる...いや完全に自動的とは言わなくても、ちょっとコマンド等で調整すればOKかも...。（すいません..これ試していません...）
これはうまくいきそうか？....いえ、実はこれもダメなんです。
Active Directory の tombstone 有効期間に関する制限があることを思い出してください。Active Directory からオブジェクトを削除すると、それらはすぐに削除されずに IsDeleted フラグが付けられて一定期間抹消されずに隠しコンテナに残されたままになります。これは、Winodws Server 2008 R2 では 既定で 180 日です。そして、この 180 日が、バックアップされた Active Directory がリストアできる有効期間でもあるのです。つまり、180 日より以前にバックアップされた Active Directory サーバーは、たとえリストアされても「不正なサーバー」扱いされてしまい複製を開始することができません。
言い換えれば、3か月に1回 VHD を更新し、VM Role も更新すればハード障害が発生しても運用を継続することができそうです。でも、それってうれしいですか？クラウドのメリットが全く生かせてないですよね...。しかもクラウドに Active Directory をさらしてまでやりたいでしょうか...。
ちなみに、Tombstone 有効期間は必要に応じて変更することができます。例えば 365日に設定して、VHD の更新間隔を1年にすることができます。でも、これは「削除したはずのオブジェクトがディレクトリに残り続ける」ということです。セキュリティ上のリスクになるだけでなく、Active Directory のデータベースが巨大化して性能に影響がでる可能性もあります。
（参考）AD DS: The resultant backup lifetime in this forest should be equal to or greater than 180 days
・
・
ということを考えると、どうやら Windows Azure 上に Active Directory を展開するのは難しそうだ...ということがわかってきます。
じゃ、残された道が全くないか...といえば、例えばこんな方法が考えられます。
- Active Directory のデータベースを Windows Azure Storage 上に置き永続化する
Windows Azure のインスタンスには、Windows Azure Storage をローカルドライブのようにマウントする機能が用意されてるので、上記のように複数の VM Role インスタンスからデータベースを共有するという構成がとれるかもしれません。ただ、この方法は"私は"全く試していませんし、VM role 上の OS 内部にもさまざまな情報を持っていますから、そう簡単にできるとは思えません。それに、NETLOGON 共有に含まれているグループポリシーやスクリプト類なども Windows Azure Storage 上に配置するといった工夫も必要です（これはそう面倒とは思えませんが）。
ITPro にとっては、腕が鳴るチャレンジではありますね！どなたか、私の代わりにチャレンジしてみませんか？