Modello di architettura per carichi di lavoro cruciali in Azure

Questo articolo presenta un modello chiave per le architetture cruciali in Azure. Applicare questo modello all'avvio del processo di progettazione e quindi selezionare i componenti più adatti ai requisiti aziendali. L'articolo consiglia un approccio di progettazione a nord star e include altri esempi con componenti tecnologici comuni.

È consigliabile valutare le aree di progettazione chiave, definire i flussi utente e di sistema critici che usano i componenti sottostanti e sviluppare una matrice di risorse di Azure e la relativa configurazione tenendo presenti le caratteristiche seguenti.

Caratteristica	Considerazioni
Durata	Qual è la durata prevista della risorsa, rispetto ad altre risorse nella soluzione? La risorsa deve durare più a lungo o condividere la durata con l'intero sistema o l'area oppure deve essere temporanea?
State	Quale impatto avrà lo stato persistente a questo livello sull'affidabilità o sulla gestibilità?
Copertura	La risorsa deve essere distribuita a livello globale? La risorsa può comunicare con altre risorse, che si trova a livello globale o all'interno di tale area?
Dependencies	Quali sono le dipendenze da altre risorse?
Limiti di scalabilità	Qual è la velocità effettiva prevista per tale risorsa? Quanta scalabilità viene fornita dalla risorsa per soddisfare tale domanda?
Disponibilità/ripristino di emergenza	Qual è l'impatto sulla disponibilità da un'emergenza a questo livello? Causerebbe un'interruzione sistemica o solo una capacità localizzata o un problema di disponibilità?

Importante

Questo articolo fa parte della serie di carichi di lavoro cruciali di Azure Well-Architected . Se non si ha familiarità con questa serie, è consigliabile iniziare con che cos'è un carico di lavoro mission-critical?

Modello di architettura principale

Risorse globali

Alcune risorse vengono condivise a livello globale dalle risorse distribuite all'interno di ogni area. Esempi comuni sono le risorse usate per distribuire il traffico tra più aree, archiviare lo stato permanente per l'intera applicazione e monitorare le risorse.

Caratteristica	Considerazioni
Durata	Si prevede che queste risorse siano di lunga durata (non temporanee). La loro durata si estende alla vita del sistema o più a lungo. Spesso le risorse vengono gestite con aggiornamenti del piano di controllo e dati sul posto, presupponendo che supportino operazioni di aggiornamento senza tempi di inattività.
State	Poiché queste risorse esistono per almeno la durata del sistema, questo livello è spesso responsabile dell'archiviazione dello stato globale e con replica geografica.
Copertura	Le risorse devono essere distribuite a livello globale e replicate nelle aree che ospitano tali risorse. È consigliabile che queste risorse comunichino con risorse a livello di area o con una bassa latenza e la coerenza desiderata.
Dependencies	Le risorse devono evitare dipendenze dalle risorse a livello di area perché la mancata disponibilità può essere causa di un errore globale. Ad esempio, i certificati o i segreti conservati in un singolo insieme di credenziali potrebbero avere un impatto globale se si verifica un errore a livello di area in cui si trova l'insieme di credenziali.
Limiti di scalabilità	Spesso queste risorse sono istanze singleton nel sistema e devono essere in grado di ridimensionare in modo che possano gestire la velocità effettiva del sistema nel suo complesso.
Disponibilità/ripristino di emergenza	Le risorse a livello di area e stamp possono usare risorse globali. È fondamentale che le risorse globali siano configurate con disponibilità elevata e ripristino di emergenza per l'integrità dell'intero sistema.

Risorse di stamp a livello di area

Il timbro contiene l'applicazione e le risorse che partecipano al completamento delle transazioni aziendali. Un timbro corrisponde in genere a una distribuzione in un'area di Azure. Anche se un'area può avere più di un timbro.

