Azure Local Sorun Giderme Rehberi

Azure Local kurulumu tamamlandıktan sonra karşılaşılan sorunlar, çoğu zaman tek bir bileşenden kaynaklanmaz. Ağ yapılandırması, Active Directory, Azure bağlantısı, Arc bileşenleri, güncelleme servisleri ve yaşam döngüsü yönetimi aynı süreç içinde birlikte çalışır.

Bu nedenle portalda görülen hata mesajları çoğu zaman yalnızca sorunun sonucunu gösterir. Asıl neden ise node üzerindeki loglarda, Environment Checker raporlarında veya Azure Local destek araçlarının çıktılarında bulunur.

Doğru yaklaşım; destek kaydını zamanında açmak, gerekli logları toplamak, tanılama araçlarını çalıştırmak ve elde edilen bulguları birlikte değerlendirmektir.

Azure Local sorunlarında kullanılabilecek dört kaynak

Azure Local sorunlarını araştırırken yalnızca portal hata mesajına bağlı kalmamak gerekir. Genellikle dört farklı kaynak birlikte kullanılmalıdır.

Kaynak	Kullanım amacı
Microsoft destek kaydı	Üretim ortamı sorunları ve ürün hataları
Azure Local topluluğu	Benzer sorunları yaşayan kullanıcıların deneyimleri
Azure Local Supportability deposu	Bilinen hata ve çözüm dokümanları
CSSTools tanılama modülü	Ortamı otomatik analiz etmek ve rapor üretmek

Bu kaynaklar birbirinin alternatifi değildir. Örneğin destek kaydı açıkken Supportability deposu incelenebilir, CSSTools çalıştırılabilir ve topluluk üzerinden aynı hatanın başka ortamlarda yaşanıp yaşanmadığı kontrol edilebilir.

Log toplama işlemi

Azure Local ortamı başarıyla dağıtılmış ve Azure’a kayıtlıysa, tanılama verileri Send-DiagnosticData komutuyla toplanabilir.

Son bir saat içindeki logları toplamak için:

Send-DiagnosticData

Belirli bir zaman aralığı için:

Send-DiagnosticData `
    -FromDate (Get-Date).AddHours(-2) `
    -ToDate (Get-Date)

Yalnızca belirli bileşenlere ait logları toplamak için:

Send-DiagnosticData `
    -FilterByRole BareMetal,ECE `
    -CollectSddc $false

Burada önemli olan nokta, mümkün olduğunca dar bir zaman aralığı kullanmaktır. Tüm günün loglarını toplamak yerine, hatanın oluştuğu zamanı kapsayan kısa bir aralık seçmek hem işlemi hızlandırır hem de destek mühendislerinin incelemesini kolaylaştırır.

Komut çalıştırıldığında genellikle aşağıdaki bilgileri içeren bir çıktı üretilir:

• Correlation ID
• Azure bölgesi
• Azure Local cluster kaynak URI’si
• Node kaynak URI’si

Correlation ID, Microsoft destek ekibinin gönderilen log koleksiyonunu bulabilmesi için kritik öneme sahiptir. Bu nedenle çıktıyı destek kaydına mutlaka eklemek gerekir.

Daha önce gerçekleştirilen log toplama işlemlerini görmek için:

Get-LogCollectionHistory

Sistem henüz Azure’a kayıtlı değilse

Kurulum veya kayıt aşamasında hata oluştuğunda Send-DiagnosticData komutu kullanılamayabilir. Çünkü bu aşamada Telemetry and Diagnostics eklentisi henüz kurulmamış veya sağlıklı çalışmıyor olabilir.

Bu durumda bağımsız tanılama komutu kullanılabilir:

Send-AzStackHciDiagnosticData `
    -ResourceGroupName <ResourceGroupName> `
    -SubscriptionId <SubscriptionId> `
    -TenantId <TenantId> `
    -RegistrationWithDeviceCode `
    -DiagnosticLogPath <LogPath> `
    -RegistrationRegion <RegionName> `
    -Cloud AzureCloud

Bu yöntem özellikle şu durumlarda kullanılabilir:

• Azure Local kurulumu tamamlanamıyorsa
• Azure kaydı başarısız oluyorsa
• Arc bağlantısı kurulmadan önce hata oluşuyorsa
• Telemetry bileşeni çalışmıyorsa
• Ortam doğrulaması sırasında deployment duruyorsa

Ağ bağlantısı sorunlarında logları yerel olarak saklama

Azure Local node’larının dış dünyaya erişimi yoksa veya logların Microsoft’a gönderilmesi engelleniyorsa, tanılama verileri yerel bir paylaşım alanına kaydedilebilir.

Send-DiagnosticData `
    -SaveToPath <PaylasimYolu> `
    -ShareCredential $shareCredential

Bağlantı yeniden sağlandıktan sonra daha önce toplanan loglar Microsoft’a gönderilebilir:

Send-DiagnosticData `
    -NoLogCollection `
    -SupplementaryLogs <PaylasimYolu> `
    -ShareCredential $shareCredential

Bu senaryoda dosyaların üzerine yazılmaması ve destek kaydıyla ilişkilendirilecek bilgilerin korunması önemlidir.

CSSTools ile otomatik ortam analizi

Microsoft tarafından sağlanan Microsoft.AzLocal.CSSTools modülü, Azure Local ortamındaki birçok bileşeni otomatik olarak kontrol eder.

Modülü yüklemek için:

Install-Module -Name Microsoft.AzLocal.CSSTools -Force
Import-Module -Name Microsoft.AzLocal.CSSTools -Force

Modül güncellendiğinde mevcut PowerShell oturumunda eski sürüm yüklü kalabilir. Bu nedenle güncelleme sonrasında modülü kaldırıp yeniden yüklemek gerekir:

Update-Module -Name Microsoft.AzLocal.CSSTools

Remove-Module -Name Microsoft.AzLocal.CSSTools

Import-Module -Name Microsoft.AzLocal.CSSTools

Tüm cluster node’larını analiz etmek için:

Invoke-AzsSupportInsight `
    -ComputerName (Get-ClusterNode).Name

Bu komut aşağıdaki alanlarda kontroller gerçekleştirir:

• Host Compute
• Host Network
• Host Storage
• Lifecycle Orchestration
• Operating System
• Virtual Machines
• Known Issues
• Control Plane Operations

Komutun sonunda özet sonuçların yanı sıra HTML formatında ayrıntılı bir rapor oluşturulur. Bu rapor, destek kaydına eklenebileceği gibi daha sonra karşılaştırma yapmak amacıyla da saklanabilir.

Belirli bir bileşeni kontrol etmek için:

Invoke-AzsSupportInsight `
    -Component HostNetwork

Birden fazla bileşen için:

Invoke-AzsSupportInsight `
    -Component LifecycleOrchestration,HostNetwork

Sağlıklı bir Azure Local cluster üzerinde bu raporu bir kez oluşturmak oldukça faydalıdır. Böylece ileride oluşan hatalarda mevcut durum, sağlıklı durumla karşılaştırılabilir.

Otomatik düzeltmeleri dikkatli kullanın

CSSTools bazı bulgular için düzeltme komutları da sağlayabilir.

Örneğin:

Invoke-AzsSupportInsightRemediation `
    -ScriptName "ClearTrustedHostsWildcard"

Ancak düzeltme komutları yalnızca ilgili analiz sonucu açıkça öneriyorsa kullanılmalıdır. Tanılama yapılmadan rastgele remediation çalıştırmak, sorunu çözmek yerine yeni bir yapılandırma problemi oluşturabilir.

Özellikle aşağıdaki işlemler destek yönlendirmesi olmadan uygulanmamalıdır:

• WinRM ve CredSSP ayarlarının değiştirilmesi
• ECE action plan temizliği
• Azure Local hesaplarının kilidinin açılması
• Azure CLI eklentilerinin kaldırılması
• Cluster veya node yapılandırmasının değiştirilmesi

Üretim ortamında değişiklik yapan komutlar çalıştırılmadan önce mevcut yapılandırmanın ve logların yedeklenmesi gerekir.

Önemli log konumları

Portalda görülen hata çok kısa olabilir. Asıl hata ayrıntısı çoğu zaman node üzerindeki log dosyalarında bulunur.

Deployment ve yaşam döngüsü logları

Konum	İçerik
C:\MASLogs	LCM ve deployment logları
C:\MASLogs\LCMECELitelogs	ECE Lite ve initialization kayıtları
C:\CloudDeployment\Logs	Action plan ve deployment işlemleri
C:\Users\lcmuser\.AzStackHci	Environment Checker çıktıları
C:\CloudContent\MASLogs	Ortam doğrulama logları
C:\CloudContent\MASLogs\SBELogs	Solution Builder Extension logları

Deployment veya güncelleme sırasında hata oluştuğunda ilk incelenmesi gereken konumlar genellikle C:\MASLogs ve C:\CloudDeployment\Logs klasörleridir.

Azure bağlantısı ve izleme logları

Konum	İçerik
C:\Observability	Tanılama verilerinin hazırlanmış kopyaları
C:\GMACache\TelemetryCache	Azure’a gönderilemeyen telemetry verileri
C:\ProgramData\AzureConnectedMachineAgent\Log	Arc Connected Machine Agent logları
C:\Packages\Plugins	Azure Local uzantıları ve eklenti logları

GMACache klasörünün sürekli büyümesi, node’un Azure’a veri gönderemediğini gösterebilir. Bu durumda klasörü silmek yerine, outbound bağlantı ve endpoint erişimleri kontrol edilmelidir.

Windows Event Viewer

Azure Local sorunlarında aşağıdaki Windows event log özellikle önemlidir:

• Microsoft-AzureStack-Hci/Admin
• Microsoft-Windows-FailoverClustering/Operational
• Microsoft-Windows-StorageSpaces-Driver/Operational
• Microsoft-Windows-Networking-NetworkATC/Operational
• Microsoft-Windows-Health/Operational

Cluster node’larından son hata ve uyarıları toplamak için:

Invoke-Command -ComputerName (Get-ClusterNode).Name -ScriptBlock {
    Get-WinEvent `
        -LogName 'Microsoft-AzureStack-Hci/Admin' `
        -MaxEvents 50 `
        -ErrorAction SilentlyContinue |
    Where-Object LevelDisplayName -in 'Error','Warning'
} |
Sort-Object TimeCreated -Descending |
Format-Table PSComputerName,TimeCreated,Id,LevelDisplayName -AutoSize

Bu yöntem, her node’a tek tek bağlanmak yerine tüm cluster genelindeki kayıtları merkezi olarak incelemeyi sağlar.

Örnek sorun giderme akışı

Bir Azure Local güncellemesinin belirli bir aşamada durduğunu varsayalım.

İzlenebilecek yol şu şekilde olmalıdır:

1. Microsoft destek kaydı açılır.
2. Hatanın oluştuğu zamanı kapsayan loglar toplanır.
3. Correlation ID destek kaydına eklenir.
4. Invoke-AzsSupportInsight ile LifecycleOrchestration ve KnownIssues kontrolleri çalıştırılır.
5. Hata mesajındaki görev veya rol adı Supportability deposunda aranır.
6. C:\MASLogs ve C:\CloudDeployment\Logs klasörleri incelenir.
7. Azure Local topluluğunda aynı build ile ilgili benzer sorunlar araştırılır.
8. Yalnızca dokümanda veya tanılama çıktısında önerilen çözüm uygulanır.
9. Sonuç, başarılı veya başarısız olması fark etmeksizin destek kaydına eklenir.

Bu sıra, rastgele komut denemek yerine kontrollü ve izlenebilir bir sorun giderme süreci oluşturur.

Azure Local sorunlarında en büyük hata, yalnızca portalda görülen hata mesajına odaklanmaktır. Başarılı bir analiz için destek kaydı, loglar, otomatik tanılama araçları, Supportability dokümanları ve topluluk deneyimleri birlikte kullanılmalıdır.

En önemli noktalar şunlardır:

• Destek kaydını en başta açın.
• Logları mümkün olduğunca erken ve dar zaman aralığıyla toplayın.
• Correlation ID bilgisini kaybetmeyin.
• Sağlıklı cluster üzerinde CSSTools temel raporu oluşturun.
• C:\MASLogs ve C:\CloudDeployment\Logs klasörlerini bilin.
• Remediation komutlarını yalnızca doğrulanmış bulgular sonrasında çalıştırın.
• Çözdüğünüz sorunları dokümante edin.

Azure Local ortamlarında her hata yalnızca bir problem değildir. Doğru şekilde kaydedildiğinde, sonraki kurulumlar ve güncellemeler için önemli bir bilgi kaynağına dönüşür.