Azure 'da Windows sanal makinelerinin kullanılabilirliğini yönetmeManage the availability of Windows virtual machines in Azure

Azure 'da Windows uygulamanız için yüksek kullanılabilirlik sağlamak üzere birden çok sanal makine ayarlama ve yönetme yolları hakkında bilgi edinin.Learn ways to set up and manage multiple virtual machines to ensure high availability for your Windows application in Azure. Linux sanal makinelerinin kullanılabilirliğini de yönetebilirsiniz.You can also manage the availability of Linux virtual machines.

Klasik dağıtım modelini kullanırken kullanılabilirlik kümeleri oluşturma ve kullanma hakkında yönergeler için bkz. bir kullanılabilirlik kümesi yapılandırma.For instructions on creating and using availability sets when using the classic deployment model, see How to Configure an Availability Set.

VM Yeniden Başlatma İşlemlerini Anlama - bakım ve kapalı kalma süresiUnderstand VM Reboots - maintenance vs. downtime

Azure 'da sanal makineye etkilenmesine neden olan üç senaryo vardır: planlanmamış donanım bakımı, beklenmedik kapalı kalma süresi ve planlı bakım.There are three scenarios that can lead to virtual machine in Azure being impacted: unplanned hardware maintenance, unexpected downtime, and planned maintenance.

  • Plansız Donanım Bakımı Olayı, Azure platformu donanımın veya fiziksel makineyle ilişkili herhangi bir platform bileşeninin arıza yapmak üzere olduğunu tahmin ettiğinde gerçekleşir.Unplanned Hardware Maintenance Event occurs when the Azure platform predicts that the hardware or any platform component associated to a physical machine, is about to fail. Platform bir arıza öngördüğünde, donanımda barındırılan sanal makineler üzerindeki etkiyi azaltmak amacıyla plansız donanım bakımı olayı düzenler.When the platform predicts a failure, it will issue an unplanned hardware maintenance event to reduce the impact to the virtual machines hosted on that hardware. Azure, sanal makineleri başarısız olan donanımdan sağlıklı fiziksel bir makineye geçirmek için dinamik geçiş teknolojisini kullanır.Azure uses Live Migration technology to migrate the Virtual Machines from the failing hardware to a healthy physical machine. Dinamik Geçiş, Sanal Makineyi yalnızca kısa bir süre için duraklatan bir VM koruma işlemidir.Live Migration is a VM preserving operation that only pauses the Virtual Machine for a short time. Bellek, açık dosyalar ve ağ bağlantıları korunur, ancak olaydan önce ve/veya sonra performans azalabilir.Memory, open files, and network connections are maintained, but performance might be reduced before and/or after the event. Dinamik Geçişin kullanılamadığı durumlarda VM, aşağıda açıklanan Beklenmeyen Kapalı Kalma Süresi yaşar.In cases where Live Migration cannot be used, the VM will experience Unexpected Downtime, as described below.

  • Beklenmedik kapalı kalma süresi , sanal makinenin donanımının veya fiziksel altyapısının beklenmedik bir şekilde başarısız olmasına neden olur.An Unexpected Downtime is when the hardware or the physical infrastructure for the virtual machine fails unexpectedly. Bu, yerel ağ arızalarını, yerel disk başarısızlıklarını veya diğer raf düzeyi başarısızlıklarını içerebilir.This can include local network failures, local disk failures, or other rack level failures. Algılandığında, Azure platformu sanal makinenizi aynı veri merkezinde sağlıklı bir fiziksel makineye otomatik olarak geçirir (toplar).When detected, the Azure platform automatically migrates (heals) your virtual machine to a healthy physical machine in the same datacenter. İyileştirme yordamı sırasında sanal makineler kapalı kalır (yeniden başlatma) ve bazı durumlarda geçici sürücü kaybı yaşar.During the healing procedure, virtual machines experience downtime (reboot) and in some cases loss of the temporary drive. Bağlı işletim sistemi ve veri diskleri her zaman korunur.The attached OS and data disks are always preserved.

    Sanal makineler Ayrıca, tüm veri merkezini veya tüm bölgeyi etkileyen bir kesinti veya olağanüstü durum durumunda kapalı kalma süresi yaşar.Virtual machines can also experience downtime in the unlikely event of an outage or disaster that affects an entire datacenter, or even an entire region. Azure, bu senaryolar için kullanılabilirlik alanları ve eşleştirilmiş bölgelerdahil olmak üzere koruma seçenekleri sunar.For these scenarios, Azure provides protection options including availability zones and paired regions.

  • Planlı Bakım olayları, Microsoft tarafından sanal makinelerinizin çalıştığı platforma ait genel güvenilirlik, performans ve güvenliği artırmak amacıyla temel alınan Azure platformunda yapılan periyodik güncelleştirmelerdir.Planned Maintenance events are periodic updates made by Microsoft to the underlying Azure platform to improve overall reliability, performance, and security of the platform infrastructure that your virtual machines run on. Bu güncelleştirmelerin çoğu Sanal Makine veya Bulut Hizmetlerinizi etkilemeden gerçekleştirilir (bkz. VM Koruyucu Bakım).Most of these updates are performed without any impact upon your Virtual Machines or Cloud Services (see VM Preserving Maintenance). Azure platformu mümkün olan tüm durumlarda VM Koruyucu Bakımı kullanmaya çalışsa da, gerekli güncelleştirmelerin temel alınan altyapıya uygulanması için bu güncelleştirmelerin sanal makineyi yeniden başlatmayı gerektirdiği nadir örnekler vardır.While the Azure platform attempts to use VM Preserving Maintenance in all possible occasions, there are rare instances when these updates require a reboot of your virtual machine to apply the required updates to the underlying infrastructure. Bu durumda, uygun zaman penceresi içinde VM’lere yönelik bakımı başlatarak Maintenance-Redeploy işlemi ile Azure Planlı Bakımını gerçekleştirebilirsiniz.In this case, you can perform Azure Planned Maintenance with Maintenance-Redeploy operation by initiating the maintenance for their VMs in the suitable time window. Daha fazla bilgi için bkz. Sanal Makineler için Planlı Bakım.For more information, see Planned Maintenance for Virtual Machines.

