امیرحسین کریم پور
مدیر ارشد توسینسو و متخصص سرویس های مایکروسافت

کاملترین آموزش راه اندازی DFS در ویندوز سرور | گام به گام + نکات

وقتی زمان آن میرسد که مدیران شبکه تصمیم به راه اندازی File Server میکنند مدیران شبکه از سرویس DFS یا Distributed File System (سیستم فایل توزیع شده) استفاده میکنند تا از دست روش های قدیمی و سنتی راه اندازی فایل سرور نظیر Standalone Share Point خود را خلاص کنند.دلیل عمده استفاده مدیران شبکه از سرویس DFS افزونگی یا Redundancy ای هست که این سرویس به ارمغان می آورد.علاوه بر این سرویس DFS دسترسی پذیری راحت تر و عملکرد بهتر را برای دسترسی یافتن به فولدر های Share شده در سطح دومین را به وجود می آورد.

دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران

آموزش راه اندازی DFS در ویندوز سرور 2012 به زبان ساده قسمت 1

روش های مختلفی با توجه به راه اندازی سرویس DFS وجود دارد که هر کدام مزایا و معایب خود را به همراه دارند.در این سری از مقالات به شما تئوریاتی که میبایست درباره سرویس مهم DFS بدانید را تشریح میکنیم و در آخر به راه اندازی این سرویس میپردازیم. شما میبایست برخی از اصطلاحات را درباره ساز و کار سرویس DFS بدانید که قطعا در پروسه راه اندازی این سرویس برایتان ضروری خواهد بود. در زیر آنها را توضیح داده ایم:

  • DFS Namespace: همانطور که از نام آن نیز پیداست Namespace یک فضای نام مرکزی برای سرویس DFS است که کاربران میتوانند تمام فولدر های اشتراکی که در آن فضای نام ایجاد شده اند را بصورت یکپارچه مشاهده کنند.
  • DFS Namespace Server: همانطور که از نامش هم مشخص است،سروری است که DFS Namespace را میزبانی میکند.DFS Namespace Root بالاترین سطح از DFS Namespace است.که هیچ تفاوتی با DFS namespace ندارد.
  • DFS Folder: فولدر DFS همان پوشه اشتراکی است که کاربران از طریق آدرس UNC به آن متصل میشوند. DFS folder میتواند در هر سروری که DFS root را میزبانی میکند وجود داشته باشد.
  • Folder target: فولدر تارگت ها فولدرهایی هستند که ابتدا در DFS Root ایجاد شده اند و سپس با ایجاد همان فولدر ها در DFS سرور های دیگر و انجام عملیات آن در DFS Root بین سرور های DFS اطلاعات آن Replicate میشوند. این توضیحات در راه اندازی سرویس DFS بیشتر برایتان ملموس خواهد بود. پس تا راه اندازی سرویس عجله نکنید.
  • DFS Tree: یک DFS tree مرجعی است که به DFS ریشه یا روت اشاره میکند.اولین DFS tree از DFS root ایجاد میشود.DFS root شامل تمامی DFS tree های زیرشاخه خودش است که به آن لینک دارند.

مزایای استفاده از DFS

  1. فولدر های Share شده در سطح شبکه به صورت سلسله مراتبی توسط DFS Root ایجاد میشود.که با این وصف دسترسی کاربران به فولدر ها و فایل را تسهیل میکند.
  2. با Replicate شدن فولدر های share شده Fault Tolerance را برایمان فراهم میکند که این کار با استفاده از سرویس FRS انجام میشود.
  3. Load Balancing میتواند با توزیع فولدر ها در سرتاسر سرورهای موجود در شبکه ایجاد شود.

Standalone Namespaces در مقایسه با Domain Based Namespace

حال که با برخی از اصطلاحات موجود در سرویس DFS آشنا شدید وقت آن است که به سراغ طراحی و برنامه ریزی برای نصب آن برویم.اولین و مهم ترین سئوالی که قبل از راه اندازی سرویس DFS باید از خودتان بپرسید این است که من میخواهم Standalone Namespaces راه اندازی کنم یا Domain Based Namespace ؟

Standalone Namespaces

