Modifica

Condividi tramite

Distribuire app Web usando Azure Red Hat OpenShift con ridondanza della zona

Azure Red Hat OpenShift
Azure Cosmos DB
Frontdoor di Azure

Questo articolo offre una panoramica completa di un carico di lavoro di app Web in Azure Red Hat OpenShift in una configurazione con ridondanza della zona. I servizi con ridondanza della zona replicano i servizi e i dati tra zone di disponibilità per proteggerli da singoli punti di errore e offrire disponibilità elevata.

Prima di creare un ambiente di produzione con Azure Red Hat OpenShift, leggere l'acceleratore di zona di destinazione di Azure Red Hat OpenShift.

Architettura

Diagramma che mostra l'architettura per un'applicazione Web con disponibilità elevata.

Scaricare un file di Visio di questa architettura.

Workflow

  • Un utente invia una richiesta ad Azure.
  • Frontdoor di Azure riceve la richiesta e instrada la richiesta a un'applicazione Web ospitata in Azure Red Hat OpenShift.
  • L'applicazione Web esegue la richiesta usando Azure Key Vault, Azure Cosmos DB e Registro Azure Container.
  • L'applicazione Web invia una risposta all'utente.

Componenti

  • Microsoft Entra ID o Azure AD B2C autentica gli utenti. In questa architettura, Microsoft Entra ID fornisce accesso sicuro e granulare alle risorse esterne.
  • Frontdoor di Azure è l'interfaccia pubblica per tutte le richieste Internet. Funge da proxy inverso HTTP globale e cache per i servizi back-end. Frontdoor di Azure migliora la sicurezza e le prestazioni di questa architettura, ad esempio l'aggiunta di protezione dagli attacchi DDoS (Distributed Denial of Service) di livello 4.
  • Azure Red Hat OpenShift è l'agente di orchestrazione contenitori basato su Kubernetes che ospita le applicazioni e i servizi API e fornisce un'interfaccia per i servizi back-end. Azure Red Hat OpenShift funge da piattaforma di calcolo primaria in questa architettura.
  • Registro Container supporta immagini di contenitori conformi a Docker e Open Container Initiative (OCI). Registro Container supporta la ridondanza della zona, che lo rende a disponibilità elevata e resiliente agli errori di zona. Supporta anche la replica geografica, che replica il servizio in più aree. In questa architettura Registro Container fornisce al cluster ARO l'accesso privato alle immagini del contenitore gestite in locale che fanno parte del carico di lavoro.
  • Azure Red Hat OpenShift usa l'integrazione della rete virtuale per connettersi ai servizi back-end tramite una rete virtuale privata. L'integrazione della rete virtuale offre una rete sicura con Azure Red Hat OpenShift e altri servizi di Azure in questa architettura.
  • Azure Cosmos DB fornisce database di documenti NoSQL per i servizi front-end. Azure Cosmos DB viene usato dal carico di lavoro in questa architettura per archiviare i dati utente.
  • Gli endpoint privati abilitano le connessioni ai servizi PaaS di Azure da reti virtuali private e consentono di disabilitare gli endpoint pubblici in questi servizi. In questa architettura, gli endpoint privati con integrazione della rete virtuale mantengono privato il traffico di rete da Azure Red Hat OpenShift durante la comunicazione con i servizi PaaS.
  • Azure DNS privato configura e aggiorna i record DNS richiesti dai servizi endpoint privati. In questa architettura, Azure DNS privato viene usato per la risoluzione dei nomi nelle reti private.
  • Key Vault archivia in modo sicuro segreti e certificati a cui si accede dai servizi di Azure. In questa architettura Azure Key Vault archivia in modo sicuro i segreti per le applicazioni in esecuzione in Azure Red Hat OpenShift.
  • Monitoraggio di Azure e Application Insights raccolgono i log del servizio e le metriche delle prestazioni dell'applicazione per l'osservabilità. In questa architettura Monitoraggio di Azure è la sincronizzazione dei log per i log della piattaforma e del carico di lavoro. Application Insights è specificamente per i log e le metriche provenienti dal codice del carico di lavoro.