Bu olayların bir veya daha fazlası nedeniyle kapalı kalma süresinin etkisini azaltmak için, sanal makinelerinizde aşağıdaki yüksek kullanılabilirlik en iyi uygulamalarının kullanılması önerilir:To reduce the impact of downtime due to one or more of these events, we recommend the following high availability best practices for your virtual machines:

Veri merkezi düzeyindeki hatalardan korumak için kullanılabilirlik bölgelerini kullanmaUse availability zones to protect from datacenter level failures

Kullanılabilirlik alanları , sanal makinelerinizdeki uygulamaların ve verilerin kullanılabilirliğini korumak için sahip olduğunuz denetim düzeyini genişletir.Availability zones expand the level of control you have to maintain the availability of the applications and data on your VMs. Kullanılabilirlik Alanları, Azure bölgesi içinde fiziksel olarak benzersiz konumlardır.Availability Zones are unique physical locations within an Azure region. Her alan bağımsız güç, soğutma ve ağ bağlantısı ile donatılmış bir veya daha fazla veri merkezinden oluşur.Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. Dayanıklılık sağlamak için, tüm etkin bölgelerde en az üç ayrı bölge vardır.To ensure resiliency, there are a minimum of three separate zones in all enabled regions. Bir bölgedeki Kullanılabilirlik Alanları fiziksel ayrımı, uygulamaları ve verileri veri merkezi hatalarından korur.The physical separation of Availability Zones within a region protects applications and data from datacenter failures. Bölgesel olarak yedekli hizmetler, uygulamalarınızı ve verilerinizi Kullanılabilirlik Alanları arasında çoğaltarak hata noktalarından koruyun.Zone-redundant services replicate your applications and data across Availability Zones to protect from single-points-of-failure.

