Comment automatisez-vous le basculement sur EC2?


13

Parmi les gens qui gèrent leurs propres clusters (c'est-à-dire qui n'utilisent / ne paient pas pour Amazon Autoscale, Rightscale, Scalr, etc.), comment gérez-vous vos instances sur EC2 et gérez-vous (par exemple) le basculement? Je me demande si la plupart des gens finissent par écrire leurs propres cargaisons de scripts contre l'API EC2, comme je le soupçonne.

C'est certainement notre approche: créer notre propre démon de surveillance / redémarrage basé sur Python Boto qui s'exécute hors site, à l'écoute des subsistances UDP de nos instances. En cas d'échec, nous clichons des volumes, enregistrons des images, démarrons de nouvelles instances, supprimons d'anciens volumes, etc.

De temps en temps, lors du piratage de nos scripts, je pense qu'il doit y avoir des outils open source qui traitent déjà de ces problèmes, et qui n'ont pas les contraintes de (par exemple) Scalr, mais je reviens toujours de Google les mains vides. (Des choses comme Scalr sont assez limitées dans les ensembles / versions / configurations de logiciels pris en charge, et ont des méthodes lourdes spécialisées et IMO pour manipuler ces configurations.)

De plus, l'écosystème Linux-HA / Pacemaker (Heartbeat, ldirectord, etc.) semble ne pas être vraiment adapté à EC2 . (Mais j'ai trouvé cela - même si je ne suis pas sûr que ce soit vraiment une solution de haute qualité).

Réponses:


5

Eh bien, je ne veux pas simplement dire l'évidence, mais l'idée générale est de pousser cette complexité dans les services gérés par Amazon.

Donc, sur le frontend, vous utiliseriez Amazon Elastic Load Balancing (ELB) pour fournir un équilibrage de charge hautement disponible. À l'arrière, vous utilisez Amazon Relational Database Service (hébergé MySQL), SimpleDB et S3 pour le stockage. Tous ces éléments sont gérés par Amazon et contiennent une sorte de gestion de haute disponibilité / basculement.

Cela laisse généralement vos serveurs d'applications Web et tous les types de serveurs moins courants que vous utilisez (serveurs de rendu, magasins de données NoSQL auto-installés, etc.).

Les serveurs Webapp sont généralement bien gérés avec les contrôles d'intégrité intégrés à ELB. Vous pouvez accepter une légère dégradation des performances lorsqu'un serveur Webapp est en panne, ou provisionner systématiquement +1 serveur de plus que nécessaire. Ou si votre configuration est simple, alors lorsqu'un serveur Webapp tombe en panne, ELB et Cloudwatch peuvent générer automatiquement un nouveau serveur Webapp pour vous.

Vos propres serveurs personnalisés sont une autre affaire. Pour ceux-ci, il est vrai que vous êtes seul et que vous devrez vous contenter des méthodes intégrées à l'application ou du ruban adhésif avec des scripts personnalisés / des outils HA open source.

Acheter la solution de Rightscale pourrait être trop cher. Mais les outils Amazon moins chers tels que ELB, les alertes de base CloudWatch (désormais gratuites pour une résolution de 5 minutes) ou AutoScale en valent la peine si vous avez besoin d'une haute disponibilité.


3
Nous connaissons l'ensemble des fonctionnalités AWS, ainsi que leurs limites. Pour prendre votre premier exemple, ELB est accessible via des RR CNAME, qui ne peuvent pas coexister avec des RR SOA, et ne peuvent donc pas servir de TLD, et ne peuvent pas non plus être accessibles via des adresses IP statiques - des frustrations largement évoquées dans les forums. Pour prendre votre deuxième exemple, oui, RDS est MySQL, qui est la limitation géante. Oui, nous souhaitons automatiser le basculement de nos propres types de machines. Oui, le déploiement de cloud privé nous concerne. Oui, je suis juste curieux. Etc.
Yang

2
@Yang: Vous auriez dû formuler votre question plus attentivement et m'éviter de taper ma réponse. Il n'y a pas de solution unique à HA; cela dépend du service en question, de la façon dont l'état est conservé, des propriétés de basculement de protocole, etc. Vous avez raison sur les limitations / difficultés à utiliser des outils HA de niveau IP typiques sur EC2. Mais il n'y a pas de réponse unique qui s'applique universellement à "HA sur AWS".
Jesper M

0

RightScale a d'excellents articles sur la façon d'automatiser le basculement sur EC2. Alors que la plupart d'entre eux vous montrent comment le faire en utilisant RightScale lui-même, les principes sont généraux et probablement utiles à quiconque pense à la façon de configurer une architecture de basculement sur EC2.


0

Les problèmes que vous décrivez (HA, surveillance des serveurs personnalisés, services de «gainage») sont généralement traités par un fournisseur PaaS. Rightscale et Scalr ont déjà été mentionnés dans une réponse précédente et il existe de bonnes options supplémentaires (voir ici pour certaines options PaaS:

/programming/9542784/looking-for-paas-providers-recommendations )

Vous devez déterminer lequel des prestataires correspond le mieux à vos besoins.

Avis: je travaille pour Cloudify, un fournisseur PaaS open source.


0

J'ai récemment écrit un article sur notre blog d'ingénierie sur la façon d'utiliser ELB en conjonction avec Auto Scaling pour réaliser un basculement automatique pour tout type d'application. Il explique comment les contrôles d'intégrité ELB peuvent être utilisés pour exécuter un ping sur l'état de votre application et déclencher des actions de mise à l'échelle automatique.


0

Vous installez Heartbeat sur les deux serveurs Vous attachez une IP élastique au serveur «actif» Vous configurez un script pour effectuer le basculement en lançant une demande d'API pour obtenir l'IP élastique Dès que le serveur «de secours» a obtenu l'IP élastique ( prend environ 30-60 secondes), il peut être le maître / actif.

Je n'ai pas les détails à fournir ici.


-1

Amazon fournit déjà un équilibrage de charge élastique ... Pourquoi réinventer la roue?


3
En raison des diverses limitations d'ELB? Parce qu'il nécessite CNAME et ne peut pas servir à la fois foo.com et www.foo.com? Parce que je veux implémenter une logique de planification personnalisée? Parce que je suis simplement curieux de savoir comment vous implémenteriez ELB vous-même dans un cluster de machines virtuelles peu fiables? Faites votre choix.
Yang

@Yang, vous le faites de la même manière que s'il s'agissait de serveurs dans votre centre de données. Il n'y a aucune différence fondamentale, aucune sauce magique qui en fait un environnement cloud.
Chris S
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.