Intersite & Intrasite Replication

در اینجا به بررسی نحوه انجام Replication  به صورت Interasite (در یک سایت) و Intersite (بین چند سایت) می پردازیم. در هر دو حالت DC ها برای بهینه سازی ترافیک Replication از یک روش استفاده می کنند. هر چند که یکی از دلایل اصلی برای ساخت سایت ها و مدیریت لینک ها، مدیریت ترافیک Replication است. از آنجایی که سرعت لینک در یک سایت بالا فرض می شود، Replication در یک سایت برای حداکثر سرعت و کمترین نا پیدایی بهینه سازی شده است. نا پیدایی عبارت است مدت زمانی که طول می کشد تا یک شیئ ساخته شده در یک دامین کنترلر در سایر دامین کنترلر های همان سایت از طریق Replication ساخته شود. اما زمانی که سرعت لینک (ها) کم باشد، استفاده بهینه از پهنای باند موجود مهمترین مسئله است. با استفاده از ساختن سایت ها می توانیم، با استفاده از تکنیک های فشرده سازی و زمان بندی کردن Schedule کردن، ترافیک Replication را به بهینه ترین شکل ممکن دربیاوریم.

Intrasite Replication

در Intrasite Replication شرایط زیر موجود است:

• فرآیند Replication توسط دامین کنترلر ارسال کننده آغاز می شود. زمانی که تغییر در Data Store ایجاد می شود، دامین کنترلر ارسال کننده، یک دامین کنترلر مقصد را از وجود تغییر در Replica مطلع می سازد. تغییرات توسط کامپیوتر مقصد، از کامپیوتر مبدا توسط یک متد به نام Remote Procedure Call یا RPC کشیده می شود. پس از پایان Replication، دامین کنترلر ارسال کننده، یک دامین کنترلر دیگر را به عنوان مقصد انتخاب می کند و فرآیند گفته شده برای مقصد جدید انجام می شود.
• معمولا Replication با تاخیر ۱۵ ثانیه پس از ایجاد تغییرات آغاز می شود. چنانچه در ۱۵ ثانیه تغییر دیگری اتفاق افتد، دامین کنترلر صبر می کند و ۱۵ ثانیه دیگر انجام replication به تاخیر می افتد. همچنین پس از انجام replication با یک DC به مدت ۳ ثانیه صبر می کند و Replication را با یک DC دیگر آغاز می کند.
• از آنجایی که تمام سرور ها در یک سایت با سرعت بالا به هم متصل هستند، به جهت کاهش حجم پردازش، ترافیک به صورت فشرده نشده ارسال می شود.

ویرایش در متد intrasite Replication

معمولا نیازی به ویرایش تنظیمات پیش فرض Intrasite Replication وجود ندارد. با این وجود می توانید گروهی از این تنظیمات را تغییر دهید:

1. Wait Time: اگر Functional Level روی Windows Sever 2003 / 2008 باشد، می توانید زمانی که دامین کنترلر ارسال کننده برای شروع عمل Replication صبر می کند و زمانی که برای ارسال به دامین کنترلر دیگر صبر می کند را ویرایش کنید. برای این منظور لازم است، Configuration Parition در ADSIEdit را باز کنید و به CN=Paritions,CN=Configutaion,DC=ForestName بروید. attribute مربوط به انتظار برای شروع، msDS-Replication-Noditfy-First-DSA-Delay است. مقدار پیش فرض ۱۵ ثانیه نمایش داده نمی شود اما آن را می توانید ویرایش کنید. qttribute مربوط به انتظار برای Replication با DC دیگر msDS-Replication-Noditfy-subsequent-DSA-Delay است که به صورت پیش فرض ۳ ثانیه است. اگر Windows Server 2000 در محیط وجود داشته باشد، لازم است روی ویندوز ۲۰۰۰ از ویرایش Registry استفاده کرد. زمان انتظار برای شروع ۳۰۰ ثانیه و زمان انتظار برای Replication با DC بعدی در Windows Server 200 برابر ۳۰ ثانیه است. همچنین با استفاده از دستور repadmin می توانید این کار را انجام دهید.
2. Strict Replication Consistency: با استفاده از این متد از بازسازی اشیائی حذف شده توسط دامین کنترلر هایی که در Tombstone Liftetime برای آن ها به دلایلی همچون Down بودن Replication انجام نشده است جلوگیری می شود. به عنوان مثال اگر در زمان down بودن یک سرور، یک شیئ حذف شود و پس از سپری شدن Tombstone Lifetime سرور Up شود، سرور با توجه به Replica خود آن شیئ را به سایر دامین کنترلر ها Replicate می کند. اگر روی سایر دامین کنترلر ها Strict Replication Consistency فعال باشد، چنین اشیائی را نمی پذیرد. در Windows Server 2008 به صورت پیش فرض، فعال است که می توانید آن را از طریق Registery در مسیر زیر، غیر فعال کنید.HKEY_Local_MachineSystemCurrentControlSetServicesNTDSParametersStrict Replication Consistency
3. میزان دیتا در Replication Packet: به صورت پیش فرض این مقدار برابر ۱,۰۰۰,۰۰۰/۱ فضای RAM است که حداقل حاوی ۱۰۰ و حداکثر ۱۰۰۰ Object است. این مقادیر می توانند از طریق Registry ویرایش شوند.HKEY_Local_MachineSystemCurrentControlSetServicesNTDS

