Load Balancer úrovně Standard a zóny dostupnostiStandard Load Balancer and Availability Zones

Azure Standard Load Balancer podporuje scénáře zón dostupnosti .Azure Standard Load Balancer supports availability zones scenarios. Standard Load Balancer můžete použít k optimalizaci dostupnosti v celém koncovém scénáři tím, že zarovnáte prostředky se zónami a rozdělujete je mezi zónami.You can use Standard Load Balancer to optimize availability in your end-to-end scenario by aligning resources with zones and distributing them across zones. Projděte si zóny dostupnosti , kde najdete pokyny k tomu, jaké zóny dostupnosti jsou, které oblasti aktuálně podporují zóny dostupnosti, a další související koncepty a produkty.Review availability zones for guidance on what availability zones are, which regions currently support availability zones, and other related concepts and products. zóny dostupnosti v kombinaci s Standard Load Balancer jsou flexibilní sada funkcí obsáhlém, která může vytvářet mnoho různých scénářů.availability zones in combination with Standard Load Balancer is an expansive and flexible feature set that can create many different scenarios. Přečtěte si tento dokument, abyste pochopili tyto Koncepty a základní pokyny k návrhuscénářů.Review this document to understand these concepts and fundamental scenario design guidance.

Důležité

V tématu zóny dostupnosti najdete související témata, včetně informací o konkrétní oblasti.Review Availability Zones for related topics, including any region specific information.

Zóny dostupnosti koncepty použité pro Load BalancerAvailability Zones concepts applied to Load Balancer

Mezi prostředky Load Balancer a skutečnou infrastrukturou nejsou žádné přímé vztahy. Vytvoření Load Balancer instanci nevytvoří.There's no direct relationship between Load Balancer resources and actual infrastructure; creating a Load Balancer doesn't create an instance. Prostředky Load Balancer jsou objekty, ve kterých můžete vyjádřit, jak by měl Azure naprogramovat svou předem vytvořenou infrastrukturu více tenantů, aby dosáhli scénáře, který chcete vytvořit.Load Balancer resources are objects within which you can express how Azure should program its prebuilt multi-tenant infrastructure to achieve the scenario you wish to create. To je v kontextu zón dostupnosti významné, protože jeden Load Balancer prostředek může řídit programování infrastruktury v několika zónách dostupnosti, zatímco služba redundantní v rámci zóny vypadá jako jeden prostředek z pohledu zákazníka.This is significant in the context of availability zones because a single Load Balancer resource can control programming of infrastructure in multiple availability zones while a zone-redundant service appears as one resource from a customer point of view.

Prostředek Load Balancer sám o sobě není oblast.A Load Balancer resource itself is regional and never zonal. A virtuální síť a podsíť jsou vždy oblastní a nikdy nepracují.And a VNet and subnet are always regional and never zonal. Členitost toho, co můžete nakonfigurovat, je omezené každou konfigurací front-endu, pravidla a definice fondu back-endu.The granularity of what you can configure is constrained by each configuration of frontend, rule, and backend pool definition.

V kontextu zón dostupnosti se chování a vlastnosti pravidla Load Balancer popisují jako redundantní nebo oblasti.In the context of availability zones, the behavior and properties of a Load Balancer rule are described as zone-redundant or zonal. Redundantní zóna a oblast popisují zonality vlastnosti.Zone-redundant and zonal describe the zonality of a property. V souvislosti s Load Balancer se v zóně – redundantní vždy znamená, že několik zón a oblastí znamená izolaci služby do jedné zóny.In the context of Load Balancer, zone-redundant always means multiple zones and zonal means isolating the service to a single zone.

Veřejné i interní Load Balancer podporují scénáře redundantních a oblastí a oba můžou směrovat provoz napříč zónami podle potřeby (vyrovnávánízatížení mezi zónami).Both public and internal Load Balancer support zone-redundant and zonal scenarios and both can direct traffic across zones as needed (cross-zone load-balancing).

Front-endFrontend

Front-end Load Balancer je konfigurace IP adresy front-endu, která odkazuje buď na prostředek veřejné IP adresy, nebo na privátní IP adresu v rámci sítě virtuálního síťového prostředku.A Load Balancer frontend is a frontend IP configuration referencing either a public IP address resource or a private IP address within the subnet of a virtual network resource. Vytvoří koncový bod s vyrovnáváním zatížení, ve kterém je vaše služba vystavená.It forms the load balanced endpoint where your service is exposed.

Prostředek Load Balancer může obsahovat pravidla s oblastmi a současně redundantními frontami typu zóna.A Load Balancer resource can contain rules with zonal and zone-redundant frontends simultaneously.

Pokud je pro zónu zaručený prostředek veřejné IP adresy nebo privátní IP adresa, zonality (nebo nejeho absence) není proměnlivý.When a public IP resource or a private IP address has been guaranteed to a zone, the zonality (or lack thereof) isn't mutable. Pokud chcete změnit nebo vynechat zonality veřejné IP adresy nebo front-endu privátních IP adres, musíte znovu vytvořit veřejnou IP adresu v příslušné zóně.If you wish to change or omit the zonality of a public IP or private IP address frontend, you need to recreate the public IP in the appropriate zone. Zóny dostupnosti nemění omezení pro více front-endu, Projděte si více front-endu pro Load Balancer , kde najdete podrobnosti o této možnosti.Availability zones do not change the constraints for multiple frontend, review multiple frontends for Load Balancer for details for this ability.

Zóna redundantní ve výchozím nastaveníZone redundant by default

V oblasti se zónami dostupnosti je Standard Load Balancer front-endu ve výchozím nastavení redundantní v zóně.In a region with availability zones, a Standard Load Balancer frontend is zone-redundant by default. Redundantní zóna znamená, že všechny příchozí nebo odchozí toky jsou obsluhovány několika zónami dostupnosti v oblasti současně pomocí jediné IP adresy.Zone-redundant means that all inbound or outbound flows are served by multiple availability zones in a region simultaneously using a single IP address. Schémata redundance DNS se nevyžadují.DNS redundancy schemes aren't required. Jedna IP adresa front-endu může překonat selhání zóny a dá se použít k přístupu ke všem (neovlivněným) členům fondu back-endu bez ohledu na zónu.A single frontend IP address can survive zone failure and can be used to reach all (non-impacted) backend pool members irrespective of the zone. Jedna nebo více zón dostupnosti můžou selhat a cesta k datům zůstane v pořádku, dokud jedna zóna v oblasti zůstane v dobrém stavu.One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy. Jedna IP adresa front-endu je souběžně obsluhována několika nezávislými nasazeními infrastruktury v několika zónách dostupnosti.The frontend's single IP address is served simultaneously by multiple independent infrastructure deployments in multiple availability zones. To neznamená hitless cestu k datům, ale všechny opakované pokusy nebo opětovné vytvoření budou úspěšné v jiných zónách, které neovlivní selhání zóny.This doesn't mean hitless data path, but any retries or reestablishment will succeed in other zones not impacted by the zone failure.

V následujícím výňatku najdete ukázku definování veřejné IP adresy, která je redundantní pro veřejnou IP adresu pro použití s vaším veřejným Standard Load Balancer.The following excerpt is an illustration for how to define a public IP a zone-redundant Public IP address to use with your public Standard Load Balancer. Pokud v konfiguraci používáte existující šablony Správce prostředků, přidejte k těmto šablonám oddíl SKU .If you're using existing Resource Manager templates in your configuration, add the sku section to these templates.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/publicIPAddresses",
            "name": "public_ip_standard",
            "location": "region",
            "sku":
            {
                "name": "Standard"
            },

