Replication در اکتیو دایرکتوری

معمولا در محیط اکتیو دایرکتوری بیش از یک Domain Controller وجود دارد. ساده ترین روش برای بالابردن Availability سرویس نیز راه اندازی چند DC است. ممکن است که تمام سرور ها در Data Center سازمان باشد، یعنی جایی که ارتباطات شبکه بسیار پر سرعت هستند، همچنین ممکن است سرور ها در کشور های متمایزی باشند که معمولا در این حالت سرعت link نا کافی است. بدون توجه به تعداد DC ها و مکان آن ها باید DCها دارای اطلاعات یکسانی باشند در غیر این صورت، دایرکتوری روی دامین کنترلر ها شامل برخی اشیاء و یا به روز رسانی های آن ها نخواهد بود. در اینجا فرآِیند یکسان سازی اطلاعات بین دامین کنترلر ها و مدیریت بر آن توضیح داده می شود. به صورت پیش فرض پس از راه اندازی چند DC آن ها شروع به Replication (همسان سازی) با یکدیگر می کنند. ممکن است موثر ترین توپولوژی Replication توپولوژی نباشد که به صورت پیش فرض انجام می شود. همانطوری که پیش تر در بحث operation masters گفته شد، role هایی وجود دارد که تنها روی یک DC می توانند در واحد زمان عمل کنند که این هم One Point of failure ایجاد می کند، اما می توان در شرایط بحرانی role ها را seize (مصادره) کرد و role را به DC دیگر اختصاص داد.

همانطور که پیش تر گفته شد، Active Directory Domain Services شامل پارتیشن هایی منطقی از اطلاعات است که هر کدام حاوی اطلاعات خاصی اند. Replication (همسان سازی) برای تمام پارتیشن ها یک متد دارد. به عنوان مثال زمانی که یک Attribute (ویژگی) در Configuration Directory تغییر کند، آن تغییر با همان متدی که هر attribute دیگری در هر پارتیشن دیگری تغییر کند Replicate می شود. مسئله ای که متغییر است لیست دامین کنترلر هایی است که لیست تغییرات را دریافت می کنند.همچنین متد Replication برای دامین کنترلر های در یک سایت، با دامین کنترلر هایی که در سایت های متمایز قرار دارند متفاوت است. AD DS از یک متد چند اصلی (Multi Master) برای Replication استفاده می کند. نتیجه آن است که تغییرات می توانند روی هر DC در محیط AD اعمال شوند و نتیجه آن ها با هم اعمال خواهند شد. در این متد از ابزار های ساده ای همچون زمان، ورژن تا ابزار هایی پیچیده استفاده شده تا Replication به بهترین صورت انجام شود.

متد  Replication در بازه های زمانی معینی یک بخشی Replica را برای برخی از DC ها ارسال می کنند، این سبب می شود تا فرآیند Replication تا حدودی ازدست دادنی باشد. به عبارتی آسان شده، Replica به کپی اسناد مربوط به AD DS گفته می شود. از دست دادنی به این معنا که تغییرات تا سیکل بعدی Replication طول می کشد که در سایر DC ها اعمال شوند و این مشروط به انجام عمل Replication در زمان خود است. همچنین متد Replication از نوعی فرآیند Store & Forward استفاده می کند، به این معنی که یک DC می تواند یک Replica را دریافت کند و آن را برای DC دیگر Forward کند.

Replication همچنین از یک متد State-Based نیز بهره می برد. این به این معنی است که هر DC وضعیت Replication را زیر نظر می گیرد. زمانی که یک DC  تغییراتی را دریافت می کند، چه مستقیما چه از طریق Replication، آن را در Replica خود از AD به روز می کند. DC دیگری که تغییرات را دریافت می کند با استفاده از Meta Data های موجود، اطلاعات تکراری دریافت نمی شوند و هچنین از بروز Conflicts ممانعت به عمل می آید. همچنین با استفاده از این متد دیگری نیازی نیست که تمام Replica موجود در DC برای Replication ارسال شود و صرفا به روز رسانی ها ارسال می شود. تمام مسائل گفته شده زمانی بیشتر خودنمایی می کنند که در یک Forest چند دامینی، چندین دامین مختلف در سایت های مختلف وجود داشته باشند. در این شرایط تحلیل وضعیت Replication به سادگی صورت نمی گیرد.

تصور کنید که در DC1 تغییری صورت گیرد، با استفاده از Replication، آن تغییر برای DC2 و DC3 ارسالی می شود. به دلیل متد Store and forward ممکن است DC2 ضمن به روز کردن Replica تغییرات را برای DC3 نیز ارسال کند. توپولوژی Replication می تواند تضمین کند که Replication به موثر ترین صورت ممکن انجام شود. Replication در Windows Server 2000 بسیار ساده بود و تمام قابلیت های امروز را دارا نبود. در Windows Server 2003 متدها کاملا بازبینی و بازطراحی شدند و تغییرات نا چیزی در Windows Server 2008 پیدا کرد.