Standalone Namespaces محدودیت های زیادی نسبت به Domain Based Namespace دارد.برای مثال شما تنها یک standalone namespace برای هر سرور میتوانید میزبانی کنید.اما شما میتوانید DFS Folder های متعددی درون DFS root ایجاد کنید.و آدرس دسترسی به standalone namespace به صورت زیر است:

Server_Name.Domain_Name\DFS_Root_Name

Standalone Namespaces همانند دیگر پیاده سازی های سرویس DFS به شما امکان میدهد تا با ایجاد folder target ها در DFS سرور های دیگر و Replicate شدن آن اطلاعات fault tolerance را برای DFS تان فراهم کنید.استفاده از folder target های متعدد برای سرویس DFS شما درجه ای از fault tolerance را فراهم میکند.و همچنین اگر داده ها در یک محل مرکزی ذخیره شود عملکرد بهتری را فراهم میکند.

مشکلی که در استفاده از folder target های متعدد وجود دارد این است که اطلاعات سرور های Target یا هدف باید با Standalone Namespaces سرور به صورت دستی synchronize یا یکسان سازی شود.مگر اینکه سرور های DFS به Domain جوین شده باشد.اغلبا standalone namespaces در محیط هایی استفاده میشود که در آن Domain و اکتیودایرکتوری وجود ندارد.همانطور که از نام آن هم پیداست standalone namespace در محیط های standalone استفاده میشود.

Domain-Based Namespaces

همانطور که احتمالا انتظار دارید،domain based namespaces نیازمند این است که تمام DFS سرور ها به دامین یا اکتیودایرکتوری جوین شده است.این نوع از محیط ها اطلاعات DFS سرور را به طور اتوماتیک بین سرور هایی که Folder Target را میزبانی میکنند Synchronize میکند.دسترسی به سرور domain based namespaces از طریق آدرس زیر در دسترس است:

\\Domain_Name\DFS_Root_Name

در پیاده سازی domain based namespaces سرور های DFS Root میتوانند بین چندین DFS سرور میزبانی شود.

نتیجه گیری

در این مقاله به یکی از کلیدی ترین تصمیماتی که برای برنامه ریزی برای راه اندازی سرویس DFS در ویندوز سرور 2012 لازم و ضروری بود توضیح دادیم که در چه زمانی باید از Domain-Based Namespaces استفاده کنیم و چه زمانی باید از Standalone Namespaces استفاده کنید.در مقاله بعد درباره توپولوژی های Replication بین DFS سرور ها صحبت خواهیم کرد.


چرا Replicate میکنیم ؟

سئوالی که ممکن است برایتان پیش بیاید این است که ما چرا از Replication در سرور های DFS استفاده میکنیم و این کار چه مزیت هایی به همراه دارد.به طور فنی شما به DFS سرور های چندگانه نیاز ندارید.اما توجه کنید شما دقیقا به Replica DFS Server نیاز خواهید داشت.برای شروع شما با استفاده از replica server های متعدد به زیرساخت DFS خود را درجه ای از scalability یا مقیاس پذیری خواهید رساند.به جای اینکه هر کاربر به منابع به اشتراک گذاشته شده در یک سرور دسترسی پیدا کنند شما میتوانید درخواست Workload ها یا بارکاری هر کاربر را بین DFS Server های متعدد توزیع کنید تا اینکه فقط یک سرور پاسخگوی درخواست های آنها باشد.

دلیل دیگر استفاده از DFS replica های چندگانه فراهم آوردن fault tolerance یا تحمل خرابی میباشد.برای مثال فرض کنید میخواهید Service Pack های ویندوز را بر روی ویندوز سرور نصب کنید و به لطف ویندوز جان در هر بار نصب شدن باید یکبار ریستارت شود این ریستارت شدن پی در پی میتواند مانع از دسترسی پیوسته به منابع سرور میشود و ما در اینجا down time خواهیم داشت حال اگر از DFS replica های چندگانه استفاده کنیم این مشکل نیز مرتفع میشود.شما میتوانید با فراهم آوردن fault tolerance در DFS سرور ها در صورت Fail شدن یکی از لینک های شبکه به سرویس دهی به کاربران ادامه دهید.

