Metodi di routing di FrontdoorFront Door routing methods

Il servizio Frontdoor di Azure supporta vari metodi di routing del traffico per determinare la modalità di instradamento del traffico HTTP/HTTPS ai vari endpoint di servizio.Azure Front Door Service supports various traffic-routing methods to determine how to route your HTTP/HTTPS traffic to the various service endpoints. Per ognuna delle richieste client che raggiunge Frontdoor, viene applicato il metodo di routing configurato per garantire che le richieste vengano inoltrate all'istanza di back-end migliore.With each of your client requests reaching Front Door, the configured routing method gets applied to ensure the requests are forwarded to the best backend instance.

Esistono quattro concetti principali in relazione al routing del traffico in Frontdoor:There are four main concepts to traffic routing available in Front Door:

  • Latenza: il routing basato sulla latenza assicura che le richieste vengano inviate al back-end con la latenza più bassa accettabile all'interno di un intervallo di sensibilità.Latency: The latency-based routing ensures that requests are sent to the lowest latency backends acceptable within a sensitivity range. Sostanzialmente, le richieste utente vengono inviate al set di back-end "più vicino" rispetto alla latenza della rete.Basically, your user requests are sent to the "closest" set of backends with respect to network latency.
  • Priorità: è possibile assegnare priorità ai diversi back-end quando si vuole usare un back-end di servizio primario per tutto il traffico e prevedere backup nel caso in cui il back-end primario o i back-end di backup non siano disponibili.Priority: You can assign priorities to your different backends when you want to use a primary service backend for all traffic, and provide backups in case the primary or the backup backends are unavailable.
  • Ponderato: è possibile assegnare un peso ai diversi back-end quando si vuole distribuire il traffico in un set di back-end, in modo uniforme o in base ai coefficienti di peso.Weighted: You can assign weights to your different backends when you want to distribute traffic across a set of backends, either evenly or according to weight coefficients.
  • Affinità di sessione: è possibile configurare l'affinità di sessione per gli host o i domini front-end quando le richieste successive da un utente devono essere inviate allo stesso back-end, a condizione che la sessione utente sia ancora attiva e l'istanza di back-end sia ancora segnalata come integra in base ai probe di integrità.Session Affinity: You can configure session affinity for your frontend hosts or domains when you want that subsequent requests from a user are sent to the same backend as long as the user session is still active and the backend instance still reports healthy based on health probes.

Tutte le configurazioni di Frontdoor includono il monitoraggio dell'integrità back-end e il failover globale immediato automatizzato.All Front Door configurations include monitoring of backend health and automated instant global failover. Per altre informazioni, vedere Front Door Backend Monitoring (Monitoraggio del back-end Frontdoor).For more information, see Front Door Backend Monitoring. Frontdoor può essere configurato per operare in base a un singolo metodo di routing. A seconda delle esigenze dell'applicazione, è comunque possibile usare diversi o tutti questi metodi di routing in combinazione per creare una topologia di routing ottimale.Your Front Door can be configured to either work based off a single routing method and depending on your application needs you can use multiple or all of these routing methods in combination to build an optimal routing topology.

Routing del traffico in base alla latenza più bassaLowest latencies based traffic-routing

La velocità di risposta di molte applicazioni può essere migliorata distribuendo i back-end in due o più posizioni a livello globale e indirizzando il traffico alla posizione più vicina agli utenti finali.Deploying backends in two or more locations across the globe can improve the responsiveness of many applications by routing traffic to the location that is 'closest' to your end users. Il metodo predefinito di routing del traffico per la configurazione di Frontdoor inoltra le richieste dagli utenti finali al back-end più vicino dall'ambiente Frontdoor che ha ricevuto la richiesta.The default traffic-routing method for your Front Door configuration forwards requests from your end users to the closest backend from the Front Door environment that received the request. In combinazione con l'architettura Anycast del servizio Frontdoor di Azure, questo approccio assicura che ognuno degli utenti finali ottenga le massime prestazioni, in modo personalizzato in base alla posizione.Combined with the Anycast architecture of Azure Front Door Service, this approach ensures that each of your end users get maximum performance personalized based on their location.

