احمد جهلولی
متخصص سرویس های مایکروسافت

کاملترین معرفی روش کار رپلیکیشن | Replication در اکتیودایرکتوری

رپلیکیشن یا Replication در اکتیودایرکتوری چگونه انجام می شود؟ چه فرآیندی در زمان Replciation سرویس Active Directory در پس زمینه در حال اجراست؟ دو دومین کنترلر چگونه اطلاعاتشان را با هم یکپارچه می کنند؟  اینبار بصورت کاملا متفاوت می خواهیم این پروسه جذاب وپیچیده را با هم یاد بگیریم.

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
  • برای انتقال داده ها درون یک دومین یا یک فارست و همچنین Sync کردن پارتیشن های Forest-wide در یک فارست اکتیو دایرکتوری از Replication استفاده می کند.
  • برای اینکه پروسه Replication بتواند این اطلاعات را بصورت بهینه دورن یک سایت یا بین سایتها منتقل کند یک توپولوژی ایجاد می کند.
  • Replication topology توسط KCC یا Knowledge Consistency Checker بر روی یک Domain Controller ایجاد می شود.
  • KCC برنامه ای می باشد که شامل اجزای مختلفی هستش و بر روی هر یک از DC ها عمل می کند. کانفیگ و مدیریت Replication توسط KCC انجام می شود.
  • KCC بصورت جداگانه بر روی DC ها فعالیت می کنند و هیچ ارتباطی با دیگر DC ها ندارند. در نتیجه آنها باید از یک الگوریتم ثابت و به همراه داده های که در Schema and * Configuration Partition ذخیره شده است استفاده کنند و توپولوژِی خود را ایجاد کنند.
  • برای اینکه KCC بتواند Replication topology را ایجاد کند از اطلاعات ساختار اکتیودایرکتوری استفاده میکند. این اطلاعات را از پارامترهای زیر بدست می آورد:
  1. سایت
  2. سرورها
  3. سایتهای وابسته به هر یک از سرورها
  4. گلوبال کاتالوگ
  5. Directory partition های ذخیره شده بر روی سرور
  6. سایت لینک ها
  7. Site link Bridge
  • برای اینکه KCC بتواند از اطلاعات ذخیره شده بر روی هارد دیسک DC و پارتیشنهای دایرکتوری سرویس استفاده کند از Directory System Agent استفاده می کند. DSA دسترسی KCC به اطلاعات مهم برای ساختن Replication topology را مسیر می کند.
  • KCC می تواند برای ایجاد Replication topology داده های (مربوط به Replication) را ایجاد، تعقیر یا حذف کند.
  • KCC در صورتی با دیگر DC ها ارتباط برقرار می کند که به دنبال Replication error باشند. KCC از این پروسه برای عیب یابی Replication استفاده می کند. یادتون باشه Replication error فقط درون یک سایت اتفاق می افتد.
  • KCC برای ارتباطات خود از پروتکل RPC استفاده می کند نه پروتکل LDAP
  • برای اینکه ترافیک Replication بین DCهای یک سایت یا چندین سایت جریان داشته باشد KCC و ISTG کانکشن ایجاد می کنند. این کانکشنها را Connection object می نامند.
  • قبل از اینکه Connection object ها ایجاد شوند باید DC مبدا و DC مقصد مشخص شود. بعد از مشخص شدن این دو پارامتر Connection objectها ایجاد خواهند شد.
  • یکی از اجزای KCC که خیلی هم مهم می باشد ISTG یا Intersite Topology Generator نام دارد که وظیفه آن ایجاد connection object های مناسب بین Bridgehead server ها برای ایجاد Replication بین سایتها می باشد. ISTG علاوه بر وظیفه فوق وظیفه انتخاب Bridgehead server و مدیریت Replication بین سایتها را بر عهده دارد.
  • Bridgehead server ها نمایندگان هر سایت می باشند که وظیفه Replication کردن تعقیرات سایت با سایتهای دیگر می باشد و همچنین تعقیرات ایجاد شده توسط سایتهای دیگر را دریافت می کنند و به DC های سایت خود منتقل می کنند.
  • ISTG فقط بر روی یکی از DC ها در کل سایت اجرا خواهد شد و یک دید کلی از کل DC های درون یک Forest را ایجاد می کند.
  • محدوده فعالیت KCC فقط بر روی یک DC می باشد ولی محدوده عملکرد ISTG کل یک سایت.
