Metodologia di progettazione per carichi di lavoro cruciali in Azure

La creazione di un'applicazione mission-critical in qualsiasi piattaforma cloud richiede notevoli competenze tecniche e investimenti di progettazione, in particolare perché c'è una complessità significativa associata a:

• Informazioni sulla piattaforma cloud,
• Scelta dei servizi e della composizione corretti,
• Applicazione della configurazione del servizio corretta,
• Operazionalizzazione dei servizi utilizzati e
• Allineamento costante con le procedure consigliate e le roadmap dei servizi più recenti.

Questa metodologia di progettazione si impegna a fornire un percorso di progettazione facile da seguire per navigare in questa complessità e informare le decisioni di progettazione necessarie per produrre un'architettura di destinazione ottimale.

1- Progettare per i requisiti aziendali

Non tutti i carichi di lavoro cruciali hanno gli stessi requisiti. Si prevede che le considerazioni di revisione e le raccomandazioni di progettazione fornite da questa metodologia di progettazione produca decisioni di progettazione diverse e compromessi per diversi scenari di applicazione.

Selezionare un livello di affidabilità

L'affidabilità è un concetto relativo e per qualsiasi carico di lavoro essere affidabile in modo appropriato deve riflettere i requisiti aziendali che lo circondano. Ad esempio, un carico di lavoro mission-critical con un obiettivo del livello di servizio di disponibilità del 99,999% richiede un livello di affidabilità molto superiore rispetto a un altro carico di lavoro meno critico con un SLO del 99,9%.

Questa metodologia di progettazione applica il concetto di livelli di affidabilità espressi come contratti di servizio di disponibilità per informare le caratteristiche di affidabilità necessarie. La tabella seguente acquisisce i budget degli errori consentiti associati ai livelli di affidabilità comuni.

Livello di affidabilità (SLO di disponibilità)	Tempo di inattività consentito (settimana)	Tempo di inattività consentito (mese)	Tempo di inattività consentito (anno)
99,9%	10 minuti, 4 secondi	43 minuti, 49 secondi	8 ore, 45 minuti, 56 secondi
99,95%	5 minuti, 2 secondi	21 minuti, 54 secondi	4 ore, 22 minuti, 58 secondi
99,99%	1 minuti	4 minuti 22 secondi	52 minuti, 35 secondi
99,999%	6 secondi	26 secondi	5 minuti, 15 secondi
99.9999%	<1 secondo	2 secondi	31 secondi

Importante

L'SLO di disponibilità è considerato da questa metodologia di progettazione più che un tempo di attività semplice, ma piuttosto un livello coerente di servizio dell'applicazione rispetto a uno stato di applicazione integro noto.

Come esercizio iniziale, è consigliabile selezionare un livello di affidabilità di destinazione determinando quanto tempo di inattività è accettabile? La ricerca di un particolare livello di affidabilità avrà in definitiva un impatto significativo sul percorso di progettazione e sulle decisioni di progettazione incluse, il che comporterà un'architettura di destinazione diversa.

Questa immagine mostra come i diversi livelli di affidabilità e i requisiti aziendali sottostanti influiscono sull'architettura di destinazione per un'implementazione di riferimento concettuale, in particolare per quanto riguarda il numero di distribuzioni a livello di area e le tecnologie globali usate.

dial

L'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) sono altri aspetti critici quando si determina l'affidabilità necessaria. Ad esempio, se si sta cercando di ottenere un RTO dell'applicazione di meno di un minuto, è probabile che le strategie di ripristino basate sul backup o una strategia di distribuzione attiva-passiva non siano sufficienti.

2- Valutare le aree di progettazione usando i principi di progettazione

Al centro di questa metodologia si trova un percorso di progettazione critico costituito da:

• Principi fondamentali della progettazione
• Area di progettazione fondamentale con decisioni di progettazione fortemente correlate e dipendenti.

L'impatto delle decisioni prese all'interno di ogni area di progettazione riverbererà in altre aree di progettazione e decisioni di progettazione. Esaminare le considerazioni e le raccomandazioni fornite per comprendere meglio le conseguenze delle decisioni incluse, che possono produrre compromessi all'interno di aree di progettazione correlate.

