Azure Local Network Deep Dive: Network ATC, RDMA ve Network Intent

Önceki makalede Azure Local deployment öncesinde yapılması gereken hazırlıkları ele almıştık. O yazıda network tasarımının deployment ekranında karar verilecek bir konu olmadığını özellikle belirtmiştim. Bu hafta biraz daha derine inip Azure Local tarafında bence en kritik katmanlardan biri olan network’ü ele alacağım.

Azure Local’ın altında Hyper-V ve Storage Spaces Direct gibi uzun yıllardır bildiğimiz teknolojiler var. Ancak özellikle Storage Spaces Direct kullanan bir yapıda network artık sadece sanal makinelerin dış dünya ile haberleşmesini sağlayan katman değil. Node’lar arasındaki storage trafiği de Ethernet üzerinden akıyor. Bir node üzerindeki disklerde bulunan verinin diğer node’lara mirror edilmesi, repair işlemleri, Live Migration ve VM trafiği aynı fiziksel network altyapısının farklı bölümlerini kullanabiliyor.

Yani network tarafında yaptığınız yanlış bir tasarım sadece “network yavaş” şeklinde karşınıza çıkmayabilir.

Storage performansı düşebilir, Live Migration uzayabilir, rebuild süresi artabilir veya cluster’ın yoğun trafik altında davranışı değişebilir.

Microsoft’un Azure Local için Network ATC’yi bu kadar merkeze koymasının nedenlerinden biri de tam olarak bu.

Network ATC bize ne kazandırıyor?

Network ATC, Microsoft’un Azure Local host networking tarafındaki konfigürasyonu standartlaştırmak ve otomatikleştirmek için kullandığı intent-based network yaklaşımı.

Burada küçük ama ilginç bir bilgi de vereyim: ATC bir kısaltma değil. Microsoft dokümantasyonunda özellikle “Network ATC is the full product name and is not an acronym or abbreviation” diye belirtiyor.

Klasik Hyper-V cluster kurulumlarını hatırlarsanız host network konfigürasyonunda yapılacak oldukça fazla işlem vardı. NIC teaming, vSwitch, VLAN, QoS, RDMA, SMB Multichannel, Live Migration network’ü derken her node üzerinde aynı ayarların yapılması gerekiyordu.

Dört node’da küçük bir konfigürasyon farkı bile ileride çok garip problemlere neden olabiliyordu.

Network ATC’nin yaklaşımı farklı.

Siz tek tek bütün ayarları tarif etmek yerine fiziksel NIC’lerin hangi amaçla kullanılacağını söylüyorsunuz.

Microsoft buna intent diyor.

Örneğin iki fiziksel NIC için:

“Bu adaptörleri Management ve Compute için kullanacağım.”

diğer iki adaptör için:

“Bunlar Storage için kullanılacak.”

diyorsunuz.

Network ATC buna göre gerekli network konfigürasyonunu oluşturuyor.

Microsoft’un güncel dokümantasyonuna göre Network ATC; network adapter özelliklerinden Data Center Bridging ayarlarına, gerekli virtual switch ve virtual adapter’ların oluşturulmasından VLAN atamalarına, storage IP adreslerinden Live Migration ayarlarına kadar birçok konfigürasyonu otomatik olarak yönetebiliyor. Ayrıca cluster node’ları arasındaki network configuration drift’i azaltmak da Network ATC’nin temel amaçlarından biri.

Bence burada en önemli kelime “otomasyon” değil, tutarlılık.

Çünkü dört node’lu bir cluster’da network’ü elle de yapılandırabilirsiniz. Esas problem birinci node ile dördüncü node’un gerçekten bire bir aynı konfigürasyonda kalmasını sağlamak.

Network ATC bunu merkezi olarak yönetmeye çalışıyor.

Network Intent aslında oldukça basit bir kavram

Intent kelimesi ilk duyulduğunda biraz karmaşık geliyor ama mantığı oldukça basit.

Bir fiziksel network adapter’ı hangi trafik için kullanmak istediğimizi tarif ediyoruz.

Azure Local tarafında temel intent türleri Management, Compute ve Storage.

Management intent host’ların yönetim erişimi için kullanılıyor.

Compute intent VM trafiğini fiziksel network’e taşıyor.

Storage intent ise Storage Spaces Direct dahil olmak üzere SMB trafiğini taşıyor.

