Azure VM için sistem yeniden başlatmasını anlama

  • Makale

Azure sanal makineleri (VM'ler) bazen görünür bir neden olmadan yeniden başlatılabilir ve bu da yeniden başlatma işlemini başlattığınızı gösterir. Bu makalede VM'lerin yeniden başlatılmasına neden olabilecek eylemler ve olaylar listelenir ve beklenmeyen yeniden başlatma sorunlarını önleme veya bu tür sorunların etkisini azaltma hakkında içgörüler sağlanır.

VM'leri yüksek kullanılabilirlik için yapılandırma

Azure'da çalışan bir uygulamayı VM yeniden başlatmalarına ve kapalı kalma süresine karşı korumanın en iyi yolu VM'leri yüksek kullanılabilirlik için yapılandırmaktır.

Uygulamanıza bu düzeyde yedeklilik sağlamak için iki veya daha fazla VM'yi bir kullanılabilirlik kümesinde gruplandırmanızı öneririz. Bu yapılandırma, planlı veya plansız bir bakım olayı sırasında en az bir VM'nin kullanılabilir olmasını ve yüzde 99,95 Azure SLA'sını karşılamasını sağlar.

Kullanılabilirlik kümeleri hakkında daha fazla bilgi için bkz. VM'lerin kullanılabilirliğini yönetme

Kaynak Durumu bilgileri

Azure Kaynak Durumu, tek tek Azure kaynaklarının durumunu kullanıma sunan ve sorunları gidermek için eyleme dönüştürülebilir yönergeler sağlayan bir hizmettir. Sunuculara veya altyapı öğelerine doğrudan erişmenin mümkün olmadığı bir bulut ortamında, Kaynak Durumu amacı sorun gidermeye harcadığınız süreyi azaltmaktır. Özellikle amaç, sorunun kökünün uygulamada mı yoksa Azure platformundaki bir olayda mı olduğunu belirlemek için harcadığınız süreyi azaltmaktır. Daha fazla bilgi için bkz. Kaynak Durumu anlama ve kullanma.

Azure'da Sanal Makine için platform tarafından başlatılan kullanılamazlığın kök nedeni hakkında daha fazla bilgi varsa, bu bilgiler ilk kullanılamama süresinden 72 saat sonrasına kadar kaynak durumunda gönderilebilir.

Etkinlik günlüğünde vm kapalı kalma süreleri eksik

Kaynak Durumu uyarılarıetkinlik Günlüğü bilgilerine göre gönderilir. Bazı durumlarda VM kapalı kalma süreleri etkinlik günlüğünde gösterilmeyebilir. Kapalı kalma süresi etkinlik günlüğünde gösterilmiyorsa, kapalı kalma süresi için Kaynak Durumu uyarılar gönderilmez. Kapalı kalma süresi hala Kaynak Durumu görünür durumdadır.

VM kapalı kalma sürelerinin etkinlik günlüğünde gösterilmediği durumlar şunlardır:

  • Vm oluşturulduğunda veya yeni bir konağa geçirildiğinde, Azure platformu VM durumunu doğru görüntülemez ve durum Bilinmiyor olarak değişir. Yalnızca tüm ağ bağlantısı ve düğüm işlemleri oluşturulduktan sonra VM durumu Kullanılabilir olarak değişir. Bilinmeyen durumunun uzun süresi etkinlik günlüğünden filtrelenir.
  • VM kullanılabilirlik durumu Kullanılabilir olan Kullanılamıyor olarak değiştiğinde ve 35 saniye içinde Kullanılabilir'e geri döndüğünde, kapalı kalma süresi etkinlik günlüğünde gösterilmez. İlk geçişin gerçekleşmesinden 15 dakika önce bağıntılı bir kapalı kalma süresi gönderilirse bu durum oluşmaz.
  • VM sistem durumu bir durumdan Bilinmiyor durumuna geçer ve özgün duruma geri dönerse, aralıklı Bilinmeyen durum ve ilgili geçişler etkinlik günlüğünden filtrelenir.

Etkinlik günlüğünde görünmeyen VM kapalı kalma süreleri, geçici hataların müşterilere yanlış kapalı kalma süreleri göstermesini önlemek için Azure platformu tarafında filtrelenir. VM sistem durumu kalitesine yapılan devam eden yatırımlarla filtreler artık gerekli olmayabilir ve VM sistem durumundaki hızlı değişikliklerin raporlanmayan kalmasına neden olabilir. Microsoft, en iyi müşteri deneyimini sunmak için bir aşamalı plan üzerinde çalışmaktadır.

VM'nin yeniden başlatılmasına neden olabilecek eylemler ve olaylar

Planlı bakım

Microsoft Azure, VM'leri kullanan konak altyapısının güvenilirliğini, performansını ve güvenliğini artırmak için düzenli aralıklarla dünya genelinde güncelleştirmeler gerçekleştirir. Bellek koruma güncelleştirmeleri de dahil olmak üzere bu güncelleştirmelerin çoğu VM'lerinizi veya bulut hizmetlerinizi etkilemeden gerçekleştirilir.

Ancak, bazı güncelleştirmeler yeniden başlatma gerektirir. Bu gibi durumlarda, altyapıya düzeltme eki uygulamamız sırasında VM'ler kapatılır ve ardından VM'ler yeniden başlatılır.

Azure planlı bakımının ne olduğunu ve Linux VM'lerinizin kullanılabilirliğini nasıl etkileyebileceğini anlamak için burada listelenen makalelere bakın. Makaleler, Azure planlı bakım işlemi ve etkiyi daha da azaltmak için planlı bakımın nasıl zamanlandığı hakkında arka plan sağlar.

Bellek koruma güncelleştirmeleri

Microsoft Azure'daki bu güncelleştirme sınıfı için kullanıcılar çalışan VM'lerini etkilemez. Bu güncelleştirmelerin çoğu, çalışan örneğe müdahale etmeden güncelleştirilebilen bileşenlere veya hizmetlere yöneliktir. Bazıları, konak işletim sistemindeki vm'ler yeniden başlatılmadan uygulanabilen platform altyapısı güncelleştirmeleridir.

Bu bellek koruma güncelleştirmeleri yerinde dinamik geçişe olanak tanıyan teknolojiyle gerçekleştirilir. Güncelleştirilirken, VM duraklatılmış duruma yerleştirilir. Bu durum RAM'deki belleği korurken, temel konak işletim sistemi gerekli güncelleştirmeleri ve düzeltme eklerini alır. VM genellikle duraklatıldıktan sonra 30 saniye içinde sürdürülür. VM sürdürüldükten sonra saati otomatik olarak eşitlenir.

Kısa duraklatma süresi nedeniyle, güncelleştirmelerin bu mekanizma aracılığıyla dağıtılması VM'ler üzerindeki etkisini büyük ölçüde azaltır. Ancak, tüm güncelleştirmeler bu şekilde dağıtılamaz.

Çok örnekli güncelleştirmeler (kullanılabilirlik kümesindeki VM'ler için) aynı anda bir güncelleştirme etki alanı uygulanır.

Not

Eski çekirdek sürümlerine sahip Linux makineleri, bu güncelleştirme yöntemi sırasında çekirdek paniğinden etkilenir. Bu sorunu önlemek için çekirdek sürüm 3.10.0-327.10.1 veya sonraki bir sürüme güncelleştirin. Daha fazla bilgi için bkz. Konak düğümü yükseltmesi sonrasında 3.10 tabanlı çekirdekte Azure Linux VM'leri panikler.

Kullanıcı tarafından başlatılan yeniden başlatma veya kapatma eylemleri

Azure portal, Azure PowerShell, komut satırı arabiriminden veya REST API'den yeniden başlatma gerçekleştirirseniz, olayı Azure Etkinlik Günlüğü'nde bulabilirsiniz.

Eylemi VM'nin işletim sisteminden gerçekleştirirseniz, olayı sistem günlüklerinde bulabilirsiniz.

Genellikle VM'nin yeniden başlatılmasına neden olan diğer senaryolar birden çok yapılandırma değiştirme eylemidir. Normalde belirli bir eylemin yürütülmesinin VM'nin yeniden başlatılmasına neden olacağını belirten bir uyarı iletisi görürsünüz. Örnek olarak vm yeniden boyutlandırma işlemleri, yönetim hesabının parolasını değiştirme ve statik IP adresi ayarlama verilebilir.

Bulut ve Windows Update için Microsoft Defender

Bulut için Microsoft Defender, eksik işletim sistemi güncelleştirmeleri için günlük Windows ve Linux VM'lerini izler. Bulut için Defender, Windows VM'de hangi hizmetin yapılandırıldığına bağlı olarak Windows Update veya Windows Server Update Services'dan (WSUS) kullanılabilir güvenlik ve kritik güncelleştirmelerin listesini alır. Bulut için Defender, Linux sistemleri için en son güncelleştirmeleri de denetler. VM'nizde bir sistem güncelleştirmesi yoksa Bulut için Defender, sistem güncelleştirmelerini uygulamanızı önerir. Bu sistem güncelleştirmelerinin uygulaması, Azure portal Bulut için Defender aracılığıyla denetlenilir. Bazı güncelleştirmeleri uyguladıktan sonra VM yeniden başlatmaları gerekebilir. Daha fazla bilgi için bkz. Bulut için Microsoft Defender'de sistem güncelleştirmelerini uygulama.

Şirket içi sunucularda olduğu gibi Azure da güncelleştirmeleri Windows Update Windows VM'lerine göndermez çünkü bu makinelerin kullanıcıları tarafından yönetilmesi amaçlanmıştır. Ancak otomatik Windows Update ayarını etkin bırakmanız teşvik edilir. güncelleştirmelerin Windows Update otomatik olarak yüklenmesi, güncelleştirmeler uygulandıktan sonra yeniden başlatmaların gerçekleşmesine de neden olabilir. Daha fazla bilgi için bkz. Windows Update SSS.

VM'nizin kullanılabilirliğini etkileyen diğer durumlar

Azure'ın vm kullanımını etkin bir şekilde askıya alabileceği başka durumlar da vardır. Bu eylem gerçekleştirilmeden önce e-posta bildirimleri alırsınız, bu nedenle temel alınan sorunları çözme fırsatınız olur. VM kullanılabilirliğini etkileyen sorunlara örnek olarak güvenlik ihlalleri ve ödeme yöntemlerinin süresinin dolması verilebilir.

Konak sunucu hataları

VM, Bir Azure veri merkezinde çalışan fiziksel bir sunucuda barındırılır. Fiziksel sunucu, diğer birkaç Azure bileşenine ek olarak Konak Aracısı adlı bir aracı çalıştırır. Fiziksel sunucudaki bu Azure yazılım bileşenleri yanıt vermemeye başladığında, izleme sistemi kurtarmayı denemesi için konak sunucusunun yeniden başlatılmasını tetikler. Çoğu durumda, VM 10-15 dakika içinde yeniden kullanılabilir duruma gelir ve daha önce olduğu gibi aynı konakta yaşamaya devam eder.

Sunucu hataları genellikle sabit disk veya katı hal sürücüsü hatası gibi donanım hatalarından kaynaklanıyor. Azure bu oluşumları sürekli izler, temel alınan hataları tanımlar ve azaltma uygulanıp test edildikten sonra güncelleştirmeleri kullanıma hazırlar.

Bazı konak sunucu hataları bu sunucuya özgü olabileceğinden, VM'yi başka bir konak sunucusuna el ile yeniden dağıtarak yinelenen bir VM yeniden başlatma durumu geliştirilebilir. Bu işlem, VM'nin ayrıntılar sayfasındaki yeniden dağıtma seçeneği kullanılarak veya Azure portal vm durdurulup yeniden başlatılarak tetiklenebilir.

Otomatik kurtarma

Konak sunucu herhangi bir nedenle yeniden başlatılamıyorsa Azure platformu, daha fazla araştırma için hatalı ana bilgisayar sunucusunu döndürmeden çıkarmak için bir otomatik kurtarma eylemi başlatır.

Bu konak üzerindeki tüm VM'ler otomatik olarak farklı, iyi durumdaki bir konak sunucusuna yeniden konumlandırılır. Bu işlem genellikle 15 dakika içinde tamamlasa da, kurtarma için gereken süre konak belleğinin boyutu ve kullanılan kurtarma yöntemleri de dahil olmak üzere çeşitli faktörlere bağlı olarak değişebilir. Otomatik kurtarma işlemi hakkında daha fazla bilgi edinmek için bkz. VM'leri otomatik kurtarma.

Planlanmamış bakım

Nadir durumlarda, Azure operasyon ekibinin Azure platformunun genel durumunu güvence altına almak için bakım etkinlikleri gerçekleştirmesi gerekebilir. Bu davranış VM kullanılabilirliğini etkileyebilir ve genellikle daha önce açıklandığı gibi aynı otomatik kurtarma eylemiyle sonuçlanabilir.

Planlanmamış bakım şunları içerir:

  • Acil düğüm birleştirme
  • Acil ağ anahtarı güncelleştirmeleri

VM kilitleniyor

VM'lerin kendi içindeki sorunlar nedeniyle VM'ler yeniden başlatabilir. VM'de çalışan iş yükü veya rol, konuk işletim sisteminde bir hata denetimi tetikleyebilir. Kilitlenmenin nedenini belirleme konusunda yardım için Windows VM'leri için sistem ve uygulama günlüklerini ve Linux VM'lerinin seri günlüklerini görüntüleyin.

Azure'daki VM'ler, Azure Depolama altyapısında barındırılan işletim sistemi ve veri depolama için sanal diskleri kullanır. VM ile ilişkili sanal diskler arasındaki kullanılabilirlik veya bağlantı 120 saniyeden uzun bir süre boyunca etkilendiğinde, Azure platformu veri bozulmasını önlemek için VM'lerin zorla kapatılmasını gerçekleştirir. Depolama bağlantısı geri yüklendikten sonra VM'ler otomatik olarak yeniden çalışır. Kapatma süresi beş dakika kadar kısa olabilir ancak önemli ölçüde daha uzun olabilir.

Diğer olaylar

Nadir durumlarda, yaygın bir sorun Bir Azure veri merkezinde birden çok sunucuyu etkileyebilir. Bu sorun oluşursa, Azure ekibi etkilenen aboneliklere e-posta bildirimleri gönderir. Devam eden kesintilerin ve geçmiş olayların durumu için Azure Hizmet Durumu panosunu ve Azure portal denetleyebilirsiniz.

VM Yeniden Başlatmalarını Tanılama

Ek tanılamalar çalıştırmak için VM dikey penceresindeki Tanılama ve Çözme dikey penceresini kullanabilirsiniz. Bu, son VM yeniden başlatma işleminizin daha belirgin nedenlerini ortaya çıkartabilir. Konuk işletim sistemi sorunu varsa lütfen bellek dökümünü toplayın ve desteğe başvurun.

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.