Distribuzione aziendale a disponibilità elevata con ambiente del servizio app

Le zone di disponibilità sono raccolte fisicamente separate di data center in una determinata area. La distribuzione di risorse tra zone garantisce che le interruzioni limitate a una zona non influiscano sulla disponibilità delle applicazioni. Questa architettura illustra come migliorare la resilienza di una distribuzione di ambiente del servizio app distribuendola in un'architettura con ridondanza della zona. Queste zone non sono correlate alla prossimità. Possono eseguire il mapping a posizioni fisiche diverse per sottoscrizioni diverse. L'architettura presuppone una distribuzione a sottoscrizione singola.

Quando si configura ambiente del servizio app come ridondante della zona, la piattaforma distribuisce automaticamente le istanze del piano di servizio app Azure in tre zone nell'area selezionata. Di conseguenza, il numero minimo di istanze del piano servizio app è sempre tre.

I servizi di Azure che supportano le zone di disponibilità possono essere zonali, ridondanti della zona o entrambi. I servizi di zona possono essere distribuiti in una zona specifica. I servizi con ridondanza della zona possono essere distribuiti automaticamente tra le zone. Per indicazioni dettagliate e consigli, vedere Supporto della zona di disponibilità. La versione precedente di ambiente del servizio app (v2) supporta solo le distribuzioni di zona, ma la versione corrente (v3) supporta le distribuzioni con ridondanza della zona.

Un'implementazione di riferimento per questa architettura è disponibile in GitHub.

Architettura

Scaricare un file di Visio di questa architettura.

Le risorse nelle subnet ambiente del servizio app in questa implementazione di riferimento sono identiche a quelle nell'architettura di distribuzione standard ambiente del servizio app. Questa implementazione di riferimento usa le funzionalità con ridondanza della zona di ambiente del servizio app v3 e cache di Azure per Redis per garantire una disponibilità più elevata. Si noti che l'ambito di questa architettura di riferimento è limitato a una singola area.

Flusso di lavoro

Questa sezione descrive la natura della disponibilità per i servizi usati in questa architettura:

• ambiente del servizio app v3 può essere configurato per la ridondanza della zona. È possibile configurare solo la ridondanza della zona durante la creazione del ambiente del servizio app e solo nelle aree che supportano tutte le dipendenze ambiente del servizio app v3. Ogni piano servizio app in un ambiente del servizio app con ridondanza della zona deve avere almeno tre istanze in modo che possano essere distribuite in tre zone. L'addebito minimo è per nove istanze. Per altre informazioni, vedere questo materiale sussidiario sui prezzi. Per indicazioni dettagliate e consigli, vedere ambiente del servizio app Supporto per zone di disponibilità.

• Azure Rete virtuale si estende su tutte le zone di disponibilità che si trovano in una singola area. Anche le subnet nella rete virtuale attraversano le zone di disponibilità. Per altre informazioni, vedere i requisiti di rete per ambiente del servizio app.

• gateway applicazione v2 è con ridondanza della zona. Analogamente alla rete virtuale, si estende su più zone di disponibilità per area. Di conseguenza, un singolo gateway applicazione è sufficiente per un sistema a disponibilità elevata, come illustrato nell'architettura di riferimento. L'architettura di riferimento usa lo SKU WAF di gateway applicazione, che offre una maggiore protezione da minacce e vulnerabilità comuni, in base a un'implementazione del set di regole di base (CRS) del progetto OWASP (Open Web Application Security Project). Per altre informazioni, vedere Ridimensionamento gateway applicazione v2 e WAF v2.

• Firewall di Azure supporta il supporto predefinito per la disponibilità elevata. Può attraversare più zone senza alcuna configurazione aggiuntiva.

  Se necessario, è anche possibile configurare una zona di disponibilità specifica quando si distribuisce il firewall. Per altre informazioni, vedere Firewall di Azure e zone di disponibilità. Questa configurazione non viene usata nell'architettura di riferimento.

• Microsoft Entra ID è un servizio globale a disponibilità elevata e altamente ridondante, che si estende su zone di disponibilità e aree geografiche. Per altre informazioni, vedere Avanzamento della disponibilità di Microsoft Entra.

• GitHub Actions offre funzionalità di integrazione continua e distribuzione continua (CI/CD) in questa architettura. Poiché ambiente del servizio app si trova nella rete virtuale, una macchina virtuale viene usata come jumpbox nella rete virtuale per distribuire le app nei piani di servizio app. L'azione compila le app all'esterno della rete virtuale. Per una maggiore sicurezza e connettività RDP/SSH senza problemi, è consigliabile usare Azure Bastion per il jumpbox.

