در ویندوز سرور فرآیند Replication وظیفه بروز رسانی اطلاعات موجود در اکتیودایرکتوری بر روی Domain Controller ها با استفاده از آخرین تغییرات به وجود آمده در سطح دامین را بر عهده دارد. فرآیند Replication علاوه بر اطلاعات موجود در اکتیودایرکتوری ، وظیفه بروز رسانی و یکسان سازی اطلاعات موجود بر روی DNS سرور را نیز بر عهده دارد. همانطور که متوجه شدید این فرآیند یکی از مهمترین فرآیند های موجود در سیستم عامل های ویندوز سرور شرکت مایکروسافت می باشد که بر روی Domain Controller ها فعالیت می کند.
با توجه به اهمیت موضوع Replication زمانیکه این فرآیند دچار مشکل می شود چه اتفاقی در شبکه رخ می دهد ؟ یا فراتر از آن ، شما از کجا متوجه می شوید که این فرآیند دچار اختلال شده است ؟ در این مقاله شما را با روش های شناسایی مشکلات Replication و نحوه رفع این مشکلات آشنا خواهیم کرد.امیدوارم که مورد توجه شما قرار بگیرد.
قبل از اینکه شما بتوانید فرآیند Replication را رفع اشکال کنید ، ابتدا بایستی درک کنید که این فرآیند چگونه کار می کند ؟ همانطور که قبلا هم اشاره کردیم فرآیند Replication برای بروز رسانی و یکپارچه سازی اطلاعات مربوط به DFS بر روی Domain Controller ها استفاده می شود. علاوه بر این ، یک سری وظایف دیگر نیز بر عهده Replication می باشد. با توجه به اینکه عنوان این مقاله رفع اشکال Replication می باشد ، ما نیز صرفا بر روی مبحث Active Directory Replication بین Domain Controller ها متمرکز می شویم و سایر وظایف دیگر Replication را در اینجا پوشش نمی دهیم.
اگر تا به حال با ویندوز سرور NT کار کرده باشید احتمالا با مفاهیم PDC و BDC در خصوص Domain Controller ها آشنایی دارید. در این محیط اگر شخصی اطلاعات موجود بر روی Security Account Manager را بروز رسانی می کرد یا تغییری بر روی آن اعمال می کرد ، این تغییرات ابتدا بر روی PDC که مخفف Primary Domain Controller می باشد ، اعمال می شد ، بعد از آن PDC به BDC ها اعلام می کرد که بیایید و Update های انجام شده بر روی Security Account Manager را دانلود کنید تا اطلاعات شما نیز بروز باشد. این ساختار به عنوان Single Master Replication شناخته می شد.
در مقابل این روش ، در ویندوز سرور 2000 و 2003 ، روشی به نام Multi-master Replication معرفی شد. در Multi-Master Replication دیگر ساختاری به نام PDC و BDC وجود ندارد. هر Domain Controller ای که در مجموعه اکتیودایرکتوری قرار گرفته باشد یک نسخه خواندنی و نوشتنی از پایگاه داده اکتیودایرکتوری را بر روی خود نگه می دارد. اگر یک مدیر سیستم بر روی اکتیودایرکتوری عملی انجام دهد که منجر به بروز رسانی اطلاعات در آن باشد ، این update به سرعت به نزدیکترین Domain Controller موجود اطلاع رسانی می شود تا اطلاعات را یکسان سازی کنند. سپس Domain Controller با استفاده از Replication کاری می کند که سایر Domain Controller ها نیز این update را دریافت کنند.
به دلیل وجود مدل Multi-Master Replication اکتیودایرکتوری به تکنیکی برای شناسایی تداخل ها نیاز دارد. برای مثال فرض کنید که دو مدیر شبکه دارید که هر دو در یک لحظه قصد ویرایش و اعمال تغییرات بر روی یک کاربر مشخص و حتی بر روی یکی از attribute های آن کاربر را دارند ، خوب در اینجا فرض کنید که هر دوی این تغییرات بر روی دو Domain Controller مختلف اعمال می شود ، زمانیکه چخه بعدی فرآیند Replication انجام شود ، شما دو عدد Domain Controller دارید که قصد دارند اطلاعات خود را بر روی Domain Controller دیگری Write کنند.
برای رفع چنین مشکلاتی ویندوز از یک ملاک استفاده می کند ، ملاک برتری در اینجا بروزتر بودن تاریخ و جدیدترین تغییرات اعمال شده است. این بدین معناست که ویندوز به timestamp یا زمانیکه هر دوی تغییرات اعمال شده اند نگاه می کند ، هر کدام از این تغییرات که جدیدتر بود بر روی سایر تغییرات overwrite یا رونویسی می شود. این تغییر آخر بر روی همگی Domain Controller ها اعمال می شود. این مثال را برای این عنوان کردم که چنین موردی را عینا در محیط واقعی دیده ام ، در سازمانی دو مدیر سیستم بودند که هر کدام بصورت جداگانه تغییراتی را بر روی یک کاربر مشخص انجام می داند و تعجب می کردند که چرا این تغییرات ثابت باقی نمی ماند و دچار تغییر می شود.پس اولین قدمی که در خصوص رفع اشکال فرآیند Replication بایستی انجام دهید این است که بررسی کنید که همزمان چندین نفر بر روی یک قسمت مشخص از اشیاء اکتیودایرکتوری کاری انجام ندهند.
یکی دیگر از جنبه هایی که می خوام در خصوص آن نیز صحبت کنم چیزی به نام Inter-site Replication است. Inter-site Replication فرآیند Replication ای است که در بین دو یا بیش از دو سایت در ساختار اکتیودایرکتوری انجام می شود. هدف اصلی و ایده ایجاد Active Directory Site ها به منظور کاهش میزان ترافیک عبوری ناشی از Replication ، از شبکه WAN ای است که در بین Domain Controller ها وجود دارد.تصور کنید که در شرکتی مشغول به کار هستید که دارای دو شعبه ، یکی در تهران و دیگری در شیراز است و ایندو اطلاعات اکتیودایرکتوری خود را از طریق لینک WAN با سرعت پایین خود Replicate می کنند.
در اینجا فرض کنید که یک Object جدید به ساختار اکتیودایرکتوری بر روی Domain Controller تهران اضافه می شود و این تغییر بایستی بر روی Domain Controller ای که در شهر دیگر قرار دارد از طریق لینک ارتباطی WAN در قالب Replication یکپارچه شود ، در اینجا ما فقط دو شعبه را مد نظر داشتیم ، اگر این شرکت در سطح کشور دارای 34 عدد شعبه بوده و به ازای اضافه شدن هر Object این 34 شعبه می بایست update ها را دریافت کنند ، آنوقت از طریق همان لینک WAN مقدار بسیار زیادی ترافیک بایستی صرف بروز رسانی و یکسان سازی اطلاعات موجود در Domain Controller ها شود. در بیشتر اوقات این ترافیک باعث از کار افتادن لینک WAN خواهد شد.
راهکار این قضیه در این است که هر یک از Domain Controller های موجود در این مجموعه را در یک سایت جداگانه قرار می دهیم. در چنین مواقعی هر یک از Domain Controller های موجود در شعب که لینک WAN به آنها متصل شده است به عنوان Bridge Head Server معرفی می شوند ، وظیفه Bridgehead Server این است که بصورت قطعه قطعه update های اکتیودایرکتوری را ارسال و دریافت کند. برای اینکه بهتر متوجه بشوید که Site چگونه کار می کند، بر می گیردیم به همان مثالی که قبلا ذکر کردیم ، فرض کنید 34 عدد Domain Controller در هر شعبه از دفاتر کشور در سطح کشور وجود دارد و با یک لینک WAN به هم متصل شده اند.
خوب در این حالت اگر شخصی یک update بر روی domain controller ای ایجاد کند ، در اینجا شما می توانید برای bridgehead server ها تعیین کنید که Replication را بصورت یکجا انجام ندهند ، در وهله های زمانی معین و با توجه به سرعت پهنای باند موجود Replication را انجام دهند . این روش باعث کاهش حجمه اطلاعات درخواستی برای Replication می شود. از طرفی فرض کنید در هر یک از سایت ها حداقل 3 عدد Domain Controller وجود داشته باشد که بخواهند update ها را دریافت کنند ، به جای اینکه تک تک آنها بروز شوند ، کافیست فقط Bridgehead Server بروز شود و در همان Domain اطلاعات سایر دامین ها را نیز بروز می کند. در این راهکار به جای اینکه یکباره تعداد زیادی update در لینک WAN رد و بدل شوند ، update ها بصورت قطعه قطعه شده رد و بدل می شوند و ترافیک WAN بسیار کاهش می یابد .
هر زمانیکه احساس کردید که یک سری اطلاعات در اکتیودایرکتوری بروز شده است و برای برخی از کاربران که در جای دیگری از طریق Domain Controller دیگری در همان مجموعه بعد از گذشت مدت زمان قابل توجهی ، قابل دسترس نیست ، احتمالا مشکلی در فرآیند Replication بین Domain Controller ها به وجود آمده است .برای مثال ، فرض کنید که یک مدیر شبکه یک کاربر جدید در اکتیودایرکتوری ایجاد می کند ، مدیر سیستم با کاربر مورد تماس میگیرد که بگوید ، کاربر شما ایجاد شده است و شما می توانید هم اکنون وارد سیستم شوید .
بعد از گذشت نیم ساعت کاربر با مدیر سیستم تماس می گیرد و اعلام می کند که نمی تواند وارد سیستم شود و سیستم عامل ویندوز به محض وارد کردن نام کاربری و رمز عبور به کاربر اعلام می کند که حساب کاربری مورد نظر شما در شبکه موجود نمی باشد. مدیر سیستم مجددا سیستم را بررسی می کند و متوجه می شود که حساب کاربری مورد نظر ایجاد شده است و در ساختار اکتیودایرکتوری وجود دارد. در این حالت حساب کاربری ایجاد شده بر روی Domain Controller ای که مدیر سیستم به آن متصل شده است وجود دارد اما به دلیل اینکه فرآیند Replication به درستی انجام نشده است یا دچار اختلال شده است ، در Domain Controller ای که کاربر به آن متصل شده است این حساب کاربری هنوز به وجود نیامده است و از نظر سیستم چنین حساب کاربری وجود ندارد.
اگر شرکت شما فقط چند Domain Controller در یک مجموعه دارد ، مدیر سیستم می تواند به راحتی با استفاده از کنسول Active Directory Users and Computers به Domain Controller مورد نظر متصل شده و بررسی کند که آیا اطلاعات مورد نظر بر روی آن نوشته شده اند یا خیر. برای اینکار کافیست بر روی نام Domain راست کلیک کرده و گزینه Connect To Domain Controller را انتخاب کنیم. در اینجا با مشاهده اسم Domain Controller مشکل دار ، آنرا انتخاب کرده و بررسی می کنیم که آیا اطلاعات آن Replicate شده اند یا خیر.
این تکنیک برای سازمان ها و شرکت هایی که تعداد محدودی Domain Controller دارند کابرد دارد ، اما آیا این روش برای محل هایی که دارای ده ها یا شاید صدها Domain Controller هستند نیز کاربرد دارد ؟ قطعا شما اینقدر هم ساده نیستید که بخواهید با این روش به حداقل 30 عدد Domain Controller متصل شوید و بررسی کنید که Replication انجام شده است یا خیر. بگذریم از اینکه من از این افراد ساده زیاد دیده ام. خوب در اینجاست که شما از ابزاری به نام Replication Monitor در اکتیودایرکتوری استفاده می کنید.
Replication Monitor ابزاری است که به شما می گوید که چه اتفاقی و در کجا در فرآیند Replication رخ داده است. این ابزار به شما اجازه می دهد که بتوانید وضعیت Replication اکتیودایرکتوری را بررسی کرده و همچنین در صورت نیاز فرآیند Replication را برای Domain Controller های خود اجبار یا Force کنید. البته این ابزار در ویندوز سرور 2000 و 2003 بیشتر کاربرد داشت و با توجه به جایگزین شدن این ویندوزها با ویندوز سرور 2008 و بالاتر از آن ، دیگر خبری از وجود این ابزار نبود ، در ویندوز سرور 2008 به جای این ابزار یک ابزار دیگر به نام Replication Administration یا Repadmin.exe جایگزین شد که یک ابزار خط فرمانی و دستوری است که همه کارهایی که Replication Monitor انجام می دهد را پشتیبانی می کند.
Replication Monitor در ویندوز سرور 2003 دارای رابط گرافیکی بود و بصورت پیشفرض نیز بر روی سیستم عامل قرار نداشت ، بلکه شما با استفاده از Support Tools می توانستید این ابزار را نصب کنید . اما ابزار Repadmin.exe در ویندوز سرور 2008 بصورت پیشفرض بر روی سیستم عامل نصب شده است و شما براحتی با وارد شدن به CMD می توانید آن را باز کرده و استفاده کنید. هدف ما در این مقاله بیشتر ویندوز سرور 2008 است .
خوب بر می گردیم به مشکل پیش آمده در بین Domain Controller ها ، وضعیت به این شکل بود که مدیر سیستم یک حساب کاربری ایجاد کرده بود که به دلیل انجام نشدن فرآیند Replication نمی توانست بر روی سیستم خود وارد شود. در این حالت شما می توانید با استفاده از ابزار Replication Administration یا repadmin.exe و اطلاعاتی که خود از ساختار موجود دارید ، متوجه بشوید که کدامیک از سرورهای Domain Controller دارای مشکل می باشند و نمی توانند فرآیند Replication را انجام دهند.
برای مثال مدیر سیستم قطعا متوجه می شود که کدامیک از Domain Controller های می تواند Replication را انجام دهد و اطلاعات را داشته باشد و کدامیک نمی تواند ، کافیست کاربر مورد نظر در Domain Controller ای که بررسی می شود وجود داشته باشد ، اگر وجود داشت پس اطلاعات بروز را دریافت کرده است و اگر وجود نداشت نتوانسته است update ها را بدست بیاورد. همانطور که قبلا هم گفته شد ، نیازی نیست برای بررسی این موضوع حتما به سرور مورد نظر ریموت بزنیم و شما می توانید با استفاده از Connect To Domain Controller اینکار را انجام دهید.
یکی دیگر از نکات مفیدی که می تواند در حل مشکل کمک کند ، دانستن محل فیزیکی قرارگیری کاربر است . با توجه به اینکه کاربر در کدامیک از ساختمان های شرکت یا سازمان قرار گرفته است ، یک مدیر سیستم می تواند متوجه شود که این کاربر از کدامیک از domain controller های موجود استفاده می کند و سایت مورد نظر را بررسی می کند. اما در اینجا فرض را بر این می گذاریم که هر دوی Domain Controller ها در یک سایت قرار گرفته اند بنابراین از این احتمال نمی توانیم استفاده کنیم.
در چنین شرایطی هر Domain Controller ای که در این Site قرار دارد ، Update های خود را به سایر Domain Controller های موجود در سایت ارسال می کند. مدیر سیستم در اینجا حداقل می داند که Domain Controller ای که خود با آن کار می کند فعال است ، طبیعی است که حساب کاربری بر روی آن ایجاد شده است. بنابراین در اینجا پیشنهاد می شود که Replication را ابتدا بر روی این Domain Controller تست کنید. با اینکار می توانید متوجه شوید که کدامیک از Domain Controller های موجود در سایت update ها را دریافت نمی کنند.
اگر نتیجه دستور نشان داد که تمامی domain controller های موجود در مجموعه می توانند updateها را دریافت کنند ، پس ممکن است مشکل از همان Domain Controller ای باشد که مدیر سیستم از آن استفاده می کند. اما بهرحال اگر فقط یکی از Domain Controller ها نتوانست update ها را دریافت کند ، بنابراین مشکل از همان Domain Controller است. برای اینکه بتوانید با استفاده از ابزار repadmin.exe اینکار را انجام دهید مراحل زیر را انجام دهید.در این سناریو ما دو Domain Controller در یک site داریم که به نامهای PDC.itpro.local و SDC.itpro.local می باشند. بر روی PDC یک کاربر اضافه شده است و می خواهیم تست کنیم که آیا فرآیند Replication به درستی انجام می شود یا خیر ، وارد Command Prompt می شویم و دستور زیر را وارد می کنیم.
C:\>Repadmin /showrepl
Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\PDC
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 5d67a4dd-5afb-43db-b617-71fa88f1c265
DSA invocationID: 5d67a4dd-5afb-43db-b617-71fa88f1c265
==== INBOUND NEIGHBORS ======================================
DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:16:21 was successful.
CN=Configuration,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:14:51 was successful.
CN=Schema,CN=Configuration,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:11:18 was successful.
DC=DomainDnsZones,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:11:18 was successful.
DC=ForestDnsZones,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:11:18 was successful.
نتیجه دستور بالا را بررسی می کنیم و به دنبال محل هایی می گردیم که در آنها خطای failed مشاهده می شود و سپس آنها را پیگیری می کنیم ، توجه کنید که در نتایج بالا هیچگونه خطایی مشاهده نمی شود ، حال برای اینکه درک درستی داشته باشید ، بصورت دستی من سرور SDC را از مدار خارج می کنم و مجددا دستور را اجرا می کنیم تا نتیجه را مشاهده کنیم ، نتیجه به شکل زیر خواهد بود.
C:\>Repadmin /showrepl
Repadmin: running command /showrepl against full DC localhost
Default-First-Site-Name\PDC
DSA Options: IS_GC
Site Options: (none)
DSA object GUID: 5d67a4dd-5afb-43db-b617-71fa88f1c265
DSA invocationID: 5d67a4dd-5afb-43db-b617-71fa88f1c265
==== INBOUND NEIGHBORS ======================================
DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:51:38 failed, result 1722 (0x6ba):
The RPC server is unavailable.
1 consecutive failure(s).
Last success @ 2013-07-10 04:21:02.
CN=Configuration,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:51:59 failed, result 1722 (0x6ba):
The RPC server is unavailable.
1 consecutive failure(s).
Last success @ 2013-07-10 04:14:51.
CN=Schema,CN=Configuration,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:52:20 failed, result 1722 (0x6ba):
The RPC server is unavailable.
1 consecutive failure(s).
Last success @ 2013-07-10 04:11:18.
DC=DomainDnsZones,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:51:38 failed, result 1256 (0x4e8):
The remote system is not available. For information about network troubleshooting, see Windows Help.
1 consecutive failure(s).
Last success @ 2013-07-10 04:11:18.
DC=ForestDnsZones,DC=itpro,DC=local
Default-First-Site-Name\SDC via RPC
DSA object GUID: 4c04ff5f-8bb5-4536-bb21-6e177a2c8ece
Last attempt @ 2013-07-10 04:51:38 failed, result 1256 (0x4e8):
The remote system is not available. For information about network troubleshooting, see Windows Help.
1 consecutive failure(s).
Last success @ 2013-07-10 04:11:18.
خوب با توجه به نتیجه دستور بالا متوجه شدید که در فرآیند Replication اشکالی وجود دارد . قدم بعدی رفع ایران به وجود آمده است. در طی سالهایی که در سازمان ها و شرکت های مختلف به عنوان کارشناس و مشاور حضور داشته ام ، تجربه به من می گوید که معمولا مشکلات به وجود آمده در فرآیند Replication به سه مسئله بر می گردد ، اولین مسئله در این است که سرور مورد نظر خاموش است !
دومین مسئله این است که سرور مورد نظر قادر به برقراری ارتباطات شبکه ای با سایر سرورها نیست ، و یا هارد دیسک سرور دچار مشکل شده استیا به قول خودمانی خر تا خر ظرفیت هارد دیسک پر شده است. البته درست است که مشکلات دیگری نیز ممکن است به وجود بیاید که بیشتر در زمینه فرآیند بروز رسانی Domain ها از ویندوز های سرور قبلی به جدید و یا سهل انگاری های مدیر سیستم است اما اهم مشکلات به غیر از این مسائل مرتبط با همان سه مسئله ای است که عنوان کردیم.
اولین پیشنهاد این است که به صورت فیزیکی به محل سرور مورد نظر مراجعه کنید و مبانی اولیه شبکه را بررسی کنید. مطمئن شوید که سرور ظرفیت هارد دیسک مناسبی دارد و پر نشده است. مطمئن شوید که می توانید Domain Controller فعال مجموعه را از این Domain Controller با استفاده از Ping به درستی تست کنید. در بحث Replication خیلی مهم است که سرورها بتوانند ، هم با آدرس IP و هم با اسم همدیگر را در شبکه Ping کنند ، پس همیشه این مورد را بررسی کنید. اگر دیدید که می توانید سرور را با استفاده از آدرس IP پینگ کنید اما نمی توانید با اسم پینگ کنید ، بنابراین ممکن است ماشین مورد نظر نتواند به درستی با سرور DNS ارتباط برقرار کند. مطمئن شوید که تنظیمات TCP IP درست هستند و آدرس DNS سرور درستی به عنوان DNS Server برای این Domain Controller تعیین شده است.
اگر تمامی موارد فوق را بررسی کردید و همگی درستی بودند اما همچنان مشکل Replication شما پابرجاست ، ممکن است مشکل از لینک ارتباطی بین site ها باشد. برای مثال زمانیکه شما Replication را در میان چندین سایت انجام می دهید ، ممکن است Bridgehead سرور شما پردازش زیادی را داشته باشد و نتواند در لحظه پاسخگوی درخواست Replication باشد. اطلاعات بیشتر در خصوص مشکلات خاصی که ممکن است در رابطه با Replication ایجاد شود را به امید خدا در مقاله ای جداگانه بصورت تخصصی بررسی خواهیم کرد. توجه کنید که در این مقاله بیشتر هدف آشنایی با فرآیند Replication و رفع اشکالاتی بود که از جزو تنظیمات داخلی Active Directory نمی باشند. امیدوارم که مورد توجه شما قرار گرفته باشد. ITPro باشید.