App Services Ortamı kullanarak yüksek oranda kullanılabilirliğe sahip kurumsal dağıtım

ASP.NET
Azure
Güvenlik Duvarı
Pipelines
.NET
GitHub

Kullanılabilirlik alanları , belirli bir bölgedeki veri merkezlerinin fiziksel olarak ayrılmış koleksiyonlarıdır.Availability zones are physically separated collections of datacenters within a given region. Dağıtımlarınızın birden çok bölgede çoğaltılması, bir bölgeyle sınırlı olan yerel kesintilerin uygulamanızın kullanılabilirliğini olumsuz şekilde etkilememesini sağlar.Replicating your deployments across multiple zones, ensures that local outages limited to a zone do not negatively impact the availability of your application. Bu mimari, birden çok kullanılabilirlik alanında dağıtım yaparak bir AO dağıtımının dayanıklılığını nasıl geliştirebileceğinizi gösterir.This architecture shows how you can improve the resiliency of an ASE deployment by deploying in multiple availability zones. Bu bölgeler yakınlık ile ilgili değildir.These zones are not related to proximity. Farklı abonelikler için farklı fiziksel konumlara eşleyebilir.They can map to different physical locations for different subscriptions. Bu mimaride tek bir abonelik dağıtımı varsayılır.This architecture assumes a single subscription deployment.

GitHub logosu Bu mimari için bir başvuru uygulama GitHub'da kullanılabilir.GitHub logo A reference implementation for this architecture is available on GitHub.

Yüksek kullanılabilirliğe sahip ASE dağıtımı için başvuru mimarisi

MimariArchitecture

Bu başvuru uygulamasında kullanılan AAS alt ağlarının içerikleri, burada açıklananstandart AAS dağıtım mimarisindeki olanlarla aynıdır.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. Bu başvuru uygulamasının dağıtımı iki AI alt ağı içinde çoğaltır.This reference implementation replicates the deployment in two ASE subnets. Her alt ağın kendi Web uygulaması, API 'SI ve tek tek App Service planlarında çalışan işlev örnekleri vardır.Each subnet has its own web app, API, and function instances running in their individual App Service plans. Uygulamalar için gereken Redsıs önbelleği, daha iyi performans için de çoğaltılır.The Redis cache required by the applications are also replicated for better performance. Bu başvuru mimarisinin kapsamının tek bir bölgeyle sınırlı olduğunu unutmayın.Note that the scope of this reference architecture is limited to a single region.

Aşağıdaki bölümde, Bu mimaride kullanılan hizmetler için kullanılabilirlik yapısı gösterilmektedir:The following section shows the nature of availability for services used in this architecture:

App Services ortamları , yalnızca Iç veya ILB modunda birden çok kullanılabilirlik bölgesine dağıtılabilir.App Services Environments can be deployed to multiple availability zones, only in internal or ILB mode. Bu başvuru uygulama, her biri farklı bir kullanılabilirlik alanında olmak üzere iki AI alt ağını dağıtır.This reference implementation deploys two ASE subnets, each one in a different availability zone. En azından, uygulamanızın uçtan uca dayanıklılığı için en az iki kullanılabilirlik bölgesi önerilir.At the minimum, two availability zones are recommended for end-to-end resiliency of your application. Çalışma zamanı ıLB ASE kaynakları, belirtilen bölgede yer alır: ASE 'nin iç yük dengeleyici IP adresi, işlem kaynakları ve ASE 'de dağıtılan tüm uygulamaları çalıştırmak için gereken temeldeki dosya depolama alanı.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. Ayrıntılı kılavuz ve öneriler için Kullanılabilirlik Alanları App Service ortamı desteğiniokuyun.For detailed guidance and recommendations, read App Service Environment Support for Availability Zones.

Azure sanal ağı veya VNET , tek bir bölgeyle sınırlı tüm kullanılabilirlik bölgelerini kapsar.Azure Virtual Network or Vnet spans all availability zones limited to a single region. VNet içindeki alt ağlar Ayrıca kullanılabilirlik alanları arasında da yayılamaz.The subnets within the VNet also span across availability zones. Bu başvuru mimarisi, bir kullanılabilirlik alanı için oluşturulan her Ao dağıtımı için bir alt ağ oluşturur.This reference architecture creates a subnet for each ASE deployment created for an availability zone. Daha fazla bilgi için App Service ortamları için ağ gereksinimleriniokuyun.For more information, read the network requirements for App Service Environments.