Intersite Replication

در Intersite Replication شرایط زیر موجود است:

1. Replication بیشتر بر اساس زمان بندی (Schedule) انجام می شود تا رخ دادن یک تغییر. برای تنظیم Replication بین دو سایت لازم است که لینک بین آن دو سایت تنظیم گردد. به عنوان مثال اگر سرعت لینک بین دو site بسیار م است می توان زمان بندی کرد که Replication در ساعات کاری انجام نشود.
2. زمانی که حجم ترافیک Replication بیشتر از ۳۲kB باشد، حدود ۴۰% فشرده سازی انجام می شود.
3. بر خلاف Replication در یک سایت، اعلامی مبنی بر رخ دادن تغییر بین دامین کنترلر های بین سایت ها انجام نمی شود.
4. امکان غیر فعال سازی فشرده سازی و فعال کردن اعلام تغییرات وجود دارد.
5. پروتکل های IP و Simple Mail Transfer Protocol یا SMTP برای Replication استفاده می شوند. SMTP می تواند برای Schema, Configuration, Application Directory استفاده شود اما برای Domain Partition نمی توان از SMTP استفاده کرد. تغییرات در ازای هر Partition برای یک bridgehead ارسال می شود و سپس توسط bridgehead همان سایت بین سایر دامینن کنترلر های همان سایت Replicate می شود. اگر یک لینک را یک پل (Bridge) تصور کنیم، bridgehead سروری است در هر سمت پل (هر سایت) وظیفه انتقال تغییرات Partition ای را به سایر DC های همان سایت دارد. ترافیک Replication توسط Bridgehead اغلب ارسال می شود تا توسط Replication به صورت دو به دو. پ
6. طراحی سایت ها یکی از مهمترین موضوعات طراحی  محیط AD DS است. این قبیل مطالب در آینده مورد پوشش قرار خواهند گرفت.

ناپیدایی

با توجه به فرآیندی که برای Replication در Windows Server 2008 گفته شد، زمانی پس ار به روز رسانی یک Object سپری می شود تا آن به روز رسانی در تمام دامین کنترلر ها اعمال شود. به این مدت زمان، ناپیدایی یا Latency گفته می شود. معمولا محاسبه مدت ناپیدایی ساده است. با توجه به مطالبی که پیش تر در خصوص Replication در یک سایت گفته شد و توپولوژی Replication که در آینده بررسی می شود، حداکثر مدت زمان ناپیدایی در یک سایت با تنظیمات پیش فرض ۱ دقیقه است.