Bir Azure bölgesindeki kullanılabilirlik bölgesi bir hata etki alanının ve bir güncelleştirme etki alanınınbirleşimidir.An Availability Zone in an Azure region is a combination of a fault domain and an update domain. Örneğin, bir Azure bölgesindeki üç bölgede üç veya daha fazla VM oluşturursanız, VM 'niz üç hata etki alanına ve üç güncelleştirme etki alanına etkili bir şekilde dağıtılır.For example, if you create three or more VMs across three zones in an Azure region, your VMs are effectively distributed across three fault domains and three update domains. Azure platformu, farklı bölgelerdeki VM 'Lerin aynı anda güncelleştirildiğinden emin olmak için bu dağıtımı güncelleştirme etki alanları genelinde tanır.The Azure platform recognizes this distribution across update domains to make sure that VMs in different zones are not updated at the same time.

Azure, Kullanılabilirlik Alanları sayesinde sektörün en iyi% 99,99 VM çalışma süresi SLA 'sını sunmaktadır.With Availability Zones, Azure offers industry best 99.99% VM uptime SLA. Bölgelerde çoğaltılan VM 'Leri kullanma çözümlerinizi tasarlayarak, uygulamalarınızı ve verilerinizi bir veri merkezi kaybından koruyabilirsiniz.By architecting your solutions to use replicated VMs in zones, you can protect your applications and data from the loss of a datacenter. Bir bölge tehlikeye girerse, çoğaltılan uygulamalar ve veriler başka bir bölgede anında kullanılabilir.If one zone is compromised, then replicated apps and data are instantly available in another zone.

Kullanılabilirlik alanları

Bir Windows veya Linux VM 'yi bir kullanılabilirlik alanına dağıtma hakkında daha fazla bilgi edinin.Learn more about deploying a Windows or Linux VM in an Availability Zone.

Bir kullanılabilirlik kümesindeki birden fazla sanal makineyi yedeklilik için yapılandırmaConfigure multiple virtual machines in an availability set for redundancy

Kullanılabilirlik kümeleri, VM artıklığı ve kullanılabilirliği sağlayan başka bir veri merkezi yapılandırması.Availability sets are another datacenter configuration to provide VM redundancy and availability. Bir veri merkezi içindeki bu yapılandırma, planlı veya plansız bir bakım olayı sırasında en az bir sanal makinenin kullanılabilir olmasını ve% 99,95 Azure SLA 'sını karşılamasını sağlar.This configuration within a datacenter ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA. Daha fazla bilgi için bkz. Sanal Makineler için SLA.For more information, see the SLA for Virtual Machines.

Önemli

Tek örnekli bir sanal makineyi bir kullanılabilirlik kümesinde tek başına bırakmaktan kaçının.Avoid leaving a single instance virtual machine in an availability set by itself. Bu yapılandırmadaki VM 'Ler, tek bir VM 'nin Azure Premium SSD'leri kullanıyor olması dışında, Azure planlı bakım OLAYLARı sırasında SLA garantisi ve yüz kesintilerine uygun değildir.VMs in this configuration do not qualify for a SLA guarantee and face downtime during Azure planned maintenance events, except when a single VM is using Azure premium SSDs. Premium SSD 'ler kullanan tek VM 'Ler için Azure SLA 'Sı geçerlidir.For single VMs using premium SSDs, the Azure SLA applies.

Kullanılabilirlik kümenizdeki her sanal makineye, temel alınan Azure platformu tarafından bir güncelleme etki alanı ve bir hata etki alanı atanır.Each virtual machine in your availability set is assigned an update domain and a fault domain by the underlying Azure platform. Belirli bir kullanılabilirlik kümesi için, aynı anda yeniden başlatılabilecek sanal makine gruplarını ve temel alınan fiziksel donanımları göstermek üzere, kullanıcı tarafından yapılandırılabilen beş güncelleme etki alanı varsayılan olarak atanır (Resource Manager dağıtımları daha sonra en fazla 20 güncelleme etki alanı sağlayacak şekilde artırılabilir).For a given availability set, five non-user-configurable update domains are assigned by default (Resource Manager deployments can then be increased to provide up to 20 update domains) to indicate groups of virtual machines and underlying physical hardware that can be rebooted at the same time. Tek bir kullanılabilirlik kümesinde beşten fazla sanal makine yapılandırıldığında, altıncı sanal makine birinci sanal makine ile, yedinci sanal makine ikinci sanal makine ile aynı güncelleme etki alanına yerleştirilir ve yerleştirme işlemi bu düzende devam eder.When more than five virtual machines are configured within a single availability set, the sixth virtual machine is placed into the same update domain as the first virtual machine, the seventh in the same update domain as the second virtual machine, and so on. Yeniden başlatılmakta olan güncelleme etki alanlarının sırası, planlanan bakım sırasında sıralı olarak uygulanmayabilir, ancak aynı anda yalnızca bir güncelleme etki alanı yeniden başlatılır.The order of update domains being rebooted may not proceed sequentially during planned maintenance, but only one update domain is rebooted at a time. Yeniden başlatılmış bir güncelleme etki alanının kurtarılması için, farklı bir güncelleme etki alanında bakım başlatılmadan önce 30 dakika beklenir.A rebooted update domain is given 30 minutes to recover before maintenance is initiated on a different update domain.

Hata etki alanları ortak bir güç kaynağı ve ağ anahtarını paylaşan sanal makine grubunu tanımlar.Fault domains define the group of virtual machines that share a common power source and network switch. Varsayılan olarak, kullanılabilirlik kümenizde yapılandırılmış olan sanal makineler, Resource Manager dağıtımları için en fazla üç hata etki alanı (Klasik için iki etki alanı) arasında ayrılır.By default, the virtual machines configured within your availability set are separated across up to three fault domains for Resource Manager deployments (two fault domains for Classic). Sanal makinelerinizin bir kullanılabilirlik kümesine yerleştirilmesi uygulamanızı işletim sistemine veya uygulamaya özel hatalardan korumasa da, olası fiziksel donanım hatalarının, ağ kesintilerinin veya güç kesintilerinin etkilerini sınırlar.While placing your virtual machines into an availability set does not protect your application from operating system or application-specific failures, it does limit the impact of potential physical hardware failures, network outages, or power interruptions.

