Centralisation des logs Windows vers Linux via syslog

[Article publié sur linuxfr.org]

Intro

Lorsqu’on gère un parc de serveur qui comprend malheureusement des serveurs Windows, on souhaite centraliser leurs logs, voir même recevoir des alertes en fonction du contenu. C’est simple à faire sous Linux avec rsyslog, avec lequel je transmets les syslogs vers l’excellent Graylog2. Par contre dans le monde Windows il n’y a pas de serveur syslog natif. J’avais donc trouvé MonitorWare Agent un impressionnant logiciel propriétaire qui permet de définir des services qui vont lire n’importe quel type de logs, puis associer à ces services des ruleset qui vont déclencher une action comme faire suivre les logs vers un serveur syslog. L’interface graphique permet de créer un nombre de services et de rulesets impressionnants pour enchaîner des actions les plus tordus.
Le seul problème est le coût de la licence à environ 200€ par serveur, ce qui peut être bloquant.

NXLOG

Prêt à laisser tomber, mon collègue et voisin de bureau @ponteilla m’a judicieusement déniché le logiciel libre nxlog qui permet de faire exactement la même chose, sans interface graphique mais ça nous fait pas peur. Après de nombreux tâtonnement et quelques mails sur la liste j’ai pu transmettre les logs d’une application qui rotate elle meme ses logs en donnant un nouveau nom au log en cours (gruik)… Cependant nxlog permet d’utiliser des wildcard sur les noms des fichiers (*.log par ex) et même d’être récursif en allant lire tous les logs dans chaque sous répertoire. Un processor transformer permet de formater le log selon la RFC syslog voulue.
La doc montre le workflow très poussé de nxlog qui permet des enchaînements vraiment tordu, genre intégrer un schéduler dans un module input, surveiller un fichier de log et le convertir en CVS vers un autre fichier xm_csv_example. Il intègre également un langage qui permet par exemple de tester une expression régulière sur un flux en entrée :

if $Message =~ /^Test (\S+)/ log_info("captured: " + $1); 

Workflow

En entrée on choisi un input module (fichier, sgbd, syslog, tcp/udp, ..), puis un processor module qui va transformer ou filtrer les datas, puis un output module (sgbd, syslog, tcp/udp, file, ..) enfin via la directive route on enchaîne ces modules entre eux. Je n’ai que survolé les possibilités du soft, mais au vu de sa richesse et de sa licence GPL/LGPL je suis plutôt surpris de ne pas le trouver dans les dépôts debian/ubuntu.

Config basique fichiers de logs (*.log) -> serveur Graylog2 Linux (syslog)

Voici ma config qui fonctionne. Le serveur Windows communique avec Graylog2 sous Linux via OpenVPN. Pour aider au paramétrage j’ai lancé sur le Linux un tcpdump pour vérifier que les paquets arrivaient bien, avec la facility voulue :

tcpdump -i tap0 "udp port 514" 

Le fichier de conf nxlog.conf

## This is a sample configuration file. See the nxlog reference manual about the
## configuration options. It should be installed locally and is also available
## online at http://nxlog.org/nxlog-docs/en/nxlog-reference-manual.html
## Please set the ROOT to the folder your nxlog was installed into,
## otherwise it will not start.
define ROOT C:\Program Files\nxlog
# define ROOT C:\Program Files (x86)\nxlog
define CERTDIR %ROOT%\cert
define CONFDIR %ROOT%\conf
define LOGDIR %ROOT%\data
Moduledir %ROOT%\modules
CacheDir %ROOT%\data
Pidfile %ROOT%\data\nxlog.pid
SpoolDir %ROOT%\data
LogFile %ROOT%\data\nxlog.log
LogLevel INFO
<Extension syslog>
 Module xm_syslog
</Extension>
<Input in>
 Module im_file
 File "C:\monapp\log\\*.log" # lit tous les .log dans tous les sous répertoires !
 Exec $Message = $raw_event;
 SavePos TRUE
 Recursive TRUE
</Input>
<Processor transformer>
 Module pm_transformer
 Exec $SyslogFacilityValue = syslog_facility_value("local2");
 OutputFormat syslog_rfc3164
</Processor>
<Output out>
 Module om_udp
 Host 10.8.0.1 # IP du serveur Linux sur lequel écoute graylog2 server
   Port 514
</Output>
<Route 1>
Path in => transformer => out
</Route> 

le confort contre la liberté

[Article publié sur Linuxfr.org] source @zifro

Je viens de tomber sur APPLE, LA TYRANNIE DU COOL qui contient cette phrase :

Tim Wu, qui compare le succès de Steve Jobs à celui d’Hollywood, en soulignant que l’humanité préfère en général « la facilité et le confort » à la liberté

