سولوشن مناسب برای پیاده سازی سناریوی زیر

پنج‌شنبه 15 تیر 1396 ساعت 11:39
چند روز پیش سناریوی که در دنیای واقعی بیشتر با آن رو به رو شده ایم را در این انجمن مطرح کردم که بنا به دلایلی کسی رغبت به حل یا ارائه یک سولوشن مناسب دراین سناریو نداشته است. من هم بخاطر این جمله معروف "می نویسم تا همه بخوانند؛ شاید کسی چیزی یاد بگیرد و یا استادی اشتباه مرا بگیرد." تصمیم گرفتم طبق Best Practice های مایکروسافت پیش برم و یک سولوشن مناسب برای این سناریو معرفی کنم.
نکته: این مقاله در دست تعقیر می باشد. در صورت دادن یک سولوشن مناسب (با دلیل و لینک) سولوشن شما جایگزین می شود.
و اما سناریو:


به تازگی شرکت ما سه شعبه دیگر با آن اضافه شده است تیم IT بعد از طراحی و پیاده سازی ساختار را بدین شکل پیاده سازی کرده اند:(همه دلایل فنی در نظر گرفته شده است) در سایت اصلی و Branch office -02 ما DC های از نوع WRDC داریم ولی بخاطر نکات امنیتی یک RODC در Branch office -01 را اندازی کردیم. بعد از نصب و راه اندازی ساختار (اماده بودیم که ژست خدائی بگیریم که ما خدای بلا منازع شبکه و ..... هستیم که) دیدیم Replication بین Branch office 01 و Branch office -02 انجام نمی شود؟؟؟؟ سایت اصلی می تواند با Branch office-02 ریپلیکت کند و برعکس و همچنین Branch office-03 بدلیل تعداد کم یوزر (در حدود 7 تا یوز) DC وجود ندارد و مشکلی از این بابت نداریم. تنها مشکلی که داریم Branch office-01 نمی تواند با Branch office-02 ریپکلت کند!!!!!؟؟؟؟ ما را در یافتن این مشکل راهنمائی کنید؟ همچنین اگر مایل بودید نظر خود را درباب Branch office-03 بگوید در آنجا DCی نصب کنیم یا خیر (چگونه آن را طراحی کنیم دلیل مناسبی دهید که بتوان با مدیریت حرف زد و توپولوژی را تعقیر داد)
جزئیات بیشتر:
Forest Name= Corp.VSP.COM
Branch Office-02= Shiraz.Corp.VSP.Com

    تمام سایتها از طریق یک لینک پر سرعت به هم دیگر وصل می باشند.
    یوزرهای سایت 3 باید به منابع این سازمان درسترسی داشته باشند.
    ساختار بصورت Hup and Spock می باشد و شعبه های 1، 2 هیچگونه ارتباط با هم دیگه ندارند و تنها با سایت اصلی در ارتباط هستند.

از شعبه سوم (Branch office-03) شروع می کنیم:
برای این شعبه دو احتمال وجود داره:

    یوزرهای مهمی برای سازمان هستند. مانند کارشناسان- مدیر پروژه یا پرسنل امور حسابداری که به عنوان یک قطب برای این سازمان فعالیت می کنند.
    یوزرهای عادی می باشند که طبق وظیفه ای که دارند بطور ثابت در یک جا مستقر نیستند و گاهی وقتا در سایت اصلی یا سایت 2 فعالیت می کنند.

