Guida all'implementazione a disponibilità elevata per l'uso di Frontdoor di Azure e soluzioni di ingresso alternative

Frontdoor di Azure è progettato per offrire resilienza e disponibilità eccezionali sia per i clienti esterni che per le proprietà interne di Microsoft. Anche se l'architettura di Frontdoor di Azure soddisfa o supera le esigenze della maggior parte dei carichi di lavoro di produzione, nessun sistema distribuito è immune a errori.

Questo articolo fornisce istruzioni di alto livello, passo dopo passo, per l'implementazione di Azure Traffic Manager per abilitare il failover manuale da Azure Front Door a una content delivery network (CDN) alternativa o a un web application firewall (WAF) di Azure Application Gateway durante rare interruzioni del servizio Azure Front Door. Integra le linee guida in Ridondanza globale del routing per applicazioni Web cruciali.

Esistono più strategie all'interno del settore per ottenere la disponibilità elevata (HA) nelle architetture della rete CDN e delle applicazioni Web. L'approccio descritto in questo articolo è incentrato su un modello di failover semplice e manuale "break-glass". I clienti possono usare il modello per reindirizzare rapidamente il traffico durante un'interruzione e ripristinare facilmente il routing a Frontdoor di Azure dopo la conferma dell'integrità del servizio.

L'articolo include anche indicazioni per l'implementazione di modelli HA in ambienti di produzione, l'istituzione di un monitoraggio dello stato di integrità e la creazione di runbook operativi a supporto della prontezza operativa continua.

Principali differenze operative

Questa guida presenta due architetture comprovate che usano Traffic Manager per fornire il failover automatico. La tabella seguente riepiloga le principali differenze operative da considerare:

Aspetto	Scenario 1 (Azure Front Door e Application Gateway)	Scenario 2 (Frontdoor di Azure + altra rete CDN)
Destinazione del failover	Istanza secondaria di Gestione traffico e più istanze del gateway applicazione.	Altro singolo endpoint CDN.
Memorizzazione nella cache durante il failover	No. Il gateway applicativo non effettua il caching.	Sì.
Distribuzione geografica	Due aree di Azure specifiche.	Altra rete perimetrale globale della rete CDN.
Protezione WAF	Web application firewall di Azure (set di regole coerenti).	Altri WAF della rete CDN (set di regole diversi).
Costo in modalità stand-by	Costi di calcolo fissi. Il gateway applicativo viene addebitato anche quando è inattivo: 200-400 $/mese per WAF_v2 con capacità minima.	A seconda dei prezzi del fornitore della rete CDN.

Considerazioni per gli ambienti di produzione

Quando si implementano architetture a disponibilità elevata per i carichi di lavoro di produzione, prendere in considerazione le seguenti procedure consigliate e note importanti:

Non configurare l'istanza primaria di Traffic Manager per il failover automatico.

Le sonde di integrità di Azure Traffic Manager provengono solo dalle aree di Azure basate sugli Stati Uniti. Per i probe degli endpoint di Frontdoor di Azure (o di qualsiasi rete CDN che usi il routing anycast), questi probe con sede negli Stati Uniti raggiungono quasi sempre i server POP statunitensi, lasciando non verificata l'integrità dei server POP non statunitensi. Questa situazione impedisce a Gestione traffico di eseguire automaticamente il failover tra Frontdoor di Azure e un altro servizio in ingresso in base alla vera integrità globale della rete CDN anycast, ad esempio Frontdoor di Azure.

Per i carichi di lavoro globali che richiedono la convalida dello stato di integrità da più aree geografiche, il failover manuale con routing ponderato e monitoraggio disabilitato offre un controllo più affidabile rispetto al routing automatico basato sullo stato di integrità.
Se attualmente si usano certificazioni gestite da Frontdoor di Azure, è necessario eseguire la migrazione ai certificati BYO (Bring Your Own). Usando il proprio certificato, è possibile mantenere coerenti i certificati TLS indipendentemente dal percorso di ingresso seguito dal traffico.

Assicurarsi che i certificati TLS siano compatibili con Frontdoor di Azure. Per altre informazioni, vedere Configurare HTTPS in un dominio personalizzato di Frontdoor di Azure e crittografia TLS con Frontdoor di Azure.
Prima di tutto testare le procedure di failover in ambienti non di produzione.
Traffic Manager non supporta l'appiattimento CNAME all'apice della zona DNS (dominio principale). Se hai bisogno di Traffic Manager al vertice, è necessario usare provider DNS che supportano record alias o meccanismi simili. DNS di Azure è un provider DNS di questo tipo.
Usare i valori TTL (Short DNS Time-to-Live) di 300-600 secondi. Monitorare i tempi di propagazione TTL DNS.
Bloccare il gateway applicazione con gruppi di sicurezza di rete (NSG) ed elenchi di controllo di accesso (ACL). Consentire gli intervalli richiesti della piattaforma e le porte di ingresso dell'applicazione. Mantenere le origini protette per tutti i percorsi in ingresso. Per altre informazioni, vedere Gruppi di sicurezza di rete.

