DFS Namespace ve DFS Replication ile Dosya Sunucusu Tasarımı

Dosya sunucusunu değiştirmek istediğinizde asıl iş sunucu değil, ona bağlı her şeydir: yüzlerce kısayol, GPO ile eşlenen sürücüler, uygulamaların içine gömülmüş UNC yolları. Hepsi eski sunucu adını gösterir. DFS Namespace (DFS-N) kullanıcıyı sunucu adından bağımsız bir yola bağlar; DFS Replication (DFS-R) aynı içeriği birden fazla sunucuda tutar. Şubeli bir yapıda ikisini birlikte tasarlarken verilecek kararlar, yapılacak hesaplar ve işletimde bakılacak komutlar aşağıda.

DFS Namespace ve DFS-R ne çözer, ne çözmez

İkisi tek ürün gibi anılır ama birbirinden bağımsızdır. DFS-N bir yönlendirme katmanıdır: istemci \\corp.local\Dosyalar\Muhasebe yolunu istediğinde namespace sunucusu bir “referral” listesi döner, istemci gerçek paylaşıma (\\FS01\Muhasebe) kendisi bağlanır. Veri namespace sunucusundan geçmez. DFS-R ise bir klasörün içeriğini birden fazla sunucuda eşitleyen çok yöneticili (multi-master) bir replikasyon motorudur; yalnız değişen blokları göndermek için Remote Differential Compression (RDC) kullanır.

Tasarım bu ayrımla başlar:

• Yalnız DFS-N: Tek merkezli yapıda sunucu adını soyutlamak ve sonraki sunucu değişimini kullanıcıya hissettirmeden yapmak için yeterli.
• DFS-N + DFS-R: Şubede yerel kopya isteniyorsa, içerik okuma ağırlıklıysa (prosedürler, kurulum dosyaları, çizim arşivi) ve sunucu arızasında alternatif hedef gerekiyorsa.
• DFS-R tek başına: Şubeden merkeze tek yönlü veri toplama, yani yedeği merkezde almak için.

DFS-R’ın yapmadıkları da aynı netlikte bilinmeli: dağıtık dosya kilidi yoktur, eşzamanlı düzenlemede bir sürüm kaybolur, silinen dosya tüm üyelerden silinir. Sahada en sık gördüğümüz hayal kırıklığı buradan çıkar. DFS-R yedekli dosya sunucusu değildir.

Namespace türleri ve modları

Namespace oluştururken iki karar verilir: etki alanı tabanlı mı bağımsız (stand-alone) mı; etki alanı tabanlıysa hangi modda.

Windows Server 2008 modu erişime dayalı numaralandırma (access-based enumeration) desteği ve daha yüksek klasör ölçeği getirir. Koşulu, etki alanı işlev düzeyinin en az Windows Server 2008 olması ve tüm namespace sunucularının da 2008 veya üstü olmasıdır. Bugünkü ortamların neredeyse tamamı bunu karşılar; yeni kurulumda varsayılan budur. Etki alanı tabanlı namespace bilgisi AD’de tutulur, ama istemciye referral’ı namespace sunucusu verir. Tek namespace sunucusu, tek arıza noktasıdır. Her namespace için en az iki namespace sunucusu, tercihen iki farklı sitede tanımlayın.

# Etki alanı tabanlı (2008 modu) namespace ve iki kök hedef
New-DfsnRoot -Path "\\corp.local\Dosyalar" -TargetPath "\\FS01\Dosyalar" -Type DomainV2
New-DfsnRootTarget -Path "\\corp.local\Dosyalar" -TargetPath "\\FS02\Dosyalar"

# Klasör ve hedefleri
New-DfsnFolder -Path "\\corp.local\Dosyalar\Proje" -TargetPath "\\FS01\Proje"
New-DfsnFolderTarget -Path "\\corp.local\Dosyalar\Proje" -TargetPath "\\FS-IZM\Proje"

Kök paylaşımda (Dosyalar) veri tutmayın. Kök yalnızca klasör bağlantılarını taşır; veri, her biri kendi NTFS ve paylaşım izinlerine sahip ayrı paylaşımlarda durur. Kökü veri klasörü gibi kullanan kurulumlarda izinler zamanla karışır, sonraki taşıma da iki kat uzar.

Klasör hedefleri ve site farkındalığı

Bir klasörün birden fazla hedefi varsa istemcinin hangisine gideceğini referral ayarları ile Active Directory Sites and Services’teki site ve alt ağ tanımları belirler. Varsayılan sıralama “en düşük maliyet”tir: istemci önce kendi sitesindeki hedefleri, sonra site bağlantı maliyetine göre diğerlerini alır. Yani DFS tasarımının ilk adımı aslında AD’dir. Şubedeki kullanıcının merkezdeki sunucuya gitmesinin en sık sebebi, o şubenin alt ağının hiçbir siteye eşlenmemiş ya da yanlış siteye eşlenmiş olmasıdır. Yeni bir VLAN açılır, AD’ye işlenmez, istemci rastgele hedef alır. Site ve alt ağ tutarlılığını Active Directory sağlık kontrolü kapsamında düzenli doğrulamak bu yüzden DFS işletiminin de parçasıdır.

