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

Standardní skladová jednotka Azure Load Balancer podporuje zóny dostupnosti scénáře.Azure Load Balancer's Standard SKU supports Availability Zones scenarios. Několik nových konceptů jsou k dispozici Load balanceru úrovně Standard, které umožňují vám umožní optimalizovat tak, že zarovnání prostředky se zónami a jejich distribuci napříč zónami dostupnosti ve vašem scénáři začátku do konce.Several new concepts are available with Standard Load Balancer, which allow you to optimize availability in your end-to-end scenario by aligning resources with zones and distributing them across zones. Kontrola zóny dostupnosti pokyny, co jsou zóny dostupnosti, ve kterých oblastech se aktuálně podporují zóny dostupnosti a druhý 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 Load balanceru úrovně Standard jsou sady funkce obsáhlém a flexibilní, můžete vytvořit mnoho různých scénářů.Availability Zones in combination with Standard Load Balancer are an expansive and flexible feature set that can create many different scenarios. Přečtěte si tento dokument, abyste umět nakonfigurovat koncepty a základní scénář pokyny k návrhu.Review this document to understand these concepts and fundamental scenario design guidance.

Důležité

Kontrola zóny dostupnosti související témata, včetně žádné informace o konkrétní oblasti.Review Availability Zones for related topics, including any region specific information.

Koncepce zón dostupnosti u nástroje pro vyrovnávání zatíženíAvailability Zones concepts applied to Load Balancer

Není žádný přímý vztah mezi prostředky nástroje pro vyrovnávání zatížení a infrastruktury skutečný; Vytvoření nástroje pro vyrovnávání zatížení nevytváří instanci.There's no direct relationship between Load Balancer resources and actual infrastructure; creating a Load Balancer doesn't create an instance. Prostředků nástroje pro vyrovnávání zatížení jsou objekty, ve kterém můžete vyjádřit, jak Azure by měl program jeho předem připravených víceklientské infrastruktury, scénář, 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 důležité v rámci zóny dostupnosti, protože jeden prostředek nástroje pro vyrovnávání zatížení můžete řídit programování infrastruktury v několika zónami dostupnosti, zatímco zónově redundantní služby se zobrazí jako jeden prostředek z hlediska zákazníků.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.

Funkce nástroje pro vyrovnávání zatížení prostředků jsou vyjádřeny jako front-end, pravidla, sondu stavu a definice fondu back-endu.A Load Balancer resource's functions are expressed as a frontend, a rule, a health probe, and a backend pool definition.

V rámci zóny dostupnosti jsou popsané chování a vlastností prostředku nástroje pro vyrovnávání zatížení jako zónové a zónově redundantní.In the context of Availability Zones, the behavior and properties of a Load Balancer resource are described as zone-redundant or zonal. Zónově redundantní a zónové popisují zonality vlastnost.Zone-redundant and zonal describe the zonality of a property. V rámci nástroje pro vyrovnávání zatížení, zónově redundantní vždy znamená, že několika zónami a zónové prostředky služby k izolování jedné zóně.In the context of Load Balancer, zone-redundant always means multiple zones and zonal means isolating the service to a single zone.

Veřejné a vnitřní nástroj pro vyrovnávání zatížení podporují zónové a zónově redundantní scénáře a podle potřeby, jak může směrovat provoz mezi zónami (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).

Prostředek nástroje pro vyrovnávání zatížení, samotného je místní a nikdy oblastmi.A Load Balancer resource itself is regional and never zonal. A virtuální sítě a podsítě jsou vždy místní a nikdy oblastmi.And a VNet and subnet are always regional and never zonal.

Front-enduFrontend

Front-endu nástroje pro vyrovnávání zatížení je konfigurace IP front-endu na prostředek veřejné IP adresy nebo privátní IP adresu v rámci podsítě prostředku virtuální sítě.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. Vymezuje koncový bod s vyrovnáváním zatížení, kde je vystaven vaší služby.It forms the load balanced endpoint where your service is exposed.

Prostředek nástroje pro vyrovnávání zatížení může obsahovat současně zónové a zónově redundantních front-endů.A Load Balancer resource can contain both zonal and zone-redundant frontends simultaneously.