Anche se un WAF del gateway applicazione mitiga gli attacchi HTTP/L7, i gruppi di sicurezza di rete forniscono solo il filtraggio dei pacchetti e non proteggono dagli attacchi DDoS volumetrici o a livello di protocollo (L3/L4). Tutti gli endpoint pubblici di Azure traggono vantaggio dalla protezione DDoS sempre attiva nella piattaforma Azure. Consente di proteggere l'infrastruttura di Azure, ma non include le garanzie di ottimizzazione, telemetria, protezione dei costi o disponibilità specifiche del carico di lavoro.

Per i carichi di lavoro di produzione e cruciali, è consigliabile usare il servizio Protezione DDoS di Azure per proteggere gli indirizzi IP pubblici del gateway applicazione. Per altre informazioni, vedere Prezzi di Protezione DDoS di Azure.
Documentare le differenze tra le regole WAF di Azure Front Door e soluzioni di failover.
Non è consigliabile usare il collegamento privato di Azure per queste architetture a disponibilità elevata perché le piattaforme di rete CDN alternative non possono accedere alle origini protette dall'integrazione del collegamento privato in Frontdoor di Azure.

Inoltre, l'Application Gateway richiede un'ulteriore configurazione della rete virtuale e dell'endpoint privato per accedere alle origini private. Il gateway applicativo non è in grado di utilizzare le funzionalità native di Private Link di Azure Front Door.

Per gli ambienti di produzione che usano Frontdoor di Azure insieme ad altri provider di rete CDN, è consigliabile usare controlli alternativi indipendenti dalla rete CDN per applicare l'attendibilità dell'origine quando non è possibile usare collegamento privato o X‑Azure‑FDID convalida. Questi controlli possono includere l'autenticazione basata su token (HMAC o URL firmati), tls reciproco (mTLS), intestazioni di origine personalizzate e filtro degli indirizzi IP.
Modificare i comandi di esempio elencati in questa guida in modo che siano personalizzati per l'ambiente per l'automazione e i runbook.
Stabilire runbook chiari. Testare le procedure di failover e failback.
Configurare il monitoraggio completo e l'invio di avvisi per tutti gli endpoint.
Verificare la funzionalità durante il failover verso soluzioni di entrata alternative.
Testare i processi di rinnovo dei certificati in tutte le piattaforme.
Verificare regolarmente che gli endpoint di failover rimangano funzionanti. È consigliabile eseguire test trimestrali.
Questa guida usa i comandi di esempio dell'interfaccia della riga di comando di Azure eseguiti da PowerShell.
Prima di procedere, vedere Ridondanza del routing globale per applicazioni Web cruciali.

Scenario 1: il failover di Gestione traffico da Frontdoor di Azure a un WAF del gateway applicazione

Questa soluzione di bilanciamento del carico basata su DNS usa più profili di Gestione traffico di Azure. Nel caso improbabile di un problema di disponibilità con Azure Front Door, Traffic Manager reindirizza il traffico attraverso il WAF dell'Application Gateway. L'istanza primaria di Traffic Manager instrada il traffico tra Azure Front Door (primario) e un'istanza di Traffic Manager secondaria annidata che punta a istanze di Application Gateway in più aree. Durante un'interruzione di Azure Front Door, il traffico viene deviato manualmente verso distribuzioni regionali di Application Gateway con protezione WAF.

Flusso del traffico (operazione normale): utente → query DNS → istanza primaria di Gestione traffico (routing ponderato/a servizio costante) → Frontdoor di Azure (priorità 1) → server di origine.
Flusso del traffico (errore di Frontdoor di Azure): utente → query DNS → istanza primaria di Gestione traffico (routing ponderato/a servizio costante) → istanza secondaria di Gestione traffico (modalità priorità) → gateway applicazione → server di origine.

Pre-distribuzione: Azure Front Door vs Application Gateway

È importante comprendere le differenze di funzionalità tra Azure Front Door e un WAF del gateway di applicazione, nel caso in cui si utilizzino funzionalità che un WAF del gateway di applicazione non offre. Le tabelle seguenti offrono una panoramica.

Importante

Questa soluzione presuppone che attualmente si stia usando Frontdoor di Azure per gestire il traffico tra più aree o a livello globale. In questa progettazione, i passaggi che seguono introducono un'istanza secondaria di Traffic Manager configurata con il routing in base alle prestazioni tra l'istanza primaria di Traffic Manager e le istanze regionali di Application Gateway.

Questo approccio è necessario perché Frontdoor di Azure è un servizio globale di livello 7. L'istanza secondaria di Gestione traffico sostituisce in modo efficace il routing globale basato sulla latenza in Frontdoor di Azure fungendo da livello di bilanciamento del carico globale. Di conseguenza, il Gestione Traffico preserva il routing utente ottimizzato in base alla latenza per un pubblico distribuito geograficamente.

