皆さんこんにちは、Miyaです。Directoryはマルチマスターレプリケーションモデルを使用して、全てのDCに情報をレプリケートします。1つのDCで変更が発生した場合、ドメインまたはフォレスト全体に情報がレプリケートされる仕組みなっています。大規模な組織であれば、地理、ネットワークの観点から、複数拠点にDCを配置する必要があるでしょう。そこで、管理者はレプリケートの計画を立てる必要ためにも、サイトという概念を理解しなければなりません。Direcotryのレプリケートの仕組みから、サイトの構成までを解説します。Directoryでは、ローカルにデータベースを保持しています。Directoryは4つのパーティションから構成されています。Directoryでは、これらのパーティションに格納されている情報を、他のDCにレプリケーションします。パーティション毎にレプリケーションされるスコープが異なります。ドメインパーティションでは、ドメイン固有のユーザー、グループ、コンピューター、OUなどの情報が格納されいることから、レプリケートのスコープはドメイン内のDCとなります。Directoryのレプリケーションは、サイト内・サイト間で動作が異なります。サイト間のレプリケーションの場合、組織全体のネットワーク環境や、ブランチオフィスの規模などを考慮してレプリケーションされる間隔や、レプリケーションパスを設計する必要があります。Directoryのサイトという言葉を説明しておきます。Directoryにおけるネットワーク範囲の定義です。既定では、「Default-First-Site-Name」というサイトが自動的に作成され、何も触らなければ、全てのDCは同一サイト内(=同一ネットワーク)として解釈されます。全国または海外にブランチオフィスを構える組織では、現地のネットワークのサブネット毎にサイトを作成・分割することで、DC間のレプリケーションや、ユーザーサインインの最適化が図れます。ここでは、サイト内のレプリケーションとなるため、一旦サイト間の構成については忘れてください。サイト内(=同一ネットワーク)では、高速かつ高信頼が前提のため、ほぼリアルタイムのレプリケーションが行われます。レプリケーションの仕組み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に情報をレプリケーションするための、レプリケーションパスが接続オブジェクトの実態です。通常、接続オブジェクトは自動的に生成されます。Setting]コンテナーから確認できます。接続オブジェクトは、一方向のレプリケーションであり、受信のみのプルレプリケーションであることを意味します。Setting配下に接続オブジェクトが作成されている必要があります。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によって作成されたレプリケーショントポロジに従って、レプリケーションされますが、レプリケーションに使用するコンポーネントがこれまでとは異なります。レプリケーション)が使用されています。DFS-Rとは、FRSの後継サービスになります。Compression)と呼ばれる圧縮アルゴリズムを使用しています。RDCを使用することで、サーバ間のレプリケーションは差分のみをレプリケーションするため、トラフィック削減が期待できます。サイトの構成についてサイト内レプリケーションの仕組みについて解説した次に、サイト間レプリケーションを解説するのですが、その前にサイトの構成について触れておきます。これまでの解説の通り、単一サイト内でのレプリケーションでは、高速なネットワークが前提であることから、ほぼリアルタイムなレプリケーションが行われます。組織によっては、全国または海外へのブランチオフィスに低速・低信頼なWANを敷いているケースがあります。その場合、サイト内レプリケーションのように、変更の都度、即時レプリケーションすることで、ネットワークに支障が及ぶケースがあります。拠点の中でも、大規模な拠点であれば、DCへの認証を拠点内で完結したいなどの要望もあるかと思います。Directoryのサイトを構成すると、低速なWAN環境であってもレプリケーションの挙動を制御・管理し、認証サービスなどの通信のローカライズを実現出来ます。サイトは通常、物理的な場所ごとに構成・分離するのが一般的です。オブジェクトと呼ばれるオブジェクトがマッピングされます。オブジェクトとは、拠点で扱われるIPアドレスのサブネット値です。この値をサイトにマッピングすることで、クライアントに割り当てらているIPアドレスを基に、どのサイトに属しているかが区別されるようになります。結果、クライアントのサインイン処理は、同一サイト内に存在するDCに対して行われます。既定では、「Default-First-Site-Name」という単一サイトが構成されているため、サイトを分離するためには管理者が手動で行う必要があります。サイト間レプリケーションのしくみサイト間レプリケーションは、低速なWAN接続があることを考慮して、通知によるプルレプリケーションは行いません。事前に定義されたスケジュールに従って、それぞれのサイトのDC間でレプリケーションが行われます。既定のレプリケーション周期は180分で設定されています。Transportsを展開すると、「DEFAULTIPSITELINK」があります。このオブジェクトはサイトリンクと呼ばれる、サイト間レプリケーションのレプリケーションパスを確立するオブジェクトです。このオブジェクトの[レプリケーション間隔]列をみると180分であることが確認できます。既定で180分ですが、最大15分まで周期を短くすることが可能となっております。話を少し戻して、サイト間レプリケーションパス確立のためのサイトリンクについて触れておきます。サイト内レプリケーションでは、KCCがレプリケーションパスを確立していましたが、KCCはサイト間レプリケーションを制御することが出来ません。そこで、各サイトのDCのKCCが、そのサイトのサイト間トポロジジェネレーター(ISTG)に指定されます。ISTGに指定されるKCCはサイト内で1つのみの存在です。指定されたISTGが、効率の良いサイト間レプリケーショントポロジを計算します。ISTGはサイトリンクによって生成されたレプリケーションパスを基に、サイト間レプリケーショントポロジを計算します。サイトを作成する際に、サイトリンクを実装しないと、異なるサイト間でレプリケーションが行われなくなります。既定の「DEFALUTIPSITELINK」をとりあえず関連付けすることでレプリケーションは行われるのですが、適切でない場合があります。次の構成例で考えてみましょう。それぞれの拠点にはDCが配置されており、いずれの拠点も本社とWANによって到達性があるものとします。東京⇔大阪100Mbps東京⇔名古屋10Mbps東京⇔北海道1Mbps管理者は、拠点のクライアントが属するブランチオフィスのDCへ認証するように構成するため、サイトの分離を計画します。管理者はTOKYO、OSAKA、HOKKAIDO、NAGOYAサイトを作成し、それぞれにサブネットオブジェクトを構成します。サイト間レプリケーションのことは特に考えず、「DEFAULTIPSITELINK」にすべてのサイトオブジェクトを入れました。この時、ネットワークはハブ&スポーク型なのに対し、ISTGは全てのサイトが相互に直接通信できる構成だと勘違いします。OSAKAサイト⇔HOKKAIDOサイトはTOKYOサイトを経由してレプリケーションされますが、ISTGはOSAKAサイトが直接HOKKAIDOサイトへレプリケーションが可能である、と理解します。この構成の問題は、実際のネットワークトポロジに合致していないレプリケーションパスが構成されている点です。そのため、管理者が意図しない無駄なレプリケーションが走る可能性があります。そこで、ネットワークトポロジと合致したレプリケーショントポロジを作成するためにサイトリンクを個別で作成し、TOYKOサイトの障害時には、自動サイトリンクブリッジによる接続オブジェクトの自動生成が行われるよう構成するのがキレイです。自動サイトリンクブリッジとは、明示的にサイトリンクを作成していないサイト間でも、透過的に複製を可能にする機能です。OSAKAサイトとHOKKAIDOサイトはTOKYOサイトを経由することでレプリケーションパスを確立することが出来ます。通常運用時は不要なサイトリンクですが、TOKYOサイトが全滅した際に、自動的にOSAKA⇔HOKKAIDO間のサイトリンクを作成してくれます。ちなみに、TOKYOサイトのDCが復活した場合、自動的に作成されたサイトリンクは削除されます。サイトリンクを適切な形に直してあげましょう。これらのサイトリンクを明示的に作成してあげることで、サイトリンクは以下のように構成されます。この構成でも同様にTOKYOサイトのDCが全滅したことを考えます。拠点間レプリケーションが行えないことを理解しているので、自動的にOSAKAサイト⇔HOKKAIDOなどのサイトリンクを作成してくれます。Transports]→[IP]を右クリックし、[サイトリンクをすべてブリッジ]をオフにすることで無効化できます。サイトリンクを明示的に作成する利点のもう一つが、サイト間ごとにレプリケーションを調整可能な点です。今回の構成では、WAN回線にばらつきがあり、北海道拠点は1Mbpsとかなり細い帯域を使用しています。一方で、大阪拠点は100Mbpsと高速な回線を使用しているため、それぞれの帯域に見合ったレプリケーションを計画する必要があります。これらより、サイトの設計は組織全体の構成に合致する設計をしなければなりません。サイト設計は単純な構成で済みますが、大規模な組織となると、既存のインフラに適合した設計をする必要があります。ADの管理者の場合、これらの知識は必須ですので、押さえておきましょう。今回の記事では、一気バーっと書いてしまいましたが、ご不明点ございましたらコメントまでお願いいたします。2017.04.10今回はDCのレプリケーションの動きと、診断ツールであるRepadminをご紹介します。2017.03.25アクセス権限の中でも馴染み深い、共有フォルダにアクセス権限を設定して見たいと思います。コメントをキャンセルメールアドレスが公開されることはありません。date*日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)プロフィールこんにちは、Miya(@miya_microsoft)です。高校~大学では情報科学部としてプログラミングを学び、SEとして某Sierに入社しました。Microsoftプロダクトをメインに設計から構築までを担当しております。本ブログは筆者の業務範囲の中で得た学びをより深めることと、その情報が皆さまのお役に立てればという思いから設立しました。キャンセル投稿を送信できませんでした。メールアドレスを確認してください。メール送信チェックに失敗しました。このブログではメールでの投稿共有はできません。