Esercizio - Espandere la progettazione in più aree
Contoso Shoes ha bisogno di un modo per sostenere le interruzioni a livello di area. Si vuole distribuire il timbro corrente in una topologia attiva-attiva, condivisa e multiregione. L'architettura deve essere progettata per reindirizzare il traffico a un'altra area nel caso in cui un'area abbia esito negativo.
Stato corrente e problema
Una singola area è stata sufficiente per l'applicazione. Tuttavia, un'interruzione a livello di area recente che ha interessato la rete ha causato l'uscita del sistema dal punto di vista dell'utente finale. La scalabilità orizzontale all'interno dell'area, o anche la distribuzione di un nuovo timbro in tale area, non avrebbe ripristinato l'applicazione dallo stato non riuscito.
IL DNS viene mantenuto da un registrar esistente per api.contososhoes.com. Il record DNS viene risolto nell'endpoint di servizio app back-end (apicontososhoes.azurewebsites.net) con un periodo di durata (TTL) di due giorni. Quando la soluzione viene distribuita in più aree, è necessario eseguire la migrazione del DNS.
Specifica
- Estendere l'architettura in modo che funzioni in una topologia attiva-attiva e multiregione.
- Modificare il modello di stamp di distribuzione che consente l'aggiunta e la rimozione dinamica delle aree in base alle necessità, invece di affidarsi a un elenco di risorse hardcoded in sole due aree.
- In caso di errori a livello di area, il traffico deve essere indirizzato verso l'area priva problemi, senza causare effetti significativi sui client già attivi in quella zona funzionante.
- I client non devono essere aggiunti a un'area.
- I client non devono modificare gli URL per contattare l'API. È necessario eseguire la migrazione del DNS al router globale.
Approccio consigliato
Per iniziare a progettare, è consigliabile seguire questa procedura:
Topologia 1-Multiregion
L'architettura deve essere distribuita in due o più aree di Azure per la protezione da interruzioni a livello di area. È necessario considerare questi fattori quando si sceglie un'area:
- L'area deve essere in grado di resistere alle interruzioni del data center in tale area.
- I servizi di Azure e le funzionalità usate nell'architettura devono essere supportati nell'area.
- Per ridurre al minimo la latenza di rete, l'area e le risorse in essa distribuite devono trovarsi in prossimità degli utenti finali e dei sistemi dipendenti.
Esaminare uno scenario di errore. Si supponga che l'area 1 ottenga il 75% del traffico e che l'area 2 appena aggiunta ottenga il traffico rimanente. Entrambe le aree sono ridimensionate in modo appropriato per gestire il carico. Si verifica un'interruzione a livello di area nell'area 1 e tutto il traffico viene ora instradato all'area 2. È possibile rendere agevole la transizione? L'area 2 può supportare l'aumento del carico del traffico?
Verificare i progressi: Distribuzione globale
2 - Routing globale
Per consentire ai client di essere indirizzati in modo trasparente a una delle due aree di lavoro, è necessario aggiungere un bilanciamento del carico globale. Il servizio di bilanciamento del carico deve usare i controlli di integrità aggiunti nell'esercizio precedente per determinare se un indicatore è integro. Esistono dei modi per gestire richieste frequenti e simili che possono essere eseguite senza raggiungere il back-end?
- Scegliere un servizio di Azure nativo che si integra con l'architettura esistente, che sia in grado di eseguire rapidamente il failover.
- Assicurarsi che il percorso di ingresso della rete sia impostato per negare il traffico non autorizzato.
- Ridurre al minimo la latenza di rete servendo gli utenti finali da una cache perimetrale.
- Eseguire la migrazione del DNS esistente senza interferire con i client esistenti.
- Avere un modo automatizzato per indicare un errore a livello di area per garantire che il traffico non venga instradato all'area con errori. Ricevere inoltre una notifica quando l'area è nuovamente disponibile in modo che il servizio di bilanciamento del carico possa riprendere il routing a tale area.
Verificare i progressi: Routing del traffico globale
3 - Modifiche dello stamp di distribuzione
Lo stato ideale è una configurazione attiva-attiva che non richiede alcun failover manuale e le richieste client possono essere gestite da qualsiasi area. Considerare l’implicazione per l'architettura. Ad esempio, si dispone di uno stato archiviato nel timbro a livello di area?
Alcuni servizi nell'architettura corrente hanno funzionalità di replica geografica. Valutare la possibilità di separare i servizi in timbri diversi: un timbro che contiene risorse globali e un altro timbro regionale che condivide le risorse con il timbro globale. Uno dei fattori decisivi deve essere il ciclo di vita delle risorse. Qual è la durata prevista della risorsa rispetto ad altre risorse nell'architettura? La risorsa deve durare più a lungo o condividere la durata con l'intero sistema o l'area oppure deve essere temporanea?
Esplorare le funzionalità di affidabilità dei servizi di Azure usati nell'architettura. È possibile iniziare con queste funzionalità ed esplorarle ulteriormente per ottimizzare l'affidabilità.
| Servizio di Azure | Funzionalità |
|---|---|
| Azure Cosmos DB | Scrittura in più aree |
| Registro Azure Container | Replica geografica |
| Piano di servizio app di Azure | Supporto della zona di disponibilità |
Verificare i progressi: Piattaforma applicazione | Piattaforma dati
Controlla il tuo lavoro
Di seguito sono riportate le scelte di progettazione delle applicazioni e dei dati per un'architettura simile. Sono stati coperti tutti gli aspetti nel progetto?
- Quale altra area di Azure è stata selezionata per la topologia in più aree e perché?
- Sono state abilitate due o più zone di disponibilità di Azure in ogni area di Azure per proteggersi in caso di interruzioni del data center?
- È stato incluso Web application firewall per controllare il traffico in ingresso? Quali regole di gestione sono state applicate e perché?
- In che modo il bilanciamento del carico supporta il record DNS esistente?
- Come è stata usata l'API per il controllo dell’integrità dell'esercizio precedente?
- L'applicazione è stata protetta dagli attacchi DDoS, impedendo in particolare ai client malintenzionati di ignorare il bilanciamento del carico e raggiungere le istanze a livello di area?
- Come è stata gestita la migrazione del DNS?
- Sono state apportate modifiche allo SKU del componente esistente per supportare la topologia in più aree?
- Quali servizi di Azure sono stati lasciati come singleton? Come è stata motivata la scelta di ciascun servizio? Sono state apportate modifiche alla configurazione?
- Si stanno registrando risorse? È possibile che ciò influisca sulla capacità di ispezionare i log per l'intero sistema?