Windows Server 2016'da DFS HA Kurulum ve Yapılandırma

DFS (Distributed File System), özellikle büyük Network'ler ve birden fazla dosya sunucusu içeren ortamlarda dosya paylaşımını daha verimli ve kesintisiz hale getirmek amacıyla kullanılan bir teknolojidir. Windows Server 2016 üzerinde DFS ile High Availability (HA) yani Yüksek Erişilebilirlik sağlamak, dosya erişiminin kesintisiz olmasını ve herhangi bir sunucu arızasında sistemin çalışmaya devam etmesini garantileyen kritik bir yapı sunar. Bu yapı, Network üzerindeki dosya paylaşımını merkezi hale getirirken, aynı zamanda yük dengelemesi ve felaket senaryolarında hızlı kurtarma gibi avantajlar sağlar.

Windows Server 2016 üzerinde DFS kullanarak bir High Availability (HA) yapısı oluşturmak, esasen birkaç temel adımdan oluşur. İlk adım, DFS Namespaces (DFS-N) ve DFS Replication (DFS-R) yapılarını kurmak ve yapılandırmaktır. DFS Namespaces, Network üzerindeki dosya paylaşımını tek bir sanal ad altında toplarken, DFS Replication ise bu dosyaların birden fazla sunucu arasında senkronize edilmesini sağlar. Bu iki bileşen, hem kullanıcı deneyimini iyileştirir hem de dosya erişimini hızlandırır.

DFS Namespaces ile kullanıcılar, fiziksel dosya sunucularının konumuna bakılmaksızın, tek bir paylaşımlı dosya adı üzerinden kaynaklara erişebilir. Bu sayede, sunucularda herhangi bir kesinti olduğunda bile kullanıcılar fark etmeksizin dosyalarına ulaşabilir. Ayrıca, Load Balancing (yük dengeleme) sayesinde farklı sunucular üzerindeki trafiği yönetmek ve performansı artırmak da mümkün hale gelir.

DFS Replication ise, dosyaların birden fazla sunucu arasında senkronize edilmesini sağlayarak veri bütünlüğünü korur. Herhangi bir sunucuda yaşanan arıza durumunda, dosyaların başka bir sunucudan erişilebilir olması, High Availability (HA) garantisini sağlar. Bu yapı, özellikle iş sürekliliği ve veri güvenliği açısından son derece önemlidir.

High Availability (HA) yapılandırmasında, Failover Cluster ile entegrasyon da önemli bir rol oynar. Failover Cluster kullanılarak, DFS sunucularının otomatik olarak yedeklenmesi ve arıza durumunda otomatik olarak başka bir sunucunun devreye girmesi sağlanabilir. Bu da olası kesinti sürelerini minimuma indirir ve sistemin her zaman erişilebilir olmasını sağlar.

Uzunca bir yazı olacağını şimdiden belirtmek istiyorum. Çünkü bu bilgiler ışığında kendi ortamınızdaki DFS Server Yüksek Erişilebilirlik (High Availability) yapısını sorunsuz bir şekilde oluşturabileceksiniz.

Topolojim, aşağıdaki şekilde olacak. Örneğimi, kurumsal firmalarda kullanılan, kullanıcı profil klasörlerinin Server'da tutulması yöntemi ile uygulayacak olup, kullanıcıların Local (yerel) bilgisayarlarındaki profil klasörlerinde hiçbir Data'nın tutulmaması üzerinde kurgulanmış olan Home Folders yapısı üzerinde kurulacak. Bu sayede de Distributed File System (DFS) Yüksek Erişilebilirlik (High Availability) Test'imizi de gerçekleştirmiş olacağız.

Topolojim, aşağıdaki gibi olacak;



Bu yapıya göre, Domain ortamımda Istanbul Site ve Antalya Site olarak ayrılmış bir Active Directory Site yapısı mevcut, her bir Site içinde birer Domain Controller ve birer tane de File Server (Dosya Sunucusu) bulunuyor. Hedefim; File Server'lar üzerinde DFS kurulumu gerçekleşirip, bu DFS Server'lar üzerinde Namespace oluşturup, birbirlerine replikeli çalışacak şekilde yapılandırdıktan sonra, kaynaklara kesintisiz bir şekilde, High Availability (Yüksek Erişilebilirlik) ile, erişimlerini sağlamak olacak.

DFS (Distributed File System) Role Kurulumu

DFS- Distributed File System Role Kurulum işlemimi öncelikli olarak, Primary (birincil) DFS sunucum olarak olan FILESRV001 Hostname'li sunucum üzerinde gerçekleştiriyorum.

1- Server Manager konsolundan, Dashboard ekranında, Manage > Add roles and Features seçeneğini tıklıyorum. Dilerseniz Dashboard ekranında orta bölümde bulunan Quick Start sekmesindeki Add Roles and Features ile de rol ekleme sihirbazını açabiliriz



2- Select Installation Type adımında Role-based or Features-based Installation seçeneği seçili iken Next butonuna basarak devam ediyorum.



3- Select destination Server adımında, kurulum hangi Server'a yapılacak ise, o Server'ı seçmemiz gerekiyor. Ben, FILESRV001 üzerinde File and Storage Services altındaki Distributed File System (DFS) Rol kurulumu yaparak yapılandıracağım için bu Server'ımı seçiyorum ve Next butonuna basarak devam ediyorum.



4- Select Server roles adımında File and Storage Services rolü altında bulunan DFS Namespaces (DFS-N) ve DFS Replication (DFS-R) özelliklerini seçiyorum.

DFS Namespace (DFS-N) ve DFS Replication (DFS-R), Microsoft’un sunduğu Distributed File System (DFS) teknolojisinin iki ana bileşenidir ve bu bileşenler, büyük Network'ler üzerinde veri paylaşımını, erişimini ve senkronizasyonunu daha verimli hale getirmek için kullanılır. Her iki yapı da farklı işlevler sunmasına rağmen, birlikte kullanıldıklarında dosya yönetimi ve paylaşımı açısından çok daha güçlü bir çözüm sağlarlar.

DFS Namespace (DFS-N)

DFS Namespace (DFS-N), birden fazla sunucuda bulunan paylaşılan klasörleri tek bir mantıksal yapı altında birleştirerek, kullanıcılara merkezi bir dosya erişimi sunar. Bu yapı, fiziksel olarak farklı sunucularda ve lokasyonlarda bulunan dosya paylaşımlarını, kullanıcıya tek bir sanal yol üzerinden sunar. Örneğin, bir kullanıcı farklı sunucularda bulunan paylaşılan klasörlere erişirken, bu klasörleri tek bir Namespace altında tek bir UNC Path ile erişilebilir hale getirir. Kullanıcılar, hangi sunucudan veri aldıklarını bilmeden, tek bir kök dizin altında tüm dosyalara ulaşabilir.

Bu yapı, büyük ölçekli organizasyonlarda dosya paylaşımını çok daha yönetilebilir hale getirir. DFS Namespace'in sunduğu en büyük avantajlardan biri, farklı sunuculardaki paylaşılan klasörlerin görünürde tek bir paylaşılan klasör gibi sunulmasıdır. Alt paylaşımlar, yani alt paylaşım klasörleri, aslında farklı Server'lar üzerinde fiziksel olarak bulunur. Ancak bu klasörler, tek bir kök paylaşım altında birleştirilir ve bu kök dizin üzerinden kullanıcılar için şeffaf bir erişim sağlanır. Bu, merkezi yönetim ve kolay kullanıcı deneyimi açısından büyük avantaj sunar.

DFS Namespace’in bir diğer önemli özelliği ise, farklı Server'lar arasında yük dengeleme ve yüksek erişilebilirlik (High Availability - HA) sağlamasıdır. Örneğin, bir sunucuda sorun yaşandığında, kullanıcılar aynı Namespace üzerinden başka bir sunucudaki yedek paylaşıma yönlendirilir. Bu sayede, dosya erişiminde kesinti yaşanmaz ve sistem sürekliliği sağlanır.

DFS Replication (DFS-R)

DFS Replication (DFS-R), LAN ve WAN gibi farklı Network bağlantıları arasında dosyaların senkronizasyonunu sağlayan bir özelliktir. Bu yapı, dosya paylaşımı yapan sunucular arasında veri replikasyonu gerçekleştirir ve özellikle farklı lokasyonlardaki kullanıcıların aynı veriye erişimini sağlar. DFS Replication, yalnızca değiştirilen veri parçalarını senkronize ederek bant genişliği kullanımını optimize eder. Yani, dosyanın tamamını tekrar göndermek yerine, sadece değiştirilen kısımlar gönderilir. Bu özellik, Network trafiğini azaltırken aynı zamanda veri senkronizasyonunu daha hızlı hale getirir.

DFS Replication özelliğinin bir diğer önemli yönü ise, zamanlama ve bant genişliği yönetimi özellikleridir. Replikasyonun hangi saatlerde yapılacağını belirlemek, yoğun Network trafiği olan saatlerde replikasyon işlemlerinin engellenmesini sağlar. Özellikle WAN bağlantıları gibi düşük hızda veri transferi yapılan Network'lerde bu tür bir zamanlama ve bant genişliği yönetimi, sistem performansını koruma açısından büyük önem taşır. Bandwidth Throttling (bant genişliği sınırlaması), replikasyonun belirli bir hızda yapılmasını sağlar ve bu sayede diğer Network aktiviteleri replikasyon işlemi tarafından olumsuz etkilenmez.

DFS Replication, DFS Namespace ile birlikte kullanıldığında, farklı sunucularda bulunan paylaşılan klasörlerin otomatik olarak senkronize edilmesini sağlar. Böylece, bir sunucuda yapılan değişiklikler diğer sunuculara hızla yansıtılır ve tüm kullanıcılar güncel verilere erişebilir. Ancak DFS Replication, DFS Namespace'ten bağımsız olarak da kullanılabilir. Yani, Namespace olmadan da dosya replikasyonu gerçekleştirilebilir. Bu özellik, yalnızca veri senkronizasyonu gereken ancak Namespace yönetimine ihtiyaç duyulmayan senaryolarda kullanılabilir.

Ek Bilgiler ve Teknik Detaylar

DFS Replication, Remote Differential Compression (RDC) teknolojisini kullanarak dosyaların yalnızca değişen bölümlerini senkronize eder. RDC, özellikle büyük dosyaların sıkça değişen küçük bölümlerinin hızlı bir şekilde güncellenmesini sağlar. Örneğin, bir dosyanın yalnızca bir bölümü değiştiyse RDC teknolojisi, bu değişikliği tespit eder ve sadece bu kısmı diğer sunuculara gönderir. Bu da replikasyon sürecini hızlandırır ve Network trafiğini azaltır.