انواع به روز رسانی ها

دو نوع به روز رسانی ممکن است صورت گیرد. نوع اول آپدیت هایی است که از خود دامین کنترلر ایجاد می شوند. به عنوان مثال زمانی که یم شیئ ساخته، ویرایش، پاک می شود. دسته دوم به روز رسانی هایی است که توسط Replication از یک دامین کنترلر دیگر انجام می شود. آپدیت هایی که از خود دامین کنترلر ایجاد می شوند؛ چهار دسته اند:

۱٫ یک شیئ جدید به AD DS اضافه می شود: اضافه شدن یک شیئ جدید با Object GUID یکتا قابل تشخیص است. تمام ویژگی های مرتبط آن دارای Version number=1 می شوند.

۲٫ یک شیئ پاک شده از AD DS: زمانی که یک شیئ پاک می شود، بلادرنگ پاک نمی شود بلکه در ابتدا برچسب Deleted می خورد. پس از گذشت از مرحله tombstone (سنگ قبر) در واقع آن شیئ حذف می گردد.

۳٫ ویژگی (Attribute) های یک شیئ موجود ویرایش یابد: در هر ویرایش Version Number مربوط به آن attribute یک واحد اضافه می شود.

۴٫ جا به جایی یک شیئ: تنها Attribute به نام name تغییر می کند و با به روز شدن در ساختار سلسله مراتبی در واقع شیئ جا به جا شده است.

به صورت پیش فرض، در یک سایت پس از یک به روز رسانی، دامین کنترلر ۱۵ ثانیه برای ارسال به روز رسانی ها صبر می کند تا اگر تغییرات دیگری نیز در راه است آن ها را در یک مرحله Replicate کند. اما در سایت ها این امر بستگی به Schedule ای که روی لینک تنظیم شده است وابسته است. برای آنکه Replication موثر انجام شود باید تنها تغییراتی که لازم است بین دو دامین کنترلر Replicate شود. AD DS در متد Replication خود از ترکیبی از عناصر Update Sequence numbers یا USN و high-Watermark و uptodateness vectors و stamps استفاده می کند. در ادامه این عناصر به تفکیک مورد بررسی قرار می گیرند.

Update Sequence Numbers

زمانی که یک شیئ در Directory به روز شود، یک شماره ی USN به آن به روز رسانی اختصاص می یابد. USN توسط خود دامین کنترلری که تغییر در آن ایجاد شده (نشات گرفته) تخصیص می یابد. بدیهی است اگر در به روز رسانی تعدادی از Attribute های یک object تغییر کند، دارای یک شماره USN برای آن به روز رسانی است. سه روش متمایز برای استفاده از USN وجود دارد. نخست، Local USN که همراه با به روز رسانی attributes ذخیره می شود. دوم، برای تغییر ویژگی USNChanged مربوط به یک Object است. این USN همراه با هر Object ذخیره می شود و حاوی بزرگترین USN مربوط به attribute های آن است. این دو USN برای تمام تغییرات محاسبه می شود. هم تغییراتی که توسط Replication انجام می شود و هم تغییراتی که در خود DC مستقیما اعمال می شوند یا به اصطلاح نشات می گیرند. سوم، USN ای است که تنها روی سروری که تغییرات در آن ایجاد شده( نشات گرفته) اعمال می شود. این USN ها در attribute های replication قرار می گیرند. USN ها در موارد ۱ و ۲ در هر DC بر اساس USN های خودشان ویرایش می شوند، اما مورد صوم بدون تغییر باقی می ماند.

به عنوان مثال، زمانی که شماره تلفن یک کاربر را روی یکی از DC ها تغییر می دهیم، اگر آخرین USN ای که در همان DC استفاده شده، ۷۷۷۷ باشد، USN  ای که برای ذخیره به همراه attribute انتخاب می شود ۷۷۷۸ خواهد بود. همچنین USNChange برای آن شیئ کاربر برابر ۷۷۷۸ می شود (اگر تغییر دیگری صورت نگیرد).

برای مشاهده ی USN ها در کنسول  Active Directory Users and Computers لازم است Advanced Features را فعال کنید. سپس در Tab (زبانه) Object مربوط به Properties مربوط به Object مورد نظر می توانید USN ها مشاهده کنید. به یاد داشته باشید که USN ها یکتا در دامین نیستند. همچنین می توانید از دستور زیر برای مشاهده ی تمام MetaData های مربوط به یک Object استفاده کنید.

repadmin /showobjectmeta DCName ObjectDN