برای هر یک از این احتمالات سولوشن های جداگانه ای وجود دارد.
احتمال اول:
چون این 7 یوزر کاربرهای مهمی هستند (زورشون زیاده با یک نامه به رئیس شما رو خفت می کنن :[) باید سعی کنیم دسترسی آنها به منابع و... سریع و Stable باشد. پس در نتیجه ایجاد یک RODC و همچنین یک File سرور در این شعبه گذینه مناسبی می باشد. ولی هزینه راه اندازی این چند سرویس بر روی سرور و همچنین نگهداری از آنها می تواند هزینه آن سازمان را افزایش دهد. برای مسئله سرور هر چند می توان از PC Server و قابلیت مجازی سازی استفاده کرد که تا حدودی در هزینه صرفه جوئی شود. ولی مشکلی که PC ها دارند بعد از چند روز یا چند ماه فعالیت یک قطعه از آنها می سوزد ( چه فشار روی این سرور باشد چه نباشد) که در نتیجه PC Server گذینه مناسبی نمی باشد. شاید در این شرایط بتوان از MicroServer های HP استفاده کرد.


http://www.storagereview.com/hp_proliant_microserver_gen8_review

اگر دسترسی و پایداری اطلاعات برای آن 7 نفر مهم باشد و این امر با خریدن سرور به انجام می رسد حتما باید این مسئله را در جلسه ای که با مدیران آن سازمان ایجاد می شود مطرح کنید. اگر مدیریت با این هزینه توافق نکرد چی؟؟؟ سادس باید از روشها و قابلیتهای استفاده کنیم که خلع این سرور را پرکند و تا حدودی دسترسی به اطلاعات با سرعت زیاد وهمچنین استفاده از امکانات سازمان را برای آنها فراهم کند.
Automatic Site Coverage process
معمولا DC ها مشخصات سایت خود و بقیه پرامترهای خود را در DNS ثبت می کنند (با استفاده از سرویس Net Logon و ثبت رکورد SRV متناسب) تا کلاینتها به DCهای سایت خودشان Log on کنند و خود را در ساختار احراز هویت کنند. اگر در سایتی DC ی وجود نداشته باشد DCهای سایت مقابل (نزدیکترین DCهای یک سایت بر اساس Cost مربوط به Site Link می شخص می شود) آمادگی خود را برای احراز هویت چنین کاربران بدون سرپرست و یتیم :// ( سایتی که DCنداشته باشد) اعلام می کنند. در نتیجه کاربران سایت 3 می توانند به DC های سایت دو متصل و احراز هویت شوند. به این روش automatic site coverage می گویند.
Sites Sites Everywhere…

https://blogs.technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere/

Offline Domain Join (Djoin.exe)
اگر لینک ارتباطی سایت 3 با سایت 2 کم سرعت و ضعیف باشد می توان از قابلیت Offline join استفاده کرد. و آنها را عضو Domain کرد.
Offline Domain Join (Djoin.exe) Step-by-Step Guide

https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step(v=ws.10).aspx

تا اینجا تونستیم این 7 کاربر را عضو دومین کنیم. شاید یکی بپرسه چه لزومی داره این 7 کاربر عضو دومین باشن؟؟؟ اگر کاربری نتواند Session Ticket ی که در پروسه Kerberos هستش دریافت کند نمی تواند به منابع آن سازمان دسترسی داشته باشد.(آن سازمان دسترسی ها را بصورت متمرکز و فقط برای کاربران Active Directory ست کرده اند) مسئله بعدی دسترسی کاربران سایت 3 به فایلهای سازمانی بر روی سایت 2 یا سایت 1 چگونه می باشد؟؟؟ این مسئله را چگونه حل کنیم؟؟؟؟ بازم سادس استفاده از قابلیت BranchCache!!!!!!
BranchCache
این قابلیت باعث می شود کلاینتها به فایلهای که در سایتهای دیگری میزبانی میشوند استفاده و کش کنند. این روش دومزیت دارد:

    دسترسی سریع به منابع.
    بهینه سازی ترافیک بین سایت 3 و سایت 2
    BranchCache™ is designed to reduce WAN link utilization and improve application responsiveness for branch office workers who access content from servers in remote locations. Branch office client computers use a locally maintained cache of data to reduce traffic over a WAN link.

BranchCache در دو مد ارائه شده:

    Distributed Cache mode
    Hosted Cache mode

در مد Distributed Cache mode اگر یکی از کاربران فایلی از فایل سرور که در سایت 2 می باشد دریافت کند، آن فایل را کش می کند و اگر کاربر دیگری آن فایل را نیاز داشت آن را از آن کلاینت قبلی دریافت می کند و نیازی نیست آن را مستقیما از فایل سرور دانلود کند.


ولی در مد Hosted Cache mode ما نیاز به یک سرور داریم که محتویات دانلود شده از شعبه اصلی در آن ذخیره می شود و کاربران از آن سرور استفاده می کنند.


ما در این سناریو از مد Distributed Cache mode استفاده می کنیم که خیلی کارآمد و مناسب می باشد. همچنین مایکروسافت برای چنین محیطهای آن را توصیه می کند:
For branch offices with fewer than 50 users, BranchCache can be configured in Distributed Cache mode.
BranchCache in Windows 7 and Windows Server 2008 R2 Overview

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

فرض کنید این 7 کاربر یک برنامه حسابداری یا مالی یا هر چیز دیگری دارند که باید به آن دسترسی داشته باشند. این مشکل را چگونه حل کنیم!!!؟؟
برای این مشکل هم راه حلهای وجود دارد مانند استفاده از قابلیت Remote App
Remote App
فکر کنم همه یک اشنائی جزئی یا کامل از این قابلیت داشته باشند. Remote App باعث میشه کاربران سایتهای دیگر یک برنامه وب بیس را از روی سروری بر روی کامپیوتر (کنسول) خود فراخوانی کنند و از آن استفاده کنند.
RemoteApp enables you to make programs that are accessed remotely through Remote Desktop Services appear as if they are running on the end user's local computer.
Overview of RemoteApp

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

ولی مسئله خریدن لایسنس برای هر RDP Session می تواند مانع شود از این سرویس استفاده کنیم. و مجبوریم از برنامه های دیگری استفاده کنیم که بتوان لایسنس آنها را دور زد. (فقط شانس بیارم مقالم حذف نشه :/) یکی از بهترین برنامه های که در این زمینه میشه استفاده کرده برنامه TSPlus می باشد.
Image

از مهندس اسحاقی عزیز تشکر می کنم که این برنامه جالب و قدرتمند را معرفی کردند. برای این موضوع شاید انتخابهای زیادی وجود داشته باشه مثل XenApp and XenDesktop و ... ولی تمام این قابلیتها بستگی به این دارد که آن برنامه مالی وب بیس باشد و با چنین تکنولوژی های همخوانی داشته باشد. تا اینجا ما راه حلهای که مناسب شعبه سوم هستش را مطرح کردیم. اگر برای این شعبه شما سولوشن بهتری سراغ دارید خوشحال میشم در قسمت نظرات آن را اعلام کنید. بریم سر بحث Replication سایت 1 و سایت 2 :
مشکلی که وجود داشت عدم Replication شدن اطلاعات بین DC های سایت 1 و 2 بود. در ابتدا بگم که موضوع Replication هیچ ربطی به RODC سایت 1 ندارد چون RODC یک Replica از اطلاعات DC دیگر می باشد و همیشه تعقیرات را از Partner خود دریافت می کند و بر روی RODC هیچگونه تعقیری ایجاد نمی شود که لزومی داشته باشد بقیه DC با آن Replicate کنند.در سناریوی فوق وقتی تعقیری بر روی DC های سایت 2 انجام شود این تعقیرات به DC های سایت اصلی Replicate می شود. و در آخر RODC این تعقیرات را از Partner خود دریافت می کند. خروجی دستور repadmin /showrepl بر روی RODC :


خب الان فرض کنید بجای RODC در سایت 1 یک دومین با نام
Mahshaher.Corp.VSP.Com
داشته باشیم. ایا الان این سه دومین می توانند با هم دیگر Replication کنند؟ جواب خیر می باشد. با تنظیمات پیش فرض، Replication بین سایت 2 و سایت 1 به هیچ وجه انجام نمی شود. و ما مجبوریم قابلیت Bridge All site link را بر غیرفعال کنیم (not full route) برای اطلاع بیشتر درباره Bridge Site Link مقاله زیر را مطالعه کنید: (بیشتر تنظیمات این قسمت را در لینک زیر توضیح دادم)
مقاله: چیزهای که باید در مورد Replication در ساختار Directory Service بدانید
نمونه ای از تنظیمات AD Site and Service برای این سناریو:


خروجی دستور repadmin /showrepl بر روی DC های سایت اصلی:


خروجی دستور repadmin /showrepl بر روی DC های سایت 1:


خروجی دستور repadmin /showrepl بر روی DC های سایت 2:


همچنین ارتباطات Replication را توسط ابزار Active Directory Replication Status Tool تست کردم. این ابزار را می توانید ازلینک زیر دانلود کنید:

https://www.microsoft.com/en-us/download/details.aspx?id=30005

این ابزار را بر روی DCهای سایت 2 تست کردم و Destination DC را DC های سایت دو انتخاب کردم. نتیجه را با هم دیگه ببینیم:


توانست Domain Partition مربوطه به Mahshaher.corp.vsp.com را از طریق DC های سایت اصلی بدست آورد.
نکته: هر DC فقط و فقط Domain Partition خود را نگهداری می کند و آن را بین DC های همان دومین Replicate می کند. ولی DC های که نقش Global Catalog بر روی آنها فعال علاوه بر Domain Partition خود نیاز به Domain Partition های دیگر دومینها دارند.
اجازه دهید این سناریو را با یک سوال تمام کنم. اگر در سایت 3 ما یک Domain داشته باشیم جریان Replication بین این سایتها چگونه می باشد؟ ایا نیاز به تعقیر تنظیمات هست یا نه؟
در آخر از مهندس اسحاقی و بهزادی عزیز کمال تشکر را دارم که مرا در حل این سناریو یاری کردن.


 

نظرات (0)
امکان ثبت نظر جدید برای این مطلب وجود ندارد.