Azure Files NFS ile Modern Linux İş Yükleri: Sahadan Bakış
Uzun zamandır Linux tarafında paylaşımlı dosya sistemi işi, Azure’da tam oturmayan bir konuydu. NFS server’ı kendin kur, HA’sını çöz, yedeğini al, izle… Hikâye kabaca buydu. Şimdi Azure Files NFS tarafı baya olgunlaştı ve özellikle AI inference, cloud-native ve klasik enterprise modernizasyon senaryolarında oyunu değiştiriyor.
Kendi deneyimimden konuşuyorum, Bu yazıda Microsoft’un son duyurularını kendi gözümden süzeceğim. Neyi iyi yapmışlar, neresi hâlâ eksik, Türkiye’deki kurumsal ekipler için ne anlama geliyor — hepsine gireceğim. Lafı gevelemeden başlayalım.
Önce Bağlam: Linux İş Yükleri Nereye Gidiyor?
Küçük bir detay: Son iki yılda gördüğüm şey şu: Linux artık sadece “web sunucusu” değil (en azından benim deneyimim böyle). Kurumsal ekipler üç ayrı cepheye yayılmış durumda, hem de aynı anda; bir tarafta on-prem’den taşınan klasik uygulamalar var — SAP eklentileri, custom Java monolitleri, PostgreSQL cluster’ları — öbür tarafta AKS üzerinde koşan mikroservisler var, üstüne bir de son bir yıldır AI inference workload’ları geldi. Epey kalabalık.
Aslında, Bu üç dünyanın ortak derdi ne? Paylaşımlı, dayanıklı, hızlı dosya erişimi. Yanı NFS. Ama on-prem’deki NetApp ya da Isilon rahatlığını bulutta bulmak açık konuşayım zordu; Azure NetApp Files vardı tabi ama fiyatlandırması. Minimum kapasite şartları her bütçeye uymuyor. İşin aslı şu: orta segment için ciddi bir boşluk vardı.
Bunu biraz açayım.
Azure Files NFS, bu boşluğu doldurmaya çalışan bir servis. Ne ANF kadar pahalı, ne de “kendim kurayım” kadar zahmetli. Ama her senaryoya oturuyor mu? Ona bakacağız.
AI Inference Tarafı: Model Yükleme Derdi
Şöyle söyleyeyim, Şimdi işin en ilginç kısmına geldik. AI inference’ta — yanı eğitilmiş modelin tahmin yapması tarafında — en pahalı adım çoğu zaman modelin storage’dan GPU’ya yüklenmesi oluyor. Bir 30-40 GB’lık modeli düşünün; her replika ayağa kalktığında bu ağırlıkları okuması gerekiyor ve GPU’lar boşta beklerken saat işliyor, para akıyor. Kulağa basit geliyor ama değil.
Klasik yaklaşım nedir? İki seçenek var:
- Model ağırlıklarını container image’a gömersin → image şişer, registry’den çekmek uzar, cold start dakikalara çıkar.
- Her replika kendi kopyasını blob’dan indirir → duplicate trafik olur, duplicate maliyet olur, yine yavaş kalır.
Tuhaf ama, Azure Files NFS’in çözümü basit. Etkili: model dosyası bir kere paylaşımda durur, büyük çoğunluk replikalar aynı anda mount edip okur. Image ince kalır, tek bir kopya vardır, yeni replika saniyeler içinde ayağa kalkar (yanlış duymadınız). Bakınca gayet mantıklı dürüyor.
nconnect: Küçük Detay, Büyük Fark
Bak şimdi, NFS’in Linux client’ında nconnect mount opsiyonu var. Ne yapıyor? Aynı file share’e paralel TCP bağlantısı açıyor. Tek TCP soketiyle sınırlı kalmıyorsun; büyük dosya okumalarında throughput’u ciddi şekilde yukarı çekiyor. Hani küçük ayar gibi dürüyor ama bazen asıl fark orada çıkıyor.
Çok konuştum, örnekle göstereyim.
sudo mount -t nfs -o vers=4.1,nconnect=8,rsize=1048576,wsize=1048576 \
storageaccount.file.core.windows.net:/storageaccount/modelshare \
/mnt/modelsBuradaki nconnect=8 değeri her senaryo için sihirli sayı değil. Genelde 4 ile 16 arasında test edip en iyi throughput’u yakalayana kadar denemek lazım; model ne kadar büyükse nconnect’in etkisi de o kadar belirgin oluyor. Emin değilim ama çoğu ekip burada erken peş ediyor gibi geliyor bana.
Zonal Placement: Latency Meselesi
Yeni gelen zonal placement özelliği bence can alıcı iyileştirmelerden biri. Burada, neden? Çünkü şimdiye kadar file share hangi AZ’da tutulacak diye tam kontrol yoktu; GPU VM’ınız zone 1’deyken storage zone 2’de olabiliyordu ve her okuma cross-zone gidiyordu. Milisaniye gibi duran fark binlerce paralel okumada birikince tablo değişiyor.
Vallahi, Şimdi VM’in ve file share’in aynı AZ’da olduğunu garanti edebiliyorsun. Round-trip latency düşüyor, GPU utilization artıyor, saat başı maliyet aynı kalıyor ama iş çıktısı yukarı çıkıyor. Küçük gibi görünen bir feature ama etkisi kağıt üstünde göründüğünden daha fazla.
Provisioned v2: Bu Faturalama Modeli Nihayet Mantıklı
Eski provisioned modelde IOPS ve throughput birbirine bağlıydı. Yanı IOPS’a ihtiyacın olduğunda mecburen throughput’u da almak zorundaydın — kullanmasan bile. Yeni v2 modelde ikisini bağımsız boyutlandırabiliyorsun; açık konuşayım bu baya iş görüyor.
Bi saniye — Bu Türkiye’deki şirketler açısından gerçekten önemli. Neden? Kurumsal müşterilerimde en sık gördüğüm mesele “over-provisioning” oluyor; ihtiyaç 300 MB/s throughput ama IOPS gereksinimi yüksek olduğu için 1 GB/s’lık paket alınıyor, fatura kabarıyor ve kullanım oranı %30’da kalıyor. TL bazında düşününce yıllık on binlerce liralık atıl kapasite demek bu.
Ne Zaman Hangisi?
| Senaryo | Tercih | Neden? |
|---|---|---|
| AI inference (model serve) | Provisioned v2 + zonal + nconnect | Yüksek throughput, düşük latency kritik |
| AKS’te RWX paylaşım | Provisioned v2 (orta seviye) | Pod’lar arası tutarlı erişim |
| Klasik lift & shift NFS | Pay-as-you-go veya v1 | Yük tahmin edilemez, esneklik önce |
| HPC / veri analitiği | Azure NetApp Files (Azure Files değil) | Sabit sub-millisecond latency lazımsa ANF hâlâ önde |
Cloud-Native Senaryolar: AKS’te RWX Derdi
Şöyle ki, Kubernetes tarafında ReadWriteMany (RWX) volume ihtiyacı hemen hemen her ekipte çıkıyor. Bir Django uygulaması düşünün; media dosyaları var, statik varlıklar var, kullanıcı upload’ları var… Bunları her pod’un ayrı diskinde tutamazsın çünkü state tutarsız kalır. RWX access mode şart oluyor.
Ve işler burada ilginçleşiyor.
Bunu yaşayan biri olarak söyleyeyim, Eskiden ne yapıyorduk? Ya bir NFS server pod’u kaldırıyorduk — single point of failure kokusu ortada — ya Rook-Ceph gibi kompleks çözümlere giriyorduk ve operasyonel yük katlanıyordu ya da ANF açıyorduk ve bütçe patlıyordu. Azure Files NFS burada orta yolu buluyor; CSI driver ile AKS’e mount ediyorsun, kullanıyorsun, sonra da çok uğraşmadan devam ediyorsun.
azurefile-csi yerine azurefile-csi-nfs StorageClass’ını kullanmanız gerekiyor. Karıştırmak sık yapılan bir hata; SMB üzerinden mount edince NFS’in performans avantajlarını kaybediyorsunuz.
Bazı İşlerde Fren Yapmak Lazım
Bunu özellikle söylemem lazım: Azure Files NFS büyük dosya okuma/yazmada iyi gidiyor ama milyonlarca ufak dosyayla çalışan bir workload’unuz varsa — mesela Git repo’şuna benzeyen ya da node_modules benzeri şeyler — performans beklediğiniz kadar olmayabilir. Bu tip işler için local SSD ya da farklı bir çözüm düşünmek gerekiyor; kağıt üstünde her şey NFS gibi görünse de workload karakteristiği kritik noktaya dönüşüyor.
Evet Peki Enterprise Modernizasyon?
Düz anlatayım: On-prem’den buluta taşınan uygulamaların önemli kısmının altında zaten bir NFS mount noktası var. SAP, Oracle, custom Java uygulamaları… Bunları refactor etmek yerine “olduğu gibi taşıyıp” mount noktasını Azure Files NFS’e çevirmek çoğu zaman en az riskli yaklaşım oluyor; az bozarak taşımak yanı.
Tuhaf ama, Böyle göç senaryolarını daha detaylı anlattığım bir yazı vardı: Azure Storage Göçü: Planlamadan Kesime Sahadan Notlar. Hele bir de kesim planlaması kısmına bakmanızı öneririm çünkü işin yarısı orada dönüyor desem abartmış olmam.
Neyse biraz dağıldım, konumuza dönelim: Kurumsal ekiplerde bu geçiş genelde şöyle yaşanıyor; önce test ortamı taşınıyor, iki hafta çalıştırılıyor ve IOPS/throughput profili çıkarılıyor, sonra provisioned v2’de doğru boyutlandırma yapılıyor. Bu adımı atlayıp direkt production’a geçen ekipler ya over-provision edip para yakıyor ya da under-provision edip performans problemi yaşıyor; ikisi de kötü.
Sız Ne Dersiniz?
Küçük bir ekipseniz veya startup’sanız pay-as-you-go modeliyle başlayın derim; kullanım profilinizi görün sonra provisioned’a geçersiniz çünkü peşin taahhüt etmek gereksiz olabilir. Aylık 100-200 dolarlık fark bile küçük ekipte hissediliyor işte.
Büyük kurumsal yapıdaysanız baştan provisioned v2 + zonal placement + reserved capacity kombinasyonuna gitmek mantıklı olabilir; 1 yıllık reserved commitment %20-30 tasarruf sağlıyor ama şart şu: workload profilinizi biliyor olmanız lazım (ben de ilk duyduğumda şaşırmıştım). Bilmiyorsanız önce 1 ay pay-as-you-go ile ölçün ki sonra şaşırmayın.
Peki Ya Partner ve ISV Ekosistemi?
Burası biraz gözden kaçıyor ama önemli: Azure Files NFS artık ciddi ISV entegrasyonlarına sahip öldü. Commvault, Veeam, Rubrik gibi backup çözümleri native destek veriyor; HPC tarafında Altair. Ansys workload’ları için referans mimariler var. Ekosistem böyle olgunlaşınca “Azure’da NFS var mı?” sorusunun cevabı netleşiyor: evet var ve destekleniyor.
Peki neden?
Kubernetes tarafından bahsederken cluster yönetim araçlarındaki gelişmeler de dikkat çekici hâle geliyor. Görsel yönetim isteyen ekipler için Headlamp Cluster API Eklentisi: CAPI Artık Görsel Arayüzde yazısına göz atmanızı öneririm; Azure Files NFS’i AKS’e mount ettikten sonra volume durumlarını Headlamp üzerinden takip etmek baya pratik oluyor.
Peki Nereden Başlayacaksınız?
Lafı uzatmadan ilk adımlar için ben şu sırayı öneriyorum:
- Storage account planı — FileStorage tipi seçin, Premium tier kullanın; Standard tier NFS desteklemiyor.
- Zonal placement — VM’ınız veya AKS node pool’unuz hangi AZ’daysa aynı AZ’yı seçin.
- Network kısıtı
- —
Sıkça Sorulan Sorular
Azure Files NFS ile Azure NetApp Files arasındaki fark ne?
Azure Files NFS, tam yönetimli. Daha uygun fiyatlı bir çözüm; yanı orta segment iş yükleri için gayet iyi iş görüyor. ANF işe sub-millisecond latency, çok yüksek IOPS ve enterprise özellikler sunuyor — SAP HANA, HPC, büyük veritabanları gibi ekstrem performans isteyen senaryolar için tasarlanmış. Fiyat farkı da buna göre tabiî; açıkçası ANF ciddi biçimde pahalı.
AKS’te Azure Files NFS mount ederken hangi StorageClass’ı kullanmalıyım?
NFS özelliklerinden faydalanmak istiyorsan azurefile-csi-nfs StorageClass’ını kullan. Standart azurefile-csi hani SMB üzerinden mount ediyor ve Linux workload’ları için performans avantajlarını kaybediyorsun. Premium tier FileStorage account da şart, bunu atlama.
nconnect değerini kaç yapmalıyım?
Sihirli bir sayı yok açıkçası. Genelde 4-16 arasında test et. AI inference gibi büyük dosya okumaları için mesela 8-16 arası iyi sonuç veriyor. Ama küçük dosya ağırlıklı workload’larda çok yüksek nconnect değerleri ters etki yapabiliyor. Bence en sağlıklısı fio veya benzeri bir benchmark aracıyla kendin ölçmek.
Provisioned v1’den v2’ye geçiş yaparken ne dikkat etmeliyim?
v2’de IOPS. Throughput bağımsız boyutlandırılıyor, yanı mevcut kullanım profilinizi çıkarıp iki metriği ayrı ayrı planlamanız gerekiyor. Migration sırasında kısa bir downtime olabiliyor; production için genelde bakım penceresi ayırın. Ayrıca tecrübeme göre reserved capacity almadan önce en az bir ay pay-as-you-go ölçüm yapmanızı öneririm.
Azure Files NFS backup nasıl yapılır?
Azure Backup, Files NFS için native destek sunuyor; snapshot tabanlı çalışıyor ve point-in-time recovery imkanı veriyor. Kritik veriler için ekstra olarak Veeam veya Commvault gibi çözümlerle cross-region backup planlamak iyi bir pratik. Sadece snapshot’a güvenmeyin — hani aynı region’da kalıyor ve bölgesel felakete karşı sizi korumaz.
Kaynaklar ve İleri Okuma
Azure Files NFS Protocol — Microsoft Learn
Accelerate modern Linux workloads with Azure Files — Azure Blog (kendi tecrübem)
Azure Files NFS Performance Tuning Guide
AKS ile Azure Files CSI Driver Kullanımı
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder