Microsoft altyapı teknolojilerini uzun süredir takip edenler için Azure Stack HCI yeni bir ürün değil. Özellikle Hyper-V, Storage Spaces Direct ve Failover Clustering tarafında çalışan pek çok sistem yöneticisi Azure Stack HCI ile uzun zamandır tanışık. Ancak son birkaç yılda ürünün kapsamında ciddi bir değişim yaşandı ve Microsoft, Ignite 2024 ile beraber Azure Stack HCI ismini Azure Local olarak değiştirdi.
Burada sadece bir isim değişikliğinden bahsetmiyoruz.
Microsoft’un kendi tanımına göre Azure Local, Azure yeteneklerini müşteriye ait ortamlara taşıyan bir “distributed infrastructure”, yani dağıtık altyapı çözümü. Azure Arc ise bu yapının ortak control plane’i olarak konumlandırılıyor. Platform modern ve geleneksel uygulamaların müşterinin kendi veri merkezinde, edge lokasyonlarında veya belirli egemenlik gereksinimleri bulunan ortamlarda çalıştırılmasına imkan sağlıyor.
Aslında Azure Stack HCI döneminden Azure Local dönemine geçerken anlamamız gereken en önemli değişiklik tam olarak bu. Konu artık sadece iyi bir HCI cluster kurmak, üzerine sanal makineleri yerleştirmek ve bunları yönetmek değil. Microsoft kendi veri merkezinizdeki altyapıyı Azure kaynak modeli ve Azure yönetim yaklaşımının bir parçası haline getirmeye çalışıyor.
Bu nedenle Azure Local’i sadece “Azure Stack HCI’ın yeni adı” diye anlatmak bana göre eksik kalır.
Azure Stack HCI ismi ürünün HCI tarafını çok net anlatıyordu. Azure Local ise Microsoft’un bugün ulaşmaya çalıştığı daha geniş yapının ismi. Microsoft da isim değişikliğinin gerekçesini açıklarken yeni ismin genişleyen ve birleşen distributed infrastructure portföyünü daha doğru temsil ettiğini belirtiyor.
Temelde bildiğimiz teknolojiler var
Azure Local tamamen sıfırdan yazılmış yeni bir sanallaştırma platformu değil. Alt tarafta uzun yıllardır kullandığımız ve kurumsal ortamlarda kendisini kanıtlamış teknolojiler bulunuyor.
Hyper-V compute katmanını, Storage Spaces Direct yazılım tanımlı storage katmanını, Failover Clustering ise yüksek erişilebilirlik tarafını oluşturuyor. Microsoft da güncel Azure Local dokümantasyonunda hyperconverged mimarinin Hyper-V, Storage Spaces Direct ve Failover Clustering gibi bilinen Microsoft teknolojileri üzerine kurulduğunu açık bir şekilde belirtiyor.
Bu aslında önemli bir detay. Çünkü Azure Local konusunu anlatırken bazen ürünün Azure ismi taşımasından dolayı tamamen cloud tarafında çalışan farklı bir sanallaştırma teknolojisiymiş gibi algılanabiliyor.
Öyle değil.
Sanal makineleriniz yine sizin veri merkezinizde bulunan fiziksel sunucular üzerinde çalışıyor. Storage sizin ortamınızda. Network sizin ortamınızda. Donanım yine sizin sorumluluğunuzda.
Değişen esas nokta bunları nasıl yönettiğiniz ve Azure servisleriyle nasıl entegre ettiğiniz.
Hyperconverged Azure Local deployment’ları bugün tek bir fiziksel makineden başlayarak 16 makineye kadar ölçeklenebiliyor. Microsoft aynı zamanda farklı üreticilerin validated hardware çözümlerinden oluşan geniş bir partner ekosistemi sunuyor.
Burada özellikle “validated hardware” kısmını atlamamak gerekiyor. Klasik Hyper-V dünyasında yaptığımız gibi elimizde bulunan herhangi bir Windows Server uyumlu sunucuyu alıp Azure Local cluster yapmak doğru bir yaklaşım değil. Donanım, network adaptörleri, diskler, firmware ve driver kombinasyonu ürünün desteklenebilirliği açısından önemli.
Ben Azure Local projelerinde donanım seçiminin sadece “kaç core, kaç GB RAM ve kaç TB disk lazım” seviyesinde yapılmasını bu nedenle doğru bulmuyorum. Özellikle storage ve network katmanında yapılan yanlış bir tasarımın etkisini daha sonra VM seviyesinde düzeltmeniz mümkün değil.
Bu konuyu serinin kapasite planlama ve donanım seçimi bölümünde daha detaylı inceleyeceğiz.
Farkı oluşturan kısım Azure Arc
Azure Local tarafındaki asıl değişimi anlamak için Azure Arc’ı anlamak gerekiyor.
Azure Arc, Microsoft’un on-premises, edge ve multicloud kaynaklarını ortak bir Azure management plane üzerinden yönetmek için kullandığı platform. Azure Local ise Arc entegrasyonunu platformun içine yerleştiriyor.
Örneğin Azure Local üzerinde bir sanal makine oluşturmak istediğinizi düşünelim.
Klasik tarafta Hyper-V Manager, Failover Cluster Manager veya Windows Admin Center üzerinden VM oluşturmaya alışığız. Azure Local’da bunların yanına başka bir model geliyor. VM’yi Azure portal üzerinden bir Azure kaynağı gibi oluşturabiliyorsunuz.
Azure Local VM management tarafında Azure Arc Resource Bridge bu işlemin önemli parçalarından biri. Resource Bridge, Azure ile lokal altyapı arasındaki bağlantıyı sağlayarak VM lifecycle işlemlerinin Azure üzerinden gerçekleştirilmesine imkan veriyor. Microsoft’un güncel dokümantasyonunda VM başlatma, durdurma, vCPU veya memory değiştirme ve disk gibi kaynakları yönetme işlemleri bu model üzerinden destekleniyor.
Yani Azure portal üzerinden baktığınızda kendi veri merkezinizde çalışan VM artık sadece bir Hyper-V nesnesi değil. Azure Resource Manager tarafında da karşılığı olan bir kaynak haline geliyor.
Bunun sahadaki karşılığı bence çok daha önemli.
Bir uygulama ekibine fiziksel cluster üzerinde yönetici yetkisi vermeden sadece belirli sanal makineleri oluşturma veya yönetme yetkisi verebilirsiniz. Azure RBAC modelini kullanabilirsiniz. Deployment işlemlerini Azure CLI veya template’ler ile otomatik hale getirebilirsiniz.
Burada klasik sanallaştırma yönetiminden cloud operating model dediğimiz yapıya doğru geçmeye başlıyoruz.
Tabii ki bunun da operasyonel bir karşılığı var. Azure Local’i aldım, Hyper-V cluster gibi kurdum, sonra bir daha Azure tarafına bakmadan kullanırım diye düşünüyorsanız ürünün sunduğu kabiliyetlerin önemli bir bölümünü zaten kullanmıyorsunuz demektir.
Azure Local artık sadece VM demek değil
Azure Stack HCI denildiğinde insanların aklına doğal olarak sanal makineler geliyordu. Azure Local tarafında ise Microsoft ürünün kapsamını bunun çok daha ötesine taşıyor.
Windows ve Linux VM’ler platformun en temel workload’ları olmaya devam ediyor. Bunun yanında AKS üzerinden Kubernetes workload’ları, Azure Virtual Desktop senaryoları ve farklı Arc enabled servisler de aynı altyapı üzerinde konumlandırılabiliyor.
Bu noktada özellikle AKS tarafı önemli. Çünkü kurumların çok büyük bir bölümü bir gecede bütün uygulamalarını container’a taşımayacak.
Gerçek hayatta genellikle iki dünya beraber yaşıyor.
Bir tarafta 10 yıllık Windows Server üzerinde çalışan kurumsal uygulamanız var, diğer tarafta yeni geliştirilen uygulamalar Kubernetes üzerinde çalışıyor. Bir üretim tesisinde bunlara bir de IoT ve lokal AI workload’ları eklenebiliyor.
Azure Local’in vermeye çalıştığı cevap tam olarak bu karma yapı.
Her şeyi public cloud’a taşıyamıyorsanız veya taşımak istemiyorsanız, Azure yönetim modelini workload’un bulunduğu yere götürmek.
Burada “cloud first” yerine “cloud operating model everywhere” gibi düşünmek bana daha doğru geliyor.
Her iş yükünü neden Azure’a taşımıyoruz?
Cloud konusunda uzun yıllardır gördüğümüz en büyük yanlış anlamalardan biri, modernizasyonun her workload’u public cloud’a taşımak anlamına geldiğinin düşünülmesi.
Halbuki gerçek dünya böyle değil.
Bir fabrikanın üretim hattını yöneten uygulama ile şirketin web sitesini aynı şekilde değerlendiremezsiniz. Üretim hattındaki sistemin milisaniyeler seviyesinde cevap vermesi gerekiyorsa, internet bağlantısı kesildiğinde üretim duracaksa veya oluşan verinin tesis dışına çıkması yasaksa bu workload’u sırf “cloud kullanıyoruz” demek için binlerce kilometre uzaktaki bir Azure region’a göndermenin çok fazla anlamı yok.
Microsoft da Azure Local için özellikle local AI inference, mission-critical business continuity, düşük gecikmeli operasyonlar ve data sovereignty gibi senaryoları öne çıkarıyor.
Bir perakende mağazasında görüntü işleme yapan AI uygulamasını düşünün. Kameralardan sürekli video Azure’a gönderip orada inference yapmak teknik olarak mümkün olabilir. Ama onlarca veya yüzlerce mağazanız varsa network maliyeti, gecikme ve privacy konuları devreye giriyor.
Inference işlemini mağazada bulunan Azure Local üzerinde yapmak, sadece sonucu merkezi sisteme göndermek çok daha mantıklı olabilir.
Aynı durum üretim tesisleri için de geçerli.
Üretim hattı internet kesildiği için duramaz.
İşte Azure Local’in “Local” kısmı tam burada anlam kazanıyor.
Compute verinin ve uygulamanın ihtiyaç duyduğu yerde kalırken, mümkün olan noktalarda merkezi Azure yönetim modeli kullanılıyor.
Azure yönetim servislerinin lokal altyapıya gelmesi
Azure Local’i klasik bir HCI ürününden ayıran bir diğer önemli konu Azure servisleriyle olan entegrasyon.
Microsoft Azure Local üzerinde Azure Policy, Microsoft Defender for Cloud ve Azure Monitor gibi Azure servislerinin kullanılabildiğini belirtiyor. Yönetim tarafında Azure portal, Azure CLI ve ARM tabanlı araçlar kullanılabiliyor.
Bunun özellikle büyük kurumlarda ciddi bir operasyonel karşılığı var.
Azure tarafında ayrı güvenlik politikanız, on-premises ortamda ayrı politika, şubelerde ayrı yönetim, fabrikalarda başka bir araç kullanıyorsanız bir süre sonra sadece ürünleri değil, ürünlerin operasyonunu yönetmek büyük bir iş haline geliyor.
Azure Local ile Microsoft’un hedeflediği modelde merkezi governance yaklaşımını bu lokasyonlara kadar genişletebiliyorsunuz.
Fakat burada da ürünün sadece güzel taraflarını anlatmamak gerekiyor.
Bu entegrasyon beraberinde Azure bağımlılığını ve daha sık bir lifecycle yönetimini de getiriyor. Azure Local, klasik Windows Server cluster mantığında “kurdum, beş yıl dokunmadım” diyebileceğiniz bir platform değil.
Microsoft her Azure Local release’inin altı ay boyunca desteklendiğini belirtiyor. Azure Stack HCI 23H2 OS ailesi de Nisan 2026 itibarıyla destek süresinin sonuna geldi. Güncel release tarafında da Azure Local sistemlerini desteklenen lifecycle içerisinde tutmanız gerekiyor.
Bu nedenle Azure Local projesi tasarlarken sadece deployment gününü düşünmeyin.
Update operasyonunu kim yapacak, OEM firmware ve driver paketleri nasıl takip edilecek, maintenance window ne olacak, cluster üzerinde çalışan kritik workload’lar update sırasında nasıl davranacak gibi konuları daha projenin başında konuşmak gerekiyor.
Benim Azure Local tarafında en fazla önem verdiğim konulardan biri bu.
Ürünü satın alıp kurmak işin kolay kısmı. Üç yıl boyunca sağlıklı ve support edilen bir şekilde işletmek asıl operasyon.
Microsoft da known issues dokümanını sürekli güncelliyor ve yeni bir Azure Local deployment’ı öncesinde bu dokümanın kontrol edilmesini özellikle öneriyor.
Bu nedenle update öncesi sadece “yeni update çıkmış, yükleyelim” mantığı ile hareket edilmemeli. Release information, known issues, OEM tarafındaki Solution Builder Extension ve mevcut workload durumu beraber kontrol edilmeli.
Connected olmak zorunda mı?
Azure Local konusunda son dönemde bence en ilgi çekici gelişmelerden biri disconnected operations.
Normal Azure Local mimarisinde Azure önemli bir control plane görevi görüyor. Ancak savunma, kamu, enerji veya kritik üretim sistemleri gibi ortamlarda public Azure bağlantısı her zaman mümkün değil.
Bazı sistemlerde internet erişimi güvenlik politikası gereği zaten yasak olabilir.
Azure Local’in disconnected operasyon modeli tam bu tip ortamlar için geliştiriliyor. Microsoft’un güncel Azure Local tanımında hem cloud-connected hem de disconnected deployment modelleri yer alıyor.
Bu konu aslında tek başına bir makale olacak kadar detaylı. Çünkü disconnected dediğimiz zaman sadece “internet kablosunu çekiyoruz ve sistem çalışmaya devam ediyor” gibi basit bir yapı yok.
Identity, management plane, update paketleri, loglar, lisanslama ve lokal operasyon modeli yeniden düşünülüyor.
Örneğin bandwidth’in kısıtlı olduğu lokasyonlarda Microsoft Azure Local solution update paketlerinin statik payload olarak indirilip daha sonra diğer sistemlere aktarılmasını ve PowerShell ile import edilmesini destekliyor.
Özellikle çok sayıda edge lokasyonu yöneten kurumlar için bunlar kağıt üzerinde küçük görünen ama operasyon tarafında ciddi fark yaratan detaylar.
Disconnected operations konusunu serinin ilerleyen bölümlerinde ayrıca ele alacağım.
VMware veya Hyper-V alternatifi olarak bakmak yeterli değil
Son dönemde özellikle VMware tarafında yaşanan değişimlerden sonra Azure Local’a olan ilginin arttığını görüyoruz. Doğal olarak müşterilerin ilk sorduğu konulardan biri de “VMware yerine Azure Local kullanabilir miyiz?” oluyor.
Teknik olarak pek çok workload için cevap evet olabilir.
Ama Azure Local’i sadece VMware alternatifi olarak değerlendirmek bence yine ürünün asıl farkını kaçırmak olur.
Hypervisor karşılaştırması yaptığınızda Hyper-V zaten uzun yıllardır bildiğimiz bir teknoloji. Azure Local’i farklı yapan Hyper-V’nin bir gecede yeni özellikler kazanması değil.
Farkı oluşturan kısım Azure Arc, Azure Resource Manager, Azure RBAC, Azure Policy, merkezi monitoring, otomasyon ve lokal altyapının Azure operasyon modeline alınması.
Aynı şekilde Azure Local’i klasik Windows Server Hyper-V ile de bire bir karşılaştırmamak gerekiyor. Microsoft’un kendi karşılaştırmasında Windows Server genel amaçlı bir server operating system olarak konumlandırılırken Azure Local, on-premises ve Azure arasında tutarlı bir yönetim deneyimi vermek üzere tasarlanan cloud-connected hyperconverged platform olarak tarif ediliyor.
Tabii ki her müşterinin Azure Local kullanması da gerekmiyor.
Eğer üç fiziksel sunucunuz, 15 sanal makineniz varsa, Azure entegrasyonuna ihtiyacınız yoksa, mevcut Hyper-V yapınız stabil çalışıyorsa ve Arc, Kubernetes, merkezi governance veya edge gibi bir hedefiniz bulunmuyorsa Azure Local’a geçmek sadece teknoloji değiştirmiş olmak için yapılan pahalı bir proje haline gelebilir.
Ama onlarca lokasyonunuz varsa, Azure kullanıyorsanız, merkezi yönetim ve governance istiyorsanız, klasik VM’lerle beraber container ve edge workload’larını da yönetmeniz gerekiyorsa Azure Local çok daha anlamlı bir platform haline geliyor.
Özetle Azure Local tarafında benim gördüğüm en önemli değişim şu:
Azure Stack HCI bize modern bir Microsoft HCI platformu sunuyordu. Azure Local ise bu altyapıyı Microsoft’un daha geniş Azure ve Adaptive Cloud stratejisinin bir parçası haline getiriyor.
Fiziksel sunucu yine sizin veri merkezinizde.
VM yine sizin sunucunuzda çalışıyor.
Veriniz yine sizin lokasyonunuzda kalabiliyor.
Ama bu kaynakların deployment, governance, security ve monitoring modeli giderek Azure ile ortak hale geliyor.
Azure Local’i önümüzdeki dönemde önemli yapacak konunun da sadece sanallaştırma olmadığını düşünüyorum. Edge, disconnected operations, Kubernetes ve özellikle lokal AI workload’ları yaygınlaştıkça “workload’u cloud’a götürmek” yerine “cloud modelini workload’un yanına getirmek” çok daha fazla konuşacağımız bir mimari olacak.
Bir sonraki makalede Azure Local tarafındaki farklı mimari seçeneklerine biraz daha yakından bakacağız. Hyperconverged, disaggregated, small form factor ve disconnected yapılar aynı Azure Local ailesinin parçası olsa da, hangi yapının hangi senaryo için kullanılması gerektiği birbirinden oldukça farklı.
Kaynaklar
Bu makalede temel olarak Microsoft’un güncel Azure Local ve Azure Arc dokümantasyonu kullanılmıştır:
- Microsoft Learn – What Is Azure Local? Overview and Key Benefits
- Microsoft Learn – Azure Local Rename and Product Scope
- Microsoft Learn – Hyperconverged Deployments of Azure Local
- Microsoft Learn – Azure Local VM Management
- Microsoft Learn – Azure Arc Overview
- Microsoft Learn – Azure Local Release Information
- Microsoft Learn – Azure Local Known Issues