[OpenStack-fr] Concept : Environment as a Service
Pierre FREUND
pierre.freund at osones.com
Lun 2 Déc 14:38:30 UTC 2013
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
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstack.org/pipermail/openstack-fr/attachments/20131202/66602a17/attachment-0001.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: EaaS.png
Type: image/png
Taille: 53569 octets
Desc: non disponible
URL: <http://lists.openstack.org/pipermail/openstack-fr/attachments/20131202/66602a17/attachment-0001.png>
More information about the OpenStack-fr
mailing list