AD冗長化構成の構築方法|ADは2台以上でのレプリケーションが必須

タイトルの「2台以上でのレプリケーションが必須」は、AD DSプロトコルが単一ドメインコントローラーを拒否するという意味ではありません。1台だけでもドメインは技術的に動作します。しかし、その1台の停止がDNS、認証、グループポリシー、ディレクトリ参照の停止に直結するため、本番設計では2台以上を可用性上の運用要件として扱います。台数だけでなく、別ホスト・別電源・別障害領域へ置き、DNS、グローバルカタログ、サイト、バックアップ、復旧担当まで設計して初めて冗長化になります。

追加DCはバックアップの代わりではありません。誤削除、暗号化被害、スキーマ破損などは正常に複製されるため、複数DCと復元可能なSystem Stateバックアップの両方が必要です。

目次

2台構成を始める前の合格条件

既存DCに複製エラーがある状態で2台目を昇格すると、障害も複製トポロジも複雑になります。最初に既存DCの時刻、名前解決、SYSVOLとNETLOGON共有、Directory Service・DNS Server・DFS Replication・Systemログ、ディスク空き容量を確認します。新サーバーには固定アドレスを割り当て、昇格中の優先DNSは同じドメインとサイトの正常な既存DNS/DCへ向けます。複製が双方向に完了するまで新DC自身だけを参照DNSにしません。

Get-ADDomainController -Filter * |
  Select-Object HostName,Site,IPv4Address,IsGlobalCatalog,OperationMasterRoles
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
repadmin /replsummary
repadmin /showrepl * /errorsonly
dcdiag /e /test:DNS /v

期待値は、予定した全DCが列挙され、所属サイトとIPが正しく、repadminに失敗がなく、dcdiagのDNS、Advertising、Services、SysVolCheckなどに未解決エラーがないことです。失敗時は追加作業を止め、DNSのSRVレコード、RPC到達性、時刻差、認証、既存複製を直します。コマンドが完走しただけ、または警告を無条件に無視した状態は開始条件を満たしません。

DNS・GC・サイトを台数とは別に設計する

  • 各クライアントとメンバーサーバーには、同じAD DNS名前空間を保持する到達可能なDNSを複数登録する。外部DNSをNICへ直接混在させず、外部名前解決はAD DNS側のフォワーダーで扱う。
  • 通常の書き込み可能DCではDNS ServerとGlobal Catalogを有効にする案を基準とし、無効化する場合はアプリ、ユニバーサルグループ、WAN断時の要件を文書化する。
  • Active Directoryサイトとサービスでサブネットを作成し、新DCが意図したサイトへ入ることを確認する。誤ったDefault-First-Site-Name所属のまま運用しない。
  • 2台を同じHyper-Vホスト、同じストレージ、同じ電源に置けば、OS障害には耐えても基盤障害には耐えない。主要な共通障害を少なくとも一つ減らす。
  • 拠点ごとにDCを置くかは、WAN停止時のサインイン・DNS・業務継続、物理セキュリティ、管理負荷を比較して決める。

追加ドメインコントローラーを昇格する

Server ManagerでAD DSと管理ツールを追加し、通知から「このサーバーをドメインコントローラーに昇格する」を開きます。「既存のドメインにドメインコントローラーを追加する」を選び、ドメイン、サイト、DNS Server、Global Catalog、複製元、NTDS・ログ・SYSVOLの保存先、DSRMパスワードを確認します。資格情報はDomain Admins相当を必要な時間だけ使い、DSRMパスワードは秘密情報管理庫へ保管します。

PowerShellでも前提条件テストを先に実行します。次のドメイン名とサイト名は例であり、実在する値へ置き換えます。テストのErrorがゼロで、Warningの意味と対処を変更記録へ残した場合だけインストールへ進みます。

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Test-ADDSDomainControllerInstallation `
  -DomainName 'corp.example.com' `
  -InstallDns `
  -SiteName 'Tokyo'

Install-ADDSDomainController `
  -DomainName 'corp.example.com' `
  -InstallDns `
  -SiteName 'Tokyo'

昇格後の再起動と初期複製が終わるまでは、古いDCの停止やFSMO移動を同時に行いません。DNS Managerで前方参照ゾーンと_ldap、_kerberos、_gc等のSRV登録を見て、Active Directoryサイトとサービスで自動接続オブジェクトとサイト所属を確認します。その後に新DCのDNSクライアント設定を組織の設計へ合わせ、自身と別DCの両方を使える状態にします。

