Azure Stack hub 'da dağıtılan VM 'Leri koruma-RuggesağlamlaştırılmışProtect VMs deployed on Azure Stack Hub - Ruggedized

Kullanıcılarınızın Azure Stack hub 'da dağıtacağı sanal makinelerin (VM 'Ler) korunması için bir plan geliştirmek üzere bu makaleyi kılavuz olarak kullanın.Use this article as a guide to develop a plan for protecting virtual machines (VMs) that your users deploy on Azure Stack Hub.

Veri kaybına ve planlanmamış kapalı kalma süresine karşı korunmak için Azure Stack hub 'daki VM tabanlı uygulamalar için bir veri koruma ve olağanüstü durum kurtarma planı uygulayın.To protect against data loss and unplanned downtime, implement a data protection and disaster recovery plan for VM-based applications on Azure Stack Hub. Uygulanan koruma planı, uygulamanın iş gereksinimlerine ve tasarımına bağlı olarak değişir.The protection plan implemented will depend on business requirements and design of the application. Bu plan, kuruluşunuzun ' kapsamlı iş sürekliliği ve olağanüstü durum kurtarma (BC/Dr) stratejiniz tarafından belirlenen çerçeveyi izlemelidir.This plan should follow the framework established by your organization's comprehensive business continuity and disaster recovery (BC/DR) strategy. Azure Stack hub 'ına yönelik BC/DR hakkında üst düzey bir genel bakış için bkz. Azure Stack: iş sürekliliği ve olağanüstü durum kurtarma için değerlendirmeler.For a high level overview of the BC/DR considerations for Azure Stack Hub, see Azure Stack: Considerations for business continuity and disaster recovery.

Uygulama kurtarma amaçlarıApplication recovery objectives

Kuruluşunuzun her bir uygulama için kabul edebildiği kesinti süresi ve veri kaybı miktarını belirleme.Determine the amount of downtime and data loss your organization can tolerate for each application. Kapalı kalma süresini ve veri kaybını azaltarak, kuruluşunuzda bir olağanüstü durum etkisini en aza indiren bir kurtarma planı oluşturabilirsiniz.By quantifying downtime and data loss, you can create a recovery plan that minimizes the impact of a disaster on your organization. Her uygulama için şunları göz önünde bulundurun:For each application, consider:

  • Kurtarma süresi hedefi (RTO)Recovery time objective (RTO)
    RTO, bir uygulamanın bir olay sonrasında kullanılamadığı en fazla kabul edilebilir süredir.RTO is the maximum acceptable time that an app can be unavailable after an incident. Örneğin, 90 dakikalık bir RTO, uygulamayı bir olağanüstü durum başlangıcından 90 dakika içinde çalışır duruma geri yükleyebilmeniz gerektiği anlamına gelir.For example, an RTO of 90 minutes means that you must be able to restore the app to a running state within 90 minutes from the start of a disaster. Düşük bir RTO varsa, bölgesel kesintiye karşı korumak için ikinci bir dağıtımı sürekli bekleme üzerinde çalışır durumda tutabilirsiniz.If you have a low RTO, you might keep a second deployment continually running on standby to protect against a regional outage.

  • Kurtarma noktası hedefi (RPO)Recovery point objective (RPO)
    RPO, olağanüstü bir durum sırasında en uzun ne kadar sürelik veri kaybının kabul edilebilir olduğudur.RPO is the maximum duration of data loss that is acceptable during a disaster. Örneğin, her saat yedeklenen ve diğer veritabanlarına çoğaltma olmayan tek bir veritabanında verileri depoluseniz, bir saat veri kaybedebilirsiniz.For example, if you store data in a single database which is backed up hourly and has no replication to other databases, you could lose up to an hour of data.

Her uygulama için RTO ve RPO tanımlamak üzere bir değerlendirme gerçekleştirin.Conduct an assessment to define the RTO and RPO for each application.

Dikkate alınması gereken diğer önemli ölçüm, bir hatadan sonra uygulamanın geri yüklenmesi için geçen ortalama süre olan (MTTR) kurtarmak için geçen süredir .Another important metric to consider is Mean Time to Recover (MTTR), which is the average time that it takes to restore the application after a failure. MTTR, bir sistem için empırical değeridir.MTTR is an empirical value for a system. MTTR, RTO 'yı aşarsa sistemdeki bir hata, ' sistemin tanımlanan RTO içinde geri yüklenmesi mümkün olmadığı için kabul edilemez bir iş kesintiye neden olur.If MTTR exceeds the RTO, then a failure in the system will cause an unacceptable business disruption because it won't be possible to restore the system within the defined RTO.

IaaS VM 'Leri için koruma seçenekleriProtection options for IaaS VMs

Yedekleme-geri yüklemeBackup-restore

VM tabanlı uygulamalar için en yaygın koruma şeması, yedekleme yazılımını kullanmaktır.The most common protection scheme for VM-based apps is to use backup software. VM yedeklemesi genellikle işletim sistemini, işletim sistemi yapılandırmasını, uygulama ikili dosyalarını ve VM 'nin içinde yer alan kalıcı uygulama verilerini içerir.Backing up a VM typically includes the operating system, operating system configuration, application binaries, and persistent application data contained inside the VM. Yedeklemeler, uygulama, işletim sistemi veya dosya sistemi/birimleri yakalamak için konuk işletim sistemindeki bir aracı kullanılarak oluşturulur.The backups are created by using an agent in the guest OS to capture application, OS, or file system/volumes. Farklı bir yaklaşım, VM yapılandırması ile ilgili bilgileri okumak ve VM 'ye bağlı diskleri anlık görüntüler ve Azure Stack hub API 'lerle tümleştirerek, aracıdan daha düşüktür.Another approach is agent-less by relying on integration with Azure Stack Hub APIs to read information about the VM configuration and snapshot the disks attached to the VM. Azure Stack hub 'ının doğrudan hiper yöneticinizden yedeklenmesini desteklemediğini lütfen unutmayın.Please note that Azure Stack Hub does not support backing up directly from the hypervisor.

Yedekleme stratejinizi planlamaPlanning your backup strategy

Yedekleme stratejinizi planlama ve ölçek gereksinimlerinin tanımlanması, korunması gereken sanal makine örneklerinin sayısını niceleyerek başlar.Planning your backup strategy and defining scale requirements starts with quantifying the number of VM instances that need to be protected. Sistemdeki tüm sanal makinelerin yedeklenmesi, uygulamayı korumanın en etkili yolu olmayabilir.Backing up all VMs in the system may not be the most effective way to protect application. Azure Stack hub ile, ölçek kümesi veya kullanılabilirlik kümesindeki VM 'Ler VM düzeyinde yedeklenmez.With Azure Stack Hub, VMs in a scale-set or availability set should not be backed up at the VM level. Bu VM 'Ler, sanal makine kümesi ölçeklendiğinden veya bir şekilde ölçeklendiği için kısa ömürlü olarak değerlendirilir. İdeal olarak, kalıcı olması gereken tüm veriler veritabanı veya nesne deposu gibi ayrı bir depodadır.These VMs are considered ephemeral since the set of VMs can be scaled-in or out. Ideally any data that needs to be persisted is in a separate repository such as a database or object store. Bir genişleme mimarisinde dağıtılan uygulamalar kalıcı ve korumalı olması gereken verileri içeriyorsa, uygulama tarafından belirtilen yerel özellikleri kullanarak veya bir aracıya bağlı olarak uygulama düzeyinde yedekleme yapılmasını gerektirir.If the applications deployed in a scale-out architecture contains data that must be persisted and protected, then that will require application level backup using native capabilities provided by the application or by relying on an agent.

Azure Stack VM 'Leri yedeklemeye yönelik önemli noktalar:Important considerations for backing up VMs on Azure Stack:

  • Kategorilere AyırmaCategorization
    • Kullanıcıların VM yedeklemesini kabul ettiği bir model düşünün.Consider a model where users opt into VM backup.
    • Uygulamaların önceliğine veya işletmenin etkilerine bağlı olarak bir kurtarma hizmet düzeyi anlaşması (SLA) tanımlayın.Define a recovery service level agreement (SLA) based on the priority of the applications or the impact to the business.
  • ÖlçeklendirmeScale
    • Çok sayıda yeni VM oluştururken (yedekleme gerekliyse) aşamalı yedeklemeleri göz önünde bulundurun.Consider staggered backups when on-boarding a large number of new VMs (if backup is required).
    • Çözümdeki kaynak içeriğini en aza indirmek için yedekleme verilerini etkili bir şekilde yakalayıp iletebilen yedekleme ürünlerini değerlendirin.Evaluate backup products that can efficiently capture and transmit backup data to minimize resource content on the solution.
    • Ortamdaki tüm VM 'lerde tam yedeklemeler gereksinimini en aza indirmek için artımlı veya değişiklik yedeklemeleri kullanarak yedekleme verilerini verimli bir şekilde depolayan yedekleme ürünlerini değerlendirin.Evaluate backup products that efficiently store backup data using incremental or differential backups to minimize the need for full backups across all VMs in the environment.
  • Geri yüklemeRestore
    • Yedekleme ürünleri sanal diskleri, var olan bir VM 'deki uygulama verilerini veya tüm VM kaynağını ve ilişkili sanal diskleri geri yükleyebilir.Backup products can restore virtual disks, app data within an existing VM, or the entire VM resource and associated virtual disks. Gerekli geri yükleme düzeni, uygulamayı nasıl geri yüklemeyi planladığınıza bağlıdır.The restore scheme you need depends on how you plan to restore the app. Örneğin, SQL Server 'ı bir şablondan yeniden dağıtmak ve ardından VM 'lerin tamamını veya VM kümesini geri yüklemek yerine veritabanlarını geri yüklemek daha kolay olabilir.For example, it may be easier to redeploy SQL server from a template and then restore the databases instead of restoring the entire VM or set of VMs.