Následující úryvek představuje ukázku definování IP adresy redundantní zóny front-endu pro interní Standard Load Balancer.The following excerpt is an illustration for how to define a zone-redundant frontend IP address for your internal Standard Load Balancer. Pokud v konfiguraci používáte existující šablony Správce prostředků, přidejte k těmto šablonám oddíl SKU .If you're using existing Resource Manager templates in your configuration, add the sku section to these templates.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/loadBalancers",
            "name": "load_balancer_standard",
            "location": "region",
            "sku":
            {
                "name": "Standard"
            },
            "properties": {
                "frontendIPConfigurations": [
                    {
                        "name": "zone_redundant_frontend",
                        "properties": {
                            "subnet": {
                                "Id": "[variables('subnetRef')]"
                            },
                            "privateIPAddress": "10.0.0.6",
                            "privateIPAllocationMethod": "Static"
                        }
                    },
                ],

Předchozí výňatky nejsou kompletními šablonami, jejichž cílem je Ukázat, jak vyjádřit vlastnosti zón dostupnosti.The preceeding excerpts are not complete templates but intended to show how to express availability zones properties. Tyto příkazy musíte zahrnout do svých šablon.You need to incorporate these statements into your templates.

Volitelná izolace zónyOptional zone isolation

Můžete zvolit, aby front-end byl zaručen pro jednu zónu, která se nazývá oblast front-endu.You can choose to have a frontend guaranteed to a single zone, which is known as a zonal frontend. To znamená, že jakýkoliv příchozí nebo odchozí tok je obsluhován jedinou zónou v oblasti.This means any inbound or outbound flow is served by a single zone in a region. Vaše sdílená složka front-endu sepravila se stavem zóny.Your frontend shares fate with the health of the zone. Cesta k datům není ovlivněná chybami v jiných zónách, než kde byla zaručena.The data path is unaffected by failures in zones other than where it was guaranteed. K vystavení IP adresy na jednu zónu dostupnosti můžete použít oblast front-endu.You can use zonal frontends to expose an IP address per Availability Zone.

Kromě toho můžete využít oblasti front-endu přímo pro koncové body s vyrovnáváním zatížení v rámci každé zóny.Additionally, you can consume zonal frontends directly for load balanced endpoints within each zone. Tuto možnost můžete použít také k vystavení koncovým bodům pro vyrovnávání zatížení zóny pro samostatné monitorování každé zóny.You can also use this to expose per zone load-balanced endpoints to individually monitor each zone. Nebo veřejné koncové body můžete integrovat s produktem pro vyrovnávání zatížení DNS, jako je Traffic Manager a používat jeden název DNS.Or for public endpoints you can integrate them with a DNS load-balancing product like Traffic Manager and use a single DNS name. Klient pak bude tento název DNS překládat na více IP adres na více oblastech.The client then will then resolve to this DNS name to multiple zonal IP addresses.

Pokud chcete tyto koncepty (zóny redundantní a oblasti pro stejný back-end) kombinovat, Projděte si téma více front-endu pro Azure Load Balancer.If you wish to blend these concepts (zone-redundant and zonal for same backend), review multiple frontends for Azure Load Balancer.

U veřejné Load Balancer front-endu přidejte parametr Zones do prostředku veřejné IP adresy, na který odkazuje konfigurace IP adresy front-endu používané příslušným pravidlem.For a public Load Balancer frontend, you add a zones parameter to the public IP resource referenced by the frontend IP configuration used by the respective rule.

U interního front-endu Load Balancer přidejte do konfigurace protokolu IP front-endu interní Load Balancer parametr Zones.For an internal Load Balancer frontend, add a zones parameter to the internal Load Balancer frontend IP configuration. Oblast front-end způsobí, že Load Balancer garantuje IP adresu v podsíti s konkrétní zónou.The zonal frontend causes the Load Balancer to guarantee an IP address in a subnet to a specific zone.

Následující úryvek je příkladem, jak v Zóna 1 dostupnosti definovat standardní veřejnou IP adresu Zona.The following excerpt is an illustration for how to define a zonal Standard Public IP address in Availability Zone 1. Pokud v konfiguraci používáte existující šablony Správce prostředků, přidejte k těmto šablonám oddíl SKU .If you're using existing Resource Manager templates in your configuration, add the sku section to these templates.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/publicIPAddresses",
            "name": "public_ip_standard",
            "location": "region",
            "zones": [ "1" ],
            "sku":
            {
                "name": "Standard"
            },

Následující úryvek je ilustrace, jak definovat interní Standard Load Balancer front-end v Zóna 1 dostupnosti.The following excerpt is an illustration for how to define an internal Standard Load Balancer front end in Availability Zone 1. Pokud v konfiguraci používáte existující šablony Správce prostředků, přidejte k těmto šablonám oddíl SKU .If you're using existing Resource Manager templates in your configuration, add the sku section to these templates. Také definujte vlastnost Zones v konfiguraci protokolu IP front-endu pro podřízený prostředek.Also, define the zones property in the frontend IP configuration for the child resource.

            "apiVersion": "2017-08-01",
            "type": "Microsoft.Network/loadBalancers",
            "name": "load_balancer_standard",
            "location": "region",
            "sku":
            {
                "name": "Standard"
            },
            "properties": {
                "frontendIPConfigurations": [
                    {
                        "name": "zonal_frontend_in_az1",
                        "zones": [ "1" ],
                        "properties": {
                            "subnet": {
                                "Id": "[variables('subnetRef')]"
                            },
                            "privateIPAddress": "10.0.0.6",
                            "privateIPAllocationMethod": "Static"
                        }
                    },
                ],

Předchozí výňatky nejsou kompletními šablonami, jejichž cílem je Ukázat, jak vyjádřit vlastnosti zón dostupnosti.The preceeding excerpts are not complete templates but intended to show how to express availability zones properties. Tyto příkazy musíte zahrnout do svých šablon.You need to incorporate these statements into your templates.

Vyrovnávání zatížení mezi zónamiCross-zone Load-Balancing

Vyrovnávání zatížení mezi zónami je schopnost Load Balancer získat přístup ke koncovému bodu back-endu v libovolné zóně a nezávisle na front-endu a zonality.Cross-zone load-balancing is the ability of Load Balancer to reach a backend endpoint in any zone and is independent of frontend and its zonality. Jakékoli pravidlo vyrovnávání zatížení může cílit na instanci back-endu v jakékoli zóně dostupnosti nebo regionálních instancích.Any load balancing rule can target backend instance in any availability zone or regional instances.

Musíte se postarat o vytvoření scénáře způsobem, který vyjádří zóny dostupnosti.You need to take care to construct your scenario in a manner which expressed an availability zones notion. Například je třeba zaručit nasazení virtuálních počítačů v rámci jedné nebo více zón a v oblasti front-endu a back-endu na stejné zóně.For example, you need guarantee your virtual machine deployment within a single zone or multiple zones, and align zonal frontend and zonal backend resources to the same zone. Pokud jste provedli zóny pro různé oblasti dostupnosti jenom s využitím oblastí, bude scénář fungovat, ale nemusí mít jasný režim selhání s ohledem na zóny dostupnosti.If you cross availability zones with only zonal resources, the scenario will work but may not have a clear failure mode with respect to availability zones.

Back-endBackend

Load Balancer funguje s instancemi virtuálních počítačů.Load Balancer works with virtual machines instances. Můžou to být samostatné, skupiny dostupnosti nebo sady škálování virtuálních počítačů.These can be standalone, availability sets, or virtual machine scale sets. Každá instance virtuálního počítače v jedné virtuální síti může být součástí fondu back-endu bez ohledu na to, jestli je nebo není zaručená zóna nebo která zóna byla zaručena.Any virtual machine instance in a single virtual network can be part of the backend pool irrespective of whether or not it was guaranteed to a zone or which zone was guaranteed to.

Pokud chcete zařadit a zaručovat front-end a back-end s jedinou zónou, umístěte virtuální počítače pouze do příslušné zóny do příslušného back-endu.If you wish to align and guarantee your frontend and backend with a single zone, only place virtual machines within the same zone into the respective backend pool.

Pokud chcete virtuálním počítačům vymezit více zón, jednoduše umístěte virtuální počítače z několika zón do stejného back-end fondu.If you wish to address virtual machines across multiple zones, simply place virtual machines from multiple zones into the same backend pool. Při používání virtuálních počítačů Virtual Machine Scale Sets můžete do stejného back-endu umístit jednu nebo víc sad škálování virtuálního počítače.When using virtual machine scale sets, you can place one or more virtual machine scale sets into the same backend pool. Všechny tyto sady škálování virtuálních počítačů můžou být v jedné nebo několika zónách.And each of these virtual machine scale sets can be in a single or multiple zones.

Odchozí připojeníOutbound connections

Stejné vlastnosti – redundantní a ploché vlastnosti se vztahují na odchozí připojení.The same zone-redundant and zonal properties apply to outbound connections. Veřejná IP adresa redundantní v zóně používaná pro odchozí připojení je obsluhována všemi zónami.A zone-redundant public IP address used for outbound connections is served by all zones. Veřejná IP adresa oblasti je dodávána pouze v zóně, ve které je zaručena.A zonal public IP address is served only by the zone it is guaranteed in. Odchozí připojení port SNAT zachová selhání zóny a váš scénář bude i nadále poskytovat odchozí připojení SNAT, pokud to nebude mít vliv na selhání zóny.Outbound connection SNAT port allocations survive zone failures and your scenario will continue to provide outbound SNAT connectivity if not impacted by zone failure. To může vyžadovat přenos nebo pro připojení, která se mají znovu zřídit pro scénáře redundantní v zóně, pokud byl tok obsluhován ovlivněnou zónou.This may require transmissions or for connections to be re-established for zone-redundant scenarios if a flow was served by an impacted zone. Toky v jiných zónách, než jsou ovlivněné zóny, to neovlivní.Flows in zones other than the impacted zones are not affected.

Algoritmus předalokace portu SNAT je stejný jako u zóny dostupnosti nebo bez ní.The SNAT port preallocation algorithm is the same with or without availability zones.

Sondy stavuHealth probes

Vaše existující definice sondy stavu zůstávají, protože jsou bez zón dostupnosti.Your existing health probe definitions remain as they are without availability zones. Rozšířili jsme ale model stavu na úrovni infrastruktury.However, we've expanded the health model at an infrastructure level.

Pokud používáte zóny, které jsou redundantní, Load Balancer rozbalí svůj interní model stavu, aby nezávisle provedl test dostupnosti virtuálního počítače z každé zóny dostupnosti, a vypíná cesty mezi zónami, které se mohly nezdařily bez zásahu zákazníka.When using zone-redundant frontends, Load Balancer expands its internal health model to independently probe the reachability of a virtual machine from each availability zone and shut down paths across zones that may have failed without customer intervention. Pokud daná cesta není k dispozici z Load Balancer infrastruktury jedné zóny do virtuálního počítače v jiné zóně, Load Balancer může tuto chybu detekovat a vyhnout se.If a given path is not available from the Load Balancer infrastructure of one zone to a virtual machine in another zone, Load Balancer can detect and avoid this failure. Jiné zóny, které se můžou připojit k tomuto virtuálnímu počítači, můžou dál obsluhovat virtuální počítač ze svých front-endu.Other zones who can reach this VM can continue to serve the VM from their respective frontends. V důsledku toho se může stát, že během událostí selhání budou mít každá zóna mírně odlišnou distribuci nových toků a současně chrání celkový stav komplexní služby.As a result, it is possible that during failure events, each zone may have slightly different distributions of new flows while protecting the overall health of your end-to-end service.

Faktory návrhuDesign considerations

Load Balancer je účelově flexibilní v kontextu zón dostupnosti.Load Balancer is purposely flexible in the context of availability zones. Můžete si vybrat, že se mají zarovnat do zón, nebo můžete pro každé pravidlo zvolit, že se má pro každé pravidlo redundantní zóna.You can choose to align to zones or you can choose to be zone-redundant for each rule. Vyšší dostupnost může zacházet z ceny zvýšené složitosti a je třeba navrhnout dostupnost pro zajištění optimálního výkonu.Increased availability can come at the price of increased complexity and you must design for availability for optimal performance. Pojďme se podívat na důležité informace o návrhu.Let's take a look at some important design considerations.

Automatická redundance zónyAutomatic zone-redundancy

Load Balancer usnadňuje jednu IP adresu jako front-redundantní front-end.Load Balancer makes it simple to have a single IP as a zone-redundant frontend. Redundantní IP adresa v zóně může bezpečně obsluhovat prostředky oblastí v libovolné zóně a může zabývat jedné nebo více selhání zóny, pokud jedna zóna zůstane v dobrém stavu v oblasti.A zone-redundant IP address can safely serve a zonal resource in any zone and can survive one or more zone failures as long as one zone remains healthy within the region. Naopak front-end je omezení služby na jednu zónu a podílí se na ní osud v příslušné zóně.Conversely, a zonal frontend is a reduction of the service to a single zone and shares fate with the respective zone.

Zóna – redundance neznamená hitlessou datacestu nebo rovinu ovládacího prvku; rovina dat je Express.Zone-redundancy does not imply hitless datapath or control plane; it is expressly data plane. Neredundantní toky v zóně můžou používat libovolné zóny a toky zákazníka použijí všechny v pořádku zóny v oblasti.Zone-redundant flows can use any zones and a customer's flows will use all healthy zones in a region. V případě selhání zóny nebudou ovlivněny provozní toky, které používají zóny v pořádku v daném časovém okamžiku.In the event of zone failure, traffic flows using healthy zones at that point in time are not impacted. Může to mít vliv na přenosové toky pomocí zóny v době selhání zóny, ale aplikace se můžou zotavit.Traffic flows using a zone at the time of zone failure may be impacted but applications can recover. Tyto toky můžou pokračovat ve zbývajících zónách v oblasti po opětovném přenosu nebo opětovném vytvoření, jakmile se Azure Sblíženo se selháním zóny.These flows can continue in the remaining healthy zones within the region upon retransmission or reestablishment, once Azure has converged around the zone failure.

Hranice mezi zónamiCross zone boundaries

Je důležité si uvědomit, že při každém přechodu mezi koncovými službami procházejí všechny zóny, takže můžete sdílet rozpad bez jedné zóny, ale potenciálně více zón.It is important to understand that any time an end-to-end service crosses zones, you share fate with not one zone but potentially multiple zones. V důsledku toho vaše koncová služba pravděpodobně nezískala žádnou dostupnost v rámci nasazení mimo oblast.As a result, your end-to-end service may not have gained any availability over non-zonal deployments.

Vyhněte se zavlečení nezamýšlených závislostí mezi zónami, které při používání zón dostupnosti budou nezruší zisky dostupnosti.Avoid introducing unintended cross-zone dependencies, which will nullify availability gains when using availability zones. Pokud se vaše aplikace skládá z několika součástí a chcete být odolná vůči selhání zóny, musíte se ujistit, že v případě selhání zóny budete mít dostatečné kritické součásti.When your application consists of multiple components and you wish to be resilient to zone failure, you must take care to ensure the survival of sufficient critical components in the event of a zone failing. Například jediná kritická součást vaší aplikace může mít vliv na celou aplikaci, pokud existuje pouze v jiné zóně než zóny, na kterých se nachází.For example, a single critical component for your application can impact your entire application if it only exists in a zone other than the surviving zone(s). Kromě toho zvažte také obnovení zóny a způsob sblížení aplikace.In addition, also consider the zone restoration and how your application will converge. Potřebujete pochopit, jakým způsobem vaše aplikace vyplývají z důvodu selhání částí.You need to understand how your application reasons with respect to failures of portions of it. Pojďme se podívat na některé klíčové body a použít je jako inspiraci pro otázky, jak si myslíte podle svého konkrétního scénáře.Let's review some key points and use them as inspiration for questions as you think through your specific scenario.

  • Pokud má vaše aplikace dvě komponenty, jako je IP adresa a virtuální počítač se spravovaným diskem a jsou zaručené v zóně 1 a 2, v případě, že zóna 1 selže, nebude vaše koncová služba zachována, když zóna 1 selže.If your application has two components like an IP address and a virtual machine with managed disk, and they're guaranteed in zone 1 and zone 2, when zone 1 fails your end-to-end service will not survive when zone 1 fails. Nevybírejte mezi zónami scénářů oblastí, pokud plně nerozumíte, že vytváříte potenciálně nebezpečný režim selhání.Don't cross zones with zonal scenarios unless you fully understand that you are creating a potentially hazardous failure mode. Tento scénář je povolený pro zajištění flexibility.This scenario is allowed to provide flexibility.

  • Pokud má vaše aplikace dvě komponenty, jako je IP adresa a virtuální počítač se spravovaným diskem, a zaručuje se, že vaše koncová služba bude zachována při selhání zóny 2, zóny 3 nebo obou, pokud se nezdařila zóna 1.If your application has two components like an IP address and a virtual machine with managed disk, and they are guaranteed to be zone-redundant and zone 1 respectively, your end-to-end service will survive zone failure of zone 2, zone 3, or both unless zone 1 has failed. Nemůžete ale přijít o případnou schopnost vaší služby, pokud je všechno, co se vám právě vystavuje, dostupnost front-endu.However, you lose some ability to reason about the health of your service if all you are observing is the reachability of the frontend. Zvažte vývoj rozsáhlejšího modelu stavu a kapacity.Consider developing a more extensive health and capacity model. K rozšíření přehledu a možností správy můžete využít koncepty a oblasti v zóně.You might use zone-redundant and zonal concepts together to expand insight and manageability.

  • Pokud má vaše aplikace dvě komponenty, jako je například zóna redundantní Load Balancer front-endu a škálování virtuálního počítače mezi zónami ve třech zónách, budou k dispozici prostředky v zónách neovlivněné selháním, ale může dojít ke snížení výkonu vaší koncové kapacity služby. během selhání zóny.If your application has two components like a zone-redundant Load Balancer frontend and a cross-zone virtual machine scale set in three zones, your resources in zones not impacted by failure will be available but your end-to-end service capacity may be degraded during zone failure. Z hlediska infrastruktury může vaše nasazení zamezit selhání jedné nebo více zón a tato akce vyvolá následující otázky:From an infrastructure perspective, your deployment can survive one or more zone failures, and this raises the following questions:

    • Porozumíte tomu, jak vaše aplikace vede k takovým selháním a snížení kapacity?Do you understand how your application reasons about such failures and degraded capacity?
    • Potřebujete v rámci služby zabezpečení a v případě potřeby vynutit převzetí služeb při selhání dvojici oblastí?Do you need to have safeguards in your service to force a failover to a region pair if necessary?
    • Jak budete monitorovat, zjišťovat a zmírnit takový scénář?How will you monitor, detect, and mitigate such a scenario? Je možné používat diagnostiku Standard Load Balancer k rozšíření monitorování komplexního výkonu služby.You may be able to use Standard Load Balancer diagnostics to augment monitoring of your end-to-end service performance. Zvažte, co je k dispozici a co může pro kompletní obrázek vyžadovat rozšíření.Consider what is available and what may need augmentation for a complete picture.
  • Zóny můžou chyby snadněji pochopit a zahrnout.Zones can make failures more easily understood and contained. Selhání zóny se ale neliší od jiných selhání, když přichází k koncepcím, jako jsou časové limity, opakování a omezení rychlosti algoritmy.However, zone failure is no different than other failures when it comes to concepts like timeouts, retries, and backoff algorithms. I když Azure Load Balancer poskytuje cesty redundantní v zóně a snaží se rychle obnovit na úrovni paketů v reálném čase, může dojít k opakovanému přenosu nebo opětovnému navázání. je důležité pochopit, jak se vaše aplikace kopiemi s úspěšně.Even though Azure Load Balancer provides zone-redundant paths and tries to recover quickly, at a packet level in real time, retransmissions or reestablishments may occur during the onset of a failure and it's important to understand how your application copes with failures. Vaše schéma vyrovnávání zatížení bude zachováno, ale je třeba naplánovat následující:Your load-balancing scheme will survive, but you need to plan for the following:

    • Pokud dojde k chybě zóny, bude vaše koncová služba rozumět této službě a pokud dojde ke ztrátě stavu, jak budete obnovovat?When a zone fails, does your end-to-end service understand this and if the state is lost, how will you recover?
    • Když se zóna vrátí, aplikace porozumí, jak bezpečně konvergovat?When a zone returns, does your application understand how to converge safely?

Projděte si vzory návrhu cloudu Azure , abyste vylepšili odolnost vaší aplikace vůči scénářům selhání.Review Azure cloud design patterns to improve the resiliency of your application to failure scenarios.

Redundantní zóna mimo oblastZone-redundant versus zonal

Redundantní zóna může poskytovat jednoduchost s možností nezávislá zóny a zároveň stejnou možností jako odolnost s jednou IP adresou pro službu.Zone-redundant can provide a simplicity with a zone-agnostic option and at the same time resilient option with a single IP address for the service. Může to snížit složitost.It can reduce complexity in turn. Redundantní zóna také nabízí mobilitu mezi zónami a může být bezpečně používána na prostředky v libovolné zóně.Zone-redundant also has mobility across zones, and can be safely used on resources in any zone. V oblastech, které nemají zóny dostupnosti, je také budoucí kontrola, což může omezit změny, které jsou požadovány, jakmile oblast získá zóny dostupnosti.Also, it's future proof in regions without availability zones, which can limit changes required once a region does gain availability zones. Syntaxe konfigurace pro redundantní IP adresu nebo front-endu zóny je úspěšná v jakékoli oblasti, včetně těch, které nemají zóny dostupnosti: zóna není zadaná v rámci zón: vlastnost prostředku.The configuration syntax for a zone-redundant IP address or frontend succeeds in any region including those without availability zones: a zone is not specified within the zones: property of the resource.

Oblast může poskytnout explicitní záruku pro zónu, explicitně sdílení osudu se stavem zóny.Zonal can provide an explicit guarantee to a zone, explicitly sharing fate with the health of the zone. Vytvoření pravidla Load Balancer s IP adresou v oblasti front-endu nebo interní Load Balancer front-endu může být žádoucí, zejména v případě, že připojený prostředek je virtuální počítač ve stejné zóně.Creating a Load Balancer rule with a zonal IP address frontend or zonal internal Load Balancer frontend can be a desirable especially if your attached resource is a zonal virtual machine in the same zone. Nebo možná vaše aplikace vyžaduje explicitní znalosti o tom, ve které zóně se prostředek nachází předem, a Vy si přejete mít důvod k jejich dostupnosti v samostatných zónách explicitně.Or perhaps your application requires explicit knowledge about which zone a resource is located in ahead of time and you wish to reason about availability in separate zones explicitly. Můžete zvolit, aby se pro koncovou službu distribuovanou v různých zónách vystavilo několik front-endu (to znamená, že zóna má na front-endové služby pro víc virtuálních počítačů Scale Sets).You can choose to expose multiple zonal frontends for an end-to-end service distributed across zones (that is, per zone zonal frontends for multiple zonal virtual machine scale sets). A pokud vaše oblast front-endu jsou veřejné IP adresy, můžete použít tyto více front-endu pro vystavení vaší služby s Traffic Manager.And if your zonal frontends are public IP addresses, you can use these multiple zonal frontends for exposing your service with Traffic Manager. Nebo můžete použít více front-endu k získání informací o stavu jednotlivých zón a přehledy o výkonu prostřednictvím řešení monitorování třetích stran a zpřístupnit celkovou službu pomocí předávacího typu zóny redundantní.Or you can use multiple zonal frontends to gain per zone health and performance insights through third party monitoring solutions and expose the overall service with a zone-redundant frontend. Měli byste používat jenom ty prostředky s oblastí front-endu zarovnané do stejné zóny a vyhnout se potenciálně škodlivým scénářům pro různé zóny pro oblasti prostředků.You should only serve zonal resources with zonal frontends aligned to the same zone and avoid potentially harmful cross-zone scenarios for zonal resources. Prostředky oblastí existují pouze v oblastech, kde existují zóny dostupnosti.Zonal resources only exist in regions where availability zones exist.

Neexistují žádné obecné pokyny, které je lepší volbou než druhá bez znalosti architektury služby.There's no general guidance that one is a better choice than the other without knowing the service architecture. Projděte si vzory návrhu cloudu Azure , abyste vylepšili odolnost vaší aplikace vůči scénářům selhání.Review Azure cloud design patterns to improve the resiliency of your application to failure scenarios.

OmezeníLimitations

  • Zatímco rovina dat je zcela redundantní (není-li zaručena oblastce), provozní operace roviny nejsou plně v zóně redundantní.While data plane is fully zone-redundant (unless zonal guarantee was specified), control plane operations aren't fully zone-redundant.

Další postupNext steps