Azure NetApp Files EDA İçin: Bulutta Çip Tasarımı Devri

Bir itirafla başlayayım. Yıllarca “yarı iletken tasarımı bulutta ölür mu, olmaz mı” tartışmalarında ben de “olmaz” diyenlerdendim. Sebebi basit: EDA dediğin iş, depolama tarafında öyle bir yük bindiriyor ki, geleneksel bulut storage mimarileri bunu kaldırmakta zorlanıyordu. Latency biraz tırmandı mı, regression süresi 8 saatten 14 saate çıkıyor, lisans saatleri uçuyor, mühendis sabırsızlıkla bekliyor…

Bakın, Ama son iki yılda işler değişti. Hem de baya değişti.

Geçenlerde bir savunma sanayii müşterimizde — adını veremeyeceğim, ama Ankara’da ciddi bir ASIC tasarım ekibi var — Azure NetApp Files üzerinde küçük bir POC yaptık. Sonuçlar beni de şaşırttı açıkçası. On-prem NetApp filer’ları ile aldıkları sonuçlara yakın, hatta bazı senaryolarda üzerinde performans çıktı. İşte bu yazıda, ANF’nın EDA workload’ları için neden bu kadar kritik bir hamle olduğunu, sahadan gözlemlerimle anlatacağım.

EDA Workload’ı Neden Bu Kadar Zorlu?

Önce şu resmî net çizelim. EDA (Electronic Design Automation) dediğimiz şey, çip tasarımcısının elindeki yazılım yığını; simülasyon, sentez, yer-yol (place and route), DRC, LVS, statik zamanlama analizi… Hepsi işin içinde. Cadence, Synopsys, Siemens EDA gibi araçlar da bunu paralel iş kuyrukları hâlinde çalıştırıyor,. Bir gecede cluster üzerinde 8.000-15.000 işin dönmesi hiç şaşırtıcı değil.

Çok konuştum, örnekle göstereyim.

Bak şimdi, asıl mesele burada başlıyor. Bu işlerin hepsi aynı shared file system’e bakıyor, aynı kütüphaneleri okuyor, aynı netlist’leri çiziyor ve milyonlarca küçük dosyada open-close yapıp duruyor; yani diskten veri okumak kadar metadata tarafı da yükün tam ortasında kalıyor.

İşin üç ana karakteristiği var: (en azından benim deneyimim böyle)

• Aşırı eş zamanlılık: Binlerce job, tek storage namespace üzerinde.
• Latency hassasiyeti: Tek bir job’ın storage cevap süresi 2 ms’den 5 ms’ye çıktığında, regression cycle dakikalar değil, saatler uzuyor.
• Küçük dosya yoğunluğu: Bir tek tasarım projesi 200 milyon dosya barındırabiliyor. Çoğu birkaç KB. — ciddi fark yaratıyor

Bulutta compute’u scale etmek kolay, önü kabul edelim. VM ekledin mi geçiyorsun. Ama shared storage’ı aynı eğride büyütmek? Hmm, orada işler biraz dağılıyor; çoğu cloud storage çözümü belli bir concurrency seviyesinden sonra hotspot yaşıyor, latency variance artıyor ve mühendis de haklı olarak yüzünü buruşturuyor.

Evet. Daha fazla bilgi için devri ile ilgili önceki yazımız yazımıza bakabilirsiniz.

Azure NetApp Files Bu İşi Nasıl Çözüyor?

ANF, aslında bildiğimiz NetApp ONTAP’in Azure üstünde first-party servis gibi duran hâli. Yani Microsoft satıyor, ama işin arkasında NetApp donanımı var; Azure veri merkezlerinde fiziksel olarak çalışan NetApp controller’lar. Ufak bir detay gibi görünüyor, değil mi? Ama değil. Çünkü düşük latency tarafının nedenini biraz da bu açıklıyor, hani “neden bu kadar seri?” sorusunun cevabı burada saklı.

Mimarı tarafta en sevdiğim nokta şu: compute ve storage’ı ayrı ayrı büyütebiliyorsunuz. EDA cluster’ınız 500 node’dan 2000’e fırladığında, storage tarafında “eyvah şimdi mimariyi yeniden mi kuracağız” diye bir dert çıkmıyor; şey, pek çıkmıyor diyeyim. Service-level performance modeli sayesinde throughput ve IOPS kapasiteyle birlikte öngörülebilir şekilde ölçekleniyor, yani kafadan tahmin yürütmek yerine biraz daha rahat nefes alıyorsunuz.

