Questo browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
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?
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. |
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. |
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. |
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.
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.
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.
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.
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.
È 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?
Esaminare le procedure consigliate per la progettazione di scenari di applicazioni cruciali.