Amazon ELB dans VPC

Question

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

Merci

Answer 1

Mon coéquipier et moi venons de mettre en œuvre ELB dans un VPC avec deux 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 correspond à un sous-réseau privé, le délai d'attente est dépassé. L'adresse IP qui correspond à votre sous-réseau public fonctionnera. Comme le DNS peut vous donner n'importe laquelle des adresses IP, parfois cela fonctionne, parfois il y a un délai d'attente.

Après quelques échanges avec amazon, nous avons découvert que l'ELB ne devait être placé que dans les sous-réseaux "publics", c'est-à-dire les 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 communiquer avec eux. Pour résoudre ce problème, nous avons dû 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 prévu. Je pense qu'il s'agit d'un bogue, ou que l'ELB était simplement dans un état bizarre à cause de tant de changements.

Voici plus ou moins ce que nous avons fait :

1. WebServer-1 est exécuté dans PrivateSubnet-1 dans la zone de disponibilité us-east-1b avec un groupe de sécurité appelé web-server.
2. WebServer-2 est exécuté dans PrivateSubnet-2 dans la zone de disponibilité us-east-1c avec un groupe de sécurité appelé web-server.
3. Création d'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 comprend 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éation d'un sous-réseau public dans la zone us-east-1c, nous l'appellerons PublicSubnet-2. Nous avons veillé à associer à ce nouveau sous-réseau la table de routage qui comprend la route vers la passerelle Internet (ig-xxxxx). (Si vous avez utilisé l'assistant pour créer un VPC public/privé, cette route existe déjà).
5. Création d'une nouvelle ELB, en y ajoutant PublicSubnet-1 et PublicSubnet-2 (pas le PrivateSubnet-X). Choisissez également 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-group.
6. Dans le groupe web-server, autorisez le trafic des ports 80 et 443 du groupe elb.

J'espère que cela vous aidera !

Answer 2

Il est important de comprendre que vous n'êtes pas en train d'"ajouter des sous-réseaux/zones de disponibilité" à ELB, mais plutôt de spécifier dans quels sous-réseaux placer les instances ELB.

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. Ainsi, 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).

Donc, comme il 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 sont exécutées. Dans ce cas, les instances ELB seront en mesure d'atteindre vos instances EC2 (pour autant que les groupes de sécurité soient configurés correctement).

Answer 3

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

Les contrôles de santé de 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.

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

Answer 4

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

Le truc, c'est le routage :

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

Détails de l'ELB :

1.Zone : Zone de sous-réseau public c 2.Instance : Serveur Web 3. groupes de sécurité : ports d'activation

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