Bir önceki makalede Azure Local tarafındaki hyperconverged, disaggregated, Small Form Factor ve disconnected mimarileri incelemiştik. Mimariyi seçtikten sonra işin belki de en kritik kısmına geliyoruz: Bu sistemi hangi donanımla ve ne kadar kapasiteyle kuracağız?
Azure Local projelerinde benim özellikle dikkat ettiğim konulardan biri sizing. Çünkü burada yapılan hata genellikle iki şekilde karşımıza çıkıyor. Ya sistem gereğinden fazla büyük tasarlanıyor ve müşteri yıllarca kullanmayacağı CPU, memory ve storage için para ödüyor ya da mevcut ortamın bire bir fotoğrafı çekilip büyüme ve arıza senaryoları hesaba katılmadığı için birkaç yıl sonra kapasite problemi yaşanıyor.
Microsoft da Azure Local için workload kapasitesinin tasarım aşamasında doğru planlanmasını Well-Architected Framework içerisinde özellikle vurguluyor ve Azure Local Sizer aracının kullanılmasını öneriyor. Buradaki önemli nokta sadece toplam vCPU, memory ve storage ihtiyacını hesaplamak değil; yüksek erişilebilirlik isteniyorsa node kaybından sonra kalan sistemin workload’u taşıyıp taşıyamayacağını da hesaba katmak. Microsoft HA VM’ler için minimum N+1, kritik iş yüklerinde ise dayanıklılığın öncelikli olduğu durumlarda N+2 kapasitenin değerlendirilmesini öneriyor.
Örneğin dört node’lu bir Azure Local ortamınız olduğunu ve normal çalışma sırasında her node’un yüzde 75 CPU ve memory kullandığını düşünelim. Kağıt üzerinde hala yüzde 25 boş kapasiteniz var ve sistem gayet sağlıklı görünüyor.
Ama node’lardan biri bakım veya arıza nedeniyle devre dışı kaldığında işler değişiyor.
Dört node’un workload’unu artık üç node taşımak zorunda. Eğer tasarım sırasında bunu düşünmediyseniz teknik olarak cluster çalışmaya devam eder ancak kalan node’larda yeterli CPU veya memory olmadığı için sanal makinelerin tamamını istediğiniz şekilde çalıştıramayabilirsiniz.
Yani yüzde 25 boş kapasite her zaman yüzde 25 gerçek yedek kapasite anlamına gelmiyor.
Bu nedenle Azure Local sizing çalışmasına “kaç VM var?” sorusuyla başlayıp orada bırakmamak gerekiyor.
Önce mevcut workload’u doğru ölçmek gerekiyor
Yeni bir Azure Local ortamı tasarlarken ilk görmek istediğim bilgiler VM sayısı, toplam vCPU, kullanılan memory ve storage miktarı olur. Ancak bunlar tek başına yeterli değil.
Örneğin 100 sanal makineniz olduğunu ve bunlara toplam 800 vCPU atanmış olduğunu düşünelim. Bu bilgi bize fiziksel olarak 800 CPU core gerektiğini söylemez.
Gerçekte bakılması gereken CPU utilization.
VM’ye sekiz vCPU verilmiş ama yıllardır ortalama yüzde 5 CPU kullanıyorsa bu VM’yi sekiz fiziksel core tüketiyormuş gibi hesaba katmak doğru olmaz. Aynı şekilde 32 GB RAM atanmış ancak gerçekten 28-30 GB kullanan bir SQL Server ile 32 GB atanmış ama 6 GB kullanan bir application server’ı aynı değerlendiremeyiz.
Bu nedenle sizing çalışmasında mümkünse birkaç günlük snapshot yerine anlamlı bir zaman aralığındaki kullanım verisine bakmak gerekiyor.
Özellikle aylık batch işlemleri, ay sonu raporlamaları, backup pencereleri veya belirli dönemlerde yükü artan uygulamalar varsa bunların peak değerleri mutlaka görülmeli.
Microsoft Azure Local Sizer aracını tam olarak bu planlama aşaması için sunuyor. Hyperconverged ve disaggregated Azure Local dokümantasyonunda da donanım gereksinimlerini tahmin etmek için sizing tool kullanılması öneriliyor.
Ben yine de sizing aracına veriyi vermeden önce mevcut ortamın temizlenmesini tavsiye ederim.
Çünkü kötü sizing verisini iyi bir hesaplama aracına verdiğinizde sonuç yine kötü olur.
Örneğin yıllar içerisinde VM’lere gereksiz yere verilmiş vCPU ve RAM değerlerini olduğu gibi yeni ortama taşırsanız aslında eski ortamınızdaki overprovisioning problemini yeni donanıma da taşımış olursunuz.
Bu nedenle migration ile beraber right-sizing yapmak ciddi maliyet avantajı sağlayabilir.
CPU ve memory tarafında sadece bugünü hesaplamayın
Azure Local donanım gereksinimlerinde Microsoft hyperconverged sistemler için minimum 32 GB ECC memory istiyor. CPU tarafında 64-bit Intel veya AMD EPYC sınıfı, SLAT destekleyen işlemciler gerekiyor. Güncel sistem gereksinimlerinde host başına maksimum 512 logical processor, 24 TB RAM ve 2.048 virtual processor destekleniyor.
Bunlar tabii ki platform limitleri. Gerçek bir üretim sisteminin 32 GB RAM ile kurulacağını düşünmüyoruz.
Asıl konu fiziksel CPU ve memory’nin workload’a göre dengeli seçilmesi.
Örneğin 100 VM’lik bir ortamda toplam 2 TB aktif memory kullanımı varsa ve dört node planlıyorsanız basit şekilde “node başına 512 GB yeter” diyemezsiniz. Çünkü node kaybettiğiniz anda üç node’un toplam kullanılabilir memory’si workload’u taşımak zorunda.
Buna host operating system, Azure Local infrastructure servisleri ve büyüme payı da eklenecek.
Aynı mantık CPU için de geçerli.
Burada ayrıca lisans maliyeti devreye giriyor. Azure Local host service ücretlendirmesi fiziksel core üzerinden yapıldığı için gereksiz yere çok yüksek core sayısına sahip CPU seçmek sadece donanım maliyetini değil, kullandığınız lisanslama modeline bağlı olarak yazılım maliyetini de etkileyebilir. Microsoft, Azure Local hizmet ücretini sistem üzerindeki fiziksel processor core sayısına göre hesaplıyor; multithreading bu sayıma dahil edilmiyor.
Yani 32 core’lu iki CPU bulunan dört node’lu bir sistem ile 16 core’lu iki CPU bulunan dört node’lu sistemin sadece işlemci satın alma maliyeti farklı değil.
Azure Local tarafındaki lisanslama hesabı da değişiyor.
Bu nedenle “en güçlü CPU’yu alalım, ileride lazım olur” yaklaşımı Azure Local’da her zaman ekonomik bir yaklaşım değil.
Özellikle yüksek frekanslı daha az core ile düşük frekanslı çok core arasında seçim yaparken workload karakteristiğine ve lisans maliyetine beraber bakmak gerekiyor.
SQL Server gibi core bazlı lisanslanan ürünleriniz varsa bu hesap daha da önemli hale geliyor.
Storage hesabı en çok hata yapılan yerlerden biri
Storage Spaces Direct kullanan hyperconverged Azure Local yapılarında fiziksel disk kapasitesi ile VM’lerin kullanabileceği efektif kapasite aynı şey değil.
Bu çok temel bir bilgi olmasına rağmen sizing çalışmalarında hala karşımıza çıkıyor.
Örneğin dört node üzerinde toplam 100 TB fiziksel disk bulunması VM’lere 100 TB alan verebileceğiniz anlamına gelmiyor.
Resiliency modeliniz, mirror veya parity kullanımı, metadata, repair işlemleri için gerekli boş alan ve büyüme payı efektif kapasiteyi değiştiriyor.
Üstelik storage pool’u yüzde 95 seviyesinde çalıştırmak da iyi bir tasarım değil.
Azure Local Health Service tarafında volume capacity için varsayılan warning threshold yüzde 80, critical threshold ise yüzde 90 olarak tanımlanmış durumda. Storage pool için de reserve capacity kontrolü bulunuyor.
Bunun operasyonel karşılığı önemli.
Bir disk veya node kaybettiğinizde sistemin veriyi yeniden dağıtabilmesi ve repair işlemini tamamlayabilmesi için boş kapasite gerekiyor. Storage’ı son TB’a kadar VM’lere dağıtırsanız arıza anında sistemin hareket alanını ortadan kaldırmış olursunuz.
Ben bu nedenle storage sizing yaparken üç farklı değeri ayrı ayrı görmek isterim:
Mevcut kullanılan kapasite, beklenen büyüme ve resiliency/operasyon için bırakılacak alan.
Özellikle iki veya üç yıllık kapasite planı yapılıyorsa storage büyüme oranını geçmiş birkaç yıldaki gerçek veriden çıkarmak çok daha sağlıklı olur.
Bugün 50 TB kullanan bir müşterinin üç yıl sonra ne kadar storage kullanacağını bilmeden 60 TB efektif kapasite tasarlamak bana göre sizing değil, tahmin olur.
Donanım seçerken sadece teknik özelliklere bakmayın
Azure Local’ın klasik Windows Server Hyper-V’den ayrıldığı önemli noktalardan biri hardware validation modeli.
Microsoft, Azure Local’ın Azure Local Catalog içerisinde bulunan validated hardware üzerinde çalıştırılmasını istiyor. Hyperconverged Azure Local dokümantasyonunda da donanımın Microsoft hardware partner’larından temin edilen validated hardware olması gerektiği açıkça belirtiliyor.
Catalog içerisinde farklı çözüm sınıflarıyla karşılaşıyoruz. Bunların arasında Validated Nodes, Integrated Systems ve Premier Solutions bulunuyor.
Burada kağıt üzerindeki CPU, RAM ve disk değerleri aynı olsa bile operasyon deneyimi aynı olmayabilir.
Özellikle Solution Builder Extension yani SBE benim donanım seçiminde bakacağım ilk konulardan biri olur.
Microsoft, Azure Local 2311.2’den sonra kataloğa eklenen yeni Integrated Systems ve Premier Solution donanımlarında firmware ve driver güncellemelerini destekleyen SBE bulunmasını şart koşuyor ve update-at-scale yeteneklerinden tam olarak yararlanmak için daha yeni Integrated Systems veya Premier Solutions kullanılmasını öneriyor.
Bunun sahadaki karşılığı oldukça basit.
Azure Local sadece Microsoft işletim sisteminden oluşmuyor.
BIOS var.
NIC firmware var.
Storage controller firmware var.
Disk firmware var.
Driver’lar var.
OEM’e özel bileşenler var.
Microsoft işletim sistemi update’i ile OEM firmware ve driver kombinasyonunun birlikte desteklenmesi gerekiyor.
SBE destekleyen modern bir çözümde bu lifecycle daha entegre yönetilebiliyor. SBE desteği olmayan bazı eski veya Validated Node çözümlerinde ise hardware update sürecini ayrıca OEM prosedürlerine göre yürütmeniz gerekebilir.
Bu yüzden Azure Local donanım tekliflerini karşılaştırırken sadece şu tabloya bakmayın:
“Dell 2 TB RAM veriyor, HPE 2 TB RAM veriyor, Lenovo da 2 TB veriyor; hangisi ucuzsa onu alalım.”
Ben mutlaka şu soruyu da sorarım:
Bu exact model ve konfigürasyon için Azure Local’ın güncel release’iyle uyumlu SBE var mı ve firmware/driver lifecycle nasıl yönetiliyor?
Çünkü sunucuyu bir kere satın alıyorsunuz ama yıllarca update ediyorsunuz.
Microsoft ayrıca Premier Solutions, Integrated Systems ve Validated Nodes kategorilerindeki Azure Local çözüm üreticilerinin en az beş yıl hardware service, support ve security update sağlamasını istediğini belirtiyor.
Donanımın sadece bugünkü benchmark sonucuna değil, üç-beş yıllık lifecycle’ına bakmak bu nedenle daha doğru.
Lisanslama tarafında L1, L2 ve L3 ayrımı önemli
Azure Local lisanslaması 2026 itibarıyla mimari seçimiyle daha doğrudan ilişkili hale gelmiş durumda.
Microsoft Azure Local host service ücretini fiziksel core başına aylık olarak hesaplıyor. Ancak artık üç farklı deployment seviyesi bulunuyor.
L1, external storage kullanmayan hyperconverged Azure Local.
L2, disaggregated veya external storage kullanan hyperconverged Azure Local.
L3 ise locally hosted control plane kullanan disconnected operations modeli.
Bu ayrım sadece teknik değil, maliyet açısından da önemli.
Özellikle Azure Hybrid Benefit kullanacak müşterilerin buna dikkat etmesi gerekiyor.
Windows Server Datacenter lisanslarınız ve aktif Software Assurance’ınız varsa Azure Hybrid Benefit for Azure Local kullanabiliyorsunuz. Microsoft’un güncel lisanslama modelinde bir adet Software Assurance kapsamındaki Windows Server Datacenter core lisansı, bir fiziksel Azure Local core ile eşleştiriliyor.
Bunun karşılığında Azure Local host service ücreti ve Windows Server guest subscription ücreti kaldırılabiliyor.
Buraya kadar güzel.
Ama önemli bir değişiklik var.
Azure Hybrid Benefit artık sadece L1, yani external storage kullanmayan, cloud-connected hyperconverged Azure Local deployment’ları için geçerli.
L2 ve L3 desteklenmiyor.
Bu detay mimari karar verirken ciddi maliyet farkı yaratabilir.
Örneğin mevcut SAN’ınız var ve teknik olarak bunu Azure Local’a bağlamak çok mantıklı görünüyor olabilir. Ancak external storage kullandığınız anda L2 modeline geçiyorsanız Azure Hybrid Benefit hesabınız da değişiyor.
Dolayısıyla “mevcut SAN’ı kullanalım, yeni disk satın almayalım, daha ucuz olur” dediğiniz bir mimari lisans tarafındaki değişiklik nedeniyle düşündüğünüz kadar ucuz olmayabilir.
İşte TCO hesabının sadece donanım fiyatıyla yapılamamasının güzel örneklerinden biri bu.
Windows Server VM lisanslarını da unutmayın
Azure Local host lisansı ile guest Windows Server lisansı aynı şey değil.
Microsoft’un Azure Local pricing sayfasında host service ücretinin Windows veya ücretli Linux guest lisanslarını içermediği açıkça belirtiliyor.
Windows Server workload’ları için birkaç farklı model bulunuyor.
Azure Hybrid Benefit kullanabiliyorsanız mevcut Windows Server Datacenter lisanslarınızdan faydalanabilirsiniz. Bunun dışında Azure üzerinden Windows Server subscription satın alınabiliyor.
Microsoft’un 27 Ağustos 2026 itibarıyla yayınladığı fiyatlandırma sayfasında Windows Server guest subscription fiyatı aylık 23,3 ABD doları / fiziksel core olarak listeleniyor. Bu abonelik Azure Local üzerindeki Windows Server guest’leri için unlimited virtualization rights sağlıyor. Gerçek fiyat tabii ki sözleşme, para birimi ve satın alma modeline göre değişebilir.
Burada da yine fiziksel core sayısının neden önemli olduğunu görüyoruz.
Sadece performans değil, lisans maliyeti.
Bu nedenle Azure Local sizing çalışmasını yapan teknik ekip ile lisanslama ekibinin birbirinden bağımsız çalışmasını doğru bulmuyorum.
Teknik ekip “en güçlü CPU olsun” derken lisans ekibi üç yıl sonra çıkan faturaya bakıyorsa iş işten geçmiş oluyor.
AKS tarafında güzel bir maliyet detayı var
Azure Local üzerinde AKS kullanmayı planlayan kurumlar için de güncel lisanslamada önemli bir değişiklik bulunuyor.
Microsoft, Azure Kubernetes Service enabled by Azure Arc’ın Azure Local 2402 ve sonraki sürümlerinde ek ücret olmadan Azure Local’a dahil edildiğini belirtiyor. Bu değişiklik Ocak 2025’ten itibaren geçerli.
Yani container platformu planlıyorsanız AKS control plane lisans maliyetini eski hesaplarla değerlendirmemek gerekiyor.
Tabii ki VM işletim sistemi, Azure servisleri, backup, monitoring veya kullandığınız diğer servislerin kendi maliyetleri ayrıca devam edebilir.
“AKS ücretsiz oldu, Kubernetes altyapısının maliyeti yok” gibi düşünmemek lazım.
Compute ve storage hala sizin Azure Local kapasitenizi tüketiyor.
TCO hesabını nasıl yaparım?
Azure Local için gerçek bir TCO çalışması yapıyorsam sadece sunucu fiyatı ile VMware veya klasik Hyper-V maliyetini karşılaştırmam.
En azından donanım, Azure Local host service, Windows Server guest lisansları, mevcut Software Assurance hakları, Azure servisleri, support, network altyapısı, enerji, rack alanı ve üç-beş yıllık büyüme maliyetini beraber görmek isterim.
Disaggregated yapı varsa SAN maliyeti ve SAN operasyonu da eklenmeli.
Disconnected operations varsa lokal control plane için ayrı donanım ihtiyacını da hesaba katmak gerekiyor. Microsoft disconnected mimaride management plane için ayrı üç node’lu dedicated management cluster öneriyor ve tenant workload’ların bu management cluster üzerinde çalıştırılmamasını istiyor.
Yani disconnected bir projede sadece workload cluster fiyatını alıp Azure Local maliyeti diye müşterinin önüne koyarsanız eksik hesap yapmış olursunuz.
Aynı şekilde mevcut Windows Server Datacenter + Software Assurance yatırımınız varsa bunu da TCO’dan düşmeniz gerekiyor.
Bana göre Azure Local’ın ekonomik olup olmadığına ancak bütün bu kalemler aynı tabloda görüldüğünde karar verilebilir.
Bir başka konu da kapasiteyi baştan ne kadar büyük almak gerektiği.
Microsoft Well-Architected Framework burada güzel bir dengeye dikkat çekiyor. Yetersiz sizing reliability problemi yaratırken gereğinden fazla donanım almak da hardware warranty süresi boyunca kaynakların kullanılmamasına ve ROI’ın düşmesine neden olabilir. Microsoft bu nedenle workload ihtiyacı, büyüme ve ek headroom’un beraber hesaplanmasını öneriyor.
Ben de aynı fikirdeyim.
“Beş yıl sonra lazım olur” diyerek bugün iki kat donanım almak çoğu zaman doğru değil.
Ama “nasıl olsa sonra node ekleriz” demek de her zaman doğru değil.
Çünkü yeni node’un satın alma süresi, aynı hardware generation’ın bulunabilirliği, CPU uyumluluğu, firmware seviyeleri ve cluster genişletme operasyonu var. Microsoft da initial sizing’in bu nedenle doğru yapılmasını özellikle öneriyor.
Özetle Azure Local kapasite planlamasında benim yaklaşımım şu olur:
Önce mevcut workload’u ölçerim, ardından right-sizing yaparım. N+1 veya workload kritikse N+2 senaryosunda kalan kapasitenin VM’leri taşıyıp taşıyamadığını kontrol ederim. Storage tarafında sadece kullanılan alanı değil resiliency, repair ve büyüme kapasitesini hesaba katarım. Sonra Azure Local Catalog içerisinden uygun donanımlara bakarım ve özellikle SBE ile lifecycle desteğini kontrol ederim.
En son aşamada da teknik tasarımı lisans modeliyle beraber tekrar değerlendiririm.
Çünkü Azure Local’da artık HCI mı disaggregated mı seçtiğiniz, external SAN kullanıp kullanmadığınız ve fiziksel CPU’da kaç core bulunduğu sadece teknik karar değil.
Doğrudan maliyet kararı.
Bir sonraki makalede artık donanımı seçtiğimizi kabul edip kuruluma yaklaşacağız. Azure Local deployment başlamadan önce Azure subscription, resource provider, Entra ID, Active Directory, DNS, NTP, firewall, proxy, sertifika, firmware ve network tarafında hangi kontrollerin yapılması gerektiğini inceleyeceğim. Özellikle sahada deployment sırasında karşımıza çıkan problemlerin önemli bir bölümünün aslında kurulum başlamadan önce tespit edilebildiğini göreceğiz.
Kullandığım temel Microsoft kaynakları: Azure Local Well-Architected Framework, Azure Local System Requirements, Azure Local Hyperconverged Deployments, Azure Local Disaggregated Deployments, Solution Builder Extension Updates, Azure Hybrid Benefit for Azure Local ve Azure Local Pricing. Fiyatlandırma ve lisanslama bilgilerini 27 Ağustos 2026 tarihinde Microsoft’un güncel sayfalarından kontrol ettim; özellikle L1/L2/L3 ayrımı ve Azure Hybrid Benefit kapsamı satın alma öncesinde tekrar doğrulanmalı.