DFS Namespace ve DFS Replication, özellikle yüksek erişilebilirlik ve veri güvenliği sağlamak amacıyla sıklıkla birlikte kullanılır. Birden fazla lokasyon ve sunucu arasında verilerin güncel tutulması gereken senaryolarda, DFS Namespace dosya erişimini kolaylaştırırken, DFS Replication ise verilerin her zaman güncel ve senkronize olmasını sağlar.

DFS Namespace’in sunduğu merkezi yapılandırma ve DFS Replication’ın sağladığı etkin veri senkronizasyonu, büyük ve dağıtık Network yapılarında veri yönetimi açısından önemli bir avantajdır. Bu iki özellik, birlikte kullanıldığında, sistem yönetimini daha verimli ve güvenli hale getirir.

 

5- Select features adımında, DFS Namespaces (DFS-N) ve DFS Replication (DFS-R) özellikleri için herhangi ek bir Feauture (özellik) kurulumuna ihtiyacımız olmadığı için, Next butonuna basarak yapılandırmaya devam ediyorum.

6- Confirm installation selections adımında, Install butonuna basarak DFS Namespaces (DFS-N) ve DFS Replication (DFS-R) özelliklerinin kurulumlarına başlıyorum.



7- Install butonuna basarak File and Storage Services altında bulunan DFS Namespaces (DFS-N) ve DFS Replication (DFS-R) özelliklerinin kurulumlarını başlatıyoruz.




8- Distributed File System (DFS) Rol kurulumu işlemim başarılı bir şekilde gerçekleşti.

Replicated DFS Üzerinde File System Role Kurulumu

9- Distributed File System Role Kurulum işlemimi, Primary (Birincil) DFS Server'ım olarak olan FILESRV001 Hostname'li sunucum üzerinde gerçekleştirdiğim gibi aynı şekilde FILESRV002 Hostname'li Replicated (Replike) DFS sunucum üzerinde de gerçekleştiriyorum.



10- FILESRV002 Hostname'li sunucum üzerindeki Distributed File System (DFS) Rol kurulumu işlemim başarılı bir şekilde gerçekleşti.

Replikasyon Klasörleri Oluşturma

DFS Replication Klasörleri oluşturma işlemi, özellikle dosya sunucularının yüksek erişilebilirlik (High Availability - HA) sunmasını sağlamak ve kullanıcı profillerinin güvenli bir şekilde merkezi sunucularda tutulmasını garanti altına almak için kritik bir adımdır. Bu senaryoda, kullanıcıların Local bilgisayarlarında hiçbir verinin saklanmaması ve tüm profil verilerinin sunucularda yönetilmesi, veri güvenliği ve erişim açısından önemli avantajlar sağlar.

DFS Replication yapısında, kullanıcıların verileri FILESRV001 ve FILESRV002 gibi File Server'lar üzerindeki ikincil Disk'lerde tutulur. Bu sunucular arasında oluşturulan replikasyon, herhangi bir sunucuda yaşanan arıza durumunda verilerin kaybolmamasını ve diğer sunuculardan erişilebilir olmasını sağlar. Özellikle kullanıcı profilleri gibi sürekli güncellenen ve kritik öneme sahip verilerin bu yapıda yönetilmesi, sistemin işleyişi açısından son derece faydalıdır.

DFS Replication ile replikasyon klasörleri oluştururken, ilk olarak replikasyon grubu oluşturulur. Bu grup, replikasyonun hangi sunucular arasında yapılacağını belirler. FILESRV001 ve FILESRV002 Hostname'li sunucular arasındaki replikasyon için, her iki sunucuya da replikasyon klasörleri tanımlanır ve bu klasörler arasında veri senkronizasyonu sağlanır. Replikasyon grubu oluşturulurken dikkat edilmesi gereken bir diğer nokta ise, replikasyonun hangi klasörler arasında yapılacağıdır. Bu klasörler, kullanıcı profillerinin ve Home Folder yapılandırmalarının tutulduğu dizinler olacaktır. Bu yapılandırma sayesinde, kullanıcıların Local profillerinde herhangi bir veri saklanmaksızın tüm veriler merkezi sunucularda güvenli bir şekilde saklanır.

DFS Replication, verilerin senkronizasyonunu yaparken Bandwidth Throttling ve Schedule özellikleri ile trafiği kontrol etme imkanı sunar. Özellikle büyük Network yapılarında replikasyon trafiğini kontrol altında tutmak, Network performansını olumsuz etkilemeden veri senkronizasyonu sağlamayı mümkün kılar. Bu sayede, sunucular arasındaki replikasyon işlemi sırasında Network üzerindeki diğer işlemler aksamadan yürütülebilir. Ayrıca, replikasyon zamanlamaları belirlenerek düşük trafik saatlerinde replikasyonun daha yoğun şekilde yapılması sağlanabilir.

DFS Management üzerinden replikasyon klasörleri oluşturulurken, dikkat edilmesi gereken bir diğer önemli husus, klasörlerin replikasyon önceliklerinin doğru yapılandırılmasıdır. Kullanıcı profil verilerinin sürekli değiştiği göz önünde bulundurulduğunda, bu klasörler yüksek öncelikli olarak yapılandırılmalıdır. Bu, verilerin en kısa sürede diğer sunuculara senkronize edilmesini sağlar ve kullanıcıların her zaman en güncel verilere erişebilmesini garanti eder.

9- FILESRV001 Hostname'li File Server'ımın ikincil Disk'inde Home Folders adında bir klasör oluşturuyor, bunu da paylaşıma açıyorum.




9.1- Oluşturduğum Home Folders adındaki bu klasörün içine de her kullanıcının kullanıcı adını taşıyan profil klasörlerini tek tek oluşturuyor, ilgil NTFS izinleri atama işlemlerini de tek tek gerçekleştiriyorum.




10- Bu sefer de FILESRV002 Hostname'li File Server'ımın ikincil Disk'inde Home Folders adında bir klasör oluşturuyor, bunu da paylaşıma açıyorum.




10.1- Oluşturduğum Home Folders adındaki bu klasörün içine bu sefer FILESRV001 Hostname'li File Server'ımda yaptığım gibi her kullanıcının kullanıcı adını taşıyan profil klasörlerini açmıyorum. Bu klasörler, replikasyon ile replike olacak.

DFS Management Üzerinde Namespace Oluşturma

Distributed File System Management üzerinde Namespace oluşturma, özellikle dağıtık yapıya sahip sistemlerde dosya paylaşımını ve erişimini kolaylaştıran temel bir adımdır. Bu yapı, farklı Server Hostname'ler altında yer alan dosya paylaşımlarını tek bir çatı altında birleştirerek kullanıcıların dosyalara erişimini sadeleştirir ve yönetilebilir hale getirir. Namespace kavramı burada devreye girer ve tüm dosya paylaşım kaynaklarının DOMAIN adı altında tek bir UNC Path üzerinden erişilmesini sağlar. Bu, büyük ve karmaşık Network yapılarında dosya paylaşımının merkezi bir noktadan yönetilmesine olanak tanır.

DFS'in en önemli avantajlarından biri, sınırlı bağlantı hızlarına sahip Network'ler üzerinde bile dosya paylaşımını senkronize edebilmesidir. Bu sayede, aynı dosya birden fazla sunucuda senkronize edilir ve kullanıcıların en yakın sunucudan dosyaya erişmesi sağlanır. Namespace, bu yapının temel taşıdır ve farklı sunucular üzerindeki dosyaların tek bir UNC Path altında erişilebilir olmasını sağlar. Özellikle kullanıcılar, fiziksel sunucuların lokasyonunu bilmeden bu sanal namespace üzerinden dosyalara kolayca erişebilir. Bu, merkezi yönetim sağlarken aynı zamanda kullanıcı deneyimini de büyük ölçüde iyileştirir.

DFS Management üzerinden Namespace oluştururken, hangi tür Namespace kullanılacağına karar vermek önemlidir. Domain-based Namespace, Active Directory ile entegre çalışarak daha büyük ölçekli ve yüksek erişilebilirlik (High Availability - HA) gerektiren ortamlar için uygundur. Bu modelde, Namespace bilgileri Active Directory'de saklanır ve kullanıcılar, Domain içindeki herhangi bir domain controller üzerinden bu Namespace'e erişebilir. Bu da kullanıcıların kesintisiz dosya erişimi sağlayabilmesini garantiler.

Stand-alone Namespace ise, Active Directory entegrasyonu gerektirmeyen ve yerel sunucu üzerinde çalışan bir modeldir. Daha küçük Network yapılarında veya domain bağımsız ortamlarda kullanıma uygundur. Ancak Stand-alone Namespace, Domain-based Namespace ile kıyasla yüksek erişilebilirlik sağlamadığı için, sunucunun arızalanması durumunda Namespace'e erişim kesilir.

DFS Management üzerinde Namespace oluşturma işlemi, ortamınıza ve ihtiyaçlarınıza göre doğru yapılandırıldığında, dosya paylaşımını daha verimli, güvenli ve kesintisiz hale getirir. Örnek vermek gerekirse, yukarıda her iki File Server üzerinde oluşturduğumuz Home Folders isimli paylaşım klasörünü,

olarak farklı farklı UNC (Universal Naming Convention) Path'ler şeklinde kullanmak yerine DFS üzerinde;

DFS Namespace'lerini;

şeklinde tek bir Domain çatısı altında toplamak, hem erişilebilirlik hem de yedeklilik anlamında daha kullanışlı ve mantıklı olacaktır. Bu bilgiler ışığında Namespace oluşturma işlemine geçecek olursak;

11- DFS Management'ı açıyor, Namespace üzerinde sağ tıklayarak New Namespace... seçeğini seçiyorum.



12- Açılan New Namespace Wizard üzerindeki Namespace Server bölümünde Namespace'i oluşturacağım Server'ımı seçiyorum.



13- Namespace Name and Settings adımında, Name alanına, Namespace'im için bir isim beleyerek alt kısımdaki Edit Settings... butonuna tıklıyorum.



13.1- Edit Settings... penceresinde Administrators have full access; other users have read and write permissions seçeneğini seçiyor, OK butonuna bararak ilgili pencereyi kapatıyorum.



13.2- Gerekli işlemleri tamamladıktan sonra Next butonuna basarak bir sonraki adıma geçiyorum.



14- Namespaces Type adımında, varsayılan olarak Domain-based Namespace ve Enable Windows Server 2008 Mode seçeneğinin seçili olduğunu görüyoruz.

