آموزش DFS در ویندوز سرور: DFS Namespace و DFS Replication

در ویندوز سرور، DFS یا Distributed File System سیستمی است شامل دو خدمت اصلی – فضای نام (DFS Namespace) و تکرار فایل (DFS‑Replication) – که به سازمان‌ها امکان می‌دهد تا مجموعه‌ای از اشتراک‌های SMB پراکنده بر روی سرورهای مختلف را به صورت یک ساختار منطقی واحد (نام «DFS Root») ارائه دهند؛ به این ترتیب کاربران با یک مسیر مانند \\DomainName\DFSRoot بدون توجه به محل فیزیکی فایل‌ها به آنها دسترسی دارند. این روش شفاف‌سازی مکان فایل‌ها، افزایش دسترسی‌پذیری، تحمل خطا و توزیع بار را ممکن می‌سازد چون در صورت خرابی یک سرور یا بارگذاری بیش‌از‌حد، کاربران به‌طور خودکار به نمونه Azure Share روی سرور دیگر هدایت می‌شوند. در این زمینه، دو نوع فضای نام قابل پیاده‌سازی است:
Standalone namespace – پیکربندی مستقل که همه اطلاعات در رجیستری سرور ذخیره می‌شود، احتیاجی به AD ندارد و قابلیت fail‑over ندارد،
و Domain‑based namespace – پیکربندی مبتنی بر AD که اطلاعات در Active Directory ذخیره می‌شوند، امکان داشتن چند سرور DFS Root (می‌تواند DC یا Member) برای redundancy و load‑balancing را فراهم می‌سازد.

اجزای معماری DFS و نقش آن‌ها

معماری DFS در ویندوز سرور حول دو مولفه اصلی—DFS Namespace برای ارائه یک ساختار منطقی و یکتا (امکان دسترسی از طریق \\<NamespaceRoot>\…) و DFS Replication برای همگام‌سازی مؤثر فایل‌ها در چند سرور—ساخته شده است؛ ادغام با Active Directory (در نوع Domain-based) به ذخیره‌سازی جداگانه‌ی پیکربندی‌ها و امکان افزونگی و دسترس‌پذیری بالا کمک می‌کند و ترافیک را با استفاده از فناوری Remote Differential Compression به حداقل می‌رساند، و در مجموع گزینه‌ای مناسب برای ساخت محیط فایل‌استوریج پایدار، مقیاس‌پذیر و قابل اتوماسیون در سازمان فراهم می‌سازد.

1. DFS Namespace (فضای نام DFS)

فضای نام بخشی از DFS است که مسیرهای SMB اشتراکی را در چند سرور به یک درخت منطقی با ریشه (namespace root) تبدیل می‌کند؛ کاربران فقط با یک مسیر متحد (مثلاً \\Contoso\MyDocs) به فایل‌ها دسترسی دارند و نمایش محل فیزیکی فایل‌ها برای آن‌ها شفاف است. این مدل دو نوع پیکربندی دارد:

• Standalone namespace که محیطی محدود در یک سرور با اطلاعات محلی بدون تکیه بر AD ارائه می‌دهد.

• Domain-based namespace که پیکربندی آن در AD ذخیره می‌شود و امکان افزونگی و داشتن چند سرور Namespace Root را دارد.

2. DFS Replication (تکرار فایل DFS‑R)

یخچالی برای انتقال تغییرات فایل بین سرورهای DFS است که فقط بلوک‌های تغییر یافته فایل را با استفاده از Remote Differential Compression (RDC) منتقل می‌کند، بنابراین بهینه، سریع و مناسب برای شبکه‌های با پهنای‌باند محدود است. در قالب Replication Group (با چند Replicated Folder) قابل پیکربندی و کنترل از طریق ابزار گرافیکی یا پاورشل است. این سیستم multi‑master عمل می‌کند یعنی هر سرور عضوی می‌تواند تغییر ایجاد کند و آن تغییر به همه اعضا انتشار یابد.

بیشتر بخوانید: ریست iLO سرورهای HP: راهنمای کامل ریست سخت افزاری ilo، نرم‌افزاری و فکتوری

3. ادغام با Active Directory (فقط در حالت Domain‑based)

هنگامی که از Namespace domain‑based استفاده می‌کنید، تمام ساختار درختی و Link‌های آن به‌صورت تکثیر‌شده در AD ذخیره می‌شوند. این روش چند مزیت مهم دارد:

• امکان استفاده از چند DFS Namespace Server هم‌زمان (متقارن یا متوالی) برای افزونگی و تعادل بار.

• پشتیبانی از مجوزهای افزونه مانند Access-based Enumeration (ABE) از طریق AD.

• ساده‌سازی تغییر سرور Root یا مهاجرت آن ‌بدون بازنشانی مسیر‌های مشتریان (clients).

4. توپولوژی‌های Replication و حل تعارض

DFS‑R از سه نوع توپولوژی اصلی پشتیبانی می‌کند:

توپولوژی	ساختار	ویژگی بارز
Full‑Mesh	هر سرور با همه اعضا ارتباط دارد	بالاترین تداوم فعالیت؛ مناسب حداکثر تا ۱۰ سرور
Hub‑and‑Spoke	یک یا چند hub به چند spoke	مصرف پهنای‌باند بهینه در سناریوهای شعب چندگانه
Custom (No‑topology اولیه)	پیش‌فرض نیست؛ مدیران آن را به‌دلخواه تعریف می‌کنند	انعطاف بالا برای سناریوهای خاص

