Azure Sanal Makine kullanılabilirliği görüntüleme

Mevcut Azure kaynak durumu özelliği, Azure kaynaklarınızı etkileyen hizmet sorunlarını tanılamanıza ve destek almanıza yardımcı olur. Kaynaklarınızın geçerli ve geçmiş sağlık durumu hakkında raporlar ve kaynaklarınızın her birinin kullanılamadığı zaman aralıklarını gösterir. Ancak, müşterilerin temel teknik soruna neyin neden olduğunu anlamak ve herhangi bir sorun hakkında nasıl iletişim alabileceklerini iyileştirmek- izleme süreçlerine beslenmek, diğer paydaşlara hıçkırıkları açıklamak ve nihayetinde iş kararlarını bilgilendirmek için “neden” ile özellikle ilgilendiklerini Microsoft gayet iyi biliyor.

Azure kaynak sağlığında VM sorunları için temel nedenleri tanıtma

Son zamanlarda, müşterilerle VM hataları hakkında paylaştığımız bilgileri geliştirecek kaynak durumu deneyimine, soruna yol açan temel neden hakkında ek bir bağlamla bir iyileştirme gönderdik. Şimdi, bir VM’nin kullanılabilirliği etkilendiğinde hızlı bir bildirim almanın yanı sıra, otomatik Kök Neden Analizi (RCA) sistemimiz VM hatasına yol açan başarısız Azure platform bileşenini tanımladığında, müşteriler daha sonraki bir noktada bir kök neden eklenmesini bekleyebilir. Bunun pratikte nasıl çalıştığını görmek için bir örnek üzerinden yürüyelim:

  1. T1 zamanında, bir sunucu rafı bir ağ sorunu nedeniyle çevrimdışı olur ve raf üzerindeki VM’lerin bağlantıyı kaybetmesine neden olur. (Ağ mimarisiyle ilgili son güvenilirlik geliştirmeleri, gelecekteki bir İlerleyen Güvenilirlik blog gönderisinde paylaşılacaktır— bu alanı izleyin!)
  2. T2 zamanında, Azure’un iç izlemesi raf üzerindeki VM’lere erişemediğini kabul eder ve etkilenen VM’leri yeni bir rafa yeniden dağıtmakla azaltmaya başlar. Bu süre zarfında, müşterilere VM’lerinin şu anda etkilendiğini ve kullanılamadığını bildiren bir ek açıklama kaynak durumuna gönderilir.

 

Bir kaynağın sistem durumu geçmişini gösteren Azure portal "kaynak durumu" dikey penceresi.

Şekil 1: Bir kaynağın sistem durumu geçmişini gösteren Azure portal “kaynak durumu” dikey penceresinin ekran görüntüsü.

  1. Zaman T3, raf anahtarının tepesinden platform telemetrisi, ana makine ve dahili izleme sistemleri, arızanın temel nedenini türetmek için RCA motorumuzda birbiriyle ilişkilidir. Hesaplandıktan sonra RCA, müşterilerin gelecekte etki olasılığını en aza indirmek için uygulayabilecekleri ilgili mimari dayanıklılık önerileriyle birlikte kaynak sağlığına geri yayınlanır.

 

VM sorunu örneği için kök neden ayrıntılarını gösteren Azure portal "sistem durumu geçmişi" dikey penceresi.

Şekil 2: VM sorunu örneği için kök neden ayrıntılarını gösteren Azure portal “sistem durumu geçmişi” dikey penceresi.

İlk kapalı kalma süresi bildirim işlevi birkaç yıldır var olsa da, bir kök cause deyiminin yayımlanması yeni bir ektir. Şimdi, bu kök nedenleri nasıl türetdiğimizin ayrıntılarına dalalım.

Kök Neden Çözümleme altyapısı

Önceki örneğe daha yakından bakalım ve RCA motorunun nasıl çalıştığının ve arkasındaki teknolojinin ayrıntılarını gözden geçirelim. VM’ler için RCA motorumuzun merkezinde, yüksek hacimli günlük telemetri analizi için optimize edilmiş büyük bir veri hizmeti olan Azure Veri Gezgini (ADX) bulunur. Azure Veri Gezgini, Azure platformunu oluşturan cihazlardan ve hizmetlerden terabaytlarca günlük telemetrisini kolayca ayrıştırma, bunları birleştirme ve ilişkili bilgi akışlarını yorumlayarak farklı hata senaryoları için kök bir neden türetme olanağı sağlar. Bu, çok çeşitli bir veri mühendisliği süreci olarak sona erer:

Aşama 1: Kapalı kalma süresini algılama

Kök neden analizinin ilk aşaması, analizin yürütüldüğü tetikleyiciyi tanımlamaktır. Sanal Makineler söz konusu olduğunda, bir VM beklenmedik şekilde yeniden başlatıldığında kök nedenleri belirlemek istiyoruz, bu nedenle tetikleyici yukarı durumdan aşağı duruma geçiş eden bir VM’dir. Platform telemetrisinden bu geçişleri tanımlamak çoğu senaryoda basittir, ancak platform telemetrisinin cihaz arızası veya güç kaybı nedeniyle kaybolabileceği belirli altyapı hatası türleri etrafında daha karmaşıktır. Bu hata sınıflarını işlemek için, VM sistem durumu geçişinin olası bir göstergesi olarak veri kaybını izleme gibi başka teknikler gerekir. Azure Veri Gezgini, seri analizinin bu zamanında üstündür ve bununla ilgili tekniklere daha ayrıntılı bir bakış Microsoft Teknoloji Topluluğu’nda bulunabilir: Azure Veri Gezgini’nde Pencere işlevlerini ve Zaman Serisi işlevlerini kullanarak kapalı kalma süresini hesaplama.

Aşama 2: Korelasyon analizi

Bir tetikleyici olayı tanımlandıktan sonra (bu durumda, sağlıksız bir duruma geçiş eden bir VM) bir sonraki aşama korelasyon analizidir. Bu adımda, telemetriyi Azure platformundaki noktalardan ilişkilendirmek için tetikleyici olayın varlığını kullanıyoruz, (mesela:

  • Azure ana bilgisayarı: VM’leri barındıran fiziksel bıçak.
  • Tor: raf ağ anahtarının üst kısmı.
  • Azure Depolama: Azure Sanal Makineleri için Sanal Diskleri barındıran hizmet.

Bu sistemlerin her birinin, ayrıştırılmış ve VM kapalı kalma süresi tetikleyici olayıyla ilişkilendirilmiş olması gereken kendi telemetri akışları vardır. Bu, bir VM için bağımlılık grafiğini ve VM’nin başarısız olmasına neden olabilecek temel sistemleri anlayarak ve daha sonra tüm bu bağımlı sistemlerin sistem durumu telemetrisini birleştirerek, zaman içinde VM geçişine nispeten yakın olan olaylara filtre uygulanarak yapılır. Azure Veri Gezgini’nin sezgisel ve güçlü sorgu dili, zamansal telemetri akışlarını bir araya getirerek zaman penceresi birleştirme gibi belgelenmiş desenlerle buna yardımcı olur. Bu korelasyon işleminin sonunda, VM hatasına neyin yol açtığını belirlemede yararlı olabilecek veya bunlara neden olabilecek tüm bağımlı sistemlerden ilişkili platform telemetrisi ile VM kapalı kalma süresi geçişlerini temsil eden bir veri kümemiz vardır.

Aşama 3: Kök neden ilişkilendirmesi

İşlemin bir sonraki adımı atıftır. Artık ilgili tüm verileri tek bir veri kümesinde bir araya topladığımıza göre, bilgileri yorumlamak ve müşteriye yönelik bir kök neden bildirimine çevirmek için ilişkilendirme kuralları uygulanır. Orijinal TOR başarısızlığı örneğimize dönersek, korelasyon analizimizden sonra yorumlamamız gereken birçok ilginç bilgi parçası olabilir. Örneğin, Azure ana bilgisayarlarını izleyen sistemlerin, bu süre zarfında ana bilgisayarlara bağlantıyı kaybettiklerini belirten günlükleri olabilir. Ayrıca sanal disk bağlantı sorunlarıyla ilgili sinyallerimiz ve TOR cihazından hata hakkında açık sinyallerimiz olabilir. Tüm bu bilgi parçaları artık taranır ve açık TOR hata sinyali, temel neden olarak diğer sinyallere göre önceliklendirilir. Bu öncelik belirleme işlemi ve arkasındaki kurallar, etki alanı uzmanlarıyla oluşturulur ve Azure platformu geliştikçe değiştirilir. Makine öğrenimi ve anomali algılama mekanizmaları, bu sınıflandırma kurallarını geliştirme fırsatlarının belirlenmesine ve bu hataların güvenli dağıtım işlem hatlarına geri beslenme hızındaki desen değişikliklerini algılamaya yardımcı olmak için bu öznitelikli kök nedenlerin üzerine oturur.

Aşama 4: RCA yayıncılığı

Son adım, müşteriler tarafından görülebilecekleri Azure kaynak durumuna kök nedenler yayımlamaktır. Bu, Azure Veri Gezgini’nde işlenen kök neden verilerini düzenli aralıklarla sorgulayan ve sonuçları kaynak durumu arka ucuna yayan çok basit bir Azure İşlevleri uygulamasında yapılır. Bilgi akışları çeşitli veri gecikmeleriyle gelebildiğinden, RCA’lar bu süreçte, başlangıçta yayınlanan daha spesifik bir kök nedene yol açan daha iyi bilgi kaynaklarını yansıtacak şekilde zaman zaman güncellenebilir.

İleriye doğru

Müşterilerimizi ve iş ortaklarımızı etkileyen sorunların temel nedenini belirlemek ve onlarla iletişim kurmak sadece bir başlangıçtır. Müşterilerimizin bu RCA’ları alıp müşterileri ve iş arkadaşlarıyla paylaşmaları gerekebilir. Kaynak RCA’larını tanımlamayı ve izlemeyi ve kolayca paylaşmayı kolaylaştırmak için buradaki çalışmaların üzerine inşa etmek istiyoruz. Bunu başarmak için, size gösterebileceğimiz benzersiz kaynak başına ve kesinti başına izleme kimlikleri oluşturmak için arka uç değişiklikleri üzerinde çalışıyoruz, böylece kapalı kalma sürelerini RCA’larıyla kolayca eşleştirebilirsiniz. Ayrıca, RCA’ları e-postayla gönderemeyi kolaylaştırmak ve sonunda VM’leriniz için RCA’lara abone olmak için yeni özellikler üzerinde çalışıyoruz. Bu, kullanılabilirlik olmayan bir olaydan sonra doğrudan gelen kutunuza BRCA’lara kaydolmanızı ve sizin tarafınızdan ek bir eyleme gerek kalmamasını mümkün kılacaktır.

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Fill out this field
Fill out this field
Lütfen geçerli bir e-posta adresi girin.
You need to agree with the terms to proceed

Menü