Il back-end più vicino non è necessariamente il più vicino in termini di distanza geografica.The 'closest' backend is not necessarily closest as measured by geographic distance. Frontdoor determina invece il back-end più vicino misurando la latenza di rete.Instead, Front Door determines the closest backends by measuring network latency. Per altre informazioni, vedere Front Door's routing architecture (Architettura di routing di Frontdoor).Read more about Front Door's routing architecture.

Di seguito è illustrato il flusso complessivo delle decisioni:Below is the overall decision flow:

Back-end disponibiliAvailable backends PrioritàPriority Segnale di latenza (basato sui probe di integrità)Latency signal (based on health probe) WeightsWeights
In primo luogo, selezionare tutti i back-end che sono abilitati e restituiti come integri (200 OK) per il probe di integrità.Firstly, select all backends that are enabled and returned healthy (200 OK) for the health probe. Supponiamo che siano presenti sei back-end A, B, C, D, E e F, tra i quali C non è integro ed E è disabilitato.Say, there are six backends A, B, C, D, E, and F, and among them C is unhealthy and E is disabled. Pertanto, l'elenco dei back-end disponibili è A, B, D e F.So, list of available backends is A, B, D, and F. Vengono quindi selezionati i back-end prioritari tra quelli disponibili.Next, the top priority backends amongst the available ones are selected. Supponiamo che i back-end A, B e D abbiano la priorità 1 e che il back-end F abbia la priorità 2.Say, backend A, B, and D have priority 1 and backend F has a priority of 2. I back-end selezionati saranno A, B e D.So, selected backends will be A, B, and D. Selezionare i back-end con l'intervallo di latenza (latenza inferiore e sensibilità di latenza in ms specificata).Select the backends with latency range (least latency & latency sensitivity in ms specified). Supponiamo che A sia a 15 ms, B a 30 ms e D a 60 ms dall'ambiente Frontdoor in cui è stata ricevuta la richiesta e che la sensibilità di latenza sia di 30 ms. In questo caso, il pool con la latenza più bassa è costituito dai back-end A e B, perché D è a oltre 30 ms dal back-end più vicino (A).Say, if A is 15 ms, B is 30 ms and D is 60 ms away from the Front Door environment where the request landed, and latency sensitivity is 30 ms, then lowest latency pool comprises of backend A and B, because D is beyond 30 ms away from the closest backend that is A. Infine, Frontdoor eseguirà il round robin del traffico tra il pool selezionato finale di back-end nel rapporto di pesi specificati.Lastly, Front Door will round robin the traffic among the final selected pool of backends in the ratio of weights specified. Se il back-end A ha un peso di 5 e il back-end B ha un peso di 8, il traffico verrà distribuito in un rapporto di 5:8 tra i back-end A e B.Say, if backend A has a weight of 5 and backend B has a weight of 8, then the traffic will be distributed in the ratio of 5:8 among backends A and B.

Nota

Per impostazione predefinita, la proprietà di sensibilità di latenza è impostata su 0 ms, ovvero inoltrare sempre la richiesta al back-end più veloce disponibile.By default, the latency sensitivity property is set to 0 ms, that is, always forward the request to the fastest available backend.

Routing del traffico basato sulla prioritàPriority-based traffic-routing

Un'organizzazione vuole spesso offrire la massima affidabilità per i propri servizi dotandosi di uno o più servizi di backup in caso di inattività del servizio primario.Often an organization wants to provide reliability for its services by deploying one or more backup services in case their primary service goes down. A livello di settore, questa topologia è anche denominata topologia di distribuzione attiva/standby o attiva/passiva.Across the industry, this topology is also referred to as Active/Standby or Active/Passive deployment topology. Il metodo di routing del traffico "Priorità" consente ai clienti di Azure di implementare facilmente questo modello di failover.The 'Priority' traffic-routing method allows Azure customers to easily implement this failover pattern.

