Crisalid Online

1) Infrastructure
2) Sécurité et Disponibilité
3) Technologies
  3a) Hébergement
  3b) Applications
4) Architecture des applications
  4a) Crisalid Presse
  4b) Plateforme d’hébergement de sites Internet
  4c) Prise de commandes en ligne
  4d) Fidélité centralisée
  4e) Hébergement mutualisé
5) Problèmes rencontrés
6) Haute Disponibilité

Voici un point de la situation au sujet de l’infrastructure qui supporte l’hébergement de nos applications en ligne comme le logiciel de gestion de la presse, la plate-forme de sites Internet, le système de commandes en ligne ou la fidélité centralisée.

Nous avons subi quelques problèmes durant le mois de février 2011 sur cette infrastructure. Toutes les équipes techniques de notre hébergeur et l’équipe de développement de Crisalid a mis tout en oeuvre pour rétablir un fonctionnement normal. Aujourd’hui ces problèmes semblent résolus.

1) Infrastructure

La base de notre infrastructure est un cloud privé : deux machines physiques très puissantes qui nous appartiennent servent à faire fonctionner une dizaine de machines virtuelles sur lesquelles sont réparties les services dont nous avons besoin : bases de données (2 serveurs), serveurs d’application (4 serveurs), serveur d’hébergement mutualisé, reverse proxy et passerelles VPN. Les disques durs de ces deux machines physiques sont eux aussi virtualisés et ils sont gérés par un serveur de stockage fourni par notre hébergeur.

2) Sécurité et Disponibilité

Tous les disques de toutes nos machines virtuelles sont sauvegardés deux fois par jour (matin et soir) par un serveur de sauvegarde fourni et géré par notre hébergeur. Ces sauvegardes sont incrémentales (une sauvegarde complète tous les 15 jours et chaque jour, envoi des modifications depuis la dernière sauvegarde qui permettent de reconstruire n’importe quelle machine virtuelle dans l’état où elle se trouvait pendant les 14 jours précédents.)

Toutes les machines virtuelles sont monitorées par un serveur de monitoring en permanence et nous recevons des alertes par email dès qu’une machine ou un service monitoré ne répond plus.

Nous disposons aussi de graphes de charge et d’utilisation des machines en temps réel.

3) Technologies

Nous et notre hébergeur nous inscrivons dans la philosophie des logiciels libres aussi l’ensemble de tous les logiciels et systèmes d’exploitations qui sont utilisés dans cette infrastructure sont des logiciels libres.

3a) Hébergement

Toutes les machines virtuelles utilisent une version stable de la distribution Linux Debian. La configuration de toutes ces machines est centralisée et contrôlée par le logiciel libre Puppet, le monitoring est assuré par Munin et Nagios, eux aussi des logiciels libres. Le serveur de stockage fonctionne avec OpenFiler (une distribution de Linux dédiée pour ce genre d’utilisation). Le tout est cohérent avec l’ensemble du parc de machines physiques ou virtuelles gérées par notre hébergeur.

3b) Applications

Nos applications sont écrites dans le language Ruby utilisant le framework de développement d’applications Web Ruby on Rails et tout son écosystème. Nos serveurs de base de données sont des PostgreSQL ou des MySQL.

4) Architecture des applications

Nous pensons qu’il est nécessaire que vous compreniez comment nous avons choisi de fabriquer les logiciels que vous utilisez.

4a) Crisalid Presse

Crisalid Presse est spécifique à une catégorie précise de professionnels : les diffuseurs de presse et le cahier des charges de l’application est en partie imposé par les messageries de presse (Press’talis et MLP.) Les titres presse en vente sont déposés en dépôt-vente tous les jours et les invendus sont rappelés quotidiennement. Les diffuseurs sont facturés sur la base des titres qu’ils ont vendu. Le logiciel Crisalid Presse aide le diffuseur de presse à communiquer les informations logistiques (livraisons, ventes, invendus, demandes de réassort) entre les messageries, leurs dépôts (les dépôts sont régionaux) et le logiciel de caisse que le diffuseur utilise pour facturer ses clients finaux. La complexité vient essentiellement de l’aspect chronologique des échanges de fichiers : un bordereau d’invendus fait systématiquement suite à un ou plusieurs bordereaux de livraison et il est difficile de compléter un bordereau d’invendus si on n’est pas capable d’identifier les ventes qui ont été réalisées : les échanges de fichiers entre tous les acteurs sont permanents et nécessitent d’être réalisés selon un planning précis.

Comme le logiciel Crisalid Presse est une application Web centralisée et que le logiciel de caisse est une application installée chez le client, nous avons développé un agent de synchronisation dont le rôle est de récupérer les fichiers du client, de les envoyer au serveur de Crisalid Presse sur lequel ils seront traités , de rapatrier les titres en vente et de transmettre les ventes réalisées dans la journée. Une fois tous les traitements de la journée finalisés sur Crisalid Presse, les fichiers à retourner aux messageries sont récupérés depuis le serveur de Crisalid Presse par l’agent et déposés sur les serveurs des messageries.

Une partie des diffuseurs de presse est éligibles à l’obtention de sur-rémunérations calculées sur la fiabilité des mouvements de vente qu’ils remontent quotidiennement aux messageries. La fiabilité de ces informations est déterminée par plusieurs critères : pourcentage de titres scannés par un lecteur de code à barres lors de la vente et respect des délai pour l’envoi des mouvements de vente (le dernier fichier de ventes doit être remonté chaque jour avant 22h, tout retard ou tout fichier manquant est pénalisé.)

4b) Plateforme d’hébergement de sites Internet

Nous avons développé Webalid, une plateforme d’hébergement de sites Internet qui nous permet de partager un moteur de rendu de sites adaptés à notre clientèle de commerçants en leur fournissant une interfaçe d’administration complète.

Cette plateforme est aussi utilisée pour le rendu et l’administration du site Crisalid. Grâce à la base centralisée de stockage des contenus, nous n’avons qu’à développer une charte graphique (identité visuelle) pour chaque client et à en faire l’intégration Web pour que le site soit consultable en ligne.

4c) Prise de commandes en ligne

Le système de prise de commandes en ligne s’appuie sur la plateforme d’hébergement de sites Webalid. Un agent de synchronisation appelé Mailsteri installé chez le client permet de synchroniser le catalogue d’articles actif dans le système d’encaissement avec le catalogue de produits disponibles à la commande en ligne. Les commandes sont enregistrées sous forme de flux XML et l’agent de synchronisation les récupère régulièrement, les stocke sur le système local du client et les intègre sous forme de commandes rappelables par un numéro unique dans le système d’encaissement du client. Le client final n’a qu’à fournir ce numéro unique lorsqu’il vient chercher sa commande au magasin pour que le ticket correspondant s’affiche, puisse être modifié et encaissé comme n’importe quel autre ticket de caisse.

4d) Fidélité centralisée

L’intérêt d’un système de carte de fidélité pour les réseaux de magasins est qu’elles puissent être utilisées dans chacun des magasins de la chaîne : les achats sont centralisés et les avantages fidélité sont calculés par le serveur. Le client final peut utiliser son avantage fidélité dans n’importe quel point de vente raccordé au serveur. Bien entendu, comme chaque commerçant est différent, nous avons développé un système de calcul des avantages fidélité qui s’adapte à chacun de nos clients.

4e) Hébergement mutualisé

Tous nos clients ne souhaitent pas intégrer notre plateforme d’hébergement et d’autres souhaitent avoir une liberté totale. C’est pour cette raison que nous avons à notre disposition une plateforme d’hébergement mutualisée qui permet à ceux qui l’utilisent d’héberger leur nom de domaine, leur site internet PHP+MySQL via un accès FTP, de disposer d’adresses email et de listes de diffusion. Cette plateforme est construire autour d’un ensemble de logiciels libres (Apache, PHP, MySQL, Postfix, Mailman, Proftpd…) et l’ensemble est paramétrable directement en ligne grâce au panneau de contrôle web AlternC.

5) Problèmes rencontrés

Cette plate-forme d’hébergement est en production chez notre hébergeur depuis le mois d’août 2010 et le fonctionnement jusqu’à maintenant n’est pas parfait. L’avantage principal de ce modèle est de pouvoir rationaliser l’utilisation des machines physiques tout en séparant les différentes applications pour permettre de facilement monter en puissance : il suffit d’ajouter un nouveau serveur physique pour faire tourner de nouvelles machines virtuelles ou pour pouvoir allouer plus de ressources aux machines virtuelles existantes. En théorie, cette architecture permet de garantie une disponibilité maximale même en cas de maintenance d’une machine physique : il suffit de “déplacer” les machines virtuelles de la machine que l’on veut arrêter sur les autres machines du nuage. Même si une des deux machines physiques tombe, il est possible de redémarrer immédiatement le service sur l’autre pendant qu’on répare la première.

Auparavant, nous avions uniquement deux machines physiques dédiées qui faisaient fonctionner tous nos services en lignes : une machine était dédiée pour la plate-forme AlternC et l’autre servait pour toutes les applications web (Crisalid Presse, Webalid, Prise de commandes, serveur de bases de données…) et la défaillance d’un seul de ces services pouvait mettre en péril l’intégralité de la plate-forme. Sans parler d’une défaillance matérielle de la machine physique qui aurait mis immédiatement fin à tous les services Crisalid en ligne. Par exemple, il nous est arrivé que l’alimentation électrique de la salle dans laquelle est hébergée notre serveur soit coupée à cause d’une défaillance du disjoncteur principal.

Le chemin est long pour atteindre les objectifs que nous nous sommes fixés en termes de disponibilité : faire que l’ensemble des services Crisalid soient disponible 100% du temps dans des conditions de fonctionnement optimales.

Au début du mois de février 2011, nous avons subit une panne à laquelle nous ne nous attendions pas et qui va nous obliger à revoir cette architecture : le serveur de stockage des disques des machines virtuelles a atteint les limites de ses capacités et n’était plus capable de fournir les fichiers dont les machines virtuelles ont besoin pour fonctionner normalement. Les délais étaient devenus tellement longs que les traitements des fichiers pouvaient prendre jusqu’à 300 fois plus de temps qu’à l’ordinaire. Les conséquences pour nous et nos clients ont été lourdes et nous avons mis plus d’une semaine à en venir à bout : des fichiers avaient été importés plusieurs fois créant des doublons dans les bases de données, d’autres manquaient et les fichiers de vente, dont les contraintes de temps pour l’envoi aux messageries en soirée sont si importantes n’ont jamais été générés, ni envoyés.

L’équipe technique de notre hébergeur a fait le nécessaire pour mieux répartir les besoins en accès disque des différentes machines virtuelles et désormais, les serveurs semblent plus rapides que jamais (au moins deux fois plus rapides dans le temps de traitement des importations ou de génération des fichiers)

Malgré tout, le serveur de stockage reste une faille potentielle dans le système car la disponibilité de l’ensemble des machines repose sur lui.

Comme une panne ne vient jamais seule nous avons du faire face à un deuxième problème une semaine plus tard : une console d’administration a bloqué l’ensemble de toutes les machines virtuelles à la fois et le temps de trouver le défaut, les machines ont toutes été indisponibles pendant deux heures.

Nous sommes conscients que de tels problèmes à si peu de temps d’intervalle sont inacceptables, nous travaillons donc avec notre hébergeur pour atteindre l’objectif que tous les acteurs du Web recherchent pour leurs applications : la Haute Disponibilité.

6) Haute Disponibilité

La haute disponibilité, voire, la très haute disponibilité n’a qu’un seul objectif : garantir la disponibilité des services 100% du temps : 24h/24, 7j/7 même si des opérations de maintenance doivent être planifiées. En pratique, on admet que la disponibilité d’un service est excellente si on atteint le chiffre de 99.999% de disponibilité sur une année (soit moins de 6 minutes d’interruption de service par an !) et si on arrive à moins d’une heure d’indisponibilité par an on est quand même à 99.99% de disponibilité ce qui est encore très bon.

L’objectif de Crisalid est celui de toutes les sociétés qui hébergent des services en ligne : atteindre 100% de disponibilité.

Il est impensable d’atteindre cet objectif sans mettre en oeuvre au moins une technique : la redondance, tout doit être doublé. Nous avons déjà doublé les machines physiques et les serveurs de bases de données (par la mise en place d’un mécanisme de réplication des données) mais il nous faut désormais nous pencher sur la réplication du stockage des machines virtuelles et sur la réplication des machines virtuelles elles-mêmes. Notre hébergeur se charge de trouver des solutions de réplication du stockage des machines virtuelles (utilisation d’un autre logiciel libre, utilisé partout dans ce genre de situations : DRDB), de cette façon, même si le serveur principal de stockage est surchargé, plein ou défaillant, un autre serveur pourra prendre sa relève.

De notre côté nous ne pouvons pas mettre tous nos oeufs (et les vôtres) dans le même panier aussi nous avons choisi de dupliquer toute notre infrastructure chez un autre hébergeur dont les locaux sont situés ailleurs. Des mécanismes existent pour permettre au deuxième site de prendre la relève du premier s’il devient totalement indisponible (cas de la coupure de courant ou de la défaillance du système de virtualisation.)