Высокий уровень доступности и аварийное восстановление для приложений IaaSHigh availability and disaster recovery for IaaS apps

В этой статье представлено дерево принятия решений и примеры параметров высокого уровня доступности (HA) и аварийного восстановления (DR) при развертывании приложений многоуровневой инфраструктуры как услуги (IaaS) в Azure.This article presents a decision tree and examples of high-availability (HA) and disaster recovery (DR) options when deploying multitier infrastructure-as-a-service (IaaS) apps to Azure.

Многоуровневая или n-уровневая архитектура широко распространена в традиционных локальных приложениях, поэтому они являются естественным выбором для переноса локальных приложений в облако или разработки приложений как в локальной среде, так и в облаке.Multitier or n-tier architectures are common in traditional on-premises apps, so they're a natural choice for migrating on-premises apps to the cloud, or when developing apps for both on-premises and the cloud. N-уровневые архитектуры обычно реализуются как приложения IaaS, разделенные на логические и физические уровни, с помощью верхнего уровня веб-приложений или представления, среднего уровня бизнеса и уровня данных.N-tier architectures are typically implemented as IaaS apps divided into logical layers and physical tiers, with a top web or presentation tier, a middle business tier, and a data tier.

В n-уровневой версии приложения каждый уровень выполняется на отдельном наборе виртуальных машин.In an IaaS n-tier app, each tier runs on a separate set of VMs. Уровни Web и Business не имеют состояния. Это означает, что любая виртуальная машина на уровне может выполнять любые запросы к этому уровню.The web and business tiers are stateless, meaning any VM in the tier can handle any request for that tier. Уровень данных — это реплицированная база данных, хранилище объектов или хранилище файлов.The data tier is a replicated database, object storage, or file storage. Несколько виртуальных машин на каждом уровне обеспечивают устойчивость, если одна виртуальная машина завершается сбоем, а подсистемы балансировки нагрузки распределяют запросы между виртуальными машинами.Multiple VMs in each tier provide resiliency if one VM fails, and load balancers distribute requests across the VMs.

Вы можете масштабировать уровни, добавив дополнительные виртуальные машины в пулы и используя масштабируемые наборы виртуальных машин для автоматического масштабирования идентичных виртуальных машин.You can scale out tiers by adding more VMs to the pools, and use virtual machine scale sets to automatically scale out identical VMs. Так как вы используете подсистемы балансировки нагрузки, можно масштабировать уровни, не влияя на время работы приложения.Because you use load balancers, you can scale out tiers without affecting app uptime.

Если соглашение об уровне обслуживания (SLA) для приложения IaaS требует > 99% доступности, можно разместить виртуальные машины в группах доступности, зонах доступностии группе размещения близости , чтобы настроить высокий уровень доступности для приложения.If the service-level agreement (SLA) for an IaaS app requires > 99% availability, you can place VMs in availability sets, availability zones, and proximity placement groups to configure high availability for the app. Выбор решений высокой доступности и аварийного восстановления зависит от требуемых соглашений об уровне обслуживания, требований к задержкам и региональных средств аварийного восстановления.The HA and DR solutions you choose depend on the required SLA, latency considerations, and regional DR requirements.

Варианты соответствующего использованияRelevant use cases

  • Перенос n-уровневого приложения из локальной среды в облако.Migrate an n-tier app from on-premises to the cloud.
  • Развертывание n-уровневого приложения как локально, так и в облаке.Deploy an n-tier app both on-premises and to the cloud.
  • Настройка высокого уровня доступности и аварийного восстановления для приложения IaaS.Configure high availability and disaster recovery for an IaaS app.

ArchitectureArchitecture

Дерево принятия решений высокой доступности

Группы доступности (группах доступности) обеспечивают избыточность и доступность виртуальных машин в центре обработки данных за счет распределения виртуальных машин между несколькими изолированными узлами оборудования.Availability sets (ASs) provide VM redundancy and availability within a datacenter by distributing VMs across multiple isolated hardware nodes. Подмножество виртуальных машин продолжает работать во время запланированного или незапланированного простоя, поэтому все приложение остается доступным и работающим.A subset of VMs keeps running during planned or unplanned downtime, so the entire app remains available and operational.

Зоны доступности (AZs) являются уникальными физическими расположениями, охватывающими центры обработки данных в регионе Azure.Availability zones (AZs) are unique physical locations that span datacenters within an Azure region. Каждое AZ обращается к одному или нескольким центрам обработки данных, имеющим независимую мощность, охлаждение и сеть, и каждый регион Azure с поддержкой AZ имеет как минимум три отдельных AZs.Each AZ accesses one or more datacenters that have independent power, cooling, and networking, and each AZ-enabled Azure region has a minimum of three separate AZs. Физическое разделение AZs в пределах региона защищает развернутые виртуальные машины от сбоев в центре обработки данных.The physical separation of AZs within a region protects deployed VMs from datacenter failure.

Блок-схема принятия решений отражает принцип, в котором приложения высокой доступности должны использовать AZs, если это возможно.The decision flowchart reflects the principle that HA apps should use AZs if possible. Кросс-Zone и, следовательно, перекрестный центр обработки данных, HA обеспечивает > 99,99% SLA из-за устойчивости к сбоям центра обработки данных.Cross-zone, and therefore cross-datacenter, HA provides > 99.99% SLA because of resilience to datacenter failure.

Группах доступности и AZs для разных уровней приложений не обязательно должны находиться в одном и том же центре обработки данных.ASs and AZs for different app tiers aren't guaranteed to be within the same datacenters. Если задержка приложения является основной проблемой, необходимо совместно разместить службы в одном центре обработки данных, используя группы размещения Ппгс с AZs и группах доступности.If app latency is a primary concern, you should colocate services in a single datacenter by using proximity placement groups (PPGs) with AZs and ASs.

Отдельные виртуальные машиныSingle VMs

Если приложению не требуется доступность > 99,9%, вам не нужно настраивать его для обеспечения высокой доступности, а также развертывать отдельные виртуальные машины.If an app doesn't require > 99.9% availability, you don't need to configure it for HA, and can deploy single VMs. Масштабируемые наборы виртуальных машин можно использовать для автоматического масштабирования идентичных виртуальных машин.You can use virtual machine scale sets to automatically scale out identical VMs. Развертывайте отдельные виртуальные машины без указания зоны, поэтому они распределяются по всему региону.Deploy single VMs without specifying a zone, so they're distributed throughout a region. При использовании дисков Azure SSD (цен. категория "Премиум") эти приложения имеют соглашение об уровне обслуживания, равное 99,9%.These apps have an SLA of 99.9% if you use Azure Premium SSD disks.

Одна виртуальная машина использует функцию восстановления службы по умолчанию, встроенную во все центры обработки данных Azure.Single VMs use the default service healing functionality built into all Azure datacenters. Для прогнозируемых сбоев эта функция обычно использует динамическую миграцию, но во время непредсказуемых событий виртуальные машины могут быть перезагружены или сделаны недоступными.For predictable failures, this functionality typically uses live migration, but during unpredictable events, VMs may be rebooted or made unavailable.

Высокий уровень доступностиHigh availability

Если приложению требуется соглашение об уровне обслуживания > 99,9%, разработайте приложение для обеспечения высокой доступности.If the app requires an SLA of > 99.9%, design the app for HA. По возможности используйте AZs, так как они обеспечивают отказоустойчивость в центре обработки данных.Use AZs if possible, because they provide datacenter fault tolerance. Можно использовать группах доступности вместо AZs, но использование группах доступности сокращает доступность с 99,99% на 99,95%, так как группах доступности не может допустить сбой центра обработки данных.You can use ASs instead of AZs, but using ASs reduces availability from 99.99% to 99.95%, because ASs can't tolerate datacenter failure.

AZs подходят для многих сценариев кластерных приложений, включая кластеры SQL AlwaysOn, использование режима "активный — активный", "активный — пассивный" или сочетание уровня высокой доступности на каждом уровне с быстрой отработкой отказа.AZs are suitable for many clustered app scenarios, including AlwaysOn SQL clusters, using active-active, active-passive, or a combination of both HA levels at each tier with fast failover. Синхронная репликация возможна между любыми узлами системы управления базами данных (СУБД) из-за низкой задержки в зональные сети.Synchronous replication is possible between any Database Management System (DBMS) nodes, because of the low latency of the cross-zonal network. Можно также запустить конфигурацию растянутого кластера в разных зонах, которая имеет более высокую задержку и поддерживает асинхронную репликацию.You can also run a stretched-cluster configuration across zones, which has higher latency and supports asynchronous replication.

Если вы хотите использовать арбитр кластерана основе виртуальной машины (например, файловый ресурс-свидетель), поместите его в третье AZ, чтобы предотвратить потерю кворума в случае сбоя одной зоны.If you want to use a VM-based cluster arbiter, for example a file-share witness, place it in the third AZ, to ensure quorum isn't lost if any one zone fails. Кроме того, вы можете использовать облачный следящий сервер в другом регионе.Alternatively, you might be able to use a cloud-based witness in another region.

Все виртуальные машины в AZ находятся в одном домене сбоя (демон) и домене обновления (обновления). Это означает, что они совместно используют общий источник питания и сетевой коммутатор, и все они могут быть перезагружены одновременно.All VMs in an AZ are in a single fault domain (FD) and update domain (UD), meaning they share a common power source and network switch, and can all be rebooted at the same time. Если вы создаете виртуальные машины в разных AZs, виртуальные машины эффективно распределяются между различными доменов сбоя и доменов обновления, поэтому они не будут перезагружаться в одно и то же время.If you create VMs across different AZs, your VMs are effectively distributed across different FDs and UDs, so they won't all fail or be rebooted at the same time. Если вы хотите использовать избыточные виртуальные машины в зонах, а также виртуальные машины с несколькими зонами, следует поместить в группах доступности в Ппгс виртуальные машины в зоне, чтобы они не перезагружались одновременно.If you want to have redundant in-zone VMs as well as cross-zone VMs, you should place the in-zone VMs in ASs in PPGs to ensure they won't all be rebooted at once. Даже для рабочих нагрузок виртуальных машин с одним экземпляром, которые не являются избыточными сегодня, можно по-прежнему использовать группах доступности в Ппгс для обеспечения будущего роста и гибкости.Even for single-instance VM workloads that aren't redundant today, you can still optionally use ASs in the PPGs to allow for future growth and flexibility.

Для развертывания масштабируемых наборов виртуальных машин в AZs рекомендуется использовать режим оркестрации, который в настоящее время находится в общедоступной предварительной версии, что позволяет объединять доменов сбоя и AZs.For deploying virtual machine scale sets across AZs, consider using Orchestration mode, currently in public preview, which allows combining FDs and AZs.

AZs с Ппгс в рамках зоны позволяют использовать одну из наименьших сетевых задержек в Azure и соглашение об уровне обслуживания не менее 99,99% из-за отказоустойчивости в нескольких центрах обработки данных.AZs with in-zone PPGs allow for one of the lowest network latencies in Azure, and an SLA of at least 99.99% because of multi-datacenter resiliency. Используйте ускоренную сеть на виртуальных машинах, где это возможно.Use accelerated networking on the VMs where possible.

Это решение может представлять ситуацию, когда служба, работающая на виртуальной машине в одной зоне, должна взаимодействовать со службой в другой зоне.This solution may present a scenario where a service running on a VM in one zone needs to interact with a service in another zone. Например, можно использовать веб-уровень "активный — активный" и уровень базы данных "активный-пассивный" в разных зонах.For example, there may be an active-active web tier and an active-passive database tier across zones. Некоторые запросы будут пересекаться между зонами, что приводит к задержкам.Some requests will cross zones, which introduces latency. Хотя задержка между зонами по-прежнему очень мала, если необходимо обеспечить наименьшую возможную задержку, следует сохранить все сетевые подключения между уровнями приложения в пределах зоны.While cross-zone latency is still very low, if you need to ensure the lowest possible latency, keep all network communications between app tiers within a zone.

Вопросы задержкиLatency considerations

Задержка сети зависит от других факторов на физическом расстоянии между развернутыми виртуальными машинами.Network latency depends, among other things, on the physical distance between deployed VMs. Если для приложения требуется очень низкая задержка между уровнями, можно развернуть его в одном центре обработки данных, используя ППГ с группах доступности для каждого уровня.If an app requires very low latency between tiers, you can deploy it in a single datacenter, using a PPG with ASs for each tier. По возможности используйте ускоренную сеть на виртуальных машинах.If possible, use accelerated networking on the VMs. Этот сценарий позволяет получить одну из самых низких сетевых задержек в Azure и соглашение об уровне обслуживания 99,95%.This scenario allows for one of the lowest network latencies in Azure, and an SLA of 99.95%.

Вы можете использовать следующие средства, чтобы получить более подробные сведения об условиях задержки для различных сценариев.You can use the following tools to gain better insight into latency conditions for a variety of scenarios:

  • Чтобы проверить задержку между виртуальными машинами, см. статью Проверка задержки сети виртуальной машины.To test the latency between VMs, see Test VM network latency.
  • Чтобы протестировать задержку между зонами, используйте авзоне-задержку-тест.To test latency between zones, use the AvZone-Latency-Test. Этот тест поможет определить, какие логические зоны имеют наименьшую задержку для подписки.This test can help you determine which logical zones have the lowest latency for your subscription.
  • Чтобы проверить задержку между регионами Azure, используйте http://www.azurespeed.com/ .To test latency between Azure regions, use http://www.azurespeed.com/. Это регулярно обновляемое средство может быть полезно при рассмотрении асинхронной репликации между регионами.This regularly updated tool can be useful when considering asynchronous replication between regions.

Аварийное восстановлениеDisaster recovery

Рекомендации по АВАРИЙному восстановлению включают доступность, возможность приложения работать в работоспособном состоянии и устойчивость данных, сохранение данных в случае аварии.DR considerations include availability, the ability of the app to keep running in a healthy state, and data durability, the preservation of data if a disaster happens.

Отработка отказа высокой доступности должна быть быстрой, без потери данных и очень ограниченного воздействия на службу.HA failover should be fast, with no data loss, and have a very limited effect on service. В отличие от этого, традиционная отработка отказа АВАРИЙного восстановления может иметь более длительное время (RTO) и целевую точку восстановления (RPO) и является асинхронной с возможной потерей данных.In contrast, a traditional DR failover may have a longer associated Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and is asynchronous, with potential data loss.

Вы можете воспользоваться преимуществами AZs для обеспечения высокого уровня доступности и аварийного восстановления, используя различные команды AZ для решения аварийного восстановления.You can take advantage of AZs for both HA and DR by using a different AZ for your DR solution. Однако использование другого AZ не гарантирует, что центры обработки данных в каждом из них будут находиться далеко друг от друга.However, using a different AZ doesn't guarantee that the datacenters in each AZ will be located physically far apart.

Azure Site Recovery позволяет реплицировать виртуальные машины в другой регион Azure для региональной аварийного восстановления и непрерывности бизнес-процессов.Azure Site Recovery lets you replicate VMs to another Azure region for regional disaster recovery and business continuity. Azure Site Recovery можно использовать для восстановления приложений в случае простоя исходного региона или проведения периодического аварийного восстановления, чтобы обеспечить соответствие требованиям.You can use Azure Site Recovery to recover your apps in the event of source region outages, or to conduct periodic disaster recovery drills to ensure you meet compliance requirements.

Если приложение поддерживает Azure Site Recovery, вы можете предоставить свое решение для расширенного аварийного восстановления, чтобы обеспечить повышенную защиту, если его важность требует это приложение.If your app supports Azure Site Recovery, you can provide a regional DR solution for increased protection, if the criticality of the app demands it. Тем не менее, кросс-Zone, высокая доступность в разных центрах обработки данных может быть достаточно защищенной, так как если приложение полностью устойчиво к сбоям центра обработки данных, это не должно быть простоев или потерь.However, cross-zone, cross-datacenter HA alone may be sufficient protection, because if an app is fully resilient to datacenter failure, there should be no downtime or data loss.

Альтернативные вариантыAlternatives

  • В качестве альтернативы региональному АВАРИЙному восстановлению с помощью Azure Site Recovery, если приложение может реплицировать данные в собственном режиме, можно реализовать Аварийное восстановление в нескольких регионах с помощью серверов горячего или холодного резерва, например растянутого кластера только для аварийного восстановления.As an alternative to regional DR using Azure Site Recovery, if the app can replicate data natively, you can implement multi-region DR using hot/cold standby servers, such as a stretched cluster for DR only. Эта альтернатива не особо подробно описана в примерах, но ее можно добавить в любое решение.This alternative isn't specifically detailed in the examples, but could be added to any of the solutions. Обратите внимание, что репликация между регионами является асинхронной и ожидается некоторая потери данных.Note that replication between regions is asynchronous, and some data loss is expected.

    Кроме того, при наличии собственной технологии репликации данных ее можно использовать для создания дополнительной зоны в регионе для аварийного восстановления.Alternatively, if you have your own data replication technology, you can use it to create a secondary in-region zone for DR. В зависимости от региона рабочих нагрузок можно также использовать Azure Site Recovery для репликации элементов в альтернативную зону, вы можете проверить региональные возможности доступности и прочесть дополнительные сведения об этой функции в статье Включение аварийного восстановления зоны для виртуальных машин Azure.Depending on the region of your workloads, it may also be possible to use Azure Site Recovery to replicate items to an alternative zone, you can check regional availability and read more about this feature at Enable Zone to Zone Disaster Recovery for Azure virtual machines.

  • Возможна высокая доступность в нескольких регионах, но для нее требуется глобальная подсистема балансировки нагрузки, например "Передняя дверь" или "диспетчер трафика".Multi-region HA is possible, but requires a global load balancer such as Front Door or Traffic Manager. Дополнительные сведения см. в статье запуск N-уровневого приложения в нескольких регионах Azure для обеспечения высокой доступности.For more information, see Run an N-tier application in multiple Azure regions for high availability.

РекомендацииConsiderations

  • AZs недоступны во всех регионах Azure.AZs aren't available in all Azure regions.

  • Выберите вариант развертывания, который будет использоваться перед построением решения.Decide which deployment option you want to use before you build the solution. Хотя это и возможно, нельзя легко перейти от одного варианта к другому после развертывания.Although possible, it's not easy to move from one option to another post-deployment. Необходимо удалить виртуальные машины и повторно создать их из базовых управляемых дисков, который является задействованным процессом.You would have to delete the VMs and recreate them from the underlying managed disks, which is an involved process.

  • Убедитесь, что вы можете сопоставлять приложение с выбранным решением.Make sure you can map your application against the selected solution. Многие шаблоны и схемы устойчивости уровня приложения выходят за рамки этого дерева принятия решений.Many app layer resiliency patterns and designs are outside the scope of this decision tree.

  • Три сценария могут привести к перезагрузке виртуальных машин Azure: незапланированное обслуживание оборудования, непредвиденное время простоя и плановое обслуживание.Three scenarios can lead to Azure VM reboots: unplanned hardware maintenance, unexpected downtime, and planned maintenance. Дополнительные сведения об этих событиях и рекомендациях по обеспечению высокой доступности для снижения их влияния см. в статье сведения о перезагрузках виртуальных машин, обслуживании и простоях.For more information about these events and HA best practices to reduce their impact, see Understand VM reboots, maintenance vs. downtime.

ЦеныPricing

Дополнительные затраты на виртуальные машины, развернутые в AZs, не взимается.There's no additional cost for VMs deployed in AZs. Может взиматься дополнительная плата за передачу данных между виртуальными машинами.There may be additional inter-AZ VM-to-VM data transfer charges. Дополнительные сведения см. на странице с ценами на пропускную способность.For more information, see the Bandwidth pricing page.