File Server / SMB / WAN Performans Analizi

Lokasyon A (Ofis) ↔ Lokasyon B (Veri Merkezi) — 100 Eşzamanlı Kullanıcı Senaryosu 0. Önce Mimariyi Netleştir (Kritik Ön Adım) SMB, round-trip time (RTT)'ye aşırı duyarlı bir prot...

Lokasyon A (Ofis) ↔ Lokasyon B (Veri Merkezi) — 100 Eşzamanlı Kullanıcı Senaryosu

0. Önce Mimariyi Netleştir (Kritik Ön Adım)

SMB, round-trip time (RTT)'ye aşırı duyarlı bir protokoldür. Disk çok hızlı olsa bile 40-60ms RTT'li bir WAN hattında dosya açma işlemi saniyeler sürebilir çünkü SMB her okuma/yazma işleminde çok sayıda senkron request-response (chatty protocol) üretir.

İlk soru şu olmalı: Kullanıcılar dosya sunucusuna WAN üzerinden mi (Lokasyon A → MPLS/Metro → Lokasyon B) yoksa lokal olarak mı bağlanıyor?

• Eğer 100 kullanıcı Lokasyon A'dan, sunucu Lokasyon B'deyse → SMB WAN latency sorunu %80 ihtimalle kök nedendir.
• SMB versiyonunu doğrula: Get-SmbConnection (client) / Get-SmbServerConfiguration (server) — SMB1 varsa acilen kapat, SMB2/3 zorunlu olmalı.

# Server tarafında SMB versiyon ve ayarları kontrol
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol, EnableMultiChannel
Get-SmbConnection  # Client tarafında hangi dialect kullanılıyor (SMB 2.0.2 / 2.1 / 3.0 / 3.1.1)

1. Eşzamanlı Yük Simülasyonu (Load Testing)

1.1. Disk I/O Katmanı — diskspd (Sunucu Lokalinde)

Amaç: Ağı devre dışı bırakıp saf disk/storage performansını ölçmek (baseline).

# 100 kullanıcının küçük dosya (Office dokümanları) davranışını simüle eden karışık I/O testi
diskspd.exe -c50G -d300 -r -w30 -t8 -o32 -b8K -Sh -L testfile.dat

# Parametre açıklaması:
# -c50G   : 50GB test dosyası
# -d300   : 300 saniye test süresi
# -r      : random I/O (dosya sunucusu davranışına yakın)
# -w30    : %30 yazma, %70 okuma
# -t8     : 8 thread
# -o32    : outstanding I/O (queue depth) = 32
# -b8K    : 8KB blok boyutu (Office dosyaları için tipik)
# -Sh     : cache bypass (gerçekçi disk yükü ölçümü)
# -L      : latency istatistikleri dahil

Farklı senaryolar için ek testler:

# Büyük dosya transferi simülasyonu (CAD, video, backup dosyaları)
diskspd.exe -c20G -d300 -w50 -t4 -o8 -b1M -Sh -L testfile2.dat

# Yüksek eşzamanlılık simülasyonu (100 kullanıcı ~ 8-16 thread x 8 outstanding IO ile temsil edilebilir)
diskspd.exe -c50G -d600 -r -w25 -t16 -o8 -b64K -Sh -L testfile3.dat

1.2. Ağ Bant Genişliği ve Latency — iPerf3

Amaç: MPLS ve Metro İnternet hatlarının gerçek throughput/latency/jitter değerlerini SMB trafiğinden bağımsız ölçmek.

# Veri Merkezinde (Lokasyon B) sunucu modu
iperf3 -s -p 5201

# Ofiste (Lokasyon A) test — TCP throughput
iperf3 -c <DataCenter_IP> -p 5201 -t 60 -P 8
# -P 8 : 8 paralel stream (100 kullanıcının paralel bağlantılarını simüle eder)

# UDP testi ile jitter ve packet loss ölçümü (MPLS hattı için önemli)
iperf3 -c <DataCenter_IP> -u -b 100M -t 60

# MPLS ve Metro İnternet'i ayrı ayrı test etmek için (varsa iki farklı hedef IP/route ile)
iperf3 -c <MPLS_Gateway_IP> -p 5201 -t 60
iperf3 -c <MetroInternet_Gateway_IP> -p 5201 -t 60

RTT ve paket kaybını sürekli izlemek için:

# Sürekli ping ile RTT trendini gözlemle (en az 500-1000 paket)
ping -c 1000 -i 0.2 <DataCenter_IP> > rtt_log.txt

# MTR ile hop-hop latency ve loss (MPLS/Metro karşılaştırması için ideal)
mtr -r -c 200 <DataCenter_IP> > mtr_report.txt

1.3. SMB Protokol Trafiği Simülasyonu

Seçenek A — robocopy ile çoklu paralel dosya operasyonu simülasyonu (Windows, en pratik):