Pokud prostředek veřejné IP adresy má byla zaručeno, že do zóny, zonality (nebo neexistenci) není měnitelný.When a public IP resource has been guaranteed to a zone, the zonality (or lack thereof) isn't mutable. Pokud chcete změnit nebo vynechejte zonality veřejnou front-endovou IP, budete muset znovu vytvořit veřejnou IP adresu v příslušné oblasti.If you wish to change or omit the zonality of a public IP frontend, you need to recreate the public IP in the appropriate zone.

Odebráním a opětovné vytvoření front-endu, změna nebo vynechání zonality můžete změnit zonality front-end interního nástroje Load Balancer.You can change the zonality of a frontend of an internal Load Balancer by removing and recreating the frontend, changing or omitting the zonality.

Pokud používáte několik front-endů, zkontrolujte několik front-endů pro nástroj pro vyrovnávání zatížení důležité informace.When using multiple frontends, review multiple frontends for Load Balancer for important considerations.

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

Důležité

Kontrola zóny dostupnosti související témata, včetně žádné informace o konkrétní oblasti.Review Availability Zones for related topics, including any region specific information.

V oblasti se zónami dostupnosti se zónově redundantní ve výchozím nastavení front-end Load balanceru úrovně Standard.In a region with Availability Zones, a Standard Load Balancer frontend is zone-redundant by default. IP adresa front-endu jeden přežijí selhání zóny a může být použité k dosažení všech členů fondu back-endu bez ohledu na to, zóna.A single frontend IP address can survive zone failure and can be used to reach all backend pool members irrespective of the zone. Cesta k datům hitless neznamená to však reestablishment ani opakování proběhne úspěšně.This doesn't mean hitless data path, but any retries or reestablishment will succeed. Schémata redundance DNS se nevyžadují.DNS redundancy schemes aren't required. Front-endu jednu IP adresu obsluhují současně více nezávislých infrastrukturu nasazení v několika zónami dostupnosti.The frontend's single IP address is served simultaneously by multiple independent infrastructure deployments in multiple Availability Zones. Zónově redundantní znamená, že všechny příchozí nebo odchozí toky obsluhuje více zón dostupnosti v oblasti současně používat jednu IP adresu.Zone-redundant means that all inbound or outbound flows are served by multiple Availability Zones in a region simultaneously using a single IP address.

Jeden nebo více zónách dostupnosti, i když selže na cestu k datům odolává tak dlouho, 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. Zónově redundantní konfigurace je výchozí a nevyžaduje žádné další akce.Zone-redundant configuration is the default and requires no additional actions.

Pomocí následujícího skriptu vytvořte zónově redundantní veřejnou IP adresu pro vaše interní Load balanceru úrovně Standard.Use the following script to create a zone-redundant Public IP address for your internal Standard Load Balancer. Pokud používáte existující šablony Resource Manageru ve vaší konfiguraci, přidejte sku části tyto šablony.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"
            },

Pomocí následujícího skriptu vytvořte zónově redundantních front-endovou IP adresu pro vaše interní Load balanceru úrovně Standard.Use the following script to create a zone-redundant frontend IP address for your internal Standard Load Balancer. Pokud používáte existující šablony Resource Manageru ve vaší konfiguraci, přidejte sku části tyto šablony.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"
                        }
                    },
                ],

Izolace volitelné zónyOptional zone isolation

Můžete zvolit, aby front-endu, zaručeno, že k jedné oblasti, což se označuje jako zónové front-endu.You can choose to have a frontend guaranteed to a single zone, which is known as a zonal frontend. To znamená, že se že všechny příchozí nebo odchozí tok je obsluhuje jednu zónu v oblasti.This means any inbound or outbound flow is served by a single zone in a region. Vaše front-endu sdílí pracuje s stavu zóny.Your frontend shares fate with the health of the zone. Cesta k datům není ovlivněn selhání v oblastech než ve kterém byla zaručená.The data path is unaffected by failures in zones other than where it was guaranteed. Oblastmi front-endů můžete použít ke zveřejnění IP adresa na zónu dostupnosti.You can use zonal frontends to expose an IP address per Availability Zone. Navíc můžete využívat oblastmi front-endů přímo nebo, když se skládá z veřejné IP adresy front-endu integrovat se službou Vyrovnávání zatížení produktu jako DNS Traffic Manageru a používat jeden název DNS, který se přeloží klienta více oblastmi IP adres.Also, you can consume zonal frontends directly or, when the frontend consists of public IP addresses, integrate them with a DNS load-balancing product like Traffic Manager and use a single DNS name, which a client will resolve to multiple zonal IP addresses. To můžete použít ke zveřejnění na zóny s vyrovnáváním zatížení koncových bodech, které jednotlivě sledovat každou zónu.You can also use this to expose per zone load-balanced endpoints to individually monitor each zone. Pokud chcete kombinovat tyto koncepty (zónově redundantní a zónové pro stejný back-end), přečtěte si několik front-endů 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.