Alternative

  • È consigliabile usare dns gestito da Azure, ma è possibile usare il proprio provider DNS.
  • È consigliabile usare app Azure lication Gateway invece di Frontdoor di Azure se la maggior parte degli utenti si trova vicino all'area di Azure che ospita il carico di lavoro e se non è necessaria la memorizzazione nella cache del contenuto. Usare Protezione DDoS di Azure per proteggere i servizi di gateway applicazione con connessione Internet.
  • Distribuire un'istanza premium di Azure Gestione API con ridondanza della zona come alternativa per l'hosting di API front-end, API back-end o entrambe. Per altre informazioni sulla ridondanza della zona Gestione API, vedere Eseguire la migrazione di Azure Gestione API al supporto della zona di disponibilità.
  • È possibile usare OpenShift Container Platform (OCP) o la distribuzione della community di origini di Kubernetes (OKD) in Azure Macchine virtuali anziché Azure Red Hat OpenShift. OCP o OKD sono alternative IaaS (Infrastructure-as-a-Service) a un servizio completamente gestito dalla piattaforma, ad esempio Azure Red Hat OpenShift. È consigliabile usare Azure set di scalabilità di macchine virtuali per la ridondanza della zona. Per altre informazioni, vedere Azure Red Hat OpenShift.

Dettagli dello scenario

Questa architettura descrive come comporre servizi con ridondanza della zona in una soluzione che offre disponibilità elevata ed è resiliente agli errori di zona.

Le zone di disponibilità sono posizioni fisiche separate in ogni area di Azure. Le zone di disponibilità distribuiscono una soluzione tra più zone indipendenti in un'area, che consente a un'applicazione di continuare a funzionare in caso di errore di una zona. Questa architettura si basa sull'infrastruttura delle zone di disponibilità disponibile in molte aree. Per un elenco delle aree che supportano le zone di disponibilità di Azure, vedere Aree di Azure con zone di disponibilità.

Quando le piattaforme di hosting sono su larga scala, spesso è difficile mantenerle a disponibilità elevata. La disponibilità elevata ha storicamente richiesto distribuzioni complesse e costose in più aree con coerenza dei dati e compromessi a prestazioni elevate. Le zone di disponibilità risolvono molti di questi problemi. La maggior parte dei servizi di Azure mainstream e molti servizi specializzati di Azure forniscono supporto per le zone di disponibilità. Tutti i servizi di Azure in questa architettura sono ridondanti della zona, semplificando la distribuzione e la gestione. Per altre informazioni, vedere Servizi di Azure che supportano le zone di disponibilità.

Per gestire i contratti di servizio, Azure Red Hat OpenShift con ridondanza della zona gestisce e attenua gli errori, inclusi gli errori di zona. La ridondanza della zona offre un tempo di ripristino pari a zero per l'errore di zona. Se una singola zona in un'area non è disponibile, non si perdono dati e il carico di lavoro continua a essere eseguito. La ridondanza della zona è configurata in fase di distribuzione ed è gestita dai servizi, quindi non è necessario gestire l'aggiunta della zona o le distribuzioni di zona.

In questa architettura, un cluster Azure Red Hat OpenShift viene distribuito in tre zone di disponibilità nelle aree di Azure che le supportano. Un cluster è costituito da tre nodi del piano di controllo e tre o più nodi di lavoro. Per migliorare la ridondanza, i nodi vengono distribuiti tra le zone.

Frontdoor di Azure, MICROSOFT Entra ID e DNS di Azure sono servizi disponibili a livello globale resilienti alle interruzioni a livello di zona e a livello di area. Tutti gli altri servizi in questa architettura sono con ridondanza della zona.

Potenziali casi d'uso

Azure Red Hat OpenShift è un servizio di orchestrazione dei contenitori che usa Kubernetes. È adatto per molti casi d'uso, ad esempio:

  • Dati bancari
  • Trading azionario
  • e-commerce
  • Social media
  • Applicazioni Web
  • Applicazioni per dispositivi mobili
  • Applicazioni di elaborazione batch
  • Streaming multimediale
  • Carichi di lavoro di Machine Learning

Consigli

Le raccomandazioni seguenti si applicano alla maggior parte degli scenari.

Frontdoor di Azure

  • Usare i certificati gestiti da Azure in tutte le applicazioni front-end per evitare problemi di configurazione e scadenza del certificato.
  • Abilitare la memorizzazione nella cache nelle route per migliorare la disponibilità. La cache di Frontdoor di Azure distribuisce il contenuto dinamico e il contenuto statico ai nodi perimetrali POP (Point of Presence) di Azure. La memorizzazione nella cache riduce il carico nei server di origine e migliora le prestazioni.
  • Distribuire Frontdoor di Azure Premium e configurare un criterio web application firewall (WAF) con un set di regole gestito da Microsoft. Applicare il criterio a tutti i domini personalizzati. Usare la modalità di prevenzione per attenuare gli attacchi Web che potrebbero causare un errore del servizio di origine.

Azure Red Hat OpenShift

  • Assicurarsi che l'area di Azure in cui sia distribuito Azure Red Hat OpenShift supporti le zone di disponibilità. Per altre informazioni, vedere Aree di Azure con supporto per la zona di disponibilità.
  • Un cluster Azure Red Hat OpenShift dipende da alcuni servizi. Assicurarsi che tali servizi supportino e siano configurati per la ridondanza della zona. Per altre informazioni, vedere Servizi di Azure con supporto per la zona di disponibilità.
  • Rimuovere lo stato dai contenitori e usare invece i servizi di archiviazione o di database di Azure.
  • Configurare più repliche nelle distribuzioni con una configurazione del budget di interruzione appropriata per fornire continuamente il servizio applicazioni nonostante le interruzioni, ad esempio gli errori hardware nelle zone.
  • Proteggere l'accesso ad Azure Red Hat OpenShift. Per assicurarsi che le richieste non possano ignorare il WAF frontdoor di Azure, consentire solo il traffico frontdoor di Azure. Per altre informazioni sulla limitazione dell'accesso a un'istanza specifica di Frontdoor di Azure, vedere Proteggere l'accesso ad Azure Red Hat OpenShift con Frontdoor di Azure.

Registro Container

Per altre informazioni, vedere Abilitare la ridondanza della zona in Registro Container per la resilienza e la disponibilità elevata e Usare Registro Container con Azure Red Hat OpenShift.

Azure Cosmos DB

Insieme di credenziali delle chiavi di

Key Vault è con ridondanza della zona in qualsiasi area in cui sono disponibili le zone di disponibilità. In questa architettura, Key Vault viene distribuito con un endpoint privato abilitato e un endpoint pubblico disabilitato. Per altre informazioni sugli endpoint privati per Key Vault, vedere Integrare Key Vault con collegamento privato.

Zone DNS di Azure private

Per semplificare la gestione DNS, integrare endpoint privati con zone DNS di Azure private. Per altre informazioni, vedere Configurazione DNS dell'endpoint privato di Azure.

Considerazioni

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

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Questa architettura garantisce l'affidabilità fornendo funzionalità di disponibilità, resilienza e servizi globali affidabili.

Disponibilità

Quando l'infrastruttura della zona di disponibilità viene implementata correttamente, questa architettura offre un'eccellente disponibilità per un costo inferiore e un sovraccarico operativo inferiore rispetto ad altre soluzioni. Questa architettura riduce il rischio di un errore di zona in un'area di Azure perché i servizi con ridondanza della zona sono in grado di resistere all'errore pur operando all'interno del contratto di servizio definito.

Gli errori a livello di area sono improbabili ma possibili. In un errore a livello di area i servizi non sono disponibili in tutte le zone di disponibilità all'interno di un'area. Combinare questa architettura con ridondanza della zona con un'architettura in più aree per ridurre il rischio di errore dell'area. Pianificare l'architettura in più aree per ridurre il tempo di ripristino se un'intera area non è disponibile.

Le progettazioni in più aree sono più complesse e spesso più costose rispetto alle progettazioni a più zone in una singola area, ma le progettazioni in più aree offrono un'opportunità per ottimizzare ulteriormente la disponibilità e l'affidabilità complessiva.

Nota

