Çoklu Web Sunucu Mimarisinde Merkezi Dosya Yönetimi: NFSv4

Kurumsal SaaS ve yüksek trafikli web uygulamalarında yatay ölçekleme (Horizontal Scaling) yaparken karşılaşılan en kritik darboğazlardan biri, kullanıcıların yüklediği dosyaların tüm web sunucularından aynı anda, tutarlı ve yüksek performansla erişilebilir olmasını sağlamaktır. Bu yazıda, HYZSOFT olarak çoklu web sunucu (Multi-Web Server) mimarimizde dosya depolama katmanını FTP, SFTP, Symlink/SSHFS ve NFSv4 alternatifleri arasında nasıl değerlendirdiğimizi, karşılaştığımız gerçek üretim ortamı sürprizlerini (Systemd Mount Namespace izolasyonu gibi) ve farklı ağlardaki sunucular arasında id_rsa ile kurduğumuz güvenli mimariyi tüm teknik detaylarıyla paylaşıyoruz.

1. Çoklu Web-Server Mimarisinde Dosyaların Merkezi Sunucuda Tutulma Zorunluluğu

Tek bir web sunucusu (Monolitik / Single-Node) üzerinde çalışan uygulamalarda dosya yükleme işlemi oldukça basittir: Kullanıcının yüklediği bir PDF sözleşme, fatura görseli veya profil fotoğrafı doğrudan o sunucunun yerel diskindeki (örneğin /var/www/vhosts/ornek-uygulama.com/httpdocs/files) dizinine kaydedilir ve yine aynı diskten sunulur.

Ancak uygulama büyüyüp artan trafiği karşılamak ve yüksek erişilebilirlik (High Availability) sağlamak amacıyla bir Yük Dengeleyici (Load Balancer) arkasına birden fazla web sunucusu (Web Server 1, Web Server 2, Web Server N) eklendiğinde, yerel disk kullanımı ciddi bir mimari krize dönüşür.

Yerel Disk Kullanımında Yaşanan “Durum (State)” Problemi

• Senkronizasyon Kaybı (404 Not Found Hatası): Kullanıcı sisteme giriş yaptığında Load Balancer isteği Web Server 1‘e yönlendirir. Kullanıcı bir dosya yüklediğinde dosya Web Server 1‘in yerel diskine yazılır. Birkaç saniye sonra aynı kullanıcı (veya ekipteki başka bir kullanıcı) dosyayı görüntülemek istediğinde Load Balancer bu yeni isteği Web Server 2‘ye gönderir. Dosya Web Server 2‘nin yerel diskinde bulunmadığı için sistem 404 Not Found hatası döndürür.
• Çift Yönlü Senkronizasyon (Rsync / Unison) Karmaşası: Sunucular arasında periyodik rsync çalıştırmak; anlık yüklenen dosyaların gecikmeli görünmesine, dosya silme/güncelleme işlemlerinde çakışmalara (conflict) ve disk alanının her sunucuda gereksiz yere kopyalanarak (N katı maliyet) tüketilmesine yol açar.
• Yatay Ölçekleme (Auto-Scaling) Engeli: Sisteme yeni bir Web Server 3 dahil edilmek istendiğinde, terabaytlarca verinin yeni sunucuya kopyalanmasını beklemek anlık ölçeklenebilirliği imkansız hale getirir.

Çözüm: “Stateless” (Durumsuz) Web Sunucuları ve Merkezi Depolama (Single Source of Truth)

Modern bulut ve kurumsal yazılım mimarisinin altın kuralı şudur: Web sunucuları tamamen “Stateless” (durumsuz) olmalı; üzerinde yalnızca uygulama kodlarını çalıştırmalıdır. Durum barındıran veriler (veritabanı, önbellek ve kullanıcı dosyaları) ise bağımsız ve merkezi katmanlarda tutulmalıdır.

Dosyalar merkezi bir dosya sunucusunda (Storage Server) toplandığında:

1. Hangi web sunucusu dosyayı yazarsa yazsın, diğer tüm web sunucuları aynı milisaniyede o dosyayı okuyabilir.
2. Yedekleme (Backup), disk genişletme, virüs taraması ve erişim yetkilendirme işlemleri N farklı sunucu yerine tek bir merkezde yönetilir.
3. Herhangi bir web sunucusu arızalandığında veya yenisi eklendiğinde veri kaybı yaşanmaz; yeni sunucu yalnızca merkezi dosya dizinini bağlayarak (mount ederek) saniyeler içinde kümeye (cluster) katılır.

2. Merkezi Sunucuya Dosya Atma ve Erişim Yöntemleri: FTP/SFTP, Symlink ve NFSv4 Karşılaştırması

Dosyaları merkezi bir sunucuda tutmaya karar verdiğinizde karşınıza üç temel mimari yaklaşım çıkar. Projemizde doğru kararı verebilmek için bu üç yöntemi performans, uygulama kodu bağımlılığı, bakım maliyeti ve işletim sistemi davranışı açısından detaylıca karşılaştırdık.

Yöntem A: Uygulama Katmanında FTP / SFTP Kullanımı

Bu yöntemde web sunucuları ile merkezi dosya sunucusu arasında işletim sistemi seviyesinde bir disk bağlantısı yoktur. Uygulama kodu (örneğin PHP), her dosya yükleme, okuma, boyut kontrolü veya silme işleminde bir FTP/SFTP kütüphanesi (ext-ftp, phpseclib veya Flysystem) kullanarak uzak sunucuya ağ üzerinden bağlanır.

• Dezavantaj 1 (Yüksek Gecikme / Handshake Maliyeti): Her HTTP isteğinde TCP ve SSH/TLS el sıkışması (handshake) yapmak ciddi bir gecikme (latency) yaratır. Bir sayfada 20 adet dosya listeleniyorsa veya küçük resimler (thumbnail) kontrol ediliyorsa uygulama hissedilir derecede yavaşlar.
• Dezavantaj 2 (Standart Fonksiyonların Devre Dışı Kalması): Uygulama kodunda kullanılan standart is_file(), is_dir(), filesize(), move_uploaded_file(), unlink() veya görsel işleme kütüphaneleri (GD / ImageMagick) doğrudan uzak sunucudaki dosya yolu üzerinde çalışamaz. Dosyayı önce yerel geçici (/tmp) dizine indirmek, işlemek ve tekrar SFTP ile göndermek gerekir.
• Dezavantaj 3 (Kod Refactoring Maliyeti): Mevcut bir projede dosya yükleyen onlarca modül varsa, tamamının kodunu SFTP API’lerine göre baştan yazmak gerekir.

Yöntem B: Uzak Dizini Bağlayıp Sembolik Link (Symlink + SSHFS/FUSE) Kullanmak

Bu yaklaşımda merkezi sunucudaki dizin, web sunucusu üzerinde /mnt/uzak_depolama gibi harici bir noktaya (genellikle FUSE tabanlı sshfs ile) bağlanır. Ardından web uygulamasının içindeki dizinden buraya bir sembolik link (ln -s /mnt/uzak_depolama /var/www/.../httpdocs/files) oluşturulur.

• Dezavantaj 1 (Web Sunucusu ve Güvenlik Kısıtlamaları): Nginx, Apache, Plesk ve cPanel gibi ortamlar güvenlik nedeniyle (SymLinksIfOwnerMatch, disable_symlinks veya PHP open_basedir kısıtlamaları) doküman kök dizini (httpdocs) dışına çıkan sembolik linkleri engelleme eğilimindedir. Kullanıcı izinleri (UID/GID) eşleşmediğinde 403 Forbidden hataları sıkça yaşanır.
• Dezavantaj 2 (FUSE / Kullanıcı Alanı Darboğazı): Bağlantı sshfs ile yapıldığında her dosya okuma/yazma çağrısı Linux çekirdeğinden (Kernel Space) kullanıcı alanındaki (User Space) FUSE katmanına, oradan şifrelenerek SSH sürecine geçer. Eşzamanlı yüksek I/O altında CPU tüketimi artar ve bağlantı koptuğunda Transport endpoint is not connected hatasıyla sembolik link “kırık (broken)” duruma düşer.
• Dezavantaj 3 (Realpath Sapmaları): Uygulama içinde realpath() kullanan güvenlik kontrolleri, sembolik linkin gerçek hedefi olan /mnt/... yolunu döndürdüğü için uygulama içi yol doğrulama (path validation) kontrollerini bozabilir.

Yöntem C: Doğrudan Hedef Dizine NFSv4 Mount (Tercih Ettiğimiz Mimari)

Network File System v4 (NFSv4) ile merkezi sunucudaki paylaşım alanı, sembolik link kullanmadan doğrudan uygulamanın dosya dizinine (/var/www/vhosts/ornek-uygulama.com/httpdocs/files) Linux çekirdeği (Kernel VFS) seviyesinde bağlanır.

• Sıfır Kod Değişikliği (100% Şeffaflık): PHP, Nginx ve Apache için bu dizin yerel bir diskten farksızdır. Tüm standart dosya fonksiyonları (move_uploaded_file, scandir, filesize) tek satır kod değiştirmeden çalışır.
• Kernel-Space Performansı ve Önbellekleme: NFSv4 doğrudan Linux çekirdeğinde çalışır, agresif sayfa önbelleklemesi (Page Cache) ve async yazma yetenekleriyle yerel diske en yakın performansı sunar.
• Güvenlik Duvarı Dostu: Eski NFSv3 sürümlerinin aksine rpcbind veya rastgele portlar gerektirmez; yalnızca tek bir standart port (TCP 2049) üzerinden durum bilgili (stateful) olarak çalışır.

Karşılaştırma Özeti Tablosu

3. NFSv4 Mimarisini Nasıl Uyguladık? (Adım Adım Kurulum ve Üretim Ortamı Çözümleri)

Mimariyi kurgularken tüm sunucularımızın aynı özel ağ (Private LAN) içinde en az ayrıcalık (Least Privilege) prensibiyle konuşmasını sağladık. Aşağıda, gerçek üretim ortamımızda uyguladığımız yapılandırmayı anonimleştirilmiş sunucu ve erişim bilgileriyle adım adım inceleyebilirsiniz.

Altyapı ve Sunucu Envanteri (Anonimleştirilmiş)

• Merkezi Dosya Sunucusu (NFSv4 Server):
  • Özel Ağ (LAN) IP Adresi: 10.0.10.50
  • Fiziksel Depolama Dizini: /data/storage/shared_files
  • NFSv4 Sanal Kök (Pseudo-Root) Dizini: /srv/nfs4/shared_files
  • Dosya Sahibi Kullanıcı / Grup (UID:GID): webuser:psacln (10001:1005)
• Web Uygulama Sunucuları (NFSv4 Clients):
  • Web Server 1 IP: 10.0.10.11
  • Web Server 2 IP: 10.0.10.12
  • Uygulama Hedef Bağlama (Mount) Noktası: /var/www/vhosts/ornek-uygulama.com/httpdocs/files

Adım 1: Merkezi Sunucuda (10.0.10.50) NFSv4 Pseudo-Root ve İzinlerin Hazırlanması

NFSv4, güvenlik amacıyla sunucunun tüm dosya sistemi ağacını dışarıya açmak yerine fsid=0 ile işaretlenmiş sanal bir kök dizin (Pseudo-Root) kullanır. Fiziksel veri dizinimizi bu sanal kök içine bind mount ile bağladık:

# 1. NFS sunucu paketlerinin kurulumu (Ubuntu/Debian)
sudo apt update && sudo apt install -y nfs-kernel-server

# 2. Fiziksel depolama ve NFSv4 sanal kök dizinlerinin oluşturulması
sudo mkdir -p /data/storage/shared_files
sudo mkdir -p /srv/nfs4/shared_files

# 3. Sahiplik (UID: 10001, GID: 1005) ve dizin izinlerinin atanması
sudo chown -R 10001:1005 /data/storage/shared_files
sudo chmod -R 2775 /data/storage/shared_files

# 4. Fiziksel dizinin NFSv4 sanal köküne bind mount edilmesi
sudo mount --bind /data/storage/shared_files /srv/nfs4/shared_files

Sunucu yeniden başladığında bind mount işleminin kalıcı olması için merkezi sunucunun /etc/fstab dosyasına şu satırı ekledik:

/data/storage/shared_files   /srv/nfs4/shared_files   none   bind   0   0

Adım 2: UID/GID Eşitlemesi (all_squash) ve /etc/exports Yapılandırması

Çoklu web sunucusu ortamında en sık karşılaşılan sorun, farklı web sunucularındaki PHP-FPM kullanıcılarının farklı UID/GID değerlerine sahip olabilmesidir. Bunu kökünden çözmek için merkezi sunucuda all_squash, anonuid=10001 ve anongid=1005 parametrelerini kullandık. Böylece hangi web sunucusundan hangi kullanıcı dosya yazarsa yazsın, merkezi disk üzerinde otomatik olarak 10001:1005 (webuser:psacln) sahipliğiyle kaydedilir.

Merkezi sunucudaki /etc/exports dosyamız:

# /etc/exports - Sadece yetkili Web Sunucularına (10.0.10.11 ve 10.0.10.12) açık
/srv/nfs4                10.0.10.11(rw,sync,fsid=0,crossmnt,no_subtree_check,all_squash,anonuid=10001,anongid=1005) \
                         10.0.10.12(rw,sync,fsid=0,crossmnt,no_subtree_check,all_squash,anonuid=10001,anongid=1005)

/srv/nfs4/shared_files   10.0.10.11(rw,async,no_subtree_check,all_squash,anonuid=10001,anongid=1005) \
                         10.0.10.12(rw,async,no_subtree_check,all_squash,anonuid=10001,anongid=1005)

Ve güvenlik duvarında (UFW / Firewall) yalnızca Web Sunucularının IP adreslerinden gelen TCP 2049 portuna izin verdik:

sudo exportfs -ra
sudo ufw allow from 10.0.10.11 to any port 2049 proto tcp
sudo ufw allow from 10.0.10.12 to any port 2049 proto tcp

Adım 3: Paylaşılan Dizinde Zararlı Betik Çalıştırmayı Engelleme (.htaccess Güvenliği)

Kullanıcıların dosya yüklediği dizin doğrudan httpdocs/files altında yer aldığı için, olası bir güvenlik açığında saldırganın .php veya .phtml uzantılı bir kabuk betiği (web shell) yükleyip çalıştırmasını engellemek kritik önem taşır. Merkezi sunucudaki ana dizine (veya uygulama katmanına) betik motorlarını kapatan .htaccess kurallarımızı yerleştirdik:

# /data/storage/shared_files/.htaccess
<IfModule mod_php.c>
    php_flag engine off
</IfModule>
<IfModule mod_php7.c>
    php_flag engine off
</IfModule>
<IfModule mod_php8.c>
    php_flag engine off
</IfModule>

<FilesMatch "\.(php|phtml|php3|php4|php5|php7|php8|phps|phar|pl|py|cgi|sh)$">
    Require all denied
</FilesMatch>
Options -ExecCGI -Indexes

Adım 4: Web Sunucularında (10.0.10.11 & 10.0.10.12) Bağlantı ve “Hayalet Dosya” Sürprizi!

Web sunucularında nfs-common paketini kurup paylaşımı bağladığımızda her şeyin bittiğini düşünmüştük. Ancak üretim ortamında çok ilginç bir teknik sürprizle karşılaştık:

Karşılaştığımız Sürpriz (Systemd Mount Namespace İzolasyonu):
Terminalden (SSH) baktığımızda df -h çıktısında NFSv4 bağlantısı sorunsuz görünüyordu. Ancak web uygulaması üzerinden bir dosya yüklendiğinde, dosya merkezi sunucuya gitmiyor; sanki NFS bağlantısı hiç yokmuş gibi web sunucusunun yerel diskine yazılıyordu! Üstelik terminalden ls -la yaptığımızda bu dosyayı göremiyorduk, fakat web üzerinden dosya açılıyordu!

Kök Neden: Modern Linux dağıtımlarında ve Plesk/cPanel gibi panellerde çalışan php-fpm ve apache2 servisleri, güvenlik amacıyla systemd birim dosyalarında PrivateTmp=true parametresiyle başlar. Bu parametre, servis başlatıldığı anda mevcut disk bağlama tablosunun (Mount Table) izole bir kopyasını (Mount Namespace) oluşturur. Eğer siz NFSv4 paylaşımını php-fpm servisi çalışırken sonradan manuel olarak mount ederseniz, ana işletim sistemi NFS’i görürken php-fpm kendi izole uzayında eski yerel klasöre yazmaya devam eder!

