NFS, SSHFS ve rsync ile Çok Sunuculu Dosya Paylaşımı

Birden Fazla Web Sunucusunda Dosya Paylaşımı Neden Kritik?

Bir web uygulamasını tek bir sunucudan alıp, iki ya da daha fazla web sunucusuna yaymaya karar ettiğiniz anda karşınıza ilk çıkan soru şudur: “Bu sunucular aynı dosyalara nasıl erişecek?” Özellikle WordPress, Laravel, WooCommerce ya da dosya ağırlıklı özel uygulamalarda; kullanıcı yüklemeleri, loglar, cache ve deploy edilmiş kodun birbiriyle tutarlı kalması işin en zor kısmıdır.

DCHost tarafında yeni bir çok sunuculu mimari planlarken, proje planlama toplantılarında en çok üzerinde durduğumuz konulardan biri tam olarak bu: Paylaşımlı depolama mı kuracağız, yoksa her sunucunun kendi diskinde tutulan dosyaları akıllı bir senkronizasyon ile mi yöneteceğiz? NFS, SSHFS ve rsync bu noktada en sık kullanılan üç araç. Her biri farklı ihtiyaçlara iyi cevap veriyor; ama yanlış senaryoda seçildiğinde performans, güvenlik ve veri bütünlüğü tarafında ciddi baş ağrıları yaratabiliyor.

Bu yazıda, birden fazla web sunucusu arasında dosya paylaşımı için NFS, SSHFS ve rsync’i teknik, pratik ve operasyonel boyutlarıyla ele alacağız. Hangi senaryoda hangisinin öne çıktığını, nerede sorun çıkardığını ve DCHost altyapısında bu çözümleri nasıl konumlandırabileceğinizi adım adım netleştireceğiz.

Önce Mimariyi Netleştirelim: Ne Paylaşılıyor?

Teknik detaya girmeden önce, çok sunuculu bir mimaride hangi dosyaların gerçekten paylaşılması gerektiğini ayırmak önemli. Gereksiz paylaşımlar hem performansı düşürür hem de hata yüzeyini büyütür.

Paylaşılması Gereken Tipik Klasörler

• Kullanıcı yüklemeleri: WordPress’te wp-content/uploads, Laravel’de storage/app/public gibi klasörler. Dosya yükleme formu hangi sunucuya denk gelirse gelsin, diğer sunucuların da bu dosyayı görebilmesi gerekir.
• Paylaşılan statik içerik: Versiyonlanmamış görseller, dokümanlar, rapor çıktıları.
• Oturum veya cache dosyaları (kısmen): Dosya tabanlı PHP session kullanıyorsanız, tüm web sunucuları aynı session dizinini okuyor olmalıdır. Ancak çoğu senaryoda burada Redis gibi ayrı bir çözüm tercih etmek daha sağlıklıdır.
• Loglar (opsiyonel): Uygulama loglarının tek yerde toplanması güzel; ama bunu zorunlu olarak paylaşımlı dosya sistemiyle yapmak şart değil. Merkezi loglama stack’i genelde daha iyi bir çözümdür.

Paylaşılması Gerekmeyen (Hatta Paylaşılmaması Gereken) Dosyalar

• Uygulama kodu: Kodun NFS gibi bir paylaşımlı diskte çalışması yerine, her sunucuya CI/CD ile deploy edilmesi daha güvenilir ve performanslıdır.
• Geçici dosyalar ve local cache: PHP opcache, local HTTP cache, derlenmiş varlıklar (assets) gibi dosyalar her sunucuda ayrı tutulabilir.
• Veritabanı dosyaları: MySQL/PostgreSQL data dizinini NFS gibi bir ağ dosya sistemine koymak genelde kötü fikirdir; bunun yerine klasik replikasyon ya da özel çözümler tercih edilmelidir.

Depolama türleri arasındaki farkları daha geniş perspektiften görmek için Object Storage vs Block Storage vs File Storage yazımızda dosya sistemlerinin güçlü ve zayıf yanlarını detaylı olarak anlattık.

İki Temel Yaklaşım: Paylaşımlı Depolama vs Senkronizasyon

• Paylaşımlı depolama (NFS, SSHFS): Tek bir merkezi depolama alanı vardır, tüm web sunucuları bu alanı sanki local diskmiş gibi mount eder. Uygulama açısından tek disk varmış gibi görünür.
• Senkronizasyon (rsync, deploy pipeline’ları): Her sunucunun kendi diski vardır; dosyalar belirli aralıklarla veya event tabanlı olarak birbirine kopyalanır.

Gerçek dünyada çoğu mimari bu iki yaklaşımı karıştırır: Örneğin uploads klasörü için paylaşımlı depolama, kod için rsync tabanlı CI/CD gibi. Şimdi NFS, SSHFS ve rsync’i bu çerçevede tek tek ele alalım.

NFS: Klasik Paylaşımlı Dosya Sistemi

NFS (Network File System), onlarca yıldır Unix/Linux dünyasında kullanılan, olgun bir ağ dosya sistemi protokolüdür. NFS depolama nedir? yazımızda temellerini detaylıca anlattık; burada ağırlıklı olarak çoklu web sunucusu bağlamındaki artı ve eksilerine odaklanacağız.

NFS Nasıl Çalışır?

Basitçe anlatırsak:

• Bir sunucu NFS server olarak çalışır; belirli bir klasörü ağ üzerinden paylaşır.
• Web sunucuları bu paylaşımı mount komutu ile kendi dosya sistemlerine bağlar.
• Uygulama, NFS üzerinde olduğunu bilmeden bu klasörü normal bir dizin gibi okur/yazar.

NFS, kernel seviyesinde çalıştığı için genelde SSHFS gibi FUSE tabanlı çözümlerden daha yüksek performans ve daha iyi POSIX uyumu sağlar.

NFS’nin Avantajları

• Gerçek zamanlı paylaşım: Bir sunucuda oluşturulan dosya, anında diğer tüm sunucularda görünür. Upload klasörleri için idealdir.
• POSIX uyumu: Dosya izinleri, owner/grup, lock mekanizmaları büyük oranda klasik bir Linux dosya sistemi gibi çalışır.
• Performans: Doğru yapılandırıldığında, özellikle yerel ağda oldukça yüksek throughput ve nispeten düşük latency sunar.
• Basit entegrasyon: Neredeyse tüm Linux dağıtımlarında NFS istemcisi hazır gelir; ek yazılım gerektirmez.

NFS’nin Dezavantajları ve Riskleri

• Tekil hata noktası (SPOF): Tüm web sunucuları tek bir NFS sunucusuna bağlıysa, o sunucu veya bağlı olduğu depolama giderse, tüm site işlevsel olarak çöker.
• Ağ bağımlılığı: NFS, latency’ye duyarlıdır. Web sunucuları ile NFS sunucusu arasında stabil ve hızlı bir ağ şarttır.
• Güvenlik: Varsayılan NFS ayarları çoğu zaman güvenli değildir. IP tabanlı yetkilendirme, root squash, firewall kuralları çok dikkatli tasarlanmalıdır.
• Bakım zorluğu: Kernel modülleri, versiyon uyumsuzlukları, lock sorunları gibi konular özellikle karmaşık yapılarda baş ağrıtabilir.

NFS Kullanırken Pratik Öneriler

• Yalnızca gerçekten gerekli klasörleri paylaşın: Örneğin /var/www/html/uploads veya storage/app/public. Tüm kodu NFS’den çalıştırmak yerine CI/CD ile dağıtın.
• Mount seçeneklerini optimize edin: noatime, nodiratime, uygun rsize/wsize ve hard,intr gibi parametreler performansı ve dayanıklılığı ciddi etkiler.
• Ağınızı izleyin: NFS sorunlarının çoğu aslında ağ sorunlarıdır. VPS veya dedicated sunucularınızı kurarken ağ gecikmesi ve paket kaybını mutlaka ölçün.
• Yedekliliği planlayın: Kritik ortamlarda tek NFS sunucusu yerine, altta yüksek erişilebilir depolama veya replikasyon kullanan çözümler tercih edilmelidir.

Hangi Senaryoda NFS Mantıklı?

• 2–4 web sunuculu, tek veri merkezi içinde çalışan WordPress/Laravel gibi PHP uygulamaları.
• Yoğun upload alan ama dosya boyutları orta seviyede olan (örneğin 1–50 MB) projeler.
• Mimari sadeliğin, aşırı karmaşık çözümlere göre daha önemli olduğu KOBİ ve ajans projeleri.

Daha büyük ölçeklerde, özellikle çok bölgeli yapılarda, NFS’yi tek başına çözüm olarak kullanmak yerine; çok bölgeli mimari ve replikasyon stratejileri ile birlikte düşünmek gerekir.

SSHFS: Hızlı Montaj, Sınırlı Üretim Kullanımı

SSHFS, FUSE (kullanıcı modunda dosya sistemi) tabanlı bir çözümdür ve dosyaları SSH üzerinden mount eder. Yani, SSH ile bir sunucuya nasıl bağlanıyorsanız, SSHFS de aynı protokolü kullanarak o sunucudaki bir klasörü kendi sisteminize disk gibi gösterir.

SSHFS’nin Avantajları

• Kolay kurulum: Eğer SSH bağlantınız varsa, çoğu durumda ekstra bir port açmadan SSHFS ile disk mount edebilirsiniz.
• Şifreli iletişim: Tüm trafik SSH üzerinden geçtiği için veri iletimi doğal olarak şifrelenir.
• Esneklik: Geçici işler, debug, log inceleme, hızlı dosya kopyalama gibi durumlarda çok pratik bir araçtır.

SSHFS’nin Dezavantajları

• Performans sınırlamaları: FUSE ve SSH katmanları nedeniyle latency ve CPU kullanımı NFS’ye göre daha yüksektir. Yüksek trafiğe maruz kalan bir web site dosya sistemi için ideal değildir.
• Stabilite sorunları: Ağ dalgalanmalarında mount’un kilitlenmesi, zaman aşımı, process’lerin asılı kalması gibi problemler yaşanabilir.
• Üretim ortamı için önerilmez: Özellikle yüksek concurrency, çok sayıda küçük dosya ve yoğun I/O olan web projelerinde, SSHFS’yi kalıcı bir paylaşımlı depolama çözümü olarak konumlandırmak risklidir.

SSHFS’yi Nerede Kullanmak Mantıklı?

• Geliştirme veya bakım sırasında, kısa süreli dosya erişim ihtiyaçları.
• Prod ortam loglarını local makinenize sanki diskmiş gibi çekip incelemek.
• Küçük iç araçlar veya yönetim script’leri için, düşük trafikli senaryolar.

DCHost tarafında biz SSHFS’yi genellikle operasyonel bir araç olarak görüyoruz; kalıcı paylaşımlı depolama çözümü olarak değil. Çok sunuculu web mimarisinde NFS veya rsync gibi yöntemlerle karşılaştırıldığında, SSHFS nadiren birincil tercih oluyor.

rsync: Senkronizasyon, Deploy ve Dağıtık Dosya Yönetimi

rsync, ağ üzerinden iki dosya ağacını verimli şekilde eşitlemek için kullanılan, neredeyse her Linux sistemde hazır gelen bir araçtır. Farkı, her seferinde tüm dosyaları kopyalamak yerine sadece değişen blokları aktarmasıdır.

rsync Nasıl Çalışır ve Neden Seviliyor?

• Kaynak ve hedef klasörü tarar; eksik veya değişmiş dosyaları tespit eder.
• Varsayılan olarak sadece farkları (delta) gönderek bant genişliğini korur.
• SSH üzerinden çalışabildiği için ekstra port açmaya gerek kalmaz.

rsync’i paylaşımlı bir dosya sistemi gibi düşünmemek gerekir; anlık senkronizasyon yapar, güncel halin canlı paylaşımını yapmaz. Bu ayrım kritik.

rsync’in Avantajları

• Basit ve olgun: Uzun yıllardır üretim ortamlarında kullanılan, çok güvenilir bir araç.
• Verimli: Sadece değişen blokları gönderdiği için, özellikle deploy ve yedekleme senaryolarında ciddi bant genişliği tasarrufu sağlar.
• Tek yönlü veya çift yönlü senkronizasyon: Genelde tek yön (master → slave) kullanılır; ama istenirse farklı topolojiler de kurulabilir.
• CI/CD entegrasyonu: GitHub Actions, GitLab CI veya benzeri sistemlerle birlikte kullanıldığında, sıfıra yakın kesintili deploy senaryolarında mükemmel çalışır.

rsync’i CI/CD süreçlerinde nasıl kullandığımıza dair daha uygulamalı bir örneği, rsync ile sıfır kesinti CI/CD rehberimizde adım adım anlattık.

rsync’in Dezavantajları

• Gerçek zamanlı değil: rsync bir kere çalışır, senkronize eder ve biter. 5 dakika aralıklarla cron’a koyarsanız, bu 5 dakika boyunca sunucular arasında fark oluşabilir.
• Çakışan yazımlar: Aynı dosyaya aynı anda iki sunucuda yazılırsa, son rsync kazanan olur ve veri kaybı yaşayabilirsiniz. Bu yüzden genelde tek yazan (master) düğüm modeli kullanılır.
• İzleme ve hata yönetimi: Cron ile çalışan rsync görevleri başarısız olduğunda, bunu fark edecek bir monitoring kurulu değilse, sunucular zaman içinde sessizce birbirinden kopabilir.

rsync Kullanım Senaryoları

• Kod dağıtımı: CI/CD pipeline’ınız build alınmış kodu önce staging’e, sonra production sunuculara rsync ile dağıtabilir.
• Okuma ağırlıklı paylaşımlar: Tek bir “prime” sunucuda oluşan dosyaları, diğer sadece-okuma (read-only) web sunucularına dağıtmak.
• Yedekleme: Web sunucularınızı merkezi bir yedek sunucusuna rsync ile senkronize etmek.

rsync’i doğru kullanmak için mantıklı bir master/slave modeli, sağlam bir cron ve log takibi, mümkünse alarm üreten bir izleme sistemi kurmak şart.

NFS vs SSHFS vs rsync: Kısa Karşılaştırma Tablosu

Güvenlik ve Performans Perspektifinden Değerlendirme

Birden fazla web sunucusu arasında dosya paylaşımı sadece mimari bir konu değil; aynı zamanda güvenlik ve performans açısından da kritik. DCHost’ta yeni bir çok sunuculu kurulum yaparken, bu üç başlığa mutlaka bakıyoruz.

Güvenlik İpuçları

• En az yetki prensibi: NFS exports, rsync kullanıcıları ve SSH anahtarları sadece gerekli dizinlere ve operasyonlara yetkili olmalı.
• Şifreli iletişim: NFS genelde şifrelenmemiştir; bu yüzden NFS trafiğini güvenilir, izole bir ağda tutmak gerekir. rsync ve SSHFS ise SSH üzerinden çalıştığı için trafiği otomatik şifreler.
• Firewall ve ağ segmentasyonu: Birden çok VPS veya dedicated sunucu kullanıyorsanız, aradaki trafiği sadece gereken portlara ve IP’lere açan bir güvenlik duvarı tasarlamak şart. Bu konuda VPS güvenlik sertleştirme kontrol listesi yazımızdan da yararlanabilirsiniz.
• Loglama: Hangi kullanıcı ne zaman senkronizasyon başlattı, hangi mount ne zaman koptu gibi bilgileri merkezi log sisteminize aktarmak, sorun anında hayat kurtarır.

Performans İpuçları

• Ağ topolojisine dikkat: Web sunucuları ile NFS/rsync sunucusu mümkün olduğunca aynı veri merkezinde ve düşük latency’li bir ağ üzerinde olmalı.
• CDN ve Object Storage ile yükü azaltın: Kullanıcıya giden statik dosyaları doğrudan web sunucusundan değil, CDN ve Object Storage üzerinden sunmak, paylaşımlı dosya sistemine binen yükü dramatik biçimde azaltır. Bunun için Object Storage ile medya offload stratejisi yazımız iyi bir başlangıç noktası.
• Cache katmanları: Uygulama tarafında doğru HTTP cache, opcache ve object cache kullanımı, dosya sistemi üzerindeki gereksiz I/O’yu ciddi biçimde düşürür.
• Büyük dosyaları bölün: Çok büyük video veya yedek dosyalarının tek parça halinde NFS veya rsync ile taşınması, ağ ve disk üzerinde spike’lar yaratabilir. Parçalı upload ve arka plan iş süreçleri kurmak daha sağlıklıdır.

Pratik Senaryolar: Hangi Desen Ne Zaman Doğru?

Senaryo 1: 2 Web Sunuculu WordPress + Nginx Load Balancer

Örnek bir mimari düşünelim:

• Önde bir Nginx reverse proxy, arkasında iki WordPress web sunucusu.
• Her iki sunucu da aynı domain altında çalışıyor, yük round-robin dağıtılıyor.

Bu mimariye benzer bir kurguyu Nginx reverse proxy ve basit load balancer rehberimizde uygulamalı olarak anlattık. Dosya paylaşımı için tipik çözüm deseni şöyle olabilir:

• Uploads için NFS: wp-content/uploads klasörü NFS’de tutulur; her iki web sunucusu bu share’i mount eder.
• Kod için rsync: WordPress çekirdeği ve temalar için CI/CD pipeline’ınız kodu aynı anda iki web sunucusuna rsync ile dağıtır.
• Cache ve session’lar: Redis kullanarak, dosya sistemi üzerindeki yük azaltılır.

Senaryo 2: Laravel Uygulaması, Arka Plan İşçiler ve Çoklu VPS

Bir diğer yaygın örnek; bir VPS üzerinde Laravel API, diğerinde ise queue worker’lar çalışıyor olsun. Kullanıcı yüklemeleri API üzerinden geliyor, worker ise bu dosyaları işliyor (örneğin PDF oluşturuyor).

• storage/app/public gibi paylaşılan bir klasör NFS’ye taşınır.
• Hem API sunucusu hem queue sunucusu bu NFS share’ini aynı noktaya mount eder.
• Kod dağıtımı yine rsync veya container imajları ile yapılır.

Böylece API’ye hangi VPS cevap verirse versin, yüklenen dosya işi yapacak queue worker’ın da erişiminde olur.

Senaryo 3: Okuma Ağırlıklı Dosya Arşivi

Bazı projelerde dosyalar sadece belirli bir yerde üretilir ama yüzlerce web sunucusu bu dosyaları sadece okur (örneğin rapor çıktıları, statik dokümanlar). Burada:

• “Master” sunucu dosyaları üretir ve rsync ile “read-only” web sunucularına dağıtır.
• Web sunucularında bu klasör kullanıcıya sadece okunur (ro) olarak sunulur.
• NFS’ye göre daha basit ve çoğu zaman daha hızlıdır; çünkü normal çalışma anında paylaşılan bir dosya sistemi yoktur.

Senaryo 4: Geleceğe Hazırlık – Object Storage ve CDN

Uzun vadede büyük projelerde uploads klasörünü bile NFS veya rsync yerine Object Storage’a taşımak çoğu zaman daha mantıklı hale gelir. Medya dosyalarını bir S3 uyumlu depolama alanına aktarıp, CDN üzerinden sunmak hem I/O baskısını hem de ölçeklenme derdini ciddi biçimde azaltır. Bu dönüşümü planlarken, yukarıda bahsettiğimiz Object Storage ile medya offload stratejisi rehberinden yararlanabilirsiniz.

DCHost Altyapısında Doğru Seçimi Yapmak

NFS, SSHFS ve rsync’i tek tek incelediğimizde netleşen şey şu: Mesele sadece “hangi aracı kullanayım?” sorusu değil; aynı zamanda “mimariyi nasıl kurayım?” sorusu. Doğru yanıt genelde şöyle bir kombinasyon oluyor:

• SSHFS: Operasyonel ve geçici işler için; üretim trafiğini taşımak için değil.
• rsync: Kod dağıtımı, yedekleme ve tek-yazan / çok-okuyan senaryolarda güçlü bir yardımcı.
• NFS: Gerçek zamanlı paylaşıma ihtiyaç duyulan uploads, public storage gibi klasörler için, dikkatli tasarlanmış bir ağ ve depolama ile.

DCHost’ta ister paylaşımlı hosting, ister NVMe tabanlı VPS, ister dedicated sunucu veya colocation kullanın; çok sunuculu mimarilerde bu üç aracı nasıl bir araya getireceğinizi en başta doğru planlamak hem performansı hem de işletme maliyetini doğrudan etkiliyor. Bir sonraki adımda yapmanız gereken, mevcut veya planladığınız projeyi masaya yatırıp şu soruları sormak:

• Hangi klasörler gerçekten paylaşılmak zorunda?
• Hangi dosyalar Object Storage/CDN’e taşınabilir?
• Hangi noktada NFS, hangi noktada rsync daha mantıklı?

Eğer bu soruların yanıtını mimarinize özel olarak netleştirmek istiyorsanız, DCHost ekibiyle birlikte VPS, dedicated sunucu veya colocation altyapınızı bu dosya paylaşım stratejilerine uygun biçimde tasarlayabiliriz. Böylece çok sunuculu yapıya geçtiğinizde “dosyalar nerede?” sorusu değil, işinizin büyümesi gündeminizde olur.