Windows Server 2016 Active Directory サイトとレプリケーションの概要①

皆さんこんにちは、Miyaです。

Active Directoryはマルチマスターレプリケーションモデルを使用して、全てのDCに情報をレプリケートします。

つまり、1つのDCで変更が発生した場合、ドメインまたはフォレスト全体に情報がレプリケートされる仕組みなっています。

大規模な組織であれば、地理、ネットワークの観点から、複数拠点にDCを配置する必要があるでしょう。
そこで、管理者はレプリケートの計画を立てる必要ためにも、サイトという概念を理解しなければなりません。

本記事では、Active Direcotryのレプリケートの仕組みから、サイトの構成までを解説します。

スポンサーリンク:

Active Direcotry レプリケートの仕組み

Active Directoryでは、ローカルにデータベースを保持しています。
データベースはパーティションで区切られており、Active Directoryは4つのパーティションから構成されています。

サイトの構成

Title:Windows Server 2016 Active Directory データーベースの概要
https://miya1beginner.com/windows-server-2016-active-director-yデーターベースの概要

Active Directoryでは、これらのパーティションに格納されている情報を、他のDCにレプリケーションします。
但し、パーティション毎にレプリケーションされるスコープが異なります。

サイトの構成

例えば、ドメインパーティションでは、ドメイン固有のユーザー、グループ、コンピューター、OUなどの情報が格納されいることから、レプリケートのスコープはドメイン内のDCとなります。

Active Directoryのレプリケーションは、サイト内・サイト間で動作が異なります。
サイト間のレプリケーションの場合、組織全体のネットワーク環境や、ブランチオフィスの規模などを考慮してレプリケーションされる間隔や、レプリケーションパスを設計する必要があります。

サイト内レプリケーション

まず、Active Directoryのサイトという言葉を説明しておきます。

サイトとは、Active Directoryにおけるネットワーク範囲の定義です。

既定では、「Default-First-Site-Name」というサイトが自動的に作成され、何も触らなければ、全てのDCは同一サイト内(=同一ネットワーク)として解釈されます。

Default-First-Site-Name

全国または海外にブランチオフィスを構える組織では、現地のネットワークのサブネット毎にサイトを作成・分割することで、DC間のレプリケーションや、ユーザーサインインの最適化が図れます。

サイトの構成

ここでは、サイト内のレプリケーションとなるため、一旦サイト間の構成については忘れてください。

サイト内(=同一ネットワーク)では、高速かつ高信頼が前提のため、ほぼリアルタイムのレプリケーションが行われます。

Title:Windows Server 2016 Active Directory レプリケーションの仕組み
https://miya1beginner.com/windows-server-2016-active-directory-%e3%83%ac%e3%83%97%e3%83%aa%e3%82%b1%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3%e3%81%ae%e4%bb%95%e7%b5%84%e3%81%bf

サイト内レプリケーションに関連するコンポーネントとして、次のモノがあります。

  • 接続オブジェクト
  • 知識整合性チェッカー
  • 通知
  • ポーリング

接続オブジェクト

DCのレプリケート先をレプリケーションパートナーと呼ばれます。
レプリケーションパートナーは、接続オブジェクトによってリンクされます。

つまり、あるDCから別のDCに情報をレプリケーションするための、レプリケーションパスが接続オブジェクトの実態です。

通常、接続オブジェクトは自動的に生成されます。
[Active Directory サイトとサービス]→[NTDS Setting]コンテナーから確認できます。

接続オブジェクト

接続オブジェクトは、一方向のレプリケーションであり、受信のみのプルレプリケーションであることを意味します。
つまり、相互にレプリケーションする場合は、お互いのNTDS Setting配下に接続オブジェクトが作成されている必要があります。

知識整合性チェッカー

知識整合性チェッカーは、別名KCC(Knowledge Consistency Checker)と呼ばれています。

KCCは、レプリケーショントポロジを自動で作成してくれるコンポーネントになります。

接続オブジェクトによって、レプリケーションパスが構築され、レプリケーションのルーティングを決定するのがKCCの役目になります。

KCCは、各DCで動作し、サイト内のDC間のレプリケーションを最適化するようトポロジを生成します。
この自動生成されたトポロジは、どのDC間でもホップ数が3を超えないこを保証しているため、サイト内レプリケーションは1分以内には完了します。

KCCはサイト内のDCが削除、あるいは反応が遅いDCがあった場合に、トポロジを動的に再構成し、接続オブジェクトの追加または削除して、最適なレプリケーションルートを指定します。

ここで一つ注意ですが、手動で作成した接続オブジェクトに対して、KCCは関与しません。

