<div dir="ltr"><div><div><div><div>Bonjour !<br><br>Ca me rappelle un projet sur lequel j'ai travaillé pour monter de manière auto des env de Prod/Recette/Int et les faire scaler automatiquement en réaction d'un dépassement de seuil sur l'outil de métrologie ou via une IHM : <a href="http://highscalability.com/blog/2011/6/13/automation-on-aws-with-ruby-and-puppet.html">Automation on AWS with Ruby and Puppet</a>.<br>
<br></div>Par contre nous n'avions pas géré l'automatisation de l'alimentation en data.<br><br></div><div>Pour la partie ordonnancement, j'avais mis en place un home-made Ruby scheduler. C'était il y a 2-3 ans. Peut-être que maintenant je regarderais du côté d'un <a href="https://juju.ubuntu.com/">Juju</a>. A voir. En tout cas ça marchait bien ! :o)<br>
</div><br></div>Cordialement,<br><br>Frédéric FAURE<br><i>Suivez-moi <a title="Frédéric FAURE @Twitter" href="http://twitter.com/fredericfaure" target="_blank">@Twitter</a></i></div><div><div><div class="gmail_extra"><br>
<div class="gmail_quote">Le 2 décembre 2013 15:38, Pierre FREUND <span dir="ltr"><<a href="mailto:pierre.freund@osones.com" target="_blank">pierre.freund@osones.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Bonjour,<br>
<br>
J'aimerais vous faire un retour d'expérience sur la création d'une
architecture cloud pour un site LAMP à fort pic de trafic en
périodes de fêtes. <br>
L'architecture est grandement améliorable, c'est un POC. Toutes
les remarques seront le bienvenu.<br>
<br>
J'ai réalisé ce travail sur AWS, mais d'ici peu de temps je pense
pouvoir également le faire sur OpenStack. Aujourd'hui il manque
principalement les services Load-balancers et base de donnée as a
service (Trove).<br>
<br>
Lors de l'intégration d'un client web sur Amazon Web Service, j'ai
imaginé une architecture "Environment as a Service", où la
création d'un environnement complet (préprod / test / dev) se
déploie aussi rapidement qu'une ressource.<br>
<br>
Je suis parti des paramètres suivants (vous pouvez remplacer AWS
par CloudWatt / Numergy ou autre ;) :<br>
<br>
- AWS fournit des ressources facturées à l'heure,<br>
- AWS fournit une API pour faire des snapshots de serveurs et de
bases de donnée,<br>
- AWS fournit un outil de déploiement automatisé nommé AWS
CloudFormation,<br>
- Le maintient des environnements de test ou validation coûte
cher, ne valide pas grand chose puisqu'il y a souvent des
différences de versions applicatives et/ou d'architecture,<br>
- Nous utilisons ces environnements souvent sur des périodes
définies, le reste du temps les serveurs tournent inutilement. <br>
<br>
D'où une certaine prise de conscience (peut-être que cela n'est
applicable qu'au web) :<br>
<br>
<b>Nous n'avons besoin que d'un seul environnement persistant : la
production. Lors de certaines périodes définies (parfois
régulières) nous avons besoin de copies de l'architecture de
production, avec l'applicatif et les données dans une version
définie (celle de la prod, celle de dev, ou autre).</b><b><br>
</b><br>
Techniquement, c'est réalisable. Avec tous les outils cloud dont
nous disposons aujourd'hui, notamment AWS CloudFormation(1) ou
OpenStack Heat(2), nous pouvons dupliquer une architecture
complète assez facilement. <br>
La copie d'un environnement de production apporte tout de même son
lot de problèmes :<br>
<br>
- Les logs : ils ne doivent pas disparaître lorsqu'un
environnement (ou stack) est supprimé,<br>
- Les datas : la production a sûrement fait évoluer ses datas
depuis le dernier backup, il n'est pas possible de se baser
uniquement sur le backup de la veille pour créer un nouvel
environnement iso-prod.<br>
- La configuration : elle est différente sur une pré-prod. Le
endpoint de la base de donnée change obligatoirement par exemple,<br>
- Les backups : si je veux sauvegarder mon environnement avant de
le supprimer, il me faut un endroit pour stocker des archives,
tous les serveurs de l'environnement étant supprimés.<br>
- Les tâches planifiées : si je copie la prod je vais copier des
crons éventuels...<br>
- La sécurité : les données de production, dont les informations
privées, se retrouvent accessibles.<br>
<br>
Je n'ai eu d'autre choix que de créer un serveur externe aux
environnements, appelé « orchestrateur » (voir schéma en pièce
jointe) regroupant plusieurs rôles :<br>
<br>
- Les logs : il fait office de rsyslog centralisé,<br>
- Les datas : au lancement de la stack, les fronts apache
téléchargent le dernier backup, puis font un rsync dans un dossier
spécial de l'orchestrateur contenant la dernière version de
l'application. C'est aussi ce process utilisé pour l'auto-scaling.
Faire un rsync sans charger le dernier backup est beaucoup trop
long pour ce client (plein de petits fichiers). NFS (ou
équivalent) est proscrit, ce serveur n'est volontairement pas
redondé et constituerait un spof,<br>
- La configuration : à terme l'orchestrateur sera un master
puppet/chef. Pour le moment c'est des sed horribles qui
reconfigurent les endpoints, users et pass,<br>
- Les backups : un script de backup cible l'environnement et
sauvegarde sur un bucket S3,<br>
- Les tâches planifiées : Les environnements ne lancent pas de
tâche, seul l'orchestrateur fait office de job scheduler. Il n'y a
donc pas de copie de tâches planifiées,<br>
- La sécurité : ce n'est pas encore traité, mais l'anonymisation
des données est réalisable. <br>
<br>
Avec cette architecture, en lançant un simple template dans AWS
CloudFormation, un nouvel environnement se crée en provisionnant
des fronts depuis une AMI standard et un backup de l'application.
La base de donnée est crée depuis le dernier snapshot de la base
de production. Tout le reste, supervision, load-balancer, DNS,
auto-scaling, est crée à la volée via AWS CloudFormation.<br>
<br>
<b>Copier sa production à la demande, c'est faisable.</b> La
cerise sur le gâteau, c'est qu'en transférant les backups sur une
autre zone (ou un autre fournisseur cloud compatible OpenStack
Heat(2)), le plan de reprise d'activité est inclus.<br>
<br>
(1) <a href="http://aws.amazon.com/fr/cloudformation/" target="_blank">http://aws.amazon.com/fr/cloudformation/</a><br>
(2) <a href="https://wiki.openstack.org/Heat" target="_blank">https://wiki.openstack.org/Heat</a><span class=""><font color="#888888">
<div style="font-family:arial,helvetica,sans-serif;font-size:small"><br>
</div>
</font></span></div><span class=""><font color="#888888">
<pre cols="72">--
Pierre FREUND
Cloud Solutions Architect | <a href="tel:%2B33%280%296.51.37.25.93" value="+33651372593" target="_blank">+33(0)6.51.37.25.93</a> | <a href="http://osones.com" target="_blank">osones.com</a></pre>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-fr mailing list<br>
<a href="mailto:OpenStack-fr@lists.openstack.org">OpenStack-fr@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-fr" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-fr</a><br>
<br></blockquote></div><br></div></div></div></div>