[OpenStack-fr] Concept : Environment as a Service

Frédéric FAURE fred.faure at gmail.com
Mar 3 Déc 11:24:25 UTC 2013


Bonjour !

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
: Automation on AWS with Ruby and
Puppet<http://highscalability.com/blog/2011/6/13/automation-on-aws-with-ruby-and-puppet.html>
.

Par contre nous n'avions pas géré l'automatisation de l'alimentation en
data.

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 Juju <https://juju.ubuntu.com/>. A voir. En tout cas ça
marchait bien ! :o)

Cordialement,

Frédéric FAURE
*Suivez-moi @Twitter <http://twitter.com/fredericfaure>*

Le 2 décembre 2013 15:38, Pierre FREUND <pierre.freund at osones.com> a écrit :

>  Bonjour,
>
> 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.
> L'architecture est grandement améliorable, c'est un POC. Toutes les
> remarques seront le bienvenu.
>
> 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).
>
> 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.
>
> Je suis parti des paramètres suivants (vous pouvez remplacer AWS par
> CloudWatt / Numergy ou autre ;) :
>
> - AWS fournit des ressources facturées à l'heure,
> - AWS fournit une API pour faire des snapshots de serveurs et de bases de
> donnée,
> - AWS fournit un outil de déploiement automatisé nommé AWS CloudFormation,
> - 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,
> - Nous utilisons ces environnements souvent sur des périodes définies, le
> reste du temps les serveurs tournent inutilement.
>
> D'où une certaine prise de conscience (peut-être que cela n'est applicable
> qu'au web) :
>
> *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).*
>
> 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.
> La copie d'un environnement de production apporte tout de même son lot de
> problèmes :
>
> - Les logs : ils ne doivent pas disparaître lorsqu'un environnement (ou
> stack) est supprimé,
> - 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.
> - La configuration : elle est différente sur une pré-prod. Le endpoint de
> la base de donnée change obligatoirement par exemple,
> - 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.
> - Les tâches planifiées : si je copie la prod je vais copier des crons
> éventuels...
> - La sécurité : les données de production, dont les informations privées,
> se retrouvent accessibles.
>
> 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 :
>
> - Les logs : il fait office de rsyslog centralisé,
> - 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,
> - 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,
> - Les backups : un script de backup cible l'environnement et sauvegarde
> sur un bucket S3,
> - 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,
> - La sécurité : ce n'est pas encore traité, mais l'anonymisation des
> données est réalisable.
>
> 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.
>
> *Copier sa production à la demande, c'est faisable.* 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.
>
> (1) http://aws.amazon.com/fr/cloudformation/
> (2) https://wiki.openstack.org/Heat
>
>  --
> Pierre FREUND
> Cloud Solutions Architect | +33(0)6.51.37.25.93 | osones.com
>
>
> _______________________________________________
> OpenStack-fr mailing list
> OpenStack-fr at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstack.org/pipermail/openstack-fr/attachments/20131203/516afcea/attachment.html>


More information about the OpenStack-fr mailing list