こんにちは、クラウドインテグレーション2部 技術1課 宮形 です。
Amazon EC2 で、Microsoft Active Directory ドメインサービス (以下AD) を運用するお客様が、徐々に増えてきている印象です。 ADサーバーをEC2で構築することは、サーバーの可用性向上や災害対策などメリットが多くあると思います。
そんなADサーバーですが、バックアップ・リカバリはしっかりされていますでしょうか？AWS上のADサーバーのバックアップ・リカバリをする際、オンプレミスとは違う考慮点やトラブルシュートがありましたので、本BLOGでご紹介させていただきます。
ADサーバーのバックアップ・リカバリ運用の比較
おおざっぱに下記３つの運用方法があるかと思っています。それぞれ注意点があります。
方法1. ADサーバーのレプリケーション
常時複数台でADサーバーを稼働しておりレプリケーションで同期しているので、1台サーバーダウンしても生き残ったサーバーから再レプリケーションして復旧する運用です。 この運用の弱点としては、オペミスでオブジェクト消してしまった場合など、誤操作が全ADサーバーに伝搬されるため復旧できない点です。Active Directory の「ごみ箱」機能で誤った削除は対応できますが、誤った更新については対応できません。レプリケーションは可用性を目的とすべきであり、バックアップと捉えるには不十分と考えます。
方法2. ADサーバーの仮想マシンをオンラインバックアップ
ADサーバーがオンプレミスまたはクラウド上で仮想化されている場合、ハイパーバイザーやストレージのスナップショットでADサーバーのオンラインバックアップを取得できます。 注意点としては、ADサーバーがサポートする Microsoft Volume Shadow Copy Services (VSS) と連携する必要があることです。AWS の場合、EBSのスナップショットを定期的取得する Data Lifecycle Manager (DLM) がありますが、残念ながらVSS連携は出来ません。AWS で VSS をサポートするサービスとしては、AWS Backup や System Manager がありますので検討するとよいです。弊社提供の Cloud Automator 活用も検討できます。EC2停止 → AMI・スナップショット取得 → EC2起動 の一連操作を自動化してオフライン化することで、安全にADサーバーのバックアップを取得できます。
方法3. Windows Server バックアップ
ADサーバーに Windows Server 機能(Feature) の「Windows Server バックアップ」を有効化して、安全にオンラインバックアップを取得できます。EC2 でも利用可能です。 バックアップのジョブスケジュール・バックアップ世代管理など、ADサーバー個別事情に合わせたバックアップ運用が必要という煩わしさがデメリットですが、 唯一ディレクトリサービス復元モード(DSRM)でのリカバリをサポートするというメリットがあります。
考察
「方法1. だけ！」と割り切っているお客様も居るとは思いますが、バックアップ・リカバリ目的とした場合は不十分かと思います。方法 1.～3. のいずれかを複数を組み合わせて運用されているケースが多いのではないでしょうか。 本BLOGでは 「方法3. Windows Server バックアップ」を EC2 で実際にディレクトリサービス復元モード(DSRM)をやってみましたのでご紹介です。 表題の「EC2が起動しなくなった話」もご参考なれば幸いです。
バックアップの取得
EC2 のOSは Windows Server 2019 を選択しています。
Windows Server バックアップ の有効化
ADサーバーとして構築したEC2にて、Windows Server バックアップ の機能(Feature) を有効化します。PowerShellから下記コマンドを実行すればOKです。
Install-WindowsFeature Windows-Server-Backup
バックアップ取得
Windows Server スタートメニューより [Windows アクセサリ] - [Windows Server バックアップ] を起動します。
「Windows Server バックアップ」のウインドウでは、左ペインより「ローカルバックアップ」を選択します。右ペインの操作より、今回検証なので「単発バックアップ」を選択します。
「単発バックアップ ウィザード」が開始します。最初の画面「バックアップ オプション」はデフォルトで「次へ」を選択します。
「バックアップの構成の選択」は「カスタム」を選択します。
「バックアップする項目を選択」では「項目の追加」を選択します。
「項目の選択」の画面では「システム状態」のチェックをオンとして「OK」を選択します。ひとつ前の画面に戻り「次へ」を選択します。
「作成先の種類の指定」の画面では「ローカルドライブ」を選択します。バックアップを出力する先として、EC2 へEBSを事前アタッチしておきます。
「バックアップ先の選択」の画面では、バックアップ先に「ローカルディスク (D:)」等、バックアップ出力先のEBSのディスクを選択します。
「確認」の画面では、設定内容を確認して「バックアップ」を選択します。バックアップ取得が開始されます。「状態：完了しました」になりましたら「閉じる」を選択して終了します。
ディレクトリサービス復元モードからのADサーバーの復旧
間違えて AD 上のユーザーを削除してしまったため復旧を行うシナリオとします。
EC2 での ADサーバーでのディレクトリサービス復元モードへの入り方
ディレクトリサービス復元モードは Windows セーフモードの一種です。セーフモードと同様、OS再起動中に F8キー を連打してブートメニューから起動モードを選択します。 EC2 の場合、F8キーからのブートメニューが選択できないので、下記いずれかの方法を行います。
- msconfig より次回ブートオプションを選択してOS再起動
- bcdedit /set safeboot dsrepair コマンドを実行してOS再起動
- (OSがオフラインで操作できない場合) 復旧用の仮設EC2にブートディスクEBSをアタッチしてブートオプション修正
この方法はAWS公式ドキュメントに紹介されています。EC2のドライバーバージョンによっても異なります。本BLOGでは一番ハードルが高そうな 3. を実施してみます。
Windows インスタンスに関する一般的な問題 - Amazon Elastic Compute Cloud
同一リージョン、AZ上に 仮設EC2 (Windows Server) を一時的に作成します。
ADサーバーのEC2のルートボリュームのボリュームIDを確認します。EC2コンソールで対象インスタンスを選択し、「ストレージ」タブより確認できます。
EC2コンソール - [ボリューム] メニューより、先ほど確認したボリュームIDを選択して「ボリュームのデタッチ」を行います。
続けて「ボリュームのアタッチ」を行います。
「ボリュームのアタッチ」の画面になります。「インスタンス」より、仮設EC2 を選択します。デバイス名はデフォルトで「xvdf」とします。
仮設EC2上から、今ほどデタッチ→アタッチしたEBSを Windows Server よりオンラインにします。Windows [管理ツール] - [コンピュータの管理] を開始します。
「コンピュータの管理」より [ディスクの管理] 画面へ移動し、アタッチした EBS がオフラインとなっている場合、サブメニューより「オンライン」をクリックします。
Windows エクスプローラーより Dドライブとしてオンラインとなります。
管理者権限のコマンドプロンプトより下記実行します。
bcdedit /store D:\Boot\BCD /set {default} safeboot dsrepair
「コンピュータの管理」より、アタッチしたEBSを「オフライン」とします。仮設EC2 はシャットダウンして停止します。
逆の手順でデタッチ→アタッチを行い、ADサーバーのEC2へEBSをアタッチして元の状態に戻します。
「ボリュームのアタッチ」の画面になります。「インスタンス」より、ADサーバーのEC2を選択します。デバイス名は「/dev/sda1」へ書き換えます。
ADサーバーのEC2を「インスタンスを開始」します。
ここで検証ではトラブルとなってしまいました！いつまで待ってもEC2のOSが起動しません。[アクション] - [モニタリングとトラブルシューティング] - [インスタンスのスクリーンショットの取得] を選択してみますと、 下記のメッセージによりWindowsブートマネージャーで止まっておりました。
状態：0xc000000e 情報：要求されたデバイスが接続されていないか、デバイスにアクセスできません。
調べてみると、どうやら AWS公式ドキュメントの下記記述の対応を行うと回避できるとありました。
Windows インスタンスに関する一般的な問題 - Amazon Elastic Compute Cloud
■ DSRM でオフラインインスタンスを起動するには [Launch instances (インスタンスの起動)] を選択し、影響のあるインスタンスと同じアベイラビリティーゾーンに一時インスタンスを作成します。別のバージョンの Windows を使用するインスタンスタイプを選択します。たとえば、インスタンスが Windows Server 2008 である場合、Windows Server 2008 R2 インスタンスを選択します。
本BLOGの検証では、ADサーバー：Windows Server 2019、仮設EC2：Windows Server 2022 で実行していたのですがNGだったようです。仮設EC2：Windows Server 2016 に変えて再実施してみたところ、無事 ディレクトリサービス復元モードで OS が起動しました。
ADサーバーのリカバリ
本BLOGの検証では、Windows Server バックアップ より、「システム状態」を上書きリカバリします。
Windows Server スタートメニューより [Windows アクセサリ] - [Windows Server バックアップ] を起動します。
「Windows Server バックアップ」のウインドウでは、左ペインより「ローカルバックアップ」を選択します。右ペインの操作より「回復」を選択します。
「回復ウィザード」が開始します。「はじめに」の画面では、「このサーバー」を選択し「次へ」を選択します。
「バックアップの日付の選択」では、リカバリに利用したいバックアップ取得時点を選択します。
「回復の種類の選択」では、「システム状態」を選択します。
「システム状態の回復先の場所を選択」では、「元の場所」として「Active Directory ファイルの Authoritative Restore を実行する：オン」とします。この選択は実際の復旧シナリオに基づいて判断となります。
情報ポップアップが出ますので「OK」とします。
「確認」では、「回復処理の完了のためにサーバーを自動的に再起動する：オン」として「回復」を選択します。 「続行しますか？」は「はい」とします。
リカバリが開始されます。途中で自動的にOS再起動が行われますので、適宜リモートデスクトップ接続を再開します。「。。。に開始したシステム状態の回復操作は正常に完了しました」が表示されれば完了です。Enterキーで応答します。
ファイル名を指定して実行より「msconfig」を起動します。「システム構成」が開始します。「ブート」タブより「セーフブート：オフ」として「OK」を選択します。OSの再起動を行います。
削除したAD上のユーザーが復旧していることを確認しました。途中利用した仮設EC2は不要であれば「インスタンス終了」にて削除します。
まとめ
ディレクトリサービス復元モード(DSRM)でEC2が起動しなくなった件は、本番環境でのリカバリで発生したとするとトラブルシューティングで復旧が遅れる等、2次災害になってしまうかもしれません。 事前にリカバリ試験を行っておいて、しっかり手順を抑えておくと安心です。リカバリ検証環境を短時間容易に作成できるのも、AWS等クラウドのメリットと言えます。
本BLOGがお客様システムの安定稼働につながれば幸いです。