Dato questo cambiamento architetturale, è necessario valutare i modelli di traffico globali e distribuire istanze del gateway applicazione in aree con volume utente significativo per garantire prestazioni e resilienza ottimali.

Differenze di funzionalità

Caratteristica / Funzionalità	Frontdoor di Azure	Application Gateway
Architettura e funzionalità di base
Ambito del servizio	Servizio globale	Servizio a livello di area
Livello OSI	Livello 7 (livello applicazione)	Livello 7 (livello applicazione)
Livello di bilanciamento del carico	Tra regioni	All'interno di un'area o di una rete virtuale
Modello di distribuzione	Singola istanza globale	Istanze per regione
Ambito back-end	Qualsiasi endpoint pubblico (Azure o esterno) e endpoint di collegamento privato selezionati	Qualsiasi endpoint pubblico (Azure o esterno), indirizzi IP privati e pod Kubernetes in una rete virtuale
Memorizzazione nella cache perimetrale del contenuto	Yes	NO
Architettura di rete	Rete perimetrale globale di Microsoft con anycast	Distribuzione regionale di Azure (senza anycast)
Differenze di configurazione
Sintassi del modello di percorso	`/path/*` o esatto `/path`	Modelli regex, mappe percorso
Set di regole WAF	Set di regole predefinito (OWASP), set di regole del gestore bot, set di regole DDoS HTTP	Set di regole predefinito (OWASP), set di regole di gestione bot, set di regole HTTP DDoS
Valutazione probe di integrità	Latenza e integrità per il routing	Solo stato di salute
Selezione back-end	In base alla priorità, al peso, alla latenza	Round-robin, affinità ai cookie
Regole di routing
Routing basato sul percorso	✓ Sì	✓ Sì
Corrispondenza dei criteri	Percorsi di corrispondenza esatta, percorsi con caratteri jolly (`/*`), nessuna distinzione tra maiuscole e minuscole, ogni carattere jolly deve essere preceduto da `/`	Mappe dei percorsi URL, regole basate sul percorso, modelli regex supportati
Routing basato su host	✓ Più host front-end	✓ Hosting multisito
URL rewrite	Percorso statico a percorso statico (classico)	Riscrittura percorso URL
Metodi di routing	Priorità, peso, basata sulla latenza	Consapevolezza del carico per l'ottimizzazione della latenza, ponderata, affinità di sessione (*disponibile con gateway applicazione per container)
Funzionalità di routing
Motore di regole/regole di riscrittura	Set di regole con condizioni e azioni	Riscrivere i set di regole con condizioni e azioni
Espressione regolare nei modelli di percorso	Non supportato in schemi da abbinare	Supportato con PCRE
Modifica dell'intestazione e della richiesta
Riscrittura intestazione	✓ Intestazioni di richieste e risposte	✓ Intestazioni di richieste e risposte
Limite di caratteri per il valore dell'intestazione	Nessun limite documentato	1.000 caratteri nelle regole di riscrittura
Riscrittura dell'intestazione host	✓ Supportato	✓ Supportato (non può riscrivere in domini esterni)
Variabili del server	✓ Supportato	✓ Supportato
Corrispondenza dei modelli di intestazione	Condizioni con schemi	Criteri di ricerca regex
funzionalità di sicurezza
Disponibilità di WAF	✓ Facoltativo (livello Premium)	✓ Facoltativo (livello WAF)
Protezione DDoS L3/4	✓ Integrato	Tramite il servizio Protezione DDoS di Azure
Politiche SSL/TLS	✓ Configurabile	✓ Configurabile
SSL da capo a coda	✓ Supportato	✓ Supportato
Supporto per Collegamento privato	✓ Livello Premium	✓ Livello V2
Regole personalizzate di WAF	✓ Supportato	✓ Supportato

Differenze di WAF

Frontdoor di Azure	Application Gateway
Microsoft Default Rule Set (DRS) 2.1	Set di regole di base OWASP (CRS) 3.2 o 4.0
ID delle regole: serie 949xxx	ID delle regole: serie 9xxxxx
Azure Front Door WAF (DRS): esamina i primi 128 KB del corpo della richiesta	WAF gateway applicazione (CRS 3.2+): ispezione fino a 2 MB; caricamento di file fino a 4 GB; applicazione e ispezione configurabili in modo indipendente.

Recommendations

Poiché è necessario mantenere set di regole distinti per ogni WAF, usare il set di regole frontdoor di Azure come baseline. Creare un set di regole del gateway applicativo che corrisponda al set di regole di Azure Front Door il più possibile.
Testare il WAF del gateway applicazione separatamente e in modo indipendente.
Documentare tutte le esclusioni personalizzate per entrambe le piattaforme.
Set di regole di controllo regolari per la coerenza.
Attenersi alle indicazioni di rete nella configurazione dell'infrastruttura del gateway applicativo di Azure. Assicurarsi di soddisfare i requisiti di rete virtuale e sottorete seguenti:
- Utilizzare il seguente ridimensionamento della subnet (per regione):
  - Minimo: /27 (32 indirizzi)
  - Consigliato: /24 (256 indirizzi) per la scalabilità automatica e la manutenzione senza riscontri
  - Formula: (numero massimo di istanze * 10) + 5 indirizzi IP riservati di Azure
  - Esempio: 20 istanze massime → (20 * 10) + 5 = 205 IP → utilizzare /24
- Per una sicurezza ottimale, usare una subnet dedicata per Application Gateway senza altre risorse.
- Assicurarsi che la connessione in ingresso consenta:
  - 443/80 da Internet (o intervalli di origine specifici)
  - 65200-5535 da gestione gateway di Azure (gateway applicazione v2)
  - Bilanciatore di carico Azure
- Bloccare altre connessioni in ingresso. Non bloccare le connessioni Internet in uscita necessarie.
- Usare i gruppi di sicurezza delle applicazioni per la segmentazione back-end e le regole con privilegi minimi.

Per la pianificazione della capacità e la strategia di scalabilità automatica, vedere Procedure consigliate per l'architettura del Gateway Applicazioni di Azure v2.

Passaggi chiave per l'implementazione

Passaggio 1: Configura i prerequisiti

Frontdoor di Azure configurato con un dominio personalizzato e un certificato BYO.
Un TTL DNS più basso per il record CNAME, in modo che Frontdoor di Azure instradi il traffico in base all'impostazione di tempo più breve.
Sottoscrizione di Azure con autorizzazioni per creare reti virtuali, un'istanza del gateway delle applicazioni e un'istanza di "Traffic Manager".
Certificato SSL/TLS in Azure Key Vault o disponibile per il caricamento.
Server di origine accessibili dalle reti virtuali di Azure.

Importante

Se attualmente si usano certificati gestiti da Frontdoor di Azure, è necessario eseguire la migrazione ai certificati BYO prima di implementare questa soluzione. I certificati gestiti da Frontdoor di Azure non possono essere esportati e installati in reti CDN alternative. Per altre informazioni, vedere Configurare HTTPS in un dominio personalizzato di Frontdoor di Azure.

Passaggio 2: Distribuire il gateway applicativo nella prima regione

Creare un'infrastruttura di rete per Application Gateway. Per altre informazioni, vedere la configurazione dell'infrastruttura del gateway applicazione.
Creare un'identità gestita e concedere l'accesso a Key Vault. Per altre informazioni, vedere Terminazione TLS con certificati di Key Vault.

Il gateway applicativo richiede il certificato SSL/TLS in formato PFX con una chiave privata. Il certificato deve essere accessibile da Key Vault o caricato direttamente. Usare lo stesso certificato usato da Frontdoor di Azure per garantire un comportamento TLS coerente.
Creare un criterio WAF. Per ulteriori informazioni, vedere Creare criteri WAF per Application Gateway.
Creare un'istanza del gateway applicazione con HTTPS e WAF. Per altre informazioni, vedere Configurare un'istanza del gateway di applicazione con terminazione TLS.
Configurare un'intestazione host back-end. Per altre informazioni, vedere Risolvere i problemi di integrità back-end in Application Gateway.

Verificare il Gateway delle applicazioni:

# Get Application Gateway public IP
$APPGW_IP = az network public-ip show `
    --name $APPGW_PIP_NAME_R1 `
    --resource-group $RESOURCE_GROUP `
    --query ipAddress -o tsv
Write-Host "Application Gateway IP: $APPGW_IP"

# Test Application Gateway directly (SkipCertificateCheck because certificate is for domain, not IP)
Invoke-WebRequest -Uri "https://$APPGW_IP/index.html" -Method Head -SkipCertificateCheck

Il risultato previsto è il codice di stato 200. Se si riceve l'errore "502 Gateway non valido", assicurarsi che nelle impostazioni HTTP del backend --host-name-from-backend-pool true sia abilitato.

Passaggio 3: Configurare le impostazioni dei criteri WAF (facoltativo)

Per impostazione predefinita, viene creato un WAF in modalità di rilevamento. La modalità di prevenzione blocca attivamente le richieste dannose. Testare attentamente prima di abilitare la modalità di prevenzione nell'ambiente di produzione.

Valuta i modelli di traffico globali e distribuisci le istanze di Application Gateway in regioni con un volume di utenti significativo. Se si implementa l'Application Gateway in più regioni, ripetere i passaggi 2 e 3 per ciascuna area aggiuntiva, ad esempio West US 2. Usare spazi di indirizzi di rete virtuale diversi (10.2.0.0/16, 10.3.0.0/16 e così via) e suffissi di variabili specifiche dell'area (R2, R3 e così via).

Passaggio 4: Creare un'architettura di Traffic Manager per supportare gli endpoint WAF dell'Application Gateway

Creare un'istanza secondaria di Gestione traffico in modalità prestazioni, come illustrato in precedenza nel diagramma per questo scenario. Per altre informazioni, vedere Creare un profilo di Gestione traffico.

Per una configurazione a singola area, usare questi dettagli:

Metodo di routing: priorità.
Endpoint: indirizzo IP pubblico del gateway di applicazione singola.

Per una configurazione in più aree, usare questi dettagli:

Metodo di routing: Performance (instrada gli utenti all'istanza di Application Gateway sana più vicina).
Endpoint: più indirizzi IP pubblici del gateway applicazione in diverse aree.
Località degli endpoint: area di Azure per ogni endpoint (obbligatorio per il routing delle prestazioni).

Usare queste impostazioni di configurazione:

Impostazione	Value	Note
Metodo di routing	Prestazioni (multi-regione) o Priorità (singola regione)	Le prestazioni ottimizzano la latenza per una configurazione in più aree.
Protocollo	HTTPS	Convalida l'integrità del gateway applicativo tramite HTTPS.
Porto	443	Porta HTTPS standard.
Percorso	`/health` o `/index.html`	Deve corrispondere al percorso del probe di integrità del back-end del gateway applicazione.
TTL	300 secondi	Bilancia il carico e la velocità di risposta delle query DNS.

Annotazioni

Per impostazione predefinita, gli indirizzi IP pubblici di Azure per il gateway applicazione non hanno nomi DNS configurati. È necessario usare l'indirizzo IP pubblico direttamente negli endpoint di Gestione traffico, non un nome DNS. Il --endpoint-location parametro è necessario per il routing delle prestazioni per abilitare il routing geografico.

Creare un'istanza primaria di Gestione traffico con routing ponderato/a servizio costante, come mostrato in precedenza nel diagramma per questo scenario. Per altre informazioni, vedere Creare un profilo di Gestione traffico.

Per entrambi gli endpoint, usare queste configurazioni:

Impostazione	Value	Note
Metodo di routing	Ponderato	Consente il controllo manuale tramite lo stato dell'endpoint (abilitato o disabilitato).
peso	100
Protocollo	HTTPS	Obbligatorio per convalidare gli endpoint SSL/TLS.
Porto	443	Porta HTTPS standard.
Percorso	`/index.html`	Scegliere un endpoint leggero per i controlli di integrità.
TTL	300 secondi	DNS TTL. I valori inferiori consentono un failover più rapido, ma aumentano le query DNS.
Controllo integrità	Servire sempre il traffico	Non abilitare le verifiche dello stato di salute.

Queste configurazioni sono specifiche dell'endpoint primario:

Tipo: endpoint esterno
Nome: endpoint-afd-primary
Nome di dominio completo (FQDN) o indirizzo IP: nome host dell'endpoint frontdoor di Azure (ad esempio, myapp-12345.z01.azurefd.net)
Abilita endpoint: selezionato (abilitato)
Impostazioni intestazione personalizzate: Host=$CUSTOM_DOMAIN (necessarie affinché Frontdoor di Azure instradi il traffico verso il dominio personalizzato corretto)
Controlli di integrità: servire sempre il traffico (disabilitare i controlli di integrità)

Queste configurazioni sono specifiche dell'endpoint secondario:

Tipo: endpoint esterno
Nome: endpoint-appgw-secondary
Nome di dominio completo (FQDN) o indirizzo IP: FQDN del gestore di traffico secondario (ad esempio, myapp-appgw.trafficmanager.net)
Abilita endpoint: deselezionato (disabilitato)

Verificare lo stato di funzionamento di Traffic Manager:

# Check endpoint health status
az network traffic-manager profile show `
    --name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --query "{ProfileStatus:profileStatus, MonitorStatus:monitorConfig.profileMonitorStatus, Endpoints:endpoints\[\].{Name:name, Target:target, Priority:priority, Status:endpointMonitorStatus}}"

Entrambi gli endpoint devono mostrare Status: Online. Se un endpoint mostra Degraded o CheckingEndpoint, attendere 1-2 minuti per il completamento dell'operazione dei probe di integrità.

Passaggio 5: Aggiornare il CNAME DNS a Traffic Manager e verificare l'aggiornamento

Avvertimento

La procedura seguente reindirizzerà il traffico di produzione da Frontdoor di Azure direttamente a Gestione traffico e causerà un potenziale impatto sul servizio. Prima di procedere:

Testare prima questi passaggi in un ambiente non di produzione. Ad esempio, modificare temporaneamente il file locale hosts in una workstation non di produzione per risolvere il dominio personalizzato nell'endpoint di Gestione traffico. Questa modifica consente la convalida senza influire sul traffico in tempo reale.
Ridurre il TTL CNAME DNS al valore più basso possibile (ad esempio, 60-300 secondi) almeno 24 ore prima di apportare modifiche.
Pianificare una finestra di manutenzione durante periodi di traffico ridotto, se possibile.
È possibile preparare le procedure di rollback nel caso in cui si verifichino problemi.

Aggiorna il record CNAME DNS in modo che punti all'istanza primaria di Gestione Traffico anziché direttamente ad Azure Front Door.