つまり、DCを削除した場合などに手動で作成した接続オブジェクトが残るケースがあります。
そのため、接続オブジェクトを手動で作成しないことをMicrosoftさんは推奨しています。

通知

あるDCのパーティションに変更が加わると、レプリケーションパートナーに通知します。

通知とは、上位パートナーが下位パートナーに変更があることを知らせるプロセスになります。

パーティション情報に変更が加わったソースDCは、既定で15秒待ってから、最初のレプリケーションパートナー(=NW的に一番近いDC)に通知します。
その他のレプリケーションパートナーには、3秒間隔で順次通知する動作になります。

レプリケーション

サイト内レプリケーションで発生するトラフィックを調整するために、一定秒間ずつズラす設計となっています。

通知を受信したDCは、ソースDCの変更キューに格納された新しい情報をプルし、自身のパーティションを更新します。

但し、ただちにレプリケーションする必要がある情報に関しては、上述の法則を無視して、即時通知を行います。
主にセキュリティ関連に関する更新が該当し、アカウントロックなどが挙げられます。

ポーリング

通知の他に、既定で一時間に一回、上位レプリケーションパートナーに情報の更新がないかを確認しに行きます。この動作をポーリングと言います。

このポーリングには、変更がないかの確認以外にもレプリケーションパートナーの生存確認を行います。

ポーリングの結果、レプリケーションパートナーからの応答がない場合、DCがダウンしたと認識し、KCCがレプリケーショントポロジを再構成します。

SYSVOLのレプリケーション

SYSVOLとは、グループポリシーに関連するオブジェクトを保持するフォルダーのコレクションであり、各DCの%Systemroot%SYSVOL配下に格納されています。

SYSVOLも同様に、KCCによって作成されたレプリケーショントポロジに従って、レプリケーションされますが、レプリケーションに使用するコンポーネントがこれまでとは異なります。

Win2003 R2以前の場合、FRS(ファイルレプリケーションサービス)を使用し、Win2008以降であれば、DFS-R(分散ファイルシステム レプリケーション)が使用されています。

DFS-Rとは、FRSの後継サービスになります。複数のファイルサーバー間で、効率の良いレプリケーションを提供するマルチマスター レプリケーション エンジンです。

DFS-Rでは、同期のスケジュールや帯域の調整をサポートし、RDC(Remote Diffrential Compression)と呼ばれる圧縮アルゴリズムを使用しています。

RDCを使用することで、サーバ間のレプリケーションは差分のみをレプリケーションするため、トラフィック削減が期待できます。

サイトの構成について

サイト内レプリケーションの仕組みについて解説した次に、サイト間レプリケーションを解説するのですが、その前にサイトの構成について触れておきます。

これまでの解説の通り、単一サイト内でのレプリケーションでは、高速なネットワークが前提であることから、ほぼリアルタイムなレプリケーションが行われます。

組織によっては、全国または海外へのブランチオフィスに低速・低信頼なWANを敷いているケースがあります。
その場合、サイト内レプリケーションのように、変更の都度、即時レプリケーションすることで、ネットワークに支障が及ぶケースがあります。

拠点の中でも、大規模な拠点であれば、DCへの認証を拠点内で完結したいなどの要望もあるかと思います。

このような場合において、Active Directoryのサイトを構成すると、低速なWAN環境であってもレプリケーションの挙動を制御・管理し、認証サービスなどの通信のローカライズを実現出来ます。

Active Directory

サイトは通常、物理的な場所ごとに構成・分離するのが一般的です。
サイトにはサブネット オブジェクトと呼ばれるオブジェクトがマッピングされます。

サブネット オブジェクトとは、拠点で扱われるIPアドレスのサブネット値です。
この値をサイトにマッピングすることで、クライアントに割り当てらているIPアドレスを基に、どのサイトに属しているかが区別されるようになります。
結果、クライアントのサインイン処理は、同一サイト内に存在するDCに対して行われます。

既定では、「Default-First-Site-Name」という単一サイトが構成されているため、サイトを分離するためには管理者が手動で行う必要があります。

サイト間レプリケーションのしくみ

サイト間レプリケーションは、低速なWAN接続があることを考慮して、通知によるプルレプリケーションは行いません。
事前に定義されたスケジュールに従って、それぞれのサイトのDC間でレプリケーションが行われます。

既定のレプリケーション周期は180分で設定されています。
[Active Directoryサイトとサービス]からSites→Inter-Site Transportsを展開すると、「DEFAULTIPSITELINK」があります。

このオブジェクトはサイトリンクと呼ばれる、サイト間レプリケーションのレプリケーションパスを確立するオブジェクトです。

Active Directory

このオブジェクトの[レプリケーション間隔]列をみると180分であることが確認できます。
既定で180分ですが、最大15分まで周期を短くすることが可能となっております。