همچنین با استفاده از ابزار LDP می توانید به اطلاعات فوق دسترسی پیدا کنید. برای انی منظور، یک DC را bind کنید و سپس Object مورد نظر را بیابید. روی آن کلیک راست کنید و Advanced را بزنید. Replication Meta Data را انتخاب کنید.

High-Watermark Values

High-Watermark Values برای مدیریت اطلاعاتی که بین DCها Replicate شده به کار می رود. هر DC مقادیر مربوط به DCهایی که عمل Replication را به صورت مستقیم با آن ها انجام می دهند، نگه داری می کند. مقدار آن در واقع آخرین USNChanged مربوط به هر Directory Partition در دامین کنترلر دیگر است. زمانی که یک DC به روز رسانی ها را ارسال می کند حاوی USNChanged است و DC دریافت کننده، آن را به نام High-WaterMark Value نگه داری می کند. این مقدار در Replication های بعدی مورد استفاده قرار می گیرد چرا که DCی منبع آگاه می شود که چه Update هایی باید ارسال شود و از ارسال تمام Replica به این صورت جلوگیری به عمل می آید.

Up-To-Dateness Vectors

up-to-dateness Vectors نیز برای کنترل اطلاعات انتقال یافته بین دامین کنترلر ها استفاده می شود. این بردارها برای ردگیری به روز رسانی های نشات گرفته شده به کار می رود. به عنوان مثال شماره تلفن کاربری در DC1 تغییر داده می شود و این تغییر دارای USN با مقدار ۵۵۵۶ می شود. پس از Replication با DC2 این مقادیر تغییر می یابند. همچنین GUID مربوط به Server نیز تغییر می یابد. اما زمانی که DC2 به روز رسانی را دریافت می کند، Up-To-Dateness Vector را به روز می کند تا معین شود این به روز رسانی از DC1 دریافت شده و آخرین USN برابر ۵۵۵۶ است. زمانی که یک DC مقصد تقاضای به روز رسانی از یک DC منبع دیگر دارد، DC منبع ابتدا اطلاعات را بر این اساس فیلتر می کند. این ویژگی بسیار دارای اهمیت است زمانی که بیش از دو دامین کنترلر در یک دامین موجود باشد. به عنوان مثال DC3 به سناریوی بالا اضافه می شود و پس از Replication هر دو DC2 و DC3 به روز رسانی را خواهند داشت و up-to-dateness vector را ویرایش می کنند که آخرین آپدیتشان مربوط به ۵۵۵۶ از DC1 است.پس از ۱۵ ثانیه بعد، DC2 دامین کنترلر دیگر یعنی DC3 را آگاه می سازد که یک به روز رسانی دارد و زمانی که DC3 به روز رسانی را درخواست می کند، با درخواست up-to-dateness vector را نیز ارسال می کند از آنجایی که DC2 آخرین آپدیت خود را با آخرین آپدیت DC3 مقایسه می کند، به DC3 اعلام می کند که هر دو یک ورژن دارند. به فرآیندی که در آن Replication توسط up-to-dateness vectors فیلتر و محدود می شود، propagation dampening گفته می شود. با استفاده از این طراحی، در واقع Replication به صورت Redundant انجام می شود. این یکی از مهمترین ویژگی های Replication در دایرکتوری مایکروسافت است.

یکی از مشکلات مربوط به اسختن لینک های redundant است. یک به روز رسانی در این حالت ممکن است از طریق لینک های مختلف در دفعات متعدد به یک دامین کنترلر از طریق DC های مختلف برسد. این امر سبب انتقال ترافیکی قابل توجه و بی فایده می شود. همچنین مشکل به وجود آمدن یک loop وجود دارد که با استفاده از up-to-dateness vectors این مسئله نیز بر طرف می شود. هرچند up-to-dateness vectors و High-Watermark Values ارسال اطلاعات را محدود و فیلتر می کنند، اما همچنان مشکلاتی پا برجا است.

Change Stamps

آخرین عنصری که در Replication نقش ایفا می کنند، مهرهای تغییرات یا Change Stamps ها هستند. هر زمانی که یک attribute تغییر یابد، این تغییر با استفاده از یک Change Stamp مشخص می گردد. این Change Stamp با Replication به تمام دامین کنترلر های دیگر ارسال می شود. این Stamp در صورتی که Conflict (تداخل) رخ دهد، مشخص می کند که کدام به روز رسانی باید اعمال شود. برخی از منابع از واژه ی Collision به جای Conflict (تصادم) نیز استفاده کردند. Change Stamp دارای سه عنصر است:

۱٫ Version Number: برای ردیابی تعداد تغییراتی که برای یک Attribute رخ داده است. زمانی که شیئ ساخته می شود، Version Number برای تمام Attribute های خالی از مقدار آن برابر صفر است. اگر آن  attribute مقداری در همان ابتدا پیدا کند، مقدار آن یک خواهد بود. برای تغییرات بعدی، Version Number یک واحد اضافه می شود.

