Azure VM için sistem yeniden başlatmasını anlama
Şunlar için geçerlidir: ✔️ Linux VM'leri ✔️ Windows VM'leri
Azure sanal makineleri (VM' ler) bazen, yeniden başlatma işlemini başlattığınızı gösteren bir kanıt olmadan belirgin bir neden olmadan yeniden başlatılabilir. 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, bir kullanılabilirlik kümesinde iki veya daha fazla VM'yi 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 bir kullanılamama durumunun kök nedeni hakkında daha fazla bilgi varsa, bu bilgiler ilk kullanılamama süresinden 72 saat sonraya 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:
- Bir 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üren süresi etkinlik günlüğünden filtrelenmiştir.
- 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. bu durum, ilk geçişin oluşmasından 15 dakika önce bağıntılı bir kapalı kalma süresi gönderilirse oluşmaz.
- VM sistem durumu bir durumdan Bilinmiyor olarak değişirse ve özgün duruma geri dönerse, aralıklı Bilinmeyen durumu 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 sürekli yapılan 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 aşamalı bir plan üzerinde çalışmaktadır.
VM'nin yeniden başlatılmasına neden olabilecek eylemler ve olaylar
Planlı bakım
Microsoft Azure, VM'leri destekleyen 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 zamanlanacağı hakkında arka plan bilgileri 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ği engellemeden güncelleştirilebilecek bileşenlere veya hizmetler içindir. 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ş olanağı sağlayan teknolojiyle gerçekleştirilir. Güncelleştirilirken VM duraklatılmış duruma yerleştirilir. Bu durum RAM belleğini korur ve bu arada alttaki 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 devam ettirildikten 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 etkiyi büyük ölçüde azaltır. Ancak, tüm güncelleştirmeler bu şekilde dağıtılamaz.
Çok örnekli güncelleştirmeler (bir kullanılabilirlik kümesindeki VM'ler için), bir seferde bir güncelleme etki alanı şeklinde 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 Bir Azure Linux VM'sinde panikler.
Kullanıcı tarafından başlatılan yeniden başlatma veya kapatma eylemleri
Azure portalından, Azure PowerShell'den, 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 için Microsoft Defender ve Windows Update
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 ayrıca Linux sistemleri için en son güncelleştirmeleri denetler. VM'nizde bir sistem güncelleştirmesi eksikse, Bulut için Defender sistem güncelleştirmelerini uygulamanızı önerir. Bu sistem güncelleştirmelerinin uygulanması, Azure portalındaki Bulut için Defender üzerinden 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'ten Windows VM'lerine göndermez çünkü bu makineler kullanıcıları tarafından yönetilmeye yöneliktir. Ancak, otomatik Windows Update ayarını etkin bırakmanız önerilir. Güncelleştirmelerin Windows Update'ten 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 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.
Ana bilgisayar sunucusu arızaları
VM, azure veri merkezinde çalışan bir fiziksel 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 öncekiyle aynı konakta yaşamaya devam eder.
Sunucu hatalarına genellikle sabit disk veya katı hal sürücüsü hatası gibi donanım arızaları neden olur. 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 alır.
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 iyileştirilebilir. Bu işlem, VM'nin ayrıntılar sayfasındaki yeniden dağıtma seçeneği kullanılarak veya Azure portalında VM durdurularak ve 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ı, sağlıklı 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 gibi ç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.
Plansız 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
Sanal makineler, sanal makinenin kendi içindeki sorunlardan dolayı yeniden başlatılabilir. VM'de çalışan iş yükü veya rol, konuk işletim sisteminde bir hata denetimi tetikleyebilir. Kilitlenmenin nedenini saptarken yardım almak için, Windows sanal makinelerinde sistem ve uygulama günlüklerini ve Linux sanal makinelerinde seri günlükleri görüntüleyin.
Depolama ile ilgili zorla kapatma işlemleri
Azure'daki VM'ler, işletim sistemi ve Azure Depolama altyapısında barındırılan 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ını 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, vm'nizin en son yeniden başlatılmasının 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 bizimle iletişim kurun
Sorularınız varsa veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteğine sorun. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.