محاسبه زمان ناپیدایی در بین چند سایت، قدری دشوار تر است. برای این منظور ابتدا باید مدت زمان ناپیدایی از DCای که در آن تغییرات اعمال شده تا bridgehead  همان سایت محاسبه کرد. پس از مدت زمانی که طول می کشد تا Replication بین دو bridgehead انجام شود باید محاسبه شود. این محاسبه به فاکتور هایی همچون زمان بندی و سرعت لینک دارد. به صورت پیش فرض ۳ساعت فاصله زمانی سیکل های Replication است. بنابراین با فرض داشتن سرعت قابل قبول لینک و عدم وقوع خطا، برای محاسبه حداکثر مدت زمان ۳ ساعت باید به زمان ناپیدایی اضافه شود. همچنین باید مدت زمان ۱ دقیقه برای سیکل Replication در site مقصد در نظر گرفته شود. حداکثر مدت زمان ۳ساعت و ۲ دقیقه ای در صورت مساعد بودن شرایط، ممکن است قابل قبول نباشد، از این رو می توان با کاهش فواصل Replication این زمان را کاهش داد. در نقاط حساس با تنظیم ۱۵ دقیقه برای لینک های مناسب، این زمان به حدود ۱۵ تا ۱۷ دقیقه کاهش می یابد. تعداد hop ها در هر site این اختلاف ۲ دقیقه ای را ایجاد می کند. اگر مدت زمان کمتری مد نظر است، لازم است تا تمام DCها در یک سایت باشند، هر چند اگر لینک های MAN، WAN در شبکه موجود باشند، این مسئله عملی نیست. محاسبه زمان ناپیدایی مطلوب در هر شبکه ای رابطه ی مستقیم با احتمالات مربوط به خطرات و حساسیت امنیتی شبکه دارد و رابطه ی معکوس با سرعت لینک.

Urgent Replication

در برخی موارد، مدت زمان ناپیدایی گفته شده، بسیار زیاد است و خطر آفرین است. در این شرایط AD DS به روز رسانی هایی که به مسائل امنیتی مرتبط است را با استفاده از متد Urgent Replication به روز می کند. در این شرایط دامین کنترلر های در یک سایت، به روز رسانی را در کمتر از ۱ ثانیه دریافت می کنند. این مسئله مربوط به Replication بین سایت ها نمی باشد. تغییرات زیر از Urgent Replication استفاده می کنند:

• به روز رسانی در Account Lockout Policy
• به روز رسانی در Domain Password Policy
• جا به جایی RID Master
• ویرایش در Local Security Authority – LSA
• قفل شدن (Lockout) شدن یک کاربر

توجه داشته باشید که تغییر Password کاربران از این متد استفاده نمی کند اما زمانی که کاربر Password خود را ویرایش می کند، این به روز رسای مستقیما با PDC Emulator در دامین Replicate می شود. این به روز رسانی دخالاتی به site ها و لینک ها ندارد و دامین کنترلری که در آن تغییر انجام شده با استفاده از یک کانکشن (اتصال) RPC به روز رسانی را انجام می دهد و پس از آن فرآیند Replication به صورت عادی انجام می شود. لازم به یاد آوری است که زمانی که کاربرمی خواهد Login کند، دامین کنترلری که username و password را بررسی می کند با PDC Emulator تغییر password را چک می کند.

Replication Topology

یکی از موضوعاتی که می تواند درک بهتری از Replication به شما بدهد، Replication Topology است. به صروت پیش فرض، این کار به عهده ی AD DS است و آن را اتوماتیک انجام می دهد هرچند که می توان این کار را به صورت دستی هم انجام داد. اغلب توپولوژی اتوماتیک AD DS بهترین توپولوژی ممکن است. برای ساخت یک توپولوؤی موفق باید عناصر زیر به طور مناسب پیکربندی شوند:

• زیرساخت IP:  به منظو تنظیم site ها لازم است هر سایت دارای یک subnet مناسب باشد و دو subnet باید قابل route به هم باشند. اشیاء با استفاده از MAP شدن Subnet به Site می توانند موقعیت درست خود را بیابند.
• DNS: سرویس DNS نقش اساسی در اکثراجزاء AD DS ایفا می کند. Replication هم از این قاعده استثنا نیست و برای یافتن سایر DCها از رکورد SRV استفاده می کند.
• NetLogon Service: این سرویس برای ثبت در DNS الزامی است.
• RPC – Remote Procedure Call: تمام DCها باید بتوانند با سایر DCها در Domain خود ارتباط RPC برقرار کنند. RPC همچنین برای ارتباط با تمام دامین کنترلر های در سایت نیز به کار می رود. SMTP پروتکل جایگزینی است که می تواند برای دامین کنترلر هایی که در همان سایت یا دامین نیستند به کار گرفته شود.
• Intersite Messaging: برای انجام Replication به صورت intersite با SMTP الزامی است.