# 8-16 paralel robocopy job'u farklı client makinelerden veya PowerShell job'ları ile başlat
1..16 | ForEach-Object {
    Start-Job -ScriptBlock {
        robocopy \\FileServer\Share$ C:\TestDest /MIR /MT:8 /R:1 /W:1
    }
}

Seçenek B — Locust ile "kullanıcı davranışı" simülasyonu (özel script gerektirir, SMB için doğrudan native destek yoktur; SMB dosya işlemlerini Python smbprotocol kütüphanesiyle sarmalayarak Locust task'ı haline getirebilirsin):

# locustfile.py (kavramsal örnek — SMB açma/kapama/yazma döngüsü)
from locust import User, task, between
import smbclient

class SMBUser(User):
    wait_time = between(1, 3)

    @task
    def open_edit_save(self):
        with smbclient.open_file(r"\\fileserver\share\test.docx", mode="rb") as f:
            data = f.read()
        with smbclient.open_file(r"\\fileserver\share\test_write.docx", mode="wb") as f:
            f.write(data)

Not: Gerçek kullanıcı davranışını (Office lock/unlock, otomatik kayıt, kısmi okuma) tam yansıtmaz; asıl amacı eşzamanlı bağlantı/handle sayısını arttırıp sunucu tarafı SMB session/tree connect limitlerini test etmektir.

Seçenek C — FIO (Linux tabanlı sunucular veya SMB mount üzerinden) — çoklu job ile yüksek eşzamanlılık:

fio --name=smbtest --filename=/mnt/smbshare/testfile --rw=randrw --rwmixread=70 \
    --bs=8k --iodepth=32 --numjobs=16 --runtime=300 --time_based --group_reporting

1.4. Test Metodolojisi Önerisi (Aşamalı Yük Artırımı)

Her aşamada CPU, RAM, Disk Queue, RTT ve SMB latency eş zamanlı loglanmalı (aşağıdaki metrikler).

2. Metrik & Performans Analizi — İzlenecek Değerler ve Eşikler

2.1. Sunucu Tarafı Metrikleri (Windows Server → Performance Monitor / perfmon)

Perfmon komut satırı ile veri toplama:

logman create counter SMBLoadTest -c "\Processor(_Total)\% Processor Time" `
  "\Memory\Available MBytes" `
  "\PhysicalDisk(*)\Avg. Disk Queue Length" `
  "\PhysicalDisk(*)\Avg. Disk sec/Transfer" `
  "\PhysicalDisk(*)\Disk Transfers/sec" `
  "\SMB Server Shares(*)\Current Open File Count" `
  "\SMB Server Shares(*)\Avg. sec/Request" `
  -si 5 -f csv -o C:\Logs\smb_perf.csv
logman start SMBLoadTest
# Test bitince:
logman stop SMBLoadTest

2.2. Ağ Tarafı Metrikleri

MPLS/Metro karşılaştırmalı izleme:

# Her iki hat için ayrı ayrı sürekli izleme (SolarWinds/PRTG yoksa manuel)
mtr --report --report-cycles 100 <MPLS_uzerinden_hedef>
mtr --report --report-cycles 100 <Metro_uzerinden_hedef>

2.3. SMB Protokol Seviyesi Analiz — Wireshark

Wireshark filtreleri:
smb2                              → tüm SMB2/3 trafiği
smb2.cmd == 5                     → Tree Connect istekleri
smb2.cmd == 8                     → Read istekleri
smb2.cmd == 9                     → Write istekleri
smb2.time > 0.1                   → 100ms'den uzun süren SMB işlemleri (yavaşlık kanıtı)
tcp.analysis.retransmission       → TCP seviyesinde retransmit (ağ sorunu kanıtı)

Kritik gösterge: SMB2 Read Response / Write Response süresi ile aynı anlık ölçülen TCP RTT'yi karşılaştır.

• Eğer SMB response süresi ≈ RTT × (chatty request sayısı) → ağ latency kaynaklı.
• Eğer RTT düşük ama SMB response süresi hâlâ yüksek → sunucu/disk kaynaklı (server işleme gecikmesi).

3. Troubleshooting — Kök Neden İzolasyonu (Adım Adım)

Adım 1: Sunucu Lokalinde Baseline Al (Ağı Devre Dışı Bırak)

Sunucunun konsolundan/RDP ile lokalde diskspd çalıştır (WAN yok).

• Sonuç kötüyse → Disk/Storage sorunu kesinleşir, 2. adıma gerek kalmadan doğrudan Bölüm 4'e (Storage çözümleri) geç.
• Sonuç iyiyse → Ağ ve/veya protokol katmanına geç.

Adım 2: Ham Ağ Performansını Test Et (SMB'siz)

iPerf3 ile Lokasyon A ↔ B arası throughput/latency/jitter ölç.

• RTT > 50ms veya packet loss > %1 → MPLS/Metro hat sorunu (kapasite, congestion, yanlış routing/QoS).
• RTT ve throughput normalse → SMB protokol katmanına odaklan.

Adım 3: MPLS mi Metro İnternet mi? Path'i Doğrula

tracert <DataCenter_IP>

veya

mtr <DataCenter_IP>

Hangi hat üzerinden gittiğini ve o hatta hangi hop'ta latency/loss arttığını belirle. Yük dengeleme (load balancing) yanlış yapılandırılmışsa trafik beklenmedik şekilde yedek (Metro İnternet) hatta gidiyor olabilir — bunu route tablosundan doğrula.

Adım 4: SMB Multichannel ve Dialect Kontrolü

Get-SmbConnection | Select ServerName, ShareName, Dialect, NumOpens
Get-SmbMultichannelConnection

• Dialect SMB 2.0.2 gibi eskiyse (Multichannel/Encryption yok) → protokol optimizasyonu şart.
• NumOpens (açık handle sayısı) beklenmedik yüksekse → uygulama tarafı dosya kilitleme sorunu olabilir.

Adım 5: Wireshark ile SMB Response Time Analizi

Bölüm 2.3'teki filtrelerle capture al. Yavaş işlemlerin TCP retransmit ile mi yoksa yüksek RTT + çok sayıda sıralı (sequential) SMB request ile mi ilişkili olduğuna bak.

Adım 6: Karar Matrisi

4. Çözüm ve İyileştirme Önerileri

4.1. Kısa Vadeli (Hızlı Kazanımlar)

• SMB3 + Multichannel'i etkinleştir (birden fazla NIC/path varsa throughput ve resilience artar):

  Set-SmbServerConfiguration -EnableMultiChannel $trueSet-SmbClientConfiguration -EnableMultiChannel $true
  

• SMB Signing/Encryption gereksiz yere aktifse (performans maliyeti var, güvenlik politikası izin veriyorsa) gözden geçir.
• Dosya sunucusundaki diğer kurumsal uygulamaları ayrıştır — aynı sunucuda dosya paylaşımı + başka servisler çalışması kaynak çakışmasının en olası nedenlerinden biri; mümkünse ayrı VM/sunucuya taşı.
• QoS politikası ile SMB/dosya trafiğine öncelik ver (MPLS üzerinde).

4.2. Orta Vadeli

• BranchCache etkinleştir (Lokasyon A'da sık erişilen dosyalar lokal cache'lenir, WAN round-trip azalır):

  # Sunucu (Content Server) tarafıInstall-WindowsFeature BranchCacheSet-BCCache -ServeClientContent $true# Client (Distributed veya Hosted Cache modu)Enable-BCDistributed -ServerNames "OfisSunucusu"netsh branchcache set service mode=distributed
  

• WAN Optimization / SD-WAN cihazı (Riverbed, Silver Peak, Cisco vb.) — TCP optimization, deduplication ve protokol hızlandırma (CIFS/SMB proxy) ile chatty protokol etkisini önemli ölçüde azaltır.
• MPLS ve Metro İnternet arasında akıllı yük dengeleme / policy-based routing — kritik SMB trafiğini düşük latency'li hatta sabitle.

4.3. Uzun Vadeli / Mimari

• Dosya sunucusunu Lokasyon A'ya (kullanıcıya yakın) taşı veya DFS Replication ile her iki lokasyonda replika oluştur (en kalıcı çözüm — WAN üzerinden canlı SMB trafiğini tamamen ortadan kaldırır):

  Install-WindowsFeature FS-DFS-Namespace, FS-DFS-ReplicationNew-DfsReplicationGroup -GroupName "FileServerRepl"New-DfsReplicatedFolder -GroupName "FileServerRepl" -FolderName "Share"
  

• Bulut tabanlı alternatif: Azure File Sync veya benzeri hibrit çözümlerle lokasyon bazlı cache sunucuları.
• Storage katmanını NVMe/All-Flash'e yükselt (yalnızca Adım 1'deki lokal test disk darboğazını doğrularsa yatırım yap — aksi halde gereksiz maliyet).
• Kapasite planlaması: Test sonuçlarına göre 100 kullanıcı için gereken minimum IOPS, bant genişliği ve sunucu kaynak bütçesini dokümante et; büyüme projeksiyonuna göre (150-200 kullanıcı) tekrar test et.

Özet Akış Şeması

[100 Kullanıcı Şikayeti]
        ↓
[Adım 1: Lokal diskspd testi] → Kötü? → STORAGE sorunu → Bölüm 4.3 (upgrade/DFS)
        ↓ İyi
[Adım 2: iPerf3 ile ham ağ testi] → RTT/Loss kötü? → AĞ (MPLS/Metro) sorunu → Bölüm 4.1/4.2 (QoS, WAN Opt)
        ↓ İyi
[Adım 3-5: SMB dialect + Wireshark analizi] → Chatty protokol / yüksek round-trip → SMB PROTOKOL sorunu → Bölüm 4.1/4.2 (Multichannel, BranchCache)
        ↓
[Sunucu kaynakları (CPU/RAM/Queue) kritikse] → SUNUCU sorunu → Uygulama ayrıştırma, kaynak artırımı