さて、話を少し戻して、サイト間レプリケーションパス確立のためのサイトリンクについて触れておきます。

サイト内レプリケーションでは、KCCがレプリケーションパスを確立していましたが、KCCはサイト間レプリケーションを制御することが出来ません。

そこで、各サイトのDCのKCCが、そのサイトのサイト間トポロジジェネレーター(ISTG)に指定されます。ISTGに指定されるKCCはサイト内で1つのみの存在です。

指定されたISTGが、効率の良いサイト間レプリケーショントポロジを計算します。

ISTGはサイトリンクによって生成されたレプリケーションパスを基に、サイト間レプリケーショントポロジを計算します。

サイトを作成する際に、サイトリンクを実装しないと、異なるサイト間でレプリケーションが行われなくなります。
既定の「DEFALUTIPSITELINK」をとりあえず関連付けすることでレプリケーションは行われるのですが、適切でない場合があります。

次の構成例で考えてみましょう。

Active Directory

本社が東京、ブランチオフィスが大阪、名古屋、北海道にあります。
それぞれの拠点にはDCが配置されており、いずれの拠点も本社とWANによって到達性があるものとします。

東京⇔大阪 100Mbps
東京⇔名古屋 10Mbps
東京⇔北海道 1Mbps

管理者は、拠点のクライアントが属するブランチオフィスのDCへ認証するように構成するため、サイトの分離を計画します。
管理者はTOKYO、OSAKA、HOKKAIDO、NAGOYAサイトを作成し、それぞれにサブネットオブジェクトを構成します。

サイト間レプリケーションのことは特に考えず、「DEFAULTIPSITELINK」にすべてのサイトオブジェクトを入れました。

Active Directory

この時、ネットワークはハブ&スポーク型なのに対し、ISTGは全てのサイトが相互に直接通信できる構成だと勘違いします。

例えば、OSAKAサイト⇔HOKKAIDOサイトはTOKYOサイトを経由してレプリケーションされますが、ISTGはOSAKAサイトが直接HOKKAIDOサイトへレプリケーションが可能である、と理解します。

この構成の問題は、実際のネットワークトポロジに合致していないレプリケーションパスが構成されている点です。
そのため、管理者が意図しない無駄なレプリケーションが走る可能性があります。

そこで、ネットワークトポロジと合致したレプリケーショントポロジを作成するためにサイトリンクを個別で作成し、TOYKOサイトの障害時には、自動サイトリンクブリッジによる接続オブジェクトの自動生成が行われるよう構成するのがキレイです。

自動サイトリンクブリッジとは、明示的にサイトリンクを作成していないサイト間でも、透過的に複製を可能にする機能です。

例えば、OSAKAサイトとHOKKAIDOサイトはTOKYOサイトを経由することでレプリケーションパスを確立することが出来ます。
通常運用時は不要なサイトリンクですが、TOKYOサイトが全滅した際に、自動的にOSAKA⇔HOKKAIDO間のサイトリンクを作成してくれます。
ちなみに、TOKYOサイトのDCが復活した場合、自動的に作成されたサイトリンクは削除されます。

まずは、サイトリンクを適切な形に直してあげましょう。
Active Directory

これらのサイトリンクを明示的に作成してあげることで、サイトリンクは以下のように構成されます。
Active Directory

この構成でも同様にTOKYOサイトのDCが全滅したことを考えます。
拠点間レプリケーションが行えないことを理解しているので、自動的にOSAKAサイト⇔HOKKAIDOなどのサイトリンクを作成してくれます。
Active Directory

この自動サイトリンクブリッジ機能は、[Active Directory サイトとサービス]から[Sites]→[Inter-Site Transports]→[IP]を右クリックし、[サイトリンクをすべてブリッジ]をオフにすることで無効化できます。

また、サイトリンクを明示的に作成する利点のもう一つが、サイト間ごとにレプリケーションを調整可能な点です。

今回の構成では、WAN回線にばらつきがあり、北海道拠点は1Mbpsとかなり細い帯域を使用しています。
一方で、大阪拠点は100Mbpsと高速な回線を使用しているため、それぞれの帯域に見合ったレプリケーションを計画する必要があります。

これらより、サイトの設計は組織全体の構成に合致する設計をしなければなりません。

おわりに

小規模な組織であれば、Active Directory のサイト設計は単純な構成で済みますが、大規模な組織となると、既存のインフラに適合した設計をする必要があります。

ADの管理者の場合、これらの知識は必須ですので、押さえておきましょう。
今回の記事では、一気バーっと書いてしまいましたが、ご不明点ございましたらコメントまでお願いいたします。

スポンサーリンク