Azure Local Kurulum Öncesi Hazırlık ve Readiness Assessment

Önceki makalelerde Azure Local mimarisini, kapasite planlamasını, donanım seçimini ve lisanslama tarafını ele aldık. Donanımlar veri merkezine geldiğinde ise insanın doğal olarak bir an önce kuruluma başlama isteği oluyor. Bana göre Azure Local projelerinde en fazla direnmemiz gereken konu da bu.

Çünkü Azure Local deployment sırasında gördüğümüz problemlerin önemli bir bölümü aslında deployment problemi değil.

DNS doğru çalışmıyor, NTP erişilemiyor, firewall üzerinde gerekli Azure adreslerinden biri kapalı, SSL inspection açık, Active Directory tarafında yanlış GPO uygulanıyor veya switch konfigürasyonu tasarlanan network yapısıyla uyuşmuyor. Bunların hepsi deployment ekranında hata olarak karşımıza çıkıyor ama aslında kurulum başlamadan önce çözülmesi gereken altyapı problemleri.

Microsoft da bu nedenle Azure Local içerisinde oldukça kapsamlı bir validation mekanizması kullanıyor. Hatta Environment Checker aracını gerçek donanımlar gelmeden önce bile çalıştırıp connectivity gereksinimlerini kontrol etmek mümkün.

Ben bir Azure Local projesinde kuruluma başlamadan önce işi birkaç ayrı katmanda kontrol etmeyi tercih ediyorum: Azure subscription, Active Directory, DNS ve zaman senkronizasyonu, internet erişimi ve firewall, fiziksel donanım ile firmware, son olarak da network.

Bunlardan biri hazır değilse deployment’a başlamanın çok anlamı yok.

Önce Azure tarafını hazırlayın

Azure Local on-premises ortamda çalışan bir altyapı olmasına rağmen control plane tarafında Azure ile oldukça sıkı bir ilişkisi var. Bu nedenle ilk hazırlık aslında veri merkezinde değil Azure subscription içerisinde başlıyor.

Azure Local makinelerinin Azure Arc’a kaydedilebilmesi ve deployment’ın gerçekleştirilebilmesi için subscription üzerinde gerekli resource provider’ların kayıtlı olması gerekiyor.

Microsoft’un Ağustos 2026 itibarıyla güncel dokümantasyonunda standart Azure Local deployment için Microsoft.HybridCompute, Microsoft.GuestConfiguration, Microsoft.HybridConnectivity, Microsoft.AzureStackHCI, Microsoft.Kubernetes, Microsoft.KubernetesConfiguration, Microsoft.ExtendedLocation, Microsoft.ResourceConnector, Microsoft.HybridContainerService, Microsoft.Attestation, Microsoft.Storage, Microsoft.Insights ve Microsoft.KeyVault gibi provider’ların kaydedilmesi isteniyor.

Burada benim tavsiyem bunları deployment günü kontrol etmemek.

Özellikle büyük şirketlerde Azure subscription üzerinde sizin Owner yetkiniz olmayabilir. Cloud ekibine ticket açmanız, security ekibinden onay almanız veya farklı bir ekip tarafından resource provider registration yapılması gerekebilir.

Dört Azure Local node rack içerisinde sizi beklerken şirket içindeki yetki sürecinin tamamlanmasını beklemek istemezsiniz.

Microsoft da dokümantasyonunda subscription üzerinde resource provider kaydını yapan kişi ile Azure Local makinelerini Arc’a kaydeden kişinin farklı kişiler olabileceğini özellikle belirtiyor.

Yani Azure Local projesinde teknik tasarım dokümanına sadece IP adreslerini ve VLAN’ları değil, Azure tarafındaki yetki modelini de eklemek gerekiyor.

Hangi subscription kullanılacak?

Resource group nerede oluşturulacak?

Azure region ne olacak?

Kim resource provider registration yapacak?

Deployment işlemini hangi kullanıcı gerçekleştirecek?

Bu soruların cevabı kurulum gününden önce belli olmalı.

Active Directory tarafını hafife almayın

Azure Local deployment için mevcut Active Directory Domain Services ortamınızı kullanıyor. Microsoft deployment öncesinde Azure Local için özel bir Organizational Unit oluşturulmasını ve gerekli AD hazırlık işlemlerinin yapılmasını istiyor.

Burada özellikle GPO konusu önemli.

Azure Local node’larını mevcut server OU’nuzun altına koyup şirket içerisinde bütün Windows Server sistemlerine uyguladığınız GPO’ları doğrudan bu sunuculara uygulamak iyi bir fikir değil.

Microsoft Azure Local için ayrılmış bir OU kullanılmasını ve bu OU üzerinde Group Policy inheritance’ın engellenmesini öneriyor. Bunun nedeni mevcut domain politikalarının Azure Local tarafından yönetilen güvenlik ve sistem ayarlarıyla çakışma ihtimali.

