Azure’da sanal makineler için bakım

Şunlar için geçerlidir: ✔️ Linux VM'leri ✔️ Windows VM'leri ✔️ Esnek ölçek kümeleri ✔️ Tekdüzen ölçek kümeleri

Azure sanal makine konak altyapısının güvenilirlik, performans ve güvenliğini iyileştirmek için düzenli olarak platformunu güncelleştirir. Bu güncelleştirmelerin amacı, barındırma ortamındaki yazılım bileşenlerine düzeltme eki uygulamadan ağ bileşenlerini yükseltmeye veya donanımı kullanımdan kaldırmaya kadar değişiklik gösterir.

Barındırılan VM'ler güncelleştirmelerden nadiren etkilenir. Güncelleştirmelerin bir etkisi olduğunda, Azure güncelleştirmeler için en az etkili yöntemi seçer:

  • Güncelleştirme yeniden başlatma gerektirmiyorsa, konak güncelleştirilirken VM duraklatılır veya VM zaten güncelleştirilmiş bir konağa canlı olarak taşınır.

  • Güncelleştirme yeniden başlatma gerektiriyorsa Azure planlı bakımı size bildirir. Azure ayrıca, bakımı sizin için uygun olan bir zamanda başlatabileceğiniz bir zaman aralığı da sunar. Kendi kendine bakım penceresi, bakım türüne bağlıdır:

    • Donanımın devreden çıkarılması: Kendi kendine bakım süresi genellikle 14 gündür.
    • Konak bakımı: Bakım acil olmadığı sürece kendi kendine bakım penceresi genellikle 35 gündür.

    Azure, planlanan platform bakımının VM'lerin yeniden başlatılmasını gerektirdiği durumların sayısını azaltmak için teknolojilere yatırım yapıyor. Planlı bakımı yönetme yönergeleri için bkz. Azure CLI, PowerShell veya portalıkullanarak planlı bakım bildirimlerini işleme.

Bu sayfada Azure'ın her iki bakım türünü de nasıl gerçekleştirdiği açıklanmaktadır. Planlanmamış olaylar (kesintiler) hakkında daha fazla bilgi için Windows için VM'lerin kullanılabilirliğini yönetme veya Linux için ilgili makaleye bakın.

Bir VM'de, Windows veya Linux için Zamanlanmış Olaylar'ı kullanarak yaklaşan bakımlarla ilgili bildirimler alabilirsiniz.

Yeniden başlatma gerektirmeyen bakım

Çoğu platform güncelleştirmesi müşteri VM'lerini etkilemez. Etkisi olmayan bir güncelleştirme mümkün olmadığında Azure, müşteri VM'leri en az etkileyen güncelleştirme mekanizmasını seçer.

VM’yi etkileyen bakım gerektiğinde, bu bakım neredeyse her zaman 10 saniyeden kısa süren bir VM duraklatmasıyla tamamlanır. Nadir durumlarda, genel amaçlı VM boyutları için en fazla 18 ayda bir Azure, VM'yi yaklaşık 30 saniye duraklatacak bir mekanizma kullanır. Herhangi bir duraklatma işleminden sonra, VM saati devam edildiğinde otomatik olarak senkronize edilir.

Bellek koruma bakımı, Azure VM'lerinin yüzde 90'ından fazlası için çalışır. G, L, N ve H serileri için çalışmaz. Daha fazla bilgi için hangi VM boyutlarının bellek koruma bakımını desteklediğine bakın. Azure, dinamik geçiş teknolojilerini giderek daha fazla kullanır ve duraklatma sürelerini azaltmak için bellek koruma bakım mekanizmalarını geliştirir.

Yeniden başlatma gerektirmeyen bu bakım işlemleri, her seferinde bir hata etki alanına uygulanır. Platform izleme araçlarından herhangi bir sağlık uyarı sinyali alırlarsa dururlar. Yeniden başlatma gerektirmeyen bakım işlemleri eşleştirilmiş bölgelerde veya Kullanılabilirlik Alanları aynı anda gerçekleşebilir. Belirli bir değişiklik için dağıtımlar çoğunlukla Kullanılabilirlik Alanları ve Bölge çiftleri genelinde sıralı olarak gerçekleştirilir, ancak son kısımda örtüşme olabilir.