Je vais tenter de décortiquer cette phrase qui me parait très lumineuse, et possède plusieurs niveaux de profondeur pour nous Linuxiens.

En effet si nous sommes tous d’accord ici pour dénoncer la perte de nos libertés fondamentales lorsqu’on utilise un produit Apple, il en est pas de même pour reconnaître la faiblesse du logiciel libre qui ne le rend pas assez attrayant face aux produits Apple/Google. Pour certains le client Apple est idiot, pour d’autres il est bling bling, pour d’autres il est anti-microsoft primaire ou bien il peut être tout ça.

Cette histoire de confort me rappelle une histoire, vraie il me semble, sur un test de scientifiques effectué sur des chimpanzés. Ils fournissaient 2 moyens à ceux-ci pour obtenir des bananes. Un très complexe à base de cordes et de poulies et un autre très simple qui permet de prendre les bananes en tendant le bras à travers des barreaux légèrement électrifié. Il s’est avéré que le stress généré par la peur du courant électrique était moins important que celui généré via le système de poulies pourtant sans douleur.

Rapporté à l’être humain, cette histoire tend à démontrer qu’il préférerait le moyen le plus simple pour effectuer des tâches courantes, quelque soit les inconvénients. Donc même si ces tâches sont effectuées via des logiciels libres offrant plus de libertés, elles seront la plupart du temps plus stressante qu’un logiciel ou surtout qu’un écosystème propriétaire comme Apple ou Google plus agréable.

Si l’on admet cette réalité, d’autant plus pour des personnes dont l’informatique n’est qu’un outil qui ne les occupent qu’une infime partie de leur temps par rapport à nous, on ne devrait plus perdre du temps à pratiquer le dénigrement ou le mépris envers ces personnes, mais comment rendre les logiciels libres plus agréable.

Le cloud

C’est un système très justement dénoncé par le risque de perte de la vie privée contenue dans nos données. Il est pourtant le pilier des écosystèmes d’Apple, de Google, et prochainement de Microsoft. Cet outil permet et permettra encore plus de simplifier la synchronisation des données personnelles, des applications et des personnalisations.
Il est l’outil indispensable à l’amélioration du confort de l’utilisateur, et pourtant nous ne faisons que le dénigrer voir dénoncer la dangerosité d’un tel système en le baptisant par certains Minitel 2.0

Certains travaillent à concevoir des logiciels libres alternatifs aux outils propriétaires les plus connus basés sur le cloud, comme movim ou diaspora. D’autres comme la FSFFrance ou tuxfamily proposent d’héberger des logiciels libres. Même si ces 2 types d’initiative pourraient conjointement arriver à un début d’alternative, encore faudrait-il une équipe de techniciens pour maintenir et faire évoluer l’infrastructure. Or nous l’avons vu avec l’APINC et Tuxfamily, ce type de service basé sur le bénévolat est par définition non pérenne.

L’autre solution est l’auto-hébergement, ce qui revient à renvoyer à l’utilisateur la prise en charge des services et donc la complexité de celle-ci. Il va s’en dire que ce n’est pas une solution pour le grand public.

Solutions

Des solutions sont à mon avis nécessaire si l’on veut que le grand public ne doivent pas choisir entre son confort et sa liberté. Pourquoi l’utilisation du logiciel libre devrait nécessairement passer par une complexité ou une compréhension de l’informatique ?
Cette question est d’autant plus critique maintenant car jusqu’à il y a quelques années l’usage d’un logiciel libre comme un navigateur web ou une suite bureautique n’impliquait pas un grand effort face à la version propriétaire, hormis bien sûr celui de changer ses habitudes. Cependant avec l’intégration de plus en plus fortes de services au sein des logiciels, la différence entre logiciel propriétaire et logiciel libre est de plus en plus flagrante et ne sera pas en faveur de ces derniers.

Une solution serait qu’une Fondation du libre possédant une certaine reconnaissance de ses pairs proposent des services. En effet le dilemme du cloud est qu’il suffit qu’une entreprise exploite de données personnelles pour que cela suffise à jeter le doute sur la vie privée, que cela soit Google ou Canonical. A priori seul une Fondation ayant en son coeur une éthique, comme la FSF ou la Mozilla Fondation pourraient obtenir la légitimité de l’exploitation de données personnelles.

L’autre solution qui est une sorte de Graal, serait de concilier le P2P et les services. Il « suffirait » que des services, quel qu’ils soient, s’appuient sur une API système, laquelle fonctionnerait en P2P pour distribuer les données découpées, chiffrées et redondées. J’ai cependant bien peur qu’un tel système ne voit pas le jour avant très longtemps.

C’est pourtant à mon avis le prochain défi du logiciel libre, ne plus se contenter de proposer du logiciel, mais aussi des services si possible décentralisés et si possible non gratuit.

