Esercizio - Espandere la progettazione in più aree

30 minuti

Contoso Shoes ha bisogno di un modo per sostenere le interruzioni a livello di area. Si vuole distribuire lo stamp corrente in una topologia attiva/attiva, condivisa e in più aree. 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, una recente interruzione a livello di area che ha interessato la rete il sistema ha portato il sistema offline per gli utenti finali. Il ridimensionamento orizzontale all'interno dell'area o anche la distribuzione di un nuovo stamp in tale area non avrebbe garantito il recupero dell'applicazione dal suo stato di errore.

IL DNS viene mantenuto da un registrar esistente per api.contososhoes.com. Il record DNS viene risolto nell'endpoint back-end di Servizi app (apicontososhoes.azurewebsites.net) con una durata (TTL) di due2 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 in più aree.
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 attenersi alla procedura seguente:

1–Topologia in più aree

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à, usati 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 riceva il 75% del traffico e che l'area 2 appena aggiunta riceva 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 ora viene indirizzato 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.
Implementare un sistema automatizzato per rilevare malfunzionamenti a livello di area per garantire che il traffico non venga indirizzato all'area con errori. Inoltre, riceve notifiche quando un'area diventa nuovamente disponibile, consentendo al bilanciatore del carico di riprendere il routing verso quell'area.

Verificare i progressi: Routing del traffico globale

3 - Modifiche dello stamp di distribuzione

Lo stato ideale è una configurazione attiva-attiva, che elimina la necessità di failover manuale e in cui le richieste dei client possono essere servite da qualsiasi area. Considerare l’implicazione per l'architettura. Ad esempio, è disponibile uno stato che è archiviato nello stamp dell’area?

Alcuni servizi nell'architettura corrente hanno funzionalità di replica geografica. Valutare la possibilità di separare i servizi in stamp diversi: un timbro che contiene risorse globali e un altro timbro di area che condivide le risorse con lo stamp 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?