Bu tür güncelleştirmeler bazı uygulamaları etkileyebilir. VM canlı olarak farklı bir ana bilgisayara taşındığında, bazı hassas iş yükleri VM duraklatılmadan önceki birkaç dakika boyunca hafif bir performans düşüşü gösterebilir. VM bakımına hazırlanmak ve Azure bakımı sırasında etkiyi azaltmak için, bu tür uygulamalar için Windows veya Linux için Zamanlanmış Olaylar'ı kullanmayı deneyin.

Sıfır etkili ve yeniden başlatmasız güncelleştirmeler de dahil olmak üzere tüm bakım etkinlikleri üzerinde daha fazla denetim için bir Bakım Yapılandırması özelliği oluşturabilirsiniz. Bakım Yapılandırması oluşturmak, tüm platform güncelleştirmelerini atlama ve istediğiniz zaman güncelleştirmeleri uygulama seçeneği sunar. Daha fazla bilgi için bkz . Bakım Yapılandırmaları ile platform güncelleştirmelerini yönetme.

Canlı geçiş

Dinamik geçiş, yeniden başlatma gerektirmeyen ve VM için belleği koruyan bir işlemdir. Genellikle en fazla 5 saniye süren bir duraklama veya dondurmaya neden olur. G, L, N ve H serisi dışındaki tüm hizmet olarak altyapı (IaaS) VM'leri dinamik geçiş için uygundur. Dinamik geçiş, M Serisi SKU'ların çoğunda kullanılabilir. Uygun VM'ler, Azure filosuna dağıtılan IaaS VM'lerinin yüzde 90'ından fazlasını temsil eder.

Not

Azure portalında, denenen veya yeniden başlatma gerektirmeyen dinamik geçiş işlemleri için bildirim almazsınız. Yeniden başlatma gerektirmeyen dinamik geçişlerin listesini görmek için zamanlanmış olayları sorgulayın.

Canlı geçiş en iyi çaba ile gerçekleştirilir. Bazı nadir durumlarda, dinamik geçiş başarılı olmayabilir ve sanal makine bildirimden önce gerekirse Hizmet İyileştirilmiş olarak zamanlanır. Dinamik geçiş garantili bir işlem değildir.

Azure platformu aşağıdaki senaryolarda dinamik geçişi tetikler:

  • Planlı bakım
  • Donanım hatası
  • Tahsis optimizasyonları

Bazı planlı bakım senaryolarında dinamik geçiş kullanılır ve dinamik geçiş işlemlerinin ne zaman başlayacağını önceden öğrenmek için Zamanlanmış Olaylar'ı kullanabilirsiniz.

Dinamik geçiş, Azure Machine Learning algoritmaları yaklaşan bir donanım hatası veya VM ayırma iyileştirmesi tahmin ettiğinde VM'leri taşımak için de kullanılabilir. Düşürülmüş donanım örneklerini algılayan tahmine dayalı modelleme hakkında daha fazla bilgi için bkz . Tahmine dayalı makine öğrenmesi ve dinamik geçiş ile Azure VM dayanıklılığını geliştirme. Dinamik geçiş bildirimleri Azure portalında İzleyici ve Hizmet Durumu günlüklerinin yanı sıra bu hizmetleri kullanıyorsanız Zamanlanmış Olaylar'da görünür.

Canlı taşıma sırasında TCP bağlantısının dayanıklılığı

Veritabanı sunucuları, ileti aracıları ve önbelleğe alma katmanları gibi uzun ömürlü TCP bağlantılarını koruyan uygulamalar, dinamik geçiş sırasında bağlantı kesintisi yaşayabilir. VM duraklatma işlemi genellikle 5 saniyenin altında olsa da, duraklatma sırasında ve sonrasındaki TCP yığını davranışı, ele alınmazsa uygulama düzeyinde kurtarma süresini uzatabilir.

