Replication – 3

پس از آنکه Connection Objects بین دو Domain Controller در یک سایت برقرار شد (چه به صورت دستی و چه به صورت خودکار توسط KCC) عملیات Replication اتفاق می افتد. Replication بین چند سایت شامل تغییرات در یک سایت خواهد بود. عملیات Replication به صورت دو به دو بین دو DC اتفاق می افتد. Replication Topology تعیین کننده ی آن است که چه DC هایی با یکدیگر به عنوان Partner فعالیت داشته باشند. زمانی که KCC یک Topology ایجاد می کند در واقع، تعدادی  Connection Object را روی Destination DC ایجاد می کند که معرف ارتباط ورودی از سمت Source DC خواهد بود.

Notification

Notification فرآیندی است که در آن یک Upstream Partner یک Downstream Partner را از وقوع تغییرات با خبر می سازد. زمانی که تغییری روی Server01 روی می دهد، به صورت پیش فرض، ۱۵ ثانیه تاخیر برای اطلاع رسانی به Downstream Partner خود یعنی Server02 تاخیر ایجاد می کند. به این تاخیر Intial Notification Delay می گوییم. Server01 به صورت پیش فرض، برای Downstream Partner های دیگر ۳ثانیه تاخیر ایجاد خواهد کرد. به این تاخیر Subsequent Notification Delay می گوییم. این تاخیر ها به ترتیب به دلیل و امکان رخداد تغییرات احتمالی روی تغییرات صورت گرفته و یا تغییرات دیگر و متناوب کردن ترافیک شبکه است.

زمانی که Server02 پیام Notification را از Server01 دریافت می کند، Server02دریافت تغییرات از Server01 درخواست خواهد کرد. Directory Replication Agent یا به اختصار DRA عملیات انتقال را بر عهده خواهد گرفت. در مثال فوق Server01 دامین کنترلری (DC) است که تغییرات روی آن صورت گرفته، برای این منظور به آن  originating DC می گوییم. زمانی که Server02 تغییرات را دریافت می کند، آن ها را روی Directory خود اعمال می کند. موضوع قابل توجه آن است که به این تغییرات Replicated Change گفته نمی شود. Server02 سپس تغییرات صورت گرفته روی Directory خود را برای Downstream Partner های خود در فرآیندی مشابه با فرآیند مطرح شده، ارسال می کند. Server03 یک Downstream Partner برای Server02 است. پس از ۱۵ ثانیه، Server02 پیام Notification به Server03 ارسال خواهد کرد. تغییرات با ۲Hop روی شبکه منتقل شدند. در Replication به صورت Intersite از Notification استفاده نمی شود و صرفا مخصوص intrasite است.

Polling

ممکن است که تغییراتی روی دیرکتوری Server01 برای مدت زمان زیادی اعمال نشود. در این صورت Server02 که یک Downstream Partner برای Server01 است، هیچ پیام Notification ای از Server01 دریافت نخواهد کرد. در این شرایط ممکن است دلیل عدم دریافت Notification آن باشد که Server01 دیگر online نیست و یا به عبارتی دیگر، Down است. اطلاع از این مسئله برای Downstream Partner ها بسیار مهم است. برای این منظور از فرآیندی به نام Polling استفاده می شود. در فرآیند Polling یک Downstream Partner با Upstream Partner های خود ارتباط برقرار می کند و با استفاده از Query بررسی می کند آیا یک Replication در صف (Queue) برای آن ها وجود دارد یا نه. به صورت پیش فرض، بازه زمانی ارسال Polling برای Intrasite Replication هر یک ساعت یک بار و برای Intersite Replication هر سه ساعت یکبار است. هر چند این موضوع توصیه نمی شود، اما در صورت لزوم برای ویرایش این مقدار، می توانید به Properties یک Connection Object مراجعه کنید. اگر یک Upstream Partner در پاسخ به Query که توسط Downstream Partner ارسال شده (پیام Polling) باز بماند، Downstream Partner فرآیند KCC را فراخوانی می کند تا دوباره Topology ساخته شود و عنوان در دسترس نبود Upstream Partner در نظر گرفته خواهد شد.

Site Links

KCC تصور می کند در یک سایت تمام DCها می توانند با یکدیگر به صورت مستقیم ارتباط برقرار کنند. برای بررسی اتصال سایت های مختلف به یک دیپر از لینک های سایت (Site Links) استفاده می کند. Site Links شیئ است که اتصال دو یا چند سایت را به یکدیگر معین می کند. Intersite Topology Generator یا ISTG یکی از مولفه های KCC است که در ساخت Connection Object ها برای اتصالات بین سایتی نقش بازی می کند.

Site Links معرف یک مسیر برای Replication است. یک Site Link کنترلر روی Routing در شبکه ایجاد نمی کند. زمانی که یک Site Link ایجاد می شود تنها برای Active Directory معین می شود که امکان Replication به صورت مستقیم بین این دو سایت وجود دارد. ISTG با توجه به Site Link ها Connection Object ها را ایجاد می کند. با آنکه Replication Topology که توسط KCC ایجاد می شود، به صورت موثر (effective) می تواند Replication را بر اساس Link های تعیین شده انجام دهد، این به معنی کارآمد بودن (efficient) آن در توپولوژی شبکه (Network Topology) نخواهد بود.

زمامی که یک Forest (جنگل) ایجاد می کنید، یک Site Link با نام DEFAULTIPSITELINK ایجاد می شود. هر سایت دیگری که ایجاد می شود، به DEFAULTIPSITELINK متصل خواهد بود. سازمانی را با Network Topology زیر در نظر بگیرید. از آنجا که تمام سایت ها به یک لینک متصل اند، KCC درکی از عدم اتصال مستقیم شعبه های سازمان به یکدیگر ندارد. و این به معنی آن است که سیاتل ممکن است عملیات Replication را از دفتر آمستردام انجام دهد و… . برای این منظور لازم است که سه Site Link به صورت دستی ساخته شوند.

Network Topology

با توجه به ساخت سه لینک مختلف، توپولوژی به صورت زیر مبدل خواهد شد.

New Topology

 

Replication Transport Protocol

تغییرات برای Replicate شدن از یکی از دو پروتکل انتقال رونوشت‌ (Replication Transport Protocol) که در زیر مطرح شده اند استفاده خواهد کرد:

۱) Directory Service Remote Procedure Call یا به اختصار DS-RPC که به عنوان IP شناخته می شود. این پروتکل، پروتکل پیش فرض و ارجح است.

۲) Inter-Site Messaging – Simple Mail Transport Protocol یا به اختصار ISM-SMTP که به عنوان SMTP شناخته می شود. این پروتکل های برای لینک هایی استفاده می شود که غیر قابل اعتماد هستند (ممکن است از دسترس خارج شوند) و یا همیشه در دسترس نیستند.

به صورت ایدآل، تمامی لینک ها از IP برای پروتکل انتقال استفاده می کنند. به دلایل محدودیت های مختلف و نیاز به یک Certificate Authority یا CA برای SMTP استفاده از SMTP ایده مناسبی نیست. از سوی دیگر، اگر دو سایت، فقط SMTP برای Replication Protocol استفاده کنند، لازم است این دو سایت دارای Domain مجزا باشند زیرا، SMTP قادر به Replication برای Domain Naming Context نمی باشد.

Bridgehead Server

برای آنکه Replication Topology به طور کارآمد تری کار کند، یک DC به عنوان Bridgehead Server انتخاب می شود. یک Bridgehead Server مسئول Replication به درون و به خارج از یک سایت است. به عنوان مثال اگر یک Data Center دارای پنج DC باشد، یکی از DCها به عنوان Bridgehead Server تعیین می شود. اکنون تغییراتی که روی هر کدام از سرور ها در دفتر مرکزی (HQ) صورت می پذیرد، توسط Bridgehead Server به Bridgehead Server ها در شعبه منتقل می شود و بر عکس. برای مثال در تصویر زیر آمستردام و دفتر مرکزی هر یک دارای سه DC اند که وظیفه Replication بین سایت های مختلف صرفا توسط یک DC به عنوان Bridgehead Server انجام می شود.

Bridgehead Server

Bridgehead Server ها به صورت خودکار توسط ISTG ایجاد می شوند. Bridgehead Server برای هر partition انتخاب می شوند، بنابراین ممکن است Bridgehead Server برای Schema Partition و Configuration Partition در یک سایت، متمایز باشند. هر چند به دلیل آنکه یک الگوریتم اعمال می شود، معمولا یک DC انتخاب می شود. در صورت وجود Application Partition و یا DC از دامین دیگری، معمولا Bridgehead Server های مختلفی برای Partition های مختلف انتخاب می شود.

امکان معین کردن Bridgehead Server دارای ارجحیت وجود دارد. برای این منظور در کنسول Active Directory Sites and Service در قسمت Properties برای شیئ Server در Site مورد نظر مراجعه کنید. مسئله قابل توجه آن است که اگر یک یا چند Preferred Bridgehead Server انتخاب شود، اگر آن Server (ها) down شوند، حتی اگر Server دیگری در سایت وجود داشته باشد که بتواند به عنوان Bridgehead Server عمل کند، Server ی به عنوان Bridgehead Server انتخاب نخواهد شد و این مسئله سبب می شود که Replication اتفاق نیافتد. به صورت ایدآل، Preferred Bridgehead Server تنظیم نمی کنیم؛ با این حال به دلیل مسائلی همچون Firewall ها و Performance نیاز به این مسئله ممکن است وجود داشته باشد.

 

image

خاصیت تعدی برای Site Links

