Distribuzione aziendale ad alta disponibilità che utilizza ambiente del servizio app.

Le zone di disponibilità sono raccolte fisicamente separate di data center in un'area specifica. È possibile distribuire le risorse tra le zone per assicurarsi che le interruzioni limitate a una zona non influiscano sulla disponibilità delle applicazioni. Questa architettura descrive come migliorare la resilienza di una distribuzione dell'ambiente del servizio App distribuendola in un'architettura a zone ridondanti. Queste zone non sono correlate alla prossimità. Possono essere associati a posizioni fisiche diverse per sottoscrizioni diverse. L'architettura presuppone una distribuzione a sottoscrizione singola.

I servizi di Azure che supportano le zone di disponibilità possono essere zonali, a ridondanza di zona o entrambi. È possibile distribuire servizi di zona in una zona specifica ed è possibile distribuire automaticamente i servizi con ridondanza della zona tra zone. Per altre informazioni, vedere Tipi di supporto delle zone di disponibilità. L'ambiente del servizio app supporta le distribuzioni con ridondanza della zona.

Quando si configura un ambiente del servizio app per la ridondanza della zona, la piattaforma distribuisce automaticamente le istanze del piano di Servizio app di Azure tra le zone disponibili nell'area selezionata. Un piano con ridondanza della zona usa almeno due zone e richiede almeno due istanze. Il numero di zone disponibili per un piano varia in base all'area.

Architecture

Scaricare un file di Visio di questa architettura.

Le risorse nelle subnet ambiente del servizio app in questa architettura corrispondono alle risorse nell'architettura di distribuzione ambiente del servizio app standard. Questa architettura utilizza le funzionalità di ridondanza della zona di ambiente del servizio app v3 e di Azure Managed Redis per garantire una maggiore disponibilità. L'ambito di questa architettura di riferimento è limitato a una singola area.

Components

• Ambiente del servizio app v3 è un'opzione di hosting isolata e ad alte prestazioni che supporta la ridondanza di zona. Nelle aree che supportano la ridondanza della zona è possibile configurare la ridondanza della zona in qualsiasi momento durante il ciclo di vita di un ambiente del servizio app. Ogni piano di servizio app in un ambiente del servizio app con ridondanza della zona deve includere almeno due istanze per garantire la distribuzione in due o più zone. È possibile combinare piani a ridondanza di zona e piani senza ridondanza di zona all'interno dello stesso ambiente del servizio app. Per configurare un piano con una sola istanza, disabilitare innanzitutto la ridondanza della zona per tale piano. La ridondanza di zona non comporta costi aggiuntivi. Si paga solo per le istanze isolate v2 in uso. Per altre informazioni, vedere Prezzi di ambiente del servizio app e Affidabilità in ambiente del servizio app. In questa architettura, l'ambiente del servizio app v3 offre una piattaforma di hosting isolata e ad alte prestazioni per app Web, API e funzioni.

• Rete virtuale di Azure è una rete basata su IP di livello 3 che si estende su tutte le zone di disponibilità all'interno di una singola area. Le subnet nella rete virtuale si estendono anche tra le zone di disponibilità. Per altre informazioni, vedere Requisiti di rete per l'ambiente del servizio app e affidabilità nella rete virtuale. In questa architettura, la rete virtuale offre una rete sicura e isolata per tutte le risorse.

• gateway applicazione di Azure v2 è un servizio di bilanciamento del carico del traffico Web nativo del cloud che supporta la ridondanza tra zone. In questa architettura si estende su più zone di disponibilità in ogni regione. Di conseguenza, un singolo gateway applicativo offre alta disponibilità, come illustrato nell'architettura di riferimento. L'architettura di riferimento utilizza lo SKU del Web application firewall di Application Gateway, che fornisce una maggiore protezione contro minacce e vulnerabilità comuni. Questa protezione si basa su un'implementazione del set di regole di base (CRS) del progetto OWASP (Open Web Application Security Project). Per altre informazioni, vedere Affidabilità nel Gateway Applicazione v2. Il gateway applicativo v2 funge da servizio di bilanciamento del carico del traffico web a ridondanza di zona.

