Si j'arrête l'instance Amazon EC2 puis la redémarre, tout ira-t-il bien?


12

J'ai un site Web qui s'exécute sur une instance basée sur Linux Amazon EC2 et est mappé sur un nom de domaine normal (x.com). Ce site parle à une base de données sur une deuxième instance EC2.

Je dois fermer cette instance et augmenter la puissance de calcul derrière elle ... si je le fais, combien de temps cela prendra-t-il, puis quand je relancerai la machine, mon site reviendra-t-il simplement en ligne? L'adresse IP, les informations DNS, etc. seront-elles toutes préservées afin que le nom de domaine continue de fonctionner et qu'il puisse toujours parler à la base de données?

Pour info, c'est ce que je vois actuellement pour le serveur web dans le panneau d'informations AWS EC2 (les adresses IP exactes ont légèrement changé mais vous avez l'idée):

Public DNS: ec2-54-1-1-1.us-west-1.compute.amazonaws.com
Private DNS: ip-10-1-1-1.us-west-1.compute.internal
Private IPs: 10.1.1.1

Réponses:


13

Arrêter et démarrer une instance de démarrage EBS est très similaire au simple redémarrage de l'instance à quelques exceptions près, la plus notable étant:

  1. Une nouvelle adresse IP interne est attribuée à l'instance.

  2. Une nouvelle adresse IP publique est attribuée à l'instance.

  3. Si l'instance n'est pas dans un VPC, toute adresse IP Elastic est dissociée de l'instance.

  4. Toutes les données sur le stockage éphémère (souvent sous / mnt) sont perdues

Il y a également des implications de facturation et de disponibilité que j'ai décrites dans cet article:

Redémarrage ou arrêt / démarrage de l'instance Amazon EC2
http://alestic.com/2011/09/ec2-reboot-stop-start

Les instances VPC ont un comportement légèrement différent, notamment la conservation des adresses IP Elastic pendant l'arrêt / le démarrage.

Si vous utilisez une instance comme serveur de base de données et que vous souhaitez vous y connecter en utilisant l'adresse IP interne (moins chère, plus rapide) et que vous ne voulez pas avoir à reconfigurer les clients de base de données après un arrêt / démarrage, vous pouvez alors affecter une adresse IP Elastic à l'instance et utilisez le nom DNS Elastic IP externe. Cela résoudra l'adresse IP interne actuelle après avoir réassocié l'adresse IP Elastic à l'instance redémarrée et vos clients reprendront là où ils se sont arrêtés.

J'entre dans les détails de cette approche dans cet article:

Utilisation d'Elastic IP pour identifier les instances internes sur Amazon EC2
http://alestic.com/2009/06/ec2-elastic-ip-internal

Comme il semble que vous l'ayez anticipé, l'arrêt / le démarrage est un moyen simple de changer le matériel qui alimente votre instance. J'ai écrit à ce sujet avec quelques instructions et avertissements dans cet article:

Déplacement d'une instance EC2 vers un type d'instance plus grand (ou plus petit)
http://alestic.com/2011/02/ec2-change-type

Pour votre situation particulière, je recommanderais d'attribuer une adresse IP Elastic à l'instance et de changer votre DNS pour pointer vers l'adresse IP Elastic en utilisant un CNAME au nom DNS externe. Vous pouvez le faire juste après l'arrêt / démarrage, ou vous pouvez le faire à l'avance en vous assurant que tout fonctionne avant l'arrêt / démarrage.


Est-ce toujours exact? J'étais sur un chat avec le support AWS ce matin et ils ont dit que l'adresse IP élastique n'est pas dissociée lorsqu'une instance est arrêtée. De plus, je n'ai jamais vu nos adresses IP internes changer lors de l'arrêt et du démarrage d'une instance.
bshacklett

@bsacklett Cette réponse était un peu dépassée. Je l'ai mis à jour pour expliquer que seules les instances non VPC perdent l'IP élastique. Aujourd'hui, la plupart des instances sont en effet des VPC.
Eric Hammond

4

Il semble donc que vous n'utilisez pas Elastic IP, comme je peux le voir d'après vos informations.

Je crois que vous devez utiliser CNAME dans le DNS pour pointer vers cette instance. Si vous redémarrez votre ordinateur, ce ec2-54-1-1-1.us-west-1.compute.amazonaws.comnom DNS changera et votre site cessera de fonctionner.

En ce qui concerne l'IP interne, elle changera également, sauf si vous utilisez VPC, ce que vous n'utilisez pas.

Donc, si j'étais vous, je serai très prudent lors du redémarrage de cette machine.

En ce qui concerne le temps, cela ne prendra que quelques minutes.

De plus, si vous avez des iptables en cours d'exécution sur l'instance de base de données, qui autorise uniquement cette IP interne à se connecter à la base de données, cela ne fonctionnera pas non plus, car votre adresse IP interne changera.

Donc, faites attention si vous voulez redémarrer cette instance et réfléchissez-y bien.


2

Votre IP / nom d'hôte interne changera et votre IP élastique se détachera (sauf si vous êtes dans un VPC).

Rattachez l'adresse IP élastique après avoir redémarré l'instance. Je le fais régulièrement pour changer la taille des instances et vous ne regardez que quelques minutes de temps d'arrêt.

Vérifiez qu'Apache et tous les autres services sont configurés pour démarrer ( chkconfigsi vous exécutez Amazon linux ami).


1

Pour autant que je me souvienne, arrêter le système de changer son type et le redémarrer ne devrait pas prendre plus de 5 à 10 minutes (cela ne dit pas que c'est un système soutenu par EBS). Pour que les services démarrent une fois que le système est de retour, assurez-vous que tous les services sont activés pour démarrer au redémarrage (comme pour marionnette sur mon ubuntu 12.04, je l'ai activé dans / etc / default / puppet). Notez l'IP (je l'ai fait il y a longtemps, donc ne me souvenez pas clairement) et tout au plus votre IP peut se détacher du système, mais elle serait toujours là dans votre compte, alors allez dans la section IP élastique et associez-la à nouveau avec le système redémarré et tout ira bien.


1

Comme déjà mentionné, si vous avez une IP élastique, elle se rattachera à l'instance, de sorte que vos paramètres DNS ne devraient pas avoir besoin d'être modifiés. D'une manière ou d'une autre, cependant, votre adresse IP privée changera. Cela signifie probablement que vous devrez mettre à jour vos paramètres GRANT dans mysql. 'Parce que tu n'es pas juste GRANT ALL PRIVILEGES ON *.* to 'somedude'@'%'... non? ;)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.