وب سایت توسینسو
  • بصورت خیلی ساده و خلاصه شده ESE جدولی می باشد که روند عملکرد یک سرویس را ردیابی می کند و بصورت Log file این رویدادها را در دیتابیس خود ذخیره می کند.
  • در تصویر بالا چهار DC مشاهده می کنید که چون همه از یک الگوریتم و یک پارتیشن سراسری (Configuration Directory Partition) استفاده می کنند یک Topology کلی برای خود ایجاد کرده اند.
  • DC های که Intrasite Replication Topology را ایجاد می کنند همیشه خود را به عنوان DC های مبدا ست می کنند. و DC های دیگر DC های مقصد ترافیک Replicate را از DC های مبدا درخواست می کنند.

چند نوع توپولوژی Replication وجود دارد؟

  1. Intra-site topology
  2. Inter-site topology

به Replication ی که درون یک سایت انجام می شود Intra-site replication می گویند. و Replicationی که بین سایتها اتفاق می افتد را Inter-site replication می نامند. replication topology درون یک سایت توسط KCC ایجاد می شود. و Inter-site topology توسط ISTG ایجاد می شود.KCC توپولوژی درون یک سایت را همیشه بصورت Ring ایجاد می کند. و ISTG یک دید کلی از کل Bridgehead Server های سایتهای دیگر ایجاد میکند.

وب سایت توسینسو

بعضی از اجزای KCC برای اجرای Replication موفقیت امیز، ضروری هستن بعضی از انها ضروری نیستند و فقط برای بهینه سازی این ارتباط بکار می روند. ساختار زیر را با دقت نگاه کنید:

وب سایت توسینسو

در تصویر بالا همه ی سرورها Domain controller هستند. همه ی آنها بصورت مستقل از اطلاعات دایرکتوری سرویس استفاده می کنند و Connection object های خود را ایجاد می کنند. KCC توپولوژی Intra-site را بین DC های یک سایت ایجاد می کند. و ISTG توپولوژی بین سایتها را نیز ایجاد می کند. درون یک سایت همه DC ها بصورت Ring تعقیرات خود را Replicate می کنند. و ISTG توپولوژی Inter-site را توسط Bridgehead Server ها ایجاد میکند.

    • هر سایت در تصویر بالا نمایانگر محدوده فعالیت فیزیکی یک شبکه یا یک شعبه از یک کمپانی بزرگ می باشد که در آنها ارتباطات سرویس ها با یکدیگر حداقل با سرعت 10 Mbps می باشد. ما این محدوده را توسط شیء به نام Siteدر ساختار دایرکتوری سرویس ایجاد می کنیم. ما این سایتها را توسط یک ارتباط پر سرعت مانند Wireless یا MPLS با هم دیگر وصل می کنیم. در ساختار دایرکتوری ما این لینک ارتباطی را بوسیله شیء به نام Site link مشخص می کنیم. Site link ها به Bridgehead server هر سایت اجازه ارتباط با دیگر Bridgehead server ها را می دهد.
    • Replication بین سایتها توسط پروتکل RPC انجام می شود. همچنین این پروتکل داخل یک سایت هم استفاده می شود. در تصویر بالا مشاهده می کنید که لینک ارتباطی بین سایت A and D پروتکل SMTP می باشد این پروتکل مانند پروتکل RPC برای Replicate کردن:
# Configuration Directory Partition
# Schema Directory Partition 
# Global Catalog read-only, partial  
# read-only directory partitions 
  • استفاده می شود.این پروتکل برای Replication کردن writable domain directory partitions,ها استفاده نمی شود. این پروتکل برای مواقعی استفاده می شود که ارتباط TCP/IPبا سایت مقصد وجود نداشته باشد یا Site link قابل اعتماد نمی باشد.
  • بصورت پیش فرض Site link A-B and A-C بصورت transitive هستند (bridged) بدین معنی که بدون Site link بین سایت B and C ترافیک Replicationبین این دو سایت از طریق سایت A جریان دارد. هر Site link یک پارمتر به نام Cost دارد که ISTG از این پارامتر برای تعین بهترین مسیر برای Replication استفاده می کند. در تصویر بالا مقدار Cost که بر روی Site link A-B and A-C وجود دارد با هم دیگر جمع می شوند و حاصل آن بعنوان یک مسیر ترجیح داده شده برای سایتهای B and C تلقی می شود. در نتیجه Replication بین سایت B and C بصورت اتوماتیک از طریق سایت A به همدیگر Route می شود. در صورتی این دو سایت با هم دیگر بصورت مستقیم Replicate می کنند (با ایجاد Connection object) که Bridgehead server های سایت A در دسترسی نباشند یا متعلق به دومین دیگری باشد.

اهداف KCC در توپولوژی Replication چه چیزهایی هستند؟

  1. متصل کردن Directory Partition های یکسان و سینک کردن انها.
  2. کنترول زمان تاخیر Replication بین سایتها
  3. مسیر Replication بین سایتها.
  4. بهبود در Log on کردن کلاینتها.
  • بصورت پیش فرض Replication Topology بصورت اتوماتیک توسط KCC and ISTG ایجاد می شود. ولی ادمین می تواند آن را بصورت دستی ایجاد کند یا تعقیر دهد که اولویت با تعقیرات ایجاد شده توسط ادمین می باشد.
  • یک Replication topology در واقع شامل چندین Replication topology اساسی می باشد. این توپولوژی ها بر اساس Directory partition ها ساخته می شوند. مثلا Schema and Configuration directory partition از یک توپولوژی استفاده می کنند و Application directory partition از یک توپولوژی جداگانه. و همچنین Domain directory partition از یک توپولوژی جداگانه. بعضی از این توپولوژی ها با هم دیگر ادغام می شوند و از کانالهای ارتباطی (connection object) استفاده می کنند و با تمام DC های که داده های یکسانی را نگهداری می کنند Replicate می شوند. به عنوان مثال Configuration and Schema directory partition بر روی همه DC های Forest یکسان می باشد.

نکته: اگر Domain controller ها Replica ی هم دیگر هستند (DC های یک دومین) برای Replication کردن Directory partitionها از یک Connection object استفاده می شود.همانطور که اشاره کردیم برای هر یک (یا هر چند) از Directory partition ها یک توپولوژی متفاوت ایجاد می شود. در بعضی از حالات Schema and Configuration Directory partition و Application Partition از همان توپولوژی استفاده می کنند که Domain directory partition استفاده می کند.

نکته: در شرایطی که Application and domain directory partition در DC مبدا و DC مقصد یکسان باشند KCC برای Application partition یک Connection object جداگانه ای ایجاد نمی کند.حتما به این نتیجه رسیدید که Connection object ها بر اساس Topology ها ایجاد می شوند. افرین به شما که به نتیجه درستی رسیدید.

نکته: هرگز برای partial replicas که در Global catalog ذخیره می شوند توپولوژی جداگانه ای ایجاد نمی شود. در نتیجه GC از Connection object های توپولوزی های دیگر استفاده می کند.برای اینکه KCC یا ISTG بتواند توپولوژی یا توپولوژی های نهائی را ایجاد کند مسیرهای ارتباطی directory partition های زیر را جمع بندی می کند:

# Configuration and schema within a site.
# Each writable domain directory partition within a site.
# Each application directory partition within a site.
# Global catalog read-only, partial domain directory partitions within a site.
# Configuration and schema between sites.
# Each writable domain directory partition between sites.
# Each application directory partition between sites.
# Global catalog read-only, partial domain directory partitions between sites.

قضیه تاخیر یا Latency بین سایتها را می توانید در این مقاله مطالعه کنید.همچنین بهبود در Log on کردن کلاینتها را میتوانید اینجا مطالعه کنید.اکتیودایرکتوری اطلاعات مربوط به Replication topology را در Configuration directory partition ذخیره می کند.برای اینکه KCC و ISTG بتوانند بهترین ومتناسبترین توپولوژِی ساختار دایرکتوری سرویس را ایجاد کنند نیاز به کمک شما دارند. عاره شما دوست عزیز :) بعضی از پارامترها را باید به این دو پروسه معرفی کنید تا بدونن چطور توپولوژی را ایجاد کنند. مایکروسافت کنسول AD Site and Services را برای این منظور ایجاد کرده است.