Bu, Azure Local node’larına hiçbir zaman GPO uygulanamaz anlamına gelmiyor. Ancak ne uyguladığınızı bilmeniz gerekiyor.

Örneğin şirketinizde bütün Windows sunucularında WinRM’i kapatan veya firewall kurallarını değiştiren bir hardening GPO’su varsa bunun Azure Local node’larına uygulanması deployment’ı doğrudan bozabilir.

Ben burada mümkün olduğunca temiz bir OU ile başlamayı tercih ederim. Sistem başarılı şekilde deploy edildikten sonra kurumun güvenlik gereksinimlerini tek tek değerlendirip Microsoft’un desteklediği sınırlar içerisinde gerekli politikaları uygulamak çok daha sağlıklı.

AD hazırlığının doğru yapıldığını kontrol etmek için Environment Checker içerisinde ayrı bir Active Directory validator da bulunuyor. Microsoft’un güncel örneğinde Invoke-AzStackHciExternalActiveDirectoryValidation komutu ile OU path, domain FQDN, naming prefix, cluster name ve fiziksel node isimleri kontrol edilebiliyor. Validator ayrıca gerekli Active Directory ve GPO PowerShell modüllerini de kontrol ediyor.

Burada naming standardını da baştan belirlemek gerekiyor.

Azure Local deployment user, OU name, deployment prefix, instance name ve fiziksel node object’leri için Microsoft’un belirlediği uniqueness ve naming gereksinimleri var. Örneğin deployment prefix maksimum sekiz karakter olabiliyor.

Bunlar küçük detaylar gibi görünüyor ama deployment sırasında isim değiştirmeye çalışmak gereksiz zaman kaybettiriyor.

DNS ve NTP çalışıyor mu?

Ben yeni bir altyapı kurulurken network ekibine “DNS çalışıyor mu?” diye sormayı çok anlamlı bulmuyorum. Cevap zaten genellikle “çalışıyor” oluyor.

Asıl soru Azure Local node’larının ihtiyaç duyduğu DNS çözümlemelerini doğru yapıp yapamadığı.

Azure Local’ın Azure servisleriyle iletişim kurabilmesi için çok sayıda public endpoint’in doğru şekilde resolve edilmesi gerekiyor. Aynı şekilde node’ların Active Directory domain controller’lara ulaşması ve AD servislerini çözümleyebilmesi lazım.

DNS tarafındaki küçük bir hata Arc registration, Azure Resource Bridge, update veya deployment aşamasında tamamen farklı bir hata mesajıyla karşınıza çıkabiliyor.

Environment Checker’ın güzel taraflarından biri de tam olarak bu. Microsoft aracın yanlış yapılandırılmış firewall URL’leri ve hatalı DNS gibi küçük ama deployment’ı engelleyebilecek sorunları daha kurulum başlamadan tespit etmek amacıyla kullanılabileceğini belirtiyor.

Zaman senkronizasyonu da benzer şekilde kritik.

Active Directory zaten Kerberos nedeniyle doğru zaman senkronizasyonuna ihtiyaç duyuyor. Azure tarafındaki authentication ve certificate işlemleri de zaman farklarına karşı hassas.

Microsoft’un Azure Local firewall gereksinimlerinde W32Time için UDP 123 trafiği açıkça listeleniyor. AD iletişimi için DNS 53, Kerberos 88, LDAP 389, SMB 445, RPC 135 ve AD Web Services 9389 gibi gerekli portların da erişilebilir olması gerekiyor.

Yani “node domain’e join oldu, AD tarafı tamamdır” demek yeterli değil.

Firewall tarafı sadece 443 açmaktan ibaret değil

Azure Local deployment’larında benim özellikle önceden kontrol edeceğim konulardan biri firewall.

Burada çok sık yapılan hata şu:

“Azure’a çıkacak, outbound 443 açık, sorun olmaz.”

Maalesef bu kadar basit değil.

Azure Local makineleri sadece tek bir Azure endpoint’ine bağlanmıyor. Azure Local’ın kendisi yanında Azure Arc-enabled Servers, Azure Resource Bridge ve AKS infrastructure için gerekli endpoint’lerin de firewall allow list içerisinde bulunması gerekiyor.

Microsoft bunun için region bazında consolidated endpoint listeleri yayınlıyor. Örneğin East US, West Europe ve Australia East için Azure Local, Arc, ARB ve AKS endpoint’lerini içeren toplu listeler mevcut.

Özellikle Türkiye’deki kurumsal müşterilerde gördüğümüz bir diğer konu proxy ve SSL inspection.

Security ekipleri doğal olarak internet trafiğini kontrol etmek istiyor. Ancak Azure Local için bu noktada önemli bir sınırlama var:

Microsoft, Azure Local node’ları ile gerekli public endpoint’ler arasındaki network yolunda SSL/TLS packet inspection desteklemiyor.

Private Link ve ExpressRoute da Azure Local’ın ihtiyaç duyduğu public endpoint bağlantısının yerine kullanılamıyor.

Bu çok önemli.

Firewall üzerinde URL’leri açmış olabilirsiniz ama HTTPS inspection yapılıyorsa certificate chain değiştiği için deployment yine başarısız olabilir.

Bu nedenle security ekibiyle daha proje başlamadan konuşmak gerekiyor. “Kurulum günü firewall’da bakarız” Azure Local için iyi bir proje yaklaşımı değil.

Microsoft ayrıca Azure Arc Gateway kullanılmasını da öneriyor. Arc Gateway, Azure Local deployment ve yönetimi için firewall veya proxy üzerinde izin verilmesi gereken endpoint sayısını ciddi şekilde azaltabiliyor.

Çok sıkı outbound internet politikası bulunan büyük yapılarda ben bu seçeneği mutlaka değerlendirirdim.

Donanım geldi diye hemen OS kurmayın

Bir önceki makalede Azure Local Catalog ve validated hardware konusunu detaylı anlatmıştım. Deployment öncesinde bunun bir kez daha kontrol edilmesi gerekiyor.

Sipariş ettiğiniz model Azure Local Catalog içerisinde olabilir ama önemli olan sadece model adı değil.

BIOS sürümü nedir?

NIC firmware hangi versiyonda?

Storage controller firmware güncel mi?

Disk firmware’leri desteklenen seviyede mi?

OEM Solution Builder Extension hangi versiyonu bekliyor?

Özellikle sunucuların üretim tarihi ile sizin deployment tarihiniz arasında birkaç ay varsa fabrikadan çıkan firmware seviyesinin güncel Azure Local release’i için önerilen seviyeden geri olması son derece normal.

Bu nedenle kutuyu açıp network kablolarını taktıktan sonra deployment’a başlamak yerine OEM’in Azure Local deployment guide’ını ve güncel firmware/driver matriksini kontrol etmek gerekiyor.

Environment Checker içerisinde hardware validator da bulunuyor. Bu validator fiziksel makinelerin ve donanım bileşenlerinin Azure Local system requirements ile uyumluluğunu kontrol ediyor.

Ama yine aynı noktaya geliyoruz.

Validator’ın hata vermesini beklemek yerine hazırlığı önceden yapmak daha doğru.

Network tarafını kağıt üzerinde bitirmeden deployment’a başlamayın

Azure Local network tasarımı başlı başına ayrı bir makale konusu ve bir sonraki yazıda Network ATC, network intent, RDMA, RoCEv2, iWARP ve storage network tasarımına detaylı gireceğim.

Ancak deployment öncesinde bazı kararların kesinleşmiş olması gerekiyor.

Hangi fiziksel NIC hangi amaçla kullanılacak?

Management ve compute aynı NIC’leri mi paylaşacak?

Storage için ayrı adapter olacak mı?

RDMA kullanılacak mı?

RoCEv2 ise switch tarafındaki DCB/PFC konfigürasyonu hazır mı?

Storage network switchless mı olacak?

Hangi VLAN hangi intent üzerinde kullanılacak?

Management IP’leri, storage IP’leri ve infrastructure IP pool nedir?

Bunları deployment ekranında karar vermeye çalışmamak gerekiyor.

Özellikle network ekibi ile Azure Local’ı kuran ekip farklıysa mutlaka ortak bir network design dokümanı hazırlanmasını tavsiye ederim.

Çünkü Azure Local tarafında doğru olduğunu düşündüğünüz konfigürasyon ile fiziksel switch üzerindeki gerçek konfigürasyon farklıysa validation zaten sizi durduracak.

Bu aslında iyi bir şey.

Kurulumun tamamlanıp üretimde problem yaşamasındansa deployment’ın sizi durdurması çok daha sağlıklı.

Environment Checker’ı deployment ekranında ilk kez görmeyin

Bence Azure Local hazırlığındaki en faydalı araçlardan biri Environment Checker.

Microsoft bunu iki farklı şekilde sunuyor.

Birincisi deployment sürecine entegre çalışan validator. Deployment sırasında gerekli kontroller otomatik olarak gerçekleştiriliyor.

İkincisi ise standalone Environment Checker.

Standalone sürüm PowerShell Gallery üzerinden indirilebiliyor ve deployment sürecinden bağımsız çalıştırılabiliyor. Daha da güzeli gerçek Azure Local donanımları gelmeden önce network içerisindeki başka bir client veya staging server üzerinden connectivity kontrollerini gerçekleştirebiliyorsunuz.

