Distribuzione aziendale a disponibilità elevata con App Service Environment

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 App Service Environment 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 App Service Environment in modo che sia ridondante della zona, la piattaforma distribuisce automaticamente le istanze del piano di Служба приложений Azure in tre zone nell'area selezionata. Pertanto, il numero minimo di istanze del piano di Serviço de Aplicativo è sempre tre.

I servizi di Azure che supportano le zone di disponibilità possono essere di zona, ridondanza 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 App Service Environment (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 App Service Environment in questa implementazione di riferimento sono identiche a quelle nell'architettura di distribuzione App Service Environment standard. Questa implementazione di riferimento usa le funzionalità con ridondanza della zona di App Service Environment v3 e Azure Cache for 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:

• App Service Environment v3 può essere configurato per la ridondanza della zona. È possibile configurare la ridondanza della zona solo durante la creazione del App Service Environment e solo nelle aree che supportano tutte le dipendenze App Service Environment v3. Ogni piano Serviço de Aplicativo in un App Service Environment 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 App Service Environment Supporto per Strefy dostępności.

• Azure Virtual Network 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 App Service Environment.

• Application Gateway v2 è con ridondanza della zona. Analogamente alla rete virtuale, si estende su più zone di disponibilità per area. Pertanto, 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 Application Gateway, 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 Application Gateway v2 e WAF v2.

• Azure Firewall include 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 Azure Firewall e Strefy dostępności. Questa configurazione non viene usata nell'architettura di riferimento.

• Azure Active Directory è un servizio globale a disponibilità elevata e con ridondanza elevata, che si estende su zone e aree di disponibilità. Per altre informazioni, vedere Avanzamento della disponibilità di Azure Active Directory.

• GitHub Actions offre funzionalità di integrazione continua e distribuzione continua (CI/CD) in questa architettura. Poiché App Service Environment si trova nella rete virtuale, una macchina virtuale viene usata come jumpbox nella rete virtuale per distribuire le app nei piani di Serviço de Aplicativo. L'azione compila le app all'esterno della rete virtuale. Per una sicurezza avanzata e una connettività RDP/SSH senza problemi, prendere in considerazione l'uso di Azure Bastion per il jumpbox.

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

Considerazioni

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

Disponibilità

Ambiente del servizio app

È possibile distribuire App Service Environment 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 Serviço de Aplicativo tra tre zone nell'area selezionata. Pertanto, il numero minimo di istanze del piano di Serviço de Aplicativo è 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.

• Le zone di disponibilità vengono configurate quando si crea il App Service Environment.
• Tutti i piani Serviço de Aplicativo creati in tale App Service Environment richiedono almeno tre istanze. Verranno automaticamente ridondanti nella zona.
• È possibile specificare le zone di disponibilità solo quando si crea un nuovo App Service Environment. Non è possibile convertire un App Service Environment 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 App Service Environment al supporto della zona di disponibilità.

Resilienza

Le applicazioni eseguite in App Service Environment formano il pool back-end per Application Gateway. Quando una richiesta all'applicazione proviene dalla rete Internet pubblica, il gateway inoltra la richiesta all'applicazione in esecuzione in App Service Environment. 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) ha esito negativo, Application Gateway instrada la richiesta all'altra applicazione nel pool back-end. Questa configurazione garantisce che la richiesta venga sempre instradata all'applicazione in una subnet App Service Environment completamente disponibile.

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à ha esito negativo. 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 del piano Serviço de Aplicativo in un App Service Environment con ridondanza della zona. Per altre informazioni, vedere prezzi di App Service Environment.
• Azure Cache for Redis è anche un servizio con ridondanza della zona. Una cache con ridondanza della zona viene eseguita nelle macchine virtuali distribuite tra più zone di disponibilità per offrire maggiore resilienza e disponibilità.

Il compromesso per un sistema a disponibilità elevata, resiliente e altamente sicuro è aumentato. 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 solo un 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 readme di GitHub. Usare lo script per la distribuzione a disponibilità elevata.

Autori di contributi

Questo articolo viene gestito da Microsoft. È stato originariamente scritto dai collaboratori seguenti.

Autori principali:

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

Per visualizzare profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

È possibile modificare questa architettura ridimensionando orizzontalmente le applicazioni, all'interno della stessa area o in diverse aree, in base alla capacità di carico massima prevista. La replica delle applicazioni in più aree potrebbe contribuire a ridurre i rischi di errori geografici più vasti, ad esempio quelli causati da terremoti o altre calamità naturali. Per altre informazioni sulla scalabilità orizzontale, vedere Scalabilità distribuita geografica con ambienti Serviço de Aplicativo. Per una soluzione di routing globale e a disponibilità elevata, è consigliabile usare Frontdoor di Azure.