“Storage’ın predictable olması, EDA için ‘fast’ olmasından daha kritik. Çünkü tape-out planlaması, regression cycle’ın kaç saat süreceğini bilmek üzerine kurulu.”

Large Volumes ve Breakthrough Mode

Bir süre önce ANF tarafına gelen “large volumes” özelliği baya iş görüyor; tek volume kapasitesini 1 PB’a kadar çıkarabiliyorsunuz. İlk bakışta sadece kapasite artışı gibi duruyor ama işin aslı biraz daha farklı, çünkü EDA ekipleri çoklu mount point karmaşasını pek sevmez — tek namespace, tek mount, az dert.

İtiraf edeyim, Geçen aylarda gelen “breakthrough mode” işe işi bir tık daha ileri taşıyor. Tek bir large volume üzerinde paralel job sayısını ciddi şekilde artırabiliyorsunuz; bağımsız benchmark sonuçlarında 826K IOPS. 10+ GB/s throughput konuşuluyor. Bu rakamları ilk kez gören biri “bu ne ya?” diyebilir, haklı da ölür. Ama kabaca söylemek gerekirse bu, mid-size bir on-prem NetApp filer’a denk performans demek; üstelik buluttan geliyor (ben de ilk duyduğumda şaşırmıştım). Neyse, şaşırdım açıkçası.

Karşılaştırma: ANF vs Diğer Storage Seçenekleri

Azure tarafında EDA için bakabileceğiniz başka seçenekler de var. Hepsini aynı torbaya atmak pek adil olmaz. İşte sahada gördüğüm, biraz kaba ama iş gören bir karşılaştırma:

Dürüst olmak gerekirse, Peki neden ANF bu tabloda öne çıkıyor? Çünkü mesele sadece hız değil. Küçük dosya yağmuru var, metadata trafiği var, bir de üstüne NFS tarafında tuhaf görünen ama EDA dünyasında gayet normal sayılan davranışlar geliyor; işte burada NetApp’in uzun yıllardır biriktirdiği tecrübe baya işe yarıyor.

Lustre tarafına gelirsek, açık konuşayım, saf HPC workload’larında baya iyi duruyor. Ama EDA başka bir hayvan. POSIX semantiği, NFS lock davranışı, küçük dosya I/O paterni… bunlar yüzünden tablo değişiyor (yanlış duymadınız). Az önce Lustre’yi övdüm ama burada küçük bir fren yapayım: her güçlü sistem, her iş yüküne uygun olmuyor.

Evet. Daha fazla bilgi için Kubernetes v1.36’da PSI Metrikleri GA: Sahadan Notlar yazımıza bakabilirsiniz.

Azure Files Premium işe idare eder bir seçenek gibi görünüyor. Yönetimi rahat, servis olarak da temiz ilerliyor. Ama latency ve metadata tarafında ANF ile aynı ligde değil; yani “olsa da ölür” ile “işi taşır” arasında ince ama önemli bir çizgi var.

Yani, Neyse, çok dağıtmadan söyleyeyim: EDA için storage seçerken sadece kapasiteye bakarsanız şaşırırsınız. Asıl oyun, erişim modeli ve dosya davranışında dönüyor. Siz ne dersiniz? Bu konuyla ilgili npm Staged Publishing GA: Tedarik Zinciri Artık Daha Güvenli yazımıza da göz atmanızı tavsiye ederim.

Türkiye’deki Yarı İletken Ekipleri İçin Ne Anlama Geliyor?

Şimdi Türkiye tarafına gelelim. Bu kısım biraz içimden geliyor, çünkü yıllardır “bizde de tasarım merkezî açılsa” diye aynı cümleyi dönüp durduk (kendi tecrübem). Son birkaç senede, hem savunma sanayii hem de telco/defense çevresinde RTL tasarım ekipleri ciddi ciddi büyümeye başladı; ASELSAN var, HAVELSAN var, birkaç startup var, TÜBİTAK BİLGEM tarafında da çalışan ekipler var, yani tablo boş değil. Bu konuyla ilgili etcd 3.7.0-beta.0 Yayında: RangeStream ve v2store Vedası yazımıza da göz atmanızı tavsiye ederim.

Bu ekiplerin ortak derdi ne biliyor müsünüz? Lisans maliyeti değil aslında. Synopsys ve Cadence lisansları zaten pahalı, önü herkes az çok kabullenmiş durumda. Asıl mesele, regression çalıştıracak yeterli compute kapasitesinin olmaması; on-prem’de 200 core ile dönen bir ekibin gece boyunca bulutta 2000 core’a çıkması çoğu zaman hayal gibi kalıyordu, çünkü storage tarafı net değildi.

