Защита виртуальных машин, развернутых на Azure Stack концентраторе — износоустойчивоеProtect VMs deployed on Azure Stack Hub - Ruggedized

Используйте эту статью как руководство по разработке плана для защиты виртуальных машин, развертываемых пользователями в центре Azure Stack.Use this article as a guide to develop a plan for protecting virtual machines (VMs) that your users deploy on Azure Stack Hub.

Чтобы защититься от потери данных и незапланированного простоя, реализуйте план защиты данных и аварийного восстановления для приложений на основе виртуальной машины в центре Azure Stack.To protect against data loss and unplanned downtime, implement a data protection and disaster recovery plan for VM-based applications on Azure Stack Hub. Реализованный план защиты будет зависеть от бизнес-требований и дизайна приложения.The protection plan implemented will depend on business requirements and design of the application. Этот план должен соответствовать инфраструктуре, установленной в вашей организации, с ' комплексной стратегией непрерывности бизнес-процессов и аварийного восстановления (BC/DR).This plan should follow the framework established by your organization's comprehensive business continuity and disaster recovery (BC/DR) strategy. Общий обзор рекомендаций BC/DR для Azure Stackного центра см. в разделе Azure Stack: рекомендации по обеспечению непрерывности бизнес-процессов и аварийному восстановлению.For a high level overview of the BC/DR considerations for Azure Stack Hub, see Azure Stack: Considerations for business continuity and disaster recovery.

Целевые показатели восстановления приложенияApplication recovery objectives

Определите объем простоя и потери данных, которые ваша организация может допустить для каждого приложения.Determine the amount of downtime and data loss your organization can tolerate for each application. Так вы сможете разработать план восстановления, который сводит к минимуму влияние сбоя в вашей организации.By quantifying downtime and data loss, you can create a recovery plan that minimizes the impact of a disaster on your organization. Для каждого приложения рассмотрите следующее:For each application, consider:

  • Целевое время восстановления (RTO)Recovery time objective (RTO)
    Это максимально допустимое время, в течение которого приложение может быть недоступно после инцидента.RTO is the maximum acceptable time that an app can be unavailable after an incident. Например, если RTO составляет 90 минут, это значит, вы должны иметь возможность восстановить приложение в рабочем состоянии в течение 90 минут с момента начала сбоя.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. Если у вас низкое RTO, вы можете оставить второе развертывание, постоянно работающее в режиме ожидания, для защиты от регионального сбоя.If you have a low RTO, you might keep a second deployment continually running on standby to protect against a regional outage.

  • Целевая точка восстановления (RPO)Recovery point objective (RPO)
    Это максимальная продолжительность потери данных, которая является приемлемой во время аварии.RPO is the maximum duration of data loss that is acceptable during a disaster. Например, если вы храните данные в отдельной базе данных без репликации в другие базы данных и ежечасно выполняете резервное копирование, вы можете потерять до часа данных.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.

Выполните оценку, чтобы определить RTO и RPO для каждого приложения.Conduct an assessment to define the RTO and RPO for each application.

Еще одна важная метрика, которую следует учитывать, — среднее время восстановления (MTTR), которое представляет собой среднее время, затрачиваемое на восстановление приложения после сбоя.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 является эмпирическим значением для системы.MTTR is an empirical value for a system. Если MTTR превышает RTO, то сбой в системе приведет к неприемлемому нарушению бизнеса, так как было невозможно ' восстановить систему в пределах определенного RTO.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.

Параметры защиты для виртуальных машин IaaSProtection options for IaaS VMs

Резервное копирование и восстановлениеBackup-restore

Наиболее распространенная схема защиты приложений, расположенных на виртуальной машине, — использовать программное обеспечение резервного копирования.The most common protection scheme for VM-based apps is to use backup software. Резервное копирование виртуальной машины обычно включает в себя операционную систему, конфигурацию операционной системы, двоичные файлы приложений и постоянные данные приложений, содержащиеся внутри виртуальной машины.Backing up a VM typically includes the operating system, operating system configuration, application binaries, and persistent application data contained inside the VM. Резервные копии создаются с помощью агента в гостевой ОС для записи приложения, ОС, файловой системы или томов.The backups are created by using an agent in the guest OS to capture application, OS, or file system/volumes. Еще один подход — меньше агента, который полагается на интеграцию с API-интерфейсами концентратора Azure Stack для считывания сведений о конфигурации виртуальной машины и моментальных снимков дисков, подключенных к виртуальной машине.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 не поддерживает резервное копирование непосредственно из низкоуровневой оболочки.Please note that Azure Stack Hub does not support backing up directly from the hypervisor.

Планирование стратегии резервного копированияPlanning your backup strategy

Планирование стратегии резервного копирования и определение требований к масштабу начинается с определения количества экземпляров виртуальной машины, которые необходимо защитить.Planning your backup strategy and defining scale requirements starts with quantifying the number of VM instances that need to be protected. Резервное копирование всех виртуальных машин в системе может быть не самым эффективным способом защиты приложения.Backing up all VMs in the system may not be the most effective way to protect application. В центре Azure Stack не следует создавать резервные копии виртуальных машин в наборе масштабирования или группы доступности на уровне виртуальной машины.With Azure Stack Hub, VMs in a scale-set or availability set should not be backed up at the VM level. Эти виртуальные машины считаются временными, так как набор виртуальных машин можно масштабировать. В идеале все данные, которые необходимо сохранить, находятся в отдельном репозитории, таком как база данных или хранилище объектов.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. Если приложения, развернутые в архитектуре с масштабным развертыванием, содержат данные, которые должны быть сохранены и защищены, то для этого потребуется резервное копирование на уровне приложения с использованием собственных возможностей, предоставляемых приложением, или с помощью агента.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.Important considerations for backing up VMs on Azure Stack:

  • КлассификацияCategorization
    • Рассмотрим модель, в которой пользователи хотят использовать резервное копирование виртуальных машин.Consider a model where users opt into VM backup.
    • Определите соглашение об уровне обслуживания (SLA) для восстановления на основе приоритетов приложений или влияния на бизнес.Define a recovery service level agreement (SLA) based on the priority of the applications or the impact to the business.
  • МасштабированиеScale
    • Рассмотрите поочередное резервное копирование при подключении большого количества новых виртуальных машин (если резервное копирование требуется).Consider staggered backups when on-boarding a large number of new VMs (if backup is required).
    • Оцените решения резервного копирования, которые могут эффективно собирать и передавать данные резервного копирования, чтобы свести к минимуму содержимое ресурса в решении.Evaluate backup products that can efficiently capture and transmit backup data to minimize resource content on the solution.
    • Оцените решения резервного копирования, которые эффективно хранят данные архивации, используя добавочные или разностные резервные копии, чтобы свести к минимуму необходимость полных резервных копий во всех виртуальных машинах среды.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.
  • ВосстановитьRestore
    • Решения резервного копирования могут восстанавливать виртуальные диски, данные приложения в имеющейся виртуальной машине или весь ресурс виртуальной машины и связанные виртуальные диски.Backup products can restore virtual disks, app data within an existing VM, or the entire VM resource and associated virtual disks. Нужная схема восстановления зависит от того, как вы планируете восстанавливать приложение.The restore scheme you need depends on how you plan to restore the app. Например, проще повторно развернуть сервер SQL из шаблона, а затем восстановить базы данные вместо восстановления всей виртуальной машины или их набора.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.

Репликация и переход на другой ресурс вручнуюReplication/manual failover

Альтернативный подход к поддержке восстановления — репликация данных в другую среду.An alternate approach to supporting recovery is to replicate data to another environment. Данные могут быть ограничены такими приложениями, как репликация базы данных или операционная система в гостевой ОС с помощью агента или на уровне виртуальной машины путем интеграции с интерфейсами API концентратора Azure Stack.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. В случае аварии требуется отработка отказа в дополнительное расположение.In the event of a disaster, failover to the secondary location is required. Отработка отказа может быть изначально обработана приложением, например с группами доступности SQL или на уровне гостевой ОС с помощью агентов или технологии кластеров, или на уровне виртуальной машины с помощью продукта защиты.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.

Высокий уровень доступности и автоматический переход на другой ресурсHigh availability/automatic failover

Приложения, изначально поддерживающие высокий уровень доступности или использующие программное обеспечение кластера для обеспечения высокой доступности между узлами, можно развертывать в одной группе виртуальных машин в одном концентраторе Azure Stack или в нескольких экземплярах концентратора Azure Stack.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. Во всех случаях требуется определенный уровень балансировки нагрузки, чтобы обеспечить правильную маршрутизацию трафика приложения.In all cases, some level of load balancing is required to ensure application traffic is routed correctly. В этой конфигурации приложение может автоматически восстанавливаться после ошибок.In this configuration, the application can automatically recover from faults. Для локальных сбоев оборудования Azure Stack инфраструктура концентратора реализует высокую доступность и отказоустойчивость в физической инфраструктуре.For local hardware faults, Azure Stack Hub infrastructure implements high availability and fault tolerance in the physical infrastructure. Для ошибок уровня вычислений центр Azure Stack использует несколько узлов в единице масштабирования в конфигурации N-1.For compute level faults, Azure Stack Hub uses multiple nodes in a scale unit in an N-1 configuration. На уровне виртуальной машины уровни доступности и масштабирования моделируют каждый узел в единице масштабирования как домен сбоя, чтобы обеспечить сглаживание на уровне узла, чтобы сбои узлов не применялись к распределенному приложению.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.

Без защитыNo protection

Некоторые приложения не могут содержать данные, которые необходимо сохранить.Some applications may not have data that needs to be persisted. Например, виртуальные машины, используемые для разработки и тестирования, обычно ' не нуждаются в восстановлении.For example, VMs used for development and testing typically don't need to be recovered. Еще один пример — это приложение без отслеживания состояния, которое можно повторно развернуть из конвейера CI/CD в случае сбоя.Another example is a stateless application that can be re-deployed from a CI/CD pipeline in the event of a failure. Важно отметить приложения, которые не требуют защиты, чтобы избежать ненужной защиты виртуальных машин.It is important to identify the applications that do not require protection to avoid unnecessarily protecting VMs.

Дальнейшие действияNext steps

В этой статье представлены общие рекомендации для защиты пользовательских виртуальных машин, развернутых в Azure Stack.This article provided general guidelines for protecting user VMs deployed on Azure Stack. Дополнительные сведения о защите виртуальных машин пользователей с помощью служб Azure см. в следующих статьях:For information about using Azure services to protect user VMs, refer to:

Партнерские продуктыPartner products