Microsoft’un Network ATC dokümantasyonunda ayrıca Stretch intent de bulunuyor. Stretch, storage intent’e benzer şekilde yapılandırılıyor ancak RDMA kullanılmıyor.

Bir fiziksel adapter yalnızca bir intent içerisinde yer alabiliyor fakat aynı intent birden fazla trafik türünü içerebiliyor.

Örneğin şöyle bir yapı mümkün:

pNIC01 + pNIC02
Management + Compute

pNIC03 + pNIC04
Storage

Bu Azure Local tarafında oldukça sık göreceğimiz converged management/compute ve dedicated storage tasarımı.

Ama bütün trafik aynı fiziksel NIC’ler üzerinden de taşınabilir.

Microsoft’un iki node fully converged reference pattern’ında iki fiziksel NIC üzerinde Management + Compute + Storage tek bir intent olarak tanımlanabiliyor. Network ATC bu durumda storage için iki ayrı vNIC oluşturuyor; varsayılan olarak VLAN 711 ve 712 kullanılıyor ve SMB Multichannel resiliency ile bandwidth aggregation sağlıyor.

Yani “Azure Local için mutlaka altı veya sekiz fiziksel network portu gerekiyor” gibi genel bir kural yok.

Doğru port sayısı seçtiğiniz topolojiye bağlı.

Ama burada benim yaklaşımım şu olur: Fiziksel port sayısını mümkün olduğunca azaltmak her zaman iyi mimari anlamına gelmez.

İki tane 25GbE portunuz var diye management, VM, Live Migration ve storage trafiğinin tamamını bu portlardan geçirmek teknik olarak mümkün olabilir. Ancak workload karakteristiğini bilmeden bunu yapmak doğru değil.

Yoğun VM trafiği, büyük Live Migration operasyonları ve Storage Spaces Direct replication aynı anda gerçekleştiğinde bu trafiğin nasıl davranacağını daha tasarım aşamasında düşünmek gerekiyor.

NIC symmetry konusu gerçekten önemli

Network ATC’nin önemli gereksinimlerinden biri adapter symmetry.

Aynı intent içerisinde kullanılan network adapter’ların bütün cluster node’larında aynı üretici, model, hız ve konfigürasyonda olması gerekiyor. Ayrıca fiziksel adapter isimlerinin de bütün node’larda aynı olması bekleniyor. Network ATC intent’i deploy etmeden önce bu simetriyi otomatik olarak kontrol ediyor ve asimetrik adapter kullanımı deployment’ın başarısız olmasına neden oluyor.

Bu nedenle dört Azure Local sunucusu sipariş ederken “hepsinde iki tane 25GbE kart var” demek yeterli değil.

Exact NIC modeli önemli.

Firmware önemli.

Driver önemli.

Port isimlendirmesi önemli.

Hatta Microsoft aynı adapter’ların her host üzerinde aynı PCI slot’larına takılmasını da öneriyor. Böylece otomatik adapter naming işlemlerinde tutarlılık sağlanıyor.

Bu küçük görünen detaylar özellikle farklı tarihlerde node eklenen ortamlarda karşımıza çıkabiliyor.

İlk dört sunucuyu bugün aldınız, iki yıl sonra aynı cluster’a iki node daha eklemek istiyorsunuz. Sunucu modeli hala satılıyor olabilir ama aynı NIC artık satılmıyor olabilir.

Bu nedenle Azure Local’ın üç-beş yıllık kapasite planlamasını yaparken sadece CPU ve memory büyümesini değil, hardware generation değişimini de düşünmek gerekiyor.

Storage network neden bu kadar önemli?

Storage Spaces Direct mimarisinde node’ların birbirlerinin disklerine erişmesi gerekiyor.

Bu iletişim SMB üzerinden gerçekleşiyor ve Azure Local storage network’ünde SMB Direct yani RDMA kullanılıyor. SMB Multichannel ise birden fazla network yolunu kullanarak hem bandwidth aggregation hem de resiliency sağlıyor.

Örneğin dört node’lu bir sistemde bir node kaybettiğinizi düşünün.

Cluster üzerindeki workload’lar kalan node’lara geçerken Storage Spaces Direct de verinin resiliency durumunu kontrol edecek ve gerektiğinde repair işlemleri başlayacak.

Bu sırada ciddi miktarda east-west storage trafiği oluşabilir.

Network tasarımını sadece normal çalışma yüküne göre yaptıysanız asıl problemi tam da sistem zaten problem yaşarken görürsünüz.

