جشنواره تخفیف ۶۰ درصدی پاییز توسینسو شروع شد
60 درصد تخفیف
کد تخفیف: autumn1403
کد تخفیف: autumn1403
احمد جهلولی
احمد جهلولی
متخصص سرویس های مایکروسافت

نکات مهم در Replication اکتیودایرکتوری که باید بدانید

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها:

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
برای مشاهده تخفیف های ویژه امروز کلیک کنید
سرفصل های این مطلب
  1. Intra-site Replication
  2. Inter-site Replication
  3. Site Link
  4. Site Link Bridges
  5. چطور!!!!!!؟؟؟؟؟؟ 
*Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts.
*Configuration directory partition*: Contains forest-wide data that controls site and replication operations.
*Schema directory partition*: Contains schema definitions for the forest.
*Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain.

بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند:

* Universal groups 
* PDC emulator
* Global Catalog
etc.
  • نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند.

DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟

سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد.

Intra-site Replication

اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند.

  • نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند.

درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند.

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

DC های بویسله پارامترهای زیر Replication را مدیریت می کنند:

* Update Sequence Numbers
* High-watermark values
* UP-TO-Dateness vectors
* Change Stamps
* Polling

برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند.

  • نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند.

Inter-site Replication

این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن.

  • نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند.
معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید:

Designate a Server as a Preferred Bridgehead Server

https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx
  • نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند.

بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که "یک تعقیر بر روی دیگر DC ریپلیکت شود" اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد.

(بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید:

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود:

A to B = 15 min + B to C = 30 min + C to D = 45 min

علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد.

  • نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند.

در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات:

* Account Lockout Policy 
* Domain Password Policy
* RID Master Moving
* Local Security Authority

برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. :////

Understanding Urgent Replication
https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/

همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید.

Site Link

بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال:

* IP or DS-RPC
* SMTP or ISM-SMTP

تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد.

زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند.

Site Link Bridges

یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید:

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد.


  • نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد.
  • نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید.
معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی
    • نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید.
And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site,

یک نمونه از یک ساختار Full Route :

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

یک نمونه از یک ساختار Not Full Route :

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد:

# NYC-TO-SEATTEL
# NYC-TO-CHICAGO
# NYC-TO-MIAMI

اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند.

این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد.

Each site link in a bridge must have at least one site in common with another site link in the bridge.
معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول:

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

خوب به این سه سایت توجه کنید:

  • همه آنها زیر مجموعه یک دومین فعالیت می کنند.
  • همه DC ها نقش GC بر روی آنها فعال شده است.
  • این سه سایت Full Route نیستند.
  • دو عدد Site Link برای ارتباط این سه سایت استفاده شده .

الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟

تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...

چطور!!!!!!؟؟؟؟؟؟

چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند.

سناریوی دوم:

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

چی می بینید؟؟؟؟

  • سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com
  • ساختار Full Route می باشد.
  • DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه.

الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند:

  1. فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها.
  2. غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی.

بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند.

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم.یک سوال مهم چرا ما به Replication نیاز داریم؟در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها: <c#> *Domain directory partition*: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts. *Configuration directory partition*: Contains forest-wide data that controls site and replication operations. *Schema directory partition*: Contains schema definitions for the forest. *Application directory partitions*: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain. <c#> بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند: <c#> * Universal groups * PDC emulator * Global Catalog etc. <c#> * نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند. DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟ سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد. !! Intra-site Replication اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند. * نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند. درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند. ||http://tosinso.com/files/get/2b354d2c-983e-49ea-9c6a-3438fc099d7b|| DC های بویسله پارامترهای زیر Replication را مدیریت می کنند: <c#> * Update Sequence Numbers * High-watermark values * UP-TO-Dateness vectors * Change Stamps * Polling <c#> برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند. * نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند. !! Inter-site Replication این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن. * نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند. ||http://tosinso.com/files/get/c09483ed-c3a5-4510-9b30-4bfc13509bb5|| گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید: <c#> Designate a Server as a Preferred Bridgehead Server https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx <c#> * نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند. بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند. بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که یک تعقیر بر روی دیگر DC ریپلیکت شود اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید). شکل زیر را نکاه کنید: ||http://tosinso.com/files/get/95a1d8d0-d308-441d-ab19-137f155c8c3d|| فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود: <c#> A to B = 15 min + B to C = 30 min + C to D = 45 min <c#> علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد. * نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند. در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات: <c#> * Account Lockout Policy * Domain Password Policy * RID Master Moving * Local Security Authority <c#> برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند. خانمها یک نمونه بارز از این نوع replication هستند. ://// <c#> Understanding Urgent Replication https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/ <c#> همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید. !! Site Link بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال: <c#> * IP or DS-RPC * SMTP or ISM-SMTP <c#> تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود. یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند. !! Site Link Bridges یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید: ||http://tosinso.com/files/get/f87a9160-414b-49d9-acbb-9959fd02bb92|| در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد. * نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد. * نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید. ||http://tosinso.com/files/get/a5d66b44-7868-4aaa-bdff-fb424b7a5c10|| * نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید. <c#> And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site, <c#> یک نمونه از یک ساختار Full Route : ||http://tosinso.com/files/get/5d7c9d78-1ac4-4264-a275-d6e7780812f4|| یک نمونه از یک ساختار Not Full Route : ||http://tosinso.com/files/get/2ba3bef5-ca1d-40b7-a3b0-79a5f856b8e0|| در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟ در بالا سه عدد site link وجود دارد: <c#> # NYC-TO-SEATTEL # NYC-TO-CHICAGO # NYC-TO-MIAMI <c#> اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند. این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد. <c#> Each site link in a bridge must have at least one site in common with another site link in the bridge. <c#> ||http://tosinso.com/files/get/bc5515db-aa0c-4b55-adb1-2670e73fdee1|| خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول: ||http://tosinso.com/files/get/df721741-6f5c-44b7-99c7-bda5141b884b|| خوب به این سه سایت توجه کنید: * همه آنها زیر مجموعه یک دومین فعالیت می کنند. * همه DC ها نقش GC بر روی آنها فعال شده است. * این سه سایت Full Route نیستند. * دو عدد Site Link برای ارتباط این سه سایت استفاده شده . الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ *تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...* !! چطور!!!!!!؟؟؟؟؟؟ چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند. سناریوی دوم: ||http://tosinso.com/files/get/3a991d12-8a74-432e-a19f-b0947d4562be|| چی می بینید؟؟؟؟ * سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com * ساختار Full Route می باشد. * DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه. الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟ این سایتها با دور روش می توانند با هم دیگر Replicate کنند: # فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها. # غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی. بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟ بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند. ||http://tosinso.com/files/get/a041f06a-a0c5-49b9-bf0d-56af78463ffd|| در مقاله بعدی سناریوی که در |اینجا ::http://network.tosinso.com/discussions/60646/%D9%85%D8%B4%DA%A9%D9%84-%D8%B9%D8%AC%DB%8C%D8%A8-replication-%D8%A8%DB%8C%D9%86-%D8%B3%D8%A7%DB%8C%D8%AA%D9%87%D8%A7-%D9%85%D8%AE%D8%AA%D9%84%D9%81!!!!!!#post-1131943|طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش. منابع: <ltr> Managing Replication Between Sites <ltr> <c#> https://technet.microsoft.com/en-us/library/cc961783.aspx <c#> <ltr> AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL) <ltr> <c#> http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/ <c#> <ltr> How Active Directory Replication Topology Works <ltr> <c#> https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx <c#> اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم. موفق و پیروز پاشید. نویسنده: احمد جهلولی

منابع:

Managing Replication Between Sites

https://technet.microsoft.com/en-us/library/cc961783.aspx

AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL)

http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/

How Active Directory Replication Topology Works

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

اخرین مقاله یکی از بهترین مقالاتی هستش که درباره Replication تا حالا خواندم.

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

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

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

نظرات