Amazon ELB en VPC

Question

Nous utilisons Amazon EC2, et nous voulons mettre un ELB (load balancer) à 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 aura souvent des délais. Est-ce que quelqu'un a implémenté avec succès un ELB dans le sous-réseau privé de leur VPC? Si oui, pourriez-vous m'expliquer la procédure?

Merci

Answer 1

Mon coéquipier et moi avons simplement mis en œuvre ELB dans un VPC avec 2 sous-réseaux privés dans les différentes zones de disponibilité. La raison pour laquelle vous obtenez des délais 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 allers-retours avec Amazon, nous avons découvert que l'ELB ne doit être placé que dans des sous-réseaux 'public', c'est-à-dire des sous-réseaux qui ont une route vers la passerelle Internet. Nous voulions conserver 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 à 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 de tant de changements.

Voici plus ou moins ce que nous avons fait:

1. WebServer-1 est en cours d'exécution dans PrivateSubnet-1 dans la zone de disponibilité nous-est-1b avec le 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é web-server.
3. Créer un sous-réseau public dans la zone us-east-1b, nous l'appellerons PublicSubnet-1. Nous avons veillé à associer la table de routage qui inclut la route à la passerelle Internet (ig-xxxxx) à ce nouveau sous-réseau. (Si vous avez utilisé l'assistant pour créer un VPC public/privé, cet itinéraire existe déjà.)
4. Créé un sous-réseau public dans la zone us-east-1c, nous l'appellerons PublicSubnet-2. Nous avons veillé à associer la table de routage qui inclut la route à la passerelle Internet (ig-xxxxx) à ce nouveau sous-réseau. (Si vous avez utilisé l'assistant pour créer un VPC public/privé, cet itinéraire existe déjà.)
5. Créé un nouvel ELB, en y ajoutant PublicSubnet-1 et PublicSubnet-2 (pas le PrivateSubnet-X). En outre, sélectionné les instances à exécuter dans l'ELB, dans ce cas WebServer-1 et WebServer-2. Assurez-vous d'assigner un groupe de sécurité qui autorise les ports entrants 80 et 443. Appelons ce groupe elb-groupe.
6. Dans le groupe de serveurs Web, autorisez le trafic provenant des ports 80 et 443 du groupe elb.

J'espère que cela aide!

Answer 2

Nous avons implémenté ELB dans un sous-réseau privé, donc l'affirmation que 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 DNS VPC et 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 App pour les sous-réseaux DB.

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

Suggestions de lecture pour lancer l'architecture VPC: http://blog.controlgroup.com/2013/10/14/guided-creation-of-cloudformation-templates-for-vpc/.

Answer 3

Vous devez ajouter les paramètres suivants.

1. zone sous-réseau public b = Le serveur NAT
2. zone de sous-réseau privé c = Serveur Web
3. zone sous-réseau public c = ELB

L'astuce est routage:

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

détails ELB:

1.Zone: zone sous-réseau public c 2.Instance: serveur Web 3.Security Groupes: enable ports

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

Answer 4

La clé est de comprendre ici, que vous n'êtes pas « Ajout/sous-réseaux zones de disponibilité » à ELB, mais plutôt préciser ce que les sous-réseaux à mettre Instances ELB dans.

Oui, ELB est un équilibreur de charge logiciel et lorsque vous créez un objet ELB, une instance personnalisée d'équilibrage de charge EC2 est placée dans tous les sous-réseaux que vous avez spécifiés. Ainsi, pour que l'ELB (ses instances) soit accessible, ils doivent être placés 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).

Comme cela a déjà été répondu ci-dessus, vous devez spécifier les réseaux «publics» pour ELB, et ces réseaux doivent provenir des AZ où vos instances EC2 sont en cours d'exécution. Dans ce cas, les instances ELB seront en mesure d'atteindre vos instances EC2 (tant que les groupes de sécurité sont configurés correctement)