Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Esempio di utilizzo nel settore automobilistico di Example Corp.
Questa sezione del white paper illustra come le considerazioni, le domande sulla definizione dei requisiti e gli alberi decisionali vengono utilizzati per aiutarvi a decidere la progettazione ottimale della rete ibrida. L'identificazione e l'acquisizione dei requisiti sono importanti poiché vengono utilizzati come input per gli alberi decisionali. L'acquisizione anticipata dei requisiti evita ulteriori iterazioni di progettazione. L'interruzione totale di un progetto, se è necessario rivisitare il progetto e disporre di risorse preziose, può essere ridotto al minimo e idealmente evitato quando i requisiti vengono compresi in anticipo.
In questa sezione verrà utilizzato Example Corp. Automotive come cliente illustrativo. Stanno cercando di implementare inizialmente il loro primo progetto di analisi su. AWS Il progetto di analisi si concentra sull'analisi dei dati delle auto prodotte dall'azienda e di altri set di dati già esistenti nei data center dell'azienda. Inizialmente, il gruppo di architettura dell'azienda ritiene che avranno bisogno di un Account AWS Amazon VPC e di poche sottoreti per ospitare ambienti di produzione e sviluppo. Il team di progetto non vede l'ora di iniziare e ha richiesto l'accesso all'ambiente di sviluppo il prima possibile. Il loro obiettivo è entrare in produzione tra tre mesi.
Example Corp. Automotive prevede inoltre di utilizzarlo AWS per diversi progetti aggiuntivi, come la migrazione dei propri sistemi ERP, della Virtual Desktop Infrastructure (VDI) e di altre 20 applicazioni dall'ambiente locale ai AWS prossimi 6 mesi. Alcuni requisiti per progetti aggiuntivi sono ancora in fase di definizione, ma è chiaro che il loro Cloud AWS utilizzo è destinato a crescere.
Il team di architettura ha deciso di sfruttare l'approccio descritto in questo white paper. Hanno utilizzato le domande sulla definizione dei requisiti delineate in ciascuna considerazione per acquisire gli input necessari per prendere le decisioni di progettazione.
Iniziano con i requisiti relativi al tipo di connettività, riassunti nella tabella seguente.
Tabella 4 — Esempi di input di affidabilità di Automotive Corp.
| Considerazioni sulla selezione del tipo di connettività | Domande sulla definizione dei requisiti | Risposte |
|---|---|---|
| È ora di implementare | Qual è la tempistica richiesta per l'implementazione? Ore, giorni, settimane o mesi? |
|
| Sicurezza | I requisiti e le politiche di sicurezza consentono l'utilizzo di connessioni crittografate su Internet per connettersi AWS o impongono l'utilizzo di connessioni di rete private? |
|
| Quando si utilizzano connessioni di rete private, il livello di rete deve fornire la crittografia in transito? | No, verrà utilizzata la crittografia a livello di applicazione. | |
| SLA | È richiesto uno SLA di connettività ibrida con crediti di servizio? |
|
| Qual è l'obiettivo di uptime? |
|
|
| L'intera rete ibrida rispetta l'obiettivo di uptime? |
|
|
| Prestazioni | Qual è la produttività richiesta? |
|
| Qual è la latenza massima accettabile tra la rete locale AWS e quella locale? |
|
|
| Qual è il jitter di rete massimo accettabile? |
|
|
| Costo | A quanti dati invieresti AWS al mese? |
|
| Da quanti dati invieresti AWS al mese? |
|
|
| Questa connettività è permanente? | Sì |
In base ai requisiti ricevuti, il team di architettura ha seguito l'albero decisionale sul tipo di connettività riportato nella Figura 9. Ha consentito al team di architettura di decidere il tipo di connettività per gli ambienti di sviluppo, test e produzione. Per quanto riguarda l'ambiente di produzione, hanno considerato i requisiti immediati e quelli imminenti. Per lo sviluppo e il test Example Corp. Automotive stabilirà una site-to-site VPN su Internet. Per la produzione, collaboreranno con un fornitore di servizi a cui connettere la rete aziendale. AWS Direct Connect Example Corp. Automotive inizialmente aveva preso in considerazione l'utilizzo di una connessione ospitata Direct Connect, tuttavia, a causa dei requisiti per uno SLA AWS fornito
Dopo aver deciso il tipo di connettività, il passaggio successivo consiste nell'individuare i requisiti che influiscono sulla selezione del progetto di connettività. Ciò è correlato alla progettazione logica, ad esempio alla modalità di configurazione delle connessioni e ai AWS servizi da utilizzare per supportare i requisiti aziendali e tecnici.
Per comprendere i requisiti del modello di scalabilità e comunicazione, il team di architettura ha utilizzato le domande sulla definizione dei requisiti contenute nelle sezioni associate di questo white paper. I requisiti relativi a queste due considerazioni sono riassunti nella tabella seguente.
Tabella 5 — Domande sulla definizione dei requisiti
| Considerazioni sulla selezione del progetto di connettività | Domande sulla definizione dei requisiti | Risposte |
|---|---|---|
| Scalabilità | Qual è il numero attuale o previsto di VPC che richiedono la connettività ai siti locali? | 2 inizialmente, con un aumento fino a 30 in 6 mesi |
| Questi VPC sono distribuiti in una Regione AWS o più regioni? | Regione singola | |
| A quanti siti locali è necessario connettersiAWS? | 2 data center | |
| A quanti dispositivi Customer Gateway avete, per sito, a cui dovete connetterviAWS? | 2 router per data center | |
| Quanti percorsi dovrebbero essere pubblicizzati AWS sui VPC e il numero di percorsi previsti che verranno ricevuti da Side? AWS |
|
|
| Si prevede di prendere in considerazione l'aumento della larghezza di banda della connessione AWS nelle prossime future? |
|
|
| Modelli di progettazione della connettività | È necessario abilitare la comunicazione tra VPC (all'interno di una regione e/o tra regioni)? | Sì, entro un Regione AWS |
| È necessario accedere ai servizi di endpoint AWS pubblici direttamente dall'ambiente locale? | Sì | |
| È necessario accedere ai AWS servizi utilizzando gli endpoint VPC dall'ambiente locale? | No |
Sulla base degli input, il team di architettura ha seguito l'albero decisionale della sezione Connectivity Design. Dopo aver previsto che il numero di VPC aumenterà da 2 a 30 nei prossimi 6 mesi, il team di architettura ha deciso di utilizzarlo AWS Transit Gateway come gateway di terminazione per la connessione e per il routing tra VPC. Independent AWS Transit Gateway s interromperà la connessione VPN utilizzata per lo sviluppo e il test e per la connettività di produzione con. AWS Direct Connect L'utilizzo di AWS Transit Gateway s separati semplifica la gestione delle modifiche e fornisce una chiara demarcazione tra ambienti di sviluppo/test e di produzione. Per la produzione, è necessario un gateway a causa di. AWS Direct Connect AWS Transit Gateway Verrà utilizzata una VIF pubblica per accedere ai servizi di endpoint AWS pubblici. La Figura 14 illustra il percorso seguito nell'albero decisionale in base ai requisiti raccolti.
Figura 14 — Albero decisionale per la progettazione di connessioni automobilistiche di Example Corp.
Dopo aver deciso la soluzione per soddisfare i requisiti del modello di scalabilità e comunicazione, il passaggio successivo consiste nell'acquisire i requisiti associati all'affidabilità. Ciò è correlato al livello di disponibilità e resilienza richiesto.
Per acquisire i requisiti di affidabilità, il team di architettura ha utilizzato le domande sulla definizione dei requisiti contenute nella sezione associata di questo white paper. I requisiti sono riassunti nella tabella seguente.
Tabella 6 — Domande sui requisiti di affidabilità
| Considerazioni sulla selezione del progetto di connettività | Domande sulla definizione dei requisiti | Risposte |
|---|---|---|
| Affidabilità | Qual è l'entità dell'impatto sull'azienda in caso di interruzione della connettività? AWS |
|
| Dal punto di vista aziendale, il costo derivante da un guasto di connettività AWS supera il costo dell'implementazione di un modello di connettività altamente affidabile? AWS |
|
Sulla base degli input ricevuti, il team di architettura ha seguito l'albero decisionale riportato nelle sezioni sulle considerazioni sull'affidabilità trattate in precedenza in questo white paper. Dopo aver considerato l'obiettivo di uptime del 99,99% per la connettività di produzione e l'elevato impatto aziendale in caso di interruzione del servizio, il team di architettura ha deciso di utilizzare 2 sedi Direct Connect e disporre di 2 collegamenti da ciascun data center locale a ciascuna sede Direct Connect (4 collegamenti in totale). La connettività VPN utilizzata per lo sviluppo e il test utilizzerà anche due connessioni VPN per una ridondanza aggiuntiva. Utilizzando le tecniche di ingegneria dei percorsi discusse nella sezione sull'affidabilità, la connettività verrà configurata come segue:
-
Per lo sviluppo e il test, il traffico verrà bilanciato dal carico utilizzando ECMP sui 2 tunnel diretti al data center principale. Ciò consente un throughput più elevato. I tunnel che portano al data center secondario verranno utilizzati in caso di guasto dei tunnel primari.
-
Per la produzione, la latenza tra locale e AWS su una delle due sedi Direct Connect è molto simile. In questo caso, è stato deciso di bilanciare il carico del traffico tra AWS e in locale sulle due connessioni dirette al data center primario per i sistemi locali distribuiti nel data center primario. Analogamente, per i sistemi locali in esecuzione nel data center secondario, il carico del traffico verrà bilanciato tra le due connessioni al data center secondario. In caso di guasto delle connessioni, BGP faciliterà un failover automatico.
La Figura 15 illustra il percorso seguito nell'albero decisionale in base ai requisiti raccolti.
Figura 15 — Albero decisionale sull'affidabilità del settore automobilistico di Example Corp.