Application Gateway v2 , bölgesel olarak yedekli.Application Gateway v2 is zone-redundant. Sanal ağ gibi, her bölge için birden çok kullanılabilirlik bölgesi yayılır.Like the virtual network, it spans multiple availability zones per region. Bu da buna karşılık, bu başvuru mimarisinde gösterildiği gibi, yüksek oranda kullanılabilir bir sistem için tek bir uygulama ağ geçidi yeterlidir.This in turn means, a single application gateway is sufficient for a highly available system, as shown in this reference architecture. V1 SKU 'SU bunu desteklemiyor.The v1 SKU does not support this. Daha fazla ayrıntı için, Otomatik ölçeklendirmeyi ve bölgesel olarak yedekli Application Gateway v2'yi okuyun.For more details, read Autoscaling and Zone-redundant Application Gateway v2.

Azure Güvenlik Duvarı , yüksek kullanılabilirlik için yerleşik desteğe sahiptir.Azure Firewall has built-in support for high availability. Ek bir yapılandırma olmadan, birden çok bölgeye yayılabilir.It can span across multiple zones without any additional configuration. Bu, birden fazla bölgede dağıtılan uygulamalar için tek bir güvenlik duvarının kullanılmasına izin verir ve bu başvuru mimarisinde yapılır.This allows the usage of a single firewall for applications deployed in more than one zone, as done in this reference architecture. Bu mimaride kullanılmasa da, gerekirse güvenlik duvarını dağıtmada belirli bir kullanılabilirlik alanını da yapılandırabilirsiniz.Although not used in this architecture, if necessary you can also configure a specific availability zone when deploying the firewall. Daha fazla bilgi için Azure Güvenlik Duvarı 'nı okuyun ve kullanılabilirlik alanları .Read Azure Firewall and Availability Zones for more information.

Azure Active Directory , yüksek oranda kullanılabilir, yüksek düzeyde yedekli, küresel hizmet, kapsayıcı kullanılabilirlik bölgeleri ve bölgeler.Azure Active Directory is a highly available, highly redundant, global service, spanning availability zones as well as regions. Daha fazla öngörü için Azure Active Directory kullanılabilirliği hakkında bilgi edinin.Read Advancing Azure Active Directory availability for more insights.

Azure Pipelines , CI/CD etkinliklerinin paralel işlemesinidestekler.Azure Pipelines supports parallel processing of CI/CD activities. Oluşturulan uygulamaları birden çok Ai alt ağına eşzamanlı olarak dağıtmak için dağıtım aşamasında bunu kullanın.Use this in the deployment phase, to simultaneously deploy the built applications to multiple ASE subnets, through multiple jumpbox VMs or Bastion subnets. Bu mimari, eşzamanlı dağıtımda yardımcı olması için iki sıçrama kutusu sanal makinesi kullanır.This architecture uses two jumpbox virtual machines to help with the simultaneous deployment. Paralel işlerin sayısının fiyatlandırma katmanına bağlı olduğunu aklınızda yapın.Note the number of parallel jobs is tied to the pricing tier. Microsoft tarafından barındırılan bir CI/CD 'nin temel ücretsiz katmanı, her biri 6 saate kadar çalışan, en fazla 10 görevin paralelleştirilmesine olanak tanır.The basic free tier of a Microsoft-hosted CI/CD allows up to 10 tasks to be parallelized, each running up to 6 hours.

Redsıs Için Azure önbelleği , bölgeye duyarlı bir hizmet değildir.Azure Cache for Redis is not a zone-aware service. Bu mimari, her biri bir as alt ağının kullanılabilirlik bölgesine sabitlendiği Redis Cache tutacak iki alt ağ oluşturur.This architecture creates two subnets to hold the Redis Cache, each pinned down to the availability zone of an ASE subnet. Bu, uygulamanın önbelleği daha iyi olduğundan, uygulama performansının daha iyi olması nedeniyle önerilir.This is recommended since the closer the cache to the application, the better the app performance. Bu, yalnızca Premium katmanı için kullanılabilen bir Önizleme özelliğidir.Note that this is a preview feature, available only for the Premium tier.

Kullanılabilirlik konusunda dikkat edilmesi gerekenlerAvailability considerations

App Service ortamlarıApp Service Environments

ILB ile App Service ortamlar belirli bir kullanılabilirlik bölgesine dağıtılabilir.App Service environments with ILB can be deployed to a specific availability zone. Kullanılabilirlik alanları, coğrafi olarak ayrı, aynı bölgedeki şirket içi veri merkezlerinizdir.Availability zones are geographically separated self-sustained datacenters within the same region. Bir veri merkezi kapalıysa ve mimariniz destekliyorsa, diğer veri merkezlerine dağıtılan uygulamalar kullanılabilirliği güvence altına alabilir.If one datacenter goes down, and if your architecture supports it, applications deployed to other datacenters can ensure availability.

Bu özellikten yararlanarak şunları yapın:Make use of this feature by:

  • Her iki farklı bölgeye en az iki ortam dağıtmak, her bir AO 'da uygulamalar yinelenmesiyle vedeploying at least two such environments to two distinct zones, with applications duplicated in each ASE, and
  • Bu başvuru mimarisinde gösterildiği gibi, bölgesel olarak yedekli bir uygulama ağ geçidikullanarak trafiğin yukarı akış olarak yük dengelenmesi.load-balancing the traffic upstream to the ASEs, using a zone-redundant App Gateway, as demonstrated in this reference architecture.

Göz önünde bulundurulması gereken bazı ek noktaları:Some additional points to consider:

  • Bir bölgeye dağıtılan bir ıLB Ao, zaten dağıtılan uygulamalar ve kaynaklar için çalışma süresi sağlar.An ILB ASE deployed to a zone ensures uptime for already deployed apps and resources used by them. Ancak, App Service planı ölçeklendirmesi, uygulama oluşturma ve uygulama dağıtımı yine de diğer bölgelerdeki kesintilerden etkilenebilir.However, app service plan scaling, app creation, and app deployment may still be affected by outages in other zones.
  • Bir ARM şablonu, ıLB ATıCı 'in bir kullanılabilirlik bölgesine ilk dağıtımı için kullanılmalıdır.An ARM template must be used for initial deployment of ILB ASE to an availability zone. Bundan sonra portal veya komut satırı üzerinden erişilebilir.Thereafter, it can be accessed through the portal or the command line. Bölgeler özelliği, mantıksal bölgeleri belirten 1, 2 veya 3 olarak ayarlanmalıdır.The zones property must be set to 1, 2, or 3 denoting the logical zones.
  • Sanal ağ varsayılan olarak bölgesel olarak yedekli olduğundan bölge tarafından dağıtılan tüm asa alt ağları aynı sanal ağda yer alabilir.Virtual network by default is zone-redundant, hence all zone-deployed ASE subnets can reside in the same virtual network.
  • Dış kullanıma yönelik ASE 'ler bir kullanılabilirlik bölgesine sabitlenemez.External-facing ASEs cannot be pinned to an availability zone.

Daha fazla ayrıntı için Kullanılabilirlik Alanları App Service ortamı desteğiniokuyun.For more details, read App Service Environment Support for Availability Zones.

Dayanıklılık konularıResiliency considerations

Ao alt ağlarında bulunan uygulamalar, Application Gateway için arka uç havuzunu oluşturur.The applications in both the ASE subnets form the backend pool for the Application Gateway. Uygulamaya yönelik bir istek genel İnternet 'ten yapıldığında, ağ geçidi iki uygulama örneklerinden birini seçebilir.When a request to the application is made from the public internet, the gateway can choose either of the two application instances. Varsayılan olarak Application Gateway, Application Gateway durum izlemeye genel bakışbölümünde açıklandığı gibi arka uç havuz kaynaklarının sistem durumunu izler.Application Gateway by default monitors the health of the backend pool resources, as described in Application Gateway health monitoring overview. Başvuru kurulumunda, varsayılan bir sistem durumu araştırması yalnızca Web ön uç durumunu izleyebilir.In the reference setup, a default health probe can only monitor the web frontend. Bu Web ön ucu diğer bileşenleri kullandığından, bu durum sağlıklı görünebilir ancak yine de bağımlılıklar söz konusu bölgedeki veri merkezinde oluşan kısmi bir hatadan dolayı başarısız olursa başarısız olur.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. Bu hatalardan kaçınmak için, uygulama sistem durumunun gerçekten ne anlama geldiğini denetlemek için özel bir araştırma kullanın.To avoid such failures, use a custom probe to control what application health really means. Bu başvuru mimarisi, Votingapp ana Web ön ucu Içinde sistem durumu denetimleri uygular.This reference architecture implements Health Checks within the main web frontend, the votingApp. Bu durum araştırması, Web API 'sinin ve Redsıs önbelleğinin iyi durumda olup olmadığını denetler.This health probe checks if the web API as well as the Redis cache are healthy. Bu araştırmayı uygulayan kod parçacığına bakın 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"));

Aşağıdaki kod parçacığında deploy_ha. sh betiğinin, uygulama ağ geçidi için arka uç havuzlarını ve sistem durumu araştırmasını nasıl yapılandırdığı gösterilmektedir: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" 
  },
...

Bu durum araştırmasına ait bileşenlerden herhangi biri Web ön ucu, API veya önbellek ise, Application Gateway isteği arka uç havuzundan diğer uygulamaya yönlendirir.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. Bu, isteğin her zaman tamamen kullanılabilir bir ASE alt ağında uygulamaya yönlendirildiğinden emin olmanızı sağlar.This makes sure that the request is always routed to the application in a completely available ASE subnet.