فرض کنید شما یک branch office دارید که با لینک WAN به main office یا اداره مرکزی وصل شده است در این حین اگر لینک WAN از کار بیفتد و خراب شود کاربران حاضر در branch office نمیتوانند به هر سروری که در main office وجود دارد وصل شوند و از منابع آنها استفاده کنند.حال اگر یک سرور DFS replica در branch office داشته باشید آخرین بار قبل از fail شدن لینک WAN اطلاعاتی که از DFS Root حاضر در main office با DFS replica حاضر در branch office ریپلیکیت شده اند دریافت میکند و زمانی که DFS Root به مدار بازگشت DFS replica در branch office اطلاعاتش را با DFS Root حاضر در main office یکسان سازی یا Synchronize میکند.

Replication Topology(توپولوژی Replication)

ویندوز سرور 2008 و همچنین 2012 از جفت توپولوژی های Replication پشتیبانی میکند.هر توپولوژی مزایا و معایب خاص خودش را داراست.اگر شما در تصمیم گیری برای استفاده از این توپولوژی ها مشکل دارید شما بایستی با توجه به نیاز سازمان خود از این توپولوژی ها بهره ببرید.در ادامه به معرفی هر یک از این توپولوژی ها میپردازیم...

The Hub and Spoke Topology

این توپولوژی یکی از محبوب ترین و پرکاربردترین توپولوژی های DFS replication میباشد.همانطور که در تصویر زیر مشاهده میکنید این توپولوژی شبیه به توپولوژی star در بین توپولوژی های شبکه های کامپیوتری است.در توپولوژی hub and spoke سروری که در مرکز قرار دارد در اصطلاح initial master نامیده میشود.هر replica یک replication دوطرفه را با سرور initial master انجام میدهد.اما با DFS سرور های کناری Replicate انجام نمیدهد.این نوع توپولوژی بسیار کارایی دارد اما نقطه ضعفی که این توپولوژی دارد این است که اگر سرور initial master از کار بیفتد سرور های replica قادر به انجام فرآیند Replicate با آن نخواهند بود.نکته ای که اینجا مطرح است برای استفاده از این توپولوژی باید حداقل 3 عدد DFS Server داشته باشید.

وب سایت توسینسو

The Full Mesh Topology

این توپولوژی یکی از توپولوژی های رایج دیگر برای DFS replication میباشد که معمولا در محیط های آزمایشی از این نوع توپولوژی استفاده میشود.تصویر زیر نمایانگر این توپولوژی است.در این توپولوژی هر DFS سرور میتواند با DFS سرور دیگر فرآیند replication اطلاعات موجود در فولدر های اشتراکی را انجام دهد.یکی از مزیت های این توپولوژی در دسترس بودن سرور ها در هر زمان میباشد بطوریکه اگر یکی از سرور ها Down شود با سرور دیگر میتواند اطلاعاتش را replicate کند.اما یکی از مهمترین نقاط ضعف این توپولوژی ایجاد ترافیک بیش از حد روی لینک شبکه است که پهنای باند خیلی زیادی را اشغال خواهد کرد.پیشنهاد میشود در صورتی که از لینک های پرسرعت استفاده میکنید از این نوع توپولوژی استفاده کنید.

وب سایت توسینسو

No Topology?

زمانیکه شما replication group را در ویندوز سرور 2008 یا 2012 پیکربندی میکنید گزینه آخر گزینه ای به نام No Topology است.شاید برایتان عجیب بنظر برسد که این توپولوژی که توپولوژی نیست پس چیست!!! گزینه No Topology به شما امکان ایجاد کردن replication group را بدون استفاده از توپولوژی فراهم میکند.این گزینه بعدا به شما اجازه میدهد تا replication topology خاص خود را انتخاب کنید.از این گزینه برای تست میتوانید در محیط های آزمایشی استفاده کنید.اما همیشه best practice ها را در نظر بگیرید.

نتیجه گیری:

همانطور که دیدید replication topologyها نقش بسیار مهمی را در معماری DFS بازی میکنند.در مقاله بعد در مورد best practice ها برای معماری و طراحی DFS بحث خواهیم کرد.


Backup Strategy (استراتژی Backup گیری)

اینکه فکر کنید فولدرها و فایل ها در DFS tree ذخیره میشوند و با سرور های دیگر این اطلاعات Replicate میشوند و نیازی به تهیه نسخه Backup از آنها ندارید متاسفانه در اشتباهید.داشتن سرور های DFS replica از اطلاعات شما در برابر وقوع حادثه ای مانند fail شدن هارد دیسک جلوگیری میکند.اما آن هیچ وقت از خرابی داده ها جلوگیری نمیکند.اگر فایلی دچار خرابی شداطلاعات خراب شده در سرور های تارگت هم Replicate میشود.