وب سایت توسینسو
  • شیء Site در کنسول بالا نشان دهنده یک یا چند Subnet می باشد که درون یک سایت استفاده می شوند ، زیر مجموعه Site کانتینری به نام Server وجود دارد که DC های آن سایت را مشخص می کند.
  • شیء Subnet سگمنتهای TCP/IP می باشند که به کلاینتهای آن سایت تعلق دارد. همچنین از این شیء برای مشخص کردن محدوده فعالیت کلاینتها استفاده میشود. ادرس هر کلاینت نماینگر سایت آن کلاینت می باشد.
  • شیء Subnet به شیء Site مپ می شود. در پروسه Domain controller location کلاینتها از شیء Subnet and Site استفاده می کنند و DC های آن سایت یا سایت نزدیک را پیدا می کنند.
  • بصورت پیش فرض وقتی Active Directory را نصب می کنید هیچگونه Subnetی ایجاد نمی شود و اگر در یک ساختار چندین سایت داشته باشید و Subnetی تنظیم نکنید پروسه احراز هویت و استفاده از منابع شبکه با مشکل رو به رو می شود.
  • زیر مجموعه سایت شیء به نام Server وجود دارد که DC های یک سایت در آن نگهداری می شود. هنگام نصب Domain Controller تنظیمات IP آن با سایتها و سابنتها مقایسه می شود و بصورت اتوماتیک، DC سایت خود را در هنگام نصب انتخاب میکند. ولی اگر تنظیمات IP سرور DC با هیچکدام از سایتها مچ نباشد خود را در سایت DCی عضو می کند که اولین Replication را با آن انجام دهد.
  • وقتی شما DC ی از سایتی به سایت دیگری منتقل می کنید باید تنظیمات IP آن را مطابق آن سایت بصورت دستی تعقیر دهید. و دستورات زیر را بر روی آن اجرا کنید:
Ipconfig /flushdns

Ipconfig /registerdns

Net stop netlogon

Net start netlogon
  • و همیشه در قسمت Preferred dns server ادرسها را بصورت ضربدری بر روی DC ها تنظیم کنید. علت اینکار را در اینده اگر عمری باقی ماند توضیح می دهم.
  • شیء NTDS که زیر مجموعه Server می باشد نشان دهنده آن است که بر روی این سرور سرویس Active Directory نصب می باشد. و همچنین این شیء نشان دهنده DC های در حال کار و یا از رده خارج شده می باشد.
  • وقتی شما DCی را demote می کنید شی NTDS حذف می شود. تا نشان دهد این سرور از رده خارج می باشد.
  • Connection object شیء می باشد که برای Replication بین DC ها استفاده می شود. Connection object یک مسیر یک طرفه می باشد که DC های مبدا ترافیک Replication خود را به سمت آنها (DC های مقصد) ارسال می کنند.
  • KCC برای هر DC ی که دارای شیء NTDS باشد یک Connection object می سازد. (این پروسه برای DC های درون یک سایت اتفاق می افتد)

Connection object هم بصورت یک طرفه One-way و هم دو طرفه Two-way در ارتباط می باشد. متد One-way درون یک سایت کاربرد دارد ولی متد Two-way بین سایتها استفاده می شود.مثال می زنم: وقتی چندین سایت داشته باشیم و قابلیت Bridge link را غیرفعال کنیم ISTG یک Connection object می سازد و از طریق این کانکشن ترافیک replication را دریافت و ارسال می کند.

  • بحثی داریم به نام مالکیت Connection object یا Ownership of Connection Objects کانکشنهای که توسط KCC ایجاد می شوند در مالکیت KCC قرار دارند و KCC میتواند آنها را حذف، تعقیر یا ایجاد کند. ولی اگر ادمین یک کانکشن ایجاد کند این کانکشن در مالکیت ادمین می باشد و پروسه KCC حق ندارد آن را تعقیر دهد.
  • وقتی شما کانکشنی را که در مالکیت KCC or ISTG باشد تنظیمات آن را تعقیر دهید از مالکیت KCC خارج می شود.
  • وقتی ادمین کانکشنی را ایجاد می کند، ان کانکشن باقی می ماند تا ادمین ان را پاک کند. همچنین اگر KCC کانکشنهای یکسانی را ایجاد کند انها را بصورت اتوماتیک حذف خواهد کرد و فقط کانکشنهای ضروری را ایجاد می کند.
  • DC ها همیشه کانکشنهای DC های مبدا را در خود ایجاد می کنند و replication را از آنها درخواست می دهند.