La gratuité

La liberté a un coût, la preuve en est que certains s’en prive en échange de confort et de simplicité. Il est à mon avis dommageable à long terme pour le libre que ce coût soit sur celui du confort d’utilisation. Le succès d’Apple montre qu’un grand nombre de personnes sont prêtes à payer très cher en monnaies, leur confort. Un autre grand nombre de personnes sont prêtes à obtenir ce confort en échange de leur vie privée, chez Facebook ou Google.
Dans les 3 cités, Apple, Facebook, Google, aucun n’a fait l’économie du confort.

Il est donc à mon avis nécessaire de diminuer fortement l’effort nécessaire à utiliser et exploiter les logiciels libres, l’usage de services liés sera pour cela de plus en plus indispensable. Une grande partie des utilisateurs seraient prêt à payer pour ces services ce qui permettrait d’une part de financer leur développement et exploitation, mais aussi que les communautés libres qui développent et supportent ces services puisse s’auto financer.

Quand je vois la part de plus en plus grande que prend l’informatique connecté à des services en ligne sur des formes aussi variées que des véhicules, des télévisions, console de jeux, téléphone, frigo, maison, etc, et que le libre ne propose aucune alternative à cela hormis dire que c’est pas bien, je suis très inquiet, certes pas à titre personnel mais pour l’avenir de tous.

Il sera je pense de plus en plus nécessaire de penser au confort, au financement et donc arriver à créer un écosystème décentralisé libre auto-financé et en terminer avec les tabous des services et de l’argent.

un petit retour des JDLL 2011

mise à jour : Je me rend compte avoir oublié de parler de la conférence sur Illyse l’association qui souhaite proposer un FAI associatif local sur Lyon et Saint Etienne. Illyse fait parti du projet d’essaimage lancé par FDN. J’ai trouvé Jean-François Mourges (que je connais ayant travaillé avec lui :) ) plutôt bon orateur et ayant semble-t-il réussi a s’entourer d’une équipe compétente , ce qui est la base de la réussite d’un projet. Cependant je m’ajoute aux requêtes qui ont été faite sur une offre VPN. En effet une offre d’un accès Internet non triple play entre 35 et 40 euros, qui comprend l’achat d’un modem ADSL et de 100 euros de frais d’installation est à mon avis un énorme frein pour pas mal de geeks. Or il serait à mon avis pragmatique de proposer en plus une offre VPN (entre 5 et 10 euros par mois par exemple) qui permettrait de financer plus rapidement l’association. Même si dans l’idéal on ne devrait pas avoir besoin d’utiliser un VPN puisque les FAI devraient respecter la neutralité des réseaux, un pragmatisme « à la Linus » en phase avec la triste réalité, permettrait, à mon avis, la réussite de ce projet.

Comme chaque année j’ai fait un tour aux JDLL le vendredi et le samedi. Il y a eu des conférences très intéressantes, notamment celle d’ Alexandre de dommelin sur puppet. J’ai déjà eu envie d’utiliser cet outil de gestion automatique des déploiements et des configurations, mais son enthousiasme m’a convaincu d’utiliser cet outil indispensable à l’industrialisation d’un SI (traçabilité, déploiement automatique, etc).

J’ai ensuite suivi les conférences sur movim et salut à toi qui sont des réseaux sociaux décentralisés basés sur XMPP. On voit qu’il y a eu beaucoup de taff derrière ces projets, et qu’ils mériteraient d’être financé. Au sujet du financement j’ai rencontré les petits gars derrière elveos qui permet de financer les développements de logiciels libre. C’est typiquement ce genre d’outil qui manque à notre écosystème depuis longtemps. Mais à mon sens ils devraient ajouter une gestion des ressources humaines en plus des ressources financières. En effet l’énorme difficulté des développeurs de logiciel libre, outre le financement, est de trouver d’autres développeurs, administrateur, graphiste, etc.

J’ai ensuite assisté à la conférence de Benjamin Bayard. Il a vraiment des talents d’orateur et de vulgarisation. Sur les problématiques aussi fondamentales telles que la neutralité des réseaux, nous mériterions qu’il touche un plus grand public plutôt que celui des geeks déjà acquis à cette cause.

Pour finir j’ai été plutôt impressionné par une démonstration d’opensuse sur le stand éponyme. L’outil OBS semble à première vue extraordinaire pour générer des paquets vers différentes distributions Linux. Mon netbook va sans doute servir de cobaye.

Peut être que l’année prochaine j’aurais assez avancé sur nodecast pour faire une petite conférence, et ainsi éviter de saouler toutes les personnes qui font l’erreur de me demander quel est mon projet :)

Quoi qu’il en soit, il me parait évident que l’avenir des prochains services libres s’annoncent décentralisé et basé sur XMPP. C’est à mon sens la meilleur voie si l’ont veut éviter l’hémorragie des utilisateurs vers des services propriétaires centralisés et ce que cela implique en terme de protection de la vie privée. Car il ne sert à rien d’utiliser des logiciels libres sur son poste de travail si les données sont stockées chez Apple, Google, Facebook, Yahoo, …

NCS : un serveur applicatif

Lors de mon dernier article sur nodecast je terminais sur la possibilité d’y intégrer un serveur web pour remplacer le serveur ruby Thin qui exposait l’API HTTP REST. C’est maintenant chose faite, la libqxt via son module QxtWeb m’a permis de mettre en œuvre assez simplement un serveur web dans un thread du serveur ncs. J’ai migré tout le projet sur github, le code du serveur est visible ici : http_api.cpp. Ce how to m’a été très utile : How to create a simple webservice using qt and libqxt

Dans la lancée j’ai également intégré un serveur XMPP grâce à QXmpp  ce qui permet au client Geekast d’effectuer des push en XMPP. Il fonctionne également dans son propre thread. Outre la rapidité de ce protocole face à HTTP, cela va permettre aux clients Geekast d’avoir une socket persistante avec le serveur ncs et donc permettre à celui-ci de faire du push vers tous les clients connectés. Les usages restent à définir mais cette possibilité ouvre un grand nombre de portes. Par exemple proposer la possibilité d’agir sur tous ses clients geekast depuis l’interface web (kill de processus, etc). L’envoi par HTTP sera toujours présent dans le client, au cas où la connexion XMPP est impossible (firewall, etc).

L’autre avancée est sur le format de donnée entre le client et le serveur, qui migre du XML vers JSON via QxtJson. Ainsi le serveur ncs qui reçoit les payload en json peut directement les transformer en bson object, format binaire de MongoDB. Plus besoin de passer par un lourd parsing du xml et des conversions vers des tableaux pour en extraire les données. La ligne suivante montre la simplicité d’une telle conversion :

bson::bo m_bo_json = mongo::fromjson(json.toStdString());

Le serveur ncs est donc maintenant autonome, Ruby est uniquement utilisé pour l’exécution du frontal web en Ruby on Rails.

Pour finir, voici un schéma du fonctionnement interne du serveur ncs.

Nodecast : backend asynchrone avec zeromq

Depuis mon dernier article sur Nodecast il y a 6 mois, de nouvelles idées ont germés qui ont données lieux à une nouvelle et sans aucun doute dernière (on y croit) réécriture du backend.

En effet dans mon dernier article je me sers d’un logiciel propriétaire pour présenter ce que je crois être l’avenir de services sur Internet via des technologies en Peer to Peer. Dans cette architecture P2P je pense que l’auto-hébergement est alors crédible car les données sont répliquées et leur accès répartie.

C’est pourquoi j’ai à nouveau réécris le backend, car dans un contexte où chaque utilisateur est encouragé à s’auto-héberger, il est nécessaire que le logiciel soit léger, simple à packager et donc avoir le moins de dépendance possible. Lorsque j’ai découvert Zeromq j’ai décidé d’implémenter avec, la gestion de la file d’attente et de répartition des jobs pour remplacer le serveur Qpid. Tous les serveurs de file comme Qpid, RabbitMQ ou Redis sont excellent dans un environnement centralisé mais sont à mon avis une contrainte s’ils sont imposés dans un environnement décentralisé ou réparti.

Zeromq me permet de migrer dans le dispatcher la gestion des files, grâce à des sockets ZMQ de type PUSH/PULL gérées dans des threads. L’usage de Zeromq est in fine plus complexe puisque plus bas niveau qu’une API fourni avec un serveur de file, mais les possibilités sont quasiment infinie, voir les différents exemples dans de nombreux langages et surtout les nombreuses spécifications de protocoles. A noter que Zeromq ne permet pas de persistance disque comme le font Qpid ou RabbitMQ, cependant une implémentation du protocole Titanic le permettrait, et il n’est sans doute pas sorcier de les ajouter en option.

A propos de la persistance des messages, tout dépend du type d’application gérée, pour un système bancaire il ne peut y avoir de perte de message bien entendu. Au contraire, il me semble avoir lu que les dev du  backend de last.fm avaient choisi une technologie sans persistance pour privilégier la performance.

Schémas

Voici le schéma de la nouvelle architecture et du dispatcher

Description