Domain-based Namespace ve Stand-alone Namespace, DFS Namespaces yapılandırmasında kullanılan iki temel modeldir. Bu iki model, dosya paylaşımını nasıl yönetmek istediğinize ve hangi özelliklerin önemli olduğuna bağlı olarak farklı senaryolarda tercih edilir. Her iki yapı da belirli avantajlar sunar ve ortamınıza en uygun olanı seçmek, uzun vadede dosya paylaşım sisteminizin performansı ve yönetilebilirliği üzerinde önemli bir etkiye sahip olacaktır.

Domain-based Namespace

Domain-based Namespace, Active Directory Domain Services (AD DS) ile entegre çalışan ve merkezi yönetim imkanı sunan bir DFS Namespaces modelidir. Bu modelde oluşturulan Namespace, Domain'in bir parçası haline gelir ve Active Directory tarafından yönetilir. En büyük avantajlarından biri, Namespace'e ait yapılandırma bilgileri Active Directory içerisinde saklandığı için yüksek erişilebilirlik (High Availability - HA) sunmasıdır. Bu sayede, Domain içindeki tüm kullanıcılar, Namespace'e kesintisiz erişim sağlayabilir.

Bu model, özellikle büyük ölçekli organizasyonlar için ideal bir çözümdür. Çünkü Domain-based Namespace, çok sayıda dosya sunucusunun bir arada bulunduğu ortamlarda kullanıcıların kaynaklara tek bir giriş noktası üzerinden erişmesine olanak tanır. Yani kullanıcılar, fiziksel dosya sunucusunun nerede olduğunu bilmeden tek bir mantıksal ad üzerinden dosya paylaşımına ulaşabilir. Bu durum, dosya erişim sürecini son derece basit hale getirir ve merkezi yönetimi kolaylaştırır.

Özellikleri:

✅ Yüksek Erişilebilirlik (HA): Namespace bilgileri Active Directory üzerinde depolandığı için, bir sunucu arızalandığında bile kullanıcılar başka bir Domain controller üzerinden Namespace'e erişmeye devam edebilir.
✅ Kapsamlı Yönetim: Active Directory'nin sunduğu kullanıcı ve grup politikaları, Namespace üzerindeki dosya paylaşımını ayrıntılı bir şekilde yönetmenizi sağlar.
✅ Güvenlik ve Yetkilendirme: AD DS ile entegre olduğundan, dosya paylaşımı üzerindeki erişim izinleri ve güvenlik ayarları Active Directory kullanıcıları ve grupları ile doğrudan yönetilebilir.
✅ Namespace Ölçeklenebilirliği: Domain-based Namespace, daha büyük ve daha karmaşık yapılandırmalar için idealdir. Aynı Namespace'i birden fazla sunucuda barındırarak ölçeklendirebilirsiniz.
✅ Replication (Yedekleme): DFS Replication ile entegre edildiğinde, dosya sunucularındaki veri senkronizasyonu merkezi olarak yönetilebilir ve veri bütünlüğü korunur.

Ancak, bu modelin bir Domain altyapısına bağımlı olduğunu unutmamak gerekir. Yani, bu yapılandırma için bir Active Directory Domain'inizin olması zorunludur. Ayrıca, Namespace bilgileri Domain controller'lar arasında replikasyona tabi tutulduğu için bu süreç, küçük bir gecikmeye neden olabilir.

NOT: Mevcut yapınızda, Windows Server 2008 öncesi işletim sistemleri varsa, Enable Windows Server 2008 Mode seçeneğini seçekere, Windows Server 2008 işletim sistemleri ile de uyumlu çalışmasını sağlayabilirsiniz.

Stand-alone Namespace

Stand-alone Namespace, Domain-based Namespace'in aksine, Active Directory ile entegre olmadan çalışan bir modeldir. Bu modelde namespace bilgileri yerel bir sunucu üzerinde tutulur ve Active Directory'ye ihtiyaç duyulmaz. Daha basit yapılandırmalar ve küçük organizasyonlar için tercih edilen bu model, Domain yapısına ihtiyaç duymayan ağlarda yaygın olarak kullanılır. Ancak, Stand-alone Namespace'in en önemli kısıtlaması, yüksek erişilebilirlik (High Availability - HA) sunmamasıdır. Namespace bilgileri sadece tek bir sunucu üzerinde saklandığından, bu sunucunun erişilememesi durumunda namespace de erişilemez hale gelir.

Bu model, Domain altyapısına ihtiyaç duyulmayan, küçük ölçekli ve daha basit dosya paylaşım senaryoları için uygundur. Bir sunucunun namespace bilgilerini saklaması ve bu sunucunun arızalanması durumunda, namespace'e erişim kesilir ve dosya paylaşımı devre dışı kalır.

Özellikleri:

✅ Yerel Yönetim: Namespace bilgileri yerel bir sunucuda tutulduğu için Active Directory olmadan çalışabilir. Bu, küçük Network ortamlarında ya da Domain altyapısının bulunmadığı ortamlarda avantajlıdır.
✅ Tek Sunucu Bağımlılığı: Namespace, sadece tek bir sunucu üzerinde depolandığından, bu sunucunun çalışmaması durumunda namespace erişilemez hale gelir.
✅ Daha Az Karmaşıklık: Active Directory entegrasyonuna ihtiyaç duymadığı için daha basit bir yapılandırma ve yönetim sağlar. Küçük ve basit Network yapılarında yönetimi kolaydır.
✅ Sınırlı Ölçeklenebilirlik: Domain-based Namespace gibi büyük ve kompleks Network yapılarında kullanılmak üzere tasarlanmamıştır. Yüksek kullanıcı sayısına sahip büyük Network'lerde yetersiz kalabilir.

Stand-alone Namespace'in en önemli avantajı, basit ve küçük ölçekli Network'ler için ideal bir çözüm sunmasıdır. Ancak, büyük ölçekli ya da kritik öneme sahip dosya paylaşım senaryolarında, Domain-based Namespace'in sunduğu özellikler ve yüksek erişilebilirlik (High Availability - HA) avantajları olmadan yönetmek zor olabilir.

Seçimime, Domain-based Namespace seçeneğini seçip, Next butonuna basarak devam ediyorum.



15- Review Settings and Create Namespace adımında, yaptığımız ayarların bir özetini görüyoruz. Yapılandırma ayarlarımız doğru ise, Create butonuna basarak Namespace oluşturma işlemimi tamamlıyorum.




16- DFS Management altında oluşturduğum Namespace'imi görebiliyorum.

DFS Management Üzerinde Replication Oluşturma

Namespace oluşturma işlemimizi tamamladık. Bu bölümde ise, DFS Management üzerinde Replication oluşturma işlemi gerçekleşterek, File Server'larım üzerinde oluşturduğum paylaşım klasörlerimin, her iki File Server üzerinde de replikeli çalışması için gerekli yapılandırmaları yapacağım.

DFS Replication Gereksinimleri

⚠️ Active Directory Domain yapısı bulunmalıdır. Workgroup yapılandırmalarında DFS replication kullanımı desteklenmez.

⚠️ Active Directory Schema yapısı, DFS Class'ları ve Attribute'larını içerecek şekilde güncel olmalıdır.

⚠️ Bir Replication grubunun tüm üyeleri aynı Forest içerisinde olmalıdır. Farklı Forest yapıları içerisindeki sunucular arasında DFS Replication etkinleştirilemez. Ancak aynı Forest içerisinde olup , farklı bir Domain'e sahip olması (ör. Child Domain) istisnadır.

⚠️ DFS Replication ile çoğaltılacak klasörler, bir NTFS Volume üzerinde bulunmalıdır.

⚠️ EFS ile şifrelenmiş dosyalar çoğaltılamaz.

⚠️ DFS Replication'ın izlenmesi, SCOM Management Pack ya da benzeri Monitoring araçları ile sağlanabilir.

17- DFS Management üzerinde, Replication üzerinde sağ tıklayarak New Replicarion Group... seçeğini seçiyorum.



18- Açılan New New Replication Group Wizard üzerinde, Replication Group Type adımında karşımıza iki seçenek çıkıyor;

Multipurpose Replication Group ve Replication Group for Data Collection, Distributed File System Replication (DFSR) mimarisinde iki farklı replikasyon senaryosu sunar. Her biri belirli kullanım senaryoları için optimize edilmiştir ve veri replikasyonu süreçlerinde nasıl konumlandırılmaları gerektiği iyi anlaşılmalıdır.

Multipurpose Replication Group

Multipurpose Replication Group, birden fazla sunucu arasında veri paylaşımını sağlamak için kullanılır. Bu yapılandırmada, belirlenen dizinlerde yapılan değişiklikler eşit seviyede tüm üyelerle senkronize edilir. Yani replikasyon işlemi tek yönlü değil, çift yönlüdür. Replikasyon topolojisi olarak Full Mesh ya da Hub and Spoke konfigürasyonları tercih edilebilir. Full Mesh topolojisinde tüm üyeler birbirleriyle doğrudan haberleşirken, Hub and Spoke modelinde merkezi bir Hub üzerinden veri dağıtımı gerçekleştirilir. Bunun avantajı, Bandwidth (bant genişliği) yönetimini daha verimli yapabilmek ve merkezi bir noktadan kontrol sağlayabilmektir.

Bu replikasyon tipi, büyük ölçekli dağıtık ortamlarda, dosya sunucularının her zaman senkronize olmasını isteyen senaryolarda kullanılır. Çok sayıda üye içeren Full Mesh topolojisi, replikasyon trafiğinin yönetilmesini zorlaştırabilir. Bu nedenle, özellikle geniş Network yapılarında, replikasyon planlamasının dikkatli yapılması gerekir. Aktif-aktif veri paylaşımı gerektiren ortamlarda Multipurpose Replication Group doğru bir seçimdir. Ancak, her sunucunun veri değişimlerine eşit erişimi olduğu için yanlış yapılandırılmış bir senaryoda, istem dışı dosya güncellemeleri veya çakışmalar yaşanabilir. Bu nedenle, uygun erişim hakları belirlenmeli ve değişikliklerin nasıl senkronize edildiği dikkatle yönetilmelidir.

Replication Group for Data Collection

Replication Group for Data Collection ise farklı bir senaryoya hitap eder. Bu yapılandırmada replikasyon süreci iki yönlü değildir. Bunun yerine, verinin bir uç noktadan diğerine taşınması için optimize edilmiştir. Genellikle şube ofislerinden merkezi bir veri merkezine veri toplanması için kullanılır. Örneğin, uzak lokasyonlarda oluşturulan günlük raporlar, belirlenen bir merkez sunucuya kopyalanarak burada yedeklenebilir ya da işlenebilir. Bu modelde, replikasyon yönü kontrollü olduğundan istem dışı veri değişiklikleri merkezi sistemlere yayılmaz.