Il sistema Frontdoor predefinito contiene un elenco con uguale priorità dei back-end.Your default Front Door contains an equal priority list of backends. Per impostazione predefinita, Frontdoor invia il traffico solo ai back-end con la massima priorità (il valore più basso per la priorità), ovvero il set primario di back-end.By default, Front Door sends traffic only to the top priority backends (lowest value for priority) that is, the primary set of backends. Se i back-end primari non sono disponibili, Frontdoor instrada il traffico al set secondario di back-end (il secondo valore più basso per la priorità).If the primary backends are not available, Front Door routes the traffic to the secondary set of backends (second lowest value for priority). Se i back-end primari e secondari non sono disponibili, il traffico viene indirizzato al terzo e così via.If both the primary and secondary backends are not available, the traffic goes to the third, and so on. La disponibilità del back-end si basa sullo stato configurato (abilitato o disabilitato) e lo stato di integrità del back-end, determinato continuamente tramite i probe di integrità.Availability of the backend is based on the configured status (enabled or disabled) and the ongoing backend health status as determined by the health probes.

Configurazione della priorità per i back-endConfiguring priority for backends

Ognuno dei back-end nel pool back-end all'interno della configurazione di Frontdoor include una proprietà denominata "Priorità", che può essere un numero compreso tra 1 e 5.Each of the backends in your backend pool within the Front Door configuration has a property called 'Priority', which can be a number between 1 and 5. Con il servizio Frontdoor di Azure, è possibile configurare la priorità del back-end in modo esplicito usando questa proprietà per ogni back-end.With Azure Front Door Service, you configure the backend priority explicitly using this property for each backend. Questa proprietà accetta un valore compreso tra 1 e 5,This property is a value between 1 and 5. dove i valori più bassi rappresentano una priorità più elevata.Lower values represent a higher priority. I back-end possono condividere i valori di priorità.Backends can share priority values.

Metodo di routing del traffico PonderatoWeighted traffic-routing method

Il metodo di routing del traffico "Ponderato" consente di distribuire il traffico tra tutti gli endpoint in modo uniforme o con un peso predefinito.The 'Weighted' traffic-routing method allows you to distribute traffic evenly or to use a pre-defined weighting.

Nel metodo di routing del traffico "Ponderato" viene assegnato un peso a ogni back-end nella configurazione di Frontdoor del pool back-end.In the Weighted traffic-routing method, you assign a weight to each backend in the Front Door configuration of your backend pool. Ogni peso è un numero intero compreso tra 1 e 1000.The weight is an integer from 1 to 1000. Questo parametro usa un peso predefinito pari a "50".This parameter uses a default weight of '50'.

Tra l'elenco dei back-end disponibili entro la sensibilità di latenza accettata (come specificato), il traffico viene distribuito in un meccanismo round robin nel rapporto dei pesi specificati.Amongst the list of available backends within the accepted latency sensitivity (as specified), the traffic gets distributed in a round-robin mechanism in the ratio of weights specified. Se la sensibilità di latenza è impostata su 0 millisecondi, questa proprietà non avrà effetto a meno che non siano disponibili due back-end con la stessa latenza di rete.If the latency sensitivity is set to 0 milliseconds, then this property doesn't take effect unless there are two backends with the same network latency.

Il metodo "Ponderato" abilita alcuni scenari utili:The weighted method enables some useful scenarios:

  • Aggiornamento graduale dell'applicazione: allocare una percentuale di traffico da indirizzare a un nuovo back-end e incrementare gradualmente il traffico nel tempo per portarlo al livello degli altri back-end.Gradual application upgrade: Allocate a percentage of traffic to route to a new backend, and gradually increase the traffic over time to bring it at par with other backends.
  • Migrazione dell'applicazione in Azure: creare un pool back-end con back-end di Azure ed esterni.Application migration to Azure: Create a backend pool with both Azure and external backends. Regolare il peso dei back-end per preferire i nuovi back-end.Adjust the weight of the backends to prefer the new backends. È possibile applicare questa configurazione gradualmente, iniziando con i nuovi back-end disabilitati, quindi assegnando loro i pesi più bassi e aumentandoli lentamente fino ai livelli di massimo traffico.You can gradually set this up starting with having the new backends disabled, then assigning them the lowest weights, slowly increasing it to levels where they take most traffic. È infine possibile disabilitare i back-end con preferenza inferiore e rimuoverli dal pool.Then finally disabling the less preferred backends and removing them from the pool.
  • Espansione del cloud per capacità aggiuntiva: espandere rapidamente una distribuzione locale nel cloud posizionandola dietro Frontdoor.Cloud-bursting for additional capacity: Quickly expand an on-premises deployment into the cloud by putting it behind Front Door. In caso di necessità di capacità aggiuntiva nel cloud, si possono aggiungere o abilitare più back-end e si può specificare la quantità di traffico da indirizzare a ogni back-end.When you need extra capacity in the cloud, you can add or enable more backends and specify what portion of traffic goes to each backend.