وب سایت توسینسو
  • برای اینکه ISTG بتواند Connection object های لازم بین سایت خود با سایتهای دیگر را ایجاد کند نیاز به ایجاد یک Site Link می باشیم. شیء Site Link به پروتکل انتقال ترافیک Replication و زمانبندی کردن Replication بین سایتها و همچنین لینک اتصال دو سایت اشاره دارد. ISTG از اطلاعات ذخیره شده در Site Link ها استفاده و Inter-site topology را ایجاد میکند.
  • بصورت پیش فرض همه site linkها که از یک پروتکل انتقال (IP or SMTP) استفاده می کنند، KCC فرض می کند که همه آنها بوسیله یک مسیر یا Route به همدیگر وصل (bridge) می باشند.

اگر می خواهید KCC چنین برداشتی نکند و برای دسترسی به سایتی چندین مسیر وجود دارد یا در مواقعی که سایتهای شما Full route نباشند باید این قابلیت را غیرفعال کنید و Route های مختلفی بوسیله Site link bridge بصورت دستی ایجاد و Site link ها را عضو Site link bridge کنید.

  • NTDS Site Settings Object شیء می باشد که در زیر مجموعه سایت قرار دارد و تنظیمات و نحوه اعمال این تنظیمات بصورت Site-wide می باشد. هر سایت مجاز به داشتن یک NTDS Site Settings Object می باشد:
وب سایت توسینسو

NTDS Site Settings Object هر سایت وظایف زیر را بر عهده دارد:

  1. مشخص کردن ISTG هر سایت.در تصویر بالا BF-01-DC مسئنول و مالک این پروسه در این سایت می باشد.
  2. ایا DC های این سایت مجاز به کش کردن اعضای Universal groups هستند یا نه؟
  3. ایجاد زمان بندی برای Connection object ها.
  • شیء دیگری وجود دارد به نام Cross-Reference Objects که در کنسول AD Site and Services قابل مشاهده نیست و بوسیله کنسول Adsiedit.msc قابل مشاهده می باشد. این شیء محل های Directory Partition را ذخیره می کند. Active directory replication از این شیء استفاده می کند و DC های که Directory Partition بر روی انها ذخیره شده است را نشان می دهد.
    • DC برای انتقال Replication از دو پروتکل انتقال استفاده می کند: RPC over IP and STMP over IP. Replication درون یک سایت و بین سایتها همیشه از RPC over IP بصورت همزمان استفاده می کند. برای سایتهای که به ندرت در دسترس هستند و ارتباط درست و درمونی بین آنها نباشه از SMTP over IP استفاده می شود. توجه کنید SMTP برای انتقال Replication بین یک Domain در دو سایت مختلف استفاده نمی شود چون بوسیله این پروتکل فقط پارتیشنهای زیر Replicate می شود:
# Schema 
# Configuration
# Global catalog

در نتیجه Domain partition نمی تواند از SMTP استفاده کند. SMTP and IP از دو متد برای انتقال ترافیک Replication استفاده می کنند.