Hub and Spoke topolojisi ile birlikte kullanıldığında, şube sunucularından merkeze verilerin düzenli olarak toplanmasını sağlayarak, merkezi veri yedekleme veya analiz süreçlerini iyileştirir. Örneğin, bir perakende zinciri farklı şubelerindeki satış verilerini merkezde toplamak istediğinde, Replication Group for Data Collection kullanılabilir. Buradaki temel fark, verinin merkeze taşınması ancak merkezin şubelere herhangi bir veri göndermemesidir. Bu model, merkezi analiz ve yedekleme işlemlerini kolaylaştırırken, istem dışı veri değişikliklerinin önüne geçilmesine de yardımcı olur.

Bu iki replikasyon modelinin en önemli farkı, verinin nasıl ve hangi yönde aktarıldığıdır. Multipurpose Replication Group, tüm üyeler arasında değişikliklerin eşit seviyede senkronize edilmesini sağlarken, Replication Group for Data Collection belirli bir merkezde veri toplamak için kullanılır. Eğer dağıtık bir Network yapısında, tüm lokasyonların güncel verilere erişmesi gerekiyorsa Multipurpose Replication Group tercih edilmelidir. Ancak veri merkezileştirme ve analiz süreçlerine odaklanılıyorsa, Replication Group for Data Collection daha uygun olacaktır.

Veri yönetimi ve replikasyon topolojisi belirlenirken Network altyapısı, Bandwidth (bant genişliği) kısıtlamaları ve veri değişim sıklığı gibi faktörler göz önünde bulundurulmalıdır. Yanlış bir yapılandırma, gereksiz replikasyon trafiği oluşturarak sistem kaynaklarını tüketebilir ve senkronizasyon problemlerine yol açabilir. Bu nedenle, ihtiyaç analizinin doğru yapılması ve replikasyon modelinin ona göre seçilmesi kritik öneme sahiptir.