Ce schéma décrit le fonctionnement interne du processus dispatcher. Les numéros en rouge indiquent le workflow suivi par un job. Même s’il n’y a plus de serveur de file dans l’architecture nodecast, le dispatcher permet d’en conserver les propriétés grâce d’une part aux threads et aux envois non bloquant :  la directive ZMQ::NOBLOCK indique à la socket zmq de ne pas attendre de confirmation du destinataire.

  1. L’API géré par Thin (externe au processus dispatcher) réceptionne les données XML envoyées par les clients nodecast. Le serveur Thin a bindé le port 5555 local, stocke le XML dans GridFS, construit un hash et le push dans la socket ZMQ_PUSH.
  2. Le thread Zreceive est connecté sur le port 5555 via une socket ZMQ:PULL. Avec ce protocole il peut y avoir plusieurs instance du dispatcher connectés, mais un seul recevra un même job. A contrario en ZMQ PUB/SUB tous les subscribers recoivent une copie du job.
  3. Zreceive a créé un ZMQ_DEVICE. Celui-ci relie la socket ZMQ_PULL vers une socket ZMQ_PUSH. Le device transmet tout ce que reçoit la socket de PULL vers la socket de PUSH. A noter que la socket ZMQ_PUSH est ici de type ZMQ_INPROC, ce n’est donc pas une socket TCP mais une zone mémoire partagée avec une autre thread.
  4. Un thread Zdispatch est connecté en ZMQ_PULL sur la zone mémoire inproc. Il désérialize les jobs reçu dans un objet BSON puis émet un signal Qt avec la charge créée.
  5. L’objet Payload reçoit la charge dans un slot. A noter que cet objet possède à une référence vers un objet Nosql ce qui lui permet d’interroger MongoDB. Dans ce cas il est impératif que le slot Payload ne soit pas appelé alors qu’il n’a pas fini ses tâches en cours. Pour cela le QObject::connect qui relie le signal de Zdispatch avec le slot de Payload doit impérativement posséder la directive  Qt::BlockingQueuedConnection. Payload découpe la charge reçue, effectue des traitements, sérialize des objects puis emet des signaux pour chaque worker.
  6. Le thread worker_push possède un slot par signal emit par Payload. Lors de sa construction il a bindé chaque socket ZMQ_PUSH par worker. Il transmet alors la charge en mode non bloquant ZMQ_NOBLOCK.
  7. Chaque worker ZMQ_PULL sur sa socket TCP dédié. Traite puis stocke dans MongoDB.

Les cadences.

Elles rythmes le workflow, s’il n’y avait qu’une seule cadence ce backend serait synchrone. Cependant on voit très bien plusieurs.

  1. Tout d’abord le serveur Thin, qui transmet le job et retourne aussitôt une réponse au client.
  2. Ensuite le thread Zreceive, retransmet à son rythme les jobs dans une zone mémoire
  3. Le thread Zdispatch lit la zone mémoire puis faire suivre les jobs dans des signaux Qt.
  4. L’objet Payload transmet les bouts de job dans des signaux vers des slots.
  5. Le thread worker_push envoie à chaque worker sa charge
L’entrée et la sortie du dispatcher sont non bloquante. Si ce dernier plante, le serveur Thin et le worker se rendront compte de rien. De plus contrairement à un serveur classique, les sockets zeromq permettent de lancer des clients même si le serveur n’est pas lancé. Si le dispatcher tombe il pourra être relancé sans problème et les workers recevront à nouveau leur jobs.

Conclusions

L’architecture du dispatcher n’est pas encore optimisée, par exemple les positions 4, 5 et 6 pourraient fusionner. Cependant le Proof Of Concept est concluant, ce backend devrait pouvoir s’exécuter correctement sur une machine recyclée. Une dernière tâche serait de migrer le serveur Thin dans un thread en Qt afin de simplifier et optimiser encore l’architecture, ou bien d’utiliser Mongrel2 à la place de Nginx et Thin comme me le conseillait un certain Zed Shaw :)
La cible d’obtenir un backend asynchrone brokerless étant atteinte la prochaine étape est l’intégration d’un worker qui permette la synchronisation en P2P des données du backend. L’objectif est qu’une instance Nodecast se synchronise avec l’instance d’un contact de l’utilisateur. Gros travail en prespective, les solutions sont nombreuses comme telehash mais qui ne fourni pas pour l’instant d’implémentation en C/C++, ou bien la lib bitdht utilisée par entre autre par retroshare.
Bonnes vacances (ou bon courage) aux lecteurs !

aerofs , une solution de sauvegarde décentralisée

La sauvegarde est un domaine vaste et complexe qui essaye de répondre à une problématique pourtant simple, sauvegarder ses données. La difficulté qui ne saute pas forcément aux yeux de l’utilisateur lambda étant de résoudre 2 problématiques, garantir la restauration des données et garantir la confidentialité.

La restauration