複製・FSMO・バックアップを確認する

FSMOは5役すべてが常時二重化される仕組みではありません。役割所有者を記録し、計画停止の前には正常なDCへ転送します。障害時のseizeは、元の所有者を二度とドメインへ戻さないと判断した非常時だけに限定します。単に2台目を追加しただけでFSMOの復旧計画が完成したとは判定しません。

repadmin /replsummary
repadmin /showrepl * /errorsonly
dcdiag /e /c
Get-ADReplicationFailure -Target * -Scope Forest
Get-ADDomainController -Filter * |
  Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles

System StateにはDCのAD DSデータ、レジストリ、ブートファイル、SYSVOLなどが含まれます。Microsoftのフォレスト回復ガイドは、各ドメインで少なくとも2台の書き込み可能DCを定期的にバックアップすることを推奨しています。バックアップ製品がAD対応であること、保存先がDCと同じ障害で失われないこと、世代保持、暗号化、DSRM情報、復元担当を確認し、隔離環境で復元試験を行います。成功条件はジョブの緑表示ではなく、選んだ世代からディレクトリとSYSVOLを所定の手順で復旧できることです。

片系停止試験で可用性を実証する

  1. 複製とdcdiagが正常な時点を記録し、System Stateを含む直近バックアップと戻し方を確認する。
  2. テストOUに利用者、グループ、GPOまたはDNSレコードを作り、両DCで同じ変更と複製メタデータが見えることを確認する。
  3. 業務時間外に一方のDCを正常停止し、クライアントが残存DNS/DCを検出できることを確認する。キャッシュ済みサインインだけで合格にしない。
  4. 未キャッシュの試験アカウントによる認証、DNS、GPO更新、パスワード変更、LDAP依存アプリ、管理ツールを試す。
  5. 停止したDCを戻し、repadmin、dcdiag、イベントログで再収束を確認してから反対側も同じ条件で試す。

期待結果は、停止中も業務が残存DCを使用し、復帰後のrepadminで失敗数が0、最大遅延が設計値内に戻ることです。DNSタイムアウト、認証失敗、GPO取得失敗、片方向複製、停止DCを参照し続けるアプリが一つでもあれば本番可用性は未達です。接続先固定、ファイアウォール、DNSキャッシュ、サイト境界を修正し、同じ試験を繰り返します。

ロールバックと降格のゲート

新DCで問題が出ても、すぐにコンピューターオブジェクトやNTDS Settingsを削除しません。まず新DCをクライアントDNSの候補から外し、変更範囲を止め、既存DCの健全性を再確認します。正常な複製が可能なら、DNS/GCの代替、FSMO非保持、アプリ参照解除、直近バックアップ、他DCへの送受信複製完了を確認して、AD DS Configuration WizardまたはUninstall-ADDSDomainControllerで正常降格します。

Test-ADDSDomainControllerUninstallation
repadmin /replsummary
repadmin /showrepl * /errorsonly

降格前テストが他DCへ接続できない、未複製変更がある、最後のDNS/GCである、FSMOを保持している場合は中止します。強制降格は通常の切り戻しではなく最終手段です。実施した場合は生存DCでメタデータ、DNSのA/CNAME/SRV、サイト、DFSR参照を清掃し、FSMOを必要に応じてseizeします。最終確認は、両DCの通常稼働、片系停止、復帰後再複製、バックアップ復元の4状態で期待結果を満たすことです。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメント一覧 (9件)

  • 分かりやすい記事を書いていただきありがとうございます。
    一つお聞きしたいですが、
    「・DNSサーバーにしたい場合は、「ドメインネームシステム(DNS)サーバー」にチェックを入れてください。後からでも変更可能です。」という記述がありますが、
    後から変更したい場合、どういう流れで変更したほうがよろしいでしょうか。
    どうぞよろしくお願いいたします。

    • 以下のような流れになります。

      「ドメインネームシステム(DNS)サーバー」にチェックを入れた
      ⇒DNSサーバー機能の削除

      「ドメインネームシステム(DNS)サーバー」にチェックを入れない
      ⇒DNSサーバー機能の追加

  • こんにちは。実際に記事を見て2台で構成してみました。ちゃんとできているか確認したく、1台停止した場合と想定して2台目を稼働させるテストをしてみたいのですがどのように行ったらよいでしょうか?よろしくお願いいたします。

コメントする

目次