Pro veřejný nástroj pro vyrovnávání zatížení front-end, přidáte zóny parametr na veřejnou IP adresu odkazuje front-endová konfigurace protokolu IP.For a public Load Balancer frontend, you add a zones parameter to the public IP referenced by the frontend IP configuration.

Interní nástroj pro vyrovnávání zatížení front-endu, přidejte zóny parametrů pro vnitřní konfigurace protokolu IP front-endu nástroje pro vyrovnávání zatížení.For an internal Load Balancer frontend, add a zones parameter to the internal Load Balancer frontend IP configuration. Oblastmi front-endu způsobí, že nástroj pro vyrovnávání zatížení pro zajištění IP adresy v podsíti pro konkrétní zónu.The zonal frontend causes the Load Balancer to guarantee an IP address in a subnet to a specific zone.

Pomocí následujícího skriptu vytvořte oblastmi standardní veřejnou IP adresu v zóně 1 dostupnosti.Use the following script to create a zonal Standard Public IP address in Availability Zone 1. Pokud používáte existující šablony Resource Manageru ve vaší konfiguraci, přidejte sku části tyto šablony.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"
            },

Pomocí následujícího skriptu vytvořte interní nástroj pro vyrovnávání zatížení front-endem v zóně 1 dostupnosti.Use the following script to create an internal Standard Load Balancer front end in Availability Zone 1.

Pokud používáte existující šablony Resource Manageru ve vaší konfiguraci, přidejte sku části tyto šablony.If you're using existing Resource Manager templates in your configuration, add the sku section to these templates. Navíc definovat zóny vlastnosti 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"
                        }
                    },
                ],

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

Vyrovnávání zatížení mezi zónami je schopnost služby Load Balancer oslovit koncový bod back-end v každé zóně a to nezávisle na front-endu a jeho 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.

Pokud chcete zarovnat a zaručit nasazení v rámci jedné oblasti, zarovnání oblastmi front-endu a zónové back-endovým prostředkům do stejné zóny.If you wish to align and guarantee your deployment within a single zone, align zonal frontend and zonal backend resources to the same zone. Nevyžaduje se žádná další akce.No further action is required.

Back-enduBackend

Nástroj pro vyrovnávání zatížení funguje s virtuálními počítači.Load Balancer works with Virtual Machines. Všech virtuálních počítačů v jedné virtuální sítě můžou být součástí fondu back-endu bez ohledu na to, zda byla zaručeno do zóny nebo zóně, ve které byla zaručeno, že.Any VM in a single VNet 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 zarovnat a zaručit front-endových a back-endu pomocí jedné oblasti, pouze umístíte virtuální počítače ve stejné zóně do příslušných back-endový fond.If you wish to align and guarantee your frontend and backend with a single zone, only place VMs within the same zone into the respective backend pool.

Pokud chcete adresy virtuálních počítačů napříč několika zónami, jednoduše umístěte virtuální počítače z několika zónami do stejného back-endový fond.If you wish to address VMs across multiple zones, simply place VMs from multiple zones into the same backend pool. Pokud použijete virtuálního počítače škálovací sady, můžete umístit jeden nebo více škálovací sady virtuálních počítačů do stejného back-endový fond.When using virtual machine scale sets, you can place one or more virtual machine scale sets into the same backend pool. A každý z těchto škálovací sady virtuálních počítačů může být v jedné nebo několika zónami.And each of these virtual machine scale sets can be in a single or multiple zones.

Odchozí připojeníOutbound connections