La restauration dépend bien sûr du support utilisé. On est passé ces dernières années des supports physique sur bande, disque à plateaux et flash à des supports dématérialisés et hébergés sur Internet. Le principal intérêt est bien sûr de se mettre à l’abri d’une destruction ou une disparition du support physique sur des lieux non adaptés à protéger des données d’une grande valeur. L’autre avantage est d’automatiser la sauvegarde et ainsi sauvegarder plus finement l’avancée de ses travaux.

Cependant cette sauvegarde externalisée dépend elle aussi du support physique utilisé. On a supprimé les risques d’une destruction occasionnée par des locaux non adaptés (chute, vol, incendie, inondation, etc) ce qui n’est pas rien, mais quid d’un crash disque sur le serveur distant ?

Il existe d’excellentes solutions externalisées, de type Dropbox. Celle-ci utilise le cloud S3 fourni par Amazon pour stocker les données de leur utilisateur. Ce type de service est censé éviter les problématiques de gestion du stockage et de crash de disque occasionnant une perte de données. Or un récent plantage de plusieurs heures dans un datacenter d’Amazon a rendu indisponible de nombreux site web et certains auraient perdu des données, même si Dropbox n’est semble t-il pas concerné.

La confidentialité

Toujours Dropbox, ils ont récemment modifié leur CGU afin de rappeler qu’ils devaient se conformer à la législation américaine et éventuellement fournir des données de leur client sur demande de la justice. Ce type de contrainte n’est bien entendu pas spécifique à Dropbox mais à toute entreprise qui doit par définition respecter la loi de leur pays. A ce titre des entreprises qui stockent sur leur cloud des données de leur client, tel que Google, Apple, Yahoo ou Microsoft ont elles aussi cette obligation, il est bon de le rappeler.

Cela ne gênera sans doute pas ceux qui, par exemple, acceptent les caméras de surveillance partout, « du moment qu’ils n’ont rien à se reprocher », mais pour les autres il y aura sans doute une gène voir une phobie à sauvegarder ses données dans ces conditions.

Le P2P

Ces récents échec du Cloud, viennent rappeler que celui-ci ne peut être une solution pérenne ni respectueuse de la confidentialité. Ces échecs viennent rappeler que la seule architecture fiable pour les données ne peut être basée que sur la même architecture qu’Internet, le P2P. Internet est une maille composée de noeuds, car il a été intégré dès sa conception l’évidence que rien ne peut garantir définitivement l’intégrité total d’un lieu géographique ou d’un matériel. Ainsi une information atteindra sa destination selon un chemin non pas figé mais selon l’état du réseau au moment de son acheminement.

Il serait intéressant de traiter le stockage et l’accès à ses données de la même manière. A vrai dire cela existe déjà puisque le P2P répond exactement à cette problématique. Or même si celui-ci est entaché d’un usage bien souvent à des fins de contrefaçons, il n’est qu’un outil neutre.

aerofs

Pour revenir au sujet, la sauvegarde a tout intérêt à exploiter les capacités du P2P. Ainsi les données ne sont pas centralisée et elles peuvent être répliquées en de multiple endroits. La startup Air Computing Inc qui a créé le logiciel aerofs a exactement compris cela puisqu’elle fourni ce logiciel. A défaut d’avoir un équivalent libre aussi souple, j’y retrouve les avantages de Dropbox (client natif et multiplateforme), sans la centralisation qui est là optionnelle et payante au delà d’1 Go.

J’ai une instance aerofs sur quelques machines, dont un serveur dédié sur lequel est synchronisé l’ensemble des données stockées dans le logiciel. Pour résoudre la problématique de la confidentialité j’utilise l’excellent encfs qui me permet de chiffrer en userland le contenu d’un répertoire. Un simple lien Aerofs vers ce répertoire chiffré, permet de chiffrer à la volée les données reçues :   (merci à Flink pour la correction) Il suffit donc de stocker le répertoire chiffré de encfs dans Aerofs pour sauvegarder de manière répartie et sécurisée ses données.

Voici une capture de l’interface en train de synchroniser des données vers mon serveur.

Il est bien sur possible de sélectionner les répertoires à synchroniser par client, afin de ne pas stocker sur son ordinateur du boulot des données personnelles. Enfin il est possible de partager un répertoire avec d’autres utilisateurs sélectionnés.

Il existe un vote d’une demande de fonctionnalité afin de rendre l’ensemble libre : http://vote.aerofs.com/forums/67721-feature-requests/suggestions/1728653-open-source-aerofs-and-only-take-payment-for-clou?ref=title

Je pense que si aerofs n’est pas libéré, il existera un jour ou l’autre un équivalent libre, voir même un file system en P2P chiffré. Chacun stockant des morceaux de données répliquées, anonymes et chiffrées.