# Synchronous=RPC over IP
# Asynchronous=SMTP over IP
  • RPC over IP از Synchronous استفاده و شروع به Inbound Replication می کند. در ارتباطات Synchronous دومین کنترولر مقصد درخواست Replicate با DC مبدا می کند و منتظر جواب می ماند تا DC مبدا درخواست را دریافت کند و Replication را اماده کند و ان را قبل از ارسال notification change به بقیه DC آن را به سمت DC مقصد ارسال کند. به این پروسه inbound replication می گویند در نتیجه DC ها مقصد در ارتباطات Synchronous جواب و داده های Replication را در مدت زمان کوتاهی دریافت می کنند. پروتکل IP از متد Synchronous استفاده می کند. ولی در متد Asynchronous که برای پروتکل SMTP استفاده می شود DC های مقصد منتظر جواب DC های مبدا نمی مانند و در بازه های زمانی خاص درخواست Replication را به چندین DC ارسال می کنند. در نتیجه دریافت Replication در یک زمان کوتاه اتفاق نمی افتد.
  • اگر سایت شما در نقطه بدی قرار دارد و همیشه در دسترس نباشد و نتوان بوسیله RPC over IP اطلاعات Replicate را سینک کرد، تنها گذینه ای که برای Replication بین دو سایت باقی می ماند استفاده از E-Mail می باشد. وقتی که ارتباط دو سایت با هم دیگر قطع وصل می شود باید از روش Asynchronous استفاده کرد (SMTP) به علاوه زمانی که محدودیتی از نظر پهنای باند بین دو سایت داشته باشیم نمی توان دو DC را مجبور کرد تمام اطلاعات خود را (All directory partition) ریپلیکت کنند در نتیجه می توان از SMTP استفاده کرد که درخواست خود را در بازه های زمانی مختلفی برای چند DC ارسال کند و در هر بازه از زمان قسمتی از اطلاعات را دریافت کند.
  • در Inter-site replication و استفاده از SMTP ما بجای RPC از Mail messaging استفاده می کنیم. در این روش از Change notification استفاده نمی شود بلکه هنگامی که هر دو سایت به همدیگر وصل شدند شروع به تبادل اطلاعات می کنند.
  • Intersite messaging قابلیتی می باشد برای Replication بین دو DC که از SMTP استفاده می کنند. این قابلیت هنگام نصب سرویس AD نصب و فعال می شود.
  • KCC برای DC های که از SMTP استفاده می کنند Connection object ایجاد نمی کند تا وقتی که شرایط زیر بر روی DC ها اعمال شود:
  1. باید رول IIS را بر روی هر دو Bridgehead server ها نصب کنیم
  2. نصب CA در مد Enterprise برای رمزگذاری پیغامهای ردو بدل شده بین دو سایت. وجود Domain Controller Certificate بر روی CA Server ضروری می باشد.
  3. دوسایت باید بوسیله SMTP site link به همدیگر وصل باشند.
  4. اگر دو سایت را بوسیله چندین Site link وصل کرده باشید (IP or SMTP) باید site link مربوط به SMTP کمترین مقدار Cost را داشته باشد.