Odchozí připojení obsluhují všechny zóny a jsou automaticky zónově redundantní v oblasti se zónami dostupnosti, pokud virtuální počítač přidružený veřejný Load Balancer a zónově redundantních front-endu.Outbound connections are served by all zones and are automatically zone-redundant in a region with Availability Zones when a virtual machine is associated with a public Load Balancer and a zone-redundant frontend. Odchozí připojení SNAT port přidělení selhání zóny.Outbound connection SNAT port allocations survive zone failures.

Naopak pokud virtuální počítač je spojen s veřejný Load Balancer a zónové front-endu, odchozí připojení je zaručeno poskytovat podle jedné oblasti.In turn, if the VM is associated with a public Load Balancer and a zonal frontend, outbound connections are guaranteed to be served by a single zone. Odchozí připojení sdílet pracuje s stav příslušných zóny.Outbound connections share fate with the respective zone's health.

Předběžné přidělení SNAT portu a algoritmus je stejná s nebo bez zón.The SNAT port preallocation and algorithm is the same with or without zones.

Sondy stavuHealth probes

Vaše existující definice sondy stavu zůstane tak, jak jsou, bez zón dostupnosti.Your existing health probe definitions remain as they are without Availability Zones. Ale jsme rozšířili modelu stavu na úrovni infrastruktury.But we've expanded the health model at an infrastructure level.

Při použití zónově redundantních front-endů, nástroje pro vyrovnávání zatížení se rozšíří jeho vnitřního stavu modelu nezávisle na sobě testu dostupnosti virtuálního počítače z každá zóna dostupnosti a vypnout cest napříč zónami, které mohlo dojít k selhání 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 VM from each Availability Zone and shut down paths across zones that may have failed without customer intervention. Pokud zadaná cesta není k dispozici z infrastruktury nástroje pro vyrovnávání zatížení jednu zónu na virtuální počítač v jiné zóně, nástroje pro vyrovnávání zatížení můžete zjišťovat a vyhnout se této chyby.If a given path is not available from the Load Balancer infrastructure of one zone to a VM in another zone, Load Balancer can detect and avoid this failure. Další zóny, kteří můžou kontaktovat tento virtuální počítač můžete nadále sloužit virtuálního počítače z jejich odpovídajících front-endů.Other zones who can reach this VM can continue to serve the VM from their respective frontends. V důsledku toho je možné, že během události selhání každé zóně může mít distribuce mírně odlišný tok při ochraně celkový stav služby začátku do konce.As a result, it is possible that during failure events, each zone may have slightly different flow distributions while protecting the overall health of your end-to-end service.

Aspekty návrhuDesign considerations

Nástroj pro vyrovnávání zatížení je záměrně flexibilní v rámci zóny dostupnosti.Load Balancer is purposely flexible in the context of Availability Zones. Můžete také zarovnat zóny nebo můžete být zónově redundantní.You can choose to align to zones or you can choose to be zone-redundant. Zajištění vyšší dostupnosti můžete vrátit za cenu zvýšení složitosti a je třeba navrhnout dostupnosti 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 některé důležité aspekty návrhu.Let's take a look at some important design considerations.

Automatické zálohování zónyAutomatic zone-redundancy

Nástroj pro vyrovnávání zatížení usnadňuje mít jednu IP adresu jako zónově redundantních front-endu.Load Balancer makes it simple to have a single IP as a zone-redundant frontend. Zónově redundantní IP adresa může bezpečně sloužit zónovým prostředkem v každé zóně a tak dlouho, dokud jednu zónu zůstane v dobrém stavu v rámci oblasti přežijí nejméně jednomu selhání zóny.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 oblastmi front-endu je snížení služby na jednu zónu a sdílené složky rozpadu příslušných zónu.Conversely, a zonal frontend is a reduction of the service to a single zone and shares fate with the respective zone.

Redundanci zón neznamená hitless datapath nebo rovina řízení; je výslovně rovina dat.Zone-redundancy does not imply hitless datapath or control plane; it is expressly data plane. Zónově redundantní toků můžete použít všechny zóny a toků na základě budou používat všechny zóny v pořádku 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 přenosové toky pomocí v dobrém stavu zóny v daném okamžiku v čase vliv.In the event of zone failure, traffic flows using healthy zones at that point in time are not impacted. Přenosové toky pomocí zóny v době selhání zóna může mít vliv, ale můžete obnovit aplikací.Traffic flows using a zone at the time of zone failure may be impacted but applications can recover. Tyto toky můžete pokračovat ve zbývajících v dobrém stavu zóny v rámci oblasti opakovaný přenos zpráv nebo reestablishment, po Azure se sloučila kolem selhání 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.