Knowledge Consistency Checker – KCC

KCC فرآیندی است که در هر DC برای ساختن یک توپولوژی Replication اجرا می شود. از زمانی که دامین کنترلر به محیط AD DS اضافه می شود، KCC کار خود را برای ساختن یک توپولوژی که هم موثر و هم مقاوم در برابر خطا (Fault tolerant) باشد آغاز می کند. زمانی که دامین کنترلر یا سایت به محیط اضافه می شود KCC با اطلاعات سرور ها، سایت ها، لینک ها و زمان بندی (Schedule) به ساخت بهترین توپولوژی ممکن می پردازد. KCC به طور مجزا در هر دامین کنترلر اجرا می شود و از اطلاعات Configuration Directory Partition استفاده می کند. از آنجایی که تمام دامین کنترلر از یک اطلاعات و یک الگوریتم برای محاسبه توپولوژی استفاده می کنند، توپولوژی ساخته شده در تمام دامین کنترلر ها یکسان خواهد بود.

KCC ساخت توپولوژی را به صورت داینامیک دنبال می کند تا با هر تغییری توپولوژی را اصلاح نماید. به عنوان مثال اگر یک دامین کنترلر برای مدتی در دسترس نباشد، KCC در توپولوژی تجدید نظر می کند. به صورت پیش فرض در هر دامین کنترلر KCC توپولوژی را در هر ۱۵ دقیقه بازمحاسبه می کند. می توان در هر زمانی KCC را مجبور کرد تا توپولوژی را بازمحاسبه نماید. برای این منظور در کنسول Active Directory Sites and Services روی NTDS Setting کلیک راست کرده و در منوی All Tasks مورد Check Replication Topology را بزنید. همچنین با استفاده از دستور Repadmin /kcc DCName می توانید این کار را انجام دهید.

Connection Object

زمانی که KCC یک توپولوژی ایجاد می کند در واقع گروهی از Connection Object را ایجاد می کند که در Configuration Directory ذخیره می شود. Connection Object در واقع دامین کنترلر هایی هستند که از لحاظ منطقی به صورت مستقیم به هم متصل اند و برای Replicate کردن اطلاعات به کار گرفته می شوند. KCC توپولوژی ایجاد می کند که هم مقاوم در برابر خطا باشد و هم موثر باشد برای این منظور، KCC هر تعداد Connection Object که مورد نیاز باشد می سازد.

Connection Object ها به صورت یک طرفه – کشیدنی ساخته می شوند. این موضوع به دلیل ماهیت فرآیند Replication است که به صورت کشیدنی است. کشیدنی به این منظور که دامین کنترلر مقصد تقاضای دریافت به روز رسانی را می کند و سپس دامین کنترلر ارسال کننده اطلاعات را ارسال می کند. در اکثر شرایط بهترین توپولوژی، توپولوژی است که KCC می سازد. اما ممکن است به دلایلی همچون بر طرف کردن مشکلات، لازم باشد توپولوژی به صورت دستی منظم گردد. هم امکان ویرایش Connection Object های موجود وجود دارد هم امکان اضافه کردن یک Connection Object جدید بنابراین به هر صورت مورد علاقه می توان توپولوژی را تغییر داد. زمانی که یک Connection Object را ویرایش می کنید، نام آن از <automatically-generated> به GUID آن شیئ تغییر می کند. KCC هیچ کدام از Connection Object هایی که به صورت دستی ایجاد یا ویرایش شده را ویرایش یا حذف نمی کند اما سایر ارتباط را که ویرایش می کند تا با اشیائی که دستی ساخته شده را در اساس الگوریتمش جبران کند.

به نقل از وب سایت پورت 80