Azure Local projelerinde en çok dikkatimi çeken konulardan biri, yeni bir platforma geçerken eski sanallaştırma alışkanlıklarımızı aynen devam ettirmeye çalışmamız.
Yıllardır Hyper-V kullanıyorsanız yeni bir sanal makine oluşturmak için Hyper-V Manager, Failover Cluster Manager, Windows Admin Center veya PowerShell kullanmanız son derece doğal. VMware dünyasından geliyorsanız benzer şekilde vCenter üzerinden VM oluşturma ve yönetme alışkanlığınız var.
Azure Local ise bu modeli tamamen ortadan kaldırmıyor ancak üzerine farklı bir yönetim katmanı getiriyor.
Artık kendi veri merkezinizde çalışan bir Windows veya Linux sanal makinesini Azure portal üzerinden oluşturabiliyor, başlatabiliyor, durdurabiliyor, CPU ve memory değerlerini değiştirebiliyor, disk ve network interface ekleyebiliyor ve bütün bunları Azure RBAC ile yetkilendirebiliyorsunuz.
Fiziksel sunucu sizin veri merkezinizde.
Storage sizin Azure Local cluster’ınızda.
VM yine lokal ortamda çalışıyor.
Ama VM’nin yaşam döngüsü Azure Resource Manager üzerinden yönetilebiliyor.
Bence Azure Local’ın klasik HCI platformundan ayrıldığı en önemli noktalardan biri tam olarak burada ortaya çıkıyor.
Çünkü konu artık yalnızca sanal makine çalıştırmak değil.
Sanal makine altyapısını Azure resource modelinin bir parçası haline getirmek.
Bu yaklaşım doğru kullanıldığında altyapı ekiplerinin sürekli VM oluşturan operasyon ekipleri olmaktan çıkmasını ve uygulama ekiplerine kontrollü self-service yetkileri verilmesini mümkün hale getiriyor.
Her Azure Local VM aynı şekilde yönetilmiyor
Öncelikle Azure Local üzerinde çalışabilecek VM türlerini birbirinden ayırmak gerekiyor.
Microsoft güncel dokümantasyonunda temelde üç farklı yönetim modelinden bahsediyor.
Birincisi Azure Local VM enabled by Azure Arc.
İkincisi Azure Arc-enabled Server.
Üçüncüsü ise unmanaged VM.
Bu üç yapı ilk bakışta birbirine benziyor çünkü hepsi Azure Local üzerinde çalışan Windows veya Linux sanal makineleri olabilir. Ancak yönetim kabiliyetleri oldukça farklı.
Azure Local VM enabled by Azure Arc, Azure Local’ın kendi VM provisioning modeli üzerinden oluşturuluyor. VM, Azure Arc Resource Bridge üzerinden Azure Resource Manager ile ilişkilendiriliyor ve Azure tarafında yönetilen bir resource haline geliyor.
Bu VM üzerinde Azure portal veya Azure CLI aracılığıyla start, stop, restart, pause, save state, disk ekleme, network interface ekleme, vCPU veya memory değiştirme gibi lifecycle işlemleri gerçekleştirilebiliyor.
Azure Arc-enabled Server ise farklı.
Mevcut bir VM üzerine Azure Connected Machine Agent yükleyerek sunucuyu Azure Arc’a bağlayabilirsiniz. Bu sayede Azure Policy, Defender for Cloud, Azure Monitor ve desteklenen extension’lar gibi Azure servislerinden faydalanabilirsiniz.
Ancak bu VM’nin hypervisor seviyesindeki yaşam döngüsü Azure Local VM management modeline geçmiyor.
Yani Azure Arc-enabled Server olmak ile Azure Local VM enabled by Azure Arc olmak aynı şey değil.
Üçüncü model ise unmanaged VM.
Hyper-V Manager, Failover Cluster Manager veya benzeri lokal araçlarla oluşturulan ve Azure yönetim katmanına dahil edilmeyen VM’lerden bahsediyoruz.
Burada özellikle dikkat edilmesi gereken bir konu var.
Mevcut bir unmanaged VM veya sadece Azure Arc-enabled Server durumundaki VM’yi doğrudan Azure Local VM modeline çevirmek bugün desteklenen standart bir conversion işlemi değil.
Microsoft mevcut VMware veya Hyper-V workload’larının Azure Local VM modeline taşınması için Azure Migrate tabanlı migration akışını destekliyor.
Dolayısıyla yeni Azure Local projesinde VM yönetim modelini daha baştan belirlemek önemli.
Bugün 100 VM’yi klasik Hyper-V araçlarıyla oluşturup altı ay sonra “bunları şimdi Azure portal üzerinden tam lifecycle yönetimine alalım” demek düşündüğümüz kadar basit olmayabilir.
Azure Arc Resource Bridge bu yapının merkezinde
Azure Local VM management mimarisini anlamak için Azure Arc Resource Bridge’i anlamak gerekiyor.
Azure Local deployment sırasında cluster başına bir Azure Arc Resource Bridge otomatik olarak oluşturuluyor.
Bu bileşen Azure Local üzerinde çalışan prepackaged bir virtual appliance. İçerisinde Azure Arc-enabled Kubernetes tabanlı bir management cluster bulunuyor.
Resource Bridge’in temel görevi Azure ile lokal altyapı arasında yönetim köprüsü oluşturmak.
Azure portal üzerinden bir VM oluşturduğunuzu düşünelim.
Siz Azure tarafında bir resource oluşturma talebi gönderiyorsunuz.
Azure Resource Manager bu isteği işliyor.
Custom Location üzerinden hangi Azure Local ortamının hedeflendiği belirleniyor.
Azure Arc Resource Bridge içerisindeki ilgili extension bu isteği lokal Azure Local cluster’a iletiyor.
VM fiziksel olarak sizin veri merkezinizde oluşturuluyor.
Ancak Azure tarafında da bu VM’yi temsil eden resource bulunuyor.
Basitleştirirsek:
Azure Portal / Azure CLI
↓
Azure Resource Manager
↓
Custom Location
↓
Azure Arc Resource Bridge
↓
Azure Local
↓
Virtual Machine
Bence burada özellikle Custom Location kavramı önemli.
Custom Location, Azure’daki klasik region yapısının bire bir karşılığı değil.
Kendi Azure Local altyapınızı Azure Resource Manager açısından deployment yapılabilecek bir hedef haline getiriyor.
Örneğin İstanbul ve Ankara’da iki farklı Azure Local ortamınız olduğunu düşünelim.
Her iki ortamın ayrı Custom Location kaynağı olabilir.
VM oluştururken hangi lokal altyapıya deployment yapılacağını bu kaynak üzerinden belirleyebilirsiniz.
Bu yaklaşım çok lokasyonlu yapılarda oldukça değerli.
Uygulama ekibinin fiziksel node isimlerini, cluster yapısını veya hangi Hyper-V host üzerinde VM oluşturulacağını bilmesi gerekmiyor.
Kendisine sunulan deployment hedefini kullanması yeterli.
Azure Arc Resource Bridge burada kritik bir platform bileşeni olduğu için klasik bir management VM gibi değerlendirilmemeli.
Microsoft bu bileşenin Azure Local VM management için kritik olduğunu ve Azure Local instance reimage veya decommission edilmeyecekse silinmemesi gerektiğini açıkça belirtiyor.
Resource Bridge geçici olarak erişilemez hale gelirse çalışan VM’ler otomatik olarak kapanmaz.
Workload ile management plane’i birbirinden ayırmak gerekiyor.
VM’ler lokal hypervisor üzerinde çalışmaya devam edebilir.
Ancak Azure üzerinden gerçekleştirilen yönetim operasyonları etkilenebilir.
Bu nedenle Resource Bridge health durumu da Azure Local operasyonel monitoring’inin bir parçası olmalı.
Self-Service için önce ortak kaynakları hazırlamak gerekiyor
Bir uygulama ekibine Azure Local üzerinde VM Contributor yetkisi verip “artık VM’lerinizi kendiniz oluşturabilirsiniz” demek gerçek anlamda self-service IaaS oluşturmak için yeterli değil.
Önce kullanılacak ortak altyapı kaynaklarını hazırlamak gerekiyor.
Azure Local VM provisioning modelinde özellikle üç kaynak önemli:
VM Image
Logical Network
Storage Path
Bunları self-service kataloğunun temel bileşenleri gibi düşünebiliriz.
Uygulama ekibinin hangi işletim sistemini kullanabileceğini image belirliyor.
VM’nin hangi network’e bağlanacağını logical network belirliyor.
VM dosyalarının ve disklerinin hangi storage alanında tutulacağını storage path belirliyor.
Bu kaynaklar merkezi altyapı ekibi tarafından hazırlanırsa uygulama ekibi fiziksel altyapının detaylarını bilmeden standart kaynaklardan VM oluşturabilir.
Bence self-service’in gerçek başlangıç noktası portal değil.
Standardizasyon.
Standart bir image yoksa, network modeli belli değilse ve storage placement tasarlanmamışsa portal üzerinden VM oluşturabiliyor olmak operasyonu çok fazla değiştirmiyor.
Image yönetimi sandığımızdan daha önemli
Azure Local üzerinde kullanılacak VM image’ları farklı kaynaklardan hazırlanabiliyor.
Microsoft güncel Azure Local VM management modelinde Azure Marketplace, Azure Compute Gallery, Azure Storage Account ve lokal file share üzerinden image oluşturulmasını destekliyor.
Bunun sahadaki karşılığı oldukça önemli.
Örneğin kurum içerisinde standart Windows Server 2025 image’ı kullanıyorsunuz.
İşletim sistemi baseline ayarları belirlenmiş.
Gerekli güvenlik güncellemeleri uygulanmış.
Belirli agent’lar hazırlanmış.
Bu image Azure Local VM image resource olarak tanımlandığında uygulama ekipleri sürekli farklı ISO dosyalarıyla VM oluşturmak yerine standart image’ı kullanabilir.
Aynı yaklaşım Linux tarafında da uygulanabilir.
Ancak image bir kere oluşturulduktan sonra unutulacak bir kaynak değil.
Windows Server image’ınızı bugün oluşturduğunuzu düşünelim.
Altı ay sonra yeni cumulative update’ler çıkacak.
Security baseline değişebilir.
Yeni agent sürümleri gelebilir.
Dolayısıyla image lifecycle da Azure Local operasyon modelinin parçası olmak zorunda.
Ben self-service IaaS tasarımında image’lara mutlaka versiyon mantığıyla yaklaşırım.
Örneğin:
Windows Server 2025 – 2026.10
Windows Server 2025 – 2026.11
Ubuntu 24.04 – 2026.10
gibi standardize edilmiş image versiyonları kullanmak, “Windows2025-Final-New-v3” benzeri kontrolsüz isimlerden çok daha sağlıklı.
Eski image’ların ne zaman kullanım dışına alınacağı da belirlenmeli.
Aksi halde bir ekip güncel image kullanırken başka bir ekip dokuz ay önce hazırlanmış işletim sistemiyle yeni VM oluşturmaya devam edebilir.
Logical Network aslında fiziksel network’ün Azure tarafındaki karşılığı
Azure Local VM oluştururken kullanılan bir diğer önemli kaynak Logical Network.
Logical Network, fiziksel network’ün Azure Resource Manager tarafındaki mantıksal temsilini oluşturuyor.
VM network interface’lerinin hangi fiziksel network’e bağlanacağını belirliyor.
Logical Network içerisinde address prefix, subnet, IP pool, gateway, DNS server ve VLAN gibi network parametreleri tanımlanabiliyor.
Örneğin kurum içerisinde üç network bulunduğunu düşünelim.
Production
Test
Management
Her biri Azure Local üzerinde ayrı Logical Network resource olarak sunulabilir.
Uygulama ekibi yeni VM oluştururken kendisine sunulan logical network’lerden uygun olanı seçebilir.
Ancak burada dikkat edilmesi gereken önemli bir konu var.
Logical Network oluşturmak fiziksel network’ü otomatik olarak oluşturmuyor.
Örneğin VLAN 120 kullanan Production Network tanımlıyorsanız bu VLAN’ın fiziksel switch altyapısında zaten doğru şekilde yapılandırılmış olması gerekiyor.
Azure Local üzerindeki external vSwitch ve fiziksel network tasarımıyla logical network birbirine uyumlu olmalı.
Bir başka önemli nokta ise bazı Logical Network parametrelerinin oluşturma sonrasında değiştirilememesi.
Microsoft’un güncel dokümantasyonunda default gateway, IP pool, IP address space, VLAN ID ve virtual switch name gibi temel network özelliklerinin Logical Network oluşturulduktan sonra güncellenemediği belirtiliyor.
Dolayısıyla network planını “önce oluşturalım, sonra değiştiririz” mantığıyla yapmak doğru değil.
Özellikle production ortamlarında IP planı ve VLAN tasarımının deployment öncesinde network ekibiyle netleştirilmesi gerekiyor.
Azure Local VM tarafında bugün IPv4 destekleniyor; IPv6 desteği bulunmuyor.
Azure Local 2607 ile beraber workload logical network üzerinde DNS server veya gateway olarak tanımlanan IP adreslerinin belirli koşullarda bir Azure Local VM’ye atanabilmesi de desteklenmeye başladı.
Bu özellik örneğin lokal DNS sunucusu veya Network Virtual Appliance çalıştırmak açısından kullanışlı olabilir.
Ancak Azure Arc tarafından yönetilen SDN kullanılan cluster’larda aynı özellik desteklenmiyor.
Bu tür detaylar bize Azure Local VM management özelliklerinin kullanılan platform sürümüne göre mutlaka kontrol edilmesi gerektiğini tekrar gösteriyor.
Storage Path sadece klasör seçmek değil
VM management tarafındaki üçüncü temel ortak kaynak Storage Path.
Storage Path, VM configuration dosyalarının, image’ların ve virtual disk’lerin Azure Local üzerindeki hangi storage alanında tutulacağını belirleyen Azure resource.
Storage Path’lerin Cluster Shared Volume üzerinde bulunması gerekiyor.
Bunun nedeni Azure Local cluster içerisindeki bütün node’ların ilgili storage alanına erişebilmesi.
Microsoft yüksek erişilebilirlik için storage path’lerin CSV altında oluşturulmasını öneriyor.
Burada önemli bir detay var.
Azure Local deployment sırasında altyapı bileşenleri için kullanılan Infrastructure_1 volume workload storage için kullanılmamalı.
Microsoft bu volume’un Azure Local infrastructure bileşenlerine ayrıldığını ve workload için kullanılmasının performans ve servis stabilitesi problemi oluşturabileceğini açıkça belirtiyor.
Dolayısıyla storage tasarımında platform storage ile workload storage’ı ayırmak gerekiyor.
Azure Local VM oluştururken storage path seçimini manuel yapabildiğimiz gibi otomatik placement da kullanılabiliyor.
Ayrıca VM’nin OS disk ve configuration dosyalarının bulunduğu storage path ile sonradan eklenen data disk’lerin storage path’leri aynı olmak zorunda değil.
Bu özellik özellikle birden fazla CSV bulunan ortamlarda önemli.
Örneğin yüksek performanslı workload’lar için ayrı storage volume, standart workload’lar için farklı volume kullanabilirsiniz.
Ancak self-service modelinde uygulama ekiplerine storage’ın fiziksel detaylarını tamamen açmak istemeyebilirsiniz.
Burada altyapı ekibinin standart storage path’leri hazırlaması ve kapasite kullanımını merkezi olarak takip etmesi daha doğru.
Çünkü RBAC, kullanıcının hangi işlemleri yapabileceğini kontrol ediyor.
Fiziksel storage’ın sonsuz olduğunu garanti etmiyor.
Azure RBAC self-service modelinin anahtarı
Self-service IaaS tarafındaki en önemli konulardan biri yetkilendirme.
Uygulama ekiplerine Azure Local cluster administrator yetkisi vermek istemiyoruz.
Fiziksel host’lara login olmalarını da istemiyoruz.
Failover Cluster Manager üzerinden cluster konfigürasyonu değiştirebilmelerini hiç istemiyoruz.
Ama kendi VM’lerini oluşturabilsinler.
VM’lerini yeniden başlatabilsinler.
Gerekirse silebilsinler.
Disk ve network interface yönetebilsinler.
Azure RBAC bu ayrımı yapmamıza imkan sağlıyor.
Microsoft Azure Local VM management için üç temel built-in rol sunuyor.
Azure Stack HCI Administrator
Bu rol Azure Local instance ve ilgili VM resource’ları üzerinde geniş yetkiye sahip.
Logical Network, VM Image ve Storage Path gibi shared resource’ları oluşturabiliyor.
Ayrıca diğer kullanıcılara VM Contributor veya VM Reader rolü atayabiliyor.
İsminde hala Azure Stack HCI bulunması eski ürün adlandırmasından geliyor.
Azure Stack HCI VM Contributor
Bu rol self-service senaryosu açısından en ilginç olanı.
Kullanıcı VM oluşturabiliyor, silebiliyor, start, stop ve restart gibi lifecycle işlemlerini gerçekleştirebiliyor.
VM’ye bağlı resource ve extension’ları yönetebiliyor.
Ancak Logical Network, VM Image ve Storage Path gibi sistem genelinde kullanılan shared resource’ları oluşturamıyor.
Bence doğru yetki ayrımının temeli burada.
Merkezi altyapı ekibi platformu ve ortak kaynakları hazırlıyor.
Uygulama ekibi bu kaynakları tüketiyor.
Azure Stack HCI VM Reader
Bu rol ise görüntüleme yetkisi sağlıyor.
Örneğin monitoring, denetim veya uygulama destek ekibine VM’leri ve ilgili kaynakları görüntüleme yetkisi verip değişiklik yapmasını engelleyebilirsiniz.
RBAC rolleri kullanıcı, grup, service principal ve managed identity’lere atanabiliyor.
Burada benim tavsiyem yetkileri mümkün olduğunca kullanıcı bazında değil grup bazında yönetmek.
Örneğin:
ERP-VM-Operators
HR-VM-Operators
AzureLocal-Platform-Admins
gibi gruplar oluşturmak uzun vadede kullanıcı hesaplarına tek tek rol atamaktan daha sağlıklı.
Bir diğer önemli konu scope.
Bir uygulama ekibine subscription seviyesinde VM Contributor vermek ile sadece kendi resource group’u üzerinde aynı rolü vermek arasında ciddi fark var.
Self-service modelinde mümkün olduğunca dar scope kullanmak gerekiyor.
Örneğin ERP ekibi sadece ERP-Production-RG içerisindeki VM kaynaklarını yönetebilmeli.
Başka uygulama ekiplerinin VM’lerini görmesine veya yönetmesine gerek yok.
Self-Service IaaS gerçekte nasıl çalışır?
Şimdi örnek bir kurum düşünelim.
Merkezi altyapı ekibimiz Azure Local platformunu yönetiyor.
ERP ekibimiz ise kendi uygulama sunucularından sorumlu.
Altyapı ekibi önce shared resource’ları oluşturuyor.
Windows Server 2025 standard image hazırlanıyor.
Production Logical Network tanımlanıyor.
Workload için uygun Storage Path oluşturuluyor.
ERP ekibi için ayrı Resource Group hazırlanıyor.
Ardından ERP ekibinin Entra grubuna bu resource group üzerinde Azure Stack HCI VM Contributor rolü atanıyor.
ERP ekibi artık Azure portal üzerinden kendi VM’sini oluşturabiliyor.
Örneğin:
ERP-APP01
4 vCPU
16 GB Memory
Windows Server 2025 Image
Production Logical Network
Standart Workload Storage Path
VM fiziksel olarak Azure Local üzerinde oluşturuluyor.
Ancak ERP ekibi fiziksel host’a login olmuyor.
Cluster Administrator değil.
Storage Spaces Direct konfigürasyonunu değiştiremiyor.
Network ATC üzerinde işlem yapamıyor.
Logical Network oluşturamıyor.
Sadece kendisine sunulan kaynaklarla VM oluşturuyor ve yaşam döngüsünü yönetiyor.
Bence gerçek self-service IaaS tanımına en fazla yaklaştığımız yer burası.
Altyapı kontrolünü devretmeden operasyonel özgürlük vermek.
Ancak self-service sınırsız kaynak tüketimi anlamına gelmemeli
Burada önemli bir risk var.
Bir uygulama ekibinin VM oluşturabiliyor olması istediği kadar CPU, memory ve storage tüketmesi gerektiği anlamına gelmiyor.
Azure RBAC bir authorization mekanizması.
Kullanıcının hangi işlemleri yapabileceğini belirliyor.
Ama fiziksel Azure Local cluster’ın kapasitesi yine sizin satın aldığınız donanımla sınırlı.
Public Azure ile Azure Local arasındaki en önemli farklardan biri burada.
Public Azure’da bir uygulama ekibi yeni VM oluşturduğunda Microsoft’un veri merkezindeki kapasiteyi kullanıyor.
Azure Local’da ise kaynak tüketimi sizin dört, sekiz veya on altı fiziksel node’unuzdan geliyor.
Örneğin uygulama ekibine VM Contributor verdiniz.
Ekip ihtiyaç oldukça yeni VM oluşturmaya başladı.
Bir süre sonra CPU kullanımınız yüzde 80’e geldi.
Memory kapasiteniz azaldı.
Storage pool dolmaya başladı.
Normal durumda sistem çalışıyor olabilir.
Ancak bir node’u maintenance için kapattığınızda kalan node’lar workload’ları taşıyamayabilir.
Dolayısıyla self-service ile capacity management beraber tasarlanmalı.
Ben burada standart VM sınıfları belirlemeyi faydalı buluyorum.
Örneğin:
Small: 2 vCPU / 8 GB
Medium: 4 vCPU / 16 GB
Large: 8 vCPU / 32 GB
XLarge: özel onay
Bunlar Azure Local’ın teknik zorunluluğu değil.
Kurumsal operasyon standardı.
Böyle bir model uygulama ekiplerinin rastgele 24 vCPU ve 128 GB memory’li VM oluşturmasını engellemek için iyi bir governance yaklaşımı sağlayabilir.
Büyük VM’ler için approval süreci uygulanabilir.
Self-service’in amacı kontrolsüzlük değil.
Tekrarlanan operasyonları kontrollü şekilde uygulama ekiplerine devretmek.
Guest Management ile VM Lifecycle aynı şey değil
Azure Local VM management tarafında zaman zaman karıştırılan başka bir konu Guest Management.
Azure Local VM oluşturduğunuzda VM üzerinde VM Guest Agent bulunuyor.
Microsoft bunu mocguestagent olarak adlandırıyor.
Guest Management etkinleştirildiğinde bu agent VM içerisine Azure Connected Machine Agent’ın kurulmasını sağlıyor.
Böylece VM artık sadece hypervisor seviyesinde Azure tarafından yönetilmiyor.
Guest işletim sistemi seviyesinde Azure Arc yeteneklerinden de faydalanabiliyor.
Örneğin desteklenen VM extension’ları kullanabilirsiniz.
Azure Monitor entegrasyonu gerçekleştirebilirsiniz.
Policy ve security servislerinden faydalanabilirsiniz.
Burada iki katman bulunuyor.
Birinci katman VM Lifecycle Management.
Start.
Stop.
CPU.
Memory.
Disk.
Network interface.
İkinci katman Guest Management.
İşletim sistemi içerisindeki Azure Arc agent ve extension yönetimi.
Bu ayrım troubleshooting sırasında oldukça önemli.
Örneğin VM Azure portal üzerinden başarılı şekilde start ve stop oluyor ancak bir extension kurulumu başarısız.
Bu durumda Azure Arc Resource Bridge çalışıyor olabilir.
VM lifecycle management tarafında problem olmayabilir.
Sorun guest operating system, Azure Connected Machine Agent veya VM’nin network connectivity tarafında olabilir.
Microsoft’un güncel dokümantasyonunda guest management etkinleştirmek için Azure Local VM’nin gerekli public network bağlantısına sahip olması gerektiği belirtiliyor.
Dolayısıyla VM’nin Azure Local üzerinde çalışıyor olması guest management servislerinin otomatik olarak çalışacağı anlamına gelmiyor.
Portal üzerinden oluşturulan VM’yi lokal araçlarla değiştirmek
Bence Azure Local VM management tarafında en dikkat edilmesi gereken operasyonel konulardan biri bu.
Bir administrator yıllardır Hyper-V yönettiyse VM üzerinde değişiklik yapmak için lokal araçları kullanması son derece doğal.
Ancak Azure Local VM enabled by Azure Arc modeliyle oluşturulan bir VM artık Azure control plane içerisinde de tanımlı.
Bu nedenle aynı VM’yi kontrolsüz şekilde hem Azure hem lokal araçlarla yönetmek configuration drift oluşturabilir.
Microsoft belirli operasyonların sadece Azure portal veya Azure CLI üzerinden yapılmasını istiyor.
Örneğin VM oluşturma, silme, start, stop, restart, network interface ekleme veya çıkarma, data disk ekleme veya silme, vCPU değiştirme, startup memory değiştirme ve extension yönetimi bu kapsama giriyor.
Bunları lokal Hyper-V araçlarıyla değiştirmek desteklenen yönetim modelini bozabilir.
Azure Local 2606 öncesinde bunun güzel bir örneği vardı.
vCPU veya startup memory değerini lokal araçla değiştirdiğinizde Azure’da kayıtlı konfigürasyon daha sonra tekrar uygulanabiliyor ve lokal değişiklik geri alınabiliyordu.
2606 sonrasında bazı davranışlar geliştirildi ancak temel prensip değişmedi.
Azure üzerinden yönetilen VM’nin temel lifecycle konfigürasyonunu mümkün olduğunca Azure management plane üzerinden yönetmek gerekiyor.
Bu, lokal araçların hiçbir zaman kullanılamayacağı anlamına gelmiyor.
Örneğin Live Migration Azure Local node’ları arasında Failover Cluster Manager veya Windows Admin Center gibi lokal araçlarla destekleniyor.
Microsoft ayrıca NUMA topology, processor reserve/limit/weight, bazı SCSI controller işlemleri, boot order, integration services, affinity/anti-affinity, nested virtualization ve shared storage gibi daha gelişmiş işlemler için Azure CLI veya desteklenen lokal yöntemler tanımlıyor.
Dolayısıyla burada yapılması gereken her şeyi portal üzerinden yapmak değil.
Hangi operasyonun hangi yönetim aracıyla desteklendiğini bilmek.
Self-service modelinde portal tek seçenek değil
Uygulama ekibinin Azure portal üzerinden VM oluşturması self-service açısından kolay ve anlaşılır.
Ancak büyük ortamlarda portal tek yönetim yöntemi olmamalı.
Önceki Azure Local Automation makalesinde Azure CLI, ARM, Bicep ve Terraform kullanımını detaylı olarak ele almıştık.
Aynı araçlar self-service modelini daha ileri seviyeye taşıyabilir.
Örneğin uygulama ekibinin standart üç katmanlı uygulaması olduğunu düşünelim.
Web VM.
Application VM.
Database VM.
Bunları her projede portal üzerinden tek tek oluşturmak yerine standart bir Bicep veya Terraform modülü hazırlanabilir.
Uygulama ekibi sadece gerekli parametreleri belirler.
Environment: Production
Location: Istanbul
Application: ERP
VM Size: Medium
Deployment pipeline gerekli VM’leri, network interface’leri ve diskleri oluşturabilir.
Bu durumda self-service sadece “portal erişimi” olmaktan çıkar.
Gerçek bir Infrastructure as Code servis modeline dönüşür.
Bence Azure Local’ın uzun vadede en güçlü kullanım modellerinden biri bu.
Özellikle onlarca lokasyon bulunan yapılarda merkezi altyapı ekibi standartları tanımlarken lokal veya uygulama ekipleri bu standartları tüketebilir.
Çok lokasyonlu yapılarda model daha anlamlı hale geliyor
Tek bir Azure Local cluster’ınız varsa klasik Hyper-V yönetim modeliyle de hayatınıza devam edebilirsiniz.
Azure Arc VM management yine faydalı olur ancak operasyonel fark sınırlı olabilir.
Ama 20 fabrika, 50 mağaza veya onlarca branch office bulunan bir yapı düşünelim.
Her lokasyonda Azure Local bulunuyor.
Merkezi altyapı ekibi bütün sistemlerden sorumlu.
Klasik yaklaşımda her lokasyon için farklı Hyper-V cluster’lara bağlanmak ve farklı yönetim operasyonları gerçekleştirmek gerekiyor.
Azure Local VM management modelinde ise Azure control plane ortak yönetim katmanı haline geliyor.
İstanbul’daki VM.
Ankara’daki VM.
İzmir’deki VM.
Hepsi Azure portal içerisinde resource olarak görülebiliyor.
Custom Location sayesinde hangi fiziksel lokasyonda çalıştıkları belli.
RBAC ile hangi ekibin hangi VM’leri yönetebileceği tanımlanabiliyor.
Infrastructure as Code ile farklı lokasyonlarda aynı VM standardı tekrar üretilebiliyor.
Bence Azure Local’ın “distributed infrastructure” yaklaşımının gerçek karşılığı da burada ortaya çıkıyor.
Fiziksel altyapı dağıtık.
Ama yönetim standardı dağıtık olmak zorunda değil.
Self-Service gerçekten altyapı ekibini ortadan kaldırmıyor
Self-service kavramı zaman zaman yanlış anlaşılıyor.
Uygulama ekibi VM oluşturabiliyor diye altyapı ekibine ihtiyaç kalmadığını düşünmek doğru değil.
Tam tersine altyapı ekibinin rolü değişiyor.
Eskiden altyapı ekibi sürekli VM oluşturuyordu.
Şimdi ise platformu hazırlıyor.
Image lifecycle’ı yönetiyor.
Logical Network standardını belirliyor.
Storage kapasitesini yönetiyor.
RBAC modelini tasarlıyor.
Azure Arc Resource Bridge health durumunu takip ediyor.
Cluster lifecycle ve update işlemlerini gerçekleştiriyor.
Capacity planning yapıyor.
Self-service sürecinin güvenli ve sürdürülebilir şekilde çalışmasını sağlıyor.
Bence bu operasyonel açıdan çok daha değerli.
Senior infrastructure mühendisinin zamanını sürekli 4 vCPU / 16 GB RAM’li VM oluşturmak için kullanmak yerine platform mimarisini yönetmek çok daha doğru.
Uygulama ekibi ise altyapı değişikliği için her seferinde ticket açmak zorunda kalmıyor.
İhtiyaç duyduğu kaynakları kendisine verilen sınırlar içerisinde oluşturabiliyor.
Her iki taraf için de daha verimli bir model.
Ama bunun çalışması için sınırların doğru çizilmesi gerekiyor.
Self-service ile administrator yetkisini birbirine karıştırmamak lazım.
Uygulama ekiplerine fiziksel Azure Local cluster yönetimi değil, kontrollü VM lifecycle yetkisi veriyoruz.
Ben olsam nasıl başlardım?
Mevcut bir Azure Local ortamında Azure Arc tabanlı self-service VM modeline geçecek olsam bütün uygulama ekiplerini ilk gün sisteme açmazdım.
Önce küçük bir pilot yapardım.
Bir application team seçerdim.
Standart iki veya üç VM image hazırlardım.
Production ve Test Logical Network kaynaklarını oluştururdum.
Workload Storage Path’lerini tanımlardım.
Uygulama ekibi için ayrı Resource Group oluştururdum.
Entra grubu üzerinden VM Contributor yetkisi verirdim.
Ardından ekibin gerçek kullanımını izlerdim.
Nerede altyapı ekibine geri dönüyorlar?
Yeni image mı istiyorlar?
Network ihtiyacı mı çıkıyor?
Storage seçimi mi problem oluyor?
VM boyutları mı kontrolsüz büyüyor?
Guest management çalışıyor mu?
Backup sistemi yeni VM’leri otomatik olarak kapsamına alıyor mu?
Monitoring ve security agent’ları doğru şekilde deploy ediliyor mu?
Bunları çözdükten sonra modeli diğer ekiplere açardım.
Çünkü başarılı self-service, kullanıcının VM oluşturabilmesi değil.
VM oluşturduktan sonra sistemin kurumun bütün operasyon standartlarına otomatik veya kontrollü şekilde dahil olabilmesi.
Backup yoksa self-service eksik.
Monitoring yoksa eksik.
Security standardı uygulanmıyorsa eksik.
Capacity kontrolü yoksa eksik.
Lifecycle belirlenmemişse eksik.
Azure Arc ve Azure Local bize bu modelin altyapısını sağlıyor.
Ama kurumsal operasyon modelini yine bizim tasarlamamız gerekiyor.
Azure Local VM management tarafının benim için en önemli sonucu şu:
Kendi veri merkezimizde çalışan sanal makineleri artık klasik anlamda sadece Hyper-V nesneleri olarak görmek zorunda değiliz.
Bu makineler Azure Resource Manager içerisinde yönetilen kaynaklara dönüşebiliyor.
Azure RBAC ile yetkilendirilebiliyor.
Azure CLI, ARM, Bicep ve Terraform ile otomatik oluşturulabiliyor.
Logical Network, VM Image ve Storage Path gibi standart kaynakları tüketebiliyor.
Guest Management ile Azure Arc servislerinden faydalanabiliyor.
Ve bütün bunlar yapılırken workload fiziksel olarak kurumun kendi altyapısında çalışmaya devam ediyor.
Bence Azure Local’ın cloud operating model yaklaşımını en net gösteren özelliklerden biri de bu.
Cloud’a taşımadan cloud tipi işletim modeli oluşturmak.
Bir sonraki makalede ise bu modelin network güvenliği tarafına geçeceğim: Azure Local SDN, NSG ve Mikro Segmentasyon. Azure Local üzerinde workload network’lerinin nasıl yönetildiğini, NSG ile VM seviyesinde trafik kontrolünün nasıl yapılabildiğini ve özellikle east-west trafiğin sınırlandırılmasının lateral movement riskini nasıl azaltabileceğini inceleyeceğiz.
Kullanılan temel Microsoft kaynakları
Bu makale 26 Ekim 2026 itibarıyla erişilebilir resmi Microsoft dokümantasyonu esas alınarak hazırlanmıştır.
- What is Azure Local VM management?
- Azure Arc resource bridge overview
- Compare management capabilities of VMs on Azure Local
- Use Role-based Access Control to manage Azure Local VMs enabled by Azure Arc
- Create logical networks for Azure Local VMs enabled by Azure Arc
- Create storage path for Azure Local
- Manage Azure Local VM images via CLI or portal
- Manage Azure Local VMs enabled by Azure Arc
- Supported operations for Azure Local VMs enabled by Azure Arc
Özellikle Azure Local VM management, guest management, Logical Network ve desteklenen operasyonlarda sürüme bağlı farklılıklar bulunduğu için production deployment öncesinde kullanılan Azure Local sürümünün güncel supported operations ve known issues dokümantasyonunun ayrıca kontrol edilmesi gerekiyor.
