Azure Files NFS ile Linux İş Yükleri: Sahadan Notlar

Uzun süredir Azure tarafında file share hikâyesi biraz “SMB ve Windows dünyası” olarak algılanıyordu. Linux tarafı işe NFS için ya kendi VM’ını kurup üzerine ganesha oturtan, ya da üçüncü parti çözümlere yönelen ekiplere kalmıştı. Şimdi tablo değişiyor. Hem de fena değişmiyor.

Geçen hafta bir müşterinin AI inference platformunu değerlendirirken tam da bu konuyu tartıştık. Model ağırlıkları 40 GB’ı geçince, her pod’un kendi kopyasını çekmesi bir noktadan sonra saçmalık hâline geliyor. İşte Azure Files NFS’in son güncellemeleri tam bu noktada devreye giriyor. Zonal yerleşim, provisioned v2 faturalama, nconnect desteği… Kağıt üstünde hepsi güzel. Peki sahada ne anlama geliyor? Bugün önü konuşacağız.

Ve işler burada ilginçleşiyor.

Neden Şimdi? Linux İş Yüklerinin Değişen Yüzü

Bakın şimdi, Linux iş yükleri artık eskisi gibi değil. Yıllardır aynı LAMP stack’i, aynı NFS mount’ları, — kendi adıma konuşayım — aynı klasik mimariler vardı. Şimdi işe üç ayrı yönde çekiştiriliyor: eski on-prem uygulamaların buluta göçü, cloud-native yeniden yazımlar ve AI/data pipeline’ları. Her birinin dosya sisteminden beklentisi farklı.

Sahada gördüğüm kadarıyla ekipler şu üçlemeyle boğuşuyor: performans, dayanıklılık ve maliyet. İkisini optimize ediyorsun, üçüncüsü uçuyor. Yönetilen bir dosya servisi bu üçgeni bir nebze rahatlatıyor — çünkü altyapıyı sen kurmuyorsun, ama üzerine gelen yükün karakterine göre parametreleri tune edebiliyorsun.

Türkiye tarafında işe ilginç bir durum var. Kurumsal kurumsal ortamlarda şunu sık görüyorum: veri egemenliği gerekçesiyle bazı iş yükleri hâlâ on-prem’de tutuluyor. Hesaplama gücünü buluttan almak istiyorlar. Hibrit senaryoda paylaşımlı dosya sistemi, adeta yapıştırıcı bir düşüneyim… görevi görüyor. E peki, sonuç ne öldü? Azure Files NFS de burada oldukça mantıklı bir seçenek.

İlgili içerik: Azure Files NFS ile Modern Linux İş Yükleri: Sahadan Bakış

Evet.

AI Inference: GPU’yu Bekletmek Cebe Ateş Etmektir

Tuhaf ama, Şunu net söyleyeyim: GPU beklerken para yakıyorsunuz. Bir A100 saatliği ne kadar tutuyor biliyorsunuz. Model ağırlıkları storage’dan yüklenirken o pahalı silikon boş boş dürüyor. Yanı soğuk başlangıç süresi doğrudan cebinizi vuruyor.

Klasik yaklaşımlar iki tane. Ya model ağırlıklarını container imajının içine gömüyorsun — bu durumda imaj şişiyor, registry pull süresi uzuyor, versiyonlama kabusa dönüyor. Ya da her replica kendi kopyasını blob’dan indiriyor. İkincisi ilk bakışta mantıklı görünüyor ama… 20 replica varsa aynı 40 GB’ı 20 kere indiriyorsunuz. Hem gereksiz, hem yavaş.

Şimdi, azure Files NFS ile model ağırlığı tek yerde dürüyor (ben de ilk duyduğumda şaşırmıştım). Her replica aynı share’i mount edip aynı dosyayı okuyor. Yeni bir replica geldiğinde imaj minik, mount hemen bağlanıyor, dosya okuma paralel. Küçük ve orta boy modellerde replica’lar saniyeler içinde ayağa kalkabiliyor (şaşırtıcı ama gerçek)

Peki neden?

nconnect: Tek Bağlantı Yetmediğinde

Linux NFS’in klasik dertlerinden biri şuydu: client ile sunucu arasında tek bir TCP bağlantısı olurdu. Yüksek bant genişliğine sahip bir GPU VM’i bile bu tek bağlantının tavanına takılırdı. nconnect mount seçeneği bu işi çözüyor. Aynı share’e paralel birden fazla TCP bağlantısı açıyorsunuz.

Size bir şey söyleyeyim, Örnek bir mount komutu şöyle görünüyor:

sudo mount -t nfs \
-o vers=4.1,nconnect=8,rsize=1048576,wsize=1048576 \
<storage-account>.file.core.windows.net:/<share> \
/mnt/models

Burada nconnect=8 ile 8 paralel bağlantı açılıyor. Rakamı arttırmak genelde iyi değil — 4 ile 8 arası genelde tatlı nokta. 16’ya çıkardığımda bazı senaryolarda ters teptiğini gördüm, CPU tarafında context switch maliyeti arttı. Denemeden karar vermeyin.