İşte ANF burada iş görüyor. Çünkü hibrit bir model kuruyor: gündüz tasarım on-prem’de kalıyor, gece regression Azure’da koşuyor. NetApp tarafındaki SnapMirror entegrasyonu sayesinde veri replikasyonu native ilerliyor — yani on-prem NetApp filer’ınız varsa, oraya SnapMirror ilişkisini kurup akşam bulutta ayağa kaldırabiliyorsunuz. Açık konuşayım, Türkiye’de orta ölçekli tasarım ekiplerinin çoğunun normalde ulaşamadığı bir esneklik bu (ki bu çoğu kişinin gözünden kaçıyor)

Çok konuştum, örnekle göstereyim.

Maliyet Tarafı: Açık Konuşalım

Bunu biri söylemek zorunda: ANF ucuz değil. Premium tier’da TB başına aylık fiyat 200 USD civarına kadar çıkabiliyor; 100 TB’lık bir EDA volume için ayda 20K USD konuşuyoruz, TL’ye çevirince de rakam baya can sıkıyor, 700K TL’yi geçiyor.

Ama hesabı tek satırda yapmak da yanlış ölür. Bir EDA mühendisinin saatlik yükü — tool license ile mühendis maliyetini birlikte düşünün — 100-200 USD bandına oturabiliyor. Eğer storage darboğazı yüzünden 1000 saatlik lisans boşa gidiyorsa, siz zaten 100K USD’yi geçmişsiniz demektir. Mesele storage’ın kendisi değil, lisansı ne kadar verimli kullandığınız (inanın bana)

İşte tam da bu noktada devreye giriyor.

Saha Hikâyesi: Bir Sorunla Karşılaştığımda

2023 sonunda bir POC sırasında garip bir şeyle uğraştım. Müşteri NFSv3 ile volume’u mount ediyordu, ama job sayısı biraz yükselince arada bir “stale file handle” hataları düşüyordu; ilk bakışta insanın aklı hemen ANF tarafına gidiyor, ben de öyle yaptım, hatta saatlerce logların içinde gezindim.

Bunu yaşayan biri olarak söyleyeyim, Bak şimdi, asıl mesele bizim taraftaymış. Client VM’lerde nconnect parametresi (söylemesi ayıp) default değerde kalmıştı; bu ayar NFS client’ın storage’a kaç paralel TCP bağlantısı açacağını belirliyor,. Yüksek concurrency gelince o tek bağlantı bazen yetmiyor, işte sorun da oradan patlıyor (yanlış duymadınız)

# Mount komutunu şöyle düzelttik:
mount -t nfs -o rw,hard,rsize=262144,wsize=262144,vers=3,tcp,nconnect=16 \
10.x.x.x:/edaVolume /mnt/eda

nconnect=16 ekleyince sorun büyük ölçüde kayboldu. Şaşırdım açıkçası. Dokümantasyonda bu detay var, evet var; ama ilk denemede kimse dönüp bakmıyor maalesef, ben de bakmamıştım. Yani lafı gevelemeden söyleyeyim: ANF kullanıyorsanız sadece servis tarafına değil, NFS client tuning kısmına da göz atın.

Evet.

Enterprise vs Startup: Hangisi Sizin İçin?

Peki, bunu yaşayan biri olarak söyleyeyim, Yıllarca farklı ölçeklerde ekiplerle çalıştıktan sonra şunu açık açık söyleyebilirim: ANF, herkesin ilk tercihi olmuyor. Hatta bazen hiç olmuyor. Çünkü işin aslı, ekip küçükse ve veri tarafı daha yeni yeni oturuyorsa, bu servis biraz fazla ağır kalabiliyor. Kubernetes v1.36 Server-Side Sharded Watch: Saha Notları yazımızda bu konuya da değinmiştik.

Küçük ekip / startup iseniz

5-10 mühendisli, daha tape-out yapmamış bir RTL ekibiniz varsa, bence ANF’ye hemen atlamayın. Peki, Azure Files Premium ya da düzgün ayarlanmış bir Lustre cluster çoğu zaman işinizi görür; hem kurulum tarafı daha az yorucu oluyor, hem de cebinizdeki bütçe daha az sarsılıyor. ANF’nın minimum capacity pool boyutu 4 TB. Fiyat yapısı tier-based — yani küçük başlayayım, sonra büyürüm diyorsanız, ilk etapta maliyet/fayda dengesi biraz can sıkabiliyor.

