Active Directory ve Distributed File System DFS Birlikte Çalışma Senaryoları – Bölüm 4
Makalemin ilk bölümünde temel anlamda DFS kavramından bahsettim. İkinci bölümünde ise DFS replikasyonundan bahsettim. Üçüncü bölümde ise DFS’ in temel çalışma mantığı ve DFS senaryolarından bahsettim. Makalemin ilk üç bölümü için aşağıdaki linkleri kullanabilirsiniz.
Bu bölümde ise detaylı olarak File staging ve “Delete and Conflict” konularına değineceğim.
DFS replikasyonu, yeni veya değişen dosyaların gönderici üyeden alıcı üyeye replike ederken staging folders denilen bir klasör kullanır. Bu klasörün amacı transfer edilecek olan dosyaların blok seviyesinde hazırlanması ve sıkıştırılarak karşı tarafa gönderilmesidir ( sadece değişen blokların gönderilmesi ve sıkıştırma işlemleri RDC açık ise gerçekleşir ).
Eğer gönderici üye, alıcı üyeden bir “request – talep” alırsa, öncelikle staging işlemine başlar. Bu süreçte talep edilen dosyalar replicated klasörden okunur ve sıkıştırılmış hali bu klasöre konulur. Bu hale gelen dosyaya staged file denir. Bu işlemin sonunda staged file istek yapan alıcı üyeye gönderilir. Eğer RDC açık ise bu durumda sadece değişen bölüm transfer edilir. İstek yapan üye bu dosyayı alır ve benzer şekilde staging klasörüne atar. Bu dosya açılır ( decompres ) ve replicated folder içerisine yüklenir – eklenir.
Her replicated folder, kendi staging klasörüne sahiptir. Bu klasör varsayılan olarak replicated folder’ ın local yolu içerisinde DfsrPrivate\Staging folder bulunur.
2008 ve sonrasında ise aşağıda görüldüğü gibi bu klasör
‘\System Volume Information\Dfsr\Private\<Replicated Folder Id>-<Member Id>’
System Volume Information klasörü altına alınmıştır.
Buradaki bir diğer değişiklik ise artık tek bir volüme üzerindeki tüm replicated folders için bu alt klasörler konsolide edilmiştir, yani tek bir dfsrprivate klasörü kullanılır.
Yine varsayılan olarak bu klasörün boyutu 4MB dur. Bu kalıcı bir limit değildir.
Eğer staging klasörü %90 oranında dolar ise eski dosyalar silinir, taki %60 boş alan kalıncaya kadar.
Ancak büyük boyutlu dosyalar için bu süreç biraz farklı çalışır. Kotadan büyük bir dosya stagin klasörüne alındığında cleanup süreci başlar, ancak eski olarak kabul edilen ama hala işlenen bu dosyalar silinemez ve bu temizleme işlemi hata alır. Çünkü büyük bir dosya vardır ve bu karşı tarafa gönderilmek üzere hazırlanmaktadır. Bir süre sonra zaten bu temizleme süreci tekrarlanacağı için, transfer bittikten sonra bu klasör boşaltılabilir. Veya siz bu klasörün boyutunu ayarlayabilirsiniz.
Eğer sürekli büyük dosyalar ile çalışıyorsanız bu durumda kotayı yükseltmek tavsiye edilen bir aksiyondur. Tabiki bu durumda replikasyon grubundaki tüm üye makinelerde bu değişikliği yapmanız gerekmektedir.
Eğer büyük dosyalar ile çalışmayı planlıyor iseniz kotayı düşürmek yüksek CPU ve kaynak kullanımına neden olabilir.
Windows 2003 sistemleri için büyük dosyalar ile çalışırken kotayı belirlemek için en büyük ilk 9 dosyaya göre bir kota belirleyebilirsiniz. Bunu tespit etmek için aşağıdaki powershell komutunu kullanabilirsiniz.
Get-ChildItem <replicatedfolderpath> -recurse | Sort-Object length -descending | select-object -first 9 | ft name,length -wrap –auto
Sonuç aşağıdaki gibi çıkmaktadır.
Bu çıktıyı aşağıdaki gibi okuyabiliriz.
Name = Dosyanın ismi
Length = bytes
Bir Gigabyte = 1073741824 Bytes
Yukarıdaki toplam byte değerini 1073741824 değerine bölüyoruz ve GB cinsinden kota değeri çıkıyor.
Bu komutu biraz daha otomatik hale getirmek için aşağıdaki şekilde kullanabiliriz.
Get-ChildItem <replicatedfolderpath> -recurse | Sort-Object length -descending | select-object -first 9 | measure-object -property length –sum
Bunun bir üst komutu yani işin net hali ise son aldığımız en büyük ilk 9 dosyanın boyutunun GB cinsinden verilmesi.
(Get-ChildItem <replicatedfolderpath> -recurse | Sort-Object length -descending | select-object -first 9 | measure-object -property length -sum).sum /1gb
Yani benim E dizini için kota olarak 20GB ayarlamam gerekiyor.
2008 ve sonrasında ise aşağıdaki gibi daha büyük dosyalar için bunu çekebilirsiniz.
(Get-ChildItem <replicatedfolderpath> -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb
Aynı dizin için rakam 20GB’ dan birden 29GB’ a çıktı.
Bu kota değişiklikleri için herhangi bir servis yeniden başlatma veya sunucu açma kapatmaya gerek yoktur. Sadece bu bilgilerin AD tarafında replike olması için biraz beklemeniz yeterlidir.
DFS staging tarafındaki sorunları aşağıdaki event numaraları ile takip edebilirsiniz;
4202, 4204, 4206, 4208 ve 4212
Anlamlarının bozulmaması için özellikle İngilizce aldım, isterseniz Türkçe bir işletim sisteminden Türkçe olarak görebilirsiniz, ancak pek çok sistem İngilizce olduğu için bu şekilde takip etmek daha doğru olacaktır.
Event ID: 4202
Severity: Warning
The DFS Replication service has detected that the staging space in use for the replicated folder at local path (path) is above the high watermark. The service will attempt to delete the oldest staging files. Performance may be affected.
Event ID: 4204
Severity: Informational
The DFS Replication service has successfully deleted old staging files for the replicated folder at local path (path). The staging space is now below the high watermark.
Event ID: 4206
Severity: Warning
The DFS Replication service failed to clean up old staging files for the replicated folder at local path (path). The service might fail to replicate some large files and the replicated folder might get out of sync. The service will automatically retry staging space cleanup in (x) minutes. The service may start cleanup earlier if it detects some staging files have been unlocked.
Event ID: 4208
Severity: Warning
The DFS Replication service detected that the staging space usage is above the staging quota for the replicated folder at local path (path). The service might fail to replicate some large files and the replicated folder might get out of sync. The service will attempt to clean up staging space automatically.
Event ID: 4212
Severity: Error
The DFS Replication service could not replicate the replicated folder at local path (path) because the staging path is invalid or inaccessible.
Burada kafa karıştırabilecek iki ID var, 4202 ve 4208.
Her iki uyarı metin olarak birbirine çok benzer. Ancak 4208 uyarısı, staging alanı temizlenmek istenmiş ve buna rağmen hala kota sorunu yaşıyor ise karşımıza çıkar. 4202 ise buna göre normal bir bilgilendirme olayı gibi görülebilir.
http://technet.microsoft.com/en-us/library/cc774476(v=ws.10).aspx
Conflict and Deleted folders
DFS içerisinde birden çok üye üzerinde yapılan değişikliklerden hangisinin saklanacağı konusunda “last-writer wins” yöntemi kabul görmüştür.
Her replicated folder, kendine ait bir “ConflictandDeleted” klasörüne sahiptir ve bu replicated folder için yerel makine üzerindeki ilgili volume altında “System Volume Information” klasöründe yer alır.
DfsrPrivate\ConflictandDeleted
Bu kota varsayılan olarak 660MB dır. Staging klasöründe olduğu gibi %90 doluluk olduğunda %60 a kadar temizlik çalışması olur.
Çakışan bu dosyaları üye makine lokalinde ve yerel admin grubu üyesi kullanıcılar ancak görebilir. Dosyaların listesini ise DfsrPrivate klasörü altındaki ConflictandDeletedManifest.xml dosyadan kontrol edebilirsiniz.
Kaynaklar
http://technet.microsoft.com/en-us/library/cc787066(v=ws.10).aspx
