Windows Server

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.

Bölüm1

Bölüm2

Bölüm3

 

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.

 

clip_image001

 

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.

 

clip_image002

 

 

Yine varsayılan olarak bu klasörün boyutu 4MB dur. Bu kalıcı bir limit değildir.

clip_image003

 

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.

 

clip_image004

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

clip_image005

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

 

clip_image006

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

clip_image007

 

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.

 

clip_image008

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.

clip_image009

 

Ç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://blogs.technet.com/b/filecab/archive/2013/07/31/dfs-replication-in-windows-server-2012-r2-revenge-of-the-sync.aspx

http://technet.microsoft.com/en-us/library/cc787066(v=ws.10).aspx

http://blogs.technet.com/b/askds/archive/2011/07/13/how-to-determine-the-minimum-staging-area-dfsr-needs-for-a-replicated-folder.aspx

Hakan Uzuner

2002 yılından beri aktif olarak bilişim sektöründe çalışmaktayım. Bu süreç içerisinde özellikle profesyonel olarak Microsoft teknolojileri üzerinde çalıştım. Profesyonel kariyerim içerisinde eğitmenlik, danışmanlık ve yöneticilik yaptım. Özellikle danışmanlık ve eğitmenlik tecrübelerimden kaynaklı pek çok farklı firmanın alt yapısının kurulum, yönetimi ve bakımında bulundum. Aynı zamanda ÇözümPark Bilişim Portalı nın Kurucusu olarak portal üzerinde aktif olarak rol almaktayım. Profesyonel kariyerime ITSTACK Bilgi Sistemlerinde Profesyonel Hizmetler Direktörü olarak devam etmekteyim.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu

Reklam Engelleyici Algılandı

ÇözümPark Bilişim Portalı gönüllü bir organizasyon olup tek gelir kaynağı reklamlardır. Bu nedenle siteyi gezerken lütfen reklam engelleme eklentinizi kapatın veya Çözümpark web sitesi için izin tanımı yapın. Anlayışınız için teşekkürler.