web-dev-qa-db-fra.com

Amazon ELB dans VPC

Nous utilisons Amazon EC2 et nous voulons mettre un ELB (équilibreur de charge) sur 2 instances sur un sous-réseau privé. Si nous ajoutons simplement le sous-réseau privé à l'ELB, il n'obtiendra aucune connexion, si nous attachons les deux sous-réseaux à l'ELB, il pourra accéder aux instances, mais il obtiendra souvent des délais d'expiration. Quelqu'un a-t-il réussi à implémenter un ELB dans le sous-réseau privé de son VPC? Si oui, pourriez-vous peut-être m'expliquer la procédure?

Merci

amazon-ec2amazon-web-servicesvpcamazon-elbamazon-vpc
69
Kevin Willock

Mon coéquipier et moi venons de mettre en œuvre ELB dans un VPC avec 2 sous-réseaux privés dans différentes zones de disponibilité. La raison pour laquelle vous obtenez des délais d'attente est que pour chaque sous-réseau que vous ajoutez à l'équilibreur de charge, il obtient une adresse IP externe. (essayez 'Dig elb-dns-name-here' et vous verrez plusieurs adresses IP). Si l'une de ces adresses IP mappe un sous-réseau privé, elle expirera. L'adresse IP qui correspond à votre sous-réseau public fonctionnera. Parce que DNS peut vous donner l'une des adresses IP, parfois cela fonctionne, parfois il arrive à expiration.

Après quelques échanges avec Amazon, nous avons découvert que l'ELB ne devait être placé que dans des sous-réseaux "publics", c'est-à-dire des sous-réseaux qui ont une route vers la passerelle Internet. Nous voulions garder nos serveurs Web dans nos sous-réseaux privés mais permettre à l'ELB de leur parler. Pour résoudre ce problème, nous devions nous assurer que nous avions un sous-réseau public correspondant pour chaque zone de disponibilité dans laquelle nous avions des sous-réseaux privés. Nous avons ensuite ajouté à l'ELB, les sous-réseaux publics pour chaque zone de disponibilité.

Au début, cela ne semblait pas fonctionner, mais après avoir tout essayé, nous avons recréé l'ELB et tout a fonctionné comme il se doit. Je pense que c'est un bug, ou l'ELB était juste dans un état étrange à cause de tant de changements.

Voici plus ou moins ce que nous avons fait:

  1. WebServer-1 s'exécute dans PrivateSubnet-1 dans la zone de disponibilité us-east-1b avec un groupe de sécurité appelé serveur Web.
  2. WebServer-2 s'exécute dans PrivateSubnet-2 dans la zone de disponibilité us-east-1c avec un groupe de sécurité appelé serveur Web.
  3. Créé un sous-réseau public dans la zone us-east-1b, nous l'appellerons PublicSubnet-1. Nous nous sommes assurés que nous avons associé la table de routage qui inclut la route vers la passerelle Internet (ig-xxxxx) à ce nouveau sous-réseau. (Si vous avez utilisé l'assistant pour créer un VPC public/privé, cette route existe déjà.)
  4. Créé un sous-réseau public dans la zone us-east-1c, nous l'appellerons PublicSubnet-2. Nous nous sommes assurés que nous avons associé la table de routage qui inclut la route vers la passerelle Internet (ig-xxxxx) à ce nouveau sous-réseau. (Si vous avez utilisé l'assistant pour créer un VPC public/privé, cette route existe déjà.)
  5. Création d'un nouvel ELB, en y ajoutant PublicSubnet-1 et PublicSubnet-2 (pas PrivateSubnet-X). Vous avez également choisi les instances à exécuter dans l'ELB, dans ce cas WebServer-1 et WebServer-2. Assurez-vous d'affecter un groupe de sécurité qui autorise les ports entrants 80 et 443. Appelons ce groupe elb-group.
  6. Dans le groupe de serveurs Web, autorisez le trafic provenant des ports 80 et 443 à partir du groupe elb.

J'espère que ça aide!

180
Nathan Pahucki

La clé ici est de comprendre que vous n'êtes pas "Ajouter des sous-réseaux/zones de disponibilité" à ELB, mais plutôt de spécifier dans quels sous-réseaux les instances ELB doivent être placées.

Oui, ELB est un équilibreur de charge logiciel et lorsque vous créez un objet ELB, une instance EC2 d'équilibrage de charge personnalisée est placée dans tous les sous-réseaux que vous avez spécifiés. Donc, pour que l'ELB (ses instances) soit accessible, elles doivent être placées dans les sous-réseaux dont la route par défaut est configurée via IGW (vous avez probablement classé ces sous-réseaux comme publics).

Ainsi, comme cela a déjà été répondu ci-dessus, vous devez spécifier des réseaux "publics" pour ELB, et ces réseaux doivent provenir des AZ où vos instances EC2 s'exécutent. Dans ce cas, les instances ELB pourront atteindre vos instances EC2 (tant que les groupes de sécurité sont correctement configurés)

13
RSH

Vous devez ajouter les paramètres suivants.

  1. Zone de sous-réseau public b = NAT du serveur
  2. Zone de sous-réseau privé c = serveur Web
  3. Zone de sous-réseau public c = ELB

L'astuce est le routage:

  1. Le routeur vers NAT est attaché avec la passerelle A.
  2. Le routeur vers le serveur Web est attaché au NAT.
  3. Le routeur vers le sous-réseau public est attaché avec la passerelle A.

Détails ELB:

1.Zone: Zone de sous-réseau public c 2.Instance: Serveur Web 3.Groupes de sécurité: activer les ports

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

2
Roberto Carlos Reyes Fernandez

Nous avons implémenté ELB dans un sous-réseau privé, donc la déclaration selon laquelle tous les ELB doivent être publics n'est pas complètement vraie. Vous avez besoin d'un NAT. Créez un sous-réseau privé pour les ELB privés, activez le DNS VPC, puis assurez-vous que la table de routage privée est configurée pour passer par le NAT. Les groupes de sécurité de sous-réseau doivent également être configurés pour autoriser le trafic entre ELB et App et les sous-réseaux App to DB.

Les contrôles d'intégrité Beanstalk ne fonctionneront pas car ils ne peuvent pas atteindre l'équilibreur de charge, mais pour les services qui doivent être hors de portée du public, c'est un bon compromis.

Lecture suggérée pour démarrer votre architecture VPC: http://blog.controlgroup.com/2013/10/14/guided-creation-of-cloudformation-templates-for-vpc/ .

2
Mike Lapinskas