MP2P PROTOCOLE & SYSTÈME DE STOCKAGE REDONDANT COACHING 2 – 30/04/2015 Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH.

Présentation au sujet: "MP2P PROTOCOLE & SYSTÈME DE STOCKAGE REDONDANT COACHING 2 – 30/04/2015 Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH."— Transcription de la présentation:

1 MP2P PROTOCOLE & SYSTÈME DE STOCKAGE REDONDANT COACHING 2 – 30/04/2015 Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

2 Table des matières 1.Le projet – Rappel 2.Rappel du périmètre projet 3.Travail réalisé durant la période 4.Avancée du projet par rapport au planning 5.Suivi des risques 6.Difficultés rencontrées 7.Demande explicite d’assistance technique 8.Résultats attendus pour la séance suivante de coaching 9.Conclusion Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

3 Le projet - Rappel MP2P, QU’EST-CE QUE C’EST ? Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

4 MP2P, c’est… Un système de stockage redondant Un système de stockage avec transferts améliorés pour utiliser toute la bande passante du client Un protocole Un couple d’applications Client/Server Un système adapté pour de grosses infrastructures (hébergeurs – Datacenters…) Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

5 MP2P, ce n’est pas… Un site web Un front-end Un système sécurisé (Intégrité & disponibilité, mais pas encore confidentialité) Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

6 Détails techniques et technologies utilisées Les outils et applications : Développement d’une bibliothèque en C++ contenant les fonctionnalités suivantes : Transferts réseau multi-threadés (boost.asio) Traitement des fichiers Un logger Développement d’une application « Master » en C++ Développement d’une application « Storage » en C++ Développement d’une application « Client » en C++ Mise en place d’un système de bases de données avec réplication : Couchbase Utilisation d’un build system : CMake Utilisation d’un outil d’intégration continue : TeamCity Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

7 Changements ? Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH Deux changements principaux ont eu lieu : Séparation de l’application Serveur en deux (anciennement faisant office de Master ET Storage) : Une application Master Une application Storage -> Pourquoi ? Des différences évidentes sont apparues entre ces deux applications. -> Ce que ça change pour nous ? Rien car nous n’avions pas commencé à les développer. Séparation de la Base de données du Master et création d’un cluster de bases de données : -> Pourquoi ? ◦La base de données nécessite un cluster sur le même réseau pour permettre une réplication efficace. ◦Pour la simplicité de configuration en local. -> Ce que ça change pour nous ? ◦Une facilité de mise en place et de développement. ◦Un coût supplémentaire pendant le développement (utilisation de 2 VM hostées – $5,76/mois)

8 Ancienne structure Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

9 Ancienne structure Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

10 Nouvelle structure

11 Rappel du périmètre CE QUE NOUS PRÉVOYONS POUR LE RENDU FINAL Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

12 Rappel du périmètre Notre projet se limitera aux éléments suivants : Upload d'un fichier sans perte de données Download d'un fichier sans perte de données Download d'un fichier avec une augmentation de vitesse Upload d'un fichier avec réplication de X parties sur Y serveurs différents Suppression d'un fichier sans laisser de mémoire occupée inutilement Possibilité d'ajouter autant de serveurs que souhaité Gestion des mises à jour Gestion d'une configuration à l'aide d'un fichier Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

13 Travail réalisé durant la période AVANCÉE DU PROJET Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

14 Travail réalisé durant la période Mise en place d’un « build system » Créer la bibliothèque d’outils Définir le protocole Division, envoi multi-threadé, reconstitution et écriture d’un fichier (à optimiser) Vérifications du hash d’un fichier avec SHA-1 Lecture d’un fichier de configuration (format JSON) Créer la base de données Mettre en place une base de données Couchbase avec réplication (redondance X) Faire un wrapper au dessus de l’interface pour simplifier les échanges avec le reste du code en cours… Créer l’application Serveur Lier la bibliothèque avec serveur Faire l’interface entre le C++ et la base de données Développement de l’application en cours… Créer l’application Client Lier la bibliothèque avec client Développement de l’application en cours… Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

15 Données à conserver en BDD Nous avons défini que les données suivantes sont à conserver : Storage (ID, ipv6_addr, available_space) Master (ID, ipv6_addr) File (ID, part[] parts, hash, redundancy, size) Part (ID, hash, size, storage[] locations) Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

16 Réalisation de fiches de test Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

17 Exemple de fiche de test

18 Ce que nous avons appris…

19 Ce que nous avons appris… …du côté technique Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH Des concepts avancés de c++ : threads intégrés dans des objets le modèle producteur/consommateur, la gestion des accès concurrents aux données. L’utilisation de boost::asio : Serveur multi-threadé écoutant sur le même port Réception asynchrone des données Mise en place d’un cluster Couchbase avec réplication (BDD)

20 Ce que nous avons appris… …du côté gestion de projet Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH Dès qu'un problème émerge, il est important de discuter avec tous les membres du groupe concernés, afin de le résoudre rapidement et d'un commun accord. Il faut se réunir fréquemment pour définir la répartition des tâches afin de ne pas effectuer de travail redondant. Réfléchir techniquement au projet avant de planifier les grandes parties.

21 Avancée du projet par rapport au planning SOMMES NOUS DANS LES TEMPS ? Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

22 Avancée du projet par rapport au planning Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH Planning prévu Planning effectif

23 Avancée du projet par rapport au planning Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

24 Suivi des risques Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

25 Suivi des risques Ne s’étant pas (encore) produit : Glissement du planning Gestion des erreurs pas suffisante/trop compliquée Risques s’étant produit : Rencontre de problématiques bloquantes (réplication/stockage distribué/bdd) Installation de la base de données sur Archlinux problématique, -> Après concertation, solution trouvée : installer sur des VM hostés sous Ubuntu Problème de robustesse de la plateforme de test Les Raspberry Pi (3) à notre disposition ne disposaient pas de suffisamment de ressources pour maintenir la BDD Couchbase -> Après concertation, solution trouvée : installer sur des VM hostés sous Ubuntu Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

26 Difficultés rencontrées Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

27 Difficultés rencontrées La prise en main de boost::asio pour tout ce qui est réseau Le transfert d’un fichier en plusieurs parties avec reconstitution La mise en place de la BDD Couchbase La plateforme de test insuffisante Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

28 Demande explicite d’assistance technique Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

29 Demande explicite d’assistance technique Nous ne demandons pour le moment pas d’assistance technique. Nous apprenons par nous même et aucune des problématiques rencontrées n’a pour le moment bloquée le développement. Chacune avait sa solution. Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

30 Résultats attendus pour la séance de coaching suivante Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

31 À la séance de coaching suivante… Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH À la date du 21/05/15 nous prévoyons : Deux applications « Master » et « Storage » presque fonctionnelles -> Il était prévu de terminer l’application Serveur à la date du 22/05/15 et l’intégration des fonctionnalités du Storage à la date du 12/06/15 mais suite à la modification de la structure de l’application, nous prévoyons donc une finalisation du « Master » et du « Storage » à la date du 12/06/15 Un client bien avancé Des interactions avec la BDD avancées

32 Conclusion Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

33 Conclusion Pas de problème particulier rencontré Pas de retard vis-à-vis du planning Equipe toujours motivée & unie Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH

34 Des questions ? DES REMARQUES ? Julien DUBIEL – Mathieu CORRE – Francis VISOIU MISTRIH