Hadian E bentornato.
In questo video parleremo del bilanciatore di carico Gateway con una panoramica di alto livello.
Prima di parlare dei bilanciatori di carico Gateway, è importante capire il
problema e le sfide che l'organizzazione deve affrontare.
Uno degli aspetti importanti, in particolare per le grandi aziende, è l'ispezione del traffico.
Ora, l'ispezione del traffico può essere correlata agli ordigni esplosivi improvvisati e ai PFU.
Può riguardare i firewall, i casi d'uso relativi alla deep packet inspection, ecc.
Questo è il motivo per cui nella maggior parte delle aziende è possibile vedere una sorta di dispositivo di rete
virtuale legato a IED, EFP, firewall che sono stati implementati in modo abusivo.
Ora analizziamo anche la prospettiva architettonica per vedere come si integra.
Supponiamo quindi di avere una sottorete in cui sono ospitati tutti i server delle applicazioni e che
sia necessaria una sorta di ispezione del traffico.
Le organizzazioni utilizzano quindi una sorta di dispositivo di rete virtuale relativo
a IED, EFP e così via. che vengono forniti da vari fornitori come Cisco, ecc.
E questo dispositivo di rete può occuparsi dell'ispezione generale del traffico.
Supponiamo ora che esista un gateway Internet utilizzato per inviare e ricevere traffico attraverso Internet.
Quindi, se un server applicativo vuole inviare o ricevere traffico da Internet, il traffico passa
prima all'appliance di rete, dove viene ispezionato dall'appliance di rete e va verso il gateway
Internet.
Allo stesso modo, il traffico proveniente da Internet passa all'appliance di rete dove viene ispezionato.
Dopo l'ispezione, il dispositivo di rete rimanda il traffico all'application server.
Questo è uno dei casi d'uso più comuni nelle aziende.
Ora, prima di procedere oltre, cerchiamo di capire, sulla base di questa architettura, come si possono
definire le tabelle di route.
Ora, nella sottorete uno dove sono ospitati i server delle applicazioni, diamo un'occhiata alla tabella delle rotte,
dove si definisce che ci sarà una rotta predefinita della VPC locale e l'obiettivo è locale.
Tuttavia, per qualsiasi altra destinazione come 0000, che include anche il traffico verso Internet,
la destinazione è l'appliance di rete E nine, quindi tutto il traffico dal server applicativo non è
destinato alla VPC, ma andrà prima verso l'appliance di rete.
A livello di dispositivo di rete, abbiamo una rotta locale qui e una a0000 che va verso il gateway
Internet.
Quindi Application Server invia prima il traffico destinato al gateway Internet all'Appliance di rete.
Network Appliance ispeziona il traffico e lo invia al gateway Internet.
Quindi questa è una parte.
La seconda parte da considerare è il percorso a livello di gateway Internet.
All'interno di questo punto, è possibile definire tutto il traffico che va verso la sottorete dell'application server.
Quindi, se vedete il sito, quel blocco è 1077 2. 0 slash 24, che si può vedere qui, tutto il traffico che
va verso la sottorete, deve andare alla E nove del dispositivo di rete.
Quindi, qualsiasi cosa abbia l'apparecchio di rete, è lì che il traffico andrà a finire.
Va bene.
Spero che con questa panoramica di alto livello abbiate capito l'architettura di questo
tipo di configurazione.
Ora, questo tipo di architettura presenta alcune sfide.
In primo luogo, come abbiamo detto, l'instradamento viene effettuato a un livello interno del dispositivo di rete.
Ad esempio, da questo percorso possiamo identificare che tutto il traffico che va verso
Internet è diretto verso l'obiettivo dell'INA dell'appliance di rete.
Questo è il significato del primo puntatore.
Quando si dispone di una tabella di rotte di questo tipo, si riscontrano problemi legati all'alta disponibilità e alla scalabilità.
Ad esempio, supponiamo che questo dispositivo di rete si sia guastato.
Questo non è altro che un'istanza facile da gestire.
Cosa succederebbe se questa istanza di EC due andasse in tilt?
Tuttavia, a seconda della tabella dei percorsi, il traffico si dirigerà verso l'INA.
Quindi, se si lancia un'altra appliance di rete EC due, si dovrà modificare la tabella
delle rotte associata al gateway Internet e quella della sottorete dell'application server.
Il secondo problema principale è la scalabilità.
Poiché abbiamo definito una sola INA.
Cosa succede se ci sono dieci istanze dell'appliance di rete in esecuzione?
Anche questo è uno dei problemi che dovrete affrontare.
Per ovviare a questo problema, A ha introdotto un nuovo tipo di bilanciamento del carico, chiamato gateway load
balancer, che consente di distribuire in scala e gestire facilmente le appliance virtuali.
In questo tipo di architettura, quindi, si dispone di più dispositivi di rete e si crea
un gateway load balancer.
Anche questo gateway load balancer ha un endpoint specifico.
Quindi tutto il traffico dal server applicativo, supponiamo verso Internet, andrà verso il gateway
load balancer.
Endpoint, che a sua volta lo inoltra al bilanciatore di carico Gateway.
Questo gateway load balancer può distribuire il traffico a più dispositivi di rete in esecuzione.
In questo tipo di architettura le cose sono molto più semplici.
L'elevata disponibilità è garantita dalla presenza di più dispositivi di rete e non è necessario
preoccuparsi dei problemi di scalabilità.
Ora, parlando del bilanciatore di carico Gateway, c'è un punto molto importante da notare:
per utilizzare il bilanciatore di carico Gateway, le appliance devono supportare il protocollo genic.
Ad esempio, si vede che le istanze EC2 attraverso l'endpoint Gateway Load Balancer inviano il traffico al
bilanciatore di carico Gateway.
Ora anche questo gateway load balancer e l'appliance di rete devono comunicare, e questo è il motivo per cui
il protocollo deve essere supportato.
L'idea è quindi che qualsiasi traffico ricevuto dalle due istanze EC venga incapsulato
con Geneve.
Questo è un punto che dovete tenere presente.
Questa è una panoramica di alto livello sui bilanciamenti di carico dei gateway e con questo concludiamo il video
di oggi.