Caratteristica	Considerazioni
Durata	Si prevede che le risorse abbiano un breve intervallo di vita (temporaneo) con la finalità che possono essere aggiunte e rimosse in modo dinamico, mentre le risorse a livello di area al di fuori dello stamp continuano a essere persistenti. La natura temporanea è necessaria per offrire maggiore resilienza, scalabilità e prossimità agli utenti.
State	Poiché i francobolli sono temporanei e verranno eliminati definitivamente con ogni distribuzione, un timbro deve essere senza stato il più possibile.
Copertura	Può comunicare con risorse internazionali e globali. Tuttavia, è consigliabile evitare la comunicazione con altre aree o altri francobolli.
Dependencies	Le risorse stamp devono essere indipendenti. Si prevede che abbiano dipendenze internazionali e globali, ma non devono basarsi su componenti in altri francobolli nella stessa area o in altre aree.
Limiti di scalabilità	La velocità effettiva viene stabilita tramite test. La velocità effettiva del timbro complessivo è limitata alla risorsa meno efficiente. La velocità effettiva stamp deve stimare l'elevato livello di domanda causato da un failover a un altro stamp.
Disponibilità/ripristino di emergenza	A causa della natura temporanea dei francobolli, il ripristino di emergenza viene eseguito ridistribuendo il timbro. Se le risorse si trovano in uno stato non integro, il timbro, nel suo complesso, può essere eliminato e ridistribuibile.

Risorse a livello di area

Un sistema può disporre di risorse distribuite nell'area, ma con una maggiore disponibilità delle risorse stamp. Ad esempio, le risorse di osservabilità che monitorano le risorse a livello di area, inclusi i francobolli.

Caratteristica	Considerazioni
Durata	Le risorse condividono la durata dell'area e le risorse del timbro sono attive.
State	Lo stato archiviato in un'area non può superare la durata dell'area. Se lo stato deve essere condiviso tra aree, è consigliabile usare un archivio dati globale.
Copertura	Le risorse non devono essere distribuite a livello globale. La comunicazione diretta con altre aree deve essere evitata a tutti i costi.
Dependencies	Le risorse possono avere dipendenze dalle risorse globali, ma non sulle risorse stamp perché i francobolli devono essere di breve durata.
Limiti di scalabilità	Determinare il limite di scalabilità delle risorse a livello di area combinando tutti i francobolli all'interno dell'area.

Architetture di base per carichi di lavoro cruciali

Questi esempi di baseline fungono da architettura di star settentrionale consigliata per le applicazioni cruciali. La baseline consiglia vivamente la containerizzazione e l'uso di un agente di orchestrazione dei contenitori per la piattaforma dell'applicazione. La baseline usa servizio Azure Kubernetes (servizio Azure Kubernetes).

Fare riferimento a Carichi di lavoro cruciali ben architettati: Containerizzazione.

• 

  Architettura della baseline

  ---

  Se si sta semplicemente iniziando il percorso mission-critical, usare questa architettura come riferimento. Il carico di lavoro viene accessibile tramite un endpoint pubblico e non richiede la connettività di rete privata ad altre risorse aziendali.

• 

  Baseline con controlli di rete

  ---

  Questa architettura si basa sull'architettura di base. La progettazione viene estesa per fornire controlli di rete rigorosi per impedire l'accesso pubblico non autorizzato da Internet alle risorse del carico di lavoro.

• 

  Baseline nelle zone di destinazione di Azure

  ---

  Questa architettura è appropriata se si distribuisce il carico di lavoro in una configurazione aziendale in cui è necessaria l'integrazione all'interno di un'organizzazione più ampia. Il carico di lavoro usa servizi condivisi centralizzati, richiede connettività locale e si integra con altri carichi di lavoro all'interno dell'organizzazione. Viene distribuito in una sottoscrizione della zona di destinazione di Azure che eredita dal gruppo di gestione Corp.

• 

  Baseline con Servizi app

  ---

  Questa architettura estende il riferimento di base considerando Servizi app come tecnologia di hosting dell'applicazione primaria, offrendo un ambiente facile da usare per le distribuzioni di contenitori.

Aree di progettazione

È consigliabile usare le indicazioni di progettazione fornite per esplorare le decisioni di progettazione chiave per raggiungere una soluzione ottimale. Per informazioni, vedere Quali sono le aree chiave di progettazione?

Passaggio successivo

Esaminare le procedure consigliate per la progettazione di scenari di applicazioni cruciali.

Progettazione di applicazioni