Dinamik geçiş TCP bağlantılarını nasıl etkiler:

  • Duraklatma sırasında, iletimdeki TCP segmentleri taşınan sanal makine tarafından onaylanmaz.
  • Gönderen taraf (istemci veya yük dengeleyici durum denetimi), üstel geri çekilme ile TCP yeniden iletimini başlatır.
  • Azure Standart Load Balancer, yapılandırılmış boşta kalma zaman aşımını aşan boşta bağlantılara bir TCP RST gönderir. Ancak, uçuş içi verilerle etkin bağlantılar için yük dengeleyici geçiş duraklatma sırasında TCP RST göndermez. Bağlantı açık kalır ancak yanıt vermez ve istemci bir hata olduğuna dair anında bir işaret almaz.
  • Uygulama düzeyinde ayarlama yapılmazsa, varsayılan TCP yeniden iletim davranışı (tcp_retries2 = 15 Linux'ta) bağlantı hatası algılamayı yaklaşık 15 dakika geciktirebilir.

Important

Etki, işletim sistemi varsayılanlarına göre önemli ölçüde değişir. Linux'ta tcp_retries2 varsayılan değer 15'tir ve bağlantının sonlandırılması yaklaşık 15 dakika sürer. Windows'da varsayılan TcpMaxDataRetransmissions değer 5'tir ve bu da herhangi bir ayarlama yapmadan algılama süresini yaklaşık 25-50 saniyeyle sınırlar. Bu makalede açıklanan azaltmalar, Linux tabanlı iş yükleri için en kritik öneme sahiptir.

Not

HTTP/1.1 iş yükleri için etki genellikle sınırlıdır: yalnızca taşıma sırasında işlemde olan istekler etkilenir ve HTTP/1.1 istemcileri kalıcı bağlantılar üzerinden istekleri ardışık olarak göndermediğinden, sonraki istek için yeni bir bağlantı açarak hızla toparlanırlar. HTTP/2 için, birden çok eşzamanlı akış tek bir TCP bağlantısını paylaştığından patlama yarıçapı daha geniştir.

Yük dengeleyici L4 TLS geçiş modunda çalıştığında, şifrelenmiş akışa hata yanıtlarını inceleyemez, yeniden deneyemez veya ekleyemez. Bu yapılandırmada istemci, durdurulan bağlantıyı algılamaktan ve kurtarmaktan yalnızca sorumludur.

Çok örnekli dağıtımlarla patlama yarıçapını azaltın:

TCP düzeyi azaltmaları uygulamadan önce mimari temeli göz önünde bulundurun. Dinamik geçiş, kullanılabilirlik kümesinde veya sanal makine ölçek kümesinde bir kerede bir VM'yi etkiler. Bağlantıların birden çok arka uç örneğine yayılması, tek bir geçiş olayının etkisini sınırlar:

  • Üç örneği olan bir ölçek kümesi, her geçiş olayının etkin bağlantıların en fazla üçte birini etkilediği anlamına gelir.
  • Kullanılabilirlik Alanları arasında dağıtım, farklı bölgelerdeki geçişlerin çakışmamasını sağlar.
  • Birden çok arka uç arasında dağıtılmış bağlantı havuzlarına sahip istemciler, etkilenmeyen bağlantılar istekleri hemen sunmaya devam ettiğinden daha hızlı kurtarılır.

VM duraklatması sırasında, duraklatılmış arka uca yönelik Azure Standart Load Balancer sistem durumu yoklamaları da başarısız olur. Yük dengeleyici, arka ucu yaklaşık 10 saniye içinde (varsayılan 5 saniyelik aralıkta ardışık iki yoklama hatası) iyi durumda değil olarak işaretler ve yeni bağlantıları yönlendirmeyi durdurur. Bu koşul, yeni bağlantıların doğal olarak korunduğu anlamına gelir. Bu makalede açıklanan TCP risk azaltmaları, geçiş başlamadan önce önceden kurulmuş olan mevcut bağlantıları ele alır.

Önerilen düzeltmeler:

Aşağıdaki risk azaltmaları tamamlayıcı niteliktedir. Birlikte uygulandıklarında, canlı geçiş olayının etkisini dakikalar sürebilecek olası bir kesintiden saniyeler içinde otomatik kurtarmaya indirirler.

Priority Mitigation Çaba Etki
1 TCP_USER_TIMEOUT öğesini soket düzeyinde ayarlayın Low Ölü bağlantı algılamayı yaklaşık 15 dakikadan 30 saniyeye düşürür
2 Zamanlanmış Olaylara Abone Olma Orta Donma gerçekleşmeden önce proaktif bağlantı boşaltmayı etkinleştirir
3 TCP keepalive parametrelerini ayarlama Low Taşıma sonrasında geçerliliğini yitiren boşta bağlantıları algılar
4 İstemci tarafı yeniden deneme mantığını uygulama Orta Kök nedenden bağımsız olarak dayanıklılık sağlar

Önlem 1: TCP_USER_TIMEOUT (en hızlı tespit)

TCP_USER_TIMEOUT , bir bağlantının öldüğünü bildirmeden önce çekirdeğin iletilen verilerin onaylanmasını ne kadar süre bekleyeceğini denetler. Bunu yuva başına 30 saniye (30000 ms) olarak ayarlamak algılama süresini önemli ölçüde azaltır.

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

Alternatif olarak, sistem genelinde yeniden iletim sayısını azaltın:

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Tip

Sistem genelinde değil SDK veya yuva düzeyinde ayarlayın TCP_USER_TIMEOUT . 30 saniyelik bir değer iyi bir başlangıç noktasıdır. 10 saniyenin altındaki değerler, normal ağ gecikme dalgalanmaları sırasında yanlış pozitiflere neden olabilir.

Windows dikkat edilmesi gerekenler:

TCP_USER_TIMEOUT soket seçeneği Linux'a özgüdür. Windows’ta TCP yeniden iletim davranışı farklı şekilde denetlenir:

  • Windows varsayılan olarak 5 yeniden iletim ()TcpMaxDataRetransmissions olarak ayarlanır ve bu da ayarlama yapılmadan yaklaşık 25-50 saniyelik algılama süresi sağlar.
  • Windows algılama süresini daha da azaltmak için kayıt defterini ayarlayın:
# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

TcpMaxDataRetransmissions 3 olarak ayarlandığında, ilk yeniden iletim zaman aşımına bağlı olarak algılama süresi yaklaşık 10-20 saniyeye düşer.

Not

Linux'un aksine, Windows yuva başına eşdeğerini TCP_USER_TIMEOUTkullanıma sunmaz. Kayıt defteri ayarı sistemdeki tüm TCP bağlantıları için geçerlidir. Windows üzerinde ayrıntılı denetim için uygulama düzeyinde zaman aşımlarına ve sistem durumu denetimlerine (Risk Azaltma 4) güvenin.

Risk Azaltma 2: Zamanlanmış Olaylar (proaktif boşaltma)

Zamanlanmış Olaylar hizmeti, dinamik geçiş başlamadan önce önceden bildirim sağlar. Uygulamalar, duraklatma gerçekleşmeden önce olayları dinleyebilir Freeze ve bağlantıları proaktif olarak boşaltabilir.

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

Canlı geçiş olayı şu şekilde görünür:

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Bir Freeze olay algılandığında:

  1. Etkilenen düğümde yeni bağlantıları kabul etmeyi durdurun.
  2. Mevcut bağlantıları sonlandırın (istemcilere diğer düğümlere yeniden bağlanmaları için sinyal verin).
  3. Sınırlı bir zaman aşımı ile uçuş içi işlemlerin tamamlanmasını bekleyin.
  4. İsteğe bağlı olarak EventId değerini geri göndererek olayı onaylar.

Not

Önceden bildirim süresi genellikle 15 dakikadır, ancak nadir durumlarda 30 saniye kadar kısa olabilir. Üretim iş yükleri için saniyede bir yoklama sıklığı önerilir.

Önlem 3: TCP keepalive ince ayarı

TCP keepalive yoklamaları, taşıma işleminden sonra boşta kalan bağlantıları algılar:

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

Bu ayarlarla, boşta kalan eski bir bağlantı 60 saniye içinde (30 + 10 x 3) tespit edilir. Keepalive yoklamaları da Standart Load Balancer’ın boşta kalma zaman aşımı açısından etkinlik sayılır; böylece yük dengeleyicinin boşta duran bağlantıları kendi başına zaman aşımına uğratmasını önler.

Önlem 4: İstemci taraflı yeniden deneme mantığı

Uygulama düzeyinde yeniden bağlanma ve yeniden deneme mantığı, hata algılama yönteminden bağımsız olarak kurtarmayı sağlar:

  1. Bağlantı hatalarını algılama (zaman aşımı, RST veya bağlantı reddedildi).
  2. Ölü bağlantıyı kapatın ve bağlantı havuzundan kaldırın.
  3. Aynı veya farklı bir düğüme yeni bir bağlantı açın.
  4. İşlemi üstel geri alma ile yeniden deneyin.

Veritabanı SDK'ları ve bağlantı havuzları için, bağlantıları proaktif olarak doğrulamak için düzenli sistem durumu denetimlerini (örneğin, 10-15 saniyede bir basit ping) etkinleştirin.

Bağlantı havuzu yapılandırması:

Uzun süreli bağlantıları koruyan bağlantı havuzları, maksimum yaşam süresi ayarından yararlanır. Bu ayar düzenli aralıklarla bağlantı geri dönüşüme zorlar ve tek bir bağlantının gelecekteki geçiş olaylarından kaynaklanan sınırsız riskin birikmemesini sağlar:

Havuz Teknolojisi Setting Önerilen Değer
HikariCP (Java) maxLifetime 1800000 (30 dakika)
PgBouncer server_lifetime 1800 (30 dakika)
Git database/sql SetConnMaxLifetime 30 * saat. Dakika
Node.js (pg Pool) idleTimeoutMillis 30000 (30 saniye boşta kalma durumunda tahliye; maksimum yaşam süresi için özel mantık gerekir)
.NET SqlConnection Bağlantı dizesi: Connection Lifetime 1800 (30 dakika)

Azami 30 dakikalık bir kullanım süresi belirlemek, aktif sağlık kontrolleri olmasa bile bağlantıların, tespit edilmeyen uzun süreli bayatlık birikmeden önce doğal olarak yenilenmesi anlamına gelir.

İzleme ve gözlemlenebilirlik:

Dinamik geçiş olaylarının TCP bağlantıları üzerindeki etkisini algılamak ve ölçmek için aşağıdaki yaklaşımları kullanın:

  • Azure İzleyici VM Kullanılabilirlik ölçümü (Önizleme): VM duraklatma sırasında 0'a düşer. Geçiş olaylarını algılamak VmAvailabilityMetric için eşik değeri 1'den az olan bir uyarı kuralı oluşturun.
  • Zamanlanmış Olaylar Etkinlik Günlüğü: Canlı geçiş olayları Etkinlik Günlüğü'nde sağlayıcının Microsoft.Compute altında işlem adıyla Microsoft.Compute/virtualMachines/liveMigration/action veya Meta Veri Hizmeti aracılığıyla sorgulandığında olaylar olarak Freeze görünür.
  • Uygulama düzeyi bağlantı hata oranı: Uygulama ölçümlerinizde TCP bağlantı sıfırlamalarını, zaman aşımlarını ve yeniden bağlantı sayılarını izleyin. VM Kullanılabilirlik düşüşleriyle ilişkili bağlantı hatalarındaki ani artış, geçişin etkisini doğrular.
  • TCP yeniden iletim sayaçları: Linux'ta alanı /proc/net/netstat izleyin TCPTimeouts veya tek tek yuvalardaki yeniden iletim sayılarını gözlemlemek için kullanınss -ti. Bilinen bir bakım aralığında artan yeniden iletimler, bağlantıların etkilendiğini gösterir.
# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

Normal işlem sırasında bu ölçümler için bir temel oluşturmak, geçiş olaylarının etkisini ölçmeyi ve azaltmalarınızın beklendiği gibi çalıştığını doğrulamayı kolaylaştırır.

Dinamik geçiş kesintisi için sıfır toleransa sahip iş yükleri

Canlı geçişten kaynaklanan hiçbir kesintiyi tolere edemeyen iş yükleri için, Azure Ayrılmış Konakları ile Bakım Yapılandırmaları kullanmayı göz önünde bulundurun. Adanmış Ana Bilgisayarlar, ana bilgisayar düzeyindeki bakımın ne zaman gerçekleşeceğini denetlemenizi sağlayarak beklenmedik canlı taşıma olaylarını ortadan kaldırır.

Yeniden başlatma gerektiren bakım

Vm'lerin planlı bakım için yeniden başlatılması gereken nadir durumlarda size önceden bildirim gönderilir. Planlı bakımın iki aşaması vardır: self servis aşaması ve zamanlanmış bakım aşaması.

Genellikle dört hafta süren self servis aşamasında, VM'lerinizde bakımı başlatırsınız. Self servis kapsamında, durumunu ve son bakım isteğinizin sonucunu görmek için her vm'yi sorgulayabilirsiniz.

Not

Dinamik Geçişi desteklemeyen VM serisi için, bakım olayları sırasında yerel (kısa ömürlü) disk verileri kaybolabilir. Dinamik Geçiş'in desteklenip desteklenmediğini öğrenmek için her vm serisine bakın.

Self servis bakımı başlattığınızda VM'niz zaten güncelleştirilmiş bir düğüme yeniden dağıtılır. VM yeniden dağıtıldığından geçici disk kaybolur ve sanal ağ arabirimiyle ilişkili genel dinamik IP adresleri güncelleştirilir.

Self servis bakım sırasında bir hata oluşursa işlem durdurulur, VM güncelleştirilmez ve self servis bakımı yeniden deneme seçeneğine sahip olursunuz.

Self servis aşaması sona erdiğinde, zamanlanmış bakım aşaması başlar. Bu aşamada bakım aşamasını sorgulamaya devam edebilirsiniz, ancak bakımı kendiniz başlatamazsınız.

Yeniden başlatma gerektiren bakımı yönetme hakkında daha fazla bilgi için bkz. Azure CLI, PowerShell veya portal kullanarak planlı bakım bildirimlerini işleme.

Zamanlanmış bakım sırasında kullanılabilirlik konusunda dikkat edilmesi gerekenler

Zamanlanmış bakım aşamasına kadar beklemeye karar verirseniz, VM'lerinizin en yüksek kullanılabilirliğini korumak için göz önünde bulundurmanız gereken birkaç şey vardır.

Eşleştirilmiş bölgeler

Her Azure bölgesi, aynı coğrafi bölgedeki başka bir bölgeyle eşleştirilir. Birlikte bir bölge çifti oluştururlar. Zamanlanmış bakım aşamasında Azure, yalnızca bir bölge çiftinin tek bir bölgesindeki VM'leri güncelleştirir. Örneğin, Orta Kuzey ABD'deki VM'yi güncelleştirirken Azure, Orta Güney ABD'deki vm'leri aynı anda güncelleştirmez. Ancak, Kuzey Avrupa gibi diğer bölgelerde, Doğu ABD ile aynı zamanda bakım yapılabilir. Bölge çiftlerinin nasıl çalıştığını anlamak, VM'lerinizi bölgeler arasında daha iyi dağıtmanıza yardımcı olabilir. Daha fazla bilgi için bkz . Azure bölge çiftleri.

Kullanılabilirlik alanları

Kullanılabilirlik alanları, bir Azure bölgesi içindeki benzersiz fiziksel konumlardır. Her alan bağımsız güç, soğutma ve ağ bağlantısı ile donatılmış bir veya daha fazla veri merkezinden oluşur. Dayanıklılığı güvence altına almak için etkinleştirilmiş tüm bölgelerde en az üç ayrı alan vardır.

Kullanılabilirlik alanı, hata etki alanı ile güncelleştirme etki alanının birleşimidir. Bir Azure bölgesinde üç bölgede üç veya daha fazla VM oluşturursanız VM'leriniz üç hata etki alanı ve üç güncelleştirme etki alanı arasında etkili bir şekilde dağıtılır. Azure platformu, farklı bölgelerdeki VM'lerin aynı anda güncelleştirilmediğinden emin olmak için bu dağıtımı güncelleştirme etki alanları arasında tanır.

Her altyapı güncelleştirmesi, tek bir bölge içinde kullanılabilirlik alanı bazında dağıtılır. Ancak, Bölge 1’de bir dağıtım devam ederken, aynı anda Bölge 2’de farklı bir dağıtım da devam edebilir. Dağıtımların tümü serileştirilmemiştir. Ancak, yeniden başlatma gerektiren tek bir dağıtım, riski azaltmak için aynı anda yalnızca bir bölgeyi kullanıma sunar. Genel olarak, mümkün olduğunda yeniden başlatma gerektiren güncelleştirmelerden kaçınılır ve Azure Dinamik Geçiş'i kullanmaya veya müşterilere denetim sağlamaya çalışır.

Sanal makine ölçek kümeleri

Esnek düzenleme modundaki sanal makine ölçek kümeleri, Tekdüzen düzenleme modundaki sanal makine ölçek kümelerinin ölçeklenebilirliğini kullanılabilirlik kümelerinin bölgesel kullanılabilirlik garantileriyle birleştirmenizi sağlayan bir Azure işlem kaynağıdır.

Esnek düzenleme ile örneklerinizin birden çok bölgeye mi yoksa tek bir bölgedeki hata etki alanlarına mı yayıldığını seçebilirsiniz.

Kullanılabilirlik kümeleri ve Tekdüzen ölçek kümeleri

Azure VM'lerine iş yükü dağıtırken, uygulamanıza yüksek kullanılabilirlik sağlamak için bir kullanılabilirlik kümesi içinde VM'ler oluşturabilirsiniz. Kullanılabilirlik kümelerini kullanarak, yeniden başlatma gerektiren bir kesinti veya bakım etkinliği sırasında en az bir VM'nin kullanılabilir olduğundan emin olabilirsiniz.

Bir kullanılabilirlik kümesinde, tek tek VM'ler en fazla 20 güncelleştirme etki alanına yayılır. Zamanlanmış bakım sırasında, aynı anda yalnızca bir güncelleştirme etki alanı güncelleştirilir. Güncelleştirme etki alanlarının sırayla güncelleştirilmiş olması gerekmez.

Tekdüzen düzenleme modundaki sanal makine ölçek kümeleri, aynı VM'leri tek bir kaynak olarak dağıtmak ve yönetmek için kullanabileceğiniz bir Azure işlem kaynağıdır. Ölçek kümesi, kullanılabilirlik kümesindeki VM'ler gibi UD'ler arasında otomatik olarak dağıtılır. Kullanılabilirlik kümelerinde olduğu gibi, Tekdüzen ölçek kümelerini kullandığınızda, zamanlanmış bakım sırasında herhangi bir zamanda yalnızca bir UD güncelleştirilir.

VM'lerinizi yüksek kullanılabilirlik için ayarlama hakkında daha fazla bilgi için Bkz. Windows için VM'lerinizin kullanılabilirliğini yönetme veya Linux için ilgili makale.

Sonraki adımlar

Planlı bakımı yönetmek için Azure CLI, Azure PowerShell veya portalı kullanın.

  • Last updated on