Related Articles
پیش از این در خصوص ساختار اکتیو دایرکتوری صحبت کردیم، یکی از مهمترین اجزاء این ساختار سایت ها هستند. برنامه ریزی سایت ها بسیار حساس است و با دقت خاصی باید انجام شود. در اینجا برخی از این مسائل را بررسی می کنیم. برای بیشتر مدیران، سایت یک بخش فیزیکی از زیرساخت شبکه است. به عنوان مثال از دفتر سازمان در یک شهر گرفته تا طبقه ای از یک ساختمان. سایت ها از طریق یک لینک به سایر بخش های شبکه متصل است. ممکن است برای ارتباط سایت ها از چند لینک مختلف استفاده شود و لینک ها هم می توانند به سادگی یک Dial-up باشند یا می توانند ارتباط بی سیم، ارتباط از طریق ماهواره یا فیبر نوری باشند. بدون توجه به آنکه یک لینک با چه زیرساختی ایجاد می شود، زیرساخت شبکه در ساختار اکتیو دایرکتوری دارای اهمیت است. در هر شرایط باید راهکارهایی را اتخاذ کرد که بیشترین اثر بخشی را در مدیریت ترافیک داشته باشند.
در واقع یک سایت دسته ای از IP subnet ها است. معمولا در یک سایت از تکنولوژی های ارتباطی LAN بهره می بریم و با استفاده از تکنولوژی های ارتباطی MAN یا WAN به یک سایت دیگر متصل می شویم. لینک ارتباطی MAN یا WAN بین دو سایت را Site Link می گوییم. با اینکه دو واژه ی Site و Site Link معنای کاملا متفاوتی دارد به اشتباه برخی به جای همدیگر به کار می برند که باید از آن پرهیز کرد. گاها گفته می شود مرزهای یک سایت مرزهای یک LAN است که با یک WAN به یک LAN دیگر متصل است. هر چند بیان درست است اما این سناریوی متداول است و همواره یک سایت چنین شرایطی را ندارد. حتی الزاما یک Site Link با استفاده از WAN Technology نیست. در سناریو های متفاوتی می توان از سایت ها استفاده کرد. امروزه Trust ها در سایت ها بی اثر اند، اما ممکن است در آینده امکان ایجاد Trust بین دو سایت ایجاد شود هر چند پروتکل های مورد استفاده در اکتیو دایرکتوری امروز این مسئله را قدری دور از ذهن می کنند. همچنین سایت ها به دامین ها هیچ ربطی ندارند. در واقع این جمله برای تاکید بیشتر روی مسئله ی آنکه یک سایت می تواند شامل چند دامین باشد و یا یا دامین می تواند شامل چند سایت باشد نوشتم.
معمولا لینک های با سرعت پایین تر از ۵۱۲ Kbps لینک کم سرعت در نظر گرفته می شوند. هر چند از آنجایی که اکثر خطوط بین شهری و خطوط شهری به صورت اجاره ای از شرکت های مخابراتی است، هنوز خطوط کم سرعت متداول ترند. لینک های بین شهری اغلب کیفیت ارتباطی بالایی ندارند لذا باید در مدیریت لینک ها دقیق عمل کرد. مسئله دیگر هزینه استفاده از خطوط است. گاهی شرکت های مخابراتی در ازای ترافیک هزینه دریافت می کنند و یا ممکن است حجمی رایگان باشد و بیش از آن مستلزم پرداخت مبلغی باشد. در این خصوص نیز باید دقت شود که لینک ارزان قیمت تر، کم ترافیک تر و… در اولویت است. فاکتوری به نام COST را برای مدیریت لینک ها در اختیار داریم. لینکی که دارای COST کمتری است در اولویت قرار خواهد داشت. با توجه به این مسئله دو عامل بزرگترین انگیزه برای ایجاد سایت ها است:
ترافیک replication :
Replication منتقل کردن تغییرات رخ داده روی دامین کنترلر ها است. به عنوان مثال زمانی که یک User جدید ایجاد می شود، این کاربر باید روی دامین کنترلر های دیگر نیز ساخته شود. بنابراین این امر ترافیکی را در شبکه ایجاد می کند. این ترافیک دو نوع مختلف دارد. از لحاظ تئوری برخی تغییرات در زمان اتفاق افتادنشان باید به سرعت بین دامین کنترلر ها Replicate شوند.
محلی کردن سرویس دهی:
اگر شبکه در دو محل فیزیکی مختلف باشد، با قرار دادن یک دامین کنترلر در هر کدام از این محل های فیزیکی، به علت پیش فرض Load Balance در اکتیو دایرکتوری نمی توان معین کرد کاربران برای Authentication از کدام دامین کنترلر استفاده کنند. اما با استفاده از سایت ها می توان در انتخاب دامین کنترلر، کلاینت را هدایت کرد. به عبارت بهتر، با قرار دادن یک دامین کنترلر در هر سایت، کلاینت ها را در استفاده برای استفاده از دامین کنترلر موجود در سایت خود تشویق می کنیم. اگر دامین کنترلر در سایت خود در دسترس نباشد آنگاه از دامین کنترلر در سایت دیگر استفاده خواهند کرد.
تذکر مهم: از آنجایی که اهداف ذکر شده در شرایطی محقق می شوند که در هر سایت یک دامین کنترلر موجود باشد، در صورتی که دامین کنترلر موجود نباشد در بسیاری از مواقع مفید نخواهد بود اما همواره چنین نیست. در واقع در اکثر شرایط مختلف وجود یک دامین کنترلر توصیه می شود. ضمن آنکه اگر Site Link با اختلال رو به رو شود که احتمال پایینی ندارد (خصوصا در ایران) وجود یک دامین کنترلر در سایت می تواند بسیار مفید باشد. در بیشتر مواقع در سایت های کوچک و branch office ها استفاده از یک Read-Only Domain Controller بهترین تصمیم است. به این صورت اگر سایت لینک اختلال داشته باشد، دامین کنترلر داخلی سایت در دسترس است و اگر دامین کنترلر اختلال داشته باشد، اگر سایت لینک اختلال نداشته باشد دامین کنترلر سایت همسایه در سایت مفروض سرویس دهی خواهد کرد. هر چند می توان از Additional Domain Controller نیز در یک سایت بهره برد.
جمعیت کاربران:
یکی دیگر از انگیزه های ایجاد سایت می تواند تعداد زیاد کاربران باشد. با این کار می توان ترافیک را تقسیم کرد و کاربران پراهمیت تر از Subnet که معمولا در آن حضور دارند به مشکلاتی که از ترافیک بالای دامین کنترلر برای آنها ایجاد می کند رو به رو نشوند. هرچند اگر در Subnet شلوغ تر Login کنند ممکن است با همان مشکلات رو به رو شوند. با توجه به هزینه های انجام این کار، زمامی که تعداد کاربران زیاد است و یا حجم کاری زیادی به دامین کنترلر وارد می کنند یک راه حل است. در حالی که زمانی امکانات سخت افزاری دامین کنترلر جوابگو نیست، می توان سخت افزار های قدرتمند تری تهیه کرد راهکار ایجاد سایت ها نیز راهکاری است که برخی مدیران شبکه طرفدار آن هستند.
ایجاد یک سایت:
مدیریت سایت ها، replication و برخی مسائل دامین کنترلر ها را از طریق کنسول Active Directory Sites and Services انجام می شود. به صورت پیش فرض یک سایت به نام Default-First-Site-Name و یک سایت لینک به نام Defaultsitelink وجود دارد. برای ساختن یک سایت جدید روی Sites کلیک راست کنید و new site را بزنید. نام سایت و لینک یا لینک هایی که آن سایت را به سایر سایت ها متصل می کند را انتخاب کنید.
اما سایت ها زمانی مفید خواهند بود که کلاینت ها و سرور ها بدانند در یک سایت هستند. این کار با معین کردن IP آدرس های هر سایت انجام می شود. به عبارت دیگر باید هر سایت یک Subnet نیز باشد و سپس با افزودن یک subnet در کنسول Active Directory Sites and Services معین می کنیم که هر Subnet مربوط به چه سایتی است. برای اضافه کردن یک Subnet روی Subnets کلیک راست کنید و گزینه New Subnet را بزنید. مشابه مثال۲۰/ ۱۵۷٫۵۴٫۲۰۸٫۰ NetID و SubnetMask را وارد کنید و سایتی که آن subnet به اختصاص دارد را انتخاب کنید.
پس از افزودن یک لینک در properties سایت مربوطه قابل مشاهده است. هرچند از اینجا نمی توانید آن را تغییر بدهید. برای این کار باید به properties همان subnet مراجعه کنید. در محیط عملیاتی توجه داشته باشید که تمام Subnet ها را در یک سایتی اضافه کرده باشید. عدم وجود یک Subnet باعث می شود کلاینت متوجه نشود در کدام سایت است و باعث مشکلات performance و ترافیک می شود.
مدیریت دامین کنترلر ها در سایت ها:
زمانی که اولین دامین کنترلر در جنگل جدید را ایجاد می کنید، به صورت پیش فرض سایتی به نام default-first-site-name ایجاد می شود و Domain Controller در آن سایت قرار می گیرد. پس از آن اگر سایت هایی ایجاد کنید، دامین کنترلر ها برحسب IP address خود در سایت های مربوط به Subnet خود اتوماتیک قرار می گیرند. توجه داشته باشید servers در کنسول Active Directory Sites and Services فقط DC ها را نمایش می دهد. همانطور که گفته شد تنها به دامین کنترلر ها می گوییم سرور و بقیه سرور ها را کامل بیان می کنیم مثلا DHCP server . هر سایت یک کانتیتر سرور برای خود دارد. می توانید با move کردن و یا drag & drop یک دامین کنترلر را در یک سایت قرار دهید. اگر یک سایت شامل دامین کنترلر نباشد یا دامین کنترلر آن سایت down شود کاربران هنوز می توانند authenticate شود چرا که در دامین کنترلر سایت همسایه یا یک دامین کنترلر دیگر در دامین استفاده می کنند.
چگونه کلاینت ها به دامین کنترلر محلی خودشان هدایت می شوند؟
این یکی از سوالاتی است که از لحاظ تکنولوژیک بسیار جالب است. خیلی خلاصه در اینجا بحث می کنم این قسمت در حل مشکلات پیش آمده بسیار مفید است و با توجه به عدم توجه بسیاری مدیران، قدری کم توجهی به این مسئله جالب شده است. زمانی که یک دامین کنترلر در یک سایت قرار می گیرد، تبلیغ می کند که من اینجا هستم، برای authenticate به من مراجعه کنید. حال اگر آن دامین کنترلر آنجا نباشد مثلا down شده باشد، قطعا مشتریان یا کلاینت ها به سراغ یک دامین کنترلر دیگر می روند.زمانی که یک دامین کنترلر به دامین اضافه می شود برای آنکه کلاینت از توانایی دامین کنترلر مطلع شوند رکورد های DNS ای را ثبت می کند. این رکورد ها از نوع ( SRV ( Service Locator هستند. در رکورد های SRV بر خلاف A record ها مشخص می شود که چه سرویسی توسط چه host name ای انجام می شود. دامین کنترلر قابلیت خود را با درست کردن رکورد های SRV و با نام های kerberos_ و LDAP_ برای کلاینت ها آشکار می کنند. این رکورد ها را در جاهای مختلفی در DNS ثبت می کنند.
اول: رکورد ها را در پوشه ی tcp_ ثبت می کنند.
دوم : رکورد ها را در پوشه TCP_ درنام سایت خود ثبت می کنند.
سوم: رکورد های دیگری هم در msdcs_ ثبت می شود. این zone شامل دامین کنترلر های مایکروسافت می شود.
بر اساس RFC 2052 یک رکورد SRV حداقل شامل:
۱٫ نام و پورت : در ویندوز سرور ۲۰۰۸ شامل ldap پورت ۳۸۹ ؛ Kerberos پورت ۸۸ ؛ KPassWD پورت ۶۴۶ و GC پورت ۳۲۶۸ در خصوص دامین کنترلر ها است. KPassWD کوتاه شده ی Kerberos PassWord است و GC کوتاه شده ی Global Catalog است.
۲٫ پروتکل : پروتکل لایه انتقال ( Transport ) باید مشخص شود که TCP یا UDP می تواند باشد که هر دوی آنها ثبت می شود. کلاینت های مایکروسافت از TCP استفاده می کنند اما UNIX از UDP هم می تواند استفاده کند.
۳٫ Host Name : مشخص کننده ی یک Host Name است که IP Address ان از طریق یک A record دیگر مشخص می شود. نکته جالب آن است که زمانی که یک Query برای یک رکورد SRV ارسال می شود، DNS Server خودکار جواب رکورد A مربوطه را نیز ارسال می کند تا Query دیگری دوباره ارسال نشود.
تصور کنید الان یک کلاینت جدید را عضو دامین می کنیم. تنظیمات IP آن Automatic است و از یک DHCP Server یک IP و… دریافت می کند. کلاینت restart می شود و اکنون آماده است که یک user تشخیص هویت شود و کاربر وارد desktop خود شود. حال کلاینت از کجا باید یک دامین کنترلر پیدا کند؟ کلاینت یک Query به DNS Server ای که DHCP Server به او معرفی کرده می فرستد. Query ارسال شده برای بخش tcp_ است که همانطور که در قبل توضیح داده شد، شامل تمام دامین کنترلر ها می شود. DNS Server هم IP آدرس تمام دامین کنترلرها را به کلاینت می دهد. اولین دامین کنترلری که جوابی به کلاینت ارسال کند از روی Subnet های معین شده به کلاینت می گوید که در کدام سایت قرار دارد. کلاینت هم نام سایت را در Reistry خود ذخیره می کند و حال به DNS Server یک Query برای دامین کنترلر سایتی که در آن حضور دارد ارسال می کند. DNS Server با توجه به آنچه گفته شد، می داند کدام دامین کنترلر در کدام سایت است پس جواب Query را به کلاینت باز می گرداند. کلاینت اکنون از تمام دامین کنترلر های سایت خود در خواست authenticate می کند و هر دامین کنترلری که اول جواب دهد او تشخیص هویت کاربر را انجام می دهد. این اولین Startup پس از عضویت در دامین بود.
از آنجا که دامین کنترلر سریع تر از بقیه جواب داده بود، کلاینت به این دامین کنترلر علاقه مند می شود و در دفعات بعدی تلاش می کند تا با همین دامین کنترلر authenticate شود. اگر این دامین کنترلر در دسترس نبود آنگاه کلاینت به اجبار یک Query به DNS Server می فرستد و از دامین کنترلر های سایت خود سوال می کند و دوباره همان مراحل در خصوص یک دامین کنترلر دیگر اتفاق می افتد. اما اگر یک کامپیوتر قابل حمل همانند یک Laptop باشد چه اتفاقی می افتد؟ تصور کنید که Laptop در سایت A یکبار Authenticate شده و اکنون از سایت A به سایت B می رود. از آنجایی که Laptop به دامین کنترلر سایت A علاقه مند شده بود، ابتدا تلاش می کند که با دامین کنترلر سایت A تشخیص هویت شود حال آنکه در سایت B است و دامین کنترلر A به Laptop تذکر خواهد داد که سایت جدید شما B است به دامین کنترلر مربوط خودتان مراجعه کنید. Laptop هم به DNS Server یک Query می فرستد و از دامین کنترلر های سایت B سوال می کند.
اما اگر هیچ دامین کنترلری در سایت C موجود نباشد چه می شود؟ در این شرایط دامین کنترلر های نزدیک رکورد SRV خود را در سایت C ثبت می کنند. به این فرآیند Site Coverage گفته می شود. توضیح دقیق تر آنکه سایتی که دامین کنترلر نداشته باشد توسط دامین کنترلر سایتی پوشش داده می شود که کمترین Cost برای Site Link آن تنظیم شده باشد. هر چند می توانید به صورت دستی هم با تنظیم priority در رکورد های DNS این روند را تغییر دهید. اگر دامین کنترلر یک سایت down شود، سایت همسایه می تواند در آن سایت به سرویس دهی بپردازد.
ایجاد یک سایت لینک:
همانطور که گفته شد، به صورت پیش فرض یک سایت لینک با نام DefaultSiteLink وجود دارد. سایت لینک ها خودکار ایجاد نمی شوند و باید برای مدیریت Replication بین سایت ها و… سایت لینک ها به خوبی مدیریت شوند. در خصوص آنکه چگونه سایت لینک روی Replication اثر می گذارند در آینده بحث می کنیم. اما می توانید در هر سایت لینک فاصله زمانی یک Replication با Replication بعدی را معین کنید. همچنین با استفاده از Schedule می توانید معین کنید Relication فقط در ساعات خاصی اتفاق بی افتد. نکته قابل توجه آن است که حتی اگر Time Zone ها بین دو سایت یکسان نباشد، از آنجایی که ساعت بر حسب local time zone مشخص می شود و (Coordinated Universal Time (UTC ذخیره می شود. این به معنای آن است که در سایت دوم، زمان بی مشکل مشخص خواهد شد. اما در هر دو سایت برای پیشگیری از بروز مشکلی بهتر است مسئله را مانیتور کنید.
یک سایت لینک خاصیت تعدی دارد. همانند ریاضی که اگر a بتواند b را نتیجه دهد و b بتواند c را نتیجه دهد، a می تواند c را نتیجه دهد. اگر سایت a و b یک سایت لینک داشته باشند و سایت b و c هم یک سایت لینک داشته باشد، سایت a به سایت c متصل در نظر گرفته می شود. می توان خاصیت تعدی (Transitive) را فعال را غیر فعال کرد. به صورت پیش فرض برای هر نوع transport فعال است. به عنوان مثال تمام لینک های موجود در IP با هم دیگر خاصیت تعدی دارند. توجه کنید که اگر خاصیت تعدی را برای یک Transport غیر فعال کنید برای تمام سایت لینک های موجود در آن Transport غیرفعال می شود و باید به صورت دستی Site Link Bridge بسازید تا بتوانید از خاصیت تعدی استفاده کنید. اما دلایل غیر فعال کردن خاصیت تعدی چه می تواند باشد؟
۱٫ می خواهید کنترل کامل روی replication بین سایت ها داشته باشید.
۲٫ Routing به صورت کامل در بین سایت ها برقرار نیست.
برای غیر فعال کردن خاصیت تعدی روی Transport مورد نظر کلیک راست کنید و گزینه properties را بزنید. سپس در زبانه(Tab) عمومی (general) گزینه Bridge all site links چک مارکش را بردارید. حال چگونه چند لینک را Bridge کنیم؟ با Bridge کردن دو یا چند سایت لینک در زمانی که خاصیت تعدی فعال است، خاصیت تعدی را برای چند سایت لینک ایجاد می کنیم . همچنین از آنجا گزینه Bridge all site links به صورت پیش فرض فعال است، Bridge کردن سایت لینک ها بدون غیر فعال بودن گزینه مذکور هیچ اثری نخواهد داشت. برای ساختن پل میان دو سایت لینک، روی transport مورد نظر کلیک راست کنید و گزینه New Site Link Bridge را بزنید. یک نام انتخاب کنید و سپس سایت لینک هایی که می خواهید خاصیت تعدی داشته باشند را انتخاب کنید.
یکی از سوالتی که برخی افراد دارند آن است که تفاوت میان IP و SMTP و RPC در Transport ها چیست؟ که در این خصوص در آینده و در بحث Replication صحبت خواهد شد.