• cache di Azure per Redis è un servizio con ridondanza della zona. Una cache con ridondanza della zona viene eseguita nelle macchine virtuali distribuite in più zone di disponibilità. Questo servizio offre maggiore resilienza e disponibilità.

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 Framework ben progettato di Microsoft Azure.

Disponibilità

Ambiente del servizio app

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

Quando si implementa la ridondanza della zona, la piattaforma distribuisce automaticamente le istanze del piano di servizio app in tre zone nell'area selezionata. Di conseguenza, il numero minimo di istanze del piano servizio app è sempre tre. Se si specifica una capacità maggiore di tre e il numero di istanze è divisibile per tre, le istanze vengono distribuite in modo uniforme. In caso contrario, tutte le istanze rimanenti vengono aggiunte alla zona rimanente o distribuite tra le due zone rimanenti.

• È possibile configurare le zone di disponibilità quando si crea il ambiente del servizio app.
• Tutti i piani servizio app creati in tale ambiente del servizio app richiedono almeno tre istanze. Saranno automaticamente ridondanti della zona.
• È possibile specificare le zone di disponibilità solo quando si crea un nuovo ambiente del servizio app. Non è possibile convertire un ambiente del servizio app preesistente per usare le zone di disponibilità.
• Le zone di disponibilità sono supportate solo in un subset di aree.

Per altre informazioni, vedere Eseguire la migrazione di ambiente del servizio app al supporto della zona di disponibilità.

Resilienza

Le applicazioni eseguite in ambiente del servizio app formano il pool back-end per gateway applicazione. Quando una richiesta all'applicazione proviene dalla rete Internet pubblica, il gateway inoltra la richiesta all'applicazione in esecuzione in ambiente del servizio app. Questa architettura di riferimento implementa i controlli di integrità all'interno del front-end Web principale, votingApp. Questo probe di integrità controlla se l'API Web e la cache Redis sono integre. È possibile visualizzare il codice che implementa questo probe in Startup.cs:

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

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

Il codice seguente illustra come lo script commands_ha.azcli configura i pool back-end e il probe di integrità per il gateway applicazione:

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

Se uno dei componenti (front-end Web, API o cache) non riesce il probe di integrità, gateway applicazione instrada la richiesta all'altra applicazione nel pool back-end. Questa configurazione garantisce che la richiesta venga sempre indirizzata all'applicazione in una subnet completamente disponibile ambiente del servizio app.

Il probe di integrità viene implementato anche nell'implementazione di riferimento standard. In questo caso, il gateway restituisce semplicemente un errore se il probe di integrità non riesce. Tuttavia, l'implementazione a disponibilità elevata migliora la resilienza dell'applicazione e la qualità dell'esperienza utente.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda la riduzione delle spese non necessarie e il miglioramento dell'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

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

Le differenze seguenti possono influire sul costo:

• Vengono addebitati almeno nove istanze di piano servizio app in un ambiente del servizio app con ridondanza della zona. Per altre informazioni, vedere prezzi ambiente del servizio app.
• cache di Azure per Redis è anche un servizio con ridondanza della zona. Una cache con ridondanza della zona viene eseguita in macchine virtuali distribuite in più zone di disponibilità per offrire resilienza e disponibilità più elevate.

Il compromesso per un sistema a disponibilità elevata, resiliente e altamente sicuro è aumentato il costo. Usare il calcolatore dei prezzi per valutare le esigenze in relazione ai prezzi.

Considerazioni sulla distribuzione

Questa implementazione di riferimento usa la stessa pipeline CI/CD a livello di produzione della distribuzione standard, con una sola macchina virtuale jumpbox. È tuttavia possibile decidere di usare un jumpbox per ognuna delle tre zone. Questa architettura usa un solo jumpbox perché il jumpbox non influisce sulla disponibilità dell'app. Il jumpbox viene usato solo per la distribuzione e il test.

Distribuire lo scenario

Per informazioni sulla distribuzione dell'implementazione di riferimento per questa architettura, vedere il file leggimi di GitHub. Usare lo script per la distribuzione a disponibilità elevata.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

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

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

Passaggi successivi

È possibile modificare questa architettura ridimensionando 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 del data center geografici più ampi, come quelli causati da terremoti o altre calamità naturali. Per altre informazioni sul ridimensionamento orizzontale, vedere Scalabilità distribuita geografica con ambiente del servizio app. Per una soluzione di routing globale e a disponibilità elevata, è consigliabile usare Frontdoor di Azure.