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 در دو مرحله توپولوژی را ایجاد می کند:
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 که برای هر کدام از آنها قوانینی وجود دارد:
writable replica بروزرسانی ها را فقط از writable replica دریافت می کند.
Read-only replica می تواند بروز رسانیها را از writable replica دریافت کند.
Read-only replica همچنین می تواند ابدیتها را از Read-only replica دریافت کند.
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 را بصورت مفصل توضیح ندادم (گرچه در مقاله های آتی به آن اشاره خواهم کرد) ولی شما می توانید این قسمتها را در لینک زیر مطالعه کنید.