güncelleştirme etki alanı ve hata etki alanı yapılandırma](./media/virtual-machines-common-manage-availability/ud-fd-configuration.png) kavramsal çizimini ![Conceptual drawing of the update domain and fault domain configuration

Bir kullanılabilirlik kümesindeki VM’ler için yönetilen diskleri kullanmaUse managed disks for VMs in an availability set

Şu anda yönetilmeyen disklere sahip VM’ler kullanıyorsanız, Kullanılabilirlik Kümesindeki VM’leri Yönetilen Diskleri kullanacak şekilde dönüştürmeniz önemle tavsiye edilir.If you are currently using VMs with unmanaged disks, we highly recommend you convert VMs in Availability Set to use Managed Disks.

Yönetilen diskler, bir Kullanılabilirlik Kümesindeki VM disklerinin tek arıza noktalarından kaçınmak üzere birbirinden yeterince ayrılmasını sağlayarak Kullanılabilirlik Kümeleri için daha fazla güvenilirlik sunar.Managed disks provide better reliability for Availability Sets by ensuring that the disks of VMs in an Availability Set are sufficiently isolated from each other to avoid single points of failure. Bu, diskleri farklı depolama hata etki alanlarına (depolama kümeleri) otomatik olarak yerleştirerek ve bunları VM hata etki alanıyla hizalayarak yapar.It does this by automatically placing the disks in different storage fault domains (storage clusters) and aligning them with the VM fault domain. Bir depolama hatası etki alanı, donanım veya yazılım arızası nedeniyle başarısız olursa, yalnızca depolama hatası etki alanındaki disklere sahip VM örneği başarısız olur.If a storage fault domain fails due to hardware or software failure, only the VM instance with disks on the storage fault domain fails. yönetilen diskler FDsManaged disks FDs

Önemli

Yönetilen kullanılabilirlik kümelerine yönelik arıza etki alanlarının sayısı bölgeye göre farklılık gösterir (bölge başına iki veya üç).The number of fault domains for managed availability sets varies by region - either two or three per region. Aşağıdaki tabloda bölge başına sayı gösterilmektedirThe following table shows the number per region

Her bölge için Hata Etki Alanı sayısıNumber of Fault Domains per region

BölgeRegion Maksimum Hata Etki Alanı sayısıMax # of Fault Domains
Doğu ABDEast US 33
Doğu ABD 2East US 2 33
Batı ABDWest US 33
Batı ABD 2West US 2 22
Orta ABDCentral US 33
Orta Kuzey ABDNorth Central US 33
Güney Orta ABDSouth Central US 33
Orta Batı ABDWest Central US 22
Kanada OrtaCanada Central 33
Kanada DoğuCanada East 22
Kuzey AvrupaNorth Europe 33
Batı AvrupaWest Europe 33
Birleşik Krallık, GüneyUK South 22
Birleşik Krallık, BatıUK West 22
Doğu AsyaEast Asia 22
Güneydoğu AsyaSouth East Asia 22
Doğu JaponyaJapan East 22
Batı JaponyaJapan West 22
Güney HindistanSouth India 22
Orta HindistanCentral India 22
Batı HindistanWest India 22
Kore OrtaKorea Central 22
Kore GüneyKorea South 22
BAE KuzeyUAE North 22
Çin DoğuChina East 22
Çin Doğu 2China East 2 22
Çin KuzeyChina North 22
Çin Kuzey 2China North 2 22
Doğu AvustralyaAustralia East 22
Güneydoğu AvustralyaAustralia Southeast 22
Avustralya OrtaAustralia Central 22
Avustralya Orta 2Australia Central 2 22
Brezilya GüneyBrazil South 22
ABD Hükümeti VirginiaUS Gov Virginia 22
US Gov TeksasUS Gov Texas 22
US Gov ArizonaUS Gov Arizona 22
US DoD OrtaUS DoD Central 22
ABD DoD DoğuUS DoD East 22

Note: belirli koşullar altında, aynı Kullanılabilirlik alanının 2 VM 'nin bir parçası aynı FaultDomain ' ı paylaşmasından kaynaklanabilir.Note: Under certain circumstances, it might happen that 2 VMs part of the same AvailabilitySet are sharing the same FaultDomain. Bu, kullanılabilirlik kümesine gidip "hata etki alanı" sütununu denetleyerek onaylanır.This can be confirmed by going into your AvailabilitySet and check the "Fault Domain" column. Bu davranış, VM 'Ler dağıtıldığında aşağıdaki sıra meydana geldiğinde gözlemlenebilir:This behavior can be observed when the following sequence happened while deploying the VMs:

  • 1. VM 'yi dağıtmaDeploy the 1st VM
  • 1. VM 'yi durdur/serbest bırakStop/Deallocate the 1st VM
  • 2. VM 'yi bu koşullarda dağıtın, 2. VM 'nin işletim sistemi diski, 1. VM ile aynı hata etki alanında oluşturulabilir ve bu nedenle 2. VM aynı FaultDomain etki alanına da eklenecektir.Deploy the 2nd VM Under these circumstances, the OS Disk of the 2nd VM might be created on the same Fault Domain as the 1st VM, and so the 2nd VM will also land on the same FaultDomain. Bu sorundan kaçınmak için, dağıtımları arasında VM 'nin durdurulması/serbest olmaması önerilir.To avoid this issue, it's recommended to not stop/deallocate the VM between their deployments.

VM 'Leri yönetilmeyen disklerle kullanmayı planlıyorsanız, VM 'lerin sanal sabit disklerinin (VHD) sayfa Bloblarıolarak depolandığı depolama hesapları için aşağıdaki en iyi yöntemleri izleyin.If you plan to use VMs with unmanaged disks, follow below best practices for Storage accounts where virtual hard disks (VHDs) of VMs are stored as page blobs.

  1. Bir VM ile ilişkili tüm diskleri (işletim sistemi ve veri) aynı depolama hesabında tutmaKeep all disks (OS and data) associated with a VM in the same storage account
  2. Bir depolama hesabına daha fazla VHD eklemeden önce Depolama hesabındaki yönetilmeyen disk sayısına ilişkin limitleri gözden geçirinReview the limits on the number of unmanaged disks in a Storage account before adding more VHDs to a storage account
  3. Bir Kullanılabilirlik Kümesindeki her VM için ayrı depolama hesabı kullanın.Use separate storage account for each VM in an Availability Set. Depolama hesaplarını aynı Kullanılabilirlik Kümesinde birden fazla VM ile paylaşmayın.Do not share Storage accounts with multiple VMs in the same Availability Set. Yukarıdaki en iyi uygulamalardan , yönetilmeyen diskler ardından, depolama hesaplarını paylaşmak için farklı kullanılabilirlik kümelerindeki VM 'Ler için kabul edilebilir.It is acceptable for VMs across different Availability Sets to share storage accounts if above best practices are followed Unmanaged disks FDs

VM etkileyen olayları önceden yanıtlamak için zamanlanmış olayları kullanmaUse scheduled events to proactively respond to VM impacting events

Zamanlanan olaylaraabone olduğunuzda, VM 'NIZ, VM 'nizi etkileyebilecek yaklaşan bakım olayları hakkında bilgilendirilir.When you subscribe to scheduled events, your VM is notified about upcoming maintenance events that can impact your VM. Zamanlanan olaylar etkinleştirildiğinde, bakım etkinliği gerçekleştirilmeden önce sanal makinenize en az bir süre verilir.When scheduled events are enabled, your virtual machine is given a minimum amount of time before the maintenance activity is performed. Örneğin, VM 'nizi etkileyebilecek ana bilgisayar işletim sistemi güncelleştirmeleri, etkiyi belirten olaylar olarak, aynı zamanda hiçbir işlem gerçekleştirilmediği zaman bakımın gerçekleştirileceği bir süre kadar sıraya alınır.For example, Host OS updates that might impact your VM are queued up as events that specify the impact, as well as a time at which the maintenance will be performed if no action is taken. Zamanlama olayları, Azure, VM 'nizi etkileyebilecek mini donanım hatası algıladığında de sıraya alınır ve bu durum, iyileştirmenin ne zaman gerçekleştirilmesi gerektiğine karar vermenize olanak tanır.Schedule events are also queued up when Azure detects imminent hardware failure that might impact your VM, which allows you to decide when the healing should be performed. Müşteriler, durumu kaydetme, ikinciye yük devretme, vb. gibi bakım öncesinde görev gerçekleştirmek için olayını kullanabilir.Customers can use the event to perform tasks prior to the maintenance, such as saving state, failing over to the secondary, and so on. Bakım olayını düzgün bir şekilde işleme için mantığınızı tamamladıktan sonra, platformun bakım ile devam etmesini sağlamak için bekleyen zamanlanmış olayını onaylayabilirsiniz.After you complete your logic for gracefully handling the maintenance event, you can approve the outstanding scheduled event to allow the platform to proceed with maintenance.

Her uygulama katmanını ayrı kullanılabilirlik bölgeleri veya kullanılabilirlik kümelerine göre yapılandırmaConfigure each application tier into separate availability zones or availability sets

Sanal makineleriniz neredeyse aynıysa ve uygulamanız için aynı amaca sahipseniz, uygulamanızın her katmanı için bir kullanılabilirlik alanı veya kullanılabilirlik kümesi yapılandırmanız önerilir.If your virtual machines are all nearly identical and serve the same purpose for your application, we recommend that you configure an availability zone or availability set for each tier of your application. Aynı Kullanılabilirlik bölgesine veya kümesine iki farklı katman yerleştirirseniz, aynı uygulama katmanındaki tüm sanal makineler aynı anda yeniden başlatılabilir.If you place two different tiers in the same availability zone or set, all virtual machines in the same application tier can be rebooted at once. Bir kullanılabilirlik alanında en az iki sanal makineyi yapılandırarak veya her katman için ayarlanmış olarak, her katmanda en az bir sanal makinenin kullanılabilir olduğundan emin olursunuz.By configuring at least two virtual machines in an availability zone or set for each tier, you guarantee that at least one virtual machine in each tier is available.

Örneğin, tüm sanal makineleri IIS, Apache ve NGINX çalıştıran uygulamanızın ön ucuna tek bir kullanılabilirlik alanına veya kümesine yerleştirebilirsiniz.For example, you could put all the virtual machines in the front end of your application running IIS, Apache, and Nginx in a single availability zone or set. Yalnızca ön uç sanal makinelerin aynı Kullanılabilirlik alanına yerleştirildiğinden veya ayarlanmış olduğundan emin olun.Make sure that only front-end virtual machines are placed in the same availability zone or set. Benzer şekilde, çoğaltılan SQL Server sanal makineleriniz ya da MySQL sanal makineleriniz gibi yalnızca veri katmanı sanal makinelerinin kendi kullanılabilirlik bölgesine veya kümesine yerleştirildiğinden emin olun.Similarly, make sure that only data-tier virtual machines are placed in their own availability zone or set, like your replicated SQL Server virtual machines, or your MySQL virtual machines.

Uygulama katmanlarını Application tiers

Bir yük dengeleyiciyi kullanılabilirlik alanları veya kümeleriyle birleştirmeCombine a load balancer with availability zones or sets

Azure Load Balancer bir kullanılabilirlik bölgesi ile birleştirin veya en fazla uygulama dayanıklılığı sağlamak için ayarlayın.Combine the Azure Load Balancer with an availability zone or set to get the most application resiliency. Azure Load Balancer, birden fazla sanal makine arasında trafiği dağıtır.The Azure Load Balancer distributes traffic between multiple virtual machines. Standart katman sanal makinelerimize Azure Load Balancer dahildir.For our Standard tier virtual machines, the Azure Load Balancer is included. Tüm sanal makine katmanları Azure Load Balancer hizmetini içermez.Not all virtual machine tiers include the Azure Load Balancer. Sanal makinelerinizde yük dengeleme hakkında daha fazla bilgi için bkz. Sanal makinelerde yük dengeleme.For more information about load balancing your virtual machines, see Load Balancing virtual machines.

Yük dengeleyici birden fazla sanal makine arasında trafiği dengeleyecek şekilde yapılandırılmamışsa, planlı bakım olayları yalnızca trafik sunan sanal makineyi etkiler ve uygulama katmanınızda kesintiye neden olur.If the load balancer is not configured to balance traffic across multiple virtual machines, then any planned maintenance event affects the only traffic-serving virtual machine, causing an outage to your application tier. Aynı yük dengeleyici ve kullanılabilirlik kümesi altına aynı katmandaki birden fazla sanal makinenin yerleştirilmesi, trafiğin en az bir örnek tarafından sürekli olarak sunulmasını sağlar.Placing multiple virtual machines of the same tier under the same load balancer and availability set enables traffic to be continuously served by at least one instance.

Kullanılabilirlik alanları arasında yük dengelemeye yönelik bir öğretici için bkz. Azure CLI kullanarak VM 'leri tüm kullanılabilirlik bölgelerinde Yük Dengeleme.For a tutorial on how to load balance across availability zones, see Load balance VMs across all availability zones by using the Azure CLI.

Sonraki adımlarNext steps

Sanal makinelerinizin Yük Dengelemesi hakkında daha fazla bilgi edinmek için bkz. Yük Dengeleme sanal makineleri.To learn more about load balancing your virtual machines, see Load Balancing virtual machines.