Kurulum için şu modül kullanılıyor:

Install-Module -Name AzStackHci.EnvironmentChecker

Environment Checker ile Active Directory, network, hardware ve diğer deployment prerequisite’leri kontrol edilebiliyor.

Sonuçlar Success, Critical, Warning ve Informational şeklinde sınıflandırılıyor. Critical sonuçlar deployment öncesinde düzeltilmesi gereken blocking problemlere işaret ediyor.

Ben olsam gerçek deployment gününden birkaç gün önce Environment Checker çalıştırır, bütün Critical sonuçları kapatır ve Warning sonuçlarını da tek tek incelerdim.

Bir önemli detay daha var.

Environment Checker’ı Azure Local node’larından birine manuel olarak kurduysanız deployment öncesinde kaldırmanız gerekiyor. Microsoft, Azure Local içerisinde Environment Checker zaten bulunduğu için manuel yüklenen sürümün potansiyel conflict yaratabileceğini açıkça belirtiyor.

Kaldırmak için Microsoft’un verdiği komutlar şöyle:

Remove-Module AzStackHci.EnvironmentChecker -Force

Get-Module AzStackHci.EnvironmentChecker -ListAvailable |
Where-Object {$_.Path -like "*$($_.Version)*"} |
Uninstall-Module -Force

Bir başka önemli nokta da Environment Checker sonucunun bir sertifika olmaması.

Bugün bütün testlerden geçmeniz yarın da geçeceğiniz anlamına gelmiyor.

Microsoft da Environment Checker sonuçlarının çalıştırıldığı andaki konfigürasyonu gösterdiğini özellikle belirtiyor. Sonrasında AD, firewall veya network üzerinde yapılan bir değişiklik daha önce başarılı olan bir kontrolün Critical hale gelmesine neden olabilir.

Bu nedenle validation’ı yaptıktan sonra deployment’a kadar geçen sürede ilgili VLAN, firewall ve GPO konfigürasyonlarının change control altına alınması bence iyi bir uygulama.

Benim deployment öncesi kontrol sıram

Azure Local kurulumu yapacak olsam deployment butonuna basmadan önce kontrol sıram kabaca şöyle olurdu:

Önce Azure subscription, resource provider ve yetkileri doğrularım. Ardından Azure Local için ayrılmış AD OU’sunu, deployment account’u ve GPO inheritance durumunu kontrol ederim. DNS resolution ve NTP erişimini test ederim.

Sonrasında firewall ve proxy tarafına geçerim. Microsoft’un güncel region-specific endpoint listesini network ekibiyle beraber kontrol eder, SSL inspection olmadığını doğrularım. Proxy kullanılacaksa Azure Local proxy gereksinimlerine göre yapılandırıldığından emin olurum.

Fiziksel tarafta Azure Local Catalog’daki exact hardware configuration ile elimdeki donanımı karşılaştırırım. BIOS, firmware ve driver seviyelerini OEM dokümanıyla kontrol ederim.

Ardından network tasarımını switch konfigürasyonuyla bire bir karşılaştırırım.

Son olarak standalone Environment Checker çalıştırırım.

Critical hata varsa deployment’a başlamam.

Bence bu son cümle önemli.

Azure Local deployment sürecinde “bir başlayalım, hata çıkarsa bakarız” yaklaşımı çok fazla zaman kaybettirebilir. Deployment bazı aşamalarda oldukça uzun sürebiliyor ve yanlış temel konfigürasyon nedeniyle işlemin ileri bir noktada durması, problemi düzelttikten sonra tekrar validation ve deployment süreçleriyle uğraşmanız anlamına geliyor.

Halbuki Microsoft’un bize verdiği Environment Checker tam olarak bunu önlemek için var.

Özetle Azure Local kurulumu sunucular rack’e takıldığında başlamıyor. Bana göre gerçek deployment bundan birkaç hafta önce Azure, AD, network, security ve donanım ekiplerinin aynı tasarım üzerinde anlaşmasıyla başlıyor.

Bu hazırlığı düzgün yaptığınızda portal üzerinden yapılan deployment işin nispeten kolay kısmı haline geliyor.

Bir sonraki makalede özellikle network tarafına gireceğim. Çünkü Azure Local’da performans ve stabiliteyi en fazla etkileyen katmanlardan biri burası. Network ATC’nin ne yaptığını, network intent kavramını, management/compute/storage trafiğinin nasıl tasarlanması gerektiğini ve özellikle RDMA tarafında RoCEv2 ile iWARP seçimlerinin sahada ne anlama geldiğini inceleyeceğiz.

Kullandığım temel Microsoft kaynakları: Azure Local Environment Checker, Azure Local Firewall Requirements, Azure Local Arc Registration and Deployment Permissions ve Azure Local Baseline Reference Architecture.