Çoğaltma/el ile yük devretmeReplication/manual failover

Kurtarma desteklemeye yönelik alternatif bir yaklaşım, verileri başka bir ortama çoğaltmalıdır.An alternate approach to supporting recovery is to replicate data to another environment. Veriler, veritabanı çoğaltması veya bir aracı kullanarak Konuk IŞLETIM sistemindeki işletim sistemi veya Azure Stack hub API 'Leri ile tümleştirerek VM düzeyinde bir uygulama kapsamına eklenebilir.The data can be scoped to the application like database replication or to the operating system in the guest OS using an agent, or at the VM level by integrating with Azure Stack Hub APIs. Olağanüstü durum durumunda ikincil konuma yük devretme gerekir.In the event of a disaster, failover to the secondary location is required. Yük devretme işlemi, SQL kullanılabilirlik grupları veya aracı ya da küme teknolojisini kullanan Konuk işletim sistemi düzeyinde veya bir koruma ürünü kullanan VM düzeyinde yerel olarak bir uygulama tarafından işlenebilir.The failover can be handled natively by the application like with SQL Availability Groups or at the guest OS level using agents or cluster technology, or at the VM level using a protection product.

Yüksek kullanılabilirlik/otomatik yük devretmeHigh availability/automatic failover

Yüksek kullanılabilirliği yerel olarak destekleyen veya düğümlerde yüksek kullanılabilirlik sağlayan uygulamalar, tek bir Azure Stack hub 'ında veya birden çok Azure Stack hub örneğinde bulunan bir VM grubu arasında dağıtılabilir.Applications that natively support high availability or rely on cluster software to achieve high availability across nodes can be deployed across a group of VMs in one Azure Stack Hub or across multiple Azure Stack Hub instances. Her durumda, uygulama trafiğinin doğru şekilde yönlendirildiğinden emin olmak için bazı yük dengeleme düzeyi gereklidir.In all cases, some level of load balancing is required to ensure application traffic is routed correctly. Bu yapılandırmada, uygulama hatalardan otomatik olarak kurtarabilir.In this configuration, the application can automatically recover from faults. Yerel donanım hataları için Azure Stack hub altyapısı fiziksel altyapıda yüksek kullanılabilirlik ve hataya dayanıklılık uygular.For local hardware faults, Azure Stack Hub infrastructure implements high availability and fault tolerance in the physical infrastructure. Azure Stack hub, işlem düzeyi hatalarında bir N-1 yapılandırmasındaki ölçek biriminde birden çok düğüm kullanır.For compute level faults, Azure Stack Hub uses multiple nodes in a scale unit in an N-1 configuration. VM düzeyinde, kullanılabilirlik ve ölçek kümeleri, düğüm ve düğüm arızalarının dağıtılmış bir uygulamayı kapatmaması için düğüm düzeyinde benzeşim sağlamak üzere ölçek birimindeki her düğümü bir hata etki alanı olarak modelleyin.At the VM level, availability and scale sets model each node in the scale-unit as a fault domain to guarantee node-level anti-affinity so node failures do not take down a distributed application.

Koruma yokNo protection

Bazı uygulamalarda kalıcı olması gereken veriler bulunmayabilir.Some applications may not have data that needs to be persisted. Örneğin, geliştirme ve test için kullanılan VM 'Lerin genellikle ' kurtarılması gerekmez.For example, VMs used for development and testing typically don't need to be recovered. Bir hata durumunda CI/CD ardışık düzeninde yeniden dağıtılabilecek durum bilgisiz bir uygulamadır.Another example is a stateless application that can be re-deployed from a CI/CD pipeline in the event of a failure. VM 'Leri gereksiz şekilde korumayı önlemek için koruma gerektirmeyen uygulamaları belirlemek önemlidir.It is important to identify the applications that do not require protection to avoid unnecessarily protecting VMs.

Sonraki adımlarNext steps

Bu makalede, Azure Stack üzerinde dağıtılan Kullanıcı sanal makinelerini korumaya yönelik genel yönergeler sunulmaktadır.This article provided general guidelines for protecting user VMs deployed on Azure Stack. Kullanıcı sanal makinelerini korumak için Azure hizmetlerini kullanma hakkında daha fazla bilgi için bkz:For information about using Azure services to protect user VMs, refer to:

İş ortağı ürünleriPartner products