کنترل تعارض (Conflict) در صورت تغییر هم‌زمان فایل روی چند سرور با سیاست “Last Writer Wins” انجام می‌شود و نسخه‌های قدیمی به پوشه‌های Conflict یا Deleted فرستاده می‌شوند. برای جلوگیری از ازدحام داده، استفاده از Staging Folder ضروری است.

مقایسه DFS با NAS و SAN

در مقایسه‌ی DFS با NAS و SAN، DFS مانند یک نرم‌افزار «مجازی‌سازی فایل» بر روی ویندوز عمل می‌کند که به‌واسطه‌ی آن یا کاربران مسیر ثابت و شفاف می‌بینند؛ تغییر سرور فیزیکی یا مهاجرت دیتا زیرساختی ندارد. NAS حکم یک جعبه مستقل را دارد که فایل‌ها را نگهداری و توزیع می‌کند، اما بدون تجمیع هوشمند مسیرها؛ مزیتش کاربری آسان‌تر و نگهداری ساده‌تر است. اما SAN دقیقا برای بارهای کاری حساس طراحی‌شده که نیازمند سرعت بالا، تاخیر پایین و امکانی کنترل‌شده برای تخصیصِ بلاک‌ سطحی ذخیره‌سازی هستند—ویژگی‌هایی که نه فقط هزینه بلکه پیچیدگی مدیریت را بالا می‌برد. در عمل، DFS برای توزیع سرورهای فایل و بالا بردن دسترس‌پذیری خوب است؛ NAS برای اشتراک‌گذاری ساده و اقتصادی فایل؛ و SAN برای بارهایی مانند بانک اطلاعاتی و مجازی‌سازی که حتی کم‌ترین تأخیر مهم است—در حالی که استقرار SAN فقط در سازمان‌هایی توجیه‌پذیر است که منابع، پشتیبانی و بودجه کافی داشته باشند.

راهکار	هزینه (معمول)	مقیاس‌پذیری	پیچیدگی مدیریت
DFS (سرور ویندوز)	کم تا متوسط (استفاده از سخت‌افزار موجود و Windows Server)	متوسط تا زیاد (افزودن سرور در DFS-R ،namespace چند سرور Domain-based)	متوسط (نیاز به طراحی Replication topology و AD-aware)
NAS (فایل-سرور appliance)	کم (turnkey appliance + لایسنس کم)	متوسط (scale‑up/scale‑out محدود در برخی برندها)	کم (تنظیمات GUI تحت وب، بدون پیچیدگی شبکه جداگانه)
SAN (Block‑level storage)	زیاد (هاردافزار FC/iSCSI، سوئیچ، HBAs، لایسنس)	زیاد (قابلیت افزایش ظرفیت و Performance کالوس استوریج)	زیاد (نیاز به متخصص Fibre/iSCSI، MPIO، SAN zoning و HA)

بیشتر بخوانید: راهنمای خرید کارت گرافیک سرور HPE

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

برای استفاده از DFS Namespace یا DFS Replication، باید نقش‌های Windows Server File and Storage Services شامل FS‑DFS-Namespace و FS‑DFS-Replication نصب‌شده باشند. اگر قصد استفاده از Domain‑based namespace با حالت Windows Server 2008 mode را دارید، نیاز است که forest functional level حداقل Windows Server 2003 و domain functional level حداقل Windows Server 2008 باشد و تمام سرورهای namespace با یکی از سیستم‌عامل‌های Windows Server 2008 R2، 2012، 2012 R2، 2016، 2019 یا 2022 اجرا شوند. همچنین، DFSR فقط روی حجم‌های فرمت‌شده به NTFS قابل اجراست (پشتیبانی از ReFS یا FAT وجود ندارد) . این راه‌حل فقط در داخل Active Directory forest واحد قابل تنظیم است و باید خدمات AD DS و سلامت DC‌ها کاملاً تأمین و در صورت نیاز به مهاجرت SYSVOL از FRS به DFSR اقدام آگاهانه انجام شود.

علاوه بر موضوعات فوق، باید موارد برنامه‌ریز شده‌ای برای پهنای باند DFS-R (تعیین زمان‌بندی و محدودیت Mbps)، تخصیص فضای کافی برای Staging Hidden Database (حداقل معادل اندازه ۳۲ فایل بزرگ) و فعال‌سازی Remote Differential Compression (RDC) انجام شود تا ترافیک WAN بهینه گردد. همچنین، تنظیم مناسب SwiftFailover جهت دیتاسنتر یا branch office ها، پیاده‌سازی صحیح Share و NTFS Permissions و بررسی استثناءهای آنتی‌ویروس با توجه به فایل‌های DFSR برای جلوگیری از اختلال در عملیات، الزامی است:

ردیف	دسته‌بندی	توضیح / پیش‌نیاز	پیشنهاد برای مدیر IT
۱	سیستم‌عامل و Functional Level	پشتیبانی از سرور DFS با Windows Server 2008 R2/2012/2016/2019/2022؛ forest FL ≥ 2003 و domain FL ≥ 2008 (برای Windows Server 2008 mode)	در سازمان‌های متوسط به بالا استفاده از Windows Server 2016 یا 2019 همراه با قابلیت اعطای Domain Controller حتی برای ‌VM سیس‌ادمین
۲	Active Directory	پیوستن به دامنه (برای domain-based)، تک‌forest AD DS، صحت Replication، و در صورت وجود FRS، مهاجرت SYSVOL به DFSR	قبل از راه‌اندازی DFS، از Health Check برای AD و مستندسازی طرح بازگشت RMS (rollback plan) اطمینان حاصل شود
۳	نصب Roleهای DFS	نصب FS‑DFS‑Namespace و FS‑DFS‑Replication بر روی هر سرور DFS	نصب از طریق GUI یا PowerShell: Install‑WindowsFeature FS‑DFS‑Namespace, FS‑DFS‑Replication –IncludeManagementTools
۴	فایل‌سیستم	حتماً باید از NTFS استفاده شود؛ ReFS یا FAT پشتیبانی نمی‌شود	در استفاده از RAID یا آرایه‌های ذخیره‌سازی اچ‌پی، فکر کنید روی RAID 10 با حجم مجزا برای DFS Staging
۵	بهینه‌سازی و multipartition	پیکربندی staging quota به‌اندازه کافی؛ فعال‌سازی RDC روی لینک‌های DFS‎R	تعیین حداقل staging برابر با بزرگ‌ترین ۳۲ فایل؛ آزمایش اولیه با بهره‌گیری از Hot-Add فضای staging در صورت نیاز
۶	شبکه و امنیت (Firewall/DNS)	ارتباط پایدار TCP/445 بین سرورهای DFS-R در هر دو طرف؛ DNS کامل به سرورها؛ زمان‌بندی ترافیک برای replication	برقراری Site-to-Site VPN یا VPLS در دفاتر branch؛ مانیتور Link با SNMP و ping‌های روزانه
۷	سطح دسترسی و مجوزها	مجوز NTFS و Share با min. Read برای کاربران نهایی؛ عضویت در گروه‌های ادمین برای راهبری DFS؛ delegate کامل برای SYSVOL اگر شده فابر	ایجاد GPO که پوشه‌های DFS را excluded (استثناء) کند؛ برنامه‌ریزی نقشه‌دهی بر خط سبک
۸	قابلیت‌های ذخیره‌سازی: سخت‌افزار و ارتقاء	سرورهای HP باید دارای حداقل ۴ گیگابایت RAM (۱۰۴۸ مگابایت برای هر ۱۰ هزار فایل DFSR)، CPU ≤۴ هسته، فضای staging مستقل با حداقل ۱۰٪ حجم فایل‌ها	سازماندهی به گونه‌ای که سخت‌افزار حداقل مطابق با Tier 2 باشد؛ برای مقیاس‌پذیری، مجازی‌سازی با ReFS پیشنهاد نمی‌شود، بلکه تأکید بر NTFS
۹	Scalability و محدودیت‌ها	حداکثر فایل‌های قابل Replicate تا ۱۰ میلیون روی Windows Server 2008/2012 و تا ۷۰ میلیون روی 2012 R2/2016/2019، تا ۱۰۰ ترابایت حجم کلی فایل روی هر Volume	برای پوشه‌های حجیم، از pre‑seed با database cloning استفاده شود؛ محدودیت‌ها را حداقل ماهانه دنبال کنید
۱۰	نسخه و Migration mode نام‌فضا (Namespace mode)	برای فضای نام با دسترس‌پذیری بالا، استفاده از “Domain‑based namespace (Windows Server 2008 mode)” ترجیح دارد؛ برای حالت standalone نیازی به AD نیست	در سازمان‌های روبه رشد، فقط از Windows Server 2008 mode برای namespace استفاده شود؛ اگر پایه ساختار قدیمی است، حتماً مهاجرت از Windows 2000 mode به 2008 mode در roadmap داشته باشد

جمع‌بندی سریع و نکات اجرایی برای پیاده‌سازی:

• ابتدا صحت سلامت AD DS، قابلیت ارتقا به functional level مناسب و رفع‌معایب FRS را بررسی کنید.

• حتماً از سرورهای مخصوص DFS (‌Member یا DC) با سیستم‌عامل ≥ Windows Server 2016 استفاده نمایید.

• فضای staging، پهنای باند، و شرایط شبکه را قبل از آغاز replication اندازه‌گیری و پیکربندی کنید.

• مجوزهای share و NTFS را صحیح تنظیم کرده و حتی‌الامکان روی فایل‌سرورهای فیزیکی اچ‌پی قراردادهایی با vendors معتبر برای پشتیبانی و گارانتی قطعات داشته باشید.

آموزش کامل پیکربندی DFS Namespace

۱. نصب نقش DFS Namespaces

• در Server Manager → افزودن نقش‌های (Add Roles and Features) → انتخاب DFS Namespaces (خدمت FS‑DFS‑Namespace). برای استفاده‌ی کامل از قابلیت‌های مدیریتی، گزینه “Include management tools” را نیز فعال کنید.

• تحت PowerShell می‌توان با فرمان زیر نصب را انجام داد:

  Install‑WindowsFeature FS‑DFS‑Namespace –IncludeManagementTools


• برای افزونگی نام‌فضا (Domain-based)، functional level دامنه باید حداقل Windows Server 2008 (DomainV2) باشد و forest FL ≥ 2003 برای ایجاد “Windows Server 2008 mode” لازم است.