به صورت پیش فرض، Link ها دارای خاصیت تعدی (Transitive) هستند. به این معنی که اگر آمستردام با HQ متصل است و سیاتل با HQ متصل است، آمستردام و سیاتل به صورت تعدی با یکدیگر متصل اند. این از دیدگاه تئوری به این معنی است که ISTG می تواند یک Connection Object از سیاتل به آمستردام بین Bridgehead Server های آن ها ایجاد کند. امکان غیرفعال کردن قابلیت تعدی وجود دارد. برای این منظور در Properties مربوط به Transport مطلوب رفته و گزینه Bridge All Site Links را بدون چک مارک (Unchecked) کنید.

Site Link Bridges

یک Site Link Bridge یک یا چند سایت مختلف را با توجه به خاصیت تعدی می تواند متصل کند. ایجاد Site Link Bridge ها زمانی لازم است که خاصیت تعدی غیر فعال شده است و نیاز به ارتباط دو سایت وجود دارد. از آنجا که به صورت پیش فرض گزینه Bridge All Site Links در هر Transport فعال است، ساختن یک Site Link Bridge هیچ قابلیتی را اضافه نمی کند. در تصویر زیر، قصد داریم سیاتل را با آمستردام به استفاده از Site Link Bridge متصل کنیم. از آنجایی که آن دو لینک خاصیت تعدی پیدا می کنند، امکان Replication مستقیم بین آمستردام و سیاتل ایجاد می شود.

Site Link Bridges

Site Link Cost

Cost روی Link ها برای مدیریت جریان ترافیک Replication استفاده می شود، زمانی که بیش از یک مسیر دربرای ترافیک موجود باشد. مقدار Cost می تواند معرف فاکتور هایی همانند سرعت، قابلیت اعتماد، هزینه اقتصادی و یا دیدگاه های امنیتی باشد. Cost کمتر اولویت بیشتری به استفاده از لینک مشخص اختصاص می دهد. به صورت پیش فرض، Cost برای هر لینکی که ایجاد می شود ۱۰۰ است. برای تغییر این عدد به properties مربوط به لینک رفته و مقدار دیگری جایگزین مقدار پیش فرض کنید.

با توجه به مثال قبل، یک لینک بین آمستردام و پکن (beijing) ایجاد و فقط زمانی که لینک به دفتر مرکزی (HQ) در دسترس نیست از آن استفاده کنیم. برای این منظور، کافی است Cost بیشتری نسبت به لینک HQ به آن اختصاص دهیم.

Site Link Cost

بازه های Replication

همانطور که اشاره شد، Replication در Intersite فقط بر اساس polling انجام می شود. به صورت پیش فرض، هر سه ساعت یک بار است (برای Intersite) این مقدار برای سازمان هایی که نیاز دارند تغییرات به سرعت Replicate شود، زیاد است. در Properties مربوط به Site Link امکان ویرایش وجود دارد. حداقل مقدار ممکن ۱۵ دقیقه است.

زمان بندی Replication

به صورت پیش فرض، Replication در تمام طول ۲۴ ساعت اتفاق می افتد. برای لینک های کم سرعت، می توان Replication را طوری مدیریت کرد که فقط در ساعات کم ترافیک همانند ساعات غیر از ساعات کاری انجام شود. برای این منظور در Properties مربوط به Site Link رفته و دکمه Change Schedule را بزنید. می توان با فعال کردن قابلیت Change Notification در Intersite Replication وضعیت Urgent Replication را به نحو مطلوب تری مدیریت کرد.

پورت های لازم برای Replication

سرویس TCP UDP
LDAP ۳۸۹ ۳۸۹
LDAP ایمن شده با SSL ۶۳۶
LDAP برای GC ۳۲۶۸
Kerberos ۸۸ ۸۸
DNS ۵۳

 

Replication روی خط فرمان

دو ابزار بسیار قدرتمند Repadmin.exe و dcdiag.exe ابزار هایی هستند که برای مدیریت و مانیتورینگ Replication به کار گرفته می شوند. با استفاده از ابزار Repadmin.exe می توان گزارشی از وضعیت انجام Replication را مشاهده کرد. با استفاده از دستور dcdiag.exe می توانید تست عملکرد صحیح، امنیت و صحت کلی Replication را بررس کنید. خروجی فایل ها می تواند انواع مختلفی از جمله XML باشد.

دستور کاربرد
repadmin /showrepl * /csv نمایش وضعیت تمام Inbound Replication ها درForest برای تمام DC ها را با فرمت CSV قابل باز کردن در EXCEL
repadmin /showrepl * /errorsonly نمایش خطاهای Inbound Replication ها در Forest برای تمام DC ها
repadmin /kcc site:HQ اجرا شدن KCC در تمام دامین کنترلر های سایت HQ
repadmin /syncall dst-dc01 dc=contoso,dc=com /d /e /a Sync کردن یک DC معین شده با تمام Partner هایش شامل DC ها در سایت های دیگر
dcdiag /test:topology بررسی اینکه آیا برای تمام DSA ها Replication Topology متصل است.
dcdiag /test:replication بررسی زمان بندی Replication بین DC ها

با استفاده از سوییچ ؟ یا جستحو می توانید اطلاعات بیشتری در خصوص این دستورات بیابید. در زیر به مهم ترین سوییچ ها اشاره شده است.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *