Questa architettura di riferimento fornisce indicazioni per la distribuzione di un carico di lavoro cruciale che usa servizi condivisi centralizzati, richiede connettività locale e si integra con altri carichi di lavoro di un'azienda. Queste linee guida sono destinate a un proprietario del carico di lavoro che fa parte di un team di applicazioni nell'organizzazione.
È possibile che si trovi in questa situazione quando l'organizzazione vuole distribuire il carico di lavoro in una zona di destinazione dell'applicazione Di Azure che eredita il gruppo di gestione Corp. Si prevede che il carico di lavoro si integri con le risorse condivise con provisioning preliminare nella zona di destinazione della piattaforma Azure gestita dai team centralizzati.
Importante
Che cos'è una zona di destinazione di Azure? Una zona di destinazione dell'applicazione è una sottoscrizione di Azure in cui viene eseguito il carico di lavoro. È connesso alle risorse condivise dell'organizzazione. Tramite tale connessione, ha accesso all'infrastruttura di base necessaria per eseguire il carico di lavoro, ad esempio rete, gestione degli accessi alle identità, criteri e monitoraggio. Le zone di destinazione della piattaforma sono una raccolta di varie sottoscrizioni, ognuna con una funzione specifica. Ad esempio, la sottoscrizione di Connessione ivity fornisce una risoluzione DNS centralizzata, una connettività locale e appliance virtuali di rete (APPLIANCE virtuali di rete) disponibili per l'uso da parte dei team delle applicazioni.
Il proprietario del carico di lavoro trae vantaggio dall'offload della gestione delle risorse condivise ai team centrali e si concentra sulle attività di sviluppo del carico di lavoro. L'organizzazione offre vantaggi applicando una governance coerente e ammortizzando i costi tra più carichi di lavoro.
È consigliabile comprendere il concetto di zone di destinazione di Azure.
In questo approccio, l'affidabilità massima è una responsabilità condivisa tra l'utente e il team della piattaforma. I componenti gestiti centralmente devono essere altamente affidabili per il funzionamento di un carico di lavoro cruciale come previsto. È necessario avere una relazione attendibile con il team della piattaforma in modo che i problemi di indisponibilità nei servizi centralizzati, che influiscono sul carico di lavoro, vengano mitigati a livello di piattaforma. Tuttavia, il team è responsabile dei requisiti di guida con il team della piattaforma per raggiungere gli obiettivi.
Questa architettura si basa sull'architettura di base cruciale con i controlli di rete. È consigliabile acquisire familiarità con l'architettura di base prima di procedere con questo articolo.
Nota
Le linee guida sono supportate da un'implementazione di esempio di livello di produzione che illustra lo sviluppo di applicazioni cruciali in Azure. Questa implementazione può essere usata come base per un ulteriore sviluppo di soluzioni come primo passo verso la produzione.
Strategie di progettazione chiave
Applicare queste strategie all'inizio della baseline mission-critical:
Percorso critico
Non tutti i componenti dell'architettura devono essere altrettanto affidabili. Il percorso critico include i componenti che devono essere mantenuti funzionali in modo che il carico di lavoro non verifichi tempi di inattività o prestazioni ridotte. Mantenere il percorso snella ridurrà al minimo i punti di errore.
Ciclo di vita dei componenti
Prendere in considerazione il ciclo di vita dei componenti critici perché ha un impatto sull'obiettivo di raggiungere un tempo di inattività quasi zero. I componenti possono essere risorse temporanee o di breve durata che possono essere create e distrutte in base alle esigenze; risorse non temporanee o di lunga durata che condividono la durata con il sistema o l'area.
Dipendenze esterne
Ridurre al minimo le dipendenze esterne da componenti e processi, che possono introdurre punti di errore. L'architettura ha risorse di proprietà di vari team esterni al team. Questi componenti (se critici) sono inclusi nell'ambito di questa architettura.
Topologia della sottoscrizione
Le zone di destinazione di Azure non implicano una singola topologia di sottoscrizione. Pianificare in anticipo il footprint della sottoscrizione con il team della piattaforma per soddisfare i requisiti di affidabilità del carico di lavoro in tutti gli ambienti.
Osservabilità autonoma nel percorso critico
Disporre di risorse di monitoraggio dedicate che consentono al team di eseguire rapidamente query sulla raccolta dei dati (in particolare il percorso critico) e di intervenire sulle correzioni.
Architettura
Scaricare un file di Visio di questa architettura.
I componenti di questa architettura sono uguali all'architettura di base cruciale con i controlli di rete. Le descrizioni sono brevità. Per altre informazioni, vedere gli articoli collegati. Per la documentazione del prodotto sui servizi di Azure, vedere Risorse correlate.
Risorse globali
Queste risorse si trovano nelle sottoscrizioni della zona di destinazione dell'applicazione. Le risorse globali non sono temporanee e condividono la durata del sistema. I servizi di Azure e la relativa configurazione rimangono uguali alle risorse globali di base.
Risorse di rete a livello di area
Queste risorse risiedono nelle sottoscrizioni della zona di destinazione della piattaforma e nelle sottoscrizioni della zona di destinazione dell'applicazione. L'architettura di base distribuisce tutte le risorse di proprietà dell'utente. In questa architettura, tuttavia, le risorse di rete vengono fornite tramite la sottoscrizione di Connessione ivity di cui viene effettuato il provisioning come parte della zona di destinazione della piattaforma.
In questo articolo, vedere la sezione Rete virtuale dell'hub regionale .
Risorse stamp a livello di area
Queste risorse si trovano nelle sottoscrizioni della zona di destinazione dell'applicazione. Queste risorse non condividono nulla con altre risorse, ad eccezione delle risorse globali.
La maggior parte dei servizi di Azure e la loro configurazione rimangono uguali all'architettura del timbro di base, ad eccezione delle risorse di rete, di cui viene effettuato il pre-provisioning dal team della piattaforma.
In questo articolo, vedere la sezione Rete virtuale spoke a livello di area.
Risorse esterne
Il carico di lavoro interagisce con le risorse locali. Alcuni di essi si trovano nel percorso critico per il carico di lavoro, ad esempio un database locale. Queste risorse e la loro comunicazione vengono inserite nel contratto di servizio composito complessivo del carico di lavoro. Tutte le comunicazioni sono attraverso la sottoscrizione Connessione ivity. Esistono altre risorse esterne che il carico di lavoro potrebbe raggiungere, ma non sono considerate critiche.
Risorse della pipeline di distribuzione
Le pipeline di compilazione e rilascio per un'applicazione mission-critical devono essere completamente automatizzate per garantire un modo coerente di distribuire un timbro convalidato. Queste risorse rimangono le stesse della pipeline di distribuzione di base.
Risorse di monitoraggio a livello di area
Queste risorse si trovano nelle sottoscrizioni della zona di destinazione dell'applicazione. I dati di monitoraggio per le risorse globali e le risorse a livello di area vengono archiviati in modo indipendente. I servizi di Azure e la relativa configurazione rimangono uguali alle risorse di monitoraggio di base.
In questo articolo, vedere la sezione Considerazioni sul monitoraggio.
Risorse gestionali
Per ottenere l'accesso al cluster di calcolo privato e ad altre risorse, questa architettura usa agenti di compilazione privati e istanze di macchine virtuali jump box. Azure Bastion offre accesso sicuro ai jump box. Le risorse all'interno degli indicatori rimangono uguali alle risorse di gestione di base.
Considerazioni sulla rete
In questa progettazione il carico di lavoro viene distribuito nella zona di destinazione dell'applicazione e richiede la connettività alle risorse federate nella zona di destinazione della piattaforma. Lo scopo può essere l'accesso alle risorse locali, il controllo del traffico in uscita e così via.
Topologia di rete
Il team della piattaforma decide la topologia di rete per l'intera organizzazione. In questa architettura si presuppone una topologia hub-spoke. Un'alternativa potrebbe essere Azure rete WAN virtuale.
Rete virtuale dell'hub a livello di area
La sottoscrizione Connessione ivity contiene una rete virtuale hub con risorse condivise dall'intera organizzazione. Queste risorse sono di proprietà e gestite dal team della piattaforma.
Dal punto di vista cruciale, questa rete non è temporanea e queste risorse si trovano nel percorso critico.
| Risorsa di Azure | Scopo |
|---|---|
| Azure ExpressRoute | Fornisce connettività privata dall'infrastruttura locale all'infrastruttura di Azure. |
| Firewall di Azure | Funge da appliance virtuale di rete che controlla e limita il traffico in uscita. |
| DNS Azure | Fornisce la risoluzione dei nomi cross-premise. |
| Gateway VPN | Connessione le filiali dell'organizzazione remota tramite la rete Internet pubblica nell'infrastruttura di Azure. Funge anche da alternativa alla connettività di backup per l'aggiunta di resilienza. |
Viene effettuato il provisioning delle risorse in ogni area e viene eseguito il peering alla rete virtuale spoke (descritta di seguito). Assicurarsi di comprendere e accettare gli aggiornamenti dell'appliance virtuale di rete, delle regole del firewall, delle regole di routing, del failover di ExpressRoute in Gateway VPN, dell'infrastruttura DNS e così via.
Nota
Un vantaggio fondamentale nell'uso dell'hub federato è che il carico di lavoro può integrarsi con altri carichi di lavoro in Azure o cross-premise attraversando gli hub di rete gestiti dall'organizzazione. Questa modifica riduce anche i costi operativi perché una parte della responsabilità viene spostata al team della piattaforma.
Rete virtuale spoke a livello di area
La zona di destinazione dell'applicazione ha almeno due Rete virtuale di Azure di cui è stato effettuato il pre-provisioning, per area, a cui fanno riferimento i francobolli a livello di area. Queste reti non sono temporanee. Uno serve il traffico di produzione e l'altro è destinato alla distribuzione vNext. Questo approccio consente di eseguire procedure di distribuzione affidabili e sicure.
Rete virtuale operativa
Il traffico operativo è isolato in una rete virtuale separata. Questa rete virtuale non è temporanea e si è proprietari di questa rete. Questa architettura mantiene la stessa progettazione dell'architettura di base con i controlli di rete.
Non esiste alcun peering tra la rete operativa e la rete spoke. Tutte le comunicazioni sono attraverso collegamento privato.
Responsabilità condivise
Avere una chiara comprensione del team responsabile per ogni elemento di progettazione dell'architettura. Ecco alcune aree chiave.
Pianificazione degli indirizzi IP
Dopo aver stimato le dimensioni necessarie per eseguire il carico di lavoro, collaborare con il team della piattaforma in modo che possano effettuare il provisioning della rete in modo appropriato.
Team della piattaforma
Specificare indirizzi distinti per le reti virtuali che partecipano ai peering. Gli indirizzi sovrapposti, ad esempio le reti locali e del carico di lavoro, possono causare interruzioni che causano interruzioni del servizio.
Allocare spazi di indirizzi IP di dimensioni sufficienti per contenere le risorse di runtime e distribuzioni, gestire i failover e supportare la scalabilità.
La rete virtuale e i peering con provisioning preliminare devono essere in grado di supportare la crescita prevista del carico di lavoro. È necessario valutare regolarmente la crescita con il team della piattaforma. Per altre informazioni, vedere Connessione ivity to Azure .For more information, see Connessione ivity to Azure.
Subnet della rete spoke a livello di area
L'utente è responsabile dell'allocazione delle subnet nella rete virtuale a livello di area. Le subnet e le risorse in esse contenute sono temporanee. Lo spazio indirizzi deve essere sufficientemente grande per supportare la potenziale crescita.
Subnet degli endpoint privati Dopo che il traffico raggiunge la rete virtuale, la comunicazione con i servizi PaaS all'interno della rete è limitata tramite endpoint privati, proprio come l'architettura di base con i controlli di rete. Questi endpoint vengono posizionati in una subnet dedicata. Gli indirizzi IP privati agli endpoint privati vengono assegnati da tale subnet.
Subnet del cluster I requisiti di scalabilità del carico di lavoro influisce sulla quantità di spazio di indirizzi da allocare per le subnet. Man mano che i nodi e i pod del servizio Azure Kubernetes aumentano il numero di istanze, gli indirizzi IP vengono assegnati da questa subnet.
Segmentazione di rete
Mantenere una segmentazione corretta in modo che l'affidabilità del carico di lavoro non venga compromessa dall'accesso non autorizzato.
Questa architettura usa gruppi di sicurezza di rete (NSG) per limitare il traffico tra subnet e la sottoscrizione Connessione ivity. I gruppi di sicurezza di rete usano ServiceTags per i servizi supportati.
Team della piattaforma
Applicare l'uso dei gruppi di sicurezza di rete tramite i criteri di Gestione rete di Azure.
Tenere presente la progettazione del carico di lavoro. Non c'è traffico diretto tra i francobolli. Inoltre, non sono presenti flussi tra aree. Se questi percorsi sono necessari, il traffico deve attraversare la sottoscrizione di Connessione ivity.
Impedire il traffico hub non necessario proveniente da altri carichi di lavoro nel carico di lavoro mission-critical.
Traffico in uscita da francobolli regionali
Tutto il traffico in uscita da ogni rete spoke a livello di area viene instradato attraverso la Firewall di Azure centralizzata nella rete hub regionale. Funge da hop successivo che controlla e quindi consente o nega il traffico.
Team della piattaforma
Creare route definite dall'utente per la route personalizzata.
Assegnare i criteri di Azure che impediranno al team dell'applicazione di creare subnet che non hanno la nuova tabella di route.
Concedere autorizzazioni di controllo degli accessi in base al ruolo adeguate al team dell'applicazione in modo che possano estendere le route in base ai requisiti del carico di lavoro.
Ridondanza in più aree
I carichi di lavoro cruciali devono essere distribuiti in più aree per resistere alle interruzioni a livello di area. Collaborare con il team della piattaforma per assicurarsi che l'infrastruttura sia affidabile.
Team della piattaforma
Distribuire risorse di rete centralizzate per area. La metodologia di progettazione cruciale richiede l'isolamento a livello di area.
Collaborare con il team dell'applicazione per individuare le dipendenze a livello di area nascoste in modo che una risorsa della piattaforma danneggiata in un'area non influisca sui carichi di lavoro in un'altra area.
Risoluzione DNS
La sottoscrizione Connessione ivity fornisce zone DNS private. Tuttavia, questo approccio centralizzato potrebbe non tenere conto delle esigenze DNS che potrebbero essere specifiche del caso d'uso. Effettuare il provisioning delle zone DNS personalizzate e collegarsi al timbro a livello di area. Se il team dell'applicazione non è proprietario del DNS, la gestione dei collegamenti privati diventa complessa per le risorse globali, ad esempio Azure Cosmos DB.
Team della piattaforma
Delegare le zone DNS privato di Azure al team dell'applicazione per coprire i casi d'uso.
Per la rete dell'hub a livello di area, impostare il valore dei server DNS su Predefinito (fornito da Azure) per supportare le zone DNS private gestite dal team dell'applicazione.
Considerazioni sulla progettazione dell'ambiente
È pratica generale inserire carichi di lavoro in ambienti separati per la produzione, la pre-produzione e lo sviluppo. Ecco alcune considerazioni chiave.
Come viene mantenuto l'isolamento?
L'ambiente di produzione deve essere isolato da altri ambienti. Anche gli ambienti inferiori devono mantenere un livello di isolamento. Evitare di condividere le risorse di proprietà dell'applicazione tra ambienti.
Un ambiente di produzione è necessario per le risorse globali, regionali e stamp di proprietà del team dell'applicazione. Gli ambienti di pre-produzione, ad esempio la gestione temporanea e l'integrazione, sono necessari per assicurarsi che l'applicazione venga testata in un ambiente che simula la produzione, il più possibile. L'ambiente di sviluppo deve essere una versione ridotta dell'ambiente di produzione.
Qual è il ciclo di vita previsto?
Gli ambienti di pre-produzione possono essere eliminati definitivamente dopo il completamento dei test di convalida. È consigliabile che gli ambienti di sviluppo condividano la durata di una funzionalità e vengano eliminati definitivamente al termine dello sviluppo. Queste azioni eseguite dall'automazione continua di integrazione/distribuzione continua (CI/CD).
Quali sono i compromessi?
Considerare i compromessi tra l'isolamento degli ambienti, la complessità della gestione e l'ottimizzazione dei costi.
Suggerimento
Tutti gli ambienti devono assumere dipendenze da istanze di produzione di risorse esterne, incluse le risorse della piattaforma. Ad esempio, un hub dell'area di produzione nella sottoscrizione Connessione ivity. Sarà possibile ridurre al minimo il delta tra gli ambienti di pre-produzione e di produzione.
Topologia di sottoscrizione per l'infrastruttura del carico di lavoro
Le sottoscrizioni vengono fornite dal team della piattaforma. A seconda del numero di ambienti, verranno richieste diverse sottoscrizioni per un solo carico di lavoro. A seconda del tipo di ambiente, alcuni ambienti potrebbero richiedere sottoscrizioni dedicate, mentre altri ambienti potrebbero essere consolidati in una sottoscrizione.
Indipendentemente dal fatto, collaborare con il team della piattaforma per progettare una topologia che soddisfi la destinazione di affidabilità complessiva per il carico di lavoro. È possibile condividere le risorse fornite dalla piattaforma tra ambienti nella stessa sottoscrizione perché rifletterà l'ambiente di produzione.
Nota
L'uso di più sottoscrizioni per contenere gli ambienti può raggiungere il livello di isolamento richiesto. Le sottoscrizioni della zona di destinazione vengono ereditate dallo stesso gruppo di gestione. Pertanto, la coerenza con la produzione viene garantita per il test e la convalida.
Sottoscrizione di produzione
Potrebbero esserci limiti di risorse per la sottoscrizione specificata. Se si concateno tutte queste risorse in una sottoscrizione, è possibile raggiungere tali limiti. In base alle unità di scala e alla scala prevista, prendere in considerazione un modello più distribuito. ad esempio:
Una sottoscrizione che contiene sia gli agenti di compilazione di Azure DevOps che le risorse globali.
Una sottoscrizione, per area. Contiene le risorse regionali, le risorse stamp e le jump box per i francobolli regionali.
Ecco una topologia di sottoscrizione di esempio usata in questa architettura.
Sottoscrizione di pre-produzione
È necessaria almeno una sottoscrizione. Può tuttavia eseguire molti ambienti indipendenti, ma è consigliabile disporre di più ambienti in sottoscrizioni dedicate. Questa sottoscrizione può anche essere soggetta a limiti di risorse come la sottoscrizione di produzione, descritta in precedenza.
Sottoscrizione di sviluppo
È necessaria almeno una sottoscrizione. Questa sottoscrizione potrebbe essere soggetta ai limiti delle risorse se esegue tutti gli ambienti indipendenti. È quindi possibile richiedere più sottoscrizioni. È consigliabile disporre di singoli ambienti nelle sottoscrizioni dedicate.
Provare a trovare la corrispondenza con la topologia di produzione il più possibile.
Considerazioni sulla distribuzione
Le distribuzioni non riuscite o le versioni errate sono cause comuni di interruzioni dell'applicazione. Testare accuratamente l'applicazione (e le nuove funzionalità) come parte del ciclo di vita dell'applicazione. Quando si distribuisce il carico di lavoro in una zona di destinazione, è necessario integrare la progettazione con le risorse e la governance fornite dalla piattaforma.
Fare riferimento a: Carichi di lavoro cruciali ben progettato: Distribuzione e test.
Infrastruttura di distribuzione
L'affidabilità dell'infrastruttura di distribuzione, ad esempio gli agenti di compilazione e la relativa rete, è spesso importante quanto le risorse di runtime del carico di lavoro.
Questa architettura usa agenti di compilazione privati per impedire l'accesso non autorizzato che può influire sulla disponibilità dell'applicazione.
È consigliabile mantenere l'isolamento tra le risorse di distribuzione. Un'infrastruttura di distribuzione deve essere associata alle sottoscrizioni del carico di lavoro per tale ambiente. Se si usano più ambienti in sottoscrizioni di pre-produzione, creare un'ulteriore separazione limitando l'accesso solo a tali singoli ambienti. Le risorse di distribuzione per area possono essere considerate per rendere l'infrastruttura di distribuzione più affidabile.
Distribuzione senza tempi di inattività
Aggiornamenti all'applicazione può causare interruzioni. L'applicazione di distribuzioni coerenti aumenterà l'affidabilità. Questi approcci sono consigliati:
- Avere pipeline di distribuzione completamente automatizzate.
- Distribuire gli aggiornamenti in ambienti di pre-produzione in un timbro pulito.
Per altre informazioni, vedere Linee guida per la distribuzione e i test cruciali.
Nell'architettura di base queste strategie vengono implementate annullando il provisioning e quindi eliminando il timbro con ogni aggiornamento. In questa progettazione non è possibile eseguire il provisioning completo perché il team della piattaforma possiede alcune risorse. Il modello di distribuzione è stato quindi modificato.
Modello di distribuzione
L'architettura di base usa il modello Blue-Green per distribuire gli aggiornamenti delle applicazioni. I nuovi francobolli con modifiche vengono distribuiti insieme ai francobolli esistenti. Dopo che il traffico viene spostato al nuovo timbro, il timbro esistente viene eliminato definitivamente.
In questo caso, la rete virtuale con peering specificata non è temporanea. Il timbro non è autorizzato a creare la rete virtuale o il peering all'hub regionale. Sarà necessario riutilizzare tali risorse in ogni distribuzione.
Il modello Canary può ottenere una distribuzione sicura con l'opzione di rollback. Prima di tutto, viene distribuito un nuovo stamp con modifiche al codice. La pipeline di distribuzione fa riferimento alla rete virtuale con provisioning preliminare e alloca le subnet, distribuisce le risorse, aggiunge endpoint privati. Sposta quindi il traffico in queste subnet in questa rete virtuale con provisioning preliminare.
Quando il timbro esistente non è più necessario, tutte le risorse stamp vengono eliminate dalla pipeline, ad eccezione delle risorse di proprietà della piattaforma. La rete virtuale, le impostazioni di diagnostica, il peering, lo spazio degli indirizzi IP, la configurazione DNS e il controllo degli accessi in base al ruolo vengono mantenuti. A questo punto, lo stamp è in uno stato pulito e pronto per la nuova distribuzione successiva.
Criteri di Azure DINE (deploy-if-not-exists)
Le zone di destinazione delle applicazioni di Azure potrebbero avere criteri di Azure DINE (deploy-if-not-exists). Questi controlli assicurano che le risorse distribuite soddisfino gli standard aziendali nelle zone di destinazione dell'applicazione, anche quando sono di proprietà del team dell'applicazione. Potrebbe verificarsi una mancata corrispondenza tra la distribuzione e la configurazione finale della risorsa.
Comprendere l'impatto di tutti i criteri DINE che verranno applicati alle risorse. Se sono state apportate modifiche alla configurazione delle risorse, incorporare l'intenzione dei criteri nelle distribuzioni dichiarative all'inizio del ciclo di sviluppo del carico di lavoro. In caso contrario, potrebbe esserci una deriva che porta a delta tra lo stato desiderato e lo stato distribuito.
Gestione degli accessi alle sottoscrizioni di distribuzione
Considerare i limiti della sottoscrizione come limiti di sicurezza per limitare il raggio di esplosione. Le minacce possono influire sull'affidabilità del carico di lavoro.
Team della piattaforma
- Concedere ai team dell'applicazione l'autorizzazione per le operazioni con autorizzazioni con ambito per la sottoscrizione dell'area di destinazione dell'applicazione.
Se si eseguono più distribuzioni all'interno di una singola sottoscrizione, una violazione influirà su entrambe le distribuzioni. È consigliabile eseguire distribuzioni in sottoscrizioni dedicate. Creare entità servizio per ogni ambiente per mantenere la separazione logica.
L'entità servizio deve offrire autonomia rispetto alle risorse del carico di lavoro. Inoltre, deve avere restrizioni che impediranno un'eccessiva manipolazione delle risorse della piattaforma all'interno della sottoscrizione.
Considerazioni sul monitoraggio
La piattaforma della zona di destinazione di Azure fornisce risorse di osservabilità condivise come parte delle sottoscrizioni di gestione. Il team operativo centralizzato incoraggia i team delle applicazioni a usare il modello federato. Tuttavia, per i carichi di lavoro cruciali, un singolo archivio di osservabilità centralizzato non è consigliato perché può potenzialmente essere un singolo punto di errore. I carichi di lavoro cruciali generano anche dati di telemetria che potrebbero non essere applicabili o interattivi per i team operativi centralizzati.
È quindi consigliabile adottare un approccio autonomo per il monitoraggio. Gli operatori del carico di lavoro sono in ultima analisi responsabili del monitoraggio e devono avere accesso a tutti i dati che rappresentano l'integrità complessiva.
L'architettura di base segue questo approccio e continua in questa architettura di riferimento. Azure Log Analytics e app Azure lication Insights vengono distribuiti a livello di area e a livello globale per monitorare le risorse in tali ambiti. L'aggregazione dei log, la creazione di dashboard e l'invio di avvisi rientrano nell'ambito del team. Sfruttare le funzionalità di Diagnostica di Azure che inviano metriche e log a vari sink per supportare i requisiti della piattaforma per la raccolta di log e metriche.
Modello di integrità
La metodologia di progettazione cruciale richiede un modello di integrità del sistema. Quando si definisce un punteggio di integrità complessivo, includere i flussi della zona di destinazione della piattaforma nell'ambito da cui dipende l'applicazione. Compilare query di log, integrità e avviso per eseguire il monitoraggio tra aree di lavoro.
Team della piattaforma
Concedere query di controllo degli accessi in base al ruolo (RBAC) e sink di log di lettura per le risorse della piattaforma pertinenti usate nel percorso critico dell'applicazione mission-critical.
Supportare l'obiettivo dell'organizzazione di affidabilità verso il carico di lavoro cruciale concedendo al team dell'applicazione un'autorizzazione sufficiente per eseguire le operazioni.
In questa architettura, il modello di integrità include log e metriche dalle risorse di cui è stato effettuato il provisioning nella sottoscrizione Connessione ivity. Se si estende questa progettazione per raggiungere una risorsa locale, ad esempio un database, il modello di integrità deve includere la connettività di rete a tale risorsa, inclusi i limiti di sicurezza come le appliance virtuali di rete in Azure e in locale. Queste informazioni sono importanti per determinare rapidamente la causa radice e correggere l'impatto sull'affidabilità. Ad esempio, si è verificato l'errore durante il tentativo di instradamento al database o si è verificato un problema con il database?
Fare riferimento a: Carichi di lavoro cruciali ben progettato: Modellazione dell'integrità.
Integrazione con i criteri e le regole forniti dalla piattaforma
La sottoscrizione dell'area di destinazione dell'applicazione eredita i criteri di Azure, le regole di Gestione rete di Azure e altri controlli dal gruppo di gestione. Il team della piattaforma fornisce tali protezioni.
Per le distribuzioni, non dipendere esclusivamente dai criteri forniti dalla piattaforma, perché:
- Non sono progettazioni per soddisfare le esigenze dei singoli carichi di lavoro.
- I criteri e le regole potrebbero essere aggiornati o rimossi all'esterno del team e quindi possono influire sull'affidabilità.
È consigliabile creare e assegnare criteri di Azure all'interno delle distribuzioni. Questo sforzo potrebbe portare a una duplicazione, ma accettabile, considerando il potenziale impatto sull'affidabilità del sistema. Se sono state apportate modifiche ai criteri della piattaforma, i criteri del carico di lavoro continueranno a essere applicati localmente.
Team della piattaforma
- Coinvolgere il team dell'applicazione nel processo di gestione delle modifiche dei criteri man mano che si evolvono.
- Tenere presente i criteri usati dal team dell'applicazione. Valutare se devono essere aggiunti al gruppo di gestione.
Distribuire questa architettura
Gli aspetti di rete di questa architettura vengono implementati nell'implementazione mission-critical Connessione ed.
Nota
L'implementazione Connessione ed è progettata per illustrare un carico di lavoro cruciale che si basa sulle risorse dell'organizzazione, si integra con altri carichi di lavoro e usa servizi condivisi. L'implementazione presuppone che esista già una sottoscrizione Connessione ivity.
Passaggi successivi
Esaminare l'area di progettazione della rete e della connettività in Azure Well-architected Framework.
Risorse correlate
Oltre ai servizi di Azure usati nell'architettura di base, questi servizi sono importanti per questa architettura.