Mevcut yapımda 2 tane DFS sunucum olsa da, sonradan 3. ya da daha fazla sayıda (64'e kadar) DFS sunucu kurarak replikasyona dahil edebilme ihtimaline karşı ben, Multipurpose replication group seçeneğini seçiyor, Next butonuna basarak devam ediyorum.



19- Name and Domain adımında, oluşturacağım Replication Group için bir isim veriyor, Next butonuna basarak devam ediyorum.



20- Replication Group Members adımında, replikasyon grubuna dahil olacak sunucularımı seçiyorum. Bunun için Add... butonuna basıyorum.



20.1- Yapımdaki FILESRV001 ve FILESRV002 Hostname'li Server'larımı seçip, ekliyorum.



20.2- FILESRV001 ve FILESRV002 Hostname'li Server'larımı replikasyon grubuna dahil etmek için ekledim. Next butonuna basarak devam ediyorum.



21- Topology Selection adımında repkasyonlar için kullanılacak olan Topolojilerden birini, kendi yapımıza göre seçmemiz gerekiyor. Bu topolojilere kısaca bir göz atalım;

Hub and Spoke

Hub and Spoke Topology, veri replikasyonunun merkezileştirildiği ve belirli bir ana sunucu üzerinden yönetildiği bir yapı sunar. Bu modelde, tüm veri akışı merkezde konumlanan bir Server aracılığıyla yönlendirilir. Replikasyon sürecine katılan Server'lar doğrudan birbirleriyle iletişim kurmaz, sadece merkezi Server ile veri senkronizasyonu gerçekleştirir. Bu yaklaşım, belirli bir kontrol noktası oluşturarak yönetim kolaylığı sağlarken, aynı zamanda veri bütünlüğünün korunmasını ve tek bir noktadan yönetilmesini mümkün kılar.

Böyle bir yapılandırmada, veri akışı çift yönlü olabilir. Replikasyon grubundaki tüm Server'lar verilerini merkezi Server ile paylaşırken, merkezi Server da bu verileri uygun hedeflere yönlendirir. Örneğin, belirli bir bölgedeki şubeler merkezi bir Server'a bağlanarak kendi verilerini ona iletir. Ardından, merkezde işlenen ve güncellenen veriler yeniden şubelere dağıtılır. Böylece her şube güncel ve senkronize bir veri kümesine erişebilir.

Ancak, bu mimari belirli avantajlar sunarken bazı zorlukları da beraberinde getirir. En önemli noktalardan biri, merkezi Server'ın Single Point of Failure (tek hata noktası) haline gelmesidir. Eğer merkezdeki Server erişilemez hale gelirse, replikasyon süreci tamamen durur ve verilerin dağıtımı sağlanamaz. Böyle bir senaryoda, felaket kurtarma mekanizmalarının ve yedekleme çözümlerinin devreye sokulması gerekir. Merkezi Server'ın erişilebilirliğini artırmak için yüksek erişilebilirlik (High Availability) çözümleri uygulanmalı, yük dengeleme (Load Balancing) stratejileri belirlenmeli ve fazladan replikasyon noktaları oluşturulmalıdır.

Ayrıca, Hub and Spoke Topology'nin performansı büyük ölçüde bant genişliğine ve Network altyapısına bağlıdır. Merkezi Server, birçok istemciden gelen veri değişikliklerini aynı anda işlemek zorundadır. Bu da büyük ölçekli replikasyon işlemlerinde yüksek işlem gücü gerektirir. Eğer Network Bandwidth (bant genişliği) yetersizse, replikasyon süreleri uzayabilir ve veri senkronizasyonunda gecikmeler yaşanabilir. Bu yüzden, replikasyon sıklığının ve zamanlamasının iyi planlanması, gereksiz veri trafiğinin önlenmesi ve delta replikasyon teknikleri ile sadece değişen verilerin taşınması gereklidir.

Bir diğer önemli konu, veri çakışmalarının nasıl ele alınacağıdır. Çift yönlü replikasyon senaryolarında, farklı Server'larda aynı anda güncellenen dosyalar arasında çakışmalar olabilir. Merkezi Server, bu çakışmaları çözümleyerek hangi verinin öncelikli olduğunu belirlemek için belirli kurallar uygular. Eğer yanlış bir konfigürasyon yapılırsa, beklenmedik veri kayıpları veya tutarsızlıklar meydana gelebilir. Bu yüzden, çakışma çözümleme politikaları önceden tanımlanmalı ve test edilmelidir.

Özellikle büyük ölçekli organizasyonlarda, Hub and Spoke Topology, merkezi yönetim ve veri tutarlılığı açısından büyük avantaj sağlar. Ancak, performansın düşmemesi için donanım kapasitesinin iyi belirlenmesi, veri transfer süreçlerinin optimize edilmesi ve yedekleme planlarının eksiksiz oluşturulması gerekir. Herhangi bir darboğazın veya tek hata noktasının önüne geçebilmek için alternatif replikasyon senaryoları da göz önünde bulundurulmalıdır. Merkezi Server'a fazla yük binmesini önlemek amacıyla, yük dengeleme ve coğrafi dağıtılmış replikasyon modelleri ile desteklenmesi sağlıklı bir yapı oluşturacaktır.



 

Avantajlar

✅ Merkezi Yönetim: Tüm replikasyon trafiği merkezi bir Hub Server üzerinden yönetildiği için veri akışı daha kontrollüdür.

✅ Daha Az Bant Genişliği Kullanımı: Hub and Spoke, yalnızca merkezi Hub ile Spoke üyeleri arasında veri aktardığı için gereksiz Network trafiğini önler.

✅ Kolay Ölçeklenebilirlik: Yeni bir Spoke Server eklemek, Hub Server ile bağlantı kurarak kolayca yapılabilir.

✅ Replikasyon Trafiğinin Optimizasyonu: Veri senkronizasyonu merkezi bir noktada gerçekleştiğinden, geniş Network ortamlarında daha verimli çalışır.

✅ Daha Düşük Çakışma Riski: Merkezi Hub veri akışını yönettiği için aynı anda güncellenen verilerde çakışmaların oluşma ihtimali azalır.

Dezavantajlar

❌ Tek Hata Noktası (Single Point of Failure): Hub Server erişilemez hale gelirse, replikasyon durur.

❌ Daha Yavaş Veri Yayılımı: Tüm veriler önce Hub’a gider ve ardından Spoke’lara dağıtılır. Bu nedenle büyük veri setlerinde gecikmeler olabilir.

❌ Hub Üzerinde Yük Oluşur: Tüm replikasyon trafiği merkezi Hub üzerinden yönetildiği için, Hub Server yüksek yük altında performans sorunları yaşayabilir.

❌ Trafik Dengesizliği: Hub Server aşırı yüklenirse, Spoke Server'lar güncellemeleri zamanında alamayabilir.

Full Mesh

Full Mesh Topology, replikasyon sürecinde maksimum erişilebilirlik ve veri tutarlılığı sağlamak için kullanılan bir yapılandırma modelidir. Bu modelde, DFS replikasyon grubuna dahil olan tüm Server'lar birbirleriyle doğrudan replikasyon yapabilir. Her bir Server, diğer tüm Server'lar ile veri alışverişinde bulunur ve böylece merkezi bir yönlendirme noktası olmadan replikasyon gerçekleşir. Bu yapı, özellikle yüksek erişilebilirlik gerektiren senaryolarda tercih edilir.

Bu topolojinin en büyük avantajı, herhangi bir Server erişilemez hale gelse bile replikasyon sürecinin kesintiye uğramamasıdır. Çünkü her Server diğerleriyle doğrudan iletişim halinde olduğu için veri akışı devam eder. Merkezi bir bağımlılığın olmaması, tek hata noktası (Single Point of Failure) riskini ortadan kaldırır. Özellikle dağıtık sistemlerde ve farklı lokasyonlar arasında replikasyon gerektiren yapılarda Full Mesh Topology, veri sürekliliğini garanti altına alır. Ancak, bu avantajların yanında belirli zorlukları da beraberinde getirir.

Bu mimarinin en büyük dezavantajlarından biri, Network trafiğinin yoğunluğudur. Replikasyon süreci her Server arasında bağımsız olarak gerçekleştiği için, Server sayısı arttıkça replikasyon trafiği de katlanarak büyür. Örneğin, N adet Server içeren bir Full Mesh yapısında her Server, diğer (N-1) Server ile iletişim kurduğundan toplam bağlantı sayısı (N*(N-1))/2 formülü ile hesaplanır. 10 Server içeren bir sistemde 45 farklı bağlantı oluşurken, bu sayı 20 Server'da 190’a kadar çıkabilir. Bu durum, Network Bandwidth (bant genişliği) kullanımını artırarak gereksiz yük oluşmasına sebep olabilir. Özellikle geniş ölçekli ortamlarda, yanlış yapılandırılmış bir Full Mesh Topology ciddi performans problemlerine yol açabilir.

Bandsidth (bant genişliği) tüketiminin minimize edilmesi için belirli optimizasyon teknikleri kullanılmalıdır. Delta replikasyon mekanizması, sadece değişen verilerin senkronize edilmesini sağlayarak gereksiz veri trafiğini azaltabilir. Ayrıca, replikasyon zamanlamasının dikkatli planlanması ve Bandwidth (bant genişliği) sınırlamalarının uygulanması, Network üzerindeki yükü yönetilebilir seviyede tutar. Eğer replikasyonun sürekli olarak gerçek zamanlı olması gerekmiyorsa, zamanlanmış senkronizasyon tercih edilebilir. Böylece yoğun saatlerde replikasyon trafiğinin minimize edilmesi sağlanabilir.

Veri çakışmalarının yönetilmesi de önemli bir konudur. Tüm Server'lar arasında bağımsız replikasyon yapıldığı için, aynı anda güncellenen verilerde tutarsızlıklar yaşanabilir. Bu gibi senaryolarda, Conflict Resolution mekanizmalarının doğru yapılandırılması gerekir. Çakışma yönetimi için belirli politikalar tanımlanarak hangi verinin öncelikli olacağına karar verilmelidir. Eğer yanlış bir konfigürasyon yapılırsa, veri bütünlüğü bozulabilir ve senkronizasyon hataları yaşanabilir.

Bu mimarinin ölçeklenebilirliği de dikkat edilmesi gereken bir faktördür. Küçük ölçekli yapılarda oldukça verimli çalışan Full Mesh Topology, Server sayısı arttıkça yönetimi zorlaşan bir hale gelebilir. Büyük ölçekli ortamlarda bu yapı yerine, daha kontrollü bir veri akışı sağlayan Hub and Spoke Topology gibi alternatif çözümler düşünülmelidir. Eğer Full Mesh Topology kullanılacaksa, replikasyon süreçleri detaylı bir şekilde planlanmalı, Network üzerindeki yük sürekli olarak izlenmeli ve gerektiğinde kademeli olarak ölçeklendirme yapılmalıdır.

Tam erişilebilirlik ve yüksek dayanıklılık sunan Full Mesh Topology, doğru senaryolarda etkili bir çözüm olabilir. Ancak, Bandwidth (bant genişliği) tüketimi, veri çakışmaları ve ölçeklenebilirlik gibi faktörler göz önünde bulundurulmalı, replikasyon süreci detaylı bir şekilde planlanmalıdır. Aksi takdirde, sistem performansında ciddi düşüşler yaşanabilir ve yönetim karmaşıklığı artabilir.

Avantajlar

✅ Tam Yedeklilik: Her Server diğer tüm Server'larla replikasyon yaptığı için herhangi bir Server devre dışı kalsa bile replikasyon devam eder.

✅ Daha Hızlı Veri Senkronizasyonu: Veri, her Server arasında doğrudan senkronize edilir. Bu, kritik dosyaların anında tüm ortama yayılmasını sağlar.

✅ Bağımsız Replikasyon: Merkezi bir Hub’a bağımlı olunmadığından, veri akışı daha esnektir.

✅ Güçlü Direnç ve Süreklilik: Tüm Server'lar birbirleriyle doğrudan bağlantılı olduğu için Network hatalarına karşı daha dayanıklıdır.

Dezavantajlar

❌ Aşırı Network Trafiği: Her Server diğer tüm Server'larla replikasyon yaptığı için bağlantı sayısı hızla artar ve Network üzerindeki yük ciddi şekilde yükselir.

❌ Ölçeklenebilirlik Sorunu: Server sayısı arttıkça replikasyon trafiği katlanarak büyür. Büyük yapılarda yönetim zorlaşır.

❌ Çakışma Yönetimi Zorlaşır: Aynı anda birçok noktada değişiklik yapılırsa veri çakışmaları oluşabilir. Yanlış yapılandırılmış bir replikasyon politikası veri kaybına neden olabilir.

❌ Bant Genişliği Kullanımı Yüksek: Büyük veri setleri anında her Server'a replikasyon yaptığı için, özellikle düşük bant genişliği olan ortamlarda darboğaz oluşabilir.

Her iki topolojinin avantaj ve dezavantajları kullanım senaryosuna göre değerlendirilmelidir. Eğer merkezi bir yönetim istiyorsan Hub and Spoke, yüksek erişilebilirlik ve doğrudan veri paylaşımı gerektiren senaryolarda Full Mesh daha uygun olacaktır.

No Topology

No Topology seçeneği, DFS replikasyon grubu oluşturma aşamasında herhangi bir replikasyon topolojisi belirlemeyen ve daha sonra manuel konfigürasyon yapmaya imkan tanıyan bir modeldir. Bu seçenek, özellikle yapılandırma sürecini esnek tutmak isteyen veya replikasyon topolojisini oluşturduktan sonra daha detaylı bir analiz yaparak karar vermek isteyenler için kullanışlıdır. İlk kurulum aşamasında replikasyon trafiğini belirli bir topolojiye bağlı kalmadan devreye almak, daha sonra ihtiyaçlara göre spesifik bir yapılandırma yapmak isteyen ortamlar için uygun bir yaklaşımdır.

Bu yöntemin en büyük avantajı, sistemin anında belirli bir topolojiyle sınırlandırılmamasıdır. Örneğin, büyük ölçekli bir dağıtık Network yapısında, replikasyon yükünün nasıl dağıldığını gözlemleyerek daha optimize bir Hub and Spoke Topology veya Full Mesh Topology seçimi yapılabilir. Böylece, replikasyon gereksinimleri ve sistemin genel kaynak kullanımı detaylı olarak analiz edilebilir. Ancak, herhangi bir yapılandırma yapılmadığı sürece replikasyon işlemi otomatik olarak başlamaz ve manuel müdahale gerektirir.

Topoloji belirlenmediği için replikasyon grubu üyeleri arasında doğrudan veri alışverişi yapılmaz. Yapılandırmanın tamamlanması için DFS Management konsolu veya PowerShell komutları kullanılarak manuel olarak topoloji belirlenmeli ve gerekli replikasyon bağlantıları oluşturulmalıdır. Eğer bu adım atlanırsa, replikasyon grubu oluşturulmuş olsa dahi veri senkronizasyonu gerçekleşmez. Bu yüzden, No Topology seçeneği yalnızca ileri düzeyde konfigürasyon planlaması yapacak ve topolojiyi daha sonra manuel olarak belirleyecek ortamlar için tercih edilmelidir.

Manuel konfigürasyon yaparken, replikasyonun gerçekleşeceği üyeler arasındaki bağlantıların belirlenmesi ve replikasyon zamanlamalarının planlanması gereklidir. Özellikle büyük ölçekli ortamlarda, yanlış yapılandırılmış bir replikasyon senaryosu, gereksiz Network trafiği oluşmasına ve performans kayıplarına yol açabilir. Bu nedenle, No Topology seçeneğini kullanmadan önce detaylı bir planlama yapılmalı ve kullanılacak topoloji modeli için önceden senaryolar belirlenmelidir.

Esneklik sağlayan bu model, bilinçli kullanılmadığında sistemde gereksiz gecikmelere ve yönetim zorluklarına neden olabilir. Eğer belirli bir replikasyon modeli oluşturulması planlanıyorsa, baştan Hub and Spoke Topology veya Full Mesh Topology gibi seçeneklerden biri belirlenerek daha verimli bir yapı kurulabilir. Ancak, replikasyon trafiğinin nasıl yönetileceğine dair kesin bir karar verilmemişse, No Topology seçeneği sayesinde replikasyon grubu oluşturulabilir ve sonrasında manuel müdahale ile en uygun model belirlenebilir. Doğru bir yapılandırma ile kullanıldığında, replikasyon süreçlerini daha kontrollü yönetmeye olanak tanır ve sistemin ihtiyaçlarına göre optimize edilmesini sağlar.

Avantajlar

✅ Tam Esneklik: Herhangi bir replikasyon topolojisine bağlı kalmadan, sonradan manuel olarak istenilen yapılandırma yapılabilir.

✅ Aşırı Network Trafiğini Önleme: Başlangıçta gereksiz replikasyon bağlantıları oluşturulmadığı için sistem üzerinde gereksiz bant genişliği tüketimi olmaz.

✅ Özel Konfigürasyonlara Uygunluk: Varsayılan topolojiler yerine özel replikasyon senaryoları oluşturmak isteyenler için daha uygun bir seçenektir.

✅ Daha Kontrollü Geçiş Süreci: Replikasyon başlatılmadan önce mevcut sistem analiz edilebilir ve en uygun yapılandırma belirlendikten sonra replikasyon grubu etkinleştirilebilir.

✅ Ölçeklenebilirlik Avantajı: Büyük ortamlarda ilk aşamada topoloji belirlemek yerine, sistemin ölçeklenebilirliği göz önünde bulundurularak aşamalı yapılandırma yapılabilir.

Dezavantajlar

❌ Manuel Konfigürasyon Gerektirir: Varsayılan bir topoloji olmadığı için tüm replikasyon bağlantılarının elle yapılandırılması gerekir. Yanlış yapılandırmalar replikasyonun başarısız olmasına neden olabilir.

❌ İlk Kurulumda Replikasyon Gerçekleşmez: No Topology seçildiğinde herhangi bir replikasyon bağlantısı otomatik olarak oluşturulmaz, bu nedenle replikasyon süreci elle başlatılana kadar veri senkronizasyonu gerçekleşmez.

❌ Zaman Kaybı: Replikasyon grubu oluşturulduktan sonra manuel yapılandırma yapılmazsa, sistem beklenenden daha uzun süre senkronizasyon başlamadan çalışabilir.

❌ Hata Yönetimi Daha Karmaşıktır: Doğru konfigüre edilmezse, replikasyon trafiği hiç başlamayabilir veya hatalı bağlantılar nedeniyle tutarsız veriler oluşabilir.

❌ Yanlış Konfigürasyon Performans Sorunlarına Yol Açabilir: Eğer replikasyon bağlantıları yanlış oluşturulursa, veri akışı optimize edilmez ve gereksiz yük oluşturabilir.

No Topology, replikasyon sürecini tamamen kullanıcı kontrolüne bırakır. Eğer detaylı konfigürasyon yapabilecek bir yapı gerekiyorsa avantajlıdır, ancak varsayılan bir yapılandırmaya sahip olmadığı için yanlış kullanıldığında replikasyonun başlamaması veya verimsiz çalışması gibi riskler taşır.

Topoloji seçimime, Full Mesh Topology seçeneğini seçerek devam ediyorum.


 

22- Replication Group Schedule and Bandwith adımında, replikasyon grubu için çoğaltma yapılacak zanan planı ve bant genişliği kullanımı ayarlanır.

22.1- 7/24 sürekli replikasyon gerçekleştirmek için Replicate continuously using the specified bandwith seçeneği seçilir ve alt kısımdaki Bandwith listesinden de bant genişliğinden ne kadarlık kısmının bu replikasyon grubuna ayıracağımızı belirleriz.

22.2- Sadece belli gün ve saatler arasında çoğaltma yapılacaksa, Replicate during the specified days and times seçemeği seçili iken gerekli planlama, alt kısımdaki Edit Schedule butonu ile gelen ekranda yapılır.



23- Primary Member adımında, paylaşım klasörü içinde tutulan içeriklerin, diğer replikasyon grubu üyelerine replikasyon işlemini yapacak olan Primary Server'ı seçiyor, Next butonuna basarak devam ediyorum.




24- Folders to Replicate adımında, replikasyon grubu üyelerine replikasyon işlemi yapılacak olan paylaşım klasörümü seçiyorum. Seçim yapmak için Add... butonuna basıyorum.



24.1- Açılan Add Folder to Replicate penceresinde Local path of folder to replicate bölümünde Browse... butonuna basıyorum.



24.2- Replikasyon işlemi yapılacak olan paylaşım klasörümü ilgili NTFS Volume üzerinde seçiyorum.



24.3- Local path of folder to replicate bölümünde Replikasyon işlemi yapılacak olan paylaşım klasörümün bulunduğu NTFS Volume Path bilgisi geldi. Dilerseniz bu işlemi, ilgili NTFS Volume Path bilgisini biliyorsanız, elle de yazabilirsiniz. İşlemimi bitirdikten sonra OK butonuna basarak pencereyi kapatıyorum.



24.4- İlgili NTFS Volume Path bilgisi, replikasyonu yapılacak paylaşım klasörü bilgisini görüyoruz. Next butonuna basarak devam ediyorum.



25- Local Path of Home Folders on Other Members adımında, Folders to Replicate adımında olduğu gibi, replikasyon grubundaki diğer DFS Server'ım üzerindeki ilgili NTFS Volume üzerinde bulunan paylaşım klasörümü seçeceğim. Edit... butonuna basarak, seçme işlemine başlıyorum.



25.1- Açılan pencerede öncelikli olarak Membership status altındaki Enabled seçeneğini seçiyor, Local path of folder bölümünde de Browse... butonuna basarak replikasyon işlemi yapılacak olan paylaşım klasörümü ilgili NTFS Volume üzerinde seçiyorum.




25.2- Local path of folder to replicate bölümünde Replikasyon işlemi yapılacak olan paylaşım klasörümün bulunduğu NTFS Volume Path bilgisi geldi. Dilerseniz bu işlemi, ilgili NTFS Volume Path bilgisini biliyorsanız, elle de yazabilirsiniz. İşlemimi bitirdikten sonra OK butonuna basarak pencereyi kapatıyorum.



25.3- Replikasyon grubu üyesi hedef DFS Server'ım, ilgili NTFS Volume Path bilgisi ile replikasyonu yapılacak paylaşım klasörü bilgisini görüyoruz. Next butonuna basarak devam ediyorum.



26- Review Settings and Create Replication Group adımında, replikasyon grup ayarlarının bir özeti bulunmaktadır. Yapılandırma ayarlarımız doğru ise, Create butonuna basarak DFS Replication Group oluşturma işlemine başlıyorum.



27- Confirmation adımında başarılı bir şekilde replikasyon grubumun oluştuğunu görüyorum. Close butonuna basarak ilgili Wizard ekranını kapatıyorum.



28- Close butonuna bastığımda karşıma, oluşturduğum replikasyonun, replikasyon grup üye sunucu(lar) tarafından alınana kadar, replikasyonun başlamayacağına dair bir bilgi mesajı çıkıyor. Başka bir ifade ile, oluşturduğum replikasyon, replikasyon grup üye sunucu(lar) üzerinde de otomatik oluşması gerekiyor.

Bu işlem, DFS ile replike olacak olan hedef DFS Server'ın, Active Directory Sites and Services üzerinde belirlediğiniz Site yapısına göre Intrasite Replication ya da Intersite Replication sürelerine bağlı olarak zaman alacaktır. Hedef DFS Server'ınız aynı Site içinde ise, varsayılan olarak Intrasite Replication süresi olan 15 dakika sonra oluşturduğunuz Replication Group bilgisini alacaktır.

Hedef DFS Server'ınız farklı bir Site içinde ise, varsayılan olarak Intersite Replication süresi olan 180 dakika sonra oluşturduğunuz Replication Group bilgisini alacaktır. Bu süresi beklemek istemezseniz, Replication Group'u oluşturduğunuz Site içindeki Domain Controller üzerinde repadmin /syncall /APed komutunu çalıştırarak, replikasyonu anlık olarak tetikletebilirsiniz.



29- Replication altında, oluşturduğum replikasyonun geldiğini görebiliyoruz.

File Staging Kavramı

File Staging kavramı, DFS Replication (DFS-R) yapısının kritik bir bileşeni olarak karşımıza çıkar. Bu mekanizma, dosya transferlerinin daha verimli bir şekilde gerçekleştirilmesini sağlarken, özellikle büyük dosyalar ve düşük bant genişliğine sahip Network'lerde veri aktarım sürecini optimize eder. DFS Replication, yeni veya değişen dosyaları, Sending Member'dan (gönderen üyeden) Receiving Member'a (alıcı üyeye) replike ederken Staging Folders adında geçici bir depolama alanı kullanır. Bu klasör, replike edilecek dosyaların hazırlanması ve blok seviyesinde işlenmesi için hayati bir rol oynar. Staging işlemi, dosyanın yalnızca değişen kısımlarının gönderilmesini ve dosyanın sıkıştırılarak daha küçük bir boyutla karşı tarafa transfer edilmesini mümkün kılar.

File Staging Süreci

DFS-R, Remote Differential Compression (RDC) etkinleştirildiğinde, dosya transferi sırasında yalnızca değişen veri bloklarını transfer ederek, Network üzerindeki trafiği minimize eder. Bu sayede büyük boyutlu dosyalarda bile minimum veri transferi yapılır, bu da bant genişliği kullanımını düşürür ve transfer sürelerini kısaltır. Gönderici üye, bir alıcıdan dosya talebi aldığında, ilk olarak Staging sürecine başlar. Bu aşamada, replike edilecek dosyalar Replicated Folder adı verilen kaynak klasörden okunur ve gerekli sıkıştırma işlemleri yapılır. Bu sıkıştırılmış dosya, Staging Folder adı verilen geçici klasöre yerleştirilir ve burada Staged File olarak adlandırılır. Staging Folder, transfer edilecek dosyaların geçici olarak depolandığı yerdir.

Gönderici üye, talep edilen dosyayı Staging Folder’a aldıktan sonra, alıcı üyeye transfer etmeye başlar. RDC açık ise, yalnızca dosyanın değişen kısımları transfer edilir. Bu süreç, özellikle geniş Network'ler ve WAN bağlantıları üzerinden yapılan dosya transferlerinde Network performansını ciddi şekilde iyileştirir. RDC'nin kapalı olduğu senaryolarda ise, dosyanın tamamı alıcı üyeye gönderilir, bu da daha fazla bant genişliği kullanımı anlamına gelir.

Alıcı üye, bu dosyayı aldıktan sonra benzer bir süreci takip eder. Önce dosyayı kendi Staging Folder’ına yerleştirir, ardından bu Decompress edilir yani dosya açılır ve sonrasında replike edilen klasör (Replicated Folder) içerisine eklenir. Bu iki yönlü süreç, veri senkronizasyonunun tutarlı bir şekilde yapılmasını sağlar ve her iki tarafta da aynı veri setinin güncellenmesini garantiler.

Staging Folder’ın Yapısı ve Yönetimi

Her bir Replicated Folder, kendine ait bir Staging Folder’a sahiptir. Varsayılan olarak bu klasör, replike edilen klasörün dizin yolu içerisinde bulunan DfsrPrivate adlı özel bir klasör altında yer alır. DfsrPrivate klasörü, DFS-R tarafından otomatik olarak oluşturulur ve bu klasörü elle düzenlemesi veya kaldırması önerilmez. Bu klasör, replikasyon sürecinde kullanılan dosyaların geçici olarak depolandığı alan olduğu için sistemin sağlıklı çalışması açısından kritik bir öneme sahiptir.

Staging Folder’ın boyutu, dosya transfer performansını doğrudan etkileyen bir faktördür. Bu klasör için ayrılan depolama alanı, replike edilen dosya boyutları ve sıklığı ile orantılı olmalıdır. Yeterli depolama alanı ayrılmadığında, DFS Replication işlemleri sırasında performans sorunları yaşanabilir. Bu nedenle, Staging Folder boyutununun sürekli izlenip, gerektiğinde boyutunun artırılması önemlidir. DFS-R, Staging Folder boyutunu otomatik olarak yönetebilir ve gereksiz dosyaları temizleyerek klasörü düzenli tutar. Ancak, büyük boyutlu ve sık değişen dosyaların bulunduğu ortamlarda manuel müdahaleler gerekebilir.

File Staging ve Performans İyileştirmeleri

Staging mekanizması, DFS Replication’ın performansını optimize etmede kilit bir rol oynar. Özellikle RDC etkinleştirildiğinde, dosyanın yalnızca değişen kısımları transfer edildiği için Network trafiği ve bant genişliği kullanımı büyük ölçüde azalır. Bununla birlikte, Staging Folder boyutunun doğru yapılandırılması ve yönetilmesi de replikasyon sürecinde performansın korunması açısından önemlidir.

Staging Folder’ın boyutu, varsayılan olarak DFS-R tarafından dinamik bir şekilde yönetilir. Ancak, replike edilen klasörler arasında çok büyük dosyalar varsa ya da sürekli değişen dosyalar sıkça senkronize ediliyorsa, bu durumda Staging Folder’ın kapasitesi dolabilir ve replikasyon işlemleri yavaşlayabilir. Bu gibi senaryolarda, DFS-R yönetim konsolu üzerinden Staging Folder boyutunu manuel olarak artırmak gerekebilir. Ayrıca, Staging Folder üzerinde disk alanı sınırlıysa, büyük dosyaların replikasyonu sırasında yetersiz disk alanı sorunları ortaya çıkabilir. Bu nedenle, Staging Folder’ın yer aldığı disk alanının yeterli olduğundan emin olmak, replikasyon performansının sürekliliği açısından kritik bir adımdır.

30- Replication Group oluşturma işleminden sonraki işlemimiz, her paylaşım klasörü için Staging kota belirlemek olacak. Bunun için, oluşturduğum Replication Group altındaki Membership sekmesi içindeki ilgili Replicated Folder üzerinde sağ tıklayarak Properties seçeneğini seçiyorum.



30.1- Açılan pencerede Staging sekmesi altında iligi Staging kota yapılandırmamı yapacağım. Varsayılan olarak bu klasörün boyutu 4096 MB'tır. Bu, değiştirilebilir bir limittir.

Staging Klasörü, DFS Replication (DFS-R) yapısında dosya transferlerinin daha verimli şekilde yönetilmesi için kritik bir rol oynar. Bu klasör, replikasyon sürecinde dosyaların blok seviyesinde işlenip sıkıştırılarak karşı tarafa gönderilmek üzere hazırlandığı geçici bir depolama alanıdır. Ancak, Staging Klasörü'nün doğru yönetilmemesi durumunda, performans sorunları ve hata durumları ortaya çıkabilir. Özellikle büyük boyutlu dosyalarla çalışıldığında, Staging Klasörü'nün kota limitlerine ulaşması sürecin aksamasına neden olabilir.

DFS Replication, Staging Klasörü dolduğunda otomatik bir Cleanup (temizleme) süreci başlatır. Bu mekanizma, Staging Klasörü'nün %90'ına ulaştığında devreye girer ve klasördeki eski dosyaları silerek yer açmaya çalışır. Sistem, %60 boş alan kalıncaya kadar eski dosyaları temizlemeye devam eder. Bu süreç genellikle sorunsuz çalışır ve klasörde yeterli boş alan yaratır. Ancak, büyük boyutlu dosyalar işlenirken bu temizleme süreci daha karmaşık hale gelir ve bazen hata verebilir.

Büyük Boyutlu Dosyalar ve Staging Klasörü Yönetimi

Büyük boyutlu dosyalar için Staging Klasörü, dosyanın transfer edilmek üzere hazırlandığı geçici alanı sunar. Ancak, bu tür dosyalar Staging Klasörü’ne alındığında kota sınırlarını hızla doldurabilir. Böyle bir durumda, DFS-R, büyük dosyaları sıkıştırarak karşı tarafa göndermek üzere hazırlarken, klasörde eski dosyaları temizlemeye çalışır. Ancak, burada kritik bir sorun ortaya çıkar: Transfer süreci devam ederken hala işlenen büyük dosyalar, eski dosya olarak kabul edilemez ve temizlenemez. Bu durumda, Cleanup süreci başarısız olur ve hata mesajları ile karşılaşılabilir. Hatanın temel sebebi, büyük dosyanın henüz tam olarak işlenmemiş ve transfer edilmemiş olmasıdır. Bu aşamada dosya hala işleniyor olduğundan, sistem bu dosyayı silmeye çalışsa da silme işlemi gerçekleşemez.

Bu sorun, genellikle büyük dosyalarla çalışan ortamlarda daha sık ortaya çıkar. Özellikle dosya boyutları Staging Klasörü için belirlenen kotanın üzerine çıktığında, bu tip sorunlar daha belirgin hale gelir. Çözüm olarak, Staging Klasörü’nün kotasının artırılması önerilir. Böylece, büyük dosyalar işlenirken klasörde yeterli alan olur ve sistem eski dosyaları silmeye çalışmadan bu dosyaların işlenmesini tamamlayabilir. Staging Klasörü kotası artırıldığında, büyük dosyalar için yeterli geçici alan sağlanır ve performans sorunları minimize edilir.

Staging Kotasının Artırılması

Eğer sistemde sık sık büyük boyutlu dosyalarla çalışılıyorsa, Staging Quota (Staging klasörü kotası) artırılması, DFS Replication’ın daha sağlıklı çalışması açısından kritik öneme sahiptir. Küçük bir kotaya sahip Staging Klasöründe, büyük dosyaların işlenmesi sırasında yaşanan sıkışıklık, hem replikasyon sürecini yavaşlatabilir hem de sıkça hata mesajlarına sebep olabilir. Bu yüzden büyük dosyalarla çalışan sistemlerde varsayılan kotanın artırılması, sistemin sürekli sorunsuz çalışmasını sağlar.

Staging kotasını artırmak, her replikasyon grubunda bulunan tüm üye sunucular üzerinde tek tek yapılması gereken bir işlemdir. DFS-R, her sunucuda kendi Staging klasörünü kullanır ve bu klasörün kotası her sunucuda ayrı ayrı ayarlanır. Dolayısıyla, replikasyon grubundaki tüm sunucuların Staging Kotasını artırmanız gerektiğinde, her sunucu üzerinde bu işlemi manuel olarak yapmanız gerekir. Bu süreç, zaman alıcı olabilir ancak büyük dosyalarla çalışan sistemlerde bu ayarların yapılması, uzun vadede performans ve veri transfer süreçlerinin kesintisiz devam etmesi açısından önemli bir adımdır.

Düşük Staging Kotasının Yarattığı Sorunlar

Düşük bir Staging Kotasına sahip olmak, büyük dosyalarla çalışılan ortamlarda ciddi sorunlar yaratabilir. Stagging Quota düşük olduğunda, büyük dosyalar işlenirken yer sıkıntısı yaşanır ve bu durumda DFS-R, eski dosyaları temizlemeye çalışır. Ancak bu dosyalar hala işleniyor olabileceği için silinemediğinde replikasyon süreci aksayabilir. Bu da Network trafiğini artırabilir, verilerin senkronizasyonunda gecikmelere yol açabilir ve kullanıcılar için veri erişiminde sorunlar yaratabilir. Özellikle sürekli büyük boyutlu dosyalarla çalışılan bir Network ortamında, bu tür sorunların yaşanması kaçınılmazdır.

Bu nedenle, büyük dosyalarla çalışan bir sistemde Staging Kotasının düşük tutulması önerilmez. Düşük bir kota, gereksiz kaynak tüketimine yol açabilir ve replikasyon işlemlerinin performansını olumsuz yönde etkileyebilir. Her sunucuda Staging Kotasını artırmak, büyük dosya transferlerinin daha hızlı ve sorunsuz gerçekleşmesini sağlar, böylece Network üzerindeki yük de azaltılır.



31- Yukarıda, replikasyon grubundaki tüm üye sunucularda Staging Quota (kota) boyutu artırma işlemini tek tek yapmanız gerektiğinden bahsetmiştim. Yine aynı şekilde bu seferde diğer üye sunucu üzerindeki ilgili Replicated Folder üzerinde sağ tıklayarak Properties seçeneğini seçiyor, açılan pencerede Staging sekmesi altında iligi Staging Quota (kota) yapılandırma işlemini aynı şekilde yapıyorum.




31.1- Her iki replikasyon grubundaki üye sunucularda Staging Quota (kota) boyutu yapılandırma işlemimi tamamladım.



31.2- RDC-Remote Differential Compression, Şubeler arası WAN-Wide Area Network hatlarındaki hız düşük seviyede ise, yüksek boyutlu dosyaların sadece değişen kısımlarının sıkıştırılarak Staging klasörüne eklenmesi için en ideal yöntemdir. Varsayılan olarak açık durumda olan RDC, iligli Replication Group üzerinde Connections sekmesindeki bağlantılar üzerinde sağ tıklayarak Properties seçeneği üzerinden açılıp, kapatılabilir.

NOT: Bu iki resim sonradan eklendiği için içerikteki isimlendirmeler farklıdır.

32- Bir sonraki adımda yapacağım işlem, yine oluşturduğum Replication Group altındaki Replicated Folders sekmesi içindeki replike edeceğim paylaşım kalasörümü, oluşturduğum Namespace altında Publish etmek (yayınlamak) olacak. Bunun için replike edeceğim paylaşım kalasörümün bulunduğu kısımda sağ tıklayarak Share and Publish in Namespace... seçeneğini seçiyorum.



33- Açılan Share and Publish Replicated Folder Wizard penceresinde Publishing Method bölümünde Share and Publish the replicated folder in Namespace seçeneğini seçiyor, Next butonuna basarak devam ediyorum.



34- Share Replicated Folders adımında, replike edeceğim paylaşım kalasörümün hangi DFS Server üzerinde ve hangi Namespace altında Publish edileceğini seçiyorum. Next butonuna basarak devam ediyorum.



35- Namespace Path adımında, Parent folder in Namespace bölümünde Publish edeceğim Namespace'imi seçmek için Browse... botonuna basıyorum.



35.1- Açılan pencerede, daha önce oluştuduğum Namespace'imi seçiyor, OK butonuna basarak pencereyi kapatıyorum.




35.2- İlgili Namespace'imi seçme işlemimi bitirdikten sonra, Next butonuna basarak devam ediyorum.



36- Review Settings and Share Replicated Folder adımında karşımıza, yapılandırma ayarlarımızın özeti çıkıyor. Yapılandırma ayarlarımız doğru ise, Share butonuna basarak iligi Namespace altında Publish etme işlemimizi tamamlıyoruz.



37- İligi Namespace altında Publish etme işlemimiz tamamlandı. Close butonuna basarak pencereyi kapatıyorum.



38- Paylaşım kalasörümün oluşturduğum Namespace altında Publish edildiğini görebiliyoruz.



39- Tüm işlemlerimizi tamamladıktan sonra sıra, replikasyon grubundaki üye DFS Server üzerindeki DFS Management'ı açıp, oluşturduğum replikasyonun bu DFS Server üzerinde de oluştuğunu görüyorum.



40- İsteğe bağlı olarak ilgili Namespace'in, replikasyon grubundaki üye DFS Server üzerindeki DFS Management altında bulunan Namespaces kısmında görünmesini isteyebilirsiniz. Bunun için, DFS Management altında bulunan Namespaces üzerinde sağ tıklayarak Add Namespaces to Display... seçeneğini seçiyorum.



40.1- Açılan pencerede, Namespaces altında ilgili Namespace'i seçip, OK butonuna basarak ekleme işlemini gerçekleştiriyorum.




41- Replikasyon grubundaki üye Replicated DFS Server üzerinde bulunan NTFS Volume'da oluşturduğum ancak içi boş olan paylaşım klasörüm içine, Primary DFS Server üzerinde bulunan NTFS Volume'da oluşturduğum paylaşım klasörüm içindeki tüm klasör ve dosyaların başarılı bir şekilde replike olduğunu görebiliyoruz.


 

DFS High Availability-HA (Yüksek Erişilebilirlik) Oluşturma

Buraya kadarki işlemlerimizde DFS Server'lar üzerinde, DFS yapısının oluşması için gerekli olan tüm işlemleri tamamladık. Sıra, en önemli kısım olan, Yüksek Erişilebilirlik (High Availability) oluşturma işlemine geldi.

DFS High Availability (HA), birden fazla DFS Server kullanarak dosya paylaşımının kesintisiz şekilde devam etmesini sağlamak için yapılandırılan bir mekanizmadır. Normal şartlarda, DFS Server'lardan biri DOWN olduğunda ilgili Namespace üzerindeki paylaşım klasörlerine erişim mümkün olmayabilir. Ancak High Availability yapılandırmasıyla, bir DFS Server devre dışı kaldığında diğer Server'lar üzerinden erişim kesintisiz olarak devam eder. Bu, hem veri kaybını önlemek hem de kullanıcıların dosyalara ulaşmasını garanti altına almak için gereklidir.

Bu yapıyı oluştururken, DFS Namespace'in en az iki farklı DFS Server üzerinde barındırılması gerekir. Namespace, Active Directory ile entegre olarak çalıştığından, Namespace Server'lar üzerinden sağlanan erişim noktaları Active Directory ile senkronize edilir. Eğer bir DFS Server devre dışı kalırsa, istemciler otomatik olarak diğer Namespace Server üzerinden yönlendirilir ve kesinti yaşanmadan çalışmaya devam eder. Bu süreç, Active Directory'nin Site-Aware mekanizmasıyla daha da optimize edilebilir, böylece istemciler her zaman kendilerine en yakın ve en az yük altındaki DFS Server'a yönlendirilir.

DFS Replication (DFSR) ile birlikte kullanıldığında, High Availability mekanizması daha güçlü hale gelir. DFSR, replikasyon grubu üyeleri arasında verileri otomatik olarak senkronize ederek herhangi bir noktada oluşabilecek veri kaybının önüne geçer. Ancak, burada replikasyon topolojisinin doğru seçilmesi büyük önem taşır. Örneğin, Full Mesh Topology, tüm Server'ların birbirleriyle replikasyon yapmasını sağlarken Hub and Spoke Topology, merkezi bir noktadan veri yayılımını yönetir. Bu yapılandırmanın seçimi, ortamın büyüklüğüne, veri değişim sıklığına ve Network altyapısına bağlı olarak değişmelidir.

Load Balancing mekanizması, DFS High Availability için tamamlayıcı bir unsurdur. DFS Server'ların yük dengesini sağlamak ve istemci bağlantılarını en uygun hedefe yönlendirmek için Active Directory ve DNS Round Robin kullanılabilir. DNS Round Robin, istemcilerin farklı DFS Server'lara rastgele yönlendirilmesini sağlar, ancak gerçek zamanlı yük dengelemesi yapmaz. Alternatif olarak, DFS Server'lar için bir Failover Cluster oluşturulabilir, ancak bu yaklaşım DFS Namespace'in bağımsız yapısını korumak yerine daha sıkı bir entegrasyon gerektirir.

Erişilebilirliği artırmak için belirli Best Practice'ler uygulanmalıdır. DFS Server'ların farklı fiziksel lokasyonlarda konumlandırılması, tek bir veri merkezine bağımlılığı ortadan kaldırır. Replikasyon sıklığının ortamın gereksinimlerine göre ayarlanması, gereksiz bant genişliği kullanımını önler. Ayrıca, Event Log'lar düzenli olarak kontrol edilerek replikasyon hataları veya senkronizasyon sorunları hızlıca tespit edilmelidir. Bir DFS Server üzerinde disk arızası veya performans düşüşü yaşanırsa, sistemin diğer Server'lara yük devretmesi sağlanmalıdır.

Bu yapılandırma tamamlandıktan sonra, istemcilerin DFS Namespace üzerindeki klasörlere kesintisiz erişimi test edilmelidir. Test sürecinde, belirli DFS Server'lar devre dışı bırakılarak istemcilerin nasıl tepki verdiği gözlemlenmeli ve yönlendirme mekanizmasının doğru çalıştığından emin olunmalıdır. Eğer istemciler beklenmedik gecikmeler veya erişim hataları ile karşılaşıyorsa, Namespace ayarları ve Active Directory ile entegrasyon tekrar gözden geçirilmelidir. Sağlam bir DFS High Availability yapılandırması, sadece sistemin teorik olarak çalışmasını değil, pratikte kesintisiz ve hızlı erişimi garanti edecek şekilde test edilmesini gerektirir.

42- DFS Management altındaki Namespaces'e tıklıyorum. Namespace Servers sekmesi altında varsayılan olarak Primary DFS Server'ım olan \\FILESRV001\HomeFolders Namespace Server'ım bulunuyor. Burada yapmak gereken, Yüksek Erişilebilirlik (High Availability) için replikasyon grubundaki üye Replicated DFS Server olan FILESRV002 Hostname'li DFS Server'ımı da sağ kısımda bulunan Add Namespace Server... üzerinden eklemek olacak.



42.1- Açılan pencerede, Browse... butonuna tıklayarak FILESRV002 Hostname'li DFS Server'ımı seçmek olacak.





42.2- FILESRV002 Hostname'li DFS Server'ımı, Namespace Servers altında ekleyerek Yüksek Erişilebilirlik (High Availability) için gerekli aksiyonu almış bulunuyorum.



42.3- FILESRV002 Hostname'li DFS Server'ımdaki DFS Management üzerinde de iligi Namespace Server'ın eklendiğini görebiliyoruz.



43- Önemle tevsiye ettiğim bir diğer işlem ise; replikasyon grubundaki tüm üye DFS sunucuların, bulundıkları Active Directory Site içinden erişilmesini sağlamak olacak. Bunun için yine DFS Management altındaki Namespaces üzerinde sağ tıklıyor, Properties seçeneğini seçiyorum.



DFS Namespace yapılandırmasında, Namespace Server'ların Active Directory'den nasıl veri çekeceği belirlenirken iki farklı optimizasyon yöntemi bulunur.

Optimize for Consistency seçeneği, Namespace Server'ların her değişiklikte Primary Domain Controller üzerinden güncelleme almasını sağlar. Ancak büyük ve dağıtık ortamlarda, bu yaklaşım gereksiz yük oluşturabilir ve ölçeklenebilirliği sınırlandırabilir.

Optimize for Scalability seçildiğinde, her Namespace Server en yakın Domain Controller ile belirli aralıklarla iletişime geçerek Namespace verilerini günceller. Böylece merkezi yük azaltılır ve replikasyon süreci daha dengeli çalışır. Özellikle geniş coğrafi dağılıma sahip ortamlarda, istemcilerin kendilerine en yakın Namespace Server üzerinden güncelleme alması sağlanır. Bu sayede gereksiz gecikmelerin önüne geçilir ve DFS Namespace'in performansı artırılır.

Bu yapılandırmada, Namespace değişikliklerinin anlık yansıtılması yerine, belirli periyotlarla yapılan senkronizasyon tercih edilir. Eğer DFS ortamında sık değişiklikler oluyorsa ve anında güncelleme gerekliliği varsa, Optimize for Consistency seçeneği daha uygun olabilir. Ancak, büyük ölçekli ortamlarda Network trafiğini optimize etmek ve Active Directory üzerindeki yükü azaltmak için Optimize for Scalability tercih edilmelidir.

Yapılandırma sonrası, Namespace Server'ların doğru Domain Controller'lar ile eşleştiğini ve replikasyon süreçlerinin planlanan periyotlarla gerçekleştiğini doğrulamak gerekir. Yanlış yapılandırılmış bir senkronizasyon politikası, istemcilerin eski veya hatalı Namespace verilerine erişmesine neden olabilir. Bu yüzden, seçim yapılırken ortamın büyüklüğü, değişim sıklığı ve Network altyapısı dikkatle değerlendirilmelidir.

43.1- Açılan pencerede Advanced sekmesi altında Optimize for scalability seçeneğini seçiyorum.

Yüksek Erişilebilirlik (High Availability) Test Aşaması

44- Bir Active Directory kullanıcısı ile, Windows 10 işletim sistemli bir bilgisayara Logon oluyorum. DFS Namespace'im altında önceden Map'lediğim Home Folder'ı görebiliyorum.



44.1- Map'lediğim Home Folder içinde girdiğimde karşıma, Active Directory kullanıcısının Profil klasörleri çıkıyor.



44.2- Desktop klasörü içine girerek, bir kaç klasör oluşturuyorum. Bu arada klasör üzerinde sağ tıklayarak klasör özelliklerini incelediğimde, DFS sekmesi altında aktif durumdaki DFS Server'ı görebilirsiniz.



44.3- Active Directory kullanıcısının Map üzerindeki Desktop klasöründe oluşturduğum klasörlerin, replikasyon grubundaki tüm üye DFS sunucuların NTFS Volume'lerindeki Home Folders paylaşım klasörüne replike olduğunu görebiliyoruz.




45- Aktif durumdaki FILESRV002 Hostname'li DFS Server'ımı DOWN durumuna getiriyorum.





46- Aktif durumdaki FILESRV002 Hostname'li DFS Server'ımı DOWN durumuna getirdikten sonra, Map'li Paylaşım klasörüne tekrar erişmek istediğimde, sunucu DOWN durumda olmasına rağmen erişilebildiğini görüyoruz. Yine DFS sekmesini incelediğimizde bu sefer de Aktif durumdaki DFS Server'ın, FILESRV001 Hostname'li DFS Server olduğunu görebiliyoruz.





Bu şekilde Yüksek Erişilebilirlik (High Availability) sağlayarak, kaynaklara kesintisiz erişim sağlamış oluyoruz. Bu makale ile birlikte, Windows Server 2016 üzerinde High Availability (HA) sağlayan DFS Server yapısının işlevselliği ve sunduğu avantajlar üzerine kapsamlı bir bakış sunuldu. Bu noktaya kadar yapılan açıklamalar ışığında, DFS Server’ın Network üzerindeki kritik rolü ve erişilebilirliği nasıl optimize ettiği konusunda daha geniş bir perspektif kazanıldığını söyleyebiliriz. Okuyucunun artık bu yapılandırmanın ne kadar hayati olduğunun farkına varması gerektiği bir noktadayız. Bu aşamadan sonra, her sistem yöneticisinin kendi Network'ü için benzer yapılar oluşturması gerekliliği, iş sürekliliği açısından kaçınılmazdır.

DFS gibi teknolojilerle sadece kısa vadeli çözümler değil, aynı zamanda uzun vadeli verimlilik ve güvenilirlik sağlayan yapıların kurulabileceği ortaya konmuştur. Makalenin sunduğu bilgiler doğrultusunda, daha yüksek erişilebilirlik sağlamak adına bu teknolojilerin etkili kullanımı önem kazanmaktadır.

Faydalı olması dileğiyle...