۲. مجوز مدیریتی

• باید عضو گروه Administrators بوده یا مجوزهای مدیریت DFS Namespace به شما واگذار شود.

• محل فولدر C:\DFSRoots<Namespace> یا هر مسیر دلخواهی باشد، باید فقط به اکانت‌های اداری اجازه نوشتن داده شود تا پیکربندی امن بماند.

۳. خرید و کیفیت سخت‌افزار

• پیشنهاد می‌شود فولدر root namespace روی یک درایو جداگانه از سرور HP ذخیره شود (RAID۱ یا RAID۵ بسته به حجم). HD باید دارای حافظه ۱ الی ۲ GB RAM و فضای کافی برای staging فایل‌های DFS باشد؛ در صورت گستره فایل بالا، RAM بیشتر (حداقل ۴ گیگ توصیه می‌شود).

۴. تنظیم DNS

• اگر قصد دارید پس از ساخت نام‌فضای DFS، نام سرور قدیمی (مثلاً fileserver01) روی آن takeover شود، باید یک CNAME در DNS ایجاد و به مسیر namespace ارجاع داده شود (مثلاً fileserver01.contoso.com → dfsroot.contoso.com).

---

۲. ایجاد Namespace: از طریق GUI یا PowerShell

یا برای standalone:

۳. بررسی نتیجه با Get-DfsnRoot
| مناسب برای اسکریپت اولیه یا تهیه Rapid Deployment؛ قابل استفاده در سرورهای غیر مراقبت‌شده |

توضیح پارامترهای PowerShell:

• -Path: مسیر Namespace root موردنظر.

• -TargetPath: مسیر فولدر اشتراکی که قرار است به عنوان محتوا لینک شود.

• -Type: Standalone, DomainV1 (Windows 2000 mode) یا DomainV2 (Windows Server 2008 mode) .

---

۳. اضافه کردن سرورهای DFS Namespace برای افزونگی (High Availability)

اگر Domain-based namespace ایجاد کرده باشید، امکان افزودن چند سرور به عنوان Namespace Servers وجود دارد تا در صورت مشکل سرور اصلی، دسترسی همچنان برقرار باشد. مراحل:

1. در DFS Management Console

   • روی نام Namespace راست‌کلیک → انتخاب Add Namespace Server

   • درج FQDN یا انتخاب از کنسول (Browse)

   • تأیید و اضافه کردن به فهرست Servers .

2. از طریق PowerShell:

   New-DfsnRootTarget -Path "\\Domain\SalesFiles" -TargetPath "\\Srv2-SHARE\Sales" -State Online


   سرور Srv2 به عنوان یک namespace server دیگر اضافه خواهد شد.

با این روش می‌توانید توازن بار ورودی (load balancing) و پایداری بیشتر ایجاد کنید—برای سازمان‌هایی با نیاز بالا به دسترسی همواره‌زمان.

---

۴. ساخت ساختار درختی: اضافه کردن Folder و Folder Target

یکی از بخش‌های کاربردی Namespace، افزودن فولدرهای وابسته است:

۱. انتخاب Namespace موردنظر → New Folder
۲. نام پوشه (مثلاً Sales Docs) وارد می‌شود و سپس Folder targets به آن افزوده می‌شوند (مثلاً \\SrvA\Sales, \\SrvB\Sales)
۳. گزینه‌هایی مثل Enable_access_based_enumeration (ABE) و Referral Priority تنظیم می‌شوند.
۴. در صورت multi-site، می‌توانید Site Costing را بر مبنای لینک‌های شبکه تعیین کنید تا کاربر به نزدیک‌ترین سرور هدایت شود.

همچنین امکان استفاده از PowerShell برای ایجاد فولدر و هدف:

---

۵. تنظیم Permissions و امنیت

۱. روی فولدر مشترکی که به عنوان Namespace root ساخته‌اید، NTFS Permissions و Share Permissions را طوری تنظیم کنید که فقط گروه‌های ادمین یا گروه DFS administrators حق کنترل داشته باشند و کاربران فقط Read/Execute داشته باشند (یا Write اگر لازم است).

۲. در حالت Domain-based، از قابلیت Access-based Enumeration (ABE) برای مخفی‌سازی فولدرهای بدون دسترسی کاربران استفاده کنید.

۳. پیشنهاد می‌شود Share و NTFS را روی همان فولدر پایه مجزا تعریف کرده و کنترل گروهی روی آن اعمال شود تا فضای پیکربندی امن بماند.

---

۶. نکات و بهترین روش‌ها

• فقط یک namespace برای همه‌ی ساختار توصیه می‌شود؛ استفاده از چند namespace سخت‌مدیریت‌تر و پیچیده‌تر است.

• بهتر است از Domain-based namespace در حالت Windows Server 2008 mode (DomainV2) استفاده کنید، چون امکان High Availability و افزودن Namespace Servers بیشتر فراهم است. برای شبکه‌هایی که CNAME takeover لازم دارند، standalone گزینه مناسب‌تری است.

• همیشه پس از ایجاد Namespace با استفاده از Get-DfsnRoot و Get-DfsnFolderTarget صحت تنظیمات را بررسی کنید، همچنین رویدادهای Event Viewer (Microsoft‑Windows‑DFS‑Namespace/Operational) را بررسی کنید.