Bu kadar mı?

Zonal Yerleşim: Latency’i Öldüren Detay

Bir de yeni gelen zonal placement var. Storage account’unuzu, GPU VM’lerinizle aynı availability zone’a yerleştirebiliyorsunuz. Kulağa küçük bir detay gibi geliyor ama… AZ’ler arası round-trip latency, aynı AZ içine kıyasla belirgin farklı. AI inference gibi latency-sensitive iş yüklerinde bu fark saatler sonunda ciddi rakamlara dönüşüyor.

“Storage’ı doğru yere koymak, çoğu zaman daha büyük VM almaktan daha ucuz bir performans kazanımı sağlıyor. Ama insanlar önce VM boyutuyla oynuyor.”

Bir şey dikkatimi çekti: Neyse, çok dağıttım, konumuza dönelim.

Provisioned v2: IOPS ve Throughput’u Ayrı Ayrı Almak

Eski faturalama modelinde şöyle bir dert vardı: kapasite arttırırsan IOPS artıyordu, IOPS istiyorsan gereksiz kapasite alıyordun. Kimi zaman 100 — ki bu tartışılır — GB veri için 5 TB share açtığın öldü mu? Benim öldü. Çünkü altındaki IOPS ihtiyacı öyle gerektiriyordu.

Provisioned v2 modeli bu bağımlılığı kırıyor. Kapasite, IOPS ve throughput’u ayrı ayrı boyutlandırıyorsunuz. Böylece:

• Küçük ama sık okunan model dosyaları için — az kapasite, çok IOPS
• Büyük ama az erişilen backup arşivi için — çok kapasite, düşük IOPS
• Video işleme pipeline için — orta kapasite, yüksek throughput

Bakın, bir şey dikkatimi çekti: Bu ayrıştırma FinOps açısından bayağı önemli (şaşırtıcı ama gerçek). Türkiye’deki kurumsal müşterilerimin çoğunda Azure faturası TL bazında büyüyor ve her ay yönetim kuruluna açıklanması gereken bir tablo hâline geliyor. “Neden 5 TB storage alıyoruz da 100 GB kullanıyoruz?” sorusuna cevap vermek zor.
Yeni modelde bu tarz absürtlükler ortadan kalkıyor.

Küçük Bir Karşılaştırma Tablosu

Senaryo	Klasik Yaklaşım	Azure Files NFS (v2)
Model ağırlığı dağıtımı	Her replica ayrı indirir	Tek kopya, paylaşımlı mount
Cold start süresi	Dakikalar	Saniyeler (küçük/orta model)
IOPS/kapasite bağı	Birbirine bağlı	Ayrı ayrı ölçeklenir
Fiyatlandırma esnekliği	Sınırlı	Yüksek

Cloud-Native ve Kubernetes: RWX Meselesi

Kubernetes’te ReadWriteMany (RWX) volume ihtiyacı olan ekipleri bilirim. Azure Disk RWO çalışır, RWX değil.
E o zaman ne yapacaksın? Ya kendi NFS server’ını kur (yönetim yükü), ya da Azure Files NFS’e git.

AKS tarafında CSI driver hazır geliyor, StorageClass tanımlayıp PVC üzerinden çekiyorsunuz.
Log toplama, paylaşımlı config, ML training için dataset klasörleri, ETL pipeline’ının ara çıktıları… Hepsi bu tarz shared storage’a ihtiyaç duyuyor.

Şunu fark ettim: Ama şunu da söyleyeyim: her RWX ihtiyacı NFS ile çözülmemeli.
Küçük dosyalarla yoğun metadata operasyonu yapan iş yükleri (mesela çok sayıda küçük dosyayla çalışan CI cache) NFS üzerinde bazen beklediğiniz gibi performans göstermeyebilir.
O senaryolarda blob + blobfuse2 veya doğrudan object storage API’si daha mantıklı olabiliyor.
Kubernetes tarafında paylaşımlı storage denklemine

Açık konuşayım,

“`html
İşte Azure Files NFS burada işi kolaylaştırıyor.
Uygulamanızın mount yolunu değiştiriyorsunuz.
Gerisi aynı.
POSIX permissions çalışıyor.
Symbolic link de çalışıyor.
Standart NFS semantiği de öyle.
Uygulamayı yeniden yazmadan buluta taşımanın maliyeti,
refactor maliyetinin genellikle onda biri civarında oluyor.
“`

<!-- Not: Yukarıdaki blok yalnızca örnek amaçlıdır -->