Affinità di sessioneSession Affinity

Per impostazione predefinita, senza l'affinità di sessione, Frontdoor inoltra le richieste provenienti dallo stesso client a diversi back-end in base alla configurazione di bilanciamento del carico, in particolare quando le latenze dei diversi back-end cambiano o se vengono ricevute richieste diverse dallo stesso utente in un ambiente Frontdoor differente.By default, without session affinity, Front Door forwards requests originating from the same client to different backends based on load balancing configuration particularly as the latencies to different backends change or if different requests from the same user lands on a different Front Door environment. Tuttavia, per alcune applicazioni con stato o in determinati scenari è preferibile inoltrare le richieste successive dallo stesso utente allo stesso back-end che ha elaborato la richiesta iniziale.However, some stateful applications or in certain other scenarios, prefer that subsequent requests from the same user land on the same backend that processed the initial request. L'affinità di sessione basata su cookie è utile quando si vuole mantenere una sessione utente nello stesso back-end.The cookie-based session affinity feature is useful when you want to keep a user session on the same backend. Usando i cookie gestiti di Frontdoor, il servizio Frontdoor di Azure può indirizzare il traffico successivo proveniente da una sessione utente allo stesso back-end per l'elaborazione, a condizione che il back-end sia integro e che la sessione utente non sia scaduta.By using Front Door managed cookies, Azure Front Door Service can direct subsequent traffic from a user session to the same backend for processing as long as the backend is healthy and the user session hasn't expired.

L'affinità di sessione può essere abilitata a livello di host front-end per tutti i domini (o i sottodomini) configurati.Session affinity can be enabled at a frontend host level that is for each of your configured domains (or subdomains). Una volta abilitata, Frontdoor aggiunge un cookie alla sessione dell'utente.Once enabled, Front Door adds a cookie to the user's session. L'affinità di sessione basata su cookie consente a Frontdoor di identificare i diversi utenti, anche se usano lo stesso indirizzo IP, permettendo una distribuzione più uniforme del traffico tra back-end differenti.Cookie-based session affinity allows Front Door to identify different users even if behind the same IP address, which in turn allows a more even distribution of traffic between your different backends.

La durata del cookie corrisponde a quella della sessione utente, perché Frontdoor attualmente supporta solo i cookie di sessione.The lifetime of the cookie is the same as the user's session, as Front Door currently only supports session cookie.

Nota

I proxy pubblici possono interferire con l'affinità di sessione,Public proxies may interfere with session affinity. perché per stabilire una sessione è necessario che Frontdoor aggiunga un cookie di affinità di sessione nella risposta, operazione che non può essere eseguita se la risposta è memorizzabile nella cache, in quanto potrebbe compromettere i cookie di altri client che richiedono la stessa risorsa.This is because establishing a session requires Front Door to add a session affinity cookie to the response, which cannot be done if the response is cacheable as it would disrupt the cookies of other clients requesting the same resource. Per proteggersi da questa situazione, l'affinità di sessione non verrà stabilita se il back-end invia una risposta memorizzabile nella cache quando si tenta di eseguire questa operazione.To protect against this, session affinity will not be established if the backend sends a cacheable response when this is attempted. Se la sessione è già stata stabilita, non importa se la risposta dal back-end è memorizzabile nella cache.If the session has already been established, it does not matter if the response from the backend is cacheable. L'affinità di sessione verrà stabilita nelle circostanze seguenti, a meno che la risposta non abbia un codice di stato HTTP 304:Session affinity will be established in the following circumstances, unless the response has an HTTP 304 status code:

  • Per l'intestazione Cache-Control della risposta vengono impostati valori specifici che impediscono la memorizzazione nella cache, ad esempio "private" o "no-store ".The response has specific values set for the Cache-Control header that prevent caching, such as "private" or no-store".
  • La risposta contiene un'intestazione Authorization non scaduta.The response contains an Authorization header that has not expired.
  • La risposta contiene un codice di stato HTTP 302.The response has an HTTP 302 status code.

Passaggi successiviNext steps