İşte tam da bu noktada devreye giriyor.

Evet.

Kurumsal / orta-büyük ekip iseniz

İlginç olan şu ki, 50+ mühendisli, sürekli regression döndüren, tape-out yapmış ya da artık o aşamaya çok yaklaşmış bir ekipseniz, burada tablo değişiyor. ANF’yi bir kenara itmek biraz acele ölür. Bilhassa hâlihazırda on-prem NetApp kullanıyorsanız, SnapMirror entegrasyonu sayesinde geçiş süreci daha az sürünüyor. Klasik “nasıl taşıyacağız bunu?” krizini biraz olsun yumuşatıyor. Bir bankacılık projesinde değil ama benzer bir hibrit mimarı kurarken bunu birebir gördüm, 6 hafta içinde tam entegrasyon mümkün olmuştu; tabii ortamın hazırlanması, testlerin dönmesi ve ekiplerin birbirine alışması da işin içine girince süre uzayabilir diye düşünmüştüm ama öyle olmadı.

Peki neden?

İlk Adımlar: Nereden Başlamalı?

Bir kurumsal müşteri ANF üstünde EDA çalıştırmaya karar verdiğinde, ben genelde işi şöyle sıralıyorum. Kulağa basit geliyor, biliyorum; ama ilk gün atlanan küçük bir detay, sonra gece yarısı can sıkıyor.

1. POC volume: Önce küçük bir volume açın, mesela 4-10 TB arası yeterli oluyor, gerçek workload ile deneyin. Sentetik benchmark yapmayın; sentetik biraz cilalı duruyor ama çoğu zaman sahadaki davranışı tam vermiyor. (bu kritik)
2. Network mimarisi: ANF’yi delegate edilmiş bir subnet’e yerleştiriyorsunuz, tamam; ama asıl mesele ExpressRoute ya da VPN tarafını daha en başta netleştirmek. On-prem bağlantı sonradan eklenince işler gereksiz uzuyor, açık konuşayım.
3. NFS tuning: Yukarıda anlattığım nconnect ve diğer parametreler için önce bir client baseline çıkarın. Böylece “bu ayar neyi bozdu?” diye ortada kalmıyorsunuz, ki bu soru beklediğinizden sık geliyor. (bu kritik)
4. Snapshot stratejisi: EDA projelerinde “ben yanlışlıkla rm -rf yaptım” hikâyesi neredeyse klasikleşmiş durumda. Snapshot policy’yi en başta kurun; sonra dönüp bakınca keşke dememek için iyi bir sigorta oluyor.
5. Maliyet izleme: Azure Cost Management’ta ANF için ayrı bir tag ve budget oluşturun. Capacity pool fiyatlandırması ilk bakışta biraz kafa karıştırabiliyor, hatta insan “bu niye böyle bölünmüş?” diye düşünüyor.

Doğrusu, Peki neden? Çünkü EDA tarafında performans kadar öngörü de önemli. Bir şey hızlı çalışsa bile, maliyet ve ağ tasarımı dağılıyorsa işin tadı kaçıyor.

Hani, Bu konuda hibrit kimlik tarafında Azure Files Entra-Only: AD’siz SMB Devri Başladı yazısı da işinize yarayabilir — özellikle Windows tarafında EDA tooling kullanıyorsanız. Hani bazen konu storage oluyor ama kapıdan kimlik giriyor ya, işte tam o noktada bu yazı baya işe yarıyor (bizzat test ettim)

Şimdi gelelim işin can alıcı noktasına.

Açık konuşayım, Evet.

Eleştirim: Eksik Bulduğum Yanlar

Bakın, Yazıyı dönüp dolaşıp “Azure süper, ANF muhteşem” diye kapatmak istemem. Çünkü açık konuşayım, öyle değil.

Şu eksikler hâlâ masada duruyor:

• Bölge sınırlaması: ANF her Azure bölgesinde yok. Türkiye’ye yakın sayılabilecek bazı bölgeler hâlâ “large volumes breakthrough” modunu desteklemiyor, bu da insanı biraz ters köşeye yatırıyor; North Europe ve West Europe tarafı işe daha oturmuş durumda. (bence en önemlisi)
• Capacity pool minimumu: 4 TB minimum capacity, küçük testler için biraz fazla kaçıyor. Hani lab ortamında iki dosya atıp deneyeyim diyorsun, olmuyor; Microsoft burada biraz daha esnek davranabilse fena olmazdı.
• Multi-protocol senaryolarda quirk’ler: Aynı volume’u hem NFS hem SMB üzerinden açtığınızda, nadir de olsa lock davranışlarında tuhaflıklar görebiliyorsunuz. Çözülüyor, evet, ama uğraştırıyor işte.
• Belgeleme: EDA odaklı tuning kılavuzları yeterince derin değil. Cadence/Synopsys tarafındaki özel best practice dokümanları da ekosistemde dağınık kalmış durumda, nasıl desem, arayıp buluyorsun ama tek yerde toplanmış hissettirmiyor. — bunu es geçmeyin

Yani kötü değil. Ama kusursuz da değil. Bence doğru yöne atılmış sağlam bir adım var burada, yalnız hâlâ olgunlaşması gereken birkaç nokta gözümden kaçmıyor.

Açıkçası, Peki neden?

Garip gelecek ama, Çünkü gerçek kullanımda iş sadece performansla bitmiyor; bölge erişimi, kapasite eşiği, protokol davranışı. Dokümantasyon birlikte düşünülünce tablo biraz değişiyor. Tam da öyle.

Sıkça Sorulan Sorular

Azure NetApp Files ile on-prem NetApp arasında performans farkı var mı?

Sahada bizzat gördüğüm kadarıyla: large volumes breakthrough mode devreye girince, orta segment on-prem NetApp filer’larla aynı performansı, hatta bazı senaryolarda daha fazlasını alıyorsunuz. Yani makas ciddi anlamda daraldı. High-end FAS/AFF sistemleriyle kıyaslarsanız özel iş yüklerinde on-prem hâlâ önde olabilir, bence bu gayet normal.

ANF için minimum bütçe ne kadar?

4 TB’lık minimum capacity pool ile başlarsanız Premium tier’da aylık 800-1000 USD civarı bir başlangıç maliyetiyle giriş yapabilirsiniz. Standard tier daha ucuz tabii, ama EDA için açıkçası Premium ya da Ultra öneririm. Ciddi EDA işleri düşünüyorsanız aylık 10K USD altını pek hesaba katmayın.

EDA tool vendor’ları ANF’yi destekliyor mu?

Vallahi, Cadence ve Synopsys, NFS shared storage üzerinde çalışan araçlarının tamamını ANF’de destekliyor. Ayrıca ekstra bir sertifikasyon gerekmiyor, hani protokol seviyesinde standart NFS olduğu için bu zaten beklenen bir şey. Bazı tool’ların performans tavsiyeleri var, onlara da bir göz atmakta fayda var.

Durun, bir saniye.

SnapMirror ile on-prem’den ANF’ye geçiş ne kadar sürer?

Veri büyüklüğüne ve hat kapasitesine bağlı değişiyor. Mesela 100 TB için 10 Gbps ExpressRoute üzerinden ilk full sync 1-2 gün sürer, incremental sync’ler işe dakikalar mertebesinde kalıyor. Asıl planlamanız gereken şey cutover anındaki delta sync penceresi, tecrübeme göre orası çoğu zaman gözden kaçıyor.

EDA dışında ANF hangi workload’lar için uygun?

SAP HANA, Oracle DB, yüksek performanslı AI/ML training storage, healthcare imaging… Yani aslında POSIX-compliant shared storage isteyen tüm enterprise workload’lar için gayet iyi bir seçenek. Ama bence en parlak olduğu yer, latency-sensitive shared file system gerektiren senaryolar.

Kaynaklar ve İleri Okuma

Açıkçası, Azure NetApp Files for EDA workloads: From revolution to breakthrough at scale (Microsoft Blog)

İtiraf edeyim, Azure NetApp Files Resmî Dokümantasyonu

İşte, bunu yaşayan biri olarak söyleyeyim, ANF Large Volumes: Gereksinimler ve Dikkat Edilecekler

NetApp EDA on Azure Solution Brief

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Microsoft Foundry Fine-Tuning Nisan 2026: RFT'de Yenilikler18 Nis 2026

Copilot Student'tan GPT-5.3-Codex Çıktı: Ne Anlama Geliyor?27 Nis 2026

Azure Files Entra-Only: AD'siz SMB Devri Başladı20 May 2026

Bir GitHub Projesinin Son %1’i: Sürümü Sağlam Kapatmak11 Nis 2026