“`text
Küçük bir uyarı:
on-prem NFS server’ınızın performansını Azure Files’a birebir yansıtmayı beklemeyin.
Lokal ağdaki 10 GbE ile bulut arasındaki latency profili farklıdır.
Göçten önce iş yükünün I/O pattern’ını profile edin.
iostat ve nfsiostat gibi araçlar dostunuz.

Enterprise vs Startup: Kime Ne Uygun?

Küçük bir ekipseniz,
birkaç servisiniz var
ve model boyutu 5-10 GB civarındaysa —
belki Azure Files’a hiç gerek yok.
Container imajına gömün,
geçin gitsin.
Fazla mühendislik yapmayın.

Ama enterprise seviyedeyseniz,
birden fazla model versiyonunuz var,
A/B testing yapıyorsunuz,
canary deployment’lar dönüyor…
İşte o zaman merkezî bir file share hem operasyonel hem finansal açıdan mantıklı hâle geliyor.
Model versiyonu değiştirmek için imaj rebuild etmek yerine sadece dosyayı share’e atmak,
deployment velocity’nızı ciddi anlamda arttırır.
“`

İlk Adım Olarak Ne Yapmalı?

“ol
Denemek istiyorsanız,
benim tavsiyem şu sırayla ilerleyin:
1) Küçük bir premium tier storage account açın,
provisioned v2 modelini seçin.
2) NFS 4\.1 protokolünü etkinleştirin
ve private endpoint ile network’e bağlayın.
3) Test VM’inizden nconnect=4 ile mount edip fio ile baseline ölçün.
4) Zonal placement’ı denediğinizde VM’in de aynı AZ’de olduğundan emin olun.
5) Sonra nconnect değerini yükseltip performansın nasıl skalar ettiğini gözlemleyin.

Bu adımları takip ederseniz iş yükünüzün karakterini de tanımış olursunuz.
Prod’a çıkmadan önce mutlaka backup ve snapshot stratejinizi netleştirin.
Azure Files snapshot’ları çok işe yarıyor ama retention policy’i baştan doğru kurmazsanız hem maliyet hem karmaşa üretir.
“`

Eksik Kaldığını Düşündüğüm Yerler

“html
Her yazımın sonunda küçük bir eleştiri kısmı olsun istiyorum çünkü kimse mükemmel değil,
Microsoft dahil.

Azure Files NFS iyi bir yerde ama hâlâ SMB tarafındaki bazı özelliklerin NFS’te olmadığını görüyoruz.
AD entegrasyonu,
Kerberos senaryoları biraz kısıtlı.

Cross-region replication seçenekleri de biraz daha esnek olabilirdi.

Bir de fiyatlandırma…
Premium tier hâlâ pahalı.

Provisioned v2 ile IOPS/kapasite ayrılığı geldi ama absolute rakamlar TL bazında düşünüldüğünde küçük ekipleri zorluyor.

Umarım standard tier’a da NFS desteği yakında gelir.

Yoksa “bütçesi kısıtlı” senaryolarda hâlâ blob + FUSE alternatifi daha cazip kalıyor.

Sıkça Sorulan Sorular

Azure Files NFS mi SMB mi — Linux için hangisi daha iyi?

Bi saniye — Açıkçası Linux iş yükleri için NFS çok daha doğal hissettiriyor. POSIX semantics tam destekli, dosya kilitleme ve permissions native çalışıyor. SMB’yi Linux’ta çalıştırabilirsiniz tabiî, ama bence karma senaryolar dışında pek gerek yok (ciddiyim)

nconnect değerini kaç yapayım?

Tecrübeme göre 4 ile 8 arası genelde tatlı nokta oluyor. VM’ınızın CPU core sayısına ve — en azından ben öyle düşünüyorum — iş yükünüzün ne kadar paralel çalıştığına göre değişiyor. 16 ve üzeri değerler bazı senaryolarda ters tepebiliyor — bu yüzden mutlaka fio ile ölçüp karar verin.

Ve işler burada ilginçleşiyor.

Provisioned v2 modelini mevcut share’lere uygulayabilir miyim?

Yeni oluşturulan file share’lerde kullanabiliyorsunuz. Mevcut share’ler için bazı migration yolları var ama her senaryo desteklenmiyor. Yanı bence en temiz yaklaşım yeni bir share açıp veriyi oraya kopyalamak — çoğu zaman daha az baş ağrısı.

Zonal placement her bölgede var mı?

Bakın, bir şey dikkatimi çekti: Hayır. Yalnızca availability zone destekleyen bölgelerde geçerli. Türkiye’ye en yakın North Europe ve West Europe’da mevcut. UAE North gibi bazı bölgelerde hâlâ sınırlı — planlama yaparken güncel bölge listesini kontrol etmenizi öneririm.

Ve işler burada ilginçleşiyor.

Backup ve disaster recovery nasıl kurulur?

Azure Backup ile file share’lerin native backup’ını alabiliyorsunuz. Snapshot’lar işe hızlı ve pratik — anlık kurtarma için gerçekten işe yarıyor. DR senaryosu içinse ayrı bir bölgede replica share tutup periyodik olarak azcopy veya rsync ile senkronize etmek yaygın bir pattern; aslında çoğu ekip de bunu yapıyor.

Kaynaklar ve İleri Okuma

İlginç olan şu ki, Microsoft Azure Blog — Accelerate Modern Linux Workloads with Azure Files

Azure Files NFS Protocol Resmî Dokümantasyonu

nconnect ile NFS Performansını İyileştirme Rehberi

AKS. Şimdi, azure Files NFS CSI Driver Kullanımı