راه اندازی سرویس DFS در ویندوز سرور 2012

راه اندازی سرویس DFS در ویندوز سرور ۲۰۱۲

راه اندازی سرویس DFS در ویندوز سرور ۲۰۱۲

وقتی مدیران شبکه تصمیم به راه اندازی File Server می کنند، از سرویس DFS یا Distributed File System (سیستم فایل توزیع شده)، استفاده می کنند تا روش های قدیمی و سنتی راه اندازی فایل سرور نظیر Standalone Share Point، را کنار بگذارند. دلیل عمده استفاده مدیران شبکه از سرویس DFS، افزونگی یا Redundancy ای هست که این سرویس به ارمغان می آورد. علاوه بر این سرویس DFS دسترسی پذیری راحت تر و عملکرد بهتر را برای دسترسی یافتن به فولدر های Share شده در سطح دومین را به وجود می آورد. روش های مختلفی با توجه به راه اندازی سرویس 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 Tree: یک DFS tree مرجعی است که به DFS ریشه یا روت اشاره می کند. اولین DFS tree از DFS root ایجاد می شود. DFS root شامل تمامی DFS tree های زیرشاخه خودش است که به آن لینک دارند.

DFS Replication

DFS Replication

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

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

مطلب پیشنهادی  حرف های اصلی در راه اندازی سیستم تلفنی الستیکس

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

اولین و مهم ترین سئوالی که قبل از راه اندازی سرویس 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 سرور ها به دامین یا اکتیو دایرکتوری join شده است. این نوع از محیط ها اطلاعات DFS سرور را به طور اتوماتیک بین سرور هایی که Folder Target را میزبانی می کنند، Synchronize می کند. دسترسی به سرور domain based namespaces از طریق آدرس زیر در دسترس است:

مطلب پیشنهادی  5 توزیع پیشرفته لینوکس که نباید از آنها غافل شد
Domain_Name\DFS_Root_Name\\

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

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

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

DFS Root:

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

راه اندازی سرویس DFS در ویندوز سرور 2012

راه اندازی سرویس DFS در ویندوز سرور ۲۰۱۲

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

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

مطلب پیشنهادی  VOIP چیست ؟

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

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

نتیجه گیری:

شما می توانید مطالب ذکر شده شده را درمحیط های عملیاتی برای اطمینان حاصل کردن از اینکه DFS Replication در شرایط مناسب انجام پذیرد به کار بگیرید.

منبع:Itpro.ir