Hedef önceliği, maliyet sıralamasını belirli hedefler için ezer. Şubelere yayılmış bir sunucu altyapısında şube sunucusu yalnızca okuma kopyası olsun, yazmalar hep merkeze gitsin istiyorsanız merkez hedefini “tüm hedefler arasında ilk” sınıfına alın:

Set-DfsnFolderTarget -Path "\\corp.local\Dosyalar\Proje" `
  -TargetPath "\\FS01\Proje" -ReferralPriorityClass GlobalHigh

Ayarlanması gereken iki parametre daha var:

• Referral önbellek süresi: İstemci aldığı listeyi bu süre boyunca kullanır. Varsayılan kök için 300, klasörler için 1800 saniyedir. Planlı bir hedef değişikliğinden önce süreyi kısaltırsanız geçiş hızlanır; unutursanız istemciler yarım saat eski hedefe gitmeye devam eder.
• İstemci geri dönüşü (failback): Kapalıysa yerel sunucu arızasında uzak hedefe geçen istemci, yerel sunucu düzeldiğinde de uzakta kalır. Şubeli yapıda açık olması genellikle doğrudur.

Kullanıcı “dosyalar eski” dediğinde ilk bakılacak yer, istemcinin hangi hedefe bağlı olduğudur: Gezgin’de klasör özelliklerindeki DFS sekmesi bunu gösterir. Önbelleği dfsutil cache referral flush ile temizleyebilirsiniz.

DFS-R replikasyon grupları ve topoloji

DFS-R’da replikasyon grubu üyeleri ve aralarındaki bağlantıları, replike klasör ise eşitlenen içeriği tanımlar. Topoloji üye sayısına göre seçilir:

• Tam ağ (full mesh): Her üye diğerleriyle doğrudan eşitlenir. Üç–dört üyeye kadar yönetilebilir; üye arttıkça bağlantı sayısı hızla büyür.
• Hub-and-spoke: Şubeler yalnız merkezle eşitlenir. Şubeli yapıda doğal seçimdir; merkez aynı zamanda yedeğin alındığı tek nokta olur.

İlk replikasyonda birincil üye (primary member) seçimi en çok hata yapılan adımdır. Birincil üyenin içeriği yetkili kabul edilir; diğer üyelerde ondan farklı olan dosyalar silinmez, her üyenin DfsrPrivate\PreExisting klasörüne taşınır. Yanlış üye birincil seçildiyse güncel dosyalar burada durur. Bu klasörü ilk eşitleme sonrası kontrol etmeden temizlemeyin.

Yeni şube sunucusu eklerken veriyi önceden kopyalamak (pre-seeding) WAN yükünü azaltır. Yöntem: robocopy ile ACL’leri koruyarak kopyalama (/COPYALL, /B), ardından iki taraftaki dosya karmalarını Get-DfsrFileHash ile karşılaştırma. Karmalar uyuşmazsa DFS-R dosyayı yeniden gönderir ve ön kopyalamanın faydası kaybolur. Sahada uyuşmazlığın tipik sebebi, kopyalamada ACL’lerin taşınmamış olmasıdır.

Staging kotası ve bant genişliği

DFS-R gönderilecek dosyaları önce staging klasöründe sıkıştırılmış hale getirir. Varsayılan staging kotası 4 GB’tır; büyük dosya barındıran klasörlerde yetmez. Kota dolunca DFS-R temizlik yapar ve replikasyon yavaşlar. Olay günlüğünde 4202 (yüksek eşik aşıldı) ve 4204 (temizlik tamamlandı) olaylarının sık görülmesi bunun işaretidir.

Microsoft’un Windows Server 2008 ve sonrası için önerdiği alt sınır, staging kotasının replike klasördeki en büyük 32 dosyanın toplam boyutundan az olmamasıdır. Hesap PowerShell ile yapılır:

$top32 = Get-ChildItem -Path "D:\Proje" -Recurse -File |
  Sort-Object Length -Descending | Select-Object -First 32 |
  Measure-Object -Property Length -Sum
[math]::Ceiling($top32.Sum / 1MB)   # MB cinsinden önerilen alt sınır

Set-DfsrMembership -GroupName "RG-Proje" -FolderName "Proje" `
  -ComputerName FS01 -StagingPathQuotaInMB 32768

Örnek hesap: çizim arşivinde en büyük 32 dosyanın toplamı 26 GB çıktıysa kota en az bu değere, biraz pay bırakarak pratikte 32 GB’a ayarlanır. Staging klasörü varsayılan olarak replike klasörle aynı birimde, DfsrPrivate altında durur. O birimde bu kadar boş alan var mı, önce ona bakın.

