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

Ayarlama ve azure'da Windows uygulamanız için yüksek kullanılabilirlik sağlamak için birden çok sanal makineleri yönetme yollarını öğrenin.Learn ways to set up and manage multiple virtual machines to ensure high availability for your Windows application in Azure. Ayrıca Linux sanal makinelerin kullanılabilirliğini yönetme.You can also manage the availability of Linux virtual machines.

Oluşturma ve kullanılabilirlik kümeleri, Klasik dağıtım modeli kullanılırken kullanma yönergeleri 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

Sanal makine azure'da etkilenmesine neden olabilecek üç senaryo vardır: plansız Donanım bakımı, beklenmeyen 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 kullanan dinamik geçiş arızalı donanımdaki sanal makineleri sağlıklı bir fiziksel makineye geçirmek teknoloji.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.

  • Beklenmeyen kapalı kalma süresi donanım ya da fiziksel altyapı sanal makinesi için beklenmedik şekilde başarısız olduğunda.An Unexpected Downtime is when the hardware or the physical infrastructure for the virtual machine fails unexpectedly. Bu, yerel ağ hatalarında, yerel disk hataları veya raf düzeyinde diğer hatalar içerebilir.This can include local network failures, local disk failures, or other rack level failures. Azure platformu algılandığında, otomatik olarak geçirir (heals) aynı veri merkezinde sağlıklı bir fiziksel makineye sanal makinenize.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 yaşandığı nadir bir veri merkezinin tamamı veya tüm bir bölgeyi etkileyen bir kesinti veya kapalı kalma süresi de oluşabilir.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. Bu senaryolar için Azure dahil olmak üzere koruma seçeneklerini sunar. kullanılabilirlik ve eşleştirilmiş bölgeleri.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:

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

Uygulamanıza yedeklilik sağlamak için bir kullanılabilirlik kümesinde iki veya daha fazla sanal makinenin gruplandırılması önerilir.To provide redundancy to your application, we recommend that you group two or more virtual machines in an availability set. Bu yapılandırma bir veri merkezinde ya da bir planlı veya Plansız bakım olayı sırasında en az bir sanal makine kullanılabilir olduğundan ve % 99,95 oranında karşıladığından emin sağlar Azure SLA'sı.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 sanal makineler değil bir SLA garantisine ve tek bir VM kullanırken dışında Azure planlı bakım olayları sırasında kapalı kalma süresi yüz Azure premium SSD.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 kullanma 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ırmasının kavramsal çizimiConceptual 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. Bunu VM hata etki alanı ile hizalayabilirsiniz ve diskleri farklı depolama hata etki alanları (depolama kümeleri) otomatik olarak yerleştirerek yapar.It does this by automatically placing the disks in different storage fault domains (storage clusters) and aligning them with the VM fault domain. Depolama hata etki alanı, donanım veya yazılım arızasından dolayı başarısız olursa, yalnızca depolama hata etki alanı disklerle sanal makine ö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 FDManaged 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
East USEast 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
Orta Güney ABDSouth Central US 33
Batı Orta ABDWest Central US 22
Orta KanadaCanada Central 33
Doğu KanadaCanada 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
Japonya DoğuJapan East 22
Japonya BatıJapan 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
Avustralya DoğuAustralia East 22
Avustralya GüneydoğuAustralia Southeast 22
Avustralya OrtaAustralia Central 22
Avustralya Orta 2Australia Central 2 22
Güney BrezilyaBrazil South 22
ABD Devleti VirginiaUS Gov Virginia 22
ABD Devleti TexasUS Gov Texas 22
ABD Devleti ArizonaUS Gov Arizona 22
US DoD OrtaUS DoD Central 22
US DoD DoğuUS DoD East 22

Yönetilmeyen diskleri olan VM'ler kullanmayı planlıyorsanız, aşağıdaki olarak sanal sabit diskleri (VHD'ler) sanal makinelerinin depolandığı depolama hesapları için en iyi uygulamayı izleyin sayfa blobları.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. Farklı kullanılabilirlik yukarıdaki en iyi deneyimler uygulanırsa, depolama hesaplarını paylaşabilir kümelerindeki vm'le yönetilmeyen diskler FDIt is acceptable for VMs across different Availability Sets to share storage accounts if above best practices are followed Unmanaged disks FDs

VM etkileyen olayları proaktif olarak yanıt vermek için zamanlanmış olayları kullanınUse scheduled events to proactively respond to VM impacting events

Abone olduğunuzda zamanlanmış olaylar, sanal Makinenizin etkileyebilir yaklaşan bakımın olaylar hakkında bildirilir.When you subscribe to scheduled events, your VM is notified about upcoming maintenance events that can impact your VM. Zamanlanmış olaylar etkinleştirildiğinde, sanal makinenizin bakım etkinliği gerçekleştiren önce geçmesi gereken süreyi en düşük düzeyde verilir.When scheduled events are enabled, your virtual machine is given a minimum amount of time before the maintenance activity is performed. Örneğin, sanal makinenizin etkileyebilecek ana bilgisayar işletim sistemi güncelleştirmeleri etkisi belirten olayları, olarak hiçbir işlem yapılmadı, bakım gerçekleştirilir birer 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. Azure iyileştirme ne zaman yapılması gereken karar vermenize olanak tanır, VM etkileyebilecek uyaran bir donanım hatası algıladığında zamanlama olayları da eklenirler.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, olay durumu kaydetmeyi gibi önce bakım görevleri gerçekleştirmek için ikincil veritabanına yük devretmeyi kullanın ve benzeri.Customers can use the event to perform tasks prior to the maintenance, such as saving state, failing over to the secondary, and so on. Düzgün bir şekilde bir bakım olayı işlemek için mantığınızı tamamladıktan sonra Bakım ve devam etmek platform izin vermek için bekleyen zamanlanmış olay 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 kümeleri halinde yapılandırmaConfigure each application tier into separate availability sets

Sanal makinelerinizin neredeyse tümü aynıysa ve uygulamanız için aynı amaca hizmet ediyorsa, uygulamanızın her katmanı için bir 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 set for each tier of your application. Aynı kullanılabilirlik kümesine iki farklı katman yerleştirirseniz, aynı uygulama katmanındaki tüm sanal makineler tek seferde yeniden başlatılabilir.If you place two different tiers in the same availability set, all virtual machines in the same application tier can be rebooted at once. Her katman için bir kullanılabilirlik kümesinde en az iki sanal makineyi yapılandırarak, her katmanda en az bir sanal makinenin kullanılabilir olmasını garanti edersiniz.By configuring at least two virtual machines in an availability set for each tier, you guarantee that at least one virtual machine in each tier is available.

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

Uygulama katmanlarıApplication tiers

Yük dengeleyiciyi kullanılabilirlik kümeleri ile birleştirmeCombine a load balancer with availability sets

En fazla uygulama dayanıklılığını elde etmek için Azure Load Balancer’ı bir kullanılabilirlik kümesiyle birleştirin.Combine the Azure Load Balancer with an availability 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.

Düzey veri merkezi arızasına karşı korumak için kullanılabilirlik alanlarını kullanmaUse availability zones to protect from datacenter level failures

Kullanılabilirlik alanlarıkullanılabilirlik alternatif ayarlar, uygulamaları ve verileri sanal makinelerinizin kullanılabilirliğini sürdürmek için sahip olduğunuz denetimi düzeyini genişletin.Availability zones, an alternative to availability sets, expand the level of control you have to maintain the availability of the applications and data on your VMs. Kullanılabilirlik Alanı, bir Azure bölgesinin içinde fiziksel olarak ayrılmış bir alandır.An Availability Zone is a physically separate zone within an Azure region. Üç kullanılabilirlik alanı desteklenen bir Azure bölgesi başına vardır.There are three Availability Zones per supported Azure region. Her kullanılabilirlik alanı farklı bir sahip güç kaynağı, ağ ve soğutma ve diğer kullanılabilirlik alanlarından Azure bölgesi içinde mantıksal olarak ayrıdır.Each Availability Zone has a distinct power source, network, and cooling, and is logically separate from the other Availability Zones within the Azure region. Çoğaltılan VM'ler bölgelerinde kullanılacak çözümlerinizi tasarlayarak, uygulamalarınızın ve verilerinizin bir veri merkezi kaybına karşı koruyabilirsiniz.By architecting your solutions to use replicated VMs in zones, you can protect your apps and data from the loss of a datacenter. Bir bölge tehlikedeyse, ardından çoğaltılan uygulamaları ve verileri 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ı

Dağıtma hakkında daha fazla bilgi bir Windows veya Linux bir kullanılabilirlik alanında VM.Learn more about deploying a Windows or Linux VM in an Availability Zone.

Sonraki adımlarNext steps

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