Pour finir je suis de plus en plus convaincu que l’avenir des applications et des données, du moins dans le Libre, utiliseront de plus en plus le P2P, comme le font Bitcoin et namecoin,  c’est tout notre intérêt et c’est le seul moyen pour lutter contre le Minitel 2.0, et contre l’hégémonie de Google qui compte bien s’étendre à toute sorte de devices : http://fr.techcrunch.com/2011/05/18/google-android-internet-des-objets/  :)

Nodecast : évolution d’une architecture web

Après ces quelques mois sans nouvelle, voici un article de mes dernières avancées sur mon projet Nodecast. En effet depuis mon dernier article Nodecast : architecture d’une application web il y a eu quelques changements d’implémentation.

Constat et évolution

Tout d’abord Gearman qui était idéal sur le papier s’est avéré très instable à l’usage, comme l’ont constaté d’autres développeurs sur la liste de diffusion. Ils ont l’air malgré tout d’avoir confiance en leur produit car ils vont ouvrir un service d’hébergement de files d’attente basé sur German : GearmanHQ.

Après quelques recherches je me suis finalement dirigé vers un serveur de files qui implémente le protocole AMQP ce qui permet de ne pas dépendre d’un serveur en particulier. Plusieurs serveurs libres l’implémentent, comme RabbitMQ (racheté par VMware), ActiveMQ ou Qpid.

L’autre problème est venu des workers qui traitent les données envoyées par le client desktop ( nodecast-gui ). Le code Ruby était tellement lent qu’il fallait parfois plus de 1 minute pour effectuer un traitement de parsing et insertion dans MongoDB. Je pense que le problème venait de la pile Ruby / Mongoid / Mongodb ruby driver et non de Ruby seul, mais il n’est tout simplement pas concevable que le worker qui intègre dans la base les processus utilisateur met plus ou moins 2 minutes pour effectuer 1 traitement avec une charge CPU maximale.

J’ai donc décidé de récrire les workers ainsi que le dispatcher, en C++ avec l’aide de Qt. Mes tests en développement sont passés à moins de 1 seconde sur le worker process, le plus lourd…. Evidemment l’effort de développement est certes plus conséquent mais les résultats sont largement payant pour que cet investissement technique paye.

Qpid quant à lui s’est pour l’instant imposé de lui même, car il est le seul à proposer une API C/C++ fonctionnelle. Des plugins permettent de lui ajouter une persistance sur disque, des fonctionnalités de cluster, du support SSL et XML en natif. Il fait d’ailleurs partie du coeur de la solution de Red Hat Enterprise MRG. Cette architecture représentée par le schéma plus bas reste tout de même à valider par l’épreuve du feu de la production.

Ingénierie

Néanmoins il est à mes yeux évident qu’un service web ayant pour objectif à moyen/long terme la prétention de monter en charge, se doit d’avoir une architecture scalable et cela dès sa conception. C’est toute la différence entre créer un site web et créer une architecture web, ou bien entre le développement logiciel et l’ingénierie logicielle. Cette dernière implique une réflexion sur les méthodes de travail, les outils à utiliser, qu’ils soient ceux utilisés par les développeurs que ceux à utiliser dans l’architecture;  la veille techno, etc. En somme tout ce qui permet d’optimiser sa productivité, l’architecture mise en place n’en sera que le reflet, réussi ou pas, de ces choix…

Voici un exemple du résultat de l’ingénierie logiciel avec cette présentation de l’architecture logicielle de la nouvelle version de LinuxFR.org l’un des plus gros site technique francophone.

Implémentation

Pour revenir à Nodecast, les workers utilisent les drivers natifs de memcached, pour invalider le cache dont la page a été mise à jour, de MongoDB et de Qpid, ce qui permet, en ayant aucune couche d’abstraction intermédiaire d’obtenir les performances maximales. Le framework Qt permet d’obtenir une certaine simplification du développement, grâce entre autre aux signaux, même si en effet la bibliothèque Boost intègre cette fonctionnalité.

J’ai développé nodecast-worker de manière relativement générique afin qu’il instancie la bonne classe worker selon le paramètre –worker-type fourni en argument :

nodecast-worker --memcached-ip=127.0.0.1 --memcached-port=11211 
--mongodb-ip 127.0.0.1 --mongodb-base=nodecast_prod --qpid-ip=127.0.0.1 
--qpid-port=5672 --worker-type=process

L’usage du serveur de file Qpid, permet outre le fait de rendre les traitements asynchrones, de monter un cluster de worker d’un même type sans développement particulier. En effet chaque worker s’abonne à la même file d’attente Qpid de type pub/sub (amq.topic). Une routing key appliquée par le dispatcher sert à taguer chaque message envoyé dans la file d’attente. Ainsi les workers filtrent les messages qui leur sont destiné, par exemple le tag worker.cpu pour le worker qui va traiter les messages qui contiennent les données de CPU envoyées par le client desktop nodecast-gui.