Překračují hranice zónyCross zone boundaries

Je důležité pochopit, že kdykoli služby začátku do konce překročí zóny, sdílet pracuje s není jednu zónu, ale potenciálně několika zónami.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 začátku do konce služby nemusí získali jakékoli dostupnost přes-zónové nasazení.As a result, your end-to-end service may not have gained any availability over non-zonal deployments.

Vyhýbejte se nežádoucích závislosti mezi zónami, které se nezruší se tím zvýšení dostupnosti při použití zón dostupnosti.Avoid introducing unintended cross-zone dependencies, which will nullify availability gains when using Availability Zones. Pokud vaše aplikace se skládá z několika součástí a chcete být odolné vůči selhání zóny, musí postará k zajištění přežití dostatečná kritických komponent v případě selhání zóny.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 jeden zásadní součástí pro vaši aplikaci může ovlivnit celé aplikace existuje pouze v zóně než zbývající zóna nebo zóny.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 se také zvažte obnovení zóny a jak se vaše aplikace sloučit.In addition, also consider the zone restoration and how your application will converge. Pojďme zkontrolovat některé klíčové body a použijte je jako inspirace pro dotazy pečlivě promyslete váš konkrétní scénář.Let's review some key points and use them as inspiration for questions as you think through your specific scenario.

  • Pokud aplikace obsahuje dvě komponenty, jako jsou IP adresy a virtuálních počítačů při použití spravovaného disku a jste zaručeno v zóně 1 a v zóně 2, při selhání vaší služby začátku do konce zóny 1 nebude překonat když zóna 1 se nezdaří.If your application has two components like an IP address and a VM 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. Není napříč zóny, není-li plně chápete, že vytváříte režim potenciálně nebezpečné selhání.Don't cross zones unless you fully understand that you are creating a potentially hazardous failure mode.

  • Pokud vaše aplikace má dvě součásti, jako jsou IP adresy a virtuální počítač s spravovaný disk a je zaručena zónově redundantní a zóna 1, respektive, vaše služba začátku do konce přežije zkázu zóny selhání v zóně 2 pro, zóna 3, nebo obojí Pokud zóna 1 se nezdařilo.If your application has two components like an IP address and a VM 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. Však ztratíte nějakou možnost argumentovat o stav vaší služby. Pokud vše, co se vyčistily dostupnosti 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 možnost zavedení rozsáhlejší modelu stavu a kapacity.Consider developing a more extensive health and capacity model. Můžete společně použít zónové a zónově redundantní koncepty rozbalte insight a zlepšit možnosti správy.You might use zone-redundant and zonal concepts together to expand insight and manageability.

  • Pokud aplikace obsahuje dvě komponenty, jako jsou zónově redundantních front-endu nástroje pro vyrovnávání zatížení a škálovací sady virtuálních počítačů napříč zónami ve třech zónách, vaše prostředky v zónách není vliv selhání bude k dispozici, ale může mít snížený výkon vaší kapacity služby začátku do konce 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 nasazení přežijí nejméně jednoho zóny, a to vyvolá na následující otázky:From an infrastructure perspective, your deployment can survive one or more zone failures, and this raises the following questions:

    • Chápete, jak vaše aplikace důvodů, proč o takové selhání a snížení kapacity?Do you understand how your application reasons about such failures and degraded capacity?
    • Je třeba mít bezpečnostní opatření ve své službě do páru oblastí v případě potřeby vynutit převzetí služeb při selhání?Do you need to have safeguards in your service to force a failover to a region pair if necessary?
    • Jak se můžete sledovat, jejich detekci a zmírnění takový scénář?How will you monitor, detect, and mitigate such a scenario? Je možné, že se můžete pomocí diagnostiky Load balanceru úrovně Standard k posílení monitorování výkonu vaší služby začátku do konce.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 rozšíření co možná bude nutné pro dokončení obrázek.Consider what is available and what may need augmentation for a complete picture.
  • Zónám lze chyby snadněji porozuměl jsem jim a obsažené.Zones can make failures more easily understood and contained. Selhání zóny se ale nijak neliší od jiné chyby při rozhodování o koncepty, jako jsou časové limity, opakovaných pokusů 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 zónově redundantní cesty a pokusí se rychle, obnovení na úrovni paketů v reálném čase, opakovaných nebo reestablishments může dojít během mozkového onemocnění v chybě a je důležité pochopit, jak vaše aplikace copes s selhá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. Přežije zkázu schéma služby Vyrovnávání zatížení, ale je potřeba naplánovat následující:Your load-balancing scheme will survive, but you need to plan for the following:

    • Pokud zónu nezdaří, vaše služba začátku do konce chápe to a pokud dojde ke ztrátě stavu, jak se vám obnoví?When a zone fails, does your end-to-end service understand this and if the state is lost, how will you recover?
    • Po návratu zónu, aplikace pochopit, jak bezpečně sloučit?When a zone returns, does your application understand how to converge safely?

