16 پاسخ
ممنون دوستان توضیحات بسیار جامعی بود اما یک نکته میمونه اونم اینه که شما فرض کنید سه تا دامین دارید،وقتی یک سایت دارید این سه دامین کلیه یوزرها و کامپیوترهای همو داخل اکتیو دایرکتوریشون به واسطه replication ای که انجام میدن دارن؟ خب این کار اصلا چه فایده ای داره؟ چه لزومی داره بین سایتها replication انجام شه؟مگه دامین کنترلهای سایتها با هم تفاوت نداره؟پس چرا این عمل replication انجام میشه،نکته مبهم دقیقا توی این نقطه هستش
من بعد از ایجاد سایت در domain و تنظیماتش بعد از یک روز سرور exchange دچار مشکل شد. به صورتی که در قسمت ecp بعد از قبول کردن user,pass پیغام bad request نشان داده میشود ,باقی موارد درست کار میکند.
میشه خواهش کنم در زمینه ی اکتیو دایرکتوری چند منبع فارسیه خوب معرفی کنید؟با تشکر
جناب خلیفی میشه این بحث و بیشتر روشن کنید:
اینکه شما میفرمایین به صورت پیش فرض (برای مثال) تمامی سرورها چه در اهواز چه در کرج چه در تهران همه در داخل یک سایت قرار میگیرند، و کلاینت ها برای لاگین کردن به دنبال نزدیکترین سرور میگردند و این و براساس سایت انتخاب میکنن.
مشکل من در انتخاب اینه که کلاینتها براساس سابنتشون تشخیص میدن توی چه سایتی قرار بگیرن؟ منظورتون از (چه سایتی) دقیقا چی هست؟؟ مگه نگفتین که تمامی این سرورها داخل یه سایت درنظر گرفته میشن!! من درست متوجه نشدم اگه لطف کنین واسه من که اطلاعات مایکروسافتی ندارم واضح تر توضیح بدین ممنون میشم
Active Directory Site and Services
به دو جهت از این سرویس استفاده می کنیم :
1. بهینه سازی زمان Authentication که ساختار فیزیکی رو به AD می فهمونیم .
2. بحث Replication هست بین DC ها
دو نوع Replication داریم :
1. IntraSite Replication
انجام Replication بین DC های داخل یک سایت رو می گوییم .
2. InterSite Replication
انجام عمل Replication بین DC های سایتهای متفاوت رو می گوییم .
در واقع در این حالت ادیمن هیچ کنسول مدیریتی دراختیار نداره ، سرویسی داریم تحت عنوان KCC (سرویسی است که توی InterSite Replication کلیه امور مربوط به Replication رو داره کنترل می کند ) که کلیه امور مربوط به Replication و IntraSite Replication رو اون کنترل می کنه .
در InterSite Replication ما کلی Option داریم که از هر سایتی یک DC رو به عنوان نماینده انتخاب می کنه که اون عمل Replication رو به عنوان نماینده انجام بده و اطلاعات رو بده به DC هایی که درون خودش هستن ویا می خواهیم درزمانهای عمل Replication بین سایتهامون انجام نشه این قابلیت در InterSite وجود داره .
در بحث Replication یکسری کارهامون Forest Wide بود یکسری Domain Wide . Forest Wide یعنی اون اطلاعات یا کاره بطور یکسان در کل Forest انجام بشه (اطلاع رسانی بشه) در Replication بعضی از اطلاعات باید به کل DCهای Forest ارسال بشن و بعضی هم باید فقط به DC دامین خودمون ارسال و Replication بشه به همین دلیل دیتا بیس اکتیو دایرکتوری رو به قسمتهایی Logical تقسیم می کنیم که حین عمل Replication ، DC ها اطلاع داشته باشن که هر تیکه ای از اطلاعات رو به کجا و کیا بفرستن ، اصطلاحا بین این تقسیم بندیها Partition می گوییم.
Information Replication
(اطلاعاتی که در هر Replication ردوبدل میشه)
1. Schema Partition
الگوی اطلاعاتی رو مشخص می کنه که می توانند درون دیتا بیس اکتیو دایرکتوری ثبت و نگهداری شوند Forest Wide ، Replication می شود .
2. Configuration Partition
Logical Structure ، Forest ما رو مشخص می کند مثلا Tree Root دامین کی هست ؟ این Tree Root چندتا Child داره ؟ و یا چندتا Tree Root در مجموعه امون وجود داره ، اینم Forest Wide ، Replication می شود .
3. Domain Partition
حاوی تمامی Objectهای دامین خودمون هست Objectهای که درون کنسول DSA.MSC وجود داره می تونیم ببینیم . Userها ، گروه ها ، OU ها ، پالیسی هایی که Set کردیم. Domain Wide ، Replication می شه.
توجه داشته باشین که بطور پیش فرض کل ساختار Logical ما یعنی Forest،Tree،Domain که نصب کردیم تماما داخل یک Default Site قرار می گیره حال اگر اینها از نظر ما قرار درسایتهای مختلف کار بکنند باید خودمون بیاییم Site Management رو انجام بدیم و Site ایجاد کنیم و مشخص کنیم چه client و Serverهایی توی این سایت دارن کار می کنند.
Site Link
در واقع یک ارتباط منطقی Logical Relationship هست که بین سایتهایی برقرار میشه که ارتباط فیزیکی دارن و می توانند Replication رو با هم انجام بدن .
به طور پیش فرض خاصیت Transitive ، سایتها Enable هست ( در اینجا AD فکر می کنه Site B و Site C با هم ارتباط دارن که غلط هست )
ما در این حالت باید این خاصیت رو از Link هامون برداریم .
Site Link Bridge
یک پل ارتباطی هست بین سایتهای که با هم ارتباط فیزیکی ندارن و قرار است از طریق یک سایت دیگر Replication بین DC هاشون انجام بشه .
Bridgehead Server
در بحث Inter Site Replication باید از هر سایتی یک نماینده معرفی کنیم که عمل Replication رو با نماینده سایتهای دیگر انجام بده و اطلاعات رو بگیره و به DC های سایت خودش بده .
حال به دو صورت Bridge Head Server رو مشخص می کنیم :
1. Manual
که Admin به طور دستی مشخص می کند و اگر DC1 از کار افتاد باز ادمین هست که باید حواسش جمع باشه و یک DC دیگر رو به عنوان نماینده Bridge Head Server مشخص کنه .
2. توسط سرویس KCC (Recommend)
توسط این سرویس Bridge Head Server انتخاب میشه و اگر Bridge Head Server از کاربیفته خود KCC یک سرور دیگرو به طور اتوماتیک انتخاب می کنه .
دوست عزیز فکر میکنم تا ایجاد دیگه مشکلی با مفهوم سایت نداشته باشی ، تعریف مایکروسافت از سایت این هست مجموعه ای از کامپیوترهای متصل به هم که با استفاده از لینک های ارتباطی با سرعت بالا به هم متصل شده اند برای مثال در یک شبکه LAN قرار دارند.به این مثال توجه کن ، شما تصور کن که یک شرکت داری که دفتر مرکزیش در تهران هست و 24 شعبه در کلیه شهرستان های ایران داره ، این شرکت یک Domain Controller داره که مشابهش باید در هر شهرستان وجود داشته باشه تا کاربرایی که از هر شهری به شکل ماموریتی به شهر دیگه میرن بتونن در اونجا وارد سیستم بشن ، اینها Domain های متفاوتی نیستن بلکه یک Domain هست که توزیع شده بین شهرستان ها و طبیعی هست که هر شهرستان برای خودش باید یک Domain Controller داشته باشه .
خوب تصور کن هر شهری برای خودش دو تا Domain Controller داره که توسط Link شبکه WAN به شهرهای دیگه و توسط کابل شبکه به Domain Controller دیگه تو همون شهر متصل هست.حالا تصور کن که یک Object به اکتیودایرکتوری یک شهرستان اضافه میشه ، با توجه به یکپارچه بودن پایگاه داده باید این Object بین تمامی Domain Controller های موجود در شبکه Replicate بشه اما خوب چون شبکه WAN هست و پهنای باند ما محدود هست قطعا میتونه باعث بالا رفتن ترافیک بشه ، اما خوب همین Object در همون شبکه براحتی و بدون وقفه میتونه با اونیکی Domain Controller موجود اطلاعاتش رو Replicate کنه چون داخل یک شبکه داخلی هستند و پهنای باند چندان براش مهم نیست.
اینکه Domain Controller از کجا میفهمه باید اطلاعات رو برای Replication نگه داره تا در زمان باز شدن پهنای باند اطلاعات رو به کنترلرهای دیگه انتقال بده و یا اینکه صبر نکنه و به این کنترلری که در شبکه خودش هست بلافاصله اطلاعات رو بده به دلیل طراحی سایت هست . این Site هست که میگه عزی من صبر کن شما پهنای باندت ضعیفه باید صبر کنی فلان ساعت Replicate کنی و یا اینکه نمیخاد صبر کنی این سرور در شبکه داخلی ما هست و سرعت مناسبه میتونی Replicate کنی رو سایت تعریف میکنه . سایت همونطوری که قبلا هم گفتم در محیط هایی معنا میشه که شما شبکه گسترده ای دارید که Subnetting انجام شده و با لینک WAN به هم متصل شدن و سرورها باید با هم Replicate کنن ، در یک شبکه Site چندان معنی نداره . به تصاویری که برات گذاشتم دقت کن .
به تصویر بالا دقت کنید ، سایت Seattle و سایت Los Angeles هر دو یک Domain منطقی هستند اما دارای چندین Domain Controller هستن که باید اطلاعات رو با هم Replicate کنن ، خوب با استفاده از تعریف سایت میتونیم بین اینها تعیین کنیم در چه زمانی و با چه لینکی Replicate انجام بشه ، حالا این Site ها طبیعتا دارای محدوده IP متفاوتی هستند ، فرض کن شما یم Domain Controller جدید به Site در Seattle اضافه می کنی ، این Domain Controller از طریق تعریف Subnet ای که در Site and Services براش انجام شده متوجه میشه که محل فیزیکیش Seattle هست و نه Los Angeles ، امیدوارم ابهامت برطرف شده باشه ، موفق باشید.
Site برا جدا کردن فیزیکی به کار میره....در حالی که Domain برای جدا کردن منطقی به کار میره.
برای مثال شما یک parent domain دارین به اسم itpro.local که در کرج هستش. شما 2 تا child domain تو شهرهای تهران و اهواز اضافه می کنید. به صورت پیش فرض، تمامی server ها داخل یک سایت قرار میگیرن. چه سرورهایی که در کرج هستن و چه server هایی که در تهران و یا اهواز هستن.
حالا چه اتفاقی میفته؟
تمامی این server ها با هم replicate میکنن. در حالی که نیاز نیست اینطور باشه. نکته اینجاست که replication مابین تمامی DC های داخل یک site انجام میشه و اینکه client ها برای login کردن، به دنبال نزدیکترین server میگردن. client ها نزدیکترین server رو بر اساس site انتخاب می کنن. اینکه client ها داخل چه سایتی قرار بگیرن، این رو از روی تنظیمات subnetی که داخلش قرار دارن، تشخیص میدن.
سایت 3 تا مزیت داره:
1. Active Directory تعداد دفعات خیلی بیشتری درون یک site کار replication رو انجام میده، در حالی که replication بین site ها به مراتب کمتر انجام میشه. به علاوه شما میتونین تنظیمات مختلفی برای replication مابین site ها انجام بدین. این ویژگی باعث میشه که شما پهنای باند بیشتری برای انجام بقیه کارها داشته باشین (مانند سناریوی بالا)
2. درست انجام شدن تنظیمات Site باعث میشه که عمل Authenticate شدن client ها سریعتر انجام بشه. وقتی کلاینت به دامین login میکنه، اول در درون site خودش به دنبال domain controller میگرده. اگر شما چندین site در ساختار active directory خودتون داشته باشین، میتونین اطمینان حاصل کنین که client ها با نزدیکترین domain controller کار autnentication رو انجام میدن که این، زمان authentication رو کم میکنه و ترافیک روی ارتباط WAN شما رو کاهش میده.
3. با توجه به اینکه تمام server های داخل یک دامین درون site خودشون فرار میگیرن (با در نظر گرفتن این نکته که از یک subnet استفاده می کنن)، کلاینت ها در زمان کمتری میتونن server ها و service های وابسته به active directory رو پیدا کنن.
ساختار اکتیودایرکتوری به دو دسته بصورت کلی تقسیم میشه ، ساختار منطقی یا Logical که به مفاهیمی مثل Domain و Tree و Forest اشاره می کنه ، این ساختارهای منطقی قابل لمس نیستند و بصورت فیزیکی وجود ندارند . دسته بندی ساختاری دوم به ساختار فیزیکی یا Physical Structure معروف هست و به مفاهیمی مثل Server و Site اطلاق میشه ، این ساختار اکتیودایرکتوری برای انسان قابل لمس هست و بصورت فیزیکی وجود داره ، شما هر تعریفی که در نهایت از ساختار های اکتیودایرکتوری یا چیزی مشابه اون داشته باشید بایستی بر روی یک محیط فیزیکی قرار بگیره که در اینجا اسمش Site هست.
قطعا شما با خودتون الان میگید اگر بحث فیزیکی هست پس چرا در اکتیودایرکتوری ما قسمت به نام Site and Services رو داریم ؟ در اصل مفهوم سایت در محیط های تک دامینی که دارای شعبه یا شبکه WAN نیستند درست درک نمیشه ، ببینید ساختار سایت به شما این اجاره رو میده که وهله های زمانی Replication بین دامین کنترلرها رو با توجه به سرعت لینک ارتباطی بین سایت ها تعیین کنید ، شما با استفاده از Site در اکتیودایرکتوری میتونید تعیین کنید که یک سرور در شهرستان قرار داره یا در مرکز داده اصلی که اینکار به وسیله تنظیمات Subnet و IP انجام میشه که در کنسول Site and Services وجود داره ، برای مثال شما می تونید یک سایت تهران و یک سایت شیراز رو در این کنسول ایجاد کنید ، برای هر کدم یک Subnet مشخص کنید ، اگر دارای شبکه WAN بین این دو استان باشید به محضی اینکه Domain Controller ای به این مجموعه اضافه بشه با توجه به Subnet ای که درش هست در محل مورد نظر بصورت خودکار برای Replication قرار میگیره ، باز اگر ابهامی بود بپرسید.
آقای ملکی، لطفا سوال خودتون رو در قالب یه تاپیک جدید مطرح کنید. با تشکر
بله درسته !
آیا این درست است ؟
اگر در شرکت مرکزی تغییراتی در اکتیودایرکتوری انجام شود ، این تغییرات پس از Replication ، با کانال ارتباطی WAN به یکی از سرور های سایت های دیگر ( در شهر های دیگر ) منتقل میشود.
و کار انتقال از طریق WAN تمام میشود و ترافیک آزاد میشود.
سپس سروری که این تغییرات را دریافت کرده ( با توجه به نوع شبکه و مسیر انتقال خود ) آن ها را به سرور هایی که در سایت خودش هستند میفرستد.
سلام، در قسمت سابنت، فقط آی پی سرورهای DC باید اضافه شوند یا تمام IP های کاربران هم باید به سایت اضافه شوند؟ فرض کنید سرورها و کاربران در سابنت های متفاوتی باشند.