Ben infrastructure tasarımında bu nedenle hep arıza anını düşünmeyi daha doğru buluyorum.

Normal durumda herkes hızlı.

Bir node kapalıyken, storage repair çalışırken ve aynı anda VM’ler diğer node’lara taşınırken sistem nasıl davranıyor?

Asıl tasarım testi bence bu.

RDMA burada devreye giriyor

RDMA yani Remote Direct Memory Access, bir sistemin diğer sistemin memory’sine CPU’yu ve klasik network stack’ini mümkün olduğunca az kullanarak doğrudan veri aktarabilmesini sağlıyor.

Azure Local storage network’ünde bunun bize sağladığı temel avantaj düşük latency, yüksek throughput ve düşük CPU tüketimi.

Microsoft Azure Local için iki Ethernet tabanlı RDMA protokolünü destekliyor:

RoCE ve iWARP.

InfiniBand ise Azure Local için desteklenmiyor. Ayrıca iki RDMA adapter’ın birbiriyle haberleşebilmesi için aynı RDMA protokolünü kullanması gerekiyor. Yani bir tarafta iWARP, diğer tarafta RoCE kullanıp bunları RDMA üzerinden konuşturamazsınız.

Peki RoCE ile iWARP arasındaki fark ne?

Burada biraz network tarafına girmemiz gerekiyor.

iWARP TCP tabanlı çalışıyor. Microsoft dokümantasyonuna göre PFC ve Enhanced Transmission Service ile geliştirilebiliyor ancak temel yapısı TCP üzerinde.

RoCE tarafında ise özellikle RoCE v2 kullanıldığında lossless Ethernet fabric tasarımı önem kazanıyor. Microsoft’un Azure Local host network gereksinimlerinde RoCE implementasyonları için fabric ve host boyunca üç traffic class tanımlanması gerekiyor. RDMA traffic class için PFC aktif ve yüzde 50 bandwidth reservation öneriliyor. System traffic için ayrı bir class bulunuyor ve PFC kullanılmıyor.

Burada PFC yani Priority Flow Control kritik.

RoCE kullandığınız switched storage tasarımında sadece server tarafındaki NIC’leri doğru ayarlamak yeterli değil. ToR switch’lerin de gerekli Data Center Bridging konfigürasyonuna sahip olması gerekiyor.

Microsoft’un güncel baseline architecture dokümanında multi-node switched storage deployment için switch’lerin VLAN, MTU ve DCB konfigürasyonlarının deployment öncesinde hazırlanması gerektiği belirtiliyor. Aynı mimaride RoCE v2 veya iWARP üzerinden RDMA kullanılıyor ve switched storage network için IEEE 802.1Qbb PFC desteği isteniyor.

İşte Azure Local projelerinde network ekibiyle altyapı ekibinin beraber çalışması gereken noktalardan biri tam burası.

Sunucunun üzerinde Enable-NetAdapterRdma çalıştırmakla RDMA projesi bitmiyor.

Switch konfigürasyonu yanlışsa çok daha ilginç problemler yaşayabilirsiniz.

RoCE mi iWARP mı?

Bu soru yıllardır Storage Spaces Direct projelerinde soruluyor.

Bana göre burada “hangisi daha iyi?” diye genel bir cevap vermek doğru değil.

Microsoft’un güncel destek matrisinde Broadcom RoCE, Nvidia RoCE; Marvell hem iWARP hem RoCE, bazı Intel adapter’lar ise her iki protokolü destekleyebiliyor. Dolayısıyla ilk karar aslında Azure Local Catalog içerisinde seçtiğiniz donanım ve OEM tasarımıyla beraber geliyor.

Eğer OEM’in validated Azure Local çözümü belirli NIC, switch ve RoCE konfigürasyonuyla geliyorsa benim gidip bunu keyfi olarak değiştirmemin çok anlamı yok.

Özellikle Azure Local gibi hardware/software lifecycle’ın beraber yönetildiği bir üründe validated tasarıma mümkün olduğunca yakın kalmayı tercih ederim.

iWARP’ın TCP tabanlı olması network tarafındaki bazı DCB gereksinimlerini daha basit hale getirebilir. RoCE ise doğru tasarlanmış bir lossless fabric üzerinde son derece yüksek performans sağlayabilir.

Ama burada teorik benchmark’tan çok operasyonel gerçeklik önemli.

