2012-02-13 15 views
63

Utilizziamo Amazon EC2 e vogliamo mettere un ELB (bilanciamento del carico) su 2 istanze in una sottorete privata. Se aggiungiamo la sottorete privata all'ELB, non otterremo alcuna connessione, se colleghiamo entrambe le subnet all'ELB, quindi potrà accedere alle istanze, ma spesso otterrà dei time-out. Qualcuno ha implementato con successo un ELB all'interno della sottorete privata del proprio VPC? Se è così, potresti spiegarmi la procedura?Amazon ELB in VPC

Grazie

risposta

164

mio compagno di squadra e ho appena hanno implementato ELB in una VPC con 2 sottoreti private in diverse zone di disponibilità. Il motivo per cui si ottiene il timeout è che per ogni sottorete aggiunta al servizio di bilanciamento del carico, ottiene un indirizzo IP esterno. (prova 'dig elb-dns-name-here' e vedrai diversi indirizzi IP). Se uno di questi indirizzi IP mappa una sottorete privata, verrà interrotto. L'IP che esegue il mapping nella sottorete pubblica funzionerà. Poiché DNS può fornire uno qualsiasi degli indirizzi IP, a volte funziona, a volte scadono.

Dopo un po 'avanti e indietro con Amazon, abbiamo scoperto che l'ELB deve essere collocato solo nelle sottoreti "pubbliche", cioè le sottoreti che hanno una rotta verso il gateway Internet. Volevamo mantenere i nostri server Web nelle nostre subnet private, ma consentire al ELB di parlare con loro. Per risolvere questo problema, dovevamo assicurarci di avere una sottorete pubblica corrispondente per ogni zona di disponibilità in cui disponevamo di sottoreti private. Abbiamo quindi aggiunto all'ELB, le subnet pubbliche per ogni zona di disponibilità.

Inizialmente, questo non sembrava funzionare, ma dopo aver provato tutto, abbiamo ricreato l'ELB e tutto ha funzionato come dovrebbe. Penso che questo sia un bug, o l'ELB era in uno stato strano da così tanti cambiamenti.

Qui è più o meno quello che abbiamo fatto:

  1. WebServer-1 è in esecuzione in PrivateSubnet-1 della disponibilità di zona ci-est-1b con gruppo di protezione denominato web-server.
  2. WebServer-2 è in esecuzione in PrivateSubnet-2 nella zona di disponibilità us-east-1c con gruppo di sicurezza denominato server web.
  3. Creata una sottorete pubblica nella zona us-east-1b, la chiameremo PublicSubnet-1. Ci siamo assicurati di associare la tabella di routing che include la route verso il gateway Internet (ig-xxxxx) con questa nuova sottorete. (Se hai usato la procedura guidata per creare un VPC pubblico/privato, questa rotta esiste già.)
  4. Creata una sottorete pubblica nella zona us-east-1c, la chiameremo PublicSubnet-2. Ci siamo assicurati di associare la tabella di routing che include la route verso il gateway Internet (ig-xxxxx) con questa nuova sottorete. (Se è stata utilizzata la procedura guidata per creare un VPC pubblico/privato, questa route esiste già.)
  5. Creato un nuovo ELB, aggiungendo ad esso PublicSubnet-1 e PublicSubnet-2 (non PrivateSubnet-X). Inoltre, selezionato le istanze da eseguire nel ELB, in questo caso WebServer-1 e WebServer-2. Assicurati di assegnare un gruppo di sicurezza che consenta le porte in entrata 80 e 443. Chiamiamo questo gruppo gruppo elb.
  6. Nel gruppo web-server, consentire il traffico dalla porta 80 e 443 dal gruppo elb.

Spero che questo aiuti!

+0

sì, siamo arrivati ​​alla stessa conclusione, ho appena dimenticato di aggiornare questo. Grazie per la risposta :) –

+1

Questa è una buona fonte di informazioni correlate: https://forums.aws.amazon.com/thread.jspa?messageID=453594񮯚 –

+4

Mi rammarico di avere un solo voto da dare. Grazie! Stavo sbattendo la testa contro il muro per le ultime 2 ore cercando di capirlo. – Cfreak

2

Abbiamo implementato ELB in una sottorete privata, quindi l'affermazione che tutti gli ELB devono essere pubblici non è completamente vera. Hai bisogno di un NAT. Crea una sottorete privata per i Private ELB, attiva il VPC DNS e assicurati che la tabella di routing privata sia configurata per passare attraverso il NAT. I gruppi di sicurezza della sottorete devono inoltre essere configurati per consentire il traffico tra ELB e App e le subnet App in DB.

Le verifiche dello stato dei beanli non funzionano in quanto non possono raggiungere il bilanciamento del carico, ma per i servizi che devono essere al di fuori della portata del pubblico questo è un buon compromesso.

Letture consigliate per l'avvio dell'architettura VPC: http://blog.controlgroup.com/2013/10/14/guided-creation-of-cloudformation-templates-for-vpc/.

2

È necessario aggiungere le seguenti impostazioni.

  1. sottorete pubblica zona b = Server NAT
  2. privato zona sottorete Web c = Server
  3. sottorete pubblica Zona C = ELB

Il trucco è il routing:

  1. Il il router al NAT è collegato al gateway A.
  2. Il router al Server Web è collegato a NAT .
  3. Il router di sottorete pubblico collegare con l'ingresso A.

ELB dettagli:

1.Zone: sottorete pubblica Zona C 2.Instance: Web Server 3.Security Gruppi: abilitare le porte

http://docs.amazonaws.cn/en_us/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html

+0

Ho trovato utili anche queste istruzioni: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Scenario2.html#Configuration-2 – BatteryAcid

9

La chiave qui è la comprensione, che non si è "aggiungendo sottoreti zone/disponibilità", per ELB, ma piuttosto specificando quale sottoreti di mettere Istanze ELB in.

Sì, ELB è un bilanciamento del carico software e quando si crea un oggetto ELB, un'istanza EC2 di bilanciamento del carico personalizzata viene inserita in tutte le sottoreti specificate. Quindi, affinché l'ELB (le sue istanze) siano accessibili, devono essere inserite nelle sottoreti che hanno una route predefinita configurata tramite IGW (molto probabilmente hai classificato queste subnet come pubbliche).

Pertanto, come già indicato sopra, è necessario specificare le reti "pubbliche" per ELB e quelle reti dovrebbero provenire dalle AZ in cui sono in esecuzione le istanze EC2. In questo caso le istanze ELB saranno in grado di raggiungere le istanze EC2 (purché i gruppi di sicurezza siano configurati correttamente)

+0

Hai fatto un punto importante nella tua prima frase. La Console AWS non è intuitiva in questo senso. Induce a credere che si sta facendo qualcosa di sbagliato quando non si visualizzano le istanze EC2 dalle proprie sottoreti private se si distribuisce l'ELB nelle sottorete pubbliche. –

Problemi correlati