۲٫ Last Write time: آخرین زمانی که یک Attribute ویرایش می شود.

۳٫ Server GUID: برای ردیابی سروری که در آن تغییرات نشات گرفته، GUID آن سرور درج می شود.

هر چند این اتفاق بسیار نادر است، اما ترتیب تصمیم گیری اکتیو دایرکتوری برای Attribute هایی که در یک سیکل Replication در دو DC ویرایش شده اند، به صورت زیر است:

۱٫ Version Number: تغییری که دارای بالاترین Version Number باشد. اگر برابر باشد، مرحله ۲ انجام می شود.

۲٫ last Write Time: تغییری که دیرتر باشد، اگر برابر باشد، مرحله ۳ انجام می شود.

۳٫ Server GUID: تغییری که مربوط به DC ای است که دارای GUID بزرگتر است. GUID یکتا است و در زمانی که دامین کنترلر به دامین اضافه می شود، تخصیص می یابد.

با استفاده از Changes Stamps، مسئله Conflict برای تغییراتی که روی دو دامین کنترلر در یک سیکل برای یک attribute خاص پیش می آید بر طرف می شود، اما یا این حال همچنان دو دسته مشکلات دیگر وجود دارند:

۱٫ ویرایش یک Object در یک دامین کنترلر در زمانی که در دامین کنترلر دیگر، Container آن Object پاک شده است.به عنوان مثال یک User جدید در Accounting OU در یک DC ساخته می شود و در DC دیگر Accounting OU  حذف می شود. در این شرایط OU حذف شده و Object به Container به نام Lost and Found منتقل می شود.

۲٫ افزودن یک Object با همان DN: به عنوان مثلا یک مدیر شبکه در Management OU یک User به نام Bill می سازد و مدیر شبکه ی دیگری، در DC دیگر همان User را می سازد و یا آن را منتقل می کند. در این شرایط Object ای که دارای GUID بزرگتری باشد، با همان نام ساخته و Object ای که دارای GUIDی کمتری باشد، با تغییر نام می یابد و GUID آن به نامش اضافه می شود. در این حالت می توان آن شیئ تغییر نام یافته را پاک یا ویرایش نمود.

پاک شدن اشیاء

همانطور که پیش تر اشاره شد، نحوه به روز رسانی پاک شدن اشیا از سایر به روز رسانی ها متمایز است. در واقع زمانی که شیئ پاک می شود، آن شیئ بلافاصله پاک نمی شود. ابتدا یک attribute به نام isDeleted برای آن Object برابر ۱ می شود و بیشتر attribute های دیگر آن خالی (blank) می شوند و برخی از Attributeهای دیگر همچون GUID یا SID باقی می مانند. اشیاء حذف شده در یک Container مخفی به نام Deleted قرار می گیرند. به این شیئ tombstone در اصطلاح گفته می شود.برای مشاهده آن اشیاء پاک شده می توان از ابزار LDP یا ابزار های مشابه استفاده کرد. tombstone lifetime به مدت زمانی گفته می شود که یک tombstone در دایرکتوری باقی می ماند. این مدت زمان به صورت پیش فرض ۱۸۰ روز است. به فرآیندی که در آن tombstone هایی که lifetime آنها سپری شده پاک می شوند garbage collection گفته می شود که به صورت پیش فرض، هر ۱۲ساعت یک بار در سراسر Forest انجام می شود. توجه داشته باشید که tombstone lifetime در نسخه های مختلف ویندوز متفاوت بوده است. در Windows Server 2003 برابر ۶۰ روز، Windows Server 2003 SP1 برابر ۱۸۰ روز و Windows Server 2003 R2 برابر ۶۰ روز است. اگر از یک دامین با ۶۰ روز دامین را ارتقا داده باشید، آن زمان باقی خواهد ماند.Linked attributes شرایط خاصی را در پاک کردن اشیاء ایجاد می کنند که در آن تمام Forward Links ها و back Links ها پاک می شود.

Replicate شدن SYSVOL

AD DS data store همانطوری که پیش تر گفته شد Replicate می شود اما Sysvol نیز شامل اطلاعاتی حیاتی برای AD DS است. Sysvol شاما اطلاعاتی همچون Group Policy و Config.pol و NTconfig.Pol است. اگر Functional Level دامین Windows Server 2003 یا پایین تر باشد، مسئولیت Replication با File Replication Service یا FRS است. اگر Functional Level دامین Windows Sever 2008 باشد، Distributer File System Replication این مسئولیت را به عهده خواهد داشت. DFSR از الگوریتم فشرده سازی RDC استفاده می کند بنابراین ترافیک را کاهش می دهد.

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