Kesin Çözüm: Web sunucularındaki /etc/fstab dosyasına systemd başlatma sıralaması bağımlılıklarını (x-systemd.before) ekledik. Böylece sunucu açılırken önce NFSv4 bağlantısı kuruluyor, ardından PHP-FPM ve Web Sunucusu servisleri başlatılıyor:

# Web Sunucuları (10.0.10.11 ve 10.0.10.12) /etc/fstab yapılandırması:
10.0.10.50:/shared_files   /var/www/vhosts/ornek-uygulama.com/httpdocs/files   nfs4   rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.automount,x-systemd.before=plesk-php82-fpm.service,x-systemd.before=apache2.service,x-systemd.before=nginx.service   0   0

Manuel mount işlemi sonrasında da ilgili servisleri yeniden başlatarak tüm süreçlerin aynı Mount Namespace’i görmesini garanti altına aldık:

sudo systemctl daemon-reload
sudo mount -a
sudo systemctl restart plesk-php82-fpm apache2 nginx

4. Farklı Network’teki Sunucularda id_rsa (SSH Key) ile Güvenli Erişim

Aynı veri merkezi veya özel VLAN içindeki sunucularda (10.0.10.x) doğrudan NFSv4 mükemmel çalışır. Ancak projeler büyüdükçe; farklı bir veri merkezinde (farklı bir bulut sağlayıcıda veya farklı bir coğrafi bölgede) bulunan bir uygulama sunucusunun, raporlama sunucusunun veya felaket kurtarma (Disaster Recovery) sunucusunun da merkezi dosya sunucusuna erişmesi gerekebilir.

Önemli Güvenlik Kuralı: NFSv4 trafiği varsayılan olarak şifrelenmemiş (unencrypted) olduğu için, 2049 portunu doğrudan genel internete (WAN) açmak güvenlik açısından kesinlikle önerilmez. Farklı network’teki sunucular arasında güvenli dosya erişimi ve senkronizasyonu için asimetrik kriptografi tabanlı SSH Anahtar Çifti (id_rsa / id_rsa.pub) mimarisini devreye aldık.

Senaryo ve Anonim Sunucu Bilgileri

• Farklı Ağdaki (Dış Veri Merkezi) Web Sunucusu: 198.51.100.10
• Merkezi Depolama Sunucusu (Dış IP): 203.0.113.50 (SSH Port: 22)
• Erişim Kullanıcısı: storage_sync (UID: 10001, GID: 1005 – merkezi dosyalarla aynı sahiplikte)

Adım 1: İstemci Sunucuda (198.51.100.10) Parolasız RSA Anahtar Çifti Üretimi

Arka plan servislerinin ve otomatik bağlama (fstab / cron) araçlarının insan müdahalesi olmadan bağlanabilmesi için 4096-bit uzunluğunda, parolasız (passphrase olmadan) bir id_rsa anahtar çifti oluşturduk:

# İstemci sunucuda (198.51.100.10) çalıştırılır:
ssh-keygen -t rsa -b 4096 -C "web-node-wan@198.51.100.10" -f ~/.ssh/id_rsa -N ""

# Özel anahtarın (Private Key) izinleri mutlaka sadece sahibi tarafından okunabilir (600) olmalıdır:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Adım 2: Merkezi Sunucuda (203.0.113.50) IP Kısıtlamalı authorized_keys Tanımlaması

Oluşturulan açık anahtarı (id_rsa.pub) merkezi sunucudaki /home/storage_sync/.ssh/authorized_keys dosyasına eklerken standart bir kopyalama yapmak yerine, SSH Key Hardening (Anahtar Sıkılaştırma) uyguladık. Anahtarın başına from="198.51.100.10" kısıtlaması ekleyerek, bu özel anahtar bir şekilde sızdırılsa bile 198.51.100.10 IP’si dışındaki hiçbir makineden çalışmamasını sağladık:

# Merkezi sunucuda (203.0.113.50) /home/storage_sync/.ssh/authorized_keys içeriği:
from="198.51.100.10",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7... web-node-wan@198.51.100.10

Adım 3: Farklı Network Üzerinden id_rsa ile 3 Farklı Kullanım Yöntemi

SSH anahtar altyapısı hazırlandıktan sonra, farklı ağdaki sunucunun ihtiyacına göre üç farklı bağlantı modeli uygulanabilir:

1. SSHFS ile Doğrudan Şifreli Dizine Bağlama (Kalıcı /etc/fstab Yapılandırması)

Farklı veri merkezindeki bir uygulama sunucusunun merkezi dosyaları doğrudan bir klasör gibi görmesi gerektiğinde, tüm trafiği SSH (id_rsa) üzerinden şifreleyen sshfs bağlantı satırı:

# /etc/fstab (198.51.100.10 üzerinde)
storage_sync@203.0.113.50:/data/storage/shared_files   /var/www/vhosts/ornek-uygulama.com/httpdocs/files   fuse.sshfs   _netdev,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,IdentityFile=/root/.ssh/id_rsa,allow_other,default_permissions,uid=10001,gid=1005   0   0

Buradaki reconnect ve ServerAliveInterval=15 parametreleri, iki veri merkezi arasındaki internet hattında anlık bir dalgalanma olsa dahi bağlantının kopmadan kendi kendini otomatik onarmasını sağlar.

2. Rsync + id_rsa ile Felaket Kurtarma (Disaster Recovery) ve Yedekleme

Merkezi dosya sunucusundaki terabaytlarca verinin farklı bir ağdaki yedek sunucuya sadece değişen blokları (delta-transfer) şifreli olarak aktarması için kullanılan komut:

rsync -avz --delete -e "ssh -i /root/.ssh/id_rsa -o StrictHostKeyChecking=accept-new" \
    storage_sync@203.0.113.50:/data/storage/shared_files/ \
    /backup/shared_files_mirror/

3. WireGuard / IPsec VPN veya SSH Tüneli Üzerinden NFSv4

Eğer farklı network’teki sunucuda da FUSE yerine yerel çekirdek (Kernel NFSv4) performansı isteniyorsa, iki sunucu arasında id_rsa veya açık/özel anahtar tabanlı bir WireGuard VPN tüneli kurulur. Tünel uçlarına sanal özel IP’ler (örneğin 10.99.0.1 ve 10.99.0.2) atanır ve 3. bölümde anlattığımız NFSv4 yapısı hiçbir değişiklik yapılmadan bu şifreli tünel üzerinden çalıştırılır.

Sonuç ve Kazanımlarımız

HYZSOFT olarak çoklu web sunucu mimarimizde merkezi dosya yönetimini NFSv4 ve SSH (id_rsa) tabanlı hibrit bir yapıyla standartlaştırdığımızda elde ettiğimiz temel kazanımlar şunlar oldu:

• Sıfır Kod Karmaşası: Geliştirici ekibimiz FTP/SFTP kütüphaneleriyle uğraşmak yerine standart dosya sistemi fonksiyonlarını kullanmaya devam etti; mevcut modüllerde geriye dönük uyumsuzluk yaşanmadı.
• Kesintisiz Yatay Ölçekleme: Artan yük altında kümemize yeni bir web sunucusu eklemek sadece /etc/fstab dosyasına tek bir satır ekleyip servisi başlatmak kadar kolaylaştı.
• Yüksek Güvenlik ve İzolasyon: all_squash ile sunucular arası izin karmaşası (UID/GID mismatch) tamamen ortadan kalktı, .htaccess kurallarıyla paylaşılan alanda betik çalıştırılması engellendi ve systemd x-systemd.before bağımlılıkları ile “hayalet dosya” (Mount Namespace) problemi kalıcı olarak çözüldü.
• Esnek Çoklu Ağ (Multi-Network) Desteği: Aynı veri merkezinde Kernel seviyesi NFSv4 hızından faydalanırken, farklı ağlardaki sunucularla id_rsa ve IP kısıtlamalı authorized_keys sayesinde şifreli ve güvenli bir köprü kuruldu.