Bant genişliği için bağlantı bazında zamanlama ve kısıtlama tanımlanabilir. Şube hattını mesaide boğmamak için gündüz düşük, gece tam bant yaygın bir başlangıçtır. Bedeli birikmedir (backlog): kısıtlama arttıkça şubedeki kopya geride kalır. Kullanıcı mesai içinde güncel veri bekliyorsa bu ayar o beklentiyle çelişir; ikisini aynı anda vaat etmeyin.

Sınırlamalar: çakışma, kilit ve yedek

DFS-R’ı devreye almadan önce aşağıdaki davranışları iş birimleriyle konuşun. Sonradan anlatmak çok daha zordur:

Kullanıcı profilleri ve ev klasörleri için Microsoft, birden fazla etkin hedefle DFS-R kullanımını desteklemez; bu klasörlerde aynı anda yalnız bir hedef etkin olmalıdır. DFS-R bir dağıtım ve erişilebilirlik aracıdır, yedekleme değil. Merkezdeki üyeden değişmez kopya ve geri yükleme testi içeren bir yedekleme kurgusu gerekir; ölçütleri 3-2-1-1-0 yedekleme kuralı yazısında anlatılır.

İzleme ve sağlık raporu

DFS-R arızası sessiz başlar. Replikasyon günlerdir durmuştur; kimse fark etmez, ta ki şubedeki kullanıcı geçen haftanın dosyasını açana kadar. Bu yüzden birikme sayısı ve kritik olaylar izleme sistemine bağlanmalıdır. Temel komutlar:

# İki üye arasındaki birikme (gönderilmeyi bekleyen dosya sayısı)
Get-DfsrBacklog -GroupName "RG-Proje" -FolderName "Proje" `
  -SourceComputerName FS01 -DestinationComputerName FS-IZM -Verbose

# Eski araçla aynı sorgu
dfsrdiag backlog /rgname:RG-Proje /rfname:Proje /smem:FS01 /rmem:FS-IZM

# HTML sağlık raporu
Write-DfsrHealthReport -GroupName "RG-Proje" -ReferenceComputerName FS01 -Path "C:\Raporlar"

Olay günlüğünde (Applications and Services Logs > DFS Replication) izlenecek başlıca kimlikler: 2213 (beklenmeyen kapanma sonrası veritabanı kurtarma bekliyor), 4012 (içerik tazelik süresi aşıldı), 4202/4204 (staging baskısı) ve replikasyon ortağına ulaşılamadığını bildiren 5000’li bağlantı olayları. 2213’ü gören ekip çoğu zaman sunucunun düzgün çalıştığını sanır; oysa o üye replikasyonu bekletmektedir. Birikme sayısı günlerce sıfıra inmeden dalgalanıyorsa staging kotası veya bant kısıtlaması yetmiyordur.

Kurulum sonrası doğrulama sırası:

• Her şube alt ağı doğru AD sitesine eşli; istemci DFS sekmesinde yerel hedefi görüyor.
• Namespace en az iki namespace sunucusunda barınıyor.
• Staging kotası en büyük 32 dosya hesabına göre ayarlı.
• Sağlık raporu düzenli üretiliyor; 2213 ve 4012 olayları alarm üretiyor.
• Merkezdeki üyeden alınan yedekten geri yükleme test edildi.

Dosya hizmetini buluta taşımayı düşünüyorsanız şirket içi DFS-R’a alternatif model Azure Files ve Azure File Sync ile hibrit dosya sunucusu yazısında anlatılıyor. Mevcut dosya sunucularının yenilenmesi ya da DFS’e geçişin planlanması gerekiyorsa sunucu ve bulut yönetimi hizmeti tasarım ve işletim adımlarını kapsar. Resmi referans için Microsoft Learn’deki DFS Namespaces genel bakış ve DFS Replication genel bakış sayfalarıyla başlayın.

Sık sorulan sorular

DFS Namespace kullanmak için DFS-R kurmak zorunlu mu?

Hayır. DFS Namespace yalnızca yönlendirme katmanıdır; tek hedefli klasörlerle tek başına çalışır. Bir klasöre birden fazla hedef tanımlayıp içeriğin aynı kalmasını istiyorsanız DFS-R veya başka bir eşitleme yöntemi gerekir.

Aynı dosyayı iki şubede aynı anda düzenlemek güvenli mi?

Değil. DFS-R dağıtık kilit sağlamaz; aynı dosya iki sunucuda kaydedilirse son yazan kazanır, diğer sürüm ConflictAndDeleted klasörüne taşınır. Ortak düzenlenen veride yazılabilir hedefi tek sunucuyla sınırlayın.

Staging kotası ne kadar olmalı?

Windows Server 2008 ve sonrası için önerilen alt sınır, replike klasördeki en büyük 32 dosyanın toplam boyutudur. Varsayılan 4 GB, büyük dosya barındıran klasörlerde çoğu zaman yetmez.

DFS-R yedekleme yerine geçer mi?

Geçmez. Silme, bozulma ve fidye yazılımı şifrelemesi de tüm üyelere replike edilir. Merkezdeki üyeden sürümlü ve bağımsız bir yedek alın, geri yüklemeyi düzenli test edin.