Bir önceki makalede Azure Local’ın Azure Stack HCI’dan nasıl daha geniş bir platforma dönüştüğünü anlatmıştım. Azure Local ile beraber artık sadece klasik anlamda bir HCI çözümünden bahsetmiyoruz. Microsoft’un Nisan 2026’da güncellediği dokümantasyona baktığımızda tek sunucudan yüzlerce sunucuya kadar farklı ölçeklerde hyperconverged, disaggregated, multi-rack ve disconnected deployment modelleri bulunuyor. Bunların yanına bir de özellikle edge senaryoları için geliştirilen Small Form Factor yapısı eklenmiş durumda.
Bence burada dikkat edilmesi gereken nokta şu: Azure Local projesine “kaç node alacağız?” sorusuyla başlamak artık yeterli değil. Önce workload’un ne olduğunu, compute ve storage’ın nasıl büyüyeceğini, sistemin nerede çalışacağını ve Azure bağlantısının olup olmayacağını anlamak gerekiyor. Bunları belirledikten sonra mimari zaten büyük ölçüde ortaya çıkıyor.
Sahada yıllardır HCI projelerinde gördüğümüz klasik bir durum var. Müşterinin 100 TB storage ihtiyacı ve nispeten düşük compute ihtiyacı oluyor ancak HCI mimarisinde kapasiteyi büyütmek için yeni node eklemek zorunda kalabiliyorsunuz. Başka bir müşteride ise tam tersi, storage yeterli ama CPU ve memory ihtiyacı çok hızlı artıyor. Azure Local’ın bugün sunduğu farklı deployment seçenekleri tam olarak bu tür ihtiyaçlara cevap vermeye çalışıyor.
Hyperconverged Azure Local
Çoğumuzun Azure Stack HCI döneminden alışık olduğu mimari hyperconverged model.
Microsoft’un güncel dokümantasyonuna göre Azure Local hyperconverged deployment tek bir fiziksel sunucudan başlayabiliyor ve standart cluster yapısında 16 sunucuya kadar çıkabiliyor. Rack-aware cluster kullanıldığında ise desteklenen üst sınır 8 sunucu. Compute ve storage aynı fiziksel sunucular üzerinde bulunuyor ve storage katmanında Storage Spaces Direct kullanılıyor.
Yani örneğin dört node’lu klasik bir Azure Local yapısı kurduğunuzu düşünelim. Her node üzerinde CPU, memory, network ve lokal diskler bulunuyor. Storage Spaces Direct bu sunuculardaki diskleri ortak bir software-defined storage katmanına dönüştürüyor, Hyper-V ise aynı sunucular üzerindeki compute kaynaklarını kullanıyor.
Bu modelin en büyük avantajı mimarinin nispeten sade olması.
Ayrı bir SAN altyapınız yok. Compute ve storage aynı node’lar içerisinde. Yeni bir node eklediğinizde sisteme aynı anda compute, memory ve storage kapasitesi eklemiş oluyorsunuz.
Ama zaten avantaj olarak söylediğimiz şey bazı projelerde dezavantaja dönüşebiliyor.
Dört node’lu ortamınızda CPU ve memory kullanımınız düşük fakat storage kapasiteniz dolmaya başladıysa sadece storage ihtiyacı için yeni compute node satın almak çok mantıklı olmayabilir. Tam tersine storage tarafında yeterli kapasiteniz varken compute ihtiyacınız arttığında yine node eklemeniz gerekir.
HCI’ın doğası bu.
Bu nedenle benim tavsiyem Azure Local tasarımına başlamadan önce sadece bugünkü VM sayısına bakmamak. Compute ve storage büyüme oranlarını ayrı ayrı çıkarmak gerekiyor. Üç yıl içerisinde storage yüzde 200 büyürken compute yüzde 20 büyüyecekse bunu ilk tasarım aşamasında görmek lazım.
Buna rağmen genel amaçlı sanallaştırma ortamları için hyperconverged Azure Local hala en sade ve mantıklı seçeneklerden biri. Özellikle compute ve storage’ın birbirine yakın oranlarda büyüdüğü yapılarda ayrıca bir SAN katmanı yönetmemek operasyonu ciddi şekilde kolaylaştırıyor.
Bir başka önemli detay ise güncel Azure Local hyperconverged mimarisinde harici SAN’ın tamamen yasak olmaması. Microsoft, desteklenen konfigürasyonlarda hyperconverged cluster’a ilave storage kapasitesi için external SAN bağlanabileceğini de belirtiyor.
Yani HCI seçtik diye hayatımızın sonuna kadar sadece lokal disklere mahkum değiliz.
Disaggregated Azure Local
Disaggregated mimari benim özellikle mevcut SAN yatırımı bulunan kurumsal müşteriler açısından ilginç bulduğum seçeneklerden biri.
Burada compute ve storage birbirinden ayrılıyor.
Hyperconverged yapıda storage node’ların içerisindeki disklerden oluşurken disaggregated Azure Local mimarisinde SAN tabanlı storage kullanılıyor. Microsoft’un Temmuz 2026’da güncellediği dokümantasyona göre bu yapı tek fiziksel sunucudan başlayabiliyor ve 64 fiziksel sunucuya kadar ölçeklenebiliyor.
Bu önemli bir fark.
Örneğin halihazırda ciddi bir enterprise SAN yatırımınız olduğunu düşünelim. Storage kapasiteniz ve performansınız yeterli, hatta önümüzdeki birkaç yıl için yatırımınız yapılmış durumda. Böyle bir müşteriye “Azure Local’a geçiyoruz, mevcut SAN’ı bırakalım ve bütün storage’ı node içerisine tekrar satın alalım” demek ekonomik olarak her zaman doğru olmayabilir.
Disaggregated model burada mevcut storage yatırımlarının değerlendirilmesine imkan veriyor.
Aynı zamanda compute ve storage’ın birbirinden bağımsız büyütülebilmesi de ciddi bir avantaj.
CPU ihtiyacı arttıysa compute ekliyorsunuz.
Storage ihtiyacı arttıysa SAN tarafını büyütüyorsunuz.
Özellikle büyük database ortamları, yüksek kapasiteli veri setleri veya compute/storage büyüme oranlarının birbirinden çok farklı olduğu yapılarda bu model daha mantıklı olabilir. Microsoft da disaggregated yapının compute ve storage kaynaklarının workload ihtiyacına göre bağımsız ölçeklenebilmesini temel kullanım avantajlarından biri olarak gösteriyor.
Tabii ki bunun bir bedeli var.
HCI yapısındaki sadeliği kaybediyorsunuz.
Artık ayrı bir storage fabric, SAN yönetimi, zoning, storage controller, multipathing ve bunların operasyonu var. Araya ne kadar fazla bileşen koyarsanız sorun giderirken kontrol etmeniz gereken katman sayısı da artıyor.
Bu nedenle “SAN daha kurumsaldır, o zaman disaggregated yapalım” şeklinde bir yaklaşımı doğru bulmuyorum.
Eğer dört node’lu standart bir sanallaştırma ortamınız varsa, storage ihtiyacınız çok sıra dışı değilse ve mevcut bir SAN yatırımınız bulunmuyorsa sırf teknik olarak mümkün diye mimariyi karmaşıklaştırmanın çok anlamı yok.
Ama 30-40 compute node’a çıkacak bir ortamdan, ciddi bir SAN yatırımından veya compute ve storage’ın farklı hızlarda büyüdüğü bir altyapıdan bahsediyorsak durum değişiyor.
Azure Local’ın eski Azure Stack HCI yaklaşımından ayrıldığı önemli noktalardan biri de bu zaten. Microsoft artık tek bir HCI topolojisini bütün müşterilere uygulamaya çalışmıyor.
Small Form Factor biraz farklı bir dünya
Small Form Factor Azure Local tarafını klasik veri merkezi mantığıyla değerlendirmemek gerekiyor.
Microsoft bu yapıyı özellikle fiziksel alan, enerji ve soğutma imkanlarının sınırlı olduğu edge ve distributed environment senaryoları için geliştiriyor. Ağustos 2026 itibarıyla Small Form Factor deployment’ların hala Preview olduğunu özellikle belirtmek lazım. Üretim tasarımı yaparken bu detay kesinlikle gözden kaçırılmamalı.
Buradaki mimari klasik Azure Local’dan oldukça farklı.
Öncelikle Linux tabanlı kompakt donanımlardan bahsediyoruz. Docker base image içerisinde geliyor ve Kubernetes tarafında lightweight K3s dağıtımı destekleniyor. Microsoft aynı zamanda Azure IoT Operations ve Foundry Local gibi edge workload’larını da bu platform için doğruluyor.
Yani buraya klasik “şubeye iki Hyper-V node koyayım, üzerinde 20 Windows VM çalıştırayım” gözüyle bakmamak gerekiyor.
Small Form Factor’ın hedefi başka.
Örneğin 500 mağazası bulunan bir perakende şirketini düşünün. Her mağazaya rack tipi iki sunucu, switch, storage ve klasik sanallaştırma altyapısı koymak istemeyebilirsiniz. Ancak mağazada kamera görüntülerini işleyen bir AI uygulaması, IoT verisini toplayan container’lar veya merkezi bağlantı kesildiğinde lokal çalışmaya devam etmesi gereken bir uygulama olabilir.
Benzer senaryoyu üretim tesisinde de görebiliriz.
Fabrikanın üretim hattının yanına klasik veri merkezi altyapısı koymak yerine küçük, enerji tüketimi düşük ve merkezi olarak yönetilebilen bir cihaz üzerinde IoT ve AI workload’larını çalıştırmak çok daha anlamlı olabilir.
Microsoft şu anda ASUS NUC 14 Pro, ASUS NUC 15 Pro, Lenovo ThinkEdge SE30, Lenovo ThinkEdge SE100 ve OnLogic HX521 gibi belirli cihazları bu mimari için doğrulamış durumda.
Burada benim dikkatimi çeken önemli özelliklerden biri de Zero-Touch Provisioning.
Binlerce edge cihazı olan bir yapıda en büyük problem cihazın kendisinden çok operasyonudur. Her lokasyona bir sistem yöneticisi gönderip kurulum yapmak zaten mümkün değil. Microsoft bu nedenle FDO uyumlu supply chain üzerinden Zero-Touch Provisioning modelini kullanıyor. Cihazın merkezi şekilde hazırlanması ve Azure üzerinden yönetilmesi hedefleniyor.
Bu mimarinin Azure Local ailesine dahil edilmesi aslında Microsoft’un Azure Local ile nereye gitmek istediğini de güzel gösteriyor.
Bir tarafta yüzlerce sunuculuk veri merkezi, diğer tarafta mağazanın arka odasında çalışan küçük bir edge cihazı var.
İkisi de Azure Local ailesinin parçası.
Disconnected Azure Local
Disconnected konusu ise fiziksel mimariden biraz farklı.
Hyperconverged veya disaggregated dediğimiz zaman compute ve storage’ın nasıl konumlandırıldığını konuşuyoruz. Disconnected dediğimizde ise control plane’in nerede olduğunu ve sistemin Azure ile nasıl iletişim kurduğunu konuşuyoruz.
Normal connected Azure Local mimarisinde workload ve veri on-premises ortamda kalırken control plane aktiviteleri için Azure ile periyodik bağlantı bulunuyor. Microsoft’a göre connected Azure Local, geçici bağlantı kesintilerinde workload’ları çalıştırmaya devam edebiliyor ve sistemin Azure ile en az 30 günde bir başarılı şekilde senkronize olması gerekiyor.
Ama bazı müşteriler için bu bile mümkün değil.
Savunma sanayi, askeri sistemler, bazı kamu kurumları, kritik altyapılar veya regülasyon nedeniyle internet bağlantısı bulunmayan sistemler buna örnek olabilir.
Disconnected operations tarafında Azure control plane’in gerekli bir bölümü lokal ortama geliyor.
Microsoft’un Haziran 2026’da güncellediği dokümantasyona göre Azure Local disconnected operations ile Azure public cloud bağlantısı olmadan Azure Local instance’ları, VM’ler ve belirli container workload’ları lokal control plane üzerinden yönetilebiliyor. Azure portal benzeri deneyim, ARM, subscription, resource group, RBAC ve Azure CLI gibi alıştığımız Azure kavramlarının bir bölümü lokal ortamda sunuluyor.
Bence buradaki en kritik nokta şu:
Disconnected Azure Local, normal Azure Local kurup sonra internet erişimini kapatmak değil.
Tamamen farklı bir operasyon modeli var.
Local control plane için ayrıca kapasite gerekiyor. Microsoft dedicated management cluster kullanılmasını istiyor ve bu cluster gerekli Azure Local infrastructure component’lerini barındırıyor. Yani sadece workload cluster’larının kapasitesini hesaplamak yeterli değil; management plane’in de ayrıca boyutlandırılması gerekiyor.
Üstelik bütün Azure servisleri disconnected ortamda çalışmıyor.
Microsoft burada özellikle “subset of Azure capabilities” ifadesini kullanıyor. Azure Local VM, Azure Resource Manager, RBAC, managed identity, Arc-enabled servers ve bazı Kubernetes yetenekleri desteklenirken servis desteğinin connected Azure ile bire bir aynı olduğunu varsaymamak gerekiyor.
Bu nedenle disconnected mimariyi “Azure internetsiz de çalışıyor” şeklinde basitleştirmek bana göre yanlış olur.
Daha doğru ifade şu olabilir:
Azure’ın belirli control plane ve platform yeteneklerinin müşteri ortamında lokal olarak çalıştırıldığı, kendi lifecycle ve operasyon gereksinimleri bulunan ayrı bir private cloud modeli.
Üstelik artık sadece bir gelecek vizyonundan bahsetmiyoruz. Disconnected operations, Azure Local 2602 sürümüyle General Availability oldu. Temmuz 2026 tarihli Microsoft dokümanında 2603, 2604 ve 2605 sürümleriyle security, scalability, diagnostics ve BCDR tarafında geliştirmelerin devam ettiği görülüyor. 2604 ile workload cluster tarafında 64 node desteği de eklenmiş durumda.
Bu nedenle özellikle sovereign cloud ihtiyacı bulunan kurumların Azure Local değerlendirmelerinde disconnected model artık ciddi şekilde masada olmalı.
Ama yine altını çizelim: İhtiyacınız yoksa disconnected seçmek bir avantaj değil.
Aksine daha fazla donanım, lokal management plane, farklı update süreci ve daha fazla operasyon demek.
İnternet erişimi olan standart bir kurumsal veri merkezinde “daha güvenli olur” düşüncesiyle disconnected mimari kurmanın bana göre bir anlamı yok. Connected model zaten workload ve veriyi lokal tutuyor, buna karşılık Azure’ın merkezi management ve monitoring servislerinden daha geniş şekilde yararlanmanızı sağlıyor.
Azure Local mimarisi seçerken benim yaklaşımım bu nedenle oldukça basit.
Standart bir veri merkezi ve genel amaçlı VM workload’ları varsa önce hyperconverged yapıya bakarım. Mevcut ve ciddi bir SAN yatırımı varsa veya compute ile storage birbirinden çok farklı büyüyorsa disaggregated mimariyi değerlendiririm. Çok sayıda mağaza, fabrika veya küçük edge lokasyonu ve container/IoT/AI workload’u varsa Small Form Factor ilginç hale geliyor ancak bugün için Preview olduğunu unutmam. Azure public cloud bağlantısının teknik, yasal veya güvenlik nedeniyle mümkün olmadığı gerçek bir gereksinim varsa o zaman disconnected operations gündeme gelir.
Bir de bu dört seçeneğin bütün Azure Local dünyasını kapsamadığını belirtelim. Microsoft artık büyük veri merkezleri için yüzlerce fiziksel sunucuya çıkabilen multi-rack Azure Local mimarisini de sunuyor. Güncel ürün dokümantasyonunda Azure Local’ın tek sunucudan yüzlerce sunucuya kadar uzanan deployment modelleri bulunuyor.
Yani bugün Azure Local projesine başlarken önce donanım listesini çıkarmak yerine workload profilini çıkarmak çok daha doğru.
Kaç VM var?
Ne kadar CPU ve memory tüketiliyor?
Storage ne kadar hızlı büyüyor?
Mevcut SAN yatırımı var mı?
Uygulamalar VM mi, container mı?
AI veya IoT workload’u var mı?
Kaç fiziksel lokasyon yönetilecek?
Azure bağlantısı mümkün mü?
Ve en önemlisi bu altyapının üç-beş yıl sonra nasıl büyümesini bekliyoruz?
Bu soruların cevapları olmadan yapılacak Azure Local sizing çalışması bana göre sadece bugünkü ortamın fotoğrafını çekmek olur. Halbuki altyapı yatırımında önemli olan bugünkü fotoğraftan çok önümüzdeki birkaç yılın büyüme şeklini doğru tahmin etmek.
Bir sonraki makalede tam olarak buradan devam edeceğim. Azure Local kapasite planlamasında CPU, memory, storage, network ve GPU ihtiyaçlarının nasıl hesaplanması gerektiğini, Azure Local Catalog içerisinden donanım seçerken nelere dikkat edilmesi gerektiğini ve işin lisanslama ile TCO tarafını inceleyeceğiz.
Kullandığım temel Microsoft kaynakları: Azure Local Deployment Types and Scalability, Hyperconverged Deployments of Azure Local, Disaggregated Deployments of Azure Local, Small Form Factor Deployments of Azure Local, Disconnected Operations for Azure Local ve Connected Operations for Azure Local. Microsoft’un Small Form Factor dokümanı Ağustos 2026 itibarıyla özelliği halen Preview olarak işaretliyor; disconnected operations ise 2602’den itibaren GA durumda.