Sistem durumu araştırması, standart başvuru uygulamasında da uygulanır.The health probe is also implemented in the standard reference implementation. Sistem durumu araştırması başarısız olursa ağ geçidi yalnızca hata döndürüyor.There the gateway simply returns error if the health probe fails. Ancak, yüksek oranda kullanılabilir uygulamada, uygulamanın dayanıklılığını ve kullanıcı deneyiminin kalitesini geliştirir.However, in the highly available implementation, it improves the resiliency of the application and the quality of the user experience.

Dağıtma konularıDeployment considerations

Bu başvuru uygulamasında, Standart dağıtımda kullanılan üretim düzeyi CI/CD işlem hattı, kullanılabilirlik alanı başına bir sıçrama kutusu sanal makinesi kullanılarak genişletilir.This reference implementation extends the production level CI/CD pipeline used in the standard deployment, by using one jumpbox virtual machine per availability zone. Bu iki amaca hizmet eder:This serves two purposes:

  • Sanal makineleri avas kaynakları tarafından kullanılan aynı Kullanılabilirlik bölgelerine sabitleyerek, bir veya iki bölge ile sınırlı bir arıza olması durumunda dağıtımda çalışma süresi sağlar.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.
  • Ayrıca, sanal makineleri bir Azure Pipelines aracılarıhavuzu olarak kullanarak dağıtıma paralel hale getirmek yardımcı olur.It also helps parallelize the deployment, by using the virtual machines as a pool of Azure Pipelines agents.

Bu başvuru uygulamasındaki Azure-Pipelines. onml dosyası, her bir bölgesel Ao için ayrı dağıtım aşamaları oluşturarak bu paralel dağıtımı gösterir.The azure-pipelines.yml file in this reference implementation illustrates this parallel deployment, by creating separate deploy stages for each zonal ASE.

Maliyetle ilgili konularCost considerations

Yüksek kullanılabilirlik mimarisine yönelik maliyet değerlendirmeleri genellikle standart dağıtıma benzerdir.The cost considerations for the high availability architecture are mostly similar to the standard deployment.

Aşağıdaki farklılıklar maliyeti etkileyebilir:The following differences can affect the cost:

  • App Service ortamların birden çok dağıtımı.Multiple deployments of App Service environments.
  • Redsıs Premium katman örnekleri için birden çok Azure önbelleği dağıtımı.Multiple deployments of Azure Cache for Redis Premium tier instances. Bu başvuru mimarisi, Premium katmanını kullanır, çünkü:This reference architecture uses Premium tier, since:
    • Yalnızca Premium katman Redis Cache sanal ağ içinden kullanılabilir veOnly Premium tier Redis Cache can be used from within the virtual network, and
    • Genel Önizleme özelliği olan Redis Cache çok sayıda sabitleme, yalnızca Premium katmanda kullanılabilir.Zonal pinning of Redis Cache, a public preview feature, is available only in the Premium tier.

Yüksek kullanılabilirlik, esnek ve güvenli sistem için zorunluluğunu getirir maliyeti artar.The tradeoff for high availability, resilient, and secure system will be increased cost. Fiyatlandırma hesaplayıcısı' nı kullanarak, fiyata göre kurumsal ihtiyaçları değerlendirin.Evaluate the enterprise needs with respect to the pricing, using the pricing calculator.

Çözümü dağıtmaDeploy the solution

Bu mimariye yönelik başvuru uygulamasını dağıtmak için GitHub Beniokudosyasına bakın ve yüksek kullanılabilirlik dağıtımı için betiği izleyin.To deploy the reference implementation for this architecture, see the GitHub readme, and follow the script for high availability deployment.

Sonraki adımlarNext steps

Bu başvuru mimarisinde gösterilen dersleri üzerinde genişletebilirsiniz ve uygulamalarınızı aynı bölgedeki veya birkaç bölgenin içinde yatay olarak ölçeklendirerek beklenen en yüksek yük kapasitesini temel alabilirsiniz.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. Uygulamalarınızı birden çok bölgede çoğaltmak, deprem veya diğer doğal felaketler gibi geniş coğrafi veri merkezi hatalarının risklerini azaltmaya yardımcı olabilir.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. Yatay ölçeklendirme hakkında daha fazla bilgi edinmek için App Service ortamları Ile coğrafi olarak dağıtılmış ölçekmakalesini okuyun.To learn more on horizontal scaling, read Geo Distributed Scale with App Service Environments. Küresel ve yüksek oranda kullanılabilir bir yönlendirme çözümü için Azure ön kapısınınkullanımını göz önünde bulundurun.For a global and highly-available routing solution, consider using Azure Front Door.