Network ekibiniz RoCE/PFC/DCB konusunda tecrübeli mi?

Mevcut switch’leriniz gereken özellikleri destekliyor mu?

OEM’in validated architecture’ı ne öneriyor?

Bu üç sorunun cevabı bana göre sentetik performans testinden daha değerli.

Switchless storage gerçekten güzel bir seçenek

Özellikle iki ve üç node Azure Local projelerinde benim sevdiğim tasarımlardan biri storage switchless mimari.

Burada storage NIC’leri ToR switch’e bağlamak yerine node’ları doğrudan birbirine bağlıyoruz.

Management ve compute trafiği yine ToR switch’lerden geçiyor ancak east-west storage trafiği fiziksel olarak node’lar arasındaki direct Ethernet bağlantılarından akıyor.

Bunun çok güzel bir avantajı var.

Storage switch konfigürasyonunu ortadan kaldırıyorsunuz.

Microsoft’un switchless reference architecture dokümanında bu yapıda storage trafiği switch üzerinden geçmediği için QoS, PFC ve ECN gibi lossless RDMA konfigürasyonlarının network switch üzerinde yapılmasına gerek olmadığı belirtiliyor. Bu hem RoCE v2 hem de iWARP için storage fabric tarafını ciddi şekilde sadeleştiriyor.

Ama bedava değil.

Üç node switchless yapıda her node için toplam altı network portu gerekiyor: storage için dört RDMA-capable port, management ve compute için iki port.

Dört node dual-link switchless yapıda ise node başına sekiz network adapter portuna çıkıyoruz; altı port storage intent, iki port management/compute için kullanılıyor.

Bir de daha önemli sınır var.

Switchless storage Azure Local mimarisinde maksimum dört node destekleniyor.

Üstelik dört node’a geldikten sonra beşinci node’u ekleyip switched yapıya otomatik büyüyemiyorsunuz. Microsoft bu nedenle switchless mimaride gelecek kapasite ihtiyacının daha deployment öncesinde hesaplanmasını özellikle öneriyor.

Bu nedenle bugün iki node yeter ama iki yıl sonra altı node olma ihtimaliniz yüksekse sırf iki switch portundan tasarruf etmek için switchless başlamak çok doğru olmayabilir.

Yine aynı noktaya geliyoruz: network mimarisi kapasite planlamasından bağımsız değil.

Storage VLAN’ları ve IP adresleri

Network ATC storage intent oluşturulduğunda varsayılan olarak storage network’lerini de yapılandırabiliyor.

Microsoft’un iki node switchless reference pattern’ında varsayılan yapı şöyle:

Storage Network 1
VLAN: 711
Subnet: 10.71.1.0/24

Storage Network 2
VLAN: 712
Subnet: 10.71.2.0/24

Bu iki storage NIC SMB Multichannel ile beraber kullanılıyor.

Tabii ki bunlar Microsoft’un default değerleri.

Kendi network standardınıza göre VLAN ve subnet’leri değiştirebilirsiniz. Network ATC bunun için override mekanizması sunuyor.

Burada dikkat edilmesi gereken önemli nokta storage network’lerinin east-west cluster trafiği için kullanılması.

Microsoft reference architecture’larında storage intent adapter’larında default gateway bulunmuyor.

Bu da aslında tasarım mantığını çok güzel gösteriyor.

Storage trafiğinin corporate LAN üzerinde dolaşmasını istemiyoruz.

Node’ların kendi aralarındaki yüksek hızlı veri yolu olarak kullanıyoruz.

Management ve Compute’u birleştirmek mantıklı mı?

Çoğu Azure Local tasarımında Management ve Compute aynı fiziksel NIC’ler üzerinde converged olarak kullanılabiliyor.

Network ATC burada Switch Embedded Teaming yani SET kullanıyor. Management için oluşturulan virtual interface host’un dış dünya ve Azure control plane ile iletişimini sağlarken VM network’leri aynı fiziksel adapter’lar üzerinden logical network ve VLAN’lar aracılığıyla taşınabiliyor.

Bu bana göre çoğu ortamda mantıklı.

Her trafik türü için ayrı iki fiziksel NIC ayırmaya kalkarsanız çok hızlı şekilde 8-10 portlu sunuculara ulaşıyorsunuz.

Ama yine workload’a bakmak gerekiyor.