Campo	Valore precedente	Nuovo valore
Nome/Host	www	www (nessuna modifica)
Valore/Punti a	Nome host dell'endpoint Front Door di Azure	`$ATM_DNS_NAME.trafficmanager.net`

Verifica della risoluzione con Traffic Manager:
```
# Verify Traffic Manager profile is resolving
nslookup "$ATM_DNS_NAME.trafficmanager.net"
```
Il test deve restituire l'indirizzo IP dell'endpoint frontdoor di Azure.
Attendere la propagazione DNS e quindi testare la connettività HTTPS. La propagazione DNS richiede in genere 5-10 minuti, ma può richiedere fino a 48 ore a livello globale.
```
# Check DNS from different resolvers
nslookup $CUSTOM_DOMAIN 8.8.8.8 # Google DNS

# Test HTTPS connectivity
Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
```
Questo test deve restituire il codice di stato 200.
Dopo la transizione DNS, monitorare attivamente le seguenti metriche di Azure Front Door:
- Numero di richieste: il conteggio deve rimanere coerente, senza alcun calo del traffico.
- Tempo di risposta: il tempo deve rimanere entro intervalli normali.
- Frequenza di errore: gli errori 4xx/5xx non devono aumentare.
- Integrità dell'origine: l'integrità del back-end deve rimanere Online.

Passaggio 6: Testare le procedure di failover

Simulare un errore di Frontdoor di Azure (failover manuale nel gateway applicazione):

# Manual failover to Application Gateway
# Disable Azure Front Door endpoint
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

# Enable secondary Traffic Manager endpoint (Application Gateway)
az network traffic-manager endpoint update `
    --name "endpoint-appgw-secondary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

# Verify Traffic Manager endpoint status
az network traffic-manager endpoint list `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
    --output table

# Flush DNS cache (Windows)
ipconfig /flushdns

# Verify DNS resolution (should now point to secondary Traffic Manager instance and Application Gateway)
nslookup $CUSTOM_DOMAIN

# Test - should now work via Application Gateway
curl --head https://$CUSTOM_DOMAIN/

Annotazioni

Il TTL DNS influisce sul tempo di failover. Con un valore TTL di 60 secondi, i client potrebbero richiedere fino a 60 secondi per visualizzare la modifica. Usare nslookup per verificare che la risoluzione punti al gateway applicazione.

Failback a Frontdoor di Azure:

# Re-enable Azure Front Door endpoint
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

# Disable Application Gateway (via Secondary Traffic Manager)
az network traffic-manager endpoint update `
    --name "endpoint-appgw-secondary" `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

# Verify endpoint status
az network traffic-manager endpoint list `
    --profile-name $ATM_PRIMARY_PROFILE `
    --resource-group $RESOURCE_GROUP `
    --query "[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}" `
    --output table

# Flush DNS cache (Windows)
ipconfig /flushdns

# Verify DNS resolution (should now point back to Azure Front Door)
nslookup $CUSTOM_DOMAIN

# Test - should now work via Azure Front Door
curl --head https://$CUSTOM_DOMAIN/

Verificare il routing corrente:
```
# Check which endpoint is serving traffic
nslookup $CUSTOM_DOMAIN

Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head | Select-Object -ExpandProperty Headers
```
I header di risposta possono aiutare a identificare l'endpoint di servizio.
- Frontdoor di Azure include l'intestazione x-azure-ref .
- Il traffico che passa attraverso Application Gateway può includere Server: Microsoft-IIS o simile.

Scenario 2: failover di Gestione traffico da Frontdoor di Azure a una rete CDN alternativa

Questa soluzione usa un singolo profilo di Gestione traffico con routing ponderato/always-serve in modo da poter passare manualmente il traffico tra Frontdoor di Azure e una rete CDN alternativa.

Endpoint primario: endpoint di dominio personalizzato di Frontdoor di Azure.
Endpoint secondario: endpoint della rete CDN alternativo.
Flusso del traffico (operazione normale): utente → query DNS → Gestione traffico (routing ponderato/a servizio costante) → Frontdoor di Azure (priorità 1) → server di origine.
Flusso del traffico (errore di Frontdoor di Azure): utente → query DNS → Gestione traffico (routing ponderato/a servizio costante) → CDN alternativa (priorità 2) → server di origine.

Passaggi chiave per l'implementazione

Passaggio 1: Configura i prerequisiti

Configurare il provider di rete CDN secondario con:

Frontdoor di Azure configurato con un dominio personalizzato e un certificato BYO.
Un account di rete CDN alternativo.
Un TTL DNS più basso per il record CNAME, in modo che Frontdoor di Azure instradi il traffico in base all'impostazione di tempo più breve.
Server di origine a cui possono accedere sia Frontdoor di Azure che la rete CDN alternativa.
Dominio personalizzato in grado di modificare i record DNS.

Importante

Se attualmente si usano certificati gestiti da Frontdoor di Azure, è necessario eseguire la migrazione ai certificati BYO prima di implementare questa soluzione a disponibilità elevata. I certificati gestiti da Frontdoor di Azure non possono essere esportati e installati in reti CDN alternative. Per altre informazioni e istruzioni di configurazione per i certificati BYO, vedere Configurare HTTPS in un dominio personalizzato di Frontdoor di Azure.

Passaggio 2: Configurare una rete CDN alternativa

Configurare il provider di rete CDN secondario:

Configurare la zona o la proprietà della rete CDN con il dominio personalizzato.
Configurare i server di origine allo stesso modo in cui è stato configurato il pool back-end di Frontdoor di Azure.
Caricare il certificato SSL/TLS BYO. Questo certificato è lo stesso usato in Frontdoor di Azure.
Configurare le regole di memorizzazione nella cache della rete CDN in modo che corrispondano al comportamento di Frontdoor di Azure. Ad esempio, configurare le durate della cache e la gestione delle stringhe di query.
Configurare le impostazioni di memorizzazione nella cache, le intestazioni di controllo e le impostazioni di compressione in modo che corrispondano alla configurazione di Frontdoor di Azure.
Configurare le regole WAF se il provider di rete CDN offre funzionalità WAF. Tentare di adeguarsi ai criteri WAF di Azure Front Door.
Configurare un dominio personalizzato in modo che corrisponda al dominio personalizzato di Frontdoor di Azure , ad esempio www.contoso.com.
Registrare il nome host perimetrale della rete CDN per la configurazione di Gestione traffico, ad esempio your-site.cdn.provider.net.

Passaggio 3: Creare un profilo di Gestione traffico

Applicare le configurazioni seguenti per creare il profilo di Gestione traffico. Per altre informazioni, vedere Creare un profilo di Gestione traffico.

Impostazione	Value	Note
Metodo di routing	Ponderato	Consente il controllo manuale tramite lo stato dell'endpoint (abilitato o disabilitato).
peso	100	Immettere 100 quando viene creato il profilo di Gestione traffico e per entrambi gli endpoint.
Protocollo	HTTPS	Obbligatorio per convalidare gli endpoint SSL/TLS.
Porto	443	Porta HTTPS standard.
Percorso	`/index.html`	Scegliere un endpoint leggero per i controlli di integrità.
TTL	300 secondi	DNS TTL. I valori inferiori consentono un failover più rapido, ma aumentano le query DNS.

Passaggio 4: Configurare gli endpoint di Gestione traffico

Creare due endpoint all'interno del profilo di Gestione traffico.

Usare queste configurazioni per l'endpoint primario (Frontdoor di Azure):

Tipo: endpoint esterno
Nome: endpoint-afd-primary
Nome di dominio completo (FQDN) o indirizzo IP: nome host dell'endpoint frontdoor di Azure (ad esempio, myapp-endpoint-12345.z01.azurefd.net)
Peso: 100
Abilita endpoint: selezionato (abilitato) inizialmente
Impostazioni intestazione personalizzate: Host=$CUSTOM_DOMAIN (necessarie affinché Frontdoor di Azure instradi il traffico verso il dominio personalizzato corretto)
Controlli di integrità: servire sempre il traffico (disabilitare i controlli di integrità)

Annotazioni

Il --custom-headers "Host=$CUSTOM_DOMAIN" parametro è fondamentale per gli endpoint frontdoor di Azure. Senza di esso, Frontdoor di Azure potrebbe non instradare correttamente le richieste alla configurazione del dominio personalizzato. Si tratta di una funzionalità supportata di Gestione traffico di Azure.

Usare queste configurazioni per l'endpoint secondario (rete CDN alternativa):

Tipo: endpoint esterno
Nome: endpoint-cdn-secondary
Nome di dominio completo (FQDN) o indirizzo IP: nome host della rete CDN edge (ad esempio, myapp.cdn.net)
Peso: 100
Abilita endpoint: deselezionato (disabilitato) inizialmente per la modalità standby

Passaggio 5: Aggiornare il CNAME DNS a Traffic Manager e verificare l'aggiornamento

Avvertimento

La procedura seguente reindirizzerà il traffico di produzione da Frontdoor di Azure direttamente a Gestione traffico. Prima di procedere:

Testare prima questi passaggi in un ambiente non di produzione.
Ridurre il TTL CNAME DNS al valore più basso possibile (ad esempio, 60-300 secondi) almeno 24 ore prima di apportare modifiche.
Pianificare una finestra di manutenzione durante periodi di traffico ridotto, se possibile.
È possibile preparare le procedure di rollback nel caso in cui si verifichino problemi.

Aggiornare il record CNAME DNS in modo che punti a Gestione traffico anziché direttamente a Frontdoor di Azure:

Campo	Valore precedente	Nuovo valore
Nome/Host	www	www (nessuna modifica)
Valore/Punti a	Nome host dell'endpoint Front Door di Azure	`$ATM_CDN_DNS_NAME.trafficmanager.net`

La propagazione DNS richiede in genere 5-10 minuti, ma può richiedere fino a 48 ore a livello globale.

Verificare la risoluzione del Traffic Manager. Attendere la propagazione DNS e quindi testare la connettività HTTPS.