بخاطر اینکه داده ها در هر سرور DFS replica ریپلیکیت و یکسان سازی میشوند شما میتوانید از یکی از سرور های DFS replica یک نسخه Backup تهیه کنید.اما چیز مهمی که حتما باید به خطر داشته باشید این است که نرم افزاری که عملیات Backup گیری از داده های سرور DFS را انجام میدهد نباید داده های آرشیو شده را هم به مجموعه اطلاعاتی که بکاپ گرفته شده اند اضافه کند،به این دلیل که file replication با فایل های بکاپ گرفته شده از نقطه نظر تاریخ و Time stamp(مهر زمانی) منجر به تداخل پارامتر های مذکور میشود.این مورد شاید جدی به نظر نرسد اما خب به عنوان Best Practice مایکروسافت بهتر است به آن عمل کنید تا از آسیب های احتمالی به داده هایتان جلوگیری کنید.

Disk Space

شاید این خیلی بدیهی به نظر برسد اما برخی اوقات شاهد این مسئله هستیم که ظرفیت Staging Folder را آنقدر کم و کوچک در نظر می گیرند که واقعا مسخره به نظر می رسد ، درایوی که حاوی Staging Folder است باید آنقدر ظرفیت و فضای خالی داشته باشد تا بتواند فرآیند Replication را برای DFS مدیریت کند ، در عین حال این فضا به منظور یک فضای موقتی برای Replicate کردن داده هایی که ارسال و دریافت می شوند نیز در نظر گرفته می شود.

DFS Root

ملاحظات متعددی درباره ایجاد DFS Root وجود دارد که باید رعایت کنید.بنده پیشنهاد میکنم که با یک DFS Root خالی شروع به ایجاد آن کنید بنابراین با این کار شما میتوانید از Replicate شدن هر داده ای جلوگیری کنید.DFS root باید تنها شامل فولدر هایی باشد که توسط DFS مدیریت میشوند.من همچنین پیشنهاد میکنم که از Replicate شدن داده های فولدر های درون DFS Namespace ریشه جلوگیری کنید،به این دلیل که ویندوز علاوه بر replicate کردن اطلاعات root فولدر های تارگت را هم replicate خواهد کرد.شاید این چیز زیاد بدی نباشد اما این را به خاطر داشته باشید که target folder ها در بسیاری از نمونه ها به طور مستقل اطلاعات خودشان را با DFS ریشه Replicate میکنند.پس راه اندازی replication در سطح Root افزونگی یا redundancy برای Replication فراهم نمیکند.

تصمیم گیری برای اینکه چه Replication ای مناسب است و یا اصلا Replication لازم است؟

در هر حال DFS replication به شما در امر تقسیم بار کاری بین فایل سرور های متعدد کمک شایانی میکند و میزانی از fault tolerance یا تحمل خرابی را برایتان به ارمغان می آورد اما توجه کنید که این همیشه مطلوب نیست.برای مثال محیطی را در نظر بگیرید که کاربران به طور مداوم بر روی داده ها تغییرات اعمال میکنند.در این چنین محیط هایی هر آپدیتی میتواند شماره ورژن فایل را تغییر دهدکه باعث انجام فرآِیند DFS replication میشود.اگر تعداد زیادی از این آپدیت ها بین فایل ها انجام شود به دنبال آن DFS Replication های زیادی انجام میپذیرد که اصلا مناسب و مورد قبول نیست.این حادثه در اصطلاح Replication storms(توفان Replication) نامیده میشود.

Replication storms ها قابل جلوگیری هستند،زیرا ویندوز سرور 2008 و 2012 به شما این امکان را میدهد تا مقدار پهنای باندی که توسط فرآیند Replication مصرف میشود را محدود کنید.مشکلی که در این قابلیت وجود دارد این است که اگر DFS replication پهنای باند کافی برای انجام دادن فرآیند replication نداشته باشد داده هایی که باید replicate میشدند بلافاصله با دیگر سرور ها synchronize نمیشوند که میتواند منجر به بوجود آمدن تداخل در ورژن های فایل شود.

به طور معمول بهترین محیط ها محیط هایی هستند که کاربران از فایل سرور های دیگر داده ها را میخوانند اما تغییرات زیادی روی آنها ایجاد نمیکنند.در اینگونه محیط ها بارکاری replication مینیمم است زیرا replication زمانی اتفاق می افتد که آپدیتی اتفاق بیافتد.اگر کاربران سازمان تان بطور مداوم فایل ها را بروز رسانی میکنند شما میتوانید یک replication schedule برای آن تعریف کنید تا در ساعات کاری غیر اوج اقدام به replicate کردن داده هایی که میخواهند بروز رسانی شوند انجام دهد با این کار صرفه جویی موثری در پهنای باند لینک شبکه تان میشود.بار دیگر نیز این کار میتواند منجر به تداخل ورژن در دو نمونه جداگانه از فایل ها در هر بروز رسانی شود،قبل از اینکه replicate انجام گیرد.از این نقطه نظر شما باید تصمیمات جدی درباره انتخاب استراتژی تان با توجه به نیاز ها و شرایط سازمان تان بگیرید.

نتیجه گیری

در این مقاله ما درباره موضوعاتی صحبت کردیم که شما میتوانید آنها را درمحیط های عملیاتی برای اطمینان حاصل کردن از اینکه DFS Replication در شرایط مناسب انجام پذیرد به کار بگیرید.ما همچنین درباره به کارگیری روش هایی که میتوانید برای عدم بوجود آمدن اختلال در شبکه در فرآیند replication انجام دهید نیز صحبت کردیم.بخاطر داشته باشید که این هایی که گفتیم تنها Best Practice های مایکروسافت در رابطه با این سرویس است و مسائل دیگر و حتی مهمتری نیز میتواند در فرآیند Replication صورت پذیرد.در مقاله بعد آموزش صفر تا صد راه اندازی سرویس DFS را در ویندوز سرور 2012 برایتان خواهیم داد.


پیش نیاز های نصب و راه اندازی سرویس DFS

  1. شما حداقل به یک عدد کلاینت و دو عدد سرور اکتیودایرکتوری نیاز دارید که سرویس DFS روی آن نصب شده است و به Domain جوین شده اند.
  2. ایجاد چند فولدر و share کردن آنها.در ادامه توضیح خواهیم داد..

توجه: ما در این سناریو Domain Based Namespace راه اندازی میکنیم.

1.ایجاد ساختار یک DFS Root ساده

برای نصب سرویس DFS طبق تصاویر زیر در ویندوز سرور 2012 عمل کنید.

وب سایت توسینسو
وب سایت توسینسو
وب سایت توسینسو

2.ایجاد یک DFS Namespace جدید

در این مرحله ما اولین DFS Namespace را که به طبع در DFS Root ما باید ساخته شود ایجاد میکنیم.در این سناریو سرور DFS Root ما DFS1 نام دارد.و سروری که DFS Root را میزبانی میکند Server1 نام دارد.

وب سایت توسینسو
وب سایت توسینسو
وب سایت توسینسو
در اینجا ما نام DFS namespace را تعیین میکنیم.

سپس رو دکمه Edit کلیک کرده و طبق تصویر زیر عمل کنید.

وب سایت توسینسو
وب سایت توسینسو

در اینجا خلاصه ای از پیکربندی های DFS namespace جدید به شما نمایش داده میشود.

وب سایت توسینسو

بعد از اتمام نصب namespace جدید در کنسول مدیریتی DFS Management نمایش داده خواهد شد.

وب سایت توسینسو

شما همچنین از طریق درایو C میتوانید مسیر ساخته شدن این namespace را مشاهده کنید.

وب سایت توسینسو

2.ایجاد Link ها

حال نوبت آن رسیده که چند فولدر در DFS Root بسازید و آنها را share کنید.در ادامه در کنسول مدیریتی DFS Management درون namespace برای آنها لینک ایجاد میکنیم.

وب سایت توسینسو

در فیلد Name ما نام فولدری که share کرده ایم را وارد میکنیم.و در فیلد Target Folder آدرس UNC فولدر شیر شده را وارد میکنیم.

وب سایت توسینسو

