400ユーザー向けのActive Directoryサーバー仕様は、人数だけで決めず、ピーク時の認証・LDAP照会、データベースの大きさ、1台停止時の負荷で検証します。Windows Server 2022のDCを複数の障害領域へ配置し、サーバーライセンスとCAL、バックアップ・復旧費用も合わせて見積もってください。
この記事はオンプレミスのActive Directory Domain Services（AD DS）と、そのドメインコントローラー（DC）の計画を扱います。Microsoft Entra IDやクラウドのOneDrive保存容量は別のサービスです。400人という規模から、NTDS.dit用に一律500GB・メモリ32GB・10Gbpsが必須とは判断できません。
400人の仕様を決める前に確認する条件
| 確認項目 | 仕様・費用への影響 |
|---|---|
| 通常時と朝のピークの同時認証・LDAP照会 | CPU、応答時間、障害時の残りDCの処理能力 |
| ユーザー以外のコンピューター・グループ・属性、複数ドメイン、GC | データベース容量とメモリキャッシュ |
| 認証する業務アプリ、監視・バックアップ・セキュリティ製品 | 認証頻度、メモリ、I/Oと管理費用 |
| 拠点・WAN遅延・切断時に必要な業務 | サイト・サブネット・DC配置と回線費 |
| 許容停止時間と戻せるデータの古さ（RTO/RPO） | 冗長構成、バックアップ頻度、復旧訓練 |
| 既存仮想化ホストとWindows Server/CAL契約 | 新規に購入する数量と移動・障害時の利用権 |
既存環境を移行する場合は、通常営業日と忙しい時間帯の計測を先に行います。新設の場合は、実際に使うGPO・アプリ・監視エージェントを含む検証環境で比較します。人数をCPUコア数へ単純換算した値だけで、購入を確定しないでください。
DCは少なくとも2台を前提に、1台停止でも容量を確保する
Microsoftは本番ドメインに少なくとも2台のDCを置くことを案内しています。2台を同じ仮想化ホストだけに置くと、そのホスト停止で両方を失います。別ホストへ分け、共有ストレージ・ネットワーク・電源などの共通障害も確認します。
DCが2台あることと、障害時の性能を満たすことは別です。通常負荷を2台で分けているなら、1台の停止・更新中に残りのDCへ負荷が集中しても、必要な認証と名前解決ができるか検証します。両方合わせて必要容量ぎりぎりなら、第三のDCや容量の増強も検討します。FSMOの役割を機械的に分散するだけで認証の可用性が成立するわけではありません。
CPU・メモリ・ディスクの検証用構成例
以下は、400人・単一ドメイン・主な役割がAD DS/DNS・大きなLDAPアプリ負荷がない場合に、見積もりと検証を始めるための設計例です。Microsoftの「400人向け保証仕様」や実測結果ではありません。既存のデータサイズ・エージェント要件と合わなければ調整してください。
| 項目 | 各DCの初期検証案 | 確定前の確認 |
|---|---|---|
| 台数 | 2台。別の仮想化ホスト等へ配置 | 1台停止時の処理・DNS・サイト設計 |
| CPU | 4 vCPUを検証の出発点にする | ピーク時CPU、ホスト側の競合・待ち、再認証の集中 |
| メモリ | 8GBを出発点とし、必要に応じ16GB以上へ調整 | OS＋NTDS.ditのキャッシュ＋エージェント＋増加分が収まるか |
| ディスク | 例として各DCの合計120GBから実容量で見直す | OS更新・SYSVOL・DB・ログ・ページファイル・空き領域 |
| 基盤 | 対応するSSD等と冗長化された保存基盤 | 容量だけでなく読み書き遅延・バックアップ時の負荷 |
| ネットワーク | DC自身は1Gbps接続を検証候補とする | 実トラフィックと拠点回線、ホスト全体の帯域 |
| バックアップ | DCとは別の保存先と復元手段 | 世代・権限・保管先の障害、復旧時間 |
vCPUと物理CPUコア、VMへ割り当てるメモリとホスト全体のメモリは別です。4 vCPU×2台だけを理由に、物理ホストのコアライセンスが8コア分で足りるとは判断できません。高性能なVMでも、ホストのCPUやメモリをほかのVMと奪い合えば応答が悪化します。
メモリとストレージはNTDS.ditの実容量から確認する
ADはデータベースをメモリにキャッシュします。メモリは人数から32GBと固定せず、NTDS.dit・OS・監視/セキュリティ/バックアップ製品・将来増加分を見ます。GCとして他ドメインの情報も保持するか、属性を多く持つ業務製品があるかでも変わります。
ディスク容量にはNTDS.ditだけでなく、SYSVOL、OS、更新用空き容量、ログ、ページファイル等を含めます。ファイルサーバーの利用者データやOneDriveの保存量を、ADデータベース容量へ足しません。監査ログの保持期間と転送先は別に計画します。
OS・ログ・データベースのボリューム分離は公式の検討項目ですが、物理ディスクの分離があらゆるSSD・共有ストレージ・VMで必須という説明は適切ではありません。同じ保存基盤上でドライブ文字だけを分けても、独立したI/Oや障害分離が得られるとは限りません。RAIDはディスク故障の対策で、誤削除や侵害から戻すバックアップの代わりにはなりません。
性能の合否は、ピーク時と保守時の計測で判断する
- パフォーマンスモニターでCPU、空きメモリ、ページング、ディスク遅延、ネットワーク送受信を収集する。カウンター名はOS言語で異なる。
- 朝のログオン、業務アプリのLDAP処理、GPO処理、監視・バックアップの稼働が重なる時間を含める。
- 通常時だけでなく、計画した保守で1台が停止している時間の認証・名前解決とアプリ応答を確認する。
- 瞬間最大値と、30分〜1時間などのピーク時間帯の継続的な利用率を分ける。
- 応答時間、レプリケーション、DNS、利用者への影響と合わせて容量を確定する。
公式のハードウェア確認例には、CPU使用率60%未満、NTDSの平均DB読み取り遅延15ms未満・ログ書き込み遅延10ms未満等があります。これは余裕を調べる目安で、短時間の超過だけで故障と判定する数値ではありません。自組織のサービス目標を定めて、継続的な超過と利用者影響を調べてください。
Active Directoryの費用はサーバーとCALを分ける
AD DSの役割を使う費用は、ハードウェアだけではありません。Windows Server 2022のStandard/Datacenterは、基本的にコアライセンスとアクセス用CALを検討します。AD用VMの数だけでエディションや契約を確定せず、同じホストの他のWindows Server VMと障害時の配置も数えます。
| 費用項目 | 見積もりに含めるもの |
|---|---|
| 基盤 | サーバー、ストレージ、ネットワーク、UPS、保守、仮想化製品 |
| Windows Server | 物理コア数、エディション、稼働VM数、障害時のホストと契約条件 |
| アクセス用CAL | User/Deviceの選択、人数・端末数、既存契約の対象版・利用権 |
| 保護と復旧 | バックアップ製品・保存先・世代管理、監視、復元訓練 |
| 作業と継続運用 | 構築、移行、アプリ/GPOの確認、更新、障害対応、将来のOS移行 |
物理コアでライセンスする場合は、全物理コアを対象に、プロセッサー当たり最低8コア・サーバー当たり最低16コアの条件があります。Standardは必要な全コアをライセンスした場合の2 OSE/VMの利用権を基準に、追加VMの分も考えます。Datacenterは全コアをライセンスした対象サーバーで、Windows Server VMを無制限に実行できる利用権があります。仮想コア単位のライセンスは有効なSoftware Assuranceまたはサブスクリプション等の条件があるため、通常の物理コア方式と混ぜて計算しません。
User CALはアクセスする利用者ごと、Device CALはアクセスする端末ごとの考え方です。全400人が利用し、既存の適切な利用権がないUser CAL案なら400人分を見積もり対象にします。共有端末中心ならDevice CAL案も比較します。既存契約を確認せずすべて新規購入と計算せず、対象版・契約の条件を販売店と照合してください。RDSのデスクトップ利用がある場合は、Windows Server CALとは別にRDS CAL等も検討します。
価格は購入チャネル、契約、保守・割引・税で変わるため、ここで固定総額は示しません。2つの案を比較するなら同じ構成・利用権・保守年数をそろえ、初期費用と年ごとの運用費用を分けた見積もりを取得します。
DCへファイル・印刷等を兼用する前に役割を分ける
DCは組織の認証を支える特権的なサーバーです。費用を抑えるためにファイル、印刷、業務アプリを同居させ、メモリだけ増やす設計を第一候補にしません。別のメンバーサーバーやVMへ分離して、管理権限・バックアップ・更新・障害範囲を整理します。DNSはAD構成と合わせて計画し、DHCP等の同居も必要性と管理条件を個別に判断します。
公式の保護案内ではServer Coreと管理用端末からの遠隔管理が推奨されています。運用者が対応できる管理方法を確認し、DC上で日常的なWeb閲覧を行わない構成にします。ネットワーク冗長化はスイッチ・ホスト側も含めて設計し、400人という理由だけでDCへ複数NICやLBFOチーミングを追加しません。
仮想化とバックアップ：スナップショットだけで復旧を組まない
仮想DCには対応するハイパーバイザーとVM-Generation IDによる安全機構がありますが、スナップショットの安全な復元はシステム状態バックアップの代わりではありません。復元したDCで未複製だった変更が失われる場合があり、全DCを同時に過去へ戻す運用も避けます。
Windows Server Backupでは、管理権限で「ローカルバックアップ」→「単発バックアップ」→構成の「カスタム」→「項目の追加」で「システム状態」を指定し、保存先を選んで取得できます。継続運用は組織のRPO/RTOに合わせて頻度・世代を設定し、完了結果と復元試験まで確認します。週次・月次なら誰にでも十分とはいえません。バックアップへのアクセス権と別障害領域への保管も設計します。
Windows Server 2022の新設時はサポート期間も確認する
2026年10月の計画では、Windows Server 2022のメインストリームサポートは2026年10月、延長サポートは2031年10月に終了する公式予定を確認します。メインストリーム終了を、直ちにセキュリティ更新が全終了する日と混同しません。正確な日時は公式表のタイムゾーンも確認してください。
2022に依存する要件がある場合は、その理由と更新計画を残します。新設では組織が対応できる新しいWindows Serverの版も比較し、業務アプリ・バックアップ製品・仮想化基盤・CALの対応を含めて選びます。この記事の例を、そのまま最新OSの互換性保証として使わないでください。
既存DCの役割を読み取りで確認する例
AD管理ツールと適切な読取り権限がある環境では、以下で対象ドメインのDC一覧を確認できます。構築・昇格・役割移動を行うコマンドではありません。対象ドメインを指定する場合は-Serverへ実際のドメインまたは適切なDCを指定します。
Get-ADDomainController -Filter * |
Select-Object HostName, Site, IPv4Address, IsGlobalCatalog,
OperatingSystem, OperationMasterRoles | Format-Table -AutoSize
この一覧は配置・OS・GC・FSMOの確認用で、容量が足りる証明ではありません。CPU・メモリ・ディスクの計測結果、実際のVMのホスト配置、バックアップ、利用者の認証テストを別にそろえます。新規フォレストの作成やDCの昇格は、ドメイン名・DNS・サイト・移行・復旧の設計が確定した後の別工程です。
見積もりを確定する前の確認
- 各DCで通常ピークと1台停止時の負荷・応答を検証したか。
- 両DCが同じホスト・電源・保存先の故障だけで同時に失われないか。
- Windows Serverのコア/VM条件と利用者・端末のCAL利用権を照合したか。
- 監視・バックアップ・更新・復元訓練まで費用と担当を含めたか。
- OSや業務製品のサポート期間と将来の移行時期を確認したか。
400人規模では、単に大きいCPUや大量のディスクを購入するよりも、実負荷に合ったDCの配置、障害時の余裕、復旧できる運用を一緒に確定することが、適切な費用と安定性の判断につながります。
コメント