Implémentation d'un MOM open-source

Dimension: px
Commencer à balayer dès la page:

Download "Implémentation d'un MOM open-source"

Transcription

1 Implémentation d'un MOM open-source Saber Dir - Victor Laborie - Guillaume Penaud 23 mars

2 Table des matières 1 Introduction et problématiques Objectifs Contexte Composition de l'équipe Délai Répartitions des rôles Planning réalisé Remerciements Qu'est ce qu'un MOM État de l'art Historique : JMS Les Protocoles AMQP MQTT STOMP OpenWire Comparatif Protocole sélectionné Les MOMs RabbitMQ HornetQ Apollo QPID Comparatif Les premiers pas sous RabbitMQ Les premiers pas avec RabbitMQ via un client PHP Introduction Installation du broker RabbitMQ Implémentation du Hello World Le producer Le consumer Les concepts Gestion des virtual hosts (ci-après nommé vhost) Gestion des utilisateurs Les types d'exchange Default Fanout Direct Topic Headers Infrastructure utilisée Phase 1 : Le bac à sable Phase 2 : L'infrastructure de la maquette - Chirement de mail Phase 3 : L'infrastructure de la maquette - Load-balancing et haute disponibilité Envoi et chirement de mail Présentation du besoin Licence ASRALL 2 IUT Charlemagne

3 6.2 Présentation de la solution Le fonctionnement mail-input encrypter mail-output broker récepteur du mail Industrialisation Transformation des consumers en services Linux (daemon) Pourquoi Mise en place Redondance et clustering Objectifs Mise en place du cluster Mise en place du load-balancing Changement au sein de nos applications Conclusion sur le clustering et le loadbalancing Apollo : Un autre MOM pour d'autres protocoles Introduction Architecture Implémentation Indépendance du protocole Administration par service REST Installation d'apollo Protocoles Envoi de message simple via MQTT MQTT - Consumer MQTT - Producer Envoi de message simple via STOMP STOMP - Consumer STOMP - Producer En conclusion Acquis Techniques Atouts en milieux professionnels L'équipe Gestion du temps Le mot de la n Annexes 43 Licence ASRALL 3 IUT Charlemagne