• Firewall di Azure è un servizio di sicurezza di rete gestito nativo del cloud che include il supporto predefinito per la disponibilità elevata. Può usare più zone senza configurazione aggiuntiva. In questa architettura Firewall di Azure offre sicurezza di rete a disponibilità elevata gestita per controllare e monitorare il traffico in uscita per le risorse nella rete virtuale.

  È anche possibile configurare una zona di disponibilità specifica quando si distribuisce il firewall. Per altre informazioni, vedere Supporto della zona di disponibilità di Firewall di Azure. L'architettura di riferimento non usa questa configurazione.

• Microsoft Entra ID è un servizio globale a disponibilità elevata e altamente ridondante che si estende su zone e aree di disponibilità. Per altre informazioni, vedere Advance Microsoft Entra ID availability. In questa architettura, Microsoft Entra ID offre servizi di gestione delle identità e degli accessi a disponibilità elevata e ridondanti per l'autenticazione e l'autorizzazione in tutti i componenti.

• GitHub Actions è una piattaforma di automazione che supporta l'integrazione continua e le funzionalità di distribuzione continua (CI/CD). In questa architettura GitHub Actions compila le app all'esterno della rete virtuale e le distribuisce nei piani di servizio app ospitati in un ambiente del servizio app.

L'ambiente del servizio app risiede nella rete virtuale, quindi una macchina virtuale (VM) funge da "jump box" nella rete virtuale per facilitare la distribuzione. Per una maggiore sicurezza e connettività RDP (Desktop remoto Protocol) e Secure Shell (SSH), prendere in considerazione l'uso di Azure Bastion per il jump box.

• Redis gestito di Azure è un servizio a ridondanza di zona. Una cache con ridondanza della zona viene eseguita nelle macchine virtuali distribuite in più zone di disponibilità. In questa architettura, Azure Managed Redis offre resilienza e disponibilità più elevate.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Jump box

Questa architettura usa la stessa pipeline CI/CD a livello di produzione della distribuzione standard, con una sola macchina virtuale jump box. Ma è possibile usare un jump box per ognuna delle tre zone. Questa architettura usa un solo jump box perché la jump box non influisce sulla disponibilità dell'app. La jump box supporta il deployment e il testing.

Ambiente del servizio app

È possibile distribuire l'ambiente del servizio app tra zone di disponibilità per offrire resilienza e affidabilità per carichi di lavoro critici per l'azienda. Questa configurazione è nota anche come ridondanza della zona.

Quando si abilita la ridondanza della zona in un piano di servizio app, la piattaforma distribuisce automaticamente le istanze in due o più zone nell'area selezionata. Un piano con ridondanza della zona richiede almeno due istanze.

• È possibile configurare le zone di disponibilità quando si crea l'ambiente del servizio app o in qualsiasi momento del ciclo di vita dell'ambiente.

• Tutti i piani di servizio di app creati nell'ambiente del Servizio App richiedono almeno due istanze per abilitare la ridondanza della zona. Se l'ambiente è ridondante a zona, si possono abilitare e disabilitare selettivamente la ridondanza a zona per i piani di App Service individuali. Per ridimensionare un piano di servizio app in una singola istanza, disabilitare la ridondanza della zona per tale piano, quindi procedere con l'operazione di ridimensionamento.

• Solo un sottoinsieme di regioni supporta le zone di disponibilità.

• Effettuare il provisioning di istanze sufficienti per il piano per gestire il carico previsto in caso di errore di una zona di disponibilità. La piattaforma usa il bilanciamento ottimale della zona, quindi i conteggi delle istanze potrebbero non essere distribuiti uniformemente tra le zone. Un'interruzione della zona può influire anche sulle operazioni non in fase di esecuzione, tra cui scalabilità, creazione di app, configurazione e pubblicazione.

Per altre informazioni, vedere Reliability in ambiente del servizio app.

Resiliency