Comme il est possible de lancer plusieurs instances worker du même type, chacun des worker dépile la même file taguée ce qui permet de répartir la charge sur plusieurs processus, voir aussi de la répartir sur des machines physiques différentes puisque les workers utilisent des connexions TCP … !

Pour comprendre les rouages et le potentiel d’une telle architecture, je conseille la lecture de ces 2 excellents articles sur l’utilisation d’un serveur AMQP : Introduction à RabbitMQ – AMQP Partie I et Introduction à RabbitMQ – AMQP Partie II

Pour finir sur cet épisode, ce développement me met de plus en plus la puce à l’oreille sur la nécessité de développer un framework / service qui permettrait le développement rapide de workers, de les enchaîner, les monitorer en temps réel et de les administrer. Ce framework / service proposerait en outre l’accès à une multitude de bibliothèques et d’API vers des services externes afin de pouvoir implémenter n’importe quelle idée, de manière rapide, stable et scalable. Cela éviterait de devoir redévelopper la roue et de devoir gérer toutes les exceptions inhérente à l’utilisation d’API bas niveau (timeout, déconnexion, reprise, exception, start/stop, …). En quelque sorte un tarpipe OpenSource mais qui permettrait d’utiliser n’importe quel langage script ou langage compilé. Comme on dit, je dis ça, je dis rien :)

Workflow

Le schéma suivant montre l’architecture en court de développement du backend de Nodecast. On y voit les 3 paliers asynchrones par lesquelles transite le traitement d’un message.

nodecast architecture

Palier 1

Le premier palier nécessite 7 étapes.

  1. Le client nodecast extrait les données système de la machine, génère un XML et l’envoie par un POST (ajout) ou un PUT (update) HTTP.
  2. le serveur web Nginx fait suivre la requête vers le cluster web Thin.
  3. Thin exécute via rack le DSL Sinatra qui sert à créer simplement l’API REST de nodecast.
  4. Ce dernier vérifie dans MongoDB les droits d’accès (couple email / token) grâce à un auth basic request HTTP transmis par le client,
  5. Si l’autorisation a réussie, le code Sinatra stocke le XML dans le GridFS mongoDB, génère une collection de hash et transmet la charge dans queue dédiée au dispatcher.
  6. Le code sinatra génère un XML de réponse au client.
  7. NGinx le fait suivre au client, ce qui termine du point de vue utilisateur le traitement.

L’objectif de ce palier est d’être le plus minimaliste possible afin qu’une autre requête puisse être traité avec le moins d’attente possible. L’auth, la conception de la charge, sa transmission et la réponse au client sont malgré tout chacune nécessaire. Dans cette architecture asynchrone il n’est pas possible de signaler dans la même passe, la bonne fin du traitement à moins de revenir à une architecture synchrone non scalable… A vrai dire il n’est de toute manière pas nécessaire de le signaler puisque le service tourne en arrière plan sur le poste utilisateur.

Palier 2

La transmission de la charge utilise 2 canaux AMQP direct : dispatcher.update ou dispatcher.add. Le dispatcher est lancé selon cette ligne de commande :

 nodecast-dispatcher --mongodb-ip 127.0.0.1 --mongodb-base=nodecast_prod 
--qpid-ip=127.0.0.1 --qpid-port=5672
  1. Il écoute les 2 files d’attente puis lors de la réception d’une charge, il vérifie l’existence de l’hôte à mettre à jour si c’est un update ou bien créé l’hôte si c’est un ajout.
  2. Il injecte ensuite le XML extrait du GridFS dans un QHash Qt. Il sérialise ce QHash et envoie par AMQP la partie dédiée à chaque file de chaque worker concerné (hash["network"] pour le worker network par exemple). En clair, le XML est découpé et chaque morceau est envoyé dans la file d’attente de chacun des workers.

Palier 3

  1. Tous les workers sont lancés et écoutent la file d’attente amqp.topic sur leur tag respectif (worker.cpuworker.loadworker.uptimeworker.networkworker.memoryworker.process).
  2. A réception d’un message, ils le sérialisent, mettent à jour la base de donnée puis invalident le cache de leur page web associée.
  3. Ils transmettent via syslog leurs statuts et leurs exceptions.

Avenir

A ce jour les workers process et cpu ont été réécrit et fonctionnent. Il reste l’implémentation des logs vers syslog ou AMQP afin de tracer les traitements des workers via des streams Graylog2.

Je souhaite remplacer Memcached par Redis pour profiter de ses très intéressantes fonctionnalités. Migrer le frontal web de Rails 2 vers la version 3. Stabiliser le client desktop et lui ajouter toutes les fonctionnalités de la lib SIGAR. Développer un client Android. Terminer le rework et Dominer le Monde :)