4 1 Introduction et problématiques Le projet "MOM open source : Middleware Orientés Messages implémentation et exploitation", a pour objet d'étudier le fonctionnement et l'écosystème des MOM dans un contexte applicatif simplié, tout en répondant à un certain nombre de contraintes simulant un contexte d'utilisation professionnelle réel. Nous avons donc, dans notre travail, essayés d'imaginer les besoins à anticiper, et chaque partie du travail eectué (état de l'art, étude des diérents moyens de communication, droits et accès, etc...) l'a été avec cette arrière-pensée. Ce rapport présente notre compréhension collective du fonctionnement d'un MOM, d'un point de vue à la fois théorique et concret. 1.1 Objectifs Notre projet se décompose en trois parties : Comprendre le rôle et le fonctionnement des MOM. Implémenter un MOM en contexte applicatif simplié (maquette), choisi après une étude de marché selon un ensemble de critères fournis par notre tuteur. Créer et gérer un ensemble de routines de production. La solution retenue devait répondre aux critères suivants : Être open-source Assurer une redondance logicielle (assurer du failover via une solution de clustering) Haute scalabilité (capacité à supporter des pics de charge importants) Ainsi, même s'il ne s'agit que d'une maquette, l'implémentation que nous avons fournie devait être exploitable sur demande et intégrable au sein d'un ensemble applicatif plus grand, ceci dans un délai raisonnable. 1.2 Contexte Composition de l'équipe Pour ce projet, nous sommes 4 étudiants en licence professionnelle ASRALL : Nom : Saber Dir Nom : Victor Laborie Nom : Guillaume Penaud Nom : Israël Olguin Suarez Licence ASRALL 4 IUT Charlemagne

5 1.2.2 Délai Le projet "MOM open source : Middleware orientés messages implémentation et exploitation" a été réalisé sur un délai de 2 mois. Pour organiser notre travail nous avons réalisés ce retroplanning : Répartitions des rôles Il a été décidé au cours de la première réunion entre membres de l'équipe, que Guillaume endosserait le rôle de "chef de projet". Voici donc les devoirs qui lui ont incombés dans ce domaine : S'assurer que la charge de travail était équitablement répartie entre les membres de l'équipe. S'occuper de la communication avec les tuteurs. Motiver les troupes si besoin. S'agissant de la rédaction des compte-rendus hebdomadaire collectifs, Guillaume en a écrit une grosse partie. Principalement parce qu'il aime bien écrire, que ça ne lui posait pas de soucis particulier et que ça lui demandait peu d'eorts. Pour le travail sur le projet en lui-même, des rôles (parlons même de spécialisation) sont apparus assez spontanément, en suivant les intérêts de chacun. Voici ce que nous avons pu constater : Saber s'est senti à l'aise dans la découverte des concepts et de techniques, concernant les MOM et les outils "annexes" que nous avons du utiliser (utilisation de gpg, transformation des scripts en services). Il a donc surtout travaillé en environnement "bac à sable" (environnement dédié et nu) ; son travail a permis à Guillaume d'implémenter la maquette en condition de production (la phase d'implémentation de la fonctionnalité "défrichée" était d'ailleurs réalisée en binôme). Comme dit précédemment, Guillaume a principalement travaillé sur la maquette elle-même, son implémentation en environnement de production ; aimant beaucoup scripter et disposant de compétences en développement certaines, il a écrit et réalisé une grosse partie de l'applicatif, ainsi que la construction et la gestion de l'infrastructure virtualisée. Licence ASRALL 5 IUT Charlemagne

6 Victor, quand à lui, s'est consacré à la recherche théorique et à l'implémentation des protocoles et des MOMs "secondaires" (appolo, etc...), tout en contribuant fortement au scripting de l'application, conjointement à Guillaume. Néanmoins, nous avons tous participés à l'élaboration de l'ensemble du projet, nous concertant très souvent et travaillant main dans la main, an que chacun ait une vision globale et complète. Concernant Israël, il s'est rapidement désengagé et n'a que très partiellement participé sur la partie théorique en début de projet ; il a par ailleurs été débarqué du projet par l'équipe pédagogique suite à plusieurs semaines d'absences an de ne pas pénaliser les autres membres de l'équipe Planning réalisé Le planning réalisé montre des diérences avec le rétro-planning, principalement due à la défection d'israël, mais aussi à des dicultés que nous avons rencontrés lors de la réalisation de la maquette Remerciements Nous souhaitons chaleureusement remercier les personnes suivantes : Antoine Alluin et Mathieu Goulin, nos tuteurs, qui nous ont énormément guidés, soutenus, et encouragés tout au long de la réalisation ce projet. Merci à eux pour s'être autant impliqués, pour s'être déplacés à l'iut an de participer aux réunions, et surtout, pour le travail que ça leur a demandé. Monsieur Yohan Parent, qui nous a donné un sacré coup de pouce dans des moments diciles. A toute l'équipe pédagogique de la licence ASRALL, pour nous avoir donné les outils technique nécessaires à la réalisation de ce projet. A tous ceux qui prendront le temps de lire et d'évaluer ce rapport. Licence ASRALL 6 IUT Charlemagne

7 1.3 Qu'est ce qu'un MOM Un MOM (Message Oriented Middleware) est un logiciel qui permet l'échange asynchrone de messages entres des applications hétérogènes (n'implémentant pas par défaut de moyen de communication entre elles) présentes sur un réseau informatique. L'ensemble des serveurs MOM, rassemblés au sein d'un cluster est appelé un broker (courtier de messages) ; dans ce contexte, un serveur MOM est alors appelé un noeud. Pour simplier, dans la suite de ce rapport, nous appelerons également un serveur MOM un broker (en considérant qu'il s'agit d'un cluster à 1 noeud). Lorsqu'une application veut envoyer un message à une autre application, elle l'envoit dans une le d'attente, située dans un exchange (un élément qui dénit la façon dont le message sera diusé), sur le broker concerné. Les applications destinatrices n'ont plus qu'à se connecter au broker et à récupérer le message sur la le d'attente. Le fonctionnement d'un MOM n'est pas sans rappeler celui d'un serveur de mail. En eet, lorsque vous envoyez un mail à une personne, vous l'envoyez en réalité à un "broker" (nommé diérement dans ce contexte, bien sûr), constitué de l'ensemble des serveurs mails nécessaire à son routage à travers internet. Votre destinataire n'aura plus qu'à se connecter au "broker de mail" pour récupérer votre message. Vous n'êtes pas obligés d'avoir vos machines connectées en même temps, d'ou la notion d'asynchronicité, principal atout des MOM. En revanche, et contrairement aux serveurs mails, les MOMs sont faits pour envoyer des messages très volumineux et conçus pour être rapide. Ils sont aussi spécialisés dans la communication interapplication, tandis que les mails sont prévus pour les échanges inter-humains, à travers le réseau. Licence ASRALL 7 IUT Charlemagne

8 2 État de l'art 2.1 Historique : JMS Pendant longtemps il n'y a eu aucun standard pour les protocoles de messageries. Le standard de facto était JMS, mais JMS est une API et non un protocole, elle dénit une interface, pas une façon de communiquer. JMS ne garantie donc pas d'interopérabilité, chaque implémentation de l'api pouvant utiliser un protocole diérent. Pour communiquer ensemble, deux applications utilisant JMS devront utiliser une implémentation qui utilise le même protocole, tandis qu'aujourd'hui des implémentations pour AMQP, MQTT, STOMP et OpenWire sont disponibles, ce qui ne fut pas toujours le cas. Le seul apport de JMS est de pouvoir changer plus facilement de protocole en changeant d'implémentation de l'api. Son défaut majeur est sa compatibilité, qui se limite au seul langage Java. 2.2 Les Protocoles AMQP Développé par la banque JPMorgan Chase, son objectif est de standardiser les échanges entres serveurs de messages. Il est, depuis sa version 1, un standard ISO/IEC et un standard du consortium OASIS. C'est un protocole bas niveau dont les messages sont au format binaire. Il est assez dicile à mettre en place, mais peut être utilisé dans de grosses infrastructures. JP Morgan l'utilise pour envoyer plus d'un milliard de messages par jour, la NASA pour son système de Cloud Computing "Nebula" et Google pour GooglePlex MQTT C'est un protocole orienté "embarqué", il est désigné spéciquement pour les machines à faible ressources, disposant de peu de bande passante. Il est pensé pour ce que l'on appelle "l'internet des objets". Les messages sont aux formats binaire pour diminuer le débit. C'est un standard du consortium OASIS depuis la version Facebook, notamment, l'utilise pour l'application Facebook Messenger pour sa faible consommation et sa faible bande passante STOMP C'est un protocole plus haut niveau, similaire à HTTP, les messages sont au formats texte. Il a pour but d'être simple à implémenter coté client ; un client peut communiquer avec un serveur STOMP simplement avec Telnet. Il est simple, léger, est implémenté dans de nombreux langages et peut même être utilisé à travers des websockets. Licence ASRALL 8 IUT Charlemagne

9 2.2.4 OpenWire C'est un protocole binaire, dont le but est d'être performant au maximum et d'avoir le plus de fonctionnalités possible. Bien qu'au format binaire il est similaire sur les commandes au protocole STOMP Comparatif Formats d'échanges Standards Binaire Texte OASIS ISO/IEC AMQP X X MQTT X X 3 STOMP X OpenWire X AMQP est un standard OASIS et ISO/IEC. Il est robuste, mature et éprouvé puisqu'utilisé par de très grosses infrastructures, tels que la banque JP Morgan, la NASA et Google. Il est donc à privilégier. MQTT est un standard OASIS et est conçu pour l'embarqué. Il est donc à privilégier quand AMQP ne peut faire l'aaire en raison de contraintes de ressources ou de réseau. STOMP n'est pas un standard, cependant son format d'échange peut être un avantage pour les clients qui veulent communiquer directement en mode texte, sans aucune transformation. OpenWire n'est pas un standard, il n'est apparemment utilisé que par des projets de la fondation Apache et très peu de documentation est disponible, il n'est pas à privilégier dans notre situation Protocole sélectionné Pour notre projet, nous avons décidés d'utiliser le protocole AMQP pour plusieurs raison : C'est un standard OASIS et ISO/IEC (Standard) Il est implémenté par la majorité des MOMs (Disponible) Il est utilisé par de nombreuses entreprises (Réputé) Il est utilisé pour de très grosses quantités de messages (Scalable) 1. Version 1.0 (29 octobre 2012) 2. Version 1.0 (1 mai 2014) 3. Version (29 octobre 2014) Licence ASRALL 9 IUT Charlemagne

10 2.3 Les MOMs RabbitMQ RabbitMQ à été développé avec le langage fonctionnel Erlang, spécialement conçu pour les applications distribuées ; il implémente le protocole AMQP et ne supporte que lui par défaut. Mais il est extensible, les protocoles MQTT et STOMP sont disponibles via des plugins. RabbitMQ garantie la disponibilité du message de bout en bout, c'est-à-dire à partir de l'envoi par le producer du message jusqu'à la réception par le consumer. En terme de persistance, RabbitMQ possède une base de données interne appelée "Mnesia". RabbitMQ permet de construire un cluster de type actif/passif, et peut donc pallier ecacement à la panne d'un serveur en assurant la haute-disponibilité du broker. En conclusion, avec RabbitMQ, on dispose d'une excellente gestion de la persistance, du clustering, et de l'envoi asynchrone. Ainsi qu'un puissant mécanisme d'acknowledgments, qui garantit au producer d'un message sa bonne réception par le consumer auquel il était destiné HornetQ HornetQ, d'abord connu sous le nom de JBoss Messaging 2.0, a été développé par JBoss dans l'optique de l'intégrer à JBoss Application Server ; il en est d'ailleurs le broker par défaut depuis la version 6. Il peut aussi être utilisé indépendamment, mais ne comporte pas de console d'administration intégrée (JBoss Application Server est nécessaire). HornetQ, grâce a un ensemble de librairies, est assimilable à un framework de messagerie java. Dans ce MOM la persistance est obtenue grâce au journal, un élément chargé de persister les messages sur un périphérique de stockage externe pour éviter de les perdre en cas d'incident ; à la diérence des autres MOM mentionnés dans ce rapport, HornetQ n'utilise pas de bases de données, mais le système de journalisation Java NIO. HotnetQ implémente une solution de haute-disponibilité. Il permet de déclarer un serveur de fallback au serveur actif, an d'assurer un basculement en cas de défaillance. En revanche, il n'implémente pas de mécanismes de répartition de charge. HornetQ supporte les protocoles AMQP et STOMP Apollo Le projet Apollo à démarré comme une expérience pour rendre ActiveMQ plus performant sur des machines multi-processeur. An de le rendre plus rapide, plus robuste et plus facile à maintenir, une architecture complètement nouvelle à été introduite. Cette architecture est basée sur le langage de programmation Scala, avec support de systèmes concurrents. Comme ActiveMQ, Apollo est un broker multi-protocole et supporte AMQP, MQTT, STOMP et OpenWire. Licence ASRALL 10 IUT Charlemagne

11 2.3.4 QPID Apache QPID à été crée par un groupe de travail comprenant entre autre JPMorgan Chase, Red Hat et Cisco Systems dans le but d'être 100% compatible avec le protocole AMQP, il est d'ailleurs le seul protocole supporté. Initialement développé en Java, il est maintenant développé en C++, la version Java étant toujours disponible. Le projet QPID maintient un sous-projet dénommé "Proton", dont le but est d'être une implémentation légère du protocole AMQP Comparatif Tout d'abord, il est important de noter que tous les MOMs sélectionnés pour le comparatif sont des JMS providers, car il s'agit d'un standard assurant ainsi qu'ils disposeront des principales fonctionnalités attendues d'un MOM digne de ce nom. La comparaison des solutions s'est donc faite principalement sur les protocoles supportés, ainsi que sur les langages dans lesquels ils sont conçus ; notre choix s'est porté sur le MOM connu comme étant le plus didactique, et facilement implémentable. Critères RabbitMQ MOM HornetQ Apollo QPID dépôts debian X X installation paquets deb X X dépôts rhel X X paquets rpm X X AMQP X X X X protocoles MQTT X 1 X STOMP X 1 X X Openwire X simplicité X X documentation prise en main X X interface web X 2 X X plugins existants X X X extensibilité création de plugins X X mirroring de queues X X haute disponibilité clustering interne X X 3 X X maturité année de sortie langage erlang java scala C++ 4 Il nous a fallu choisir le MOM le plus adapté à la réalisation de notre maquette ; les critères étant, nous le rappelons : opensource, simplicité de mise en oeuvre, support de charge. Au vu de ces critères, RabbitMQ s'est démarqué comme étant la solution présentant le plus de qualités. En outre, c'est la solution que nos tuteurs maîtrisaient le mieux. 1. Via plugins 2. Disponible dans JBoss Application Server 3. Failover uniquement (pas de répartition de charge) 4. Initialement en Java Licence ASRALL 11 IUT Charlemagne

12 3 Les premiers pas sous RabbitMQ 3.1 Les premiers pas avec RabbitMQ via un client PHP Introduction RabbitMQ est un système permettant à diérentes applications clientes de communiquer très simplement en échangeant des messages. Il s'appuie sur le protocole AMQP. Sur la base de ce MOM, nous avons choisis de vous présenter deux exemples distincts, réalisés en nous appuyant sur deux langages : PHP et Ruby. Nous allons voir comment une application A envoie des messages vers RabbitMQ, qui va ensuite les transmettre à une autre application B. La première chose à faire est donc bien évidemment d'installer RabbitMQ Installation du broker RabbitMQ Le paquet rabbitmq-server est inclus dans le dépôt Debian à partir de la version 6.0 (Squeeze) et la version 9.04 d'ubuntu. Le site ociel de RabbitMQ conseille néanmoins d'installer le.deb à partir du site (ou en ajoutant leur propre dépôt dans sources.list), car les versions des dépôts sont désuètes (2.8, sur Debian stable, alors que la dernière version de RabbitMQ est la 3.5). Voila les étapes d'installation : 1. Ajoutez la ligne suivante dans /etc/apt/sources.list : 1 deb testing main 2. Mise a jour des dépôts et installation : 1 sudo apt-get update && sudo apt-get install rabbitmq-server 3. Pour activer RabbitMQ Management Console : 1 sudo rabbitmq-plugins enable rabbitmq management 4. On peut maintenant accéder aux service web de RabbitMQ en utilisant l'adresse suivante : A noter : par défaut, le nom et le mot de passe de l'utilisateur sont "guest/guest". Il est impossible d'accéder à l'interface de management à partir de ce compte. Licence ASRALL 12 IUT Charlemagne

13 3.1.3 Implémentation du Hello World Nous avons repris l'exemple donné dans la documentation du site ociel de RabbitMQ. Il s'agit d'une implémentation très simple, composée d'un producer (application P) qui envoie des messages ; et d'un consumer (application C) qui les reçoit. Nous avons donc écrit deux scripts PHP, exécutés depuis un shell. Un producer, qui a la charge d'envoyer un message, et un consumer, qui reçoit les messages et les achent. Dans le schéma cidessous (image1), "P" est notre producer et "C" est notre consumer. La boîte rouge est une le d'attente (queue) qui contient les messages le temps que le consumer les récupèrent. Nous avons utilisés la librairie php-amqplib pour pouvoir communiquer avec le broker. Il faut alors : 1. Ajouter un chier composer.json au dossier : 1 { 2 "require": 3 { 4 "videlalvaro/php-amqplib": "v2.1.0" 5 } 6 } 2. Installer composer : 1 curl https://getcomposer.org/installer php 3. Exécuter la commande : 1./composer.phar install Le producer Le producer envoit un message JSON, contenant le titre de la tâche à eectuer et le temps que celle-ci doit prendre. Une fois l'autoloader de composer chargé : On initialise une connexion vers le broker. On créé un nouveau channel. On déclare ensuite une queue. (pour que le message arrive dans une queue, il faut que celleci existe. La méthode queue_declare() permet de créer une queue si elle n'existe pas). Dans cet exemple elle s'appelle "hello", et n'est pas durable (si le serveur redémarre, cette queue n'existera plus, ni les messages qu'elle contenait à ce moment là). On crée un message et on le publie. Le paramètre basic_publish() contient le nom de l'exchange à utiliser. RabbitMQ a quelques exchanges précongurés. Licence ASRALL 13 IUT Charlemagne

14 1 #!/usr/bin/php5 2 <?php 3 require_once DIR. '/vendor/autoload.php'; 4 use PhpAmqpLib\Connection\AMQPConnection; 5 use PhpAmqpLib\Message\AMQPMessage; 6 #$connection = new AMQPConnection(' ', 5672, 'nathan', 'nathan'); 7 $connection = new AMQPConnection('localhost', 5672, 'guest', 'guest'); 8 $channel = $connection->channel(); 9 $channel->queue_declare('hello', false, false, false, false); 10 $msg = new AMQPMessage('Hello World!'); 11 $channel->basic_publish($msg, '', 'hello'); 12 echo " [x] Sent 'Hello World!'\n"; 13 $channel->close(); 14 $connection->close(); 15?> Le consumer Ici, il s'agit d'établir une connection et de déclarer la queue. Ceci fait, le consumer s'abonne à la queue. La méthode basic_consume() est la méthode qui sera exécutée pour chaque message transmis à notre consumer. Ici, elle achera simplement le titre fourni dans le message et attendra un temps (dont la durée est dénie dans le message). Lorsqu'il n'a aucun message à traiter, le consumer attend jusqu'à ce qu'il y en ait un qui lui parvienne. On peut lancer le consumer an que celui-ci se mette en attente de messages. Enn, à l'aide d'un autre terminal, on peut exécuter le producer. 1 #!/usr/bin/php5 2 <?php 3 require_once DIR. '/vendor/autoload.php'; 4 use PhpAmqpLib\Connection\AMQPConnection; 5 $connection = new AMQPConnection('localhost', 5672, 'guest', 'guest'); 6 $channel = $connection->channel(); 7 $channel->queue_declare('hello', false, false, false, false); 8 echo ' [*] Waiting for messages. To exit press CTRL+C', "\n"; 9 $callback = function($msg) { 10 echo " [x] Received ", $msg->body, "\n"; 11 }; 12 $channel->basic_consume('hello', '', false, true, false, false, $callback); 13 while(count($channel->callbacks)) { 14 $channel->wait(); 15 } 16 $channel->close(); 17 $connection->close(); 18?> Licence ASRALL 14 IUT Charlemagne

15 4 Les concepts 4.1 Gestion des virtual hosts (ci-après nommé vhost) Les vhosts sont des espaces virtuels, intégrés au broker, qui peuvent héberger un nombre illimité d'exchanges et de queues tout en les isolant les uns des autres. Des droits utilisateurs peuvent être y être dénis ; les vhosts permettent à un serveur RabbitMQ de simuler la pésence d'autant de brokers que voulu, et permettent de ce fait des communications en loopback physique. Les vhosts se gèrent en ligne de commande via l'outil rabbitmqctl : 1 #creation 2 rabbitmqctl add_vhost vhost_name 3 #listing 4 rabbitmqctl list_vhosts 5 #suppression 6 rabbitmqctl delete_vhost vhost_name 4.2 Gestion des utilisateurs Les utilisateurs sont des entités disposant de certains droits vis à vis du broker, Il existe 3 droits fondamentaux : congure : droit de supprimer les exchanges et les queues du broker, et d'en déclarer pour certains modes particuliers. read : droit de déclarer des exchange et des queues, de bind / unbind des routing_keys dans les exchanges uniquement, de consommer et de purger des messages. write : droit de publier un message, et de bind / unbind pour les exchange et les queues. Note importante : Les droits utilisateurs s'appliquent toujours à un vhost ; les commandes suivantes ne fonctionneront qu'à la condition que l'argument -p soit non vide et fasse référence à un vhost existant. 1 #suppression d'un utilisateur 2 rabbitmqctl delete_user guest 3 #ajout d'un utilisateur 4 rabbitmqctl add_user my_user_1 5 #ajout de toutes les permissions sur vhost_name a my_user_1 6 rabbitmqctl set_permissions -p vhost_name my_user_1 ".*" ".*" ".*" 7 #ajout du droit de lecture / ecriture uniquement sur queues et exchanges prexes par " test " 8 rabbitmqctl set_permissions -p vhost_name my_user_2 "" "test.*" "test.*" 4.3 Les types d'exchange Note : Les schémas présentés ci-après proviennent de la documentation ocielle de RabbitMQ : http ://www.rabbitmq.com/tutorials/tutorial-six-php.html Licence ASRALL 15 IUT Charlemagne

16 Rappel : un exchange est un espace dans lequel sont déposés les messages (par les publishers), d'ou ils sont distribués aux queues spéciées, selon une méthode particulière. Ce sont ces méthodes qui diérencient les exchanges ; nous en verrons 5 pour RabbitMQ. Il en existe 6 en réalité, mais la dernière, nommée "RPC", est très particulière et très peu utilisée. Les exchanges sous RabbitMQ : L'exchange default L'exchange fanout L'exchange direct L'exchange topic L'exchange headers Default Ce premier exchange est celui activé par défaut ; il ne prend aucun paramètre, et place simplement le message dans la queue qui a été désignée lors de l'appel du producer. Néanmoins, comme le montre le schéma ci-dessous, cet exchange permet de répartir la charge de travail entre plusieurs consumers s'ils écoutent tous les deux sur la queue concernée. Ainsi, le producer place le message, via un exchange par défaut, dans une queue identiée (nommée). Nos deux consumers vont se connecter à cette même queue, et attendre qu'on leur assigne des tâches. Si une seconde tâche est poussée dans la queue avant que la première ne soit terminée par consumer 1, alors consumer 2 va intervenir et s'en occuper. De plus, si consumer 1 échoue à réaliser la tâche (s'il n'envoie pas d'acknowledgement au producer), alors celui ci va renvoyer le message pour que consumer 2 exécute la tâche à sa place Fanout Le fonctionnement de l'exchange fanout ressemble très fortement au concept de broadcast ; le producer place un message dans l'exchange, an que tous les consumers ayant souscrit à la queue puissent récupérer une instance du message, et ce sans aucun ltrage ni distinction. Licence ASRALL 16 IUT Charlemagne

17 Une fois le message dans l'exchange de type fanout, les consumers s'y connectent (l'exchange doit donc posséder un nom) ; ils créent alors une queue anonyme et temporaire (existant seulement le temps de consommer le message), qu'ils bindent (attachent) à l'exchange. Ne reste plus alors qu'à consumer les messages Direct L'exchange direct nécessite que l'on rajoute un argument au message envoyé par le producer ; cet argument peut alors être pris en compte par le consumer pour savoir dans quelle queue doit aller le message. Ce mécanisme permet de router les messages selon un ou plusieurs paramètres. Comme l'indique le schéma, ce type d'exchange matchera exactement les arguments passés. Le consumer, dans ses bindings, doit passer les arguments qui lui permettront de matcher les messages qui l'intéressent. Ainsi, les messages dont les routing-keys ont la valeur suivante : orange : ira dans la queue 1 black ou green : ira dans la queue Topic Ce dernier mode est le plus exible et le plus puissant de tous. Il permet de router très nement les messages, grâce à un mécanisme de pattern proche des expressions régulières. Les topics s'appuient sur deux symboles : # : signie 0 ou N mots * : signie exactement 1 mot Si nous imaginons une communication en mode topic sur des messages dont les routing-keys sont composés de noms d'animaux et de couleur : Licence ASRALL 17 IUT Charlemagne

18 Ainsi, les messages dont les routing-keys ont la valeur suivante : faster.orange : n'ira nul part (il doit y avoir 1 mot avant ET après orange) lazy.orange.ape : ira dans la queue 1 (répond aux critères) very.lazy.white.rabbit : n'ira nulle part (ne doit pas contenir plus de 2 mots avant rabbit) lazy : ira dans la queue 2 (les paramètres sont optionnels) lazy.white.blue.red.green.little.tiger : ira dans la queue 2 (nombre de paramètres entre 0 et N) Cette façon de faire permet à un consumer d'écouter des messages provenant d'ensembles structurés et hiérarchiques. Comme pour le routage, les consumers bindent un ensemble de routing_keys matchant les topics souhaités. Ainsi, il est possible de congurer les applications réceptrices avec toute la exibilité désirée Headers L'exchange headers route les messages selon un ou plusieurs entête(s) du message AMQP, à la diérence des autres qui se basent sur une routing-key. Licence ASRALL 18 IUT Charlemagne

19 5 Infrastructure utilisée 5.1 Phase 1 : Le bac à sable L'objectif de cette première infrastructure était de "jouer" avec RabbitMQ, et de nous familiariser avec le fonctionnement des queues et des diérents types d'exchanges. An de faciliter les tests et la manipulation des brokers RabbitMQ, nous avons décidés de simuler une infrastructure physique à 3 noeuds, à l'aide de kvm et libvirt. Chaque noeud de cette infrastructure hébergeait un serveur RabbitMQ, et se trouvait donc en position de produire comme de consommer des messages. Voici les caractéristiques techniques de l'infrastructure, composée de 3 brokers de messages (3 brokers diérents, pas 1 broker à 3 noeuds...) : Sur l'hôte : kvm 1 :2.1 libvirt Sur les machines virtuelles : rabbimq-server ruby 1 :1.9.3 amq-protocol bunny Pourquoi avoir fait ce choix d'infrastructure? D'une part, il nous fallait tester la possibilité de se connecter à distance aux diérents brokers ; et donc que des consumers situé sur un noeud A puissent accéder à une queue sur un noeud B. D'autre part, le choix de 3 noeuds diérents nous a semblé pertinent pour les raisons suivantes Pouvoir utiliser un producer et deux consumers simultanément (pour les exchanges fanout, direct et topic), tout en s'assurant qu'ils communiquent tous à distance Dispatcher des vhosts RabbitMQ sur de multiples noeuds, et savoir donc gérer la conguration des consumers aérents. Etre en capacité de dénir plusieurs utilisateurs disposant de droits diérents sur les noeuds, dans le but d'également en maîtriser la manipulation et la conguration. Licence ASRALL 19 IUT Charlemagne

20 5.2 Phase 2 : L'infrastructure de la maquette - Chirement de mail Cette infrastructure a été pensée dans le but de répondre aux besoins de la maquette que nous ont demandés de réaliser monsieur Goulin et monsieur Alluin. Notre préoccupation, à cette étape, a été de créer une infrastructure fonctionnelle ; la scalabilité ou la redondance n'ont pas été des critères importants en phase 2. Réaliser cette maquette imposait les contraintes suivantes : Deux serveurs postx Une application de chirement Un broker RabbitMQ assurant le transport des données L'application de chirement et le serveur postx devaient se situer sur des VMs diérents, car elles implémentent chacune un consumer amqp destinée à recevoir tout les messages provenant du broker RabbitMQ, puis les injectent dans les applications qui les traitent. Il était bien plus simple, confortable, et compréhensible, de séparer chaque "couche" de la maquette en l'intégrant à une machine virtuelle dédiée. Sur l'hôte ( ), nous avons conguré un serveur DNS (avec bind9) et dénis un domaine "rmq" comportant les entrées suivantes. Pour le broker : broker1 IN A Pour l'application : encrypter IN A mail-input IN A mail-output IN A Pour la haute disponibilité broker2 IN A virtual-ip IN A Licence ASRALL 20 IUT Charlemagne

21 Voici un schéma décrivant le contenu de chacune de ces machines : Licence ASRALL 21 IUT Charlemagne

22 Voici quelques réponses aux questions que vous vous posez certainement : Pourquoi deux serveurs postx diérents? Un serveur postx remplissant les rôles de mail-input et mail-output n'eut-il pas été susant? D'une part, nous avons préférés séparer "physiquement" (quoique virtuellement) les diérentes parties de notre maquette ; cela nous apportait une meilleure lisibilité, et la possibilité d'expliquer notre travail plus aisément. En second lieu, il était inconcevable de n'avoir qu'un seul serveur postx, car il est impossible de conditionner l'utilisation du module pipe ; ainsi, avec un unique serveur postx, les mails auraient bouclés sans n dans le circuit de notre infrastructure. Pourquoi mettre l'application de chirement sur une VM à part? Là encore, notre principal objectif a été la clarté. Mais il était également nécessaire de générer le plus de trac amqp possible, car c'est là l'objet de ce projet. Il eut donc été stupide de procéder diéremment. 5.3 Phase 3 : L'infrastructure de la maquette - Load-balancing et haute disponibilité Pour la phase 3, l'infrastructure a du évoluer, en ajoutant à l'existant un second serveur RabbitMQ, que nous avons nommé broker2. Ci-contre, les caractéristiques de la machine : 6 Envoi et chirement de mail 6.1 Présentation du besoin Le besoin lié à la réalisation de cette maquette (Proof of Concept) peut être découpé ainsi : Le besoin métier : Réaliser une maquette permettant de chirer automatiquement un grand nombre de mails. La contrainte pédagogique : utiliser un MOM comme solution de communication entre les diérents composants, an d'avoir un couplage faible entre la couche application et la couche communication, c'est à dire que les applications devaient être totalement indépendantes de leur moyen de communication. Licence ASRALL 22 IUT Charlemagne

23 A titre d'exemple, il faut que l'ajout d'une fonctionnalité (une application de traduction, par exemple) ne change rien à la topologie du système de communication inter-applicatif. Les MOMs ont été pensés pour cela, leur utilisation s'imposait donc comme une évidence dans ce contexte. La contrainte de scalabilité : l'application devait présenter une scalabilité certaine, ainsi qu'une tenue de charge importante, et se devait donc d'être compatible avec des solutions de clustering et de loadbalancing telles qu'haproxy et pacemaker. La plupart des MOMs répondent à ces contraintes, et possèdent une architecture pensée dans ce sens. 6.2 Présentation de la solution Basée sur l'infrastructure décrite dans le chapitre précédent, elle nous a permis d'avoir une répartition des rôles claire. voici la maquette sous la forme d'un schéma : Licence ASRALL 23 IUT Charlemagne

24 La solution retenue a été : trois applications en interaction, dialoguant ensemble à travers un broker RabbitMQ. mail-input, qui s'occupe de détourner l'envoi des mails, de formatter ses données (et ses métadonnées) sous une forme exploitable par le protocole amqp. L'application encrypter, ensuite, chargée de recevoir le message amqp, de l'ouvrir, d'en chirer le contenu, puis de le renvoyer vers la dernière application mail-output, chargée pour sa part de naliser l'envoi du mail. Comme langage de script, nous avons choisi bash, et ce pour plusieurs raisons : C'est un langage standard, ne nécessitant aucune installation supplémentaire. Il permet de gérer facilement les processus, les status, et l'appel de commandes système. Le langage était connu et maîtrisé par nos tuteurs. C'est l'outil le plus répandu chez les administrateurs système à l'heure actuelle. Le MOM que nous avons choisi est bien entendu RabbitMQ, car de tous ceux que nous avons étudiés, c'est lui le plus simple, le plus facile à utiliser et à installer ; sa documentation, claire et complète nous a beaucoup facilitée le travail ; il répondait de surcroît à toutes les contraintes qui nous avaient été données. Le client AMQP qui a été sélectionné est : amqp-tools. il s'agit d'un ensemble de binaire, exécutable en ligne de commande, packagé au sein de Debian, permettant l'envoi et la réception de message amqp à destination de brokers tels que RabbitMQ ; à noter : il permet de lire le corps des messages amqp, mais pas leurs entêtes, ce qui nous a causés des ennuis lors de la phase de load-balancing. Pour pallier à ce manque nous avons du utiliser ruby et sa bibliothèque amqp Bunny. Pour gérer l'envoi de mail, nous avons choisi le serveur de mail postx, en grande partie pour sa exibilité et sa gestion du transport (dont le module pipe fait partie), qui était une caractéristique indispensable de notre application de chirement. C'est enn le caractère standard de ce serveur qui a fait pencher la balance dénitivement en sa faveur. 6.3 Le fonctionnement mail-input En résumé : Tout d'abord, le serveur postx de mail-input est conguré de façon à détourner les mails vers le script mailinput_mom_mailinjecter, grâce au module "pipe". Juste avant d'être envoyé au destinataire via smtp (ou directement dans la mailbox si le serveur local est le domaine nal de destination), le mail est "détourné" vers l'entrée standard d'une commande ; permettant ainsi d'opérer un traitement, via un langage de script quelconque, dessus. Ci-après, le schéma du mécanisme de pipe dans le contexte de notre maquette. Licence ASRALL 24 IUT Charlemagne

25 1 # Voici la conguration postx aérente sur mail-input : /etc/postx/master.cf 2 # Exécution du script à destination du MOM 3 # 4 mailinjecter unix - n n - - pipe 5 user=rabbit argv=/home/rabbit/mailinput_mom_mailinjecter ${sender} ${recipient} Quelques explications s'imposent : mailinjecter : le nom de l'entrée dans le chier de conguration pipe : le module postx à utiliser user : l'utilisateur unix qui lance le script argv : le chemin complet du script à exécuter ${sender} et ${recipient} : des macros postx - informations contenues dans le mail Licence ASRALL 25 IUT Charlemagne

26 Il faut commencer par envoyer un mail, qui sera intercepté par le module pipe de postx ; voici un script réalisant cela : En ce qui concerne mailinput_mom_mailinjecter, ce script reçoit un mail provenant du module pipe de postx (conguré dans cet but) ; il nettoie le mail reçu de son contenu superu (les headers smtp, notamment), puis construit un message amqp exploitable par amqp-tools et RabbitMQ ; enn, il envoit le message sur l'exchange direct, bindé sur la routing-key "to_encrypt". Voici les logs produits, si tout se passe comme prévu : Pour plus de détails quant au fonctionnement de ce script, vous pouvez vous référer à l'annexe 1 : La réalisation de ce script a posée quelques dicultés, notamment lorsque nous avons du choisir un format pour le message amqp. Comment nettoyer le mail pipé par postx? Par quelle méthode découper la chaine de caractère de façon à la splitter au sein de diérentes variables? Et surtout, comment faire, une fois le message amqp transmis sur une autre machine (et donc un autre shell bash) pour retrouver exactement le même format et la même indentation? De façon à ce que le destinataire reçoive le même mail que celui d'origine, évidemment. Awk proposait une solution très puissante pour le nettoyage du mail ; et la syntaxe HEREDOC nous a permis de conserver parfaitement l'indentation, la "forme" du mail encrypter En résumé : Pour encrypter_mom_mailencrypter, le fonctionnement est le suivant : il reçoit le contenu du message amqp provenant de mail-input.rmq sur son entrée standard ; il extrait du message les informations suivantes dans des variables bien distinctes : sender (expéditeur) recipient (destinataire) subject (sujet) content (contenu du message) Licence ASRALL 26 IUT Charlemagne

27 Suite à cela, il essaie de chirer le mail avec la clef publique du destinataire ; si celle ci n'existe pas, il envoie une erreur sous la forme d'un message amqp à mail-input, qui alerte l'expéditeur de l'echéc de l'opération. Sinon, le message amqp d'origine est reconstruit, avec le contenu chiré cette fois ; puis est envoyé vers mail-output. Voici les logs produits, si tout se passe comme prévu : Pour plus de détails quant au fonctionnement de ce script, vous pouvez vous référer à l'annexe 2 : A ce stade, la diculté a été de récupérer les données convenablement ; sed n'a pas été notre premier choix. Nous avons tentés beaucoup d'autres solutions, avec awk et bash, avant d'y penser. Nous avons eu un cas intéressant, qui nous a servi de leçon et nous a démontré l'intérêt du travail en équipe. Guillaume, qui travaillait sur ce script à ce moment là, était parti dans l'idée qu'il devait extraire les données du message amqp, à la façon de php (fonction array_pop, ou instruction "list") ; il a cherché à travailler sur les données elles-même, sans se rendre compte qu'il n'avait qu'à les acher avec un outil comme grep et sed, puis aecter la sortie standard à une variable bash, et de ce fait récupérer leur valeur comme il convenait. Cette erreur a été résolue par Saber, qui lui a simplement fait remarquer qu'il s'embêtait pour rien. Et cinq minutes plus tard, tout marchait parfaitement. Cet épisode nous a montré le danger d'avoir excessivement "la tête dans le guidon", et l'intérêt que chacun corrige ou soutienne le travail de l'autre ; car il sera évidemment bien plus frais sur le problème à résoudre, avec un regard neuf et le recul indispensable mail-output En résumé : Le script mailoutput_mom_mailforwarder reçoit, via l'entrée standard, le message amqp en provenance de encrypter ; il en extrait les données, puis envoie un mail au destinataire dont l'adresse se trouve à l'intérieur du message. Voici les logs produits, si tout se passe comme prévu : Licence ASRALL 27 IUT Charlemagne

28 Pour plus de détails quant au fonctionnement de ce script, vous pouvez vous référer à l'annexe 3 : Nous n'avons pas rencontré de dicultés particulières sur ce script ; il reprend dans les grandes lignes la structure des scripts précédents. En revanche, il nous a fallu congurer postx de façon à ce qu'il utilise le compte gmail de guillaume pour envoyer les mails chirés broker1 Le broker a simplement été conguré pour disposer d'un utilisateur nommé "ub1v1" récepteur du mail Le client mail était situé, dans notre cas, sur l'hôte de l'infrastructure. Nous avons travaillés avec icedove (thunderbird - debian), et le plugin enigmail. Ci-contre, une capture d'écran du mail dans le cas ou l'utilisateur n'insère pas la passphrase qui lui est demandé : Ici, une capture d'écran sur le mail déchiré après que l'utilisateur eut entré sa passphrase dans le popup ouvert par enigmail : Licence ASRALL 28 IUT Charlemagne

29 7 Industrialisation 7.1 Transformation des consumers en services Linux (daemon) Pourquoi Il était très laborieux de lancer manuellement les scripts consumers à chaque démarrage de notre infrastructure ; de surcroit, ces appications devant tourner en continu, il nous a semblé tout à fait naturel de chercher à les transformer en service. Dans ce but, nous avons crées, sur la base de procédures trouvées sur le site ociel de debian, deux scripts (daemon_structure.sh et create_daemon.sh) permettant une génération totalement autiomatisée de services sysvinit. Lancer cette transformation est plutôt simple : bash create-deamon.sh <nom du script> Mise en place Il a d'abord fallu créer un script bash constituant le squelette d'un service, que nous avons nommés daemon_structure.sh. En voici le contenu (la gestion des paramètres d'entrée a été volontairement retirée, ne présentant que peu d'intérêt) : 1 2 Auteur : Saber Dir 3 Organisation : IUT Charlemagne (License ASRALL) 4 License : GNU/GPL 5 6 Description : Structure de base nécessaire pour transformer un script passé 7 en paramètre en service (daemon) DAEMON="/home/rabbit/SCRIPT_BASENAME" 11 DAEMON_OPT="" 12 DAEMON_USER="rabbit" 13 DAEMON_NAME="SCRIPT_BASENAME" PATH="/sbin:/bin:/usr/sbin:/usr/bin:/home/rabbit" test -x $DAEMON exit /lib/lsb/init-functions d_start () { 21 log_daemon_msg "Starting system $DAEMON_NAME Daemon" 22 # On s'assure ainsi que ce démon se à la n du démarrage de la machine 23 # pour s'assurer de la disponibilité des connections réseaux. 24 sleep Licence ASRALL 29 IUT Charlemagne

30 26 start-stop-daemon --background --start --quiet --chuid $DAEMON_USER --exec $DAEMON -- $DAEMON_OPT 27 log_end_msg $? 28 } Nous avons dénis dans ces variables bash un marqueur (SCRIPT_BASENAME), remplacé plus tard (avec la commande sed) par le nom du script à transformer en service : DAEMON="/home/rabbit/SCRIPT_BASENAME" DAEMON_OPT="" DAEMON_USER="rabbit" DAEMON_NAME="SCRIPT_BASENAME" Les options utilisées : --start - pour démarrer le script ; --quiet - pour rendre le script silencieux (CQFD) ; --background - pour mettre le script en arrière-plan (CQFD) ; --exec $DAEMON - pour lancer le programme ; Au départ, nous avions utilisés deux autres options : --make-pidfile afin de créer un fichier contenant le pid du service (pour pouvoir forcer l'arrêt plus --pidfile \$PIDFILE qui nous permet de définir le fichier dans lequel sera le PID. Mais nous nous sommes vite rendu compte que les programmes dont nous avions besoin du PID étaient les commandes amqp-consume forkées à l'intérieur de nos scripts encrypter_mom_mailconsumer et mailoutput_mom_mailconsumer ; il était donc inutile d'utiliser ces options ; les PID devaient être récupérés et sauvegardés dans le code même de nos consumers, juste après l'exécution des commandes amqp-consume. Puis, le script create_daemon.sh, qui se charge, sur la base de daemon_structure.sh, de générer un service complètement valide et compatible sysvinit sous debian stable. En voici la partie essentielle : 1 cp /home/rabbit/$script_name /usr/bin/$script_name 2 3 # Copie la structure du démon dans /etc/init.d/ 4 write_log INF "Copy the daemon structure into /etc/init.d" 5 cp /home/rabbit/daemon_structure.sh /etc/init.d/$script_name 6 7 # Remplace la chaîne SCRIPT_BASENAME par le nom du script dans la structure du démon 8 write_log INF "Replace SCRIPT_BASENAME by $script_name" 9 sed -i "s/script_basename/$script_name/g" /etc/init.d/$script_name # Procède à quelques vérications 12 write_log INF "Ensure that $script_name is executable and rabbit is the owner" 13 chmod u+x /etc/init.d/$script_name 14 chown rabbit:rabbit /etc/init.d/$script_name Licence ASRALL 30 IUT Charlemagne

31 15 16 # Génère les liens symbolqies nécessaires dans les dossier rc*.d 17 # Enregistre le script en tant que service 18 write_log INF "Make an update.rc defaults and a insserv on $script_name" 19 update-rc.d $script_name defaults 20 insserv $script_name # Démarre le service 23 write_log INF "Start the daemon $script_name" 24 /etc/init.d/$script_name start #************************************************************************** 27 #EOF 28 #************************************************************************** write_log END "Successfully executed" 31 exit 0 Notre service accepte maintenant un ensemble d'options que l'on peut passer directement au script de la ligne de commande, par exemple : start: démarre un service stop: arrète un service restart: redémarre un service sans recharger son fichier de configuration reload: envoie un signal SIGHUP à un processus en cours d'exécution status: renvoie l'état d'un service Lors de la réalisation de cette partie du projet, nous avons rencontrés une épineuse diculté. Les processus amqp-consume ne s'exécutaient pas à chaque démarrage de l'infrastructure. Au début, ça nous a semblé se produire de façon totalement aléatoire. Les logs des diérents consumers ne montraient rien, si ce n'est que les scripts se lançaient correctement ; c'était les commandes amqp-consume, qui ne fonctionnaient pas. Au cours de tests, nous nous sommes aperçus que certaines ressources du broker étaient verrouillées lors du redémarrage de l'infrastructure ; fort de cette nouvelle donnée, nous nous sommes vite rendus compte qu'arrêter, puis redémarrer le broker RabbiMQ arrangeait le soucis. Chaque redémarrage qui suivait une purge du broker permettaient aux processus amqp-consume de démarrer. Néanmoins, impossible de comprendre pourquoi le broker avait besoin d'être purgé pour que les consumers démarrent et soient à l'écoute. Nous avons donc réaliser un debug "step by step", en exécutant l'infrastructure, et en faisant varier les paramètres suivants : variation de la durée du sleep, pour le lancement du service exécution des consumers en utilisateurs diérents (root, rabbit) purge, ou non, de broker1 Licence ASRALL 31 IUT Charlemagne

32 Ces exécutions comparatives nous ont permis d'éliminer un certain nombre d'hypothèses, et nous ont amenées à nous concentrer sur le problème du broker qui bloque ses ressources (queues et exchanges) en cas de redémarrage de l'infrastructure. En faisant quelques recherches, nous avons nalement trouvés le bug : Nous arrêtions les vm en faisant : virsh --connect system:///qemu destroy nom_de_la_vm Cette commande équivaut à débrancher un serveur physiquement. En eectuant cela sur broker1, celuici n'avait pas le temps de libérer les ressources précédement allouées ; ainsi, lors du redémarrage elles étaient en état "locked", et il était nécessaire de purger broker1 pour permettre à nos consumers de démarrer. La solution était simplement d'arrêter nos vm à l'aide de cette commande : virsh --connect system:///qemu shutdown nom_de_la_vm Ainsi, broker1 fermait proprement ses processus, et libérait toutes les ressources qu'il utilisait précédemment. La résolution de ce bug a été longue et dicile, car nous ne disposions pas de logs précis permettant de comprendre ce problème, et ce soucis pouvait avoir de nombreuses sources ; il nous a fallu procéder par élimination. Ce fut un authentique dé intellectuel et méthodologique. Le problème a été résolu à partir du moment ou nous nous sommes contraints à noter chaque étape du processus de debug, an d'avancer pas à pas, de façon rigoureuse. ce bug nous a également apporté une connaissance bien plus ne de la façon dont RabbitMQ gère ses élements (queues, exchanges) ; nous savons les lister, les manipuler, et les purger, quand c'est nécessaire. Ca n'a donc pas été du temps perdu ; bien au contraire. 7.2 Redondance et clustering Objectifs Cette partie du travail avait pour objet les points suivants : Assurer la haute disponibilité du broker via du clustering Répartir la charge sur les deux noeuds du broker Voici la solution conçue pour répondre à ce besoin. Une autre solution était possible, plus simple, mais elle ne permettait pas le loadbalancing. Activer la fonctionnalité de clustering interne de RabbitMQ, an de faire de broker1 et broker2 les noeuds d'un même broker, joignable sur une des deux ip. Nous avons préféré utiliser une solution plus générique, à savoir deux serveurs haproxy mis en cluster grâce à Pacemaker et Corosync. Le choix de ces solutions a été rapide à faire ; nous les maîtrisions, et elles sont open-source. Des critères susants pour nous convaincre. Il s'agit ici dun cluster actif/passif. Le schéma de l'infrastructure de haute-disponibilité mise en place : Licence ASRALL 32 IUT Charlemagne

33 7.2.2 Mise en place du cluster Tout d'abord, il a fallu installer la suite logicielle pacemaker (qui contient corosync). apt-get install pacemaker corosync-keygen Puis, congurer ainsi /etc/default/corosync start=yes An que broker1 et broker2 soient reconnus comme les noeuds d'un même cluster, il a fallu congurer /et/corosync/corosync.conf et y modier la partie "interface" de la façon suivante : Licence ASRALL 33 IUT Charlemagne

34 interface { # IP des noeud du broker member { # IP de broker1 memberaddr: } member { # IP de broker2 memberaddr: } ringnumber: 0 # IP du réseau bindnetaddr: } mcastaddr: mcastport: 5405 transport: udpu An de permettre aux deux noeuds de communiquer ensemble, il a fallu générer la clef corosync grâce à la commande suivante : corosync-keygen Puis il a été nécessaire de copier ces 2 chiers sur broker2 à l'aide de la commande : scp /etc/corosync/corosync.conf /etc/corosync/authkey Suivi d'un démarrage en règle du gestionnaire de cluster : /etc/init.d/corosync start Seconde étape, et non des moindre, la conguration des ressources du cluster. Nous avons choisi ici de procéder avec l'outil cli "crm" en mode non-interactif : # pas de fencing ici crm configure property stonith-enabled=false # deux noeuds seulement, donc il est nécessaire de désactiver le quorum crm configure property no-quorum-policy=ignore crm configure primitive VIRTUAL-IP ocf:heartbeat:ipaddr2 params ip=" " nic="eth0" op monitor crm configure primitive HAPROXY lsb:haproxy op monitor interval="10s" # nécessaire pour que les ressources démarrent ensemble group group-web VIRTUAL-IP HAPROXY commit Licence ASRALL 34 IUT Charlemagne

35 Il est à noter que la ressource VIRTUAL-IP a une adresse membre du réseau /24. Néanmoins, le cluster ne fonctionne pas encore, car les load-balancers haproxy ne sont pas installés sur les noeuds ; il s'agit de notre prochaine étape Mise en place du load-balancing Notre choix logiciel concernant le load-balancing, comme l'indique la conguration Pacemaker, s'est arrêté sur Haproxy. Les raisons en sont simples : il s'agit d'un projet mature, réputé, et open-source, que nous avons eu l'occasion d'utiliser par le passé. Notre objectif dans la mise en place d'haproxy était d'en installer un sur chaque noeud du cluster. De cette façon, même si un noeud du cluster se retrouve déconnecté ou dysfonctionne, la répartition de charge aura toujours lieu. Voici comment l'installation d'haproxy s'est déroulée : étant sous debian stable (Wheezy), haproxy n'était pas dans les dépôts ociels ; il a donc été nécessaire d'ajouter les dépôts backports, en ajoutant dans /etc/apt/sources.list : deb wheezy-backports main Voici la conguration du load-balancing tel que décrite dans le chier /etc/haproxy/haproxy.cfg listen rabbitmq_cluster :5673 mode tcp # load-balancing en tour par tour balance roundrobin # délai de 3 heures avant la fermeture inopinée de la connection TCP timeout client 3h timeout server 3h # envoit des paquets TCP keepalived côté client ET côté serveur option tcpka # les 2 noeuds RabbitMQ doivent être actifs et en capacité de répondre server broker1 broker1.rmq:5672 check inter 5000 rise 2 fall 3 server broker2 broker2.rmq:5672 check inter 5000 rise 2 fall 3 Il ne reste plus qu'à relancer corosync : /etc/init.d/corosync restart Et à acher l'état du cluster pour voir le résultat : Licence ASRALL 35 IUT Charlemagne

36 Voilà, Le cluster est correctement conguré Changement au sein de nos applications Au niveau de notre application de chirement, il a fallu changer la valeur du paramètre server des commandes amqp-consume et amqp-publish, an que les producers et consumers s'adressent à l'ip virtuelle du cluster, sur laquelle écoute haproxy au niveau du port 5673, an que celui-ci redispatche en round-robin les requêtes sur broker1 et broker2 alternativement. 1 --server virtual-ip.rmq:5673 \ RAPPEL : virtual-ip est enregistré dans la zone "rmq" du DNS de l'hôte, à l'ip Conclusion sur le clustering et le loadbalancing C'est une partie que nous n'avons pas pu terminer, faute de temps. La défection d'israël nous a privé d'une force de travail qui nous eut été utile pour terminer ce morceau. Le basculement des noeuds fonctionne au niveau du cluster, mais nous ne sommes pas parvenus à faire en sorte que les connections TCP se déplacent sur broker2 sans s'interrompre, au cas ou nous eteignions brutalement broker1 (le basculement s'opère, mais la connection des commandes amqp-consume cesse). De plus, nous n'avons pas pu prouver que la répartition de charge s'opérait bien sur les noeuds. En apporter la preuve est relativement complexe, et nous aurait demandé un peu de travail supplémentaire. Licence ASRALL 36 IUT Charlemagne

Présentation d'un MOM open-source

Présentation d'un MOM open-source Présentation d'un MOM open-source Saber Dir - Victor Laborie - Guillaume Penaud Licence ASRALL 25 mars 2015 Middleware Orientés Message 25 mars 2015 1 / 29 Sommaire 1 Introduction 2 Etat de l'art 3 Maquette

Plus en détail

Implémentation d'un MOM open-source

Implémentation d'un MOM open-source Implémentation d'un MOM open-source Saber Dir - Victor Laborie - Guillaume Penaud 18 mars 2015 1 Table des matières 1 Introduction et problématiques 4 1.1 Objectifs.............................................

Plus en détail

TARDITI Richard Mise en place d une Haute Disponibilité

TARDITI Richard Mise en place d une Haute Disponibilité TARDITI Richard Mise en place d une Haute Disponibilité Dans le cadre du projet GSB j ai mis en place un cluster de deux machines virtuelles Apache sous Linux, avec une haute disponibilité produite grâce

Plus en détail

Titre: Version: Dernière modification: Auteur: Statut: Licence:

Titre: Version: Dernière modification: Auteur: Statut: Licence: Titre: Installation de WebObjects 5.3 Version: 2.1 Dernière modification: 2011/02/17 11:00 Auteur: Aurélien Minet Statut: version finale Licence: Creative Commons

Plus en détail

SERVEUR WEB HAUTE DISPONIBILITÉ

SERVEUR WEB HAUTE DISPONIBILITÉ SERVEUR WEB HAUTE DISPONIBILITÉ Page 1 Table des matières I. Sujet... 3 II. Caractéristiques du projet... 2 A. Contexte... 2 B. Configuration... 2 C. Étapes et gestion du projet et travail en groupe...

Plus en détail

Télécom Nancy Année 2013-2014

Télécom Nancy Année 2013-2014 Télécom Nancy Année 2013-2014 Rapport 1A Ajout du langage C dans la Programmer's Learning Machine GIANNINI Valentin Loria 615, rue du Jardin Botanique 54600, Villers-Lès-Nancy Maître de stage : QUINSON

Plus en détail

TP : installation de services

TP : installation de services TP : installation de services Ce TP a été rédigé rapidement. Il ne donne certainement pas toutes les explications nécessaires à la compréhension des manipulations. Assurez vous de bien comprendre ce que

Plus en détail

INSTALLATION ET CONFIGURATION SERVEUR RSYSLOG

INSTALLATION ET CONFIGURATION SERVEUR RSYSLOG INSTALLATION ET CONFIGURATION SERVEUR RSYSLOG Table des matières 1. Préambule... 2 2. Pré-requis... 2 3. Installation et configuration du serveur... 3 3.1. Installation... 3 3.1.1. Rsyslog... 3 3.1.2.

Plus en détail

Installation d'un cluster ejabberd

Installation d'un cluster ejabberd Installation d'un cluster ejabberd Sommaire 1. Avant-propos 2. Configuration DNS 3. Installation 1. Installation sur le premier noeud 2. Configuration du noeud 1. Configuration de base 2. Configuration

Plus en détail

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5 Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server 3, 3.5 Machine virtuelle Machine virtuelle Machine virtuelle VMware ESX Network Shutdown Module

Plus en détail

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts

TP : Shell Scripts. 1 Remarque générale. 2 Mise en jambe. 3 Avec des si. Systèmes et scripts E3FI ESIEE Paris Systèmes et scripts B. Perret TP : Shell Scripts 1 Remarque générale Lorsque vous cherchez des informations sur Internet, n'oubliez pas que langage de shell script que nous avons vu correspond

Plus en détail

Architecture de la plateforme SBC

Architecture de la plateforme SBC Simple Business Connector Architecture de la plateforme SBC Titre Projet Description Architecture de la plateforme SBC Plateforme SBC Ce document reprend toutes les étapes de l'installation du serveur

Plus en détail

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée

Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée Sauf mention contraire, le contenu de cet ouvrage est publié sous la licence : Creative Commons BY-NC-SA 2.0 La copie de cet ouvrage est autorisée sous réserve du respect des conditions de la licence Texte

Plus en détail

Projet Système Distribué : Implémentation d'un serveur générateur de certicats. BEUQUE Eric, CORNEVAUX Sébastien, MOUTENET Cyril 13 janvier 2009

Projet Système Distribué : Implémentation d'un serveur générateur de certicats. BEUQUE Eric, CORNEVAUX Sébastien, MOUTENET Cyril 13 janvier 2009 Projet Système Distribué : Implémentation d'un serveur générateur de certicats BEUQUE Eric, CORNEVAUX Sébastien, MOUTENET Cyril 13 janvier 2009 1 Table des matières 1 Sujet 3 2 Analyse 4 3 Création clé

Plus en détail

Réseau : Interconnexion de réseaux, routage et application de règles de filtrage.

Réseau : Interconnexion de réseaux, routage et application de règles de filtrage. TD réseau - Réseau : interconnexion de réseau Réseau : Interconnexion de réseaux, routage et application de règles de filtrage. Un réseau de grande importance ne peut pas seulement reposer sur du matériel

Plus en détail

Parcours IT Projet réseaux informatiques Christophe DOIGNON

Parcours IT Projet réseaux informatiques Christophe DOIGNON FORMATION INGENIEURS ENSPS EN PARTENARIAT (2008-2009) MODULE MI6 DU PARCOURS INFORMATIQUE ET TELECOMMUNICATIONS MISE EN OEUVRE D'UN RESEAU INFORMATIQUE LOCAL EMULE ROUTAGE SOUS LINUX 1. Introduction La

Plus en détail

Chapitre 3 Gestion des sauvegardes

Chapitre 3 Gestion des sauvegardes Chapitre 3 Gestion des sauvegardes 1. Notions préalables et terminologie Gestion des sauvegardes 1.1 Consistance, snapshots et VSS L'erreur la plus commune lorsque l'on parle de solutions de sauvegarde,

Plus en détail

Cours Administration BD

Cours Administration BD Faculté des Sciences de Gabès Cours Administration BD Chapitre 2 : Architecture Oracle Faîçal Felhi felhi_fayssal@yahoo.fr 1 Processus serveur 1 Mémoire PGA Architecture SGBD Oracle Processus serveur 2

Plus en détail

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname

TP2 - Conguration réseau et commandes utiles. 1 Généralités. 2 Conguration de la machine. 2.1 Commande hostname Département d'informatique Architecture des réseaux TP2 - Conguration réseau et commandes utiles L'objectif de ce TP est d'une part de vous présenter la conguration réseau d'une machine dans l'environnement

Plus en détail

Java - TP3. Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet. Année 2008-2009

Java - TP3. Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet. Année 2008-2009 Java - TP3 Nicolas Baudru, Carine Guivier-Curien, Laurent Vallet Année 2008-2009 Le but de ce TD est d'écrire une application client/serveur de type msn : 1. Des clients se connectent à un serveur 2. Un

Plus en détail

Le service FTP. M.BOUABID, 04-2015 Page 1 sur 5

Le service FTP. M.BOUABID, 04-2015 Page 1 sur 5 Le service FTP 1) Présentation du protocole FTP Le File Transfer Protocol (protocole de transfert de fichiers), ou FTP, est un protocole de communication destiné à l échange informatique de fichiers sur

Plus en détail

TPC#9 : Client & Serveur!

TPC#9 : Client & Serveur! TPC#9 : Client & Serveur! Table des matières 1 Structure du rendu 1 2 Introduction 2 3 Sockets et Threads 2 3.1 Les sockets............................................ 2 3.1.1 Cours et exemples....................................

Plus en détail

TD introduction Virtualisation/Réseau/Services. Licence Pro R&T. IUT Nice Sophia-Antipolis

TD introduction Virtualisation/Réseau/Services. Licence Pro R&T. IUT Nice Sophia-Antipolis TD introduction Virtualisation/Réseau/Services Licence Pro R&T IUT Nice Sophia-Antipolis L'objectif de ce TD est de vous familiariser avec l environnement de travail utilisé à l'iut qui est basé sur l'utilisation

Plus en détail

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server

Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server Network Shutdown Module V3 Extension du Manuel Utilisateur pour architecture Virtualisée VMWare ESX Server Machine virtuelle Machine virtuelle Machine virtuelle VMware ESX 3 Network Shutdown Module Network

Plus en détail

Exchange Server 2013 Configuration et gestion de votre environnement de messagerie

Exchange Server 2013 Configuration et gestion de votre environnement de messagerie Introduction à Exchange 1. Présentation d'exchange 17 1.1 La messagerie au sein de l entreprise 17 1.2 L évolution des plateformes Exchange 18 2. Introduction à Exchange 2O13 23 2.1 Contribution aux métiers

Plus en détail

Cosnefroy Thibaut Mars 2015 BTS 2 SIO Répartition de charge serveur web (debian wheezy) Version 1.0 (03/03/2015)

Cosnefroy Thibaut Mars 2015 BTS 2 SIO Répartition de charge serveur web (debian wheezy) Version 1.0 (03/03/2015) Conditions requises: Avoir deux machines déja configurés et prêtes pour faire de la répartition de charge entre machines. La première machine à pour adresse 10.0.0.2 et aura juste apache 2 d'installé.

Plus en détail

PFE Télécommunications. Pré-rapport à l'issue des 6 premières semaines de stage. Page 1 sur 5 1 %

PFE Télécommunications. Pré-rapport à l'issue des 6 premières semaines de stage. Page 1 sur 5 1 % PFE Télécommunications Pré-rapport à l'issue des 6 premières semaines de stage!"!"#$%&' ()*()!")+")# (#),()-,)*)"-./0 1 ()*()!")+-)# % 23 &0 )14) 56 7$8797%77:7' '72 Page 1 sur 5 Contexte Les centres de

Plus en détail

Les messages d erreur d'applidis Client

Les messages d erreur d'applidis Client Fiche technique AppliDis Les messages d erreur d'applidis Client Fiche IS00313 Version document : 1.00 Diffusion limitée : Systancia, membres du programme Partenaires AppliDis et clients ou prospects de

Plus en détail

Sujet Projets 2 nd Semestre

Sujet Projets 2 nd Semestre Sujet Projets 2 nd Semestre Seuls les appels systèmes vus en cours sont autorisés. L usage d autres fonctions doit impérativement être validé par l enseignant. La date d ouverture pour l assignation de

Plus en détail

Exchange Server 2013 Préparation à la certification MCSE Messaging - Examen 70-341

Exchange Server 2013 Préparation à la certification MCSE Messaging - Examen 70-341 Chapitre 1 Introduction à Exchange A. Présentation d'exchange 16 1. Public visé 16 2. La messagerie au sein de l entreprise 16 3. L évolution des plateformes Exchange 17 B. Introduction à Exchange 2O13

Plus en détail

Fonctionnement du serveur Z39.50

Fonctionnement du serveur Z39.50 Fonctionnement du serveur Z39.50 Table des matières 1 Configuration du serveur...2 1.1 Comportement du serveur...2 1.2 Configuration de la traduction z39.50 -> base de données...2 1.3 Configuration du

Plus en détail

Mise en place d'un Serveur DHCP sous Linux Par wawanopoulos

Mise en place d'un Serveur DHCP sous Linux Par wawanopoulos Mise en place d'un Serveur DHCP sous Linux Par wawanopoulos Licence Creative Commons BY 2.0 Dernière mise à jour le 11/07/2010 Sommaire 1/9 Sommaire Sommaire... 1 Mise en place d'un Serveur DHCP sous Linux...

Plus en détail

Contexte InfoRéseau50. Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015

Contexte InfoRéseau50. Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015 Contexte InfoRéseau50 Charles SAINT-LÔ SIO2 Lycée Notre Dame de la Providence Année 2014-2015 1 Présentation du contexte : Je travaille chez InfoRéseau50, qui est une société spécialisée dans la gestion

Plus en détail

Plugin Payment-OnLine

Plugin Payment-OnLine Plugin Payment-OnLine Le plugin "Payment-Online" est un plugin technique dont l'objectif est de faciliter l'utilisation du paiement en ligne dans des applications Lutèce. Il se compose d'une librairie

Plus en détail

Le meilleur de l'open source dans votre cyber cafe

Le meilleur de l'open source dans votre cyber cafe Le meilleur de l'open source dans votre cyber cafe Sommaire PRESENTATION...1 Fonctionnalités...2 Les comptes...3 Le système d'extensions...4 Les apparences...5 UTILISATION...6 Maelys Admin...6 Le panneau

Plus en détail

Comment faciliter l'intégration de ces architectures dans nos SI?

Comment faciliter l'intégration de ces architectures dans nos SI? Comment faciliter l'intégration de ces architectures dans nos SI? Benoit Mortier Directeur Profil de l'orateur Qui? Benoit Mortier né en 1967 en Belgique Quoi? Fondateur de Opensides in 2001 Responsable

Plus en détail

Back up Server DOC-OEMSPP-S/6-BUS-FR-17/05/11

Back up Server DOC-OEMSPP-S/6-BUS-FR-17/05/11 Back up Server DOC-OEMSPP-S/6-BUS-FR-17/05/11 Les informations contenues dans le présent manuel de documentation ne sont pas contractuelles et peuvent faire l objet de modifications sans préavis. La fourniture

Plus en détail

TP : Le jeu de Bataille. 1 Le jeu de bataille. 2 Programmation du jeu. Algorithmes et Programmation Impérative 2

TP : Le jeu de Bataille. 1 Le jeu de bataille. 2 Programmation du jeu. Algorithmes et Programmation Impérative 2 Univ. Lille1 - Licence Informatique 2ème année 2012-2013 Algorithmes et Programmation Impérative 2 TP : Le jeu de Bataille Objectifs : Réaliser un programme utilisant les structures de piles et de les.

Plus en détail

Load Balancing. Table des matières. Gatien, Julien, Rémi, Vincent. 2 mars 2009. 1 Le projet 2. 2 L'équilibrage de charge 2.

Load Balancing. Table des matières. Gatien, Julien, Rémi, Vincent. 2 mars 2009. 1 Le projet 2. 2 L'équilibrage de charge 2. Load Balancing Gatien, Julien, Rémi, Vincent 2 mars 2009 Table des matières 1 Le projet 2 2 L'équilibrage de charge 2 3 Algorithmes 2 4 État de l'art 3 4.1 LVS..........................................

Plus en détail

C. Configuration des services de transport

C. Configuration des services de transport Page 282 Chapitre 8 Dans la version 2013 d'exchange, les dossiers publics sont devenus un type de boîtes aux lettres et utilisent les mêmes mécanismes de routage que les e-mails. - Le message est destiné

Plus en détail

Guide de sécurité de VMware vrealize Log Insight

Guide de sécurité de VMware vrealize Log Insight Guide de sécurité de VMware vrealize vrealize 2.5 Ce document prend en charge la version de chacun des produits répertoriés, ainsi que toutes les versions publiées par la suite jusqu'au remplacement dudit

Plus en détail

Administration Des Réseaux

Administration Des Réseaux M1 Réseaux Informatique et Applications Administration Des Réseaux Date: 27/11/07 Auteurs: Gaël Cuenot Professeur: Patrick Guterl Table des matières 1Introduction...3 2Problème 1: SYN flood...3 2.1Présentation...3

Plus en détail

Rapport d'architecture

Rapport d'architecture Romain Alexandre Cécile Camillieri Rapport d'architecture 1 / 12 Table des matières I) Description du projet p. 3 1) Canaux de communication p. 3 2) Diagrammes de cas d'utilisation p. 3 II) Gestion des

Plus en détail

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com - 5, rue Soutrane - 06560 Valbonne Sophia-Antipolis E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com NQI Orchestra 3.3 - Guide d'installation Linux....................................................................

Plus en détail

CAHIER DES CHARGES D IMPLANTATION

CAHIER DES CHARGES D IMPLANTATION CAHIER DES CHARGES D IMPLANTATION Tableau de diffusion du document Document : Cahier des Charges d Implantation EVRP Version 6 Etabli par DCSI Vérifié par Validé par Destinataires Pour information Création

Plus en détail

CAHIER DES CHARGES D IMPLANTATION D EvRP V3

CAHIER DES CHARGES D IMPLANTATION D EvRP V3 CAHIER DES CHARGES D IMPLANTATION D EvRP V3 Tableau de diffusion du document Document : Cahier des Charges d Implantation EVRP V3 Version 42 Etabli par Département Accompagnement des Logiciels Vérifié

Plus en détail

Sujets des projets L2 Programmation Orientée Système II deadline : 10/05/2015

Sujets des projets L2 Programmation Orientée Système II deadline : 10/05/2015 Sujets des projets L2 Programmation Orientée Système II deadline : 10/05/2015 9 mars 2015 Introduction L'objectif de ces projets est de vous proposer une application des notions vues en cours, dans des

Plus en détail

Répartition des charges avec HaProxy CONTEXTE MFC JULIEN HUBERT

Répartition des charges avec HaProxy CONTEXTE MFC JULIEN HUBERT 2015 Répartition des charges avec HaProxy CONTEXTE MFC JULIEN HUBERT Développée par le français Willy Tarreau en 2002, HAProxy est une solution libre, fiable et très performante de répartition de charge

Plus en détail

Hyper-V et SC Virtual Machine Manager sous Windows Server 2008 R2

Hyper-V et SC Virtual Machine Manager sous Windows Server 2008 R2 186 Hyper-V et SC Virtual Machine Manager sous Windows Server 2008 R2 L'utilisation des fonctionnalités de haute disponibilité intégrées aux applications, L'ajout de solutions tierces. 1.1 Windows Server

Plus en détail

TP 6 : Java Server Pages et Tomcat.

TP 6 : Java Server Pages et Tomcat. TP 6 : Java Server Pages et Tomcat. Christophe Gravier, Frédérique Laforest, Julien Subercaze Télécom Saint-Étienne Université Jean Monnet {pnom.nom}@univ-st-etienne.fr FI2_INFO4 20122013 1 / 24 Plan Objectifs

Plus en détail

Préparation à l installation d Active Directory

Préparation à l installation d Active Directory Laboratoire 03 Étape 1 : Installation d Active Directory et du service DNS Noter que vous ne pourrez pas réaliser ce laboratoire sans avoir fait le précédent laboratoire. Avant de commencer, le professeur

Plus en détail

SISR1 CH5 Gérer un ordinateur à distance

SISR1 CH5 Gérer un ordinateur à distance SISR1 CH5 Gérer un ordinateur à distance - Page 1 - Sommaire Application 1 Gestion d'un ordinateur à distance (entre 2 postes sous Windows)...2 Préambule...2 Coté serveur (Server)...3 Coté client (Viewer)...4

Plus en détail

http://cri.univ-lille1.fr Virtualisation de Windows dans Ubuntu Linux

http://cri.univ-lille1.fr Virtualisation de Windows dans Ubuntu Linux http://cri.univ-lille1.fr Virtualisation de Windows dans Ubuntu Linux Version 1.0 Septembre 2011 SOMMAIRE 1. Introduction 3 2. Installation du logiciel de virtualisation VirtualBox 4 3. Création d'une

Plus en détail

IP Office IP Office Manuel de l'utilisateur de la messagerie vocale intégrée

IP Office IP Office Manuel de l'utilisateur de la messagerie vocale intégrée Manuel de l'utilisateur de la messagerie vocale intégrée 15-604067 Version 11a - (29/04/2011) 2011 AVAYA Tous droits réservés. Note Bien que tous les efforts nécessaires aient été mis en œuvre en vue de

Plus en détail

Windows sur Kimsufi avec ESXi

Windows sur Kimsufi avec ESXi Introduction Depuis fin 2013 les serveurs Kimsufi sont livrés avec une seule adresse IPv4 et une seule adresse IPv6. De même les distributions Windows ne sont plus disponibles à l'installation Il est cependant

Plus en détail

«clustering» et «load balancing» avec Zope et ZEO

«clustering» et «load balancing» avec Zope et ZEO IN53 Printemps 2003 «clustering» et «load balancing» avec Zope et ZEO Professeur : M. Mignot Etudiants : Boureliou Sylvain et Meyer Pierre Sommaire Introduction...3 1. Présentation générale de ZEO...4

Plus en détail

SISR3 : Cluster de basculement de serveurs de fichiers

SISR3 : Cluster de basculement de serveurs de fichiers SISR3 : Cluster de basculement de serveurs de fichiers Objectif : Mettre en place un cluster de basculement de deux serveurs de fichiers. Il est nécessaire pour ce TP de disposer d'un Active Directory,

Plus en détail

Introduction. Licence MASS L3 Inf f3

Introduction. Licence MASS L3 Inf f3 Le modèle client serveur Introduction Licence MASS L3 Inf f3 Encapsulation : rappel Données Données Application En-tête En-tête Transport UDP Données TCP Données Paquet UDP Segment TCP En-tête IP Données

Plus en détail

Guide utilisateur Guide d utilisation. Connexion à la plateforme Cloud... 3 Utiliser l interface... 4. Structuration de l'interface...

Guide utilisateur Guide d utilisation. Connexion à la plateforme Cloud... 3 Utiliser l interface... 4. Structuration de l'interface... 1 Table des matières Connexion à la plateforme Cloud... 3 Utiliser l interface... 4 Structuration de l'interface... 4 Le tableau de bord (Dashboard)... 5 Les machines virtuelles... 6 Propriétés... 6 Actions...

Plus en détail

Installation de (K)unbutu

Installation de (K)unbutu Installation de (K)unbutu Après avoir créer notre machine virtuelle, il s'agit de lui installer un Système d'exploitation ou OS. Nous avons choisi de lui installer (K)ubuntu. Pour cela, après avoir fini

Plus en détail

Documentation utilisateur, manuel utilisateur MagicSafe Linux. Vous pouvez télécharger la dernière version de ce document à l adresse suivante :

Documentation utilisateur, manuel utilisateur MagicSafe Linux. Vous pouvez télécharger la dernière version de ce document à l adresse suivante : Documentation utilisateur, manuel utilisateur MagicSafe Linux. Vous pouvez télécharger la dernière version de ce document à l adresse suivante : http://www.hegerys.com/documentation/magicsafe-windows-doc.pdf

Plus en détail

Retrospect 7.7 Addendum au Guide d'utilisation

Retrospect 7.7 Addendum au Guide d'utilisation Retrospect 7.7 Addendum au Guide d'utilisation 2011 Retrospect, Inc. Certaines parties 1989-2010 EMC Corporation. Tous droits réservés. Guide d utilisation d Retrospect 7.7, première édition. L utilisation

Plus en détail

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL

TP n 2: Mise en place d'un serveur Web avec PHP et MySQL TP n 2: Mise en place d'un serveur Web avec PHP et MySQL Le but de ce TP est de vous apprendre comment installer et congurer un serveur Web avec PHP et MySQL sous Linux. Cela requiert plusieurs étapes

Plus en détail

BTS SIO 2. Projet GSB. Apache 2. Voiset Nicolas

BTS SIO 2. Projet GSB. Apache 2. Voiset Nicolas BTS SIO 2 Projet GSB Apache 2 Voiset Nicolas 1 Table des matières 1-Contexte d utilisation... 3 2-Informations d utilisation... 5 3-Comparaison... 5 4-Problèmes et solutions... 6 5-Phase de test... 6 Annexe1-Configuration

Plus en détail

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server

Un serveur FTP chez soi Tutoriel pour Filezilla FTP server Space-OperaRécitsLogicielsCréationsBlogForum Un serveur FTP chez soi Tutoriel pour Filezilla FTP server DynDNS : Pourquoi et comment? Téléchargement et installation de Filezilla Server Configuration réseau

Plus en détail

La Haute disponibilité des modules EOLE

La Haute disponibilité des modules EOLE La Haute disponibilité des modules EOLE EOLE 2.3 révisé : Janvier 2014 Documentation sous licence Creative Commons by-nc-sa - EOLE (http ://eole.orion.education.fr) V e r s i o n d u d o c u m e n t r

Plus en détail

Guide de démarrage. pour Solution de gestion des EPN (Espaces Publics Numériques)

Guide de démarrage. pour Solution de gestion des EPN (Espaces Publics Numériques) Guide de démarrage pour Solution de gestion des EPN (Espaces Publics Numériques) 73 rue de Saint-Mandrier 83140 Six-Fours Tél.: 04 89 81 43 43 - Fax : 09 89 39 88 59 - www.aesis-conseil.com RCS Toulon

Plus en détail

AJAX est l'acronyme d'asynchronous JavaScript And XML, autrement dit JavaScript Et XML Asynchrones.

AJAX est l'acronyme d'asynchronous JavaScript And XML, autrement dit JavaScript Et XML Asynchrones. Le concept d'ajax Introduction AJAX est l'acronyme d'asynchronous JavaScript And XML, autrement dit JavaScript Et XML Asynchrones. AJAX n'est ni une technologie ni un langage de programmation ; AJAX est

Plus en détail

Linux Solutions de Haute Disponibilité (2ième édition)

Linux Solutions de Haute Disponibilité (2ième édition) Introduction 1. Introduction 19 2. Remerciements 22 Disponibilité du stockage 1. Introduction au SAN 23 1.1 Mutualiser le stockage 23 1.2 Avantages 24 1.3 Protocoles 25 1.4 Infrastructure 26 1.5 Accès

Plus en détail

Grid Technology. ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Technology Group Information Technology Department

Grid Technology. ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Technology Group Information Technology Department DB GT CF Grid ActiveMQ pour le grand collisionneur de hadrons (LHC) Lionel Cons Grid Group Information Department Journée de la communauté FUSE, Paris, 2010 CERN IT Department CH-1211 Geneva 23 Switzerland

Plus en détail

Module M3102 TP 0. Préambule - Environnement des TP

Module M3102 TP 0. Préambule - Environnement des TP Module M3102 TP 0 Préambule - Environnement des TP Les TP du module M3102 ne vont pas se faire avec des équipements physiques (routeurs et switches placés sous le bandeau de pré-câblage en salles 405 et

Plus en détail

Documentation déploiement Auteur: Ratefiarivony Herimamy herimamy.ratefiarivony@enscachan.fr Date: 23/10/08

Documentation déploiement Auteur: Ratefiarivony Herimamy herimamy.ratefiarivony@enscachan.fr Date: 23/10/08 Objet: Documentation déploiement Auteur: Ratefiarivony Herimamy herimamy.ratefiarivony@enscachan.fr Date: 23/10/08 Présentation de l'architecture matérielle du SIENS/Cachan: Spider3 (Linux) via adaptor

Plus en détail

Pouvez-vous expliquer pourquoi «ok!» ne s'affichera-t-il pas dans ces conditions? Proposez un morceau de code qui corrige le problème. (coef.

Pouvez-vous expliquer pourquoi «ok!» ne s'affichera-t-il pas dans ces conditions? Proposez un morceau de code qui corrige le problème. (coef. 1 Citez au moins une des nouveautés introduites par PHP 5.3. (coef. 2) Réponse attendue : namespace, closure, objet DateTime... bref n'importe quoi de neuf dans PHP 5.3 Objectif : mesurer la culture G

Plus en détail

Partager des fichiers avec un NAS

Partager des fichiers avec un NAS Partager des fichiers avec un NAS Avec la multiplication des écrans à la maison (ordinateurs sous Windows, Mac ou Linux, tablettes, smartphones, TV connectées, consoles de jeux), il devient de plus intéressant

Plus en détail

TD séance n 2c Mise à jour des Systèmes

TD séance n 2c Mise à jour des Systèmes 1 Gestion des Logiciels 1.1 Introduction sur les logiciels Un logiciel est un programme nécessaire au fonctionnement d'un ordinateur (logiciel système) ou au traitement de données (logiciel applicatif).

Plus en détail

Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source JShaft

Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source JShaft Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source Jérôme Petit, Serge Petit & Serli Informatique, ITMatic Jérôme Petit, Serge Petit & SERLI & ITMatic Serli : SSII

Plus en détail

Service SMTP Le multiple instances Artica v1.4.063000 / Postfix 2.6.x Guide de démarrage

Service SMTP Le multiple instances Artica v1.4.063000 / Postfix 2.6.x Guide de démarrage Service SMTP Le multiple instances Artica v1.4.063000 / Postfix 2.6.x Guide de démarrage Page : 1/12 Table des matières Introduction : Pourquoi le multiple-instances? :...3 Le comportement standard...3

Plus en détail

Sauvegardes sous Windows c 2003 serveur

Sauvegardes sous Windows c 2003 serveur Sauvegardes sous Windows c 2003 serveur Louis-Maurice De Sousa ~ Fabrice Lemoine ~ Jackie Daon 27 mars 2006 Table des matières 1 Introduction 3 2 NTbackup 3 2.1 La sauvegarde...........................

Plus en détail

Installation de la messagerie EMWAC IMS Sur Windows NT4 serveur ou Windows 2000 serveur

Installation de la messagerie EMWAC IMS Sur Windows NT4 serveur ou Windows 2000 serveur Installation de la messagerie EMWAC IMS Sur Windows NT4 serveur ou Windows 2000 serveur Ce document explique comment utiliser les services de messagerie EMWAC IMS avec un serveur NT4 ou 2000 ou 2003, il

Plus en détail

TP Administration Système : Compilation d'un noyau Linux 2.6.x.y

TP Administration Système : Compilation d'un noyau Linux 2.6.x.y TP Administration Système : Compilation d'un noyau Linux 2.6.x.y 29 septembre 2005 Mickaël Marchand Sébastien Varrette Bernard Parisse

Plus en détail

Compte-rendu de projet de Système de gestion de base de données

Compte-rendu de projet de Système de gestion de base de données Compte-rendu de projet de Système de gestion de base de données Création et utilisation d'un index de jointure LAMBERT VELLER Sylvain M1 STIC Université de Bourgogne 2010-2011 Reponsable : Mr Thierry Grison

Plus en détail

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com

E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com - 5, rue Soutrane - 06560 Valbonne Sophia-Antipolis E-mail : contact@nqicorp.com - Web : http://www.nqicorp.com NQI Orchestra 3.3 - Guide d'installation Windows.................................................................

Plus en détail

II Importation et retrait automatiques de

II Importation et retrait automatiques de II Importation et retrait automatiques de postes de travail Les services d'importation et de retrait automatiques de postes de travail de Novell ZENworks for Desktops (ZfD) permettent de gérer facilement

Plus en détail

Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server

Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server Microsoft OSQL OSQL ou l'outil de base pour gérer SQL Server Suite à mon précédent article concernant MSDE, je me suis rendu compte à partir des commentaires que de nombreux utilisateurs avaient des problèmes

Plus en détail

L3 ASR Projet 1: DNS. Rapport de Projet

L3 ASR Projet 1: DNS. Rapport de Projet L3 ASR Projet 1: DNS Rapport de Projet Table des matières I. Maquette de travail...1 II. Configuration des machines...2 III. Type de zone...3 IV. Délégation de zone...3 V. Suffixes DNS...4 VI. Mise en

Plus en détail

CONNECTEUR PRESTASHOP VTIGER CRM

CONNECTEUR PRESTASHOP VTIGER CRM CONNECTEUR PRESTASHOP VTIGER CRM Page 1 / 14 Vtiger CRM - Prestashop Connector Pour PRESTASHOP version 1.4.x et 1.5.x Pour vtiger CRM version 5.1, 5.2.0, 5.2.1, 5.3 et 5.4 Introduction En tant que gérant

Plus en détail

Notice du LiveCD Spécialité Réseaux

Notice du LiveCD Spécialité Réseaux Notice du LiveCD Spécialité Réseaux 21 2 Ethereal : Ethereal est un sniffer de réseau, il capture les trames circulant sur le réseau, en permet l'analyse et sépare suivant l'encapsulation les différnetes

Plus en détail

[Serveur de déploiement FOG]

[Serveur de déploiement FOG] 2012 Yann VANDENBERGHE TAI @ AFPA Lomme [Serveur de déploiement FOG] Procédure d'installation d'un serveur FOG pour la création et le déploiement d'images disques. 1.1 Introduction : Malgré le développement

Plus en détail

MANUEL D INSTALLATION D UN PROXY

MANUEL D INSTALLATION D UN PROXY MANUEL D INSTALLATION D UN PROXY Squid, SquidGuard, Dansguardian Dans ce guide on va détailler l installation et la configuration d une solution proxy antivirale en utilisant les outils ; squid, dansguardian,

Plus en détail

Archipel: une couche au dessus de libvirt

Archipel: une couche au dessus de libvirt Archipel: une couche au dessus de libvirt Emmanuel Blindauer IUT R.Schuman, Université de Strasbourg 72 route du Rhin, ILLKIRCH Résumé Archipel est un logiciel de gestion d'hyperviseurs et de machines

Plus en détail

Raspberry pi : Développer une petite application web sur Raspberry

Raspberry pi : Développer une petite application web sur Raspberry Raspberry pi : Développer une petite application web sur Raspberry Introduction Le Raspberry Pi est un nano-ordinateur basé sur une architecture ARM (conçu par David Braden) qui permet l'exécution de plusieurs

Plus en détail

M2-ESECURE. Virtualisation : XEN. Pierre BLONDEAU

M2-ESECURE. Virtualisation : XEN. Pierre BLONDEAU M2-ESECURE Virtualisation : XEN Pierre BLONDEAU La virtualisation Wikipedia : La virtualisation consiste à faire fonctionner un ou plusieurs systèmes d'exploitation1 / applications (comme un navigateur),

Plus en détail

SCOoffice Mail Connector for Microsoft Outlook. Guide d'installation Outlook 2002

SCOoffice Mail Connector for Microsoft Outlook. Guide d'installation Outlook 2002 SCOoffice Mail Connector for Microsoft Outlook Guide d'installation Outlook 2002 Rév 1.1 4 décembre 2002 SCOoffice Mail Connector for Microsoft Outlook Guide d'installation - Outlook XP Introduction Ce

Plus en détail

Partie sur papier: durée 1h30, sans documents Partie Unix

Partie sur papier: durée 1h30, sans documents Partie Unix Partie sur papier: durée 1h30, sans documents Partie Unix Question 1 :généralités Q1: Quel fichier contient les directives de montage des volumes au démarrage du système? Q2: Citez une commande permettant

Plus en détail

Guide d'installation et de démarrage du Driver X-WAY sur TCP/IP

Guide d'installation et de démarrage du Driver X-WAY sur TCP/IP Guide d'installation et de démarrage du Driver X-WAY sur TCP/IP Sommaire Chapitre Page 1 Mise en oeuvre 1/1 1.1 Généralités 1/1 1.1-1 Architecture documentaire 1/1 1.1-2 Compatibilités 1/1 1.2 Installation

Plus en détail

S E C U R I N E T S C l u b d e l a s é c u r i t é i n f o r m a t i q u e I N S A T. Tutoriel Postfix

S E C U R I N E T S C l u b d e l a s é c u r i t é i n f o r m a t i q u e I N S A T. Tutoriel Postfix Tutoriel Postfix 1. Introduction : Un peu d historique : Postfix est le système de courrier crée par Wietse Venema, également auteur des TCP wrappers, reconnus pour leur intérêt dans le domaine de la sécurité,

Plus en détail

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7

et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Tsoft et Groupe Eyrolles, 2006, ISBN : 2-212-11747-7 Il est possible, pour des objets, de visualiser ou modifier le contenu. La présentation des objets dans le navigateur peut être paramétrée ; vous trouverez

Plus en détail

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox

Service WEB, BDD MySQL, PHP et réplication Heartbeat. Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Version utilisée pour la Debian : 7.7 Conditions requises : Dans ce TP, il est nécessaire d'avoir une machine Debian sous ProxMox Caractéristiques de bases : Un service web (ou service de la toile) est

Plus en détail

Fiche Technique Windows Azure

Fiche Technique Windows Azure Le 25/03/2013 OBJECTIF VIRTUALISATION mathieuc@exakis.com EXAKIS NANTES Identification du document Titre Projet Date de création Date de modification Fiche Technique Objectif 25/03/2013 27/03/2013 Windows

Plus en détail