Adresse IP EC2 : Comment un serveur web peut-il identifier l'adresse IP d'un serveur de données au démarrage ?

Vous devez partir du principe que vous ne pouvez pas utiliser un mécanisme de diffusion-réponse comme DHCP pour cette tâche, ce qui signifie que la seule option restante est de mettre à jour et d'interroger un répertoire quelque part.

DNS dynamique (par exemple, DNS UPDATE ; RFC 2136 ) est une solution évidente. Si vous avez déjà un serveur de noms, cette solution prend environ 5 minutes à mettre en place. Voir http://linux.yyz.us/nsupdate/ pour un tutoriel de démarrage rapide sur la mise en place de bind pour les mises à jour dynamiques et en utilisant le nsupdate commandement. Voir cet article de blog pour des informations sur l'utilisation du DDNS avec Route 53.

Vous pouvez également créer votre propre solution en utilisant quelque chose comme un simple script PHP privé sur un serveur web quelque part pour gérer les mises à jour de l'enregistrement des IP et les mécanismes de réponse aux requêtes. Cette solution est évidemment un peu plus flexible, mais elle n'a pas l'élégance simple du DDNS.

Je suggère que l'une des solutions consiste à utiliser le nuage privé virtuel (VPC) d'Amazon - cela semble être un bon cas d'utilisation. (En outre, le VPC n'a pas de coût supplémentaire, dans ce scénario).

Essentiellement, vous pourriez créer un nouveau VPC et un sous-réseau public (généralement 10.0.0.0/24) au sein de ce VPC. Puis lancer les deux instances dans le sous-réseau.

• Lancez l'instance websphere dans le sous-réseau et associez-lui une IP élastique.
  • Remarque : vous avez besoin d'IPs Elastiques VPC spéciales - les IPs normales ne fonctionnent pas dans VPC - lors de leur allocation, spécifiez le domaine comme 'vpc'.
• Lancez l'instance Oracle, et passez le paramètre PrivateIpAddress avec une adresse IP valide de votre sous-réseau.
  • Ceci assignera l'IP privée demandée à votre instance, elle sera disponible pour les autres instances dans le VPC (mais pas d'accès internet sans une IP élastique dans le VPC) et vous ne gaspillerez pas d'adresses IP publiques. Il convient de noter que les adresses VPC sont conservées pendant toute la durée de vie de l'instance - même si l'instance est arrêtée, l'adresse n'est pas dissociée. De plus, vous ne pouvez pas router le trafic entre les instances d'un VPC en utilisant une IP élastique.

Bien sûr, dans cette configuration ou dans toute autre configuration n'utilisant pas de NAT, chaque instance ayant un accès à Internet se verra attribuer une IP publique (même si ce n'est pas une adresse IP élastique). Ce n'est qu'en utilisant à la fois des sous-réseaux privés et publics avec une instance NAT configurée pour le routage, que vous pouvez permettre à une instance de ne pas avoir d'IP publique du tout, tout en étant capable d'accéder à Internet. (L'inconvénient, bien sûr, est que pour une petite configuration - par exemple 2 instances - vous avez besoin d'une 3ème instance pour effectuer le NAT, ce qui n'est pas pratique).

Pour en savoir plus :

• Communiqué de presse de l'AWS : Attribution des adresses IP
• Référence EC2-run-instances (Notez les options spécifiques au VPC)
• Sous-réseaux publics sur VPC

Vous pouvez demander au serveur de la base de données d'enregistrer un enregistrement CNAME DNS dynamique au démarrage.

Je fais quelque chose de similaire pour un serveur que nous appellerons mydb. (Les noms d'hôtes et les IP ont été modifiés pour protéger les identités).

sortie de 'dig mydb.e

mydb.example.net.       108     IN      CNAME   ec2-123-45-6-7.compute-1.amazonaws.com.
ec2-123-45-6-7.compute-1.amazonaws.com. 258 IN A 123.45.6.7

résultat de 'dig mydb.example.net' à partir d'AWS

mydb.example.net.       108     IN      CNAME   ec2-123-45-6-7.compute-1.amazonaws.com.
ec2-123-45-6-7.compute-1.amazonaws.com. 258 IN A 10.2.2.2

Notez le délai d'attente relativement faible (108s) pour cet enregistrement CNAME.

Lorsque le serveur mydb est lancé, il modifie l'enregistrement CNAME pour pointer vers le NOUVEAU nom dynamique AWS.

Un autre point positif est que selon que vous êtes à l'extérieur ou à l'intérieur de la PIC, vous obtiendrez une réponse différente. (la réponse la plus rentable)

L'utilisation d'une IP élastique évite d'avoir à attendre le délai d'expiration TTL du DNS, ce qui est appréciable, mais si vous pouvez vivre avec un délai d'expiration TTL du DNS pour mettre en place un nouveau serveur de base de données (vous devriez avoir un serveur de base de données de basculement à mydb2.example.net prêt en permanence, n'est-ce pas ?) ), alors cette solution pourrait vous convenir.

Il n'y a que trois solutions possibles (lorsque l'EIP n'est pas une option) et vous semblez avoir déjà une idée générale de ces solutions :

1. Utilisez le dns dynamique. Vous pouvez faire en sorte que votre base de données mette à jour une zone hébergée dans Route53 avec son adresse IP privée. Route53 permet des TTL très bas. Vos serveurs websphere devraient toujours savoir qu'ils doivent se connecter à l'enregistrement A désigné de Route53, par exemple mydb.internal.mydomain.com.

2. Utilisez les balises pour marquer le rôle et l'adresse IP de votre instance de base de données. Demandez ensuite à votre serveur Websphere de rechercher les instances étiquetées comme serveur de base de données et de découvrir leur adresse IP.

3. Utilisez un VPC et spécifiez l'IP privée pour votre instance de DB au lancement. Vos instances websphere se connectent toujours à la même IP désignée.

J'éviterais un VPC s'il n'est pas nécessaire et compte tenu de votre description ci-dessus, il ne semble pas justifié d'après ce que je comprends.