Развертывание приложений с высоким уровнем доступности в среде служб приложенийHighly available app deployment in App Services Environment

Зоны доступности — это физически разделенные коллекции центров обработки данных в пределах заданного региона.Availability zones are physically separated collections of datacenters within a given region. Репликация развертываний в нескольких зонах гарантирует, что локальные простои, ограниченные зоной, не оказывают негативного влияния на доступность приложения.Replicating your deployments across multiple zones, ensures that local outages limited to a zone do not negatively impact the availability of your application. Эта архитектура показывает, как можно повысить устойчивость развертывания ASE путем развертывания в нескольких зонах доступности.This architecture shows how you can improve the resiliency of an ASE deployment by deploying in multiple availability zones. Эти зоны не связаны с близостью.These zones are not related to proximity. Они могут сопоставляться с различными физическими расположениями для разных подписок.They can map to different physical locations for different subscriptions. Эта архитектура предполагает развертывание одной подписки.This architecture assumes a single subscription deployment.

Логотип GitHub . Эталонная реализация для этой архитектуры доступна на сайте GitHub.GitHub logo A reference implementation for this architecture is available on GitHub.

Эталонная архитектура для развертывания с высоким уровнем доступности ASE

АрхитектураArchitecture

Содержимое подсетей ASE, используемых в этой эталонной реализации, совпадает с теми, которые описаны в стандартной архитектуре развертывания ASE, описанной здесь.The contents of the ASE subnets used in this reference implementation are the same as the ones in the standard ASE deployment architecture described here. Эта эталонная реализация реплицирует развертывание в двух подсетях ASE.This reference implementation replicates the deployment in two ASE subnets. Каждая подсеть имеет собственное веб-приложение, API и экземпляры функций, выполняющиеся в отдельных планах службы приложений.Each subnet has its own web app, API, and function instances running in their individual App Service plans. Кэш Redis, необходимый для приложений, также реплицируется для повышения производительности.The Redis cache required by the applications are also replicated for better performance. Обратите внимание, что область этой эталонной архитектуры ограничена одним регионом.Note that the scope of this reference architecture is limited to a single region.

В следующем разделе показан характер доступности для служб, используемых в этой архитектуре:The following section shows the nature of availability for services used in this architecture:

Среды служб приложений можно развернуть в нескольких зонах доступности только во внутреннем или ilB режиме.App Services Environments can be deployed to multiple availability zones, only in internal or ILB mode. Эта эталонная реализация развертывает две подсети ASE, каждая из которых находится в другой зоне доступности.This reference implementation deploys two ASE subnets, each one in a different availability zone. Как минимум, для комплексной отказоустойчивости приложения рекомендуется использовать две зоны доступности.At the minimum, two availability zones are recommended for end-to-end resiliency of your application. Все ресурсы среды выполнения ILB ASE будут расположены в указанной зоне: IP-адрес внутренней подсистемы балансировки нагрузки ASE, ресурсы вычислений, а также базовое хранилище файлов, необходимое для работы ASE для запуска всех приложений, развернутых в этой ASE.All of the runtime ILB ASE resources will be located in the specified zone: the internal load balancer IP address of the ASE, the compute resources as well as the underlying file storage required by the ASE to run all the apps deployed on that ASE. Подробные инструкции и рекомендации см. в статье поддержка среда службы приложений для зоны доступности.For detailed guidance and recommendations, read App Service Environment Support for Availability Zones.

Виртуальная сеть Azure ( vnet ) охватывает все зоны доступности, ограниченные одним регионом.Azure Virtual Network or Vnet spans all availability zones limited to a single region. Подсети в виртуальной сети также распространяются между зонами доступности.The subnets within the VNet also span across availability zones. Эта Эталонная архитектура создает подсеть для каждого развертывания ASE, созданного для зоны доступности.This reference architecture creates a subnet for each ASE deployment created for an availability zone. Дополнительные сведения см. в статье требования к сети для сред службы приложений.For more information, read the network requirements for App Service Environments.

Шлюз приложений версии 2 является избыточнымв виде зоны.Application Gateway v2 is zone-redundant. Как и виртуальная сеть, она охватывает несколько зон доступности для каждого региона.Like the virtual network, it spans multiple availability zones per region. Это, в свою очередь, означает, что для высокодоступной системы достаточно одного шлюза приложений, как показано в этой эталонной архитектуре.This in turn means, a single application gateway is sufficient for a highly available system, as shown in this reference architecture. Номер SKU версии v1 не поддерживается.The v1 SKU does not support this. Дополнительные сведения см. в статье Автомасштабирование и избыточное в зонах приложение шлюза версии 2.For more details, read Autoscaling and Zone-redundant Application Gateway v2.

Брандмауэр Azure имеет встроенную поддержку обеспечения высокого уровня доступности.Azure Firewall has built-in support for high availability. Она может охватывать несколько зон без дополнительной настройки.It can span across multiple zones without any additional configuration. Это позволяет использовать один брандмауэр для приложений, развернутых в нескольких зонах, как это делается в этой эталонной архитектуре.This allows the usage of a single firewall for applications deployed in more than one zone, as done in this reference architecture. Хотя это и не используется в этой архитектуре, при необходимости можно также настроить конкретную зону доступности при развертывании брандмауэра.Although not used in this architecture, if necessary you can also configure a specific availability zone when deploying the firewall. Дополнительные сведения см. в статье брандмауэр Azure и зоны доступности .Read Azure Firewall and Availability Zones for more information.

Azure Active Directory — это высокодоступная, очень избыточная, Глобальная служба, охватывающая зоны доступности и регионы.Azure Active Directory is a highly available, highly redundant, global service, spanning availability zones as well as regions. Дополнительные сведения см. в статье о Azure Active Directory доступности .Read Advancing Azure Active Directory availability for more insights.

Azure pipelines поддерживает параллельную обработку действий CI/CD.Azure Pipelines supports parallel processing of CI/CD activities. Используйте эту возможность на этапе развертывания, чтобы одновременно развернуть созданные приложения в нескольких подсетях ASE с помощью нескольких виртуальных машин Jumpbox или подсетей бастиона.Use this in the deployment phase, to simultaneously deploy the built applications to multiple ASE subnets, through multiple jumpbox VMs or Bastion subnets. Эта архитектура использует две виртуальные машины Jumpbox, чтобы обеспечить возможность одновременного развертывания.This architecture uses two jumpbox virtual machines to help with the simultaneous deployment. Обратите внимание, что число параллельных заданий привязано к ценовой категории.Note the number of parallel jobs is tied to the pricing tier. Уровень "базовый" уровня "бесплатный" для непрерывной интеграции (CI/CD), размещаемой корпорацией Майкрософт, позволяет параллельно выполнять до 10 задач, каждая из которых работает до 6 часов.The basic free tier of a Microsoft-hosted CI/CD allows up to 10 tasks to be parallelized, each running up to 6 hours.

Кэш Azure для Redis не является службой, поддерживающей зоны.Azure Cache for Redis is not a zone-aware service. Эта архитектура создает две подсети для хранения кэша Redis, которые закрепляются в зоне доступности подсети ASE.This architecture creates two subnets to hold the Redis Cache, each pinned down to the availability zone of an ASE subnet. Это рекомендуется, так как чем ближе кэш к приложению, тем выше производительность приложения.This is recommended since the closer the cache to the application, the better the app performance. Обратите внимание, что это Предварительная версия функции, доступная только для уровня "Премиум".Note that this is a preview feature, available only for the Premium tier.

Вопросы доступностиAvailability considerations

Среда службы приложенийApp Service Environments

Среды службы приложений с ILB можно развернуть в определенной зоне доступности.App Service environments with ILB can be deployed to a specific availability zone. Зоны доступности являются географически разделенными резидентными центрами обработки данных в одном регионе.Availability zones are geographically separated self-sustained datacenters within the same region. Если один центр обработки данных выйдет из строя и ваша архитектура поддерживает, приложения, развернутые в других центрах обработки данных, могут обеспечить доступность.If one datacenter goes down, and if your architecture supports it, applications deployed to other datacenters can ensure availability.

Используйте эту функцию следующим образом.Make use of this feature by:

  • развертывание по крайней мере двух таких сред в двух разных зонах, при этом приложения дублируются в каждой ASE иdeploying at least two such environments to two distinct zones, with applications duplicated in each ASE, and
  • Балансировка нагрузки потока трафика в среды ASE с помощью шлюза приложений, избыточногов рамках зоны, как показано в этой эталонной архитектуре.load-balancing the traffic upstream to the ASEs, using a zone-redundant App Gateway, as demonstrated in this reference architecture.

Некоторые дополнительные моменты, которые следует учитывать:Some additional points to consider:

  • ILB ASE, развернутый в зоне, гарантирует время простоя для уже развернутых приложений и ресурсов, используемых ими.An ILB ASE deployed to a zone ensures uptime for already deployed apps and resources used by them. Однако масштабирование плана службы приложений, создание приложений и развертывание приложений по-прежнему может повлиять на сбои в других зонах.However, app service plan scaling, app creation, and app deployment may still be affected by outages in other zones.
  • Для первоначального развертывания ILB ASE в зоне доступности необходимо использовать шаблон ARM.An ARM template must be used for initial deployment of ILB ASE to an availability zone. После этого доступ к нему можно получить с помощью портала или командной строки.Thereafter, it can be accessed through the portal or the command line. Свойство Zones должно иметь значение 1, 2 или 3, обозначая логические зоны.The zones property must be set to 1, 2, or 3 denoting the logical zones.
  • Виртуальная сеть по умолчанию является избыточной в пределах зоны, поэтому все развернутые в зоне подсети ASE могут находиться в одной виртуальной сети.Virtual network by default is zone-redundant, hence all zone-deployed ASE subnets can reside in the same virtual network.
  • Внешний среды ASE не может быть прикреплен к зоне доступности.External-facing ASEs cannot be pinned to an availability zone.

Дополнительные сведения см. в статье поддержка среда службы приложений для зоны доступности.For more details, read App Service Environment Support for Availability Zones.

Рекомендации по обеспечению устойчивостиResiliency considerations

Приложения в обеих подсетях ASE формируют серверный пул для шлюза приложений.The applications in both the ASE subnets form the backend pool for the Application Gateway. Когда запрос к приложению выполняется из общедоступного Интернета, шлюз может выбрать один из двух экземпляров приложения.When a request to the application is made from the public internet, the gateway can choose either of the two application instances. По умолчанию шлюз приложений отслеживает работоспособность ресурсов серверного пула, как описано в разделе Обзор мониторинга работоспособности шлюза приложений.Application Gateway by default monitors the health of the backend pool resources, as described in Application Gateway health monitoring overview. В настройке ссылок проверка работоспособности по умолчанию может отслеживать только веб-интерфейс.In the reference setup, a default health probe can only monitor the web frontend. Поскольку этот веб-интерфейс, в свою очередь, использует другие компоненты, он может выглядеть работоспособным, но в случае сбоя зависимостей из-за частичного сбоя центра обработки данных в этой зоне он будет работать нормально.Since this web frontend in turn uses other components, it might look healthy but still fail if the dependencies fail due to a partial failure of the datacenter in that zone. Чтобы избежать таких сбоев, используйте пользовательскую пробу для управления работоспособностью приложения.To avoid such failures, use a custom probe to control what application health really means. Эта Эталонная архитектура реализует проверки работоспособности в основном веб-интерфейсе, вотингапп.This reference architecture implements Health Checks within the main web frontend, the votingApp. Эта проверка работоспособности проверяет работоспособность веб-API, а также кэша Redis.This health probe checks if the web API as well as the Redis cache are healthy. См. фрагмент кода, который реализует эту проверку в Startup.CS:See the snippet that implements this probe in the Startup.cs:

            var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionStrings:VotingDataAPIBaseUri"))
            {
                Path = "/health"
            };

            services.AddHealthChecks()
                .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
                .AddRedis(Configuration.GetValue<string>("ConnectionStrings:RedisConnectionString"));

В следующем фрагменте кода показано, как сценарий deploy_ha. sh настраивает серверные пулы и пробы работоспособности для шлюза приложений:The following snippet shows how the deploy_ha.sh script configures the backend pools and the health probe for the App Gateway:

# Generates parameters file for appgw arm script
cat <<EOF > appgwApps.parameters.json
[
  { 
    "name": "votapp", 
    "hostName": "${APPGW_APP1_URL}", 
    "backendAddresses": [ 
      { 
        "fqdn": "${INTERNAL_APP1_URL1}" 
      },
      { 
        "fqdn": "${INTERNAL_APP1_URL2}" 
      } 
    ], 
    "certificate": { 
      "data": "${CERT_DATA_1}", 
      "password": "${PFX_PASSWORD}" 
    }, 
    "probePath": "/health" 
  },
...

Если какой-либо из компонентов завершается сбоем в этой проверке работоспособности, то есть на веб интерфейсе, API или кэше, шлюз приложений направляет запрос в другое приложение из внутреннего пула.If either of the components fail in this health probe, that is the web frontend, the API, or the cache, the Application Gateway will route the request to the other application from the backend pool. Это гарантирует, что запрос всегда перенаправляется в приложение в полностью доступной подсети ASE.This makes sure that the request is always routed to the application in a completely available ASE subnet.

Проба работоспособности также реализована в стандартной эталонной реализации.The health probe is also implemented in the standard reference implementation. Шлюз просто возвращает ошибку в случае сбоя проверки работоспособности.There the gateway simply returns error if the health probe fails. Однако в реализации высокой доступности она повышает устойчивость приложения и качество взаимодействия с пользователем.However, in the highly available implementation, it improves the resiliency of the application and the quality of the user experience.

Рекомендации по развертываниюDeployment considerations

Эта эталонная реализация расширяет конвейер CI/CD уровня производства, используемый в стандартном развертывании, используя одну виртуальную машину Jumpbox для каждой зоны доступности.This reference implementation extends the production level CI/CD pipeline used in the standard deployment, by using one jumpbox virtual machine per availability zone. Это служит двум целям:This serves two purposes:

  • Закрепляет виртуальные машины в тех же зонах доступности, которые используются ресурсами ASE, обеспечивая время простоя в развертывании в случае сбоя, ограниченного одной или двумя зонами.Pins the virtual machines to the same availability zones used by the ASE resources, ensuring uptime in the deployment in case of a failure limited to one or two zones.
  • Он также помогает параллелизации развертывания, используя виртуальные машины в качестве пула агентов Azure pipelines.It also helps parallelize the deployment, by using the virtual machines as a pool of Azure Pipelines agents.

Файл Азуре-пипелинес. yml в этой эталонной реализации иллюстрирует это параллельное развертывание, создавая отдельные этапы развертывания для каждого зональные ASE.The azure-pipelines.yml file in this reference implementation illustrates this parallel deployment, by creating separate deploy stages for each zonal ASE.

Рекомендации по стоимостиCost considerations

Рекомендации по затратам для архитектуры с высоким уровнем доступности в основном похожи на стандартное развертывание.The cost considerations for the high availability architecture are mostly similar to the standard deployment.

Следующие отличия могут повлиять на стоимость:The following differences can affect the cost:

  • Несколько развертываний сред службы приложений.Multiple deployments of App Service environments.
  • Несколько развертываний кэша Azure для экземпляров уровня "Премиум " Redis.Multiple deployments of Azure Cache for Redis Premium tier instances. В этой эталонной архитектуре используется уровень Premium, так как:This reference architecture uses Premium tier, since:
    • В виртуальной сети можно использовать только кэш Redis уровня "Премиум".Only Premium tier Redis Cache can be used from within the virtual network, and
    • Зональные закрепление кэша Redis — общедоступная Предварительная версия функции доступна только на уровне Premium.Zonal pinning of Redis Cache, a public preview feature, is available only in the Premium tier.

Повышение уровня доступности, отказоустойчивости и безопасности системы увеличится.The tradeoff for high availability, resilient, and secure system will be increased cost. Оцените потребности предприятия в соответствии с ценами, используя Калькулятор цен.Evaluate the enterprise needs with respect to the pricing, using the pricing calculator.

Развертывание решенияDeploy the solution

Чтобы развернуть эталонную реализацию для этой архитектуры, ознакомьтесь с файлом readmeи выполните скрипт для развертывания с высоким уровнем доступности.To deploy the reference implementation for this architecture, see the GitHub readme, and follow the script for high availability deployment.

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

Вы можете расширить знания, продемонстрированные в этой эталонной архитектуре, и горизонтально масштабировать приложения в пределах одного региона или в нескольких регионах на основе ожидаемой емкости пиковой нагрузки.You can expand on the learnings demonstrated in this reference architecture, and horizontally scale your applications within the same region or across several regions, based on the expected peak load capacity. Репликация приложений в нескольких регионах может помочь снизить риски, связанные с более широкими географическими сбоями центра обработки данных, например из-за землетрясения или других стихийных бедствий.Replicating your applications on multiple regions may help mitigate the risks of wider geographical data center failures, such as due to earthquakes or other natural disasters. Дополнительные сведения о горизонтальном масштабировании см. в статье Геораспределенное масштабирование в средах службы приложений.To learn more on horizontal scaling, read Geo Distributed Scale with App Service Environments. Чтобы получить доступ к глобальным и высокодоступным решениям для маршрутизации, рассмотрите возможность использования передней дверцы Azure.For a global and highly-available routing solution, consider using Azure Front Door.