Network yoğun NFV workload’ları, yüksek trafik üreten appliance VM’leri veya çok sayıda VM’nin aynı anda ciddi east-west/north-south trafik ürettiği ortamlar varsa compute network için ayrı kapasite düşünmek gerekebilir.

Network ATC’nin güzel tarafı burada farklı intent kombinasyonlarına izin vermesi.

Yani Microsoft bize tek bir fiziksel topolojiyi zorlamıyor.

Ama hangi topolojiyi seçersek seçelim Network ATC ile bunu bütün node’larda aynı şekilde uygulamaya çalışıyor.

Live Migration’ı da Network ATC yönetiyor

Network ATC’nin az konuşulan ama bence faydalı özelliklerinden biri Live Migration ayarlarını da yönetebilmesi.

Microsoft’un güncel dokümantasyonuna göre Network ATC işletim sistemi sürümüne göre önerilen Live Migration konfigürasyonlarını uyguluyor. Buna aynı anda gerçekleştirilebilecek maksimum Live Migration sayısı, kullanılacak network, transport yöntemi ve Live Migration’ın kullanabileceği maksimum SMB Direct bandwidth miktarı dahil. İstenirse bu değerler override edilebiliyor.

Bu önemli çünkü Live Migration ciddi miktarda network bandwidth tüketebilir.

Örneğin 512 GB RAM kullanan bir VM’yi node’lar arasında taşırken bu trafiğin storage replication ile aynı anda network’ü tüketmesini istemeyebilirsiniz.

Network ATC burada bandwidth management tarafını da standardize ediyor.

Yine “default her zaman doğrudur” demiyorum.

Çok özel workload’larınız varsa override gerekebilir.

Ama önce Microsoft’un validated default’uyla başlamak, gerçekten ihtiyacınız varsa değiştirmek bana göre çok daha sağlıklı.

Azure Local network tasarımında genel yaklaşımım da aslında bu.

Önce OEM ve Microsoft’un validated reference architecture’ına mümkün olduğunca yakın bir yapı kurarım. Network ATC’nin default’larını kullanırım. Gerçek bir teknik gereksinim ortaya çıkarsa override ederim.

Tam tersini, yani ilk günden bütün default’ları değiştirip eski Hyper-V cluster’ımızdaki network tasarımını bire bir Azure Local’a taşımayı doğru bulmuyorum.

Azure Local sadece yeni isim verilmiş eski Hyper-V cluster değil. Network lifecycle ve configuration management modeli de değişmiş durumda.

Özellikle Network ATC’nin configuration drift’i engelleme yaklaşımı burada önemli.

Bir node üzerinde manuel değişiklik yapıp problemi çözdüğünüzü düşünürken aslında cluster node’ları arasındaki standardı bozabilirsiniz. Bu nedenle troubleshooting sırasında bile “bu ayarı elle değiştirirsem Network ATC bunu nasıl değerlendirecek?” sorusunu sormak gerekiyor.

Özetle Azure Local network tasarımında benim için dört temel konu var: fiziksel NIC ve switch tasarımı, doğru intent modeli, RDMA ve storage trafiğinin doğru yapılandırılması ve bütün node’larda aynı konfigürasyonun korunması.

Network ATC sonuncusunu bizim adımıza ciddi şekilde kolaylaştırıyor ama kötü fiziksel tasarımı düzeltemez.

İki adet yanlış seçilmiş NIC’i Network ATC’ye verirseniz elinizde otomatik yapılandırılmış kötü bir network olur.

Bu nedenle Azure Local Catalog, OEM network guide, switch compatibility, NIC firmware ve fiziksel topoloji hala projenin en önemli parçaları.

Bir sonraki makalede network üzerinden taşıdığımız verinin kendisine geçeceğim. Storage Spaces Direct’ın Azure Local içerisindeki yapısını, disklerin storage pool’a nasıl katıldığını, mirror ve resiliency modellerini, node veya disk kaybında repair işlemlerini ve özellikle kullanılabilir kapasite hesabında neden fiziksel disk toplamına bakmanın yeterli olmadığını detaylı olarak inceleyeceğiz.

Kullandığım temel Microsoft kaynakları: Network ATC Overview, Deploy Host Networking with Network ATC, Azure Local Host Network Requirements, Azure Local Baseline Reference Architecture, Azure Local Storage Switchless Architecture ve Two-Node Storage Switchless Reference Pattern. Network ATC dokümanı 26 Haziran 2026,