• در پروژه‌های سازمانی با استفاده از سرورهای HP، برای هر فولدر target از یک کانال شبکه‌ی مجزا با حداقل لینک 1 Gbps استفاده کنید تا performance پایدار باشد. طراحی RMS برای پشتیبان‌گیری و رفع خطاهای احتمالی برای active-passive بودن ضروری است.

• در صورت نیاز به مهاجرت NameSpace از سرور FTP یا NAS به DFS، می‌توانید با استفاده از DNS CNAME و گزینه takeover در GUI یا PowerShell (-Path با #Name در حالت Standalone takeover) مهاجرت بدون قطعی احتمالی انجام دهید.

آموزش DFS Replication (تکرار فایل‌ها)

DFS Replication (یا DFS‑R) یک موتور active‑active فایل ریپلیکیشن در ویندوز سرور است که با استفاده از Remote Differential Compression (RDC) فقط بلوکی از تغییرات فایل‌ها را روی لینک‌های WAN یا LAN ارسال می‌کند؛ این مکانیزم باعث کاهش مصرف پهنای‌باند، تحمل خطای بالا و هماهنگی موثری بین سرورهای فایل سازمانی می‌شود، بدون نیاز به سخت‌افزار بلاک استوریج اختصاصی. این سرویس به‌طور کامل با DFS Namespace و AD ادغام شده و می‌تواند روی سرورهای HP استاندارد با NTFS اجرا شود.

مرحله	با GUI (DFS Management Wizard)	با PowerShell
۱	Server Manager → Add Roles → File and Storage Services → DFS Replication	Install-WindowsFeature FS-DFS-Replication
۲	Folder یا Namespace موردنظر → «Replicate Folder…» Wizard	ساخت Replication Group:New-DfsReplicationGroup -GroupName "RG01" افزودن Replica Folder:New-DfsReplicatedFolder -GroupName "RG01" -FolderName "Data01"
۳	انتخاب اعضا (Servers)، تعیین Primary و مسیر Content ⇒ ادامه Wizard	افزودن اعضا:Add-DfsrMember -GroupName "RG01" -ComputerName "SRV01","SRV02" Primary + Staging:Set-DfsrMembership -GroupName "RG01" ... -PrimaryMember $True -StagingPathQuotaInMB 20480
۴	تعیین Topology (Full‑Mesh یا Hub‑and‑Spoke)، زمان‌بندی و محدودیت پهنای‌باند	Add-DfsrConnection -GroupName "RG01" -SourceComputerName ... -DestinationComputerName ... تنظیم برنامه با:Set-DfsrConnectionSchedule
۵	بررسی فرآیند replication و رفع خطا در Health Report Wizard یا PowerShell cmdlet	Write-DfsrHealthReport –GroupName "RG01" برای گزارش سلامتی و‌‌dfsrdiag backlog… برای مشاهده backlog

اگر قصد دارید نسخه اولیه را به‌سرعت در سرور مقصد داشته باشید، فایل‌ها را با Robocopy.exe قبل از ساخت گروه DFS‑R ریسِد کنید (pre‑seeding) — این روش حجم ترافیک اولیه را بسیار کاهش می‌دهد.

تعیین حجم Staging Folder (قواعد مایکروسافت)

ویژگی	مقدار پیشنهاد‌شده
اندازه پیش‌فرض	~۴۰۹۶ MB
محاسبه Staging Quota	حداقل برابر مجموع ۳۲ فایل بزرگ‌ترین در Replicated Folder
مثال عملی	اگر ۳۲ فایل بزرگ در مجموع ۷۰ گیگ هستند ⇒ Staging ≥۷۰GB

• اگر حجم پوشه بزرگ یا تغییرات مداوم دارید، Staging باید بزرگ‌تر باشد (تا 100٪ حجم فایل برای Replication‌های حجیم).

• هنگام اجرای Robocopy یا pre‑seed، نیازی به Staging بالا نیست؛ اما برای اولتیم synchronization، افزایش موقت آن به اجرای روان تر کمک می‌کند.

انتخاب توپولوژی برای کارایی بهتر

سایت‌ها (Members)	توپولوژی پیشنهادی	مزیت اصلی
≤ ۱۰ سرور در شبکه خوب	Full-Mesh	ارتباط مستقیم، تأخیر کمتر، پایداری بالا
مرکز HQ + شعبه‌ها	Hub‑&‑Spoke	مصرف کمتر WAN، طراحی مدیریتی ساده‌تر
حالت خاص (مثلا شعبه‌هایی با چند Site Costs)	ساخت دستی اتصالات در PowerShell	کنترل دقیق بر تخصیص منابع ترافیک

DFSR نیازمند این است که هر سرور هر دو اتصال inbound و outbound داشته باشد (full connectivity) حتی در طراحی‌های read-only.

نکات مهم و بهترین روش‌ها

Handle Conflict (مواجهه با تعارض در تکرار Concurrent)

• DFS-R از الگوریتم «Last Writer Wins» استفاده می‌کند و فایل‌های قدیمی‌تر را به مسیر پنهانی DfsrPrivate\Conflict and Deleted می‌فرستد؛ فایل جدیدتر باقی می‌ماند.

• این پوشه در هیچ‌جای دیگری کپی نمی‌شود و تحت quota حذف می‌شود؛ در صورت حجم زیاد می‌توانید وقفه replication را بررسی کنید.

فیلتر و استثنائات

• از فیلتر فایل (File/Directory Filters) در New-DfsReplicatedFolder برای حذف فایل‌های temp مثل ~*, *.bak, *.tmp استفاده کنید.

• پوشه‌های سیستم (DfsrPrivate, Staging, Conflict) نباید در مواجهه با quоta یا file screening باشند.

تعریف شبکه و تنظیمات امنیتی

• باید اجازه دسترسی TCP 135 + پورت‌های RPC >۱۰۲۴ بین اعضا بدهید؛ برای سرعت پایدار، در شبکه بین شعبه از VPN یا LB برای حذف Packet loss استفاده شود.

• عبور از فایروال‌های سازمانی برای port 445 و RPC اتوماتیک و زمان‌بندی حدود ۶۰ دقیقه AD polling در DFS-R باید فعال باشند.

نظارت و عیب‌یابی (Monitoring & Health)

• از DFS Management Console → Replication → Generate Diagnostic Report استفاده کنید.

• در PowerShell: Get-DfsrState, Get-DfsrBacklog, Write-DfsrHealthReport.

• در صورت ایجاد مشکل مثل Event IDs:

  • 4202/4204: Staging پر است → پاک‌سازی فایل‌های قدیمی رخ داده.

  • 4212: فضای staging تمام شده، جلوگیری از تکرار.

  • 6002/6016 یا مربوط به SYSVOL: مشکل Sync کنترلی در AD وجود دارد.

مقایسه Topology‌های DFS Replication

در جدول زیر، مقایسه جامع بین سه توپولوژی اصلی DFS Replication ارائه شده است:

توپولوژی	ساختار اتصالات Replication	مناسب برای چه سناریویی؟	مزایا	معایب / نکات کلیدی
Full Mesh (دوبه‌دو)	هر سرور به تمام سرورها متصل; اتصال‌های دوطرفه (inbound/outbound) میان زوج‌ها تعریف می‌شود؛ ترافیک همگام‌سازی مستقیم بین همه‌ی اعضاست.	محیط LAN داخلی، تعداد سرورها ≤ 10؛ Multipurpose replication group برای اشتراک‌گذاری دوطرفه داده­ها.	بیشترین دسترس‌پذیری (از تکرار محلی و جانشینی در صورت قطع هر عضو)، تغییرات هر سرور مستقیماً در سایرین منعکس می‌شوند، بی‌نیاز به hub مرکزی برای انتقال.	بار شبکه بالا؛ اتصال بین هر زوج لازم است؛ برای سناریوهای WAN یا تعداد >10 سرور توصیه نمی‌شود (پیشنهاد رسمی مایکروسافت تا 10 سرور ≈< turn0search2>).
Hub and Spoke (ستاره‌ای)	تمام spoke‌ها دو اتصال دارند: inbound/outbound فقط با یک یا دو hub (اگر redundancy نیاز باشد، hub دوم اضافه می‌شود). اتصال بین spoke‌ها تعریف نمی‌شود.	طراحی شعبه اصلی یا دفاتر branch office؛ انتشار متمرکز یا جمع‌آوری داده به hub؛ ideal برای WAN یا دفاتر پراکنده بدون ارتباط بین شعب.	مصرف پایین‌تر پهنای‌باند WAN، کنترل متمرکز بر داده‌ها و امکان طراحی read-only برای spoke با استفاده از مجوزهای NTFS/share؛ امکان اضافه‌کردن hub دوم برای افزونگی.	تک نقطه شکست (single point of failure) در hub؛ تغییرات روی spoke همچنان به hub ارسال می‌شوند (چون DFS-R multi‑master است) ـ برخلاف تصور رایج، که ممکن است تغییرات محدود به hub باشند؛ مدیریت hub‌ها در صورت تعداد spoke زیاد، پیچیده می‌شود. |
No Topology / Custom	هیچ اتصالی در مراحل Wizard ایجاد نمی‌شود؛ مدیران باید با PowerShell یا DFS Management tool اتصالات دلخواه را تعریف کنند.	طراحی‌های خاص یا هیبرید: مانند ring topology، چند hub مجزا، یا مدل «spoke-to-multiple hub»، تطبیق دقیق با توپولوژیِ شبکه سازمان.	انعطاف کامل؛ می‌توانید بیشترین بهره‌وری ترافیک و کاهش مصرف لینک را تعریف کنید یا طراحی مقطعی برای مهاجرت داشته باشید.	نیاز به دقت بالا‌تر در پیکربندی؛ در صورت فراموش کردن ایجاد ارتباط، replication انجام نمی‌شود؛ مستلزم مستندسازی و کنترل دقیق‌تر است.

• مایکروسافت در مستندات رسمی توصیه می‌کند که Full Mesh تنها تا ۱۰ سرور استفاده شود، چرا که بالاتر از آن سربار (overhead) شبکه و منابع سنگینی را ایجاد می‌کند.

• گزینه Hub and Spoke در New Replication Group Wizard فقط در صورت انتخاب ۳ یا بیشتر سرور ظاهر می‌شود و امکان تعیین دو hub برای redundancy فراهم است.

• اگر تیم فنی سازمان به شدت به انتخاب دقیق اتصالات نیاز دارد (مثلاً موارد WAN با نیاز متنوع)، بهترین گزینه، انتخاب حالت No Topology است تا بتوان ATP اتصالات را sèl manually مدیریت کرد.

زمان‌بندی Replication و توصیه‌های عملی برای سازمان‌ها

در جدول زیر، الگوهای رایج زمان‌بندی DFS‑Replication برای سناریوهای مختلف شبکه‌ای (LAN داخلی، WAN بین‌شعبه، دفاتر شعبه)، همراه با محدودیت پهنای‌باند و توصیه‌های فنی مناسب، گردآوری شده است. این پیشنهادها طبق مستندات رسمی مایکروسافت و تجربه مدیریت DFS تدوین شده‌اند:

سناریو / موقعیت شبکه	زمان‌بندی پیشنهادی (به وقت محلی سرور دریافت‌کننده)	نرخ پهنای‌باند (Throttle)	توصیه‌های عملی برای پیاده‌سازی
۱. لینک LAN داخلی با ترافیک بالا	۲۴×۷ فعال (بدون محدودیت زمان)	بدون محدودیت / Full	• زمان‌بندی گروهی یا اتصال را روی continuous قرار دهید تا تغییرات فوراً و بدون تأخیر منتشر شوند.• RDC مفید نبوده یا اثر کمی دارد چون پهنای‌باند بالاست؛ در این حالت ممکن است آن را برای کاهش CPU غیرفعال کنید.
۲. لینک WAN شعبه تا HQ (تغییر متوسط)	Replication window شبانه: مثلاً ۰۱:۰۰ الی ۰۶:۰۰ یا ۲۲:۰۰ الی ۰۶:۰۰	۲۰–۶۴ Kbps برای لینک‌های محدود یا Full برای خطوط ≥۵ Mbps	• برای جلوگیری از backlog، replication را در ساعات اداری قطع کنید و شب‌ها بدون throttle یا با نرخ بالاتر اجرا کنید. این روش به کاهش هم‌زمان بار ترافیک روزانه و رهایی از قفل‌های انتقال کمک می‌کند. • از PowerShell یا DFS Management برای تنظیم “custom per‑connection schedule” استفاده کنید. |
۳. دفاتر شعبه پراکنده با تغییرات کم (Passive)	شکاف هفتگی یا آخر هفته: جمعه تا شنبه یا شب‌های آخر هفته	محدود به ۵۰–۱۲۸ Kbps یا Full بسته به SLA	• برای کاهش ترافیک روزمره، replication-heavy را به بازه آخر هفته موکول کنید.• توجه کنید: replica های send only در دستور Non‑master (مانند branch‌های read‑only). Backlog آخر هفته باید به صف قبل از start دوره بعدی برسد.
۴. لینک با پهنای‌باند بسیار محدود (مثلاً ISDN/Dial‑up)	پنجره ۱۰۰٪ Off‑peak شبانه یا آخر هفته	محدود از ۱۶ Kbps تا ۶۴ Kbps	• در این حالت throttle دقیق ضروری است، چون DFS-R امکان تشخیص خودکار پهنای باند ندارد.• خروجی burst بسته به RPC-buffer است، بنابراین شبکه ممکن است لحظاتی اشباع شود.
۵. محیط چند‌منطقه‌ای با اختلاف زمانی (Time‑Zone)	Define schedule به صورت UTC ثابت یا ساعات محلی مدل‌سازی‌شده	بر اساس هر منطقه، throttle متفاوت	• انتخاب واحد زمان “UTC” در replication group کمک می‌کند در DST یا اختلاف زمانی پیچیده یکنواخت عمل کند.• توصیه می‌شود تنظیمات گروهی با New‑DfsReplicationGroup –ScheduleType UTC تدوین شود تا محل اجرا روی تمام PR(replica receiving) متمرکز باشد.

نکات فنی برای موفقیت در زمان‌بندی Replication

• فاصله نمونه (Granularity): فقط می‌توانید پنجره‌هایی با دقت ۱۵ دقیقه تنظیم کنید (ساعات به ۴ ربع ۱۵ دقیقه تقسیم شده) .

• تشخیص محدودیت واقعی: DFS-R قادر به سنس پهنای‌باند لینک نیست؛ throttle تنها با محدود کردن تماس‌های RPC عمل می‌کند و ممکن است منجر به burst لحظه‌ای شود.

• بهینه‌سازی حجم staging: اگر حجم تغییرات بیش از توان لینک است، staging quota باید حداقل برابر حجم ۳۲ فایل بزرگ‌ باشد تا overflow زیاد نشود.

• ڈ Monitoring Backlog: پیشنهاد می‌شود با dfsrdiag backlog یا PowerShell تشخیص دهید آیا replication backlog پس از پایان پنجره تمام شده است یا خیر. اگر رشته backlog باقی ماند، نیاز به گسترش پنجره یا افزایش throttle است.

• تست در محیط شبیه‌سازی: قبل از اجرایی کردن در محیط واقعی، بهتر است بازده replication تحت تغییرات مختلف (ران ساعت، حجم زیاد، DNS یا AD replication latency) در شبکه مشابه تست شود.

مانیتورینگ و عیب‌یابی DFS

در محیط‌های سازمانی، اطمینان از پایداری و همگام‌سازی صحیح DFS Replication نیازمند مشاهده مداوم عملیات و واکنش به هشدارهای سیستمی است. به‌عنوان یک مدیر فناوری اطلاعات با تجربه، ابتدا با ابزار داخلی DFS Management Console شروع کنید تا سلامت replication group را بررسی کرده و یک Health Report دوره‌ای (مثلاً با استفاده از PowerShell یا dfsradmin.exe) تنظیم کنید تا بر backlog، راندمان انتقال یا خطاهای replication نظارت داشته باشید . ابزار قدرتمند دیگری که اهمیت زیادی دارد‌، دستور dfsrdiag.exe است؛ با اجرای پارامترهایی مانند backlog و propagation test می‌توانید تعداد فایل‌های ناتمام replication و زمان باقی‌مانده را اطلاع‌رسانی کنید و موارد تعارض یا خطا را شناسایی نمایید . اگر سازمان شما از System Center Operations Manager استفاده می‌کند، نصب DFS Replication Management Pack به شما امکان ارسال هشدار بر حسب شرایط مانند توقف replication، خطاهای staging یا موقعیت‌های backlog زیاد را به‌صورت اتوماتیک خواهد داد. همچنین جمع‌آوری Performance Counter‌های مکانیزم فضیله‌نشینی (staging_*), مصرف CPU، I/O و شبکه به همراه همبستگی با گزارش‌های event log (Event IDهای 4000 تا 6000 در log category DFS Replication) به تحلیل Root-Cause کمک می‌کند.

اگر دسترسی به ** DFS Namespace‌ (DFSN)** به‌طور ناگهانی دچار خطا شده یا کاربران نمی‌توانند namespace را mount کنند، بررسی دقیق‌تر ضروری است. با استفاده از ابزارهای dfsutil.exe, مخصوصا پارامترهایی مانند /pktinfo, /spcinfo, /insite /display, وضعیت **ارجاع (referral)**‌های DFSN و ارتباط با domain controllerها را کنترل کنید و مطمئن شوید که تغییرات DFSN از طریق AD به‌درستی تکثیر شده‌اند (مثلاً با دستور repadmin /showrepl) . در این فرآیند، log سیستم و eventهای مرتبط در Event Viewer از جمله خطاهای مربوط به سرویس DFS Namespaces، RPC یا مشکلات DNS باید با توجه دقیق خوانده و تحلیل شوند. همچنین مشکلات staging quotas پرشده، عدم برقراری اتصال RPC بین سرورها، قفل‌های فایل یا تغییرات فیلتر اشتباه روی فایل‌ها می‌توانند باعث ایجاد خطای replication یا توقف آن ‌شوند—رویکرد تولید گزارش سلامت برای پیدا کردن ریشه خطا و بررسی تنظیمات استثنائات فایل‌ها ضروری است.

خرید سرور با گارانتی یاقوت سرخ

نکات امنیتی و پشتیبان‌گیری در DFS

• برای Namespace از حالت Domain‑based استفاده کرده و حداقل دو Nameserver از دو سیستم متفاوت (ترجیحاً غیر DC) داشته باشید تا از نقاط شکست (SPOF) جلوگیری شود و امنیت و در دسترس‌پذیری namespace حفظ گردد.

• همیشه از Access‑Based Enumeration (ABE) استفاده کنید تا کاربران فقط فولدرهایی را ببینند که به آن‌ها دسترسی دارند؛ این گزینه در تنظیمات Namespace قابل فعال‌سازی است .

• معرفی مجدد referral caching، تنظیم TTL و کنترل polling AD نیز گزینه‌هایی هستند که باید طبق Check‑list رسمی مایکروسافت بهینه‌سازی شوند تا namespace اذیت نشود به خاطر تغییرات AD ناگهانی .

• در نظر داشته باشید که فقط NTFS permissions در replication گروه‌ها همگام‌سازی می‌شوند؛ Share permissions توسط DFS replicate نمی‌شود. پس تنظیمات اشتراک‌گذاری فولدر بهتر است با Everyone – Read یا Authenticated Users – Read باشد تا کنترل مجوزها فقط از طریق NTFS اعمال شود .

• برای انجام احراز هویت بدون استفاده از پروتکل NTLM و مشکلات fallback، پیشنهاد می‌شود SPN به‌درستی تنظیم شود. 

• همچنین خود سرویس DFS روی DC نباید با داده‌های کاربری ترکیب شود؛ جدا کردن roles به افزایش کنترل امنیتی و تفکیک ترافیک احراز هویت کمک می‌کند.

• هرگز سرویس DFS‑R را قبل از backup برای مدت طولانی غیرفعال نکنید؛ چون ممکن است USN Journal بپیچد و replication بعدی مختل شود یا به backlog سنگین منجر شود .

• اگر داده‌ای حذف یا خراب شود، اول باید تصمیم گرفت restore به صورت non‑authoritative (فقط داده‌ی local دوباره sync شود) یا authoritative (کپی خاصی از فایل‌ها به کل گروه push شود) انجام شود. انتخاب نادرست ممکن است منجر به تکرار حذف یا خراب‌سازی شود.

• در مرحله Disaster Recovery، export namespace به همراه backup AD و system‑state کمک ویژه‌ای می‌کند تا زمان بازیابی از چند ساعت به چند دقیقه کاهش یابد