Le applicazioni eseguite nell'ambiente del Servizio App formano il pool back-end per il gateway dell'applicazione. Quando una richiesta all'applicazione proviene dalla rete Internet pubblica, il gateway inoltra la richiesta all'applicazione eseguita nell'ambiente del servizio app. È possibile implementare i controlli di integrità nell'applicazione ed è possibile implementare probe di integrità per controllare l'integrità delle risorse dipendenti, ad esempio le cache. Per aggiungere un controllo integrità in un'applicazione C#, usare codice simile al seguente:

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

Se una destinazione non riesce il probe di integrità, il gateway applicazione contrassegna la destinazione come non integra e arresta il routing delle richieste. Se tutte le destinazioni nel pool back-end non sono integre, il gateway applicazione restituisce una risposta HTTP 502. Uno stato Sconosciuto nel report sull'integrità back-end indica che il piano di controllo non è in grado di determinare l'integrità della destinazione e non significa necessariamente che il gateway applicazione ha arrestato il traffico di routing. I probe di integrità rilevano gli errori, ma non forniscono un'altra applicazione o ambiente del servizio app per il failover.

La ridondanza della zona migliora la resilienza a un errore della zona di disponibilità distribuendo le istanze del piano di servizio app tra zone. Non protegge da un'interruzione a livello di area o da errori che influiscono su ogni istanza, ad esempio un difetto dell'applicazione o una dipendenza non disponibile. Per la protezione da interruzioni a livello di area, distribuire il carico di lavoro in più aree e usare un servizio di bilanciamento del carico globale per instradare il traffico a una distribuzione a livello di area integra. Per altre informazioni, vedere Architetture a più aree per Servizio app di Azure ripristino di emergenza.

Azure Redis gestito

Configurare Azure Redis gestito per la disponibilità elevata in modo che distribuisca almeno due nodi tra zone di disponibilità. Durante un errore di zona, Azure Redis gestito reindirizza automaticamente il traffico a nodi integri. Il failover potrebbe causare da 10 a 15 secondi di tempo di inattività e i dati che non sono stati replicati in un'altra zona potrebbero andare persi. Le applicazioni devono ripetere gli errori temporanei e usare il modello diCache-Aside in modo che possano eseguire il fallback all'archivio dati primario quando la cache non è disponibile. Per altre informazioni, vedere Affidabilità in Azure Managed Redis.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Le considerazioni sui costi per l'architettura a disponibilità elevata sono simili all'architettura standard.

Le differenze seguenti possono influire sul costo:

• Il supporto della zona di disponibilità non comporta costi aggiuntivi. Si paga solo per le istanze usate. Per ulteriori informazioni, consultare la sezione dei prezzi per l'ambiente del servizio app.

• Azure Redis gestito diventa un servizio a ridondanza di zona nelle aree con più zone di disponibilità quando la disponibilità elevata è abilitata. Una cache a ridondanza di zona viene eseguita su nodi distribuiti in più zone di disponibilità all'interno di una regione per garantire una maggiore resilienza e disponibilità. Per altre informazioni, vedere Affidabilità in Azure Managed Redis.

Il compromesso per un sistema a disponibilità elevata, resiliente e altamente sicura include un aumento dei costi per alcuni servizi di Azure. Esaminare la stima dei costi di esempio per questa architettura e modificare i livelli di servizio e i presupposti di utilizzo in modo che corrispondano al carico di lavoro.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Deep Bhattacharya | Cloud Solution Architect
• Suhas Rao | Cloud Solution Architect

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Per modificare questa architettura, è possibile ridimensionare orizzontalmente le applicazioni all'interno della stessa area o in più aree, in base alla capacità di carico massima prevista. La replica delle applicazioni in più aree può contribuire a ridurre i rischi di errori di data center geografici più ampi, ad esempio gli errori causati da terremoti o altre calamità naturali.

• Per ulteriori informazioni sul ridimensionamento orizzontale, vedere Scalabilità geografica distribuita con ambiente del servizio app.
• Per una soluzione di routing globale e a disponibilità elevata, è consigliabile usare Frontdoor di Azure.