Ad esempio, per definire un'architettura di destinazione è fondamentale determinare il modo migliore per monitorare l'integrità dell'applicazione tra i componenti chiave. È consigliabile esaminare l'area di progettazione della modellazione dell'integrità, usando le raccomandazioni descritte per guidare le decisioni.

3: Distribuire la prima applicazione mission-critical

Fare riferimento a queste architetture di riferimento che descrivono le decisioni di progettazione basate su questa metodologia.

• Architettura di base di un'applicazione con connessione Internet

• Architettura di base di un'applicazione con connessione Internet con controlli di rete

Suggerimento

L'architettura è supportata dall'implementazione mission-critical online che illustra le raccomandazioni di progettazione.

Artefatti di livello di produzione Ogni artefatto tecnico è pronto per l'uso in ambienti di produzione con tutti gli aspetti operativi end-to-end considerati.

Radicate in esperienze reali Tutte le decisioni tecniche sono guidate dalle esperienze dei clienti di Azure e dalle lezioni apprese dalla distribuzione di tali soluzioni.

Allineamento della roadmap di Azure Le architetture di riferimento cruciali hanno una roadmap personalizzata allineata alle roadmap del prodotto Azure.

4: Integrare il carico di lavoro nelle zone di destinazione di Azure

Le sottoscrizioni della zona di destinazione di Azure forniscono un'infrastruttura condivisa per le distribuzioni aziendali che necessitano di governance centralizzata.

È fondamentale valutare il caso d'uso della connettività richiesto dall'applicazione cruciale. Le zone di destinazione di Azure supportano due archetipi principali separati in ambiti diversi del gruppo di gestione: Online o Corp. Come illustrato in questa immagine.

Sottoscrizione online

Un carico di lavoro mission-critical opera come soluzione indipendente, senza connettività di rete aziendale diretta al resto dell'architettura della zona di destinazione di Azure. L'applicazione verrà ulteriormente tutelata tramite la governance guidata dai criteri e si integrerà automaticamente con la registrazione centralizzata della piattaforma tramite i criteri.

L'architettura di base e l'implementazione mission-critical online sono allineate all'approccio online.

Sottoscrizione di Corp.

Quando viene distribuita in una sottoscrizione aziendale, un carico di lavoro cruciale dipende dalla zona di destinazione di Azure per fornire le risorse di connettività. Questo approccio consente l'integrazione con altre applicazioni e servizi condivisi. Sarà necessario progettare alcune risorse fondamentali, che saranno disponibili in anticipo come parte della piattaforma di servizi condivisi. Ad esempio, lo stamp di distribuzione a livello di area non deve più includere un Rete virtuale temporaneo o una zona di azure DNS privato perché questi elementi saranno presenti nella sottoscrizione Corp.

Per iniziare a usare questo caso d'uso, è consigliabile usare l'architettura di base in un'architettura di riferimento della zona di destinazione di Azure.

Suggerimento

L'architettura precedente è supportata dall'implementazione mission-critical connected .

5- Distribuire un ambiente dell'applicazione sandbox

In parallelo alle attività di progettazione, è consigliabile stabilire un ambiente dell'applicazione sandbox usando le implementazioni di riferimento Mission-Critical.

In questo modo è possibile convalidare le decisioni di progettazione replicando l'architettura di destinazione, consentendo di valutare rapidamente l'incertezza di progettazione. Se applicato correttamente con la copertura dei requisiti rappresentativi, la maggior parte dei problemi che potrebbero ostacolare l'avanzamento può essere individuata e risolta successivamente.

6- Evolversi continuamente con roadmap di Azure

Le architetture delle applicazioni stabilite usando questa metodologia di progettazione devono continuare a evolversi in linea con le roadmap della piattaforma Azure per supportare la sostenibilità ottimizzata.

Passaggio successivo

Esaminare i principi di progettazione per scenari di applicazioni cruciali.

Principi di progettazione