برای دیگر فولدر ها هم مانند روال قبل عمل کنید.

وب سایت توسینسو

حال میتوانیم در کامپیوتر کلاینت برای تست به Namespace مان وارد شویم.در آموزش های قبلی توضیح دادیم که برای دستیابی به Domain based namespace باید مثل تصویر زیر آدرس UNC را وارد کنید.

وب سایت توسینسو

نکته:لینک ها در Domain based namespace دسترسی به Shared Folders را بدون اینکه از محل سرور آگاهی داشته باشیم برایمان فراهم میکند.

تصاویر کاملا گویای این نکته است.
وب سایت توسینسو

3.ایجاد کردن Replica Shares:

توجه کنید برای اینکه Replica Shares درست کنیم باید در سرور هایمان سرویس DFS Replication فعال و در حال اجرا باشد.

وب سایت توسینسو

در ابتدا DFS shares های DFS Root مان را در DFS سرور دیگر کپی میکنیم.توجه کنید که Permission های آنها حفظ شوند.

وب سایت توسینسو

حال برای اضافه نمودن Target Folder برای هر فولدر share شده مان مثل مراحل زیر پیش میرویم.

وب سایت توسینسو

در تصویر زیر دقت کنیدکه در فیلد Server باید نام DFS سرور Targer مان را وارد میکنیم.

وب سایت توسینسو

در تصویر زیر ما قبول میکنیم که میخواهیم یک replication group بین دو DFS سرور برای آن فولدر که کمی پیش روی آن راست کلیک کرده و Add Folder Target را زدیم ایجاد کنیم.

وب سایت توسینسو

مانند تصویر زیر شما میتوانید براحتی نام و اسم فولدر replication group را ویرایش کنید.

وب سایت توسینسو
وب سایت توسینسو

در زیر شما باید سرور Primary که در سناریوی ما Server1 نام دارد را انتخاب کنید.زیرا اطلاعاتی که میبایست replicate شوند از Server1 به Server2(تارگت سرور) منتقل میشوند.

وب سایت توسینسو

در تصویر زیر شما باید توپولوژی Replication را انتخاب کنید(در آموزش های قبل بطور مفصل درباره آنها صحبت کردیم).در این سناریو چون ما دو عدد DFS Server داریم پس نمیتوانیم توپولوژی Hub and spoke را انتخاب کنیم.

وب سایت توسینسو

سپس شما میتوانید میزان پهنای باندی که میتواند در فرآیند Replication مصرف شود را انتخاب کنید.در اینجا ما در محیط آزمایشی تمام پهنای باند را در نظر گرفتیم.در محیط واقعی شما نباید چنین کاری بکنید.گزینه بعدی به شما امکان میدهد تا روز های مشخصی را برای انجام Replication مشخص کنید.

وب سایت توسینسو

در تصویر زیر خلاصه ای از آنچه برای پیکربندی ساخت replication group انجام دادید به شما نمایش داده میشود.

وب سایت توسینسو

حالا شما میتوانید به کنسول مدیریتی DFS Management در سرور دوم بروید و مشاهده کنید که آنچه که برای replication group در Server 1 انجام دادید در Server 2 هم ظاهر شده است.توجه کنید در تصویر زیر ما برروی Server 1 قرار داریم نه Server 2.

وب سایت توسینسو

اگر شما نیاز به replication schedule دارید میتوانید بر روی replication group راست کلیک کرده و Properties را بزنید و سپس در تب General بر روی دکمه Edit schedule دابل کلیک کنید و طبق تصویر زیر میتوانید پهنای باند مصرفی یا bandwidth و replication schedule را طرح ریزی بکنید.

وب سایت توسینسو

پایان


امیرحسین کریم پور
امیرحسین کریم پور

مدیر ارشد توسینسو و متخصص سرویس های مایکروسافت

امیرحسین کریم پور ، مدیر ارشد توسینسو ، متخصص شبکه ، تخصص در حوزه سیستم عامل های کلاینت و سرور مایکروسافت و سرویس های مربوطه ، سیستم عامل لینوکس و... ، سابقه کار با سازمان ها و شرکت های مختلف در زمینه سرویس های مایکروسافت در قالب پروژه ، مشاوره و آموزش. علاقه مند به حوزه امنیت اطلاعات و تست نفوذ سنجی

نظرات