اینبار بصورت کاملا متفاوت می خواهیم این پروسه جذاب وپیچیده را با هم یاد بگیریم.
برای انتقال داده ها درون یک دومین یا یک فارست و همچنین 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 را ایجاد کند از اطلاعات ساختار اکتیودایرکتوری استفاده میکند. این اطلاعات را از پارامترهای زیر بدست می آورد:
سایت
سرورها
سایتهای وابسته به هر یک از سرورها
گلوبال کاتالوگ
Directory partition های ذخیره شده بر روی سرور
سایت لینک ها
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 های مبدا درخواست می کنند.
دو نوع Topology داریم:
Intra-site topology
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 topology را ایجاد می کند:
متصل کردن Directory Partition های یکسان و سینک کردن انها.
کنترول زمان تاخیر Replication بین سایتها
مسیر Replication بین سایتها.
بهبود در 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 را برای این منظور ایجاد کرده است.
Image
شیء 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 را از آنها درخواست می دهند.
Image
برای اینکه 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 می باشد:
Image
NTDS Site Settings Object هر سایت وظایف زیر را بر عهده دارد:
مشخص کردن ISTG هر سایت.در تصویر بالا BF-01-DC مسئنول و مالک این پروسه در این سایت می باشد.
ایا DC های این سایت مجاز به کش کردن اعضای Universal groups هستند یا نه؟
ایجاد زمان بندی برای 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 ها اعمال شود:
باید رول IIS را بر روی هر دو Bridgehead server ها نصب کنیم
نصب CA در مد Enterprise برای رمزگذاری پیغامهای ردو بدل شده بین دو سایت. وجود Domain Controller Certificate بر روی CA Server ضروری می باشد.
دوسایت باید بوسیله SMTP site link به همدیگر وصل باشند.
اگر دو سایت را بوسیله چندین Site link وصل کرده باشید (IP or SMTP) باید site link مربوط به SMTP کمترین مقدار Cost را داشته باشد.
سایتهای که مربوط به یک Domain باشند. کلا نمی توانند از این روش استفاده کنند.
DC را باید تنظیم کنیم که E-Mail ها را دریافت کند، علاوه بر آن باید مطمئن شد که mail ها دست DC مقابل برسد. (اگر دو سایت مستقیما به هم دیگر وصل باشند نیازی به تنظیم خاصی نیست، در غیر اینصورت نیاز به تنظیم یک Mail gateway هستیم.