La disponibilité de Zero-downtime dans un frontend de service Web sur EC2?

Nous avons une application Web à faible charge mais à haute disponibilité. Il se compose d'un seul équilibreur de charge et de plusieurs servers back-end. L'équilibreur de charge est principalement destiné à masquer les pannes, et non à répartir la charge.

Les servers back-end sont hautement disponibles via une réplication dans deux zones de disponibilité. Mais comment pouvez-vous rendre la pointe avant très disponible? Il s'agit actuellement d'un seul point d'échec.

Nous pourrions aller avec AWS Elastic Load Balancing, mais c'est un peu cher et nous n'avons pas vraiment besoin de la partie d'équilibrage de charge, alors: comment résoudriez-vous ce problème d'une autre manière?

Une idée qui se rapproche est de surveiller le front-end avec pings ou heartbeats; en cas d'expiration, basculez l'adresse Elastic IP de l'interface vers une autre machine configurée pour servir également de front-end. Mon principal souci avec cette approche est qu'il peut apparemment prendre 10 minutes pour que l'affectation IP élastique se propage.

Quelque chose avec un time de réponse plus rapide que cette approche? Pensez-vous qu'aucun time d'arrêt n'est possible?

Faire tourner cette question d'une autre manière: comment allez-vous accomplir cela dans un centre de données auto-hébergé régulier, où vous ne possédez pas AWS Elastic Load Balancing?

Rapide, fiable, pas cher. Choisissez les deux.

Honnêtement, cependant, "time d'arrêt zéro" est, à toutes fins utiles, impossible. Vous ne voulez aucun time d'arrêt, mais il ne semble pas que vous soyez prêt à dépenser l'argent nécessaire pour le faire.

Je crois que vous êtes sur la bonne voie avec des battements de coeur et faites pivoter l'IP du front end sur un autre nœud. Tout ce qui est plus impliqué que cela impliquerait soit de contracter les services d'un CDN comme Akamai ou Limelight, soit en obtenant un numéro AS, en configurant BGP, en obtenant une allocation IP, en configurant un équipement dans deux colos géographiquement distants et en répliquant des données entre eux. L'une de ces options serait assez coûteuse et complexe à mettre en œuvre.

Lorsque vous regardez le service ELB d'Amazon, gardez à l'esprit qu'il utilise un logging CNAME afin que vous ne puissiez pas équilibrer la racine de votre domaine (exemple.com). Vous devriez utiliser un sous-domaine comme http://www.example.com et requestr à la machine d'accepter le trafic envoyé à example.com redirect les clients vers http://www.example.com. Cela vous donne un seul point d'échec. Vous findez plus de discussions sur ce problème sur les forums Amazon: http://developer.amazonwebservices.com/connect/thread.jspa?threadID=32044

Votre propre numéro AS dans deux ou plusieurs réseaux de class opérateur est aussi proche des time d'arrêt zéro que vous obtiendrez. Avec les sites physiques muliple en ligne. Cela dit, EC2 est proche du time d'arrêt zéro.

En utilisant deux équilibreurs de charge sur actif / passif ou actif / actif, vous pouvez éviter d'être spoof.

Il suffit de penser que dans un scénario actif / actif, vos deux lb fonctionneront en même time et si l'un ou l'autre échoue, l'autre prend le relais.