Zónově redundantní a oblastmiZone-redundant versus zonal

Důležité

Kontrola zóny dostupnosti související témata, včetně žádné informace o konkrétní oblasti.Review Availability Zones for related topics, including any region specific information.

Zónově redundantní můžete zadat zónu nezávislá a na stejné možnosti čas odolné jednu IP adresu pro službu.Zone-redundant can provide a zone-agnostic and at the same time resilient option with a single IP address for the service. Pak ji lze omezit složitost.It can reduce complexity in turn. Zónově redundantní také má mobility napříč zónami a lze jej bezpečně používat na prostředky v každé zóně.Zone-redundant also has mobility across zones, and can be safely used on resources in any zone. Je také budoucnost v oblastech, které nemají zóny dostupnosti, které můžete omezit změny po oblast získat 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 zónově redundantní IP adresu nebo front-endu úspěšná v libovolné oblasti, včetně těch, které nemají zóny dostupnosti.The configuration syntax for a zone-redundant IP address or frontend succeeds in any region including those without Availability Zones.

Zónové může poskytnout explicitní záruka se zónou sdílení pracuje s stavu zóny.Zonal can provide an explicit guarantee to a zone, sharing fate with the health of the zone. Přidružení oblastmi IP adresu nebo oblastmi front-endu nástroje pro vyrovnávání zatížení může být žádoucí nebo přiměřené atribut zejména v Pokud je připojené prostředků virtuálního počítače s oblastmi ve stejné zóně.Associating a zonal IP address or zonal Load Balancer frontend can be a desirable or reasonable attribute especially if your attached resource is a zonal VM in the same zone. Nebo možná vaše aplikace vyžaduje explicitní znalosti o zóně, ve které je prostředek umístěn v a chcete explicitně odůvodnitelný v samostatných zón dostupnosti.Or perhaps your application requires explicit knowledge about which zone a resource is located in and you wish to reason about availability in separate zones explicitly. Můžete také zveřejnit několika oblastmi front-endů pro službu začátku do konce distribuované napříč zónami (tedy za zónu oblastmi front-endů pro více oblastmi virtuálního počítače škálovací sady).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). Pokud vaše oblastmi front-endů jsou veřejné IP adresy, můžete pomocí těchto více oblastmi front-endů pro vystavení služby s Traffic Manageru.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 několik front-endů zónové a získat za zónu přehledy stavu a výkonu prostřednictvím monitorování řešení třetích stran tak a zpřístupnit s zónově redundantních front-endové služby.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. Pouze by měla sloužit zónové prostředky s oblastmi front-endů zarovnán do stejné zóny a vyhnout potenciálně škodlivé napříč zónami scénáře pro zónové prostředky.You should only serve zonal resources with zonal frontends aligned to the same zone and avoid potentially harmful cross-zone scenarios for zonal resources. Zónové prostředky existují jenom v oblastech, kde existují zóny dostupnosti.Zonal resources only exist in regions where Availability Zones exist.

Neexistuje žádné obecné pokyny, že jeden je vhodnější než ten 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.

OmezeníLimitations

  • Zatímco dat roviny je plně zónově redundantní (Pokud byl zadán oblastmi se zárukou), operace roviny řízení nejsou plně zónově redundantní.While data plane is fully zone-redundant (unless zonal guarantee was specified), control plane operations aren't fully zone-redundant.

Další postupNext steps