Eseguire una valutazione dei rischi per determinare se la soluzione richiede un'architettura in più aree.

Resilienza

Le progettazioni a più zone basate sulle zone di disponibilità offrono disponibilità e resilienza che soddisfano o superano i requisiti aziendali della maggior parte delle organizzazioni. Tuttavia, se si vuole replicare i dati in un'area secondaria per il ripristino di emergenza, le opzioni variano a seconda dei servizi di Azure usati.

Ad esempio, Archiviazione di Azure supporta la replica di oggetti per i BLOB in blocchi. I servizi dati di Azure, ad esempio Azure Cosmos DB, offrono la replica dei dati in altre aree di Azure con backup continuo. È possibile usare queste funzionalità per ripristinare la soluzione in caso di emergenza. Per altre informazioni, vedere Backup continuo con ripristino temporizzato in Azure Cosmos DB.

Servizi globali

Gli errori nei servizi globali, ad esempio Frontdoor di Azure e Microsoft Entra ID, sono rari, ma l'effetto di un errore può essere elevato. Per migliorare il ripristino in caso di errore, preparare e ripetere i runbook.

Ad esempio, è possibile ridurre i tempi di inattività di Frontdoor di Azure usando un runbook per distribuire app Azure lication Gateway e modificare i record DNS per reindirizzare il traffico fino al ripristino di Frontdoor di Azure.

Per altre informazioni, vedere Creazione di resilienza nell'infrastruttura di gestione delle identità e degli accessi.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

  • Valutare la possibilità di distribuire un cluster privato.
  • Usare gli endpoint privati nei servizi di Azure a cui non si accede dalla rete Internet pubblica.
  • Per impostazione predefinita, tutte le comunicazioni da servizio a servizio in Azure sono crittografate tls (Transport Layer Security). Configurare Frontdoor di Azure per accettare solo il traffico HTTPS e impostare la versione minima di TLS.
  • Le identità gestite autenticano la comunicazione da servizio a servizio di Azure in cui è disponibile. Per altre informazioni, vedere Informazioni sulle identità gestite per le risorse di Azure
  • Per gestire e proteggere segreti, certificati e stringa di connessione nel cluster, connettere il cluster Azure Red Hat OpenShift a Kubernetes abilitato per Azure Arc. Usare l'estensione Del provider di segreti dell'insieme di credenziali delle chiavi per recuperare i segreti.
  • Configurare Microsoft Defender per contenitori per garantire la sicurezza per cluster, contenitori e applicazioni. Defender per contenitori è supportato tramite Kubernetes abilitato per Azure Arc. Analizzare le immagini per individuare le vulnerabilità con Microsoft Defender o un'altra soluzione di analisi delle immagini.
  • Configurare l'integrazione di Microsoft Entra per usare Microsoft Entra ID per autenticare gli utenti (ad esempio, SRE, SecOps o sviluppatori di applicazioni) nel cluster Azure Red Hat OpenShift.

Ottimizzazione costi

L'ottimizzazione dei costi consiste nell'esaminare i 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 architetture con ridondanza della zona sono meno costose delle alternative in più aree perché i servizi vengono distribuiti in una singola area. Tuttavia, esistono diverse implicazioni in termini di costi da tenere presenti:

  • Alcuni servizi richiedono la distribuzione di un numero minimo di istanze o repliche per ottenere la ridondanza della zona.
  • L'archiviazione con ridondanza della zona e l'archiviazione con ridondanza locale hanno prezzi diversi. Per altre informazioni, vedere Prezzi di archiviazione.
  • Gli endpoint privati sono principalmente disponibili in SKU del servizio Di Azure Premium. Gli endpoint privati comportano addebiti orari e addebiti per la larghezza di banda. Per altre informazioni, vedere prezzi collegamento privato.

Ottimizzare i costi riservando le risorse in anticipo. Molti servizi in questa architettura sono idonei per i prezzi di capacità riservata. Per altre informazioni, vedere Prenotazioni.

Usare il calcolatore dei prezzi di Azure per stimare i costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Tutti i servizi di Azure piattaforma distribuita come servizio (PaaS) sono integrati con Monitoraggio di Azure. Seguire le procedure consigliate di Monitoraggio di Azure (affidabilità, sicurezza, ottimizzazione dei costi, eccellenza operativa ed efficienza delle prestazioni) per:

  • Creare un modello di integrità per quantificare l'integrità delle applicazioni nel contesto dei requisiti aziendali.
  • Configurare la quantità corretta di raccolta dati di log.
  • Creare dashboard di Azure per unificare i dati in un'unica visualizzazione per i team operativi.
  • Creare una strategia di avviso riuscita.
  • Integrare Application Insights nelle app per tenere traccia delle metriche delle prestazioni dell'applicazione.
  • Per fornire notifiche quando è necessaria un'azione diretta, usare un sistema di avvisi, ad esempio avvisi delle metriche di Informazioni dettagliate contenitore o l'interfaccia utente di avviso di Azure Red Hat OpenShift.
  • Prendere in considerazione vari metodi per il monitoraggio e la registrazione di Azure Red Hat OpenShift per ottenere informazioni dettagliate sull'integrità delle risorse e prevedere potenziali problemi.
  • Esaminare la matrice di responsabilità di Azure Red Hat OpenShift per comprendere in che modo Microsoft, Red Hat e i clienti condividono le responsabilità per i cluster.
  • Automatizzare le distribuzioni di servizi con Bicep, un linguaggio modello per la distribuzione dell'infrastruttura come codice (IaC). Poiché i servizi di Azure in questa architettura hanno endpoint privati, non è possibile usare agenti ospitati da Microsoft di Azure Pipelines o strumenti di esecuzione ospitati in GitHub. Usare soluzioni come agenti self-hosted di Azure Pipelines o strumenti di esecuzione ospitati in GitHub.
  • Convalidare continuamente il carico di lavoro per testare le prestazioni e la resilienza dell'intera soluzione usando servizi, ad esempio Test di carico di Azure e Azure Chaos Studio.

Efficienza delle prestazioni

L'efficienza delle prestazioni è la capacità del carico di lavoro di ridimensionarsi per soddisfare le esigenze poste dagli utenti in modo efficiente. Per altre informazioni, vedere Elenco di controllo per l'efficienza delle prestazioni.

  • Memorizzare nella cache gli asset in Frontdoor di Azure per distribuire i carichi di lavoro nelle posizioni perimetrali.
  • Esaminare i limiti e le quote delle sottoscrizioni per assicurarsi che i servizi vengano ridimensionati per la domanda.
  • Monitorare le prestazioni dell'applicazione usando Application Insights.
  • Carichi di lavoro di test delle prestazioni per misurare qualsiasi latenza causata da connessioni tra zone.
  • Scegliere le dimensioni appropriate delle macchine virtuali per i carichi di lavoro. Scegliere una dimensione sufficientemente grande per ottenere i vantaggi di una maggiore densità, ma non così grande che il cluster non possa gestire il carico di lavoro di un nodo con errori.
  • Usare le richieste e i limiti dei pod per gestire le risorse di calcolo all'interno di un cluster. Le richieste e i limiti dei pod informano l'utilità di pianificazione kubernetes, che assegna le risorse di calcolo a un pod. Limitare l'utilizzo delle risorse in un progetto usando intervalli di limiti.
  • Definire le richieste e i limiti delle risorse dei pod nei manifesti della distribuzione dell'applicazione e applicarli con Criteri di Azure.
  • Ottimizzare i valori delle richieste di CPU e memoria e ottimizzare l'efficienza delle risorse del cluster usando l'utilità di scalabilità automatica verticale dei pod.
  • Ridimensionare i pod per soddisfare la domanda usando l'utilità di scalabilità automatica orizzontale dei pod.
  • Definire ClusterAutoScaler e MachineAutoScaler per ridimensionare i computer quando il cluster esaurisce le risorse per supportare più distribuzioni.

Distribuire lo scenario

Per distribuire questa architettura, vedere l'acceleratore di zona di destinazione di Azure Red Hat OpenShift e il repository GitHub associato.

Collaboratori

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

Autori principali:

Altri contributori:

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

Passaggi successivi