# Verify Traffic Manager profile is resolving
nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"
# Expected result: Should return IP address of Azure Front Door endpoint

# Check DNS from different resolvers
nslookup $CUSTOM_DOMAIN 8.8.8.8    # Google DNS

# Test HTTPS connectivity
Invoke-WebRequest -Uri "https://$CUSTOM_DOMAIN/index.html" -Method Head
# Expected result: Status code 200

Dopo la transizione DNS, monitorare attivamente le seguenti metriche di Azure Front Door:
- Numero di richieste: il conteggio deve rimanere coerente, senza alcun calo del traffico.
- Tempo di risposta: il tempo deve rimanere entro intervalli normali.
- Frequenza di errore: gli errori 4xx/5xx non devono aumentare.
- Integrità dell'origine: l'integrità del back-end deve rimanere Online.

Passaggio 6: Testare le procedure di failover

Eseguire manualmente il failover nella rete CDN alternativa:

# Failover: Disable Azure Front Door and enable CDN
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

az network traffic-manager endpoint update `
    --name "endpoint-cdn-secondary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

# Verify endpoint status
az network traffic-manager profile show `
    --name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus, Target:target}"

# Flush local DNS cache and verify resolution
ipconfig /flushdns
nslookup "$ATM_CDN_DNS_NAME.trafficmanager.net"

# Test HTTPS access
curl --head https://$CUSTOM_DOMAIN/

Failback a Frontdoor di Azure:

# Failback: Enable Azure Front Door, disable CDN
az network traffic-manager endpoint update `
    --name "endpoint-afd-primary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Enabled

az network traffic-manager endpoint update `
    --name "endpoint-cdn-secondary" `
    --profile-name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --type externalEndpoints `
    --endpoint-status Disabled

# Verify
az network traffic-manager profile show `
    --name $ATM_CDN_PROFILE_NAME `
    --resource-group $RESOURCE_GROUP `
    --query "endpoints[].{Name:name, Status:endpointStatus, Health:endpointMonitorStatus}"

Monitoraggio

Importante

Configurare i monitoraggi sintetici per avvisare immediatamente gli errori. Questi avvisi devono attivare il failover manuale se il failover automatico non è sufficiente (ad esempio, problemi del dominio personalizzato di Azure Front Door che Traffic Manager non è in grado di rilevare).

È consigliabile usare le soluzioni di monitoraggio seguenti per gli ambienti di produzione:

Cartelle di lavoro di Azure Monitor: tenere traccia delle query di Traffic Manager, delle richieste di Azure Front Door e dell'integrità di Application Gateway. Per altre informazioni, vedere la panoramica delle cartelle di lavoro.
Monitoraggio esterno per rilevare i problemi globali di Frontdoor di Azure: implementare soluzioni di monitoraggio sintetico globali esterne (ad esempio Catchpoint o ThousandEyes) per monitorare gli endpoint. I servizi come WebPageTest offrono un'alternativa gratuita che offre visibilità globale limitata.
Test di disponibilità di Application Insights: usare controlli HTTP in più aree. Per altre informazioni, vedere Test di disponibilità di Application Insights.
Monitoraggio DNS: convalidare la catena di risoluzione CNAME e la propagazione TTL tramite DNSPerf, Pingdom o Uptime.com.
Monitoraggio dei certificati: usare il test del server SSL di Qualys SSL Labs per analizzare la configurazione del server.

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-02-19

Guida all'implementazione a disponibilità elevata per l'uso di Frontdoor di Azure e soluzioni di ingresso alternative

Principali differenze operative

Considerazioni per gli ambienti di produzione

Scenario 1: il failover di Gestione traffico da Frontdoor di Azure a un WAF del gateway applicazione

Pre-distribuzione: Azure Front Door vs Application Gateway

Differenze di funzionalità

Differenze di WAF

Recommendations

Passaggi chiave per l'implementazione

Passaggio 1: Configura i prerequisiti

Passaggio 2: Distribuire il gateway applicativo nella prima regione

Passaggio 3: Configurare le impostazioni dei criteri WAF (facoltativo)

Passaggio 4: Creare un'architettura di Traffic Manager per supportare gli endpoint WAF dell'Application Gateway

Passaggio 5: Aggiornare il CNAME DNS a Traffic Manager e verificare l'aggiornamento

Passaggio 6: Testare le procedure di failover

Scenario 2: failover di Gestione traffico da Frontdoor di Azure a una rete CDN alternativa

Passaggi chiave per l'implementazione

Passaggio 1: Configura i prerequisiti

Passaggio 2: Configurare una rete CDN alternativa

Passaggio 3: Creare un profilo di Gestione traffico

Passaggio 4: Configurare gli endpoint di Gestione traffico

Passaggio 5: Aggiornare il CNAME DNS a Traffic Manager e verificare l'aggiornamento

Passaggio 6: Testare le procedure di failover

Monitoraggio

Commenti e suggerimenti

Risorse aggiuntive