سایتهای که مربوط به یک Domain باشند. کلا نمی توانند از این روش استفاده کنند.

  1. DC را باید تنظیم کنیم که E-Mail ها را دریافت کند، علاوه بر آن باید مطمئن شد که mail ها دست DC مقابل برسد. (اگر دو سایت مستقیما به هم دیگر وصل باشند نیازی به تنظیم خاصی نیست، در غیر اینصورت نیاز به تنظیم یک Mail gateway هستیم.
  • Replication بین چندین سایت برای انتقال Domain directory partition, زمانیکه DC های یک دومین در چندین سایت قرار دارند. همچنین اگر بیش از یک سایت داشته باشیم Replicate کردن Schema and configuration directory partition برای همه سایتها لازم و ضروری می باشد. Replication بین چند سایت از طریق Bridgehead server ها انجام می شود. هر سروری که یک Connection objet از DC های دیگر سایتها داشته باشید بعنوان Bridgehead server مشخص می شود. همچنین با دستور زیر می توانید Bridgehead server های هر سایت را مشخص کنید:
repadmin /bridgeheads

KCC دومین کنترولری را به عنوان Bridgehead انتخاب می کند که بتواند تمام Directory partition ها بعلاوه partial global catalog partitions را از دیگر سایتها Replicate کند. بصورت پیش فرض KCC بر روی DC ی که ISTG روی آن فعال باشد شروع به انتخاب Bridgehead server ها می کند. سرور های که نقش GC بر روی آنها فعال می باشد اولویت آنها برای BH زیادتر از بقیه DC ها می باشد.

  • ترافیک Replicate شده بین سایتها فشرده سازی می شود.ولی این مسئله دورن یک سایت صدق نمی کند.
  • بصورت پیش فرض همه سایت لینکها قابلیت تعدی یا Transitive هستند که این قابلیت را بصورت مفصل اینجا توضیح دادم.
  • وقتی قابلیت Transitive بر روی همه site linkها فعال باشد KCC میتواند مسیر replicate را تعقیر دهد و connectionهای لازم را ایجاد کند. تصویر زیر را ببینید:
وب سایت توسینسو

در صورت Down شدن BH سرورهای سایت Seattle پروسه KCC مسیر Replicate را تعقیر و کانکشنهای لازم با دو سایت Portland and Boston را ایجاد می کند.توجه کنید این پروسه در صورتی موثر می باشد که همه سایتها full route باشند و Transitive. پروسه KCC بوسیله مقدار Cost مسیر replication را تعیین می کند. برای درک این موضوع تصویر زیر را ببینید:

وب سایت توسینسو

دو عدد سایت لینک که سه سایت را به همدیگر وصل کرده اند و قابلیت Transitive بر روی سایت لینکها فعال می باشد. برای اینکه سایت Portland and Boston بتوانند بصورت مستقیم با همدیگر Replicate کنند ISTG مقدار Cost دو سایت لینک را جمع می کند و حاصل آن می شود مقدار Cost لینک (مجازی یا منطقی) بین دو سایت Portland and Boston . در نتیجه DC3 یک Connection object با DC2 و بلعکس ایجاد می کند.

(اینجا را با دقت بخوانید و درک کنید)

ولی صبر کنید سه سایت بالا Directory Partition یکسانی دارند (همه DC ها در یک دومین فعالیت می کنند) پس در نتیجه ISTG بجای ایجاد یک Site link مجازی از سایت لینک PS که دارای Cost کمتری می باشد استفاده می کند و بوسیله متد Store-and-Forward بهره می برد و Replication را بوسیله DC های سایت Seattle ارسال و دریافت می کند. ولی اگر سایت Seattle دومین جداگانه ای باشد یا BH سرورهای سایت Seattle در دسترس نباشند یک Site link مجازی بین Portland and Boston ایجاد می شود.

  • نکته: تمام پروسه (ساختار را بصورت Full Route در نظر بگیرید) بالا در صورتی امکان پذیر می باشد که سایت لینکها Bridge or Transitive باشند.

نکته: برای اینکه پروسه بالا با موفقیت اجرا شود باید زمان بندی و دفعات Replication در دو سایت لینک PS and SB یکسان باشند.

  • نکته: اگر قابلیت Bridge بر روی این دو سایت لینک غیرفعال باشد هرگز سایت لینک مجازی بین سایتهای Portland and Boston ایجاد نمی شود. و شما باید یک Site link bridge بصورت دستی ایجاد کنید.

یک سوال خیلی مهم و کاربردی: چه زمانی ما باید یک Site link bridge بصورت دستی ایجاد کنیم؟؟؟

زمانی که ساختار ما non-full route باشند و Domain directory partition مربوط به یک دومین در چند سایت مختلف نگهداری می شود. به عبارت دیگر DC های یک دومین در چند سایت مختلف می باشند. تصویر زیر را ببینید:

وب سایت توسینسو

پروسه یا فرآیند KCC چیست و چگونه انجام می شود؟

  • پروسه KCC هر 15 دقیقه کل توپولوژی را چک می کند و توپولوژی مورد نظر را ایجاد یا تعقیر می دهد.
  • بصورت پیش فرض اولین فعالیت KCC 5 دقیقه بعد از استارت شدن DC می باشد. اگر DC دارای سرویس های DHCP-WINS و غیره باشد این مدت زمان افزایش می یابد. این مدت زمان از طریق Registry قابل تعقیر می باشد.

KCC چگونه توپولوژی Replication را ایجاد می کند؟

Evaluation:در این فاز KCC با استفاده از اطلاعات موجود در DC ساختار را ارزشیابی می کند و طبق این اطلاعات Connection object ها را ایجاد یا حذف می کند.

Translation: در این فاز طبق ارزشیابی وتصمیماتی که KCC در مرحله قبلی انجام داده توپولوژی را ایجاد می کند. در این مرحله KCC یک صفت RepsFrom برای هر DC ایجاد می کند که برای Intra-site topology لازم می باشد یا بر روی Bridgehead server ها این صفت را ایجاد می کند. (برای Inter-site topology)

KCC چند محدوده و حالت فعالیت دارد؟

وب سایت توسینسو

وقتی KCC توپولوژی را محاسبه میکند دو نوع replication را لحاظ می کند یکی Writable or read-only Replication که برای هر کدام از آنها قوانینی وجود دارد:

  1. writable replica بروزرسانی ها را فقط از writable replica دریافت می کند.
  2. Read-only replica می تواند بروز رسانیها را از writable replica دریافت کند.
  3. Read-only replica همچنین می تواند ابدیتها را از Read-only replica دریافت کند.
  4. writable replica هرگز بروزرسانیها را از یک Read-only replica دریافت نمی کند.

KCC برای هر یک از Directory partition ها دو نوع توپولوژي محاسبه می کند. یکی برای Writable replica و یکی برای read-only replica. که این محاسبات تحت شرایطی منجر به ایجاد یک Connection object اضافی برای read-only replica می شود. شاید بعضیا تفاوت این دو مد را با هم ندانند که توضیح میدم. بعضی از Directory partition ها بصورت کامل بین DC های یک فارست Replicate می شود مانند Schema, configuration و هر یک از DC ها سه نوع پارتیشن را بصورت کامل دریافت می کنندSchema, configuration و Domain partition مربوط به دومین خود (دومین معتبر) به این نوع ریپلیکیشن Writable replica می گویند.

در بعضی از DC ها نقش GC فعال می باشد GC علاوه بر پارتیشن های بالا نیاز به Domain directory partition بقیه دومین های فارست دارد. ( GC تمام اطلاعات Domain partition بقیه دومین ها را دریافت نمی کند بلکه Attribute های محدودی از همه ابجکتها را (که در Schema قابل تعیین می باشد که به لیست PAS معروفه) دریافت می کند که به این نوع Replication بین دو GC میگن Read-only Replica. همچنین پارتیشنی که بین GC ها Replicate می شود Read-only می باشد. در تصویر زیر یک سایت با چهار دومین مختلف مشاهده می کنید. بر روی یکی از DC های دومین A نقش GC فعال می باشد. Replicate بین DC ها بدین شکل می باشد:

وب سایت توسینسو

نکته مهم: اگر یک DC بعد از چند با سعی کردن نتوانست جوابی از DC مقابل دریافت کند و این روال تا دو ساعت همچنان باقی بماند KCC فرض را بر غیر قابل دسترس بودن این DC میگذارد. و توپولوژي را دوباره محاسبه می کند و Connection object آن DC را پاک و یک Connection object جدید ایجاد و یک DC جدید انتخاب می کند.

  • Replication برای ارتباط در یک یا چندین سایت بصورت پیش فرض از RPC استفاده می کند. RPC برای عملکرد خود از پورتهای تصادفی استفاده می کند. در جدول زیر پورتهای لازم برای Replication را می بینید:
وب سایت توسینسو

در سناریوهای که بین کلاینتها و DC فایروالی وجود دارد شما باید این پورتها را در مد Fixed تنظیم کنید. برای اینکار از گوگل استفاده کنید. در این مقاله روش ایجاد توپولوژی در Intra-site and Inter-site را بصورت مفصل توضیح ندادم (گرچه در مقاله های آتی به آن اشاره خواهم کرد) ولی شما می توانید این قسمتها را در لینک زیر مطالعه کنید. منبع مقاله قبلی واین مقاله لینک زیر می باشد:

How Active Directory Replication Topology Works

https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx#w2k3tr_repto_how_ludi

حرفه ای باشید


احمد جهلولی
احمد جهلولی

متخصص سرویس های مایکروسافت

سایت شخصی من: https://msdeeplearn.net

نظرات