2015 AA2 FR onitu .pdf



Nom original: 2015_AA2_FR_onitu.pdf

Ce document au format PDF 1.3 a été généré par LaTeX with hyperref package / Mac OS X 10.10.4 Quartz PDFContext, et a été envoyé sur fichier-pdf.fr le 09/08/2015 à 13:26, depuis l'adresse IP 94.252.x.x. La présente page de téléchargement du fichier a été vue 887 fois.
Taille du document: 2.6 Mo (39 pages).
Confidentialité: fichier public


Aperçu du document


Onitu

EIP Onitu
Bilan Architecture AA2

21 juillet 2015

EIP Onitu — Bilan Architecture AA2

Onitu
Résumé du document
Ce document présente la deuxième édition du Bilan d’architecture de notre projet Onitu. Ce
bilan a pour but de détailler les composants de la future solution, et ainsi de nous guider dans
sa réalisation. Il offre ainsi un regard synthétique sur le projet, permettant à toute personne
extérieure d’en comprendre la conception.
À travers diverses vues sous forme de diagrammes, le lecteur est ainsi amené à découvrir en profondeur l’architecture de notre programme, et les subtilités qui le composent. Ce
traitement débute par une vision globale du projet avant de s’intéresser aux différents points
particuliers qu’il aggrège.

EIP Onitu — Bilan Architecture AA2

Onitu
Description du document
Titre
Date
Auteur
Responsable
E-Mail
Sujet
Mots clés
Version du modèle

EIP Onitu
21/07/2015
Alexandre Baron
Louis Roché
onitu_2015@labeip.epitech.eu
Bilan d’architecure
architecture, use cases, vues, composants
3.0

Tableau des révisions
Date
11/09/2013

Auteur
Antoine Rozo

12/09/2013
12/09/2013
12/09/2013
13/09/2013

Yannick Péroux
Alexandre Baron
Mathis Dupuy
Morgan Faget

13/09/2013
13/09/2013
14/09/2013
14/09/2013

Wannes Rombouts
Antoine Rozo
Yannick Péroux
Wannes Rombouts

Section(s)
Chapitre 1,
10, 11
Chapitre 9
Chapitre 5
Chapitre 6
Chapitre 4
Chapitre 8
Chapitre 7
Chapitre 2
Chapitre
8.1

Commentaires
Introduction, Taille et Qualité
Vue données
Vue logique
Vue processus
Use Cases principaux et détaillés
Implémentation
Vue déploiement
Architecture globale
Amélioration du texte, ajout
d’explications

EIP Onitu — Bilan Architecture AA2

Onitu

Table des matières
1 Introduction
1.1 Rappel de l’EIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Contexte et périmètre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Définitions, acronymes et abréviations . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
1
2

2 Représentation de l’architecture globale

3

3 Architecture, buts et contraintes
3.1 Objectifs spécifiques ayant un impact sur l’architecture . . . . . . . . . . . . . . .
3.2 Contraintes fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Contraintes non fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
5
5
6

4 Vue globale du projet
4.1 Use Cases principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Use Cases détaillés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
7
7

5 Vue logique de l’application
5.1 Vue globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Composants principaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9
9
11

6 Vue processus

12

7 Vue déploiement

18

8 Implémentation
8.1 Vue globale . . . . . . . . . . .
8.1.1 Messaging . . . . . . . .
8.1.2 Canaux de comunication
8.1.3 Séquences type . . . . .
8.2 Couches applicatives . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

20
20
20
21
23
29

9 Vue données

31

10 Taille et performance

32

11 Qualité

34

EIP Onitu — Bilan Architecture AA2

Onitu

Chapitre 1

Introduction
1.1

Rappel de l’EIP

Epitech, école d’expertise informatique en cinq ans, offre aux étudiants l’opportunité de
réaliser un projet de fin d’études sur trois ans, l’EIP (pour Epitech Innovative Project ).
À ce titre, les élèves doivent s’organiser en un groupe d’au moins cinq personnes et choisir
un sujet porteur de nouveautés ou améliorant un ancien sujet. L’EIP est un passage obligatoire
et unique dans la scolarité de l’étudiant, de par son envergure (18 mois) et la préparation
requise. Le but est, à la fin du temps imparti, d’obtenir un projet commercialisable.

1.2

Contexte et périmètre du projet

Onitu est un projet visant à proposer une alternative libre et open-source au serveur
d’Ubuntu One.
Ubuntu One est un service de Canonical (sponsor officiel d’Ubuntu) permettant de disposer
d’un espace de stockage en ligne, synchronisé entre différents ordinateurs et périphériques
compatibles via un logiciel client. Le client et le protocole d’Ubuntu One sont disponibles sous
licence libre. Néanmoins, le serveur est propriétaire et n’a pas été publié.
L’objectif d’Onitu est de proposer un équivalent libre à ce serveur, afin de profiter des
fonctionnalités d’Ubuntu One tout en maîtrisant le stockage des données et des informations.
Les fichiers gérés par Onitu pourront être stockés sur un serveur administré par son utilisateur, ou bien sûr des services tiers tels que Dropbox, Amazon S3, ou Google Drive. L’innovation
d’Onitu réside dans un paramétrage fin de façon à ce que l’utilisateur puisse choisir sur quels
services seront stockés quels fichiers.
La cible première d’Onitu est l’utilisateur averti, soucieux des problématiques de centralisation des données, et son entourage, à qui il fera profiter le serveur mis en place. Il n’est pas
forcément technicien mais assez curieux, le profil même de l’utilisateur Ubuntu. Onitu vise
aussi à être utilisé au sein d’entreprises ayant la volonté de maîtriser facilement le stockage
de leur données.

Introduction

1/35

1.3

Définitions, acronymes et abréviations

Onitu

— SGDB : Système de Gestion de Base de Données.
— Core, Referee, Plug, drivers : Organes spécifiques de notre applications, détaillés en
partie 5.2.
— Redis, Circus, ZeroMQ (ou Zmq, 0mq) : Différentes bibliothèques utilisées au sein de
notre programme, elles aussi détaillées dans la section 5.2.

Introduction

2/35

Onitu

Chapitre 2

Représentation de l’architecture
globale
Onitu doit répondre à des contraintes de latences très fortes. De nombreux événements
peuvent survenir en très peu de temps, mais avec des temps de traitement extrêmement variés (de quelques millisecondes à plusieurs heures). Afin de répondre à cette contrainte, l’architecture globale se doit d’être décentralisée, et de pouvoir monter en charge facilement.

Les différents éléments sont donc isolés dans des processus systèmes, qui sont lancés et surveillés par le logiciel Circus. Les processus partagent les informations dont ils ont besoin via
la base de données en mémoire Redis, et échangent des données via des sockets ZeroMQ.

Le schéma suivant présente les différents éléments constituant Onitu, avec pour exemple deux
drivers, un premier pour Ubuntu One et un second pour Dropbox. Les flèches pointillées représentent la parenté (quel processus lance quel processus), et les flèches avec des tirets
représentent la communication via ZeroMQ.

Représentation de l’architecture globale

3/35

Onitu

Figure 2.1 – Architecture globale
Représentation de l’architecture globale

4/35

Onitu

Chapitre 3

Architecture, buts et contraintes
3.1

Objectifs spécifiques ayant un impact sur l’architecture

La réflexion sur l’architecture du projet passe d’abord par la définition d’objectifs clairs,
que voici énoncés.
Le premier objectif est d’offrir une alternative libre au serveur Ubuntu One, et donc d’être
entièrement compatible avec ce dernier.
Un autre est d’offrir à l’utilisateur un contrôle total sur ses données, il lui revient de choisir
où ses fichiers seront stockés.
Aussi, pour une meilleure expérience utilisateur, cette solution se devra d’être facilement
déployable.
Un des objectifs est aussi de permettre de stocker les données sur des services externes,
tels Dropbox, par l’intermédiaire de drivers. C’est principalement autour de cet objectif que
se forme l’architecture du projet.

3.2

Contraintes fonctionnelles

Différentes contraintes permettent aussi de diriger les choix techniques. Premièrement,
les contraintes fonctionnelles, qui décrivent les caractéristiques du système.
Il a été décidé que les différents drivers communiqueraient entre-eux à l’aide de queues
de messages. Ainsi, le programme disposera d’un core très basique, ne s’occupant que de la
transmission des messages.
Une autre contrainte et la volonté de pouvoir assurer une réplication des données sur
différents services. Par l’intermédiaire des drivers, préalablement configurés, qui écouteront
les modifications d’un ensemble de fichiers pour les reproduire à l’identique sur leur espace
de stockage.
L’ensemble des modules devront pouvoir être configurés de façon centralisée à l’aide d’un
DSL, permettant une configuration plus souple qu’un simple système clef-valeur.

Architecture, buts et contraintes

5/35

3.3

Contraintes non fonctionnelles

Onitu

Les autres contraintes, non fonctionnelles, régissant les choix architecturaux sont les suivantes.
Onitu devra être conforme au protocole définit par Ubuntu One, puisque compatible avec
le client officiel.
L’utilisation de certaines bibliothèques, telles que Twisted, non portée en Python3, contraint
à l’utilisation d’une version antérieure.
Dans un soucis de simplicité, le DSL proposé devra être facilement compréhensible par
l’utilisateur, ne devra pas le rebuter. Ce dernier devrait sans problème pouvoir bénéficier
d’une configuration fine de son système.
C’est principalement dans un soucis de protection et contrôle des données que la solution
Onitu sera utilisée, c’est pourquoi sa sécurité doit être maximale.

Architecture, buts et contraintes

6/35

Onitu

Chapitre 4

Vue globale du projet
Ce chapitre est destiné à présenter au lecteur les différentes actions possibles sur le système et leurs implications.
Ces actions sont représentées sous forme de diagrammes UML nommés use cases, et présentés en deux catégries : les principaux qui offrent une vision globale de celles-ci, et les
diagrammes détaillés qui explicitent en profondeur ces actions.

4.1

Use Cases principaux

Figure 4.1 – Use Cases principaux

4.2

Use Cases détaillés

Vue globale du projet

7/35

Onitu

Figure 4.2 – Use Cases détaillés

Figure 4.3 – Use Cases détaillés

Vue globale du projet

8/35

Onitu

Chapitre 5

Vue logique de l’application
5.1

Vue globale

Structurellement, l’application Onitu est divisée en plusieurs modules séparés selon leur
rôle. Tout d’abord le Core, nœud central de l’application. Puis le Referee (ou aiguilleur), qui
a pour mission de rediriger correctement les fichiers à synchroniser, et enfin les drivers, des
briques logicielles créées sur mesure pour chaque protocole voulu, chargées de relayer les
communications entre le Core et l’application cible de chacune d’entre elles. Les drivers sont
des instances de ce qu’on appelle un Plug.
Étant une application résolument orientée réseau, Onitu a par conséquent besoin d’outils performants pour gérer un nombre de connexions ainsi que des transferts de fichiers qui
peuvent potentiellement être conséquents. Pour cela, nous nous basons sur Circus, un manager de processus et de sockets, avec lequel nous interagissons grâce au daemon circusd
pour le lancement d’Onitu, mais également au travers de son API Python à l’intérieur de notre
programme.
Circus utilise ZeroMQ, une surcouche très performante aux systèmes de sockets classiques
et bénéficiant de nombreuses améliorations (systèmes de publisher/subscriber, divide-andconquer, etc.).
Pour encore plus de rapidité, nous utilisons également Redis, un SGBD clé-valeur en mémoire, permettant d’excellentes performances en minimisant les accès disques. Il est lui aussi
géré par Circus.

Vue logique de l’application

9/35

Vue logique de l’application
Figure 5.1 – Vue logique de l’application

Onitu

10/35

5.2

Composants principaux

Onitu

Dans cette partie, nous allons décrire plus en détails les principaux composants de notre
application.
— Le Core : Il s’agit du nœud central, celui destiné à tourner sur le serveur et héberger
toutes les informations du système et des fichiers qui y sont synchronisés (métadonnées,
etc.). Il devra être configurable, soit au moyen d’un fichier de configuration, soit via une
interface web.
— Le Referee : Aussi appelé aiguilleur, il est l’nterlocuteur direct du Core. Lorsqu’une
modification sur le système est détectée (ajout, suppression, modification de fichier. . .),
c’est l’entité qui est chargée de décider, à partir de règles établies au préalable (dans
la configuration par exemple), avec quels drivers faut-il synchroniser l’information ou
commencer un transfert.
— Le Plug : C’est l’entité générique qui se connecte (d’où son nom) au Referee pour récupérer et envoyer des données à un driver spécifique.
— Les drivers : Les drivers sont des programmes interagissant chacun avec un Plug (au
moyen de décorateurs) afin de faire la transition entre le système Onitu et l’application
cible (Dropbox, Ubuntu One. . .) dans le protocole de cette application.
— Redis : Système de gestion de base de données clé-valeur stockant entièrement les données en mémoire. Ce procédé permet d’excellentes performances tout en minimisant
de coûteux accès disque. Un de ses avantages est qu’il gère plusieurs types de valeurs
autres que des strings. Nous l’utilisons conjointement avec Circus afin d’être plus performant qu’avec un système de base de données classique.
— Circus : Système de gestion de processus et de sockets basé sur ZeroMQ, destiné à
contrôler plus finement l’exécution des processus surveillés et permet notamment de
mettre en commun des sockets entre ces processus. Circus comprend également une
API Python, proposant par exemple un wrapper et un manager de processus. Nous
utilisons Circus notamment pour gérer notre application ainsi que la base de données
Redis.
— ZeroMQ : Système de gestion de messages permettant la communication entre les différents organes de l’application. ZeroMQ est une bibliothèque réalisée en C mais offrant
des bindings pour ne nombreux langages tels que Python.

Vue logique de l’application

11/35

Onitu

Chapitre 6

Vue processus
Au lancement d’Onitu, la première étape est le démarrage de Circus. Circus va nous permettre de lancer et de monitorer des processus de façon simple et optimisée. Circus se charge
donc de démarrer, dans deux processus distincts, Redis tout d’abord qui nous permettra de
stocker toute les métadonnées des fichiers. Puis le Core d’Onitu, qui se charge d’analyser le
fichier «entries.json» contenant la liste des drivers (ainsi que leurs paramètres de configuration) à démarrer. Pour chaque entrée valide, le Core demande à Circus de lancer le driver
correspondant. Une fois ceci fait, le Core bouclera en attente d’actions à effectuer.

Vue processus

12/35

Onitu

Figure 6.1 – Lancement par Circus

Vue processus

13/35

Onitu

Figure 6.2 – Fonctionement d’un driver

Vue processus

14/35

Onitu
Le driver constitue donc un processus à part, lancé et monitoré par Circus. À son lancement, il s’initialise avec les paramètres transmis, puis démarre son Plug. Le Plug est l’organe
communiquant du driver, il va donc se connecter à Redis pour consulter et transmettre des
informations. Il écoutera aussi les requêtes que Redis lui transmet et les traitera s’il s’agit de
celles qu’il gère, en renvoyant une réponse si necessaire.

Les drivers peuvent aussi être lancés directement par le core pendant que l’application tourne
grace à la flexibilité de Circus.

Figure 6.3 – Vue processus

Vue processus

15/35

Onitu

Figure 6.4 – Vue processus

Vue processus

16/35

Onitu

Figure 6.5 – Vue processus

Vue processus

17/35

Onitu

Chapitre 7

Vue déploiement
Onitu est principalement destiné à être utilisé par des particuliers, dans un cadre privé. Le
parc de machines sur lequel il sera amené à être installé est donc particulièrement hétéroclite :
machines diverses, de gammes différentes (de l’entrée de gamme au serveur professionnel),
possédant chacune un environnement et une configuration leur étant propre. Pour éviter que
cela ne constitue un frein au déploiement de notre solution, l’installation de l’outil devra donc
être des plus aisées.

Le déploiement de la solution, une fois les sources récupérées depuis un dépôt Git par exemple,
se fera à l’aide d’une procédure d’installation détaillée, voire d’un script. Celle-ci commencera
bien sûr par la mise en place de l’interpréteur CPython, sur lequel s’appuient le code et les
bibliothèques du projet.
Par la suite, à l’aide du gestionnaire de modules python PIP, les dépendances à Onitu seront installées sur la machine hôte, telles que Circus, ZeroMQ ou encore Redis. La solution est
alors prête à l’emploi. Seule persiste pour l’administrateur la configuration de celle-ci, passant
notamment par la mise en place de l’arborescence de fichiers.

Les contraintes géographiques du système seront dépendantes des hôtes sur lequel il sera
installé : ceux-ci régiront en effet les performances et la bande passante. En fonction de l’activité des utilisateurs du système (fréquence des requêtes) et de la taille des fichiers stockés,
la consommation en bande passante pourra s’avérer importante. Il sera donc de la responsabilité de l’administrateur de veiller à ce que cette utilisation ne soit pas excessive suivant les
caractéristiques de son installation.
À terme, l’architecture permettra aux différents composants du serveur de fonctionner de
façon décorrélée sur différentes machines, néanmoins reliées entre-elles. Ce traffic supplémentaire sera semblable à celui nécessaire pour la communication avec les organes distants,
tels que DropBox, et ne constituera donc pas une charge supplémentaire.

Vue déploiement

18/35

Vue déploiement
Figure 7.1 – Vue déploiement

Onitu

19/35

Onitu

Chapitre 8

Implémentation
8.1

Vue globale

Par nature, Onitu doit gérer beaucoup d’operations en parallèle, pour cela il existe traditionnellement plusieurs solutions classiques. Les trois options principales sont d’utiliser un
système événementiel, d’utiliser plusieurs threads ou plusieurs processus.
Le système événementiel nous paraît le plus compliqué à mettre en œuvre car il laisse
moins de libertés aux différentes parties qui devront obligatoirement respecter une API commune et relativement stricte. Elle est aussi moins tolérante envers les composants deffectueux
qui bloqueraient sans raison, et cela pourait entraîner rapidement une perte de performances
ou un arrêt complet du système.
Dans Onitu, nous voudrions que l’utilisateur ait la possibilité d’ajouter des drivers faits
par un tiers, ainsi, un système centralisé où tout fonctionnerait parfaitement nous semble
utopique.
Il nous reste donc le choix entre l’utilisation de threads ou de différents processus. Nous
avons pour l’instant choisi d’utiliser des threads car l’avantage principal d’avoir plusieurs
processus est de pouvoir étendre facilement le système sur plusieurs machines. Cela ne nous
interesse que moyenement à ce niveau car nous pourrons déjà le faire en ayant simplement
plusieurs instances d’Onitu. L’autre avantage à utiliser plusieurs processus est de contourner
le Global-Interpreter-Lock (GIL ) de Python qui n’autorise en fait qu’une seule opération en parallèle, même dans le cadre du multi-thread. Cependant nous estimons que notre application
sera IO-bounded, c’est à dire qu’elle sera principalement limitée par les opérations d’entrée/sortie sur le disque et sur le réseau. Ces deux types d’opérations sont implementés de facon à
ne pas causer de blocage sur le GIL.

8.1.1

Messaging

La programation parallèle, multi-thread dans notre cas, apporte souvent son lot de problemes. La plus part du temps, il s’agit d’erreurs de gestion de ressources, partagées entre
différentes unités d’execution. Ces ressources partagées se retrouvent utilisées par plusieurs
unités en même temps, ce qui cause des conflicts et entraîne dans la majorité des cas une
corruption des données. Il est très compliqué de parvenir à une architecture qui éliminerait
Implémentation

20/35

Onitu
ce type de problèmes. C’est pourquoi nous avons décidé de limiter au maximum les données
partagées entre threads. Cela devrait aussi faciliter un eventuel futur changement vers une
architecture multi-process.
Pour limiter les données communes, nous utilisons une architecture de type messaging.
Il n’y as pas de ressource commune entre les différentes unités d’execution. Néanmoins, les
parties du programe pourront communiquer entre-elles au travers de messages en utilisant
la bibliothèque ZeroMQ. Un thread sera prévenu des événements propres à son backend par
une implémentation de son choix qui depend grandement de la nature de ce backend (hooks
sur le filesystem, threads jumeaux qui surveillent une API, etc.). À l’arrivée d’évènements,
il préviendra les autres entités du programe qui souhaitent être en être informés, en leur
envoyant des messages. De la même facon, il va recevra des messages qui seront pour lui des
ordres, principalement en provenance du referee.
Cette architecture particulière fait que les relations entre les élements d’Onitu sont très
simples et se résument souvent à un moyen de démarrer les différentes parties, et à une
interface de comunication utilisant ZeroMQ.

8.1.2

Canaux de comunication

Les différents design patterns que nous utilisons au niveau du messaging sont des surcouches des sockets fournies par la bibliothèque ZeroMQ. Nous utilisons principalement deux
design patterns :
— PUBlisher/SUBscriber : Il s’agit d’un modèle de publication d’informations, l’émeteur
publie un message en utilisant une socket de type PUB et tout les abonés (subscribers)
le reçoivent. Les messages sont de type broadcast et unidirectionels. Il existe cependant
la possibilité d’utiliser un filtre sur les messages à recevoir du coté abonné, ce qui rend
possible le multicast.
— REQuest/REsPonse : Ce modèle est relativement standard, il s’agit de celui utilisé par
beaucoup de serveurs : un client envoie une requête puis attend une réponse du serveur.
Il est obligatoire que la réponse à la requête soit reçue avant de pouvoir en faire une
nouvelle.

Implémentation

21/35

Onitu
Voici, avec un exemple, comment communiquent les différentes entités du système :

Figure 8.1 – Vue globale
1. Un driver (A) prévient d’un changement sur son backend, par exemple un nouveau
fichier. Le referee est abonné à tous les drivers et reçoit donc la notification.
2. Le referee décide que le driver (B) doit dupliquer ce fichier, il lui envoie une requête le
lui demandant et recoit de suite une réponse affirmative signifiant que (B) va essayer la
duplication.
3. Le driver (B) fait un ensemble de requêtes sur (A) pour récupérer les différents blocs
du fichier que (A) lui transmet.
4. Le driver (B) prévient le referee du succès ou de l’échec de l’opération en publiant un
message indiquant le status.

Implémentation

22/35

Onitu
8.1.3

Séquences type

Lorsqu’un driver remarque un changement dans son backend, il publie une notification. Le
referee met alors à jour sa vision du système et décide des actions à entreprendre.

Figure 8.2 – Diagramme de séquence
Un driver n’est pas nécessairement connecté lorsque le referee voudrait lui demander
quelque chose. Ces ordres sont alors gardés dans une liste et seront exécutés lorsque le driver
en question se connectera.
Voici un exemple complet, il s’agit du cas où un driver détecte un nouveau fichier :
Comme nous l’avons vu, les différentes séquences sont très similaires, en fait les seuls
changements se font au niveau de l’action qui est effectuée par le driver. Voici les séquences
pour les trois actions principales. Il s’agit de la duplication, la modification et la suppresion
d’un fichier :

Implémentation

23/35

Onitu

Figure 8.3 – Diagramme de séquence

Implémentation

24/35

Onitu

Figure 8.4 – Diagramme de séquence

Implémentation

25/35

Onitu

Figure 8.5 – Diagramme de séquence

Implémentation

26/35

Onitu

Figure 8.6 – Diagramme de séquence

Implémentation

27/35

Onitu

Figure 8.7 – Diagramme de séquence

Implémentation

28/35

8.2

Couches applicatives

Onitu

Onitu étant un serveur relativement générique gérant des drivers pour différents backends, son architecture centrale est relativement simple. D’autant plus qu’elle s’appuie sur
du messaging, ce qui diminue grandement le besoin de beaucoup de methodes et attributs.

Figure 8.8 – Couches applicatives

Implémentation

29/35

Onitu
Le Plug sera lancé automatiquement dans un thread lorsqu’on le démarre. Généralement
l’implémentation d’un driver voudra surveiller son backend dans un autre thread. Voici un
exemple simple avec une implémentation possible pour un driver gérant un système de fichier
local :

Figure 8.9 – Couches applicatives
Le watcher utilise une librairie qui lui permet d’être réveillé lorsque des modifications ont
lieu sur le système de fichier. Dès lors, il utilise le Plug et ses méthodes publish_x pour publier
les changements. À la réception des ordres par le Plug, il appelle les callbacks enregistrés par
le driver, il s’agirait ici des méthodes reply_x.

Implémentation

30/35

Onitu

Chapitre 9

Vue données
Les principales données gérées par Onitu sont des fichiers. Afin de manipuler ces fichiers
avec une grande précision et de manière performante, des métadonnées sont stockées.
Ces métadonnées sont stockées dans une base de données clé-valeur en mémoire, Redis.
Les données sont préservées entre chaque lancement du serveur grâce à un dump régulier de
la base.

Chaque nom de fichier correspond à une clé dans Redis, à laquelle est associée un tableau
associatif (hash) contenant les métadonnées du fichier, sous la forme suivante :
{
checksum: ’6d96270004515a0486bb7f76196a72b40c55a47f’,
size: 1798585,
type: ’file’,
content-type: ’image/png’,
created-at: ’Thu Jun 20 2013 20:31:34 GMT+0200’,
updated-at: ’Mon Jun 24 2013 18:27:04 GMT+0200’,
}
Redis sert aussi à partager diverses informations, comme les options de configuration des
drivers, ou les ports correspondants aux sockets ZeroMQ.

Vue données

31/35

Onitu

Chapitre 10

Taille et performance
Dans un premier temps, Onitu ne vise pas à être déployé sur de très grosses structures,
mais plutôt sur des réseaux domestiques ou au sein de petites et moyennes entreprises. Plus
tard, si la capacité à monter en charge est satisfaisante et que la demande est présente, de
plus gros réseaux seront envisagés.

Onitu doit pouvoir être utilisé au sein d’un réseau amateur, et donc avec peu de moyens.
Un matériel tel que le Raspberry Pi doit par exemple être suffisant pour faire fonctionner le
serveur, avec une dizaine de drivers, quelques milliers de fichiers et plusieurs centaines de
requêtes par heure. Même si nous ne cherchons pour le moment pas à nous adapter à de très
grosses structures, nous devons à tous prix éviter d’augmenter de manière exponentielle selon
un facteur.

Pour le moment, les deux goulots d’étranglement sont la synchronisation d’un fichier, et le traitement des règles par le Referee. Pour le premier, plusieurs algorithmes devront être essayés,
mais la qualité du réseau reste l’élément discriminant, sur lequel nous n’avons aucun contrôle.
Pour le traitement des règles par le Referee, d’autres instances de ce dernier pourront être
lancées en cas de ralentissement, permettant une concurrence et un parallélisme.

L’optimisation de l’utilisation du réseau est au cœur de l’architecture d’Onitu, et des adaptations en profondeur devront être effectuées si nous ne répondons pas à des critères satisfaisants. De part la nature très hétéroclite des différentes solutions avec lesquelles nous communiquons (fichiers locaux, Dropbox, serveur SSH. . .), il est très dur de s’adapter à toutes les vitesses. En effet, un échange entre deux fichiers locaux de plusieurs giga-octets pourra prendre
quelques millisecondes sur un SSD, alors que le téléchargement d’un fichier de quelques octets pourra prendre plusieurs heures sur Amazon Glacier. Parfois, le temps de réponse est le
facteur discriminant, parfois c’est la taille de la requête. Nous travaillons encore à améliorer
l’algorithme d’échange de fichiers afin de mieux nous adapter. Nous pensons notament utiliser

Taille et performance

32/35

Onitu
un système de crédits, ainsi que des tailles de découpage variables, qui seront contrôlés par
les drivers eux-même.

Onitu utilise la base de données Redis afin de stocker les métadonnées. Cette base de données monte extrêmement bien en charge et peut supporter facilement des milliers de requêtes
par seconde sur de petits systèmes. Mais pour cela, elle conserve toutes les données dans la
mémoire vive. Une attention particulière doit donc être apportée quant à la constitution de
ces métadonnées, afin de ne pas utiliser trop de mémoire. Pour le moment, nous essayons de
nous en tenir à moins de 100 méga-octets utilisés pour stocker un million de fichiers, soit 100
octets par fichier. Bien entendu, cela reste une moyenne et dépend notamment de la longueur
du nom du fichier.

Taille et performance

33/35

Onitu

Chapitre 11

Qualité
Les contraintes purement fonctionnelles, évoquées tout au long de ce document ne représentent pas l’ensemble des exigences auxquelles notre architecture devra répondre.

Premièrement, Onitu, afin d’être au plus proche des besoins de ses utilisateurs, devra permettre d’agréger un grand nombre de services externes de stockage. Ne pouvant prétendre à
l’intégration de toutes les présentes solutions existantes, et encore moins des futures, l’architecture permettra d’étendre facilement ses fonctionnalités en y greffant des modules complémentaires.

La fiabilité du système est sans aucun doute le point le plus important de la solution. S’occupant de la synchronisation, et donc de la sauvegarde des fichiers utilisateurs, il n’est en effet
pas tolérable que de telles données se perdent ou soient corrompues. Ce point est comblé
par une conception modulaire et un isolement des drivers : si l’un d’entre-eux rencontre un
problème, le reste de l’application ne sera pas affecté. Des outils de contrôle de sommes des
données seront aussi implémentés afin de s’assurer à tout moment de la fiabilité de celles-ci.

La sécurité des échanges, bien que cruciale, ne relève pas de notre architecture, car étant relative au protocole de chacun des services externes. Nous ne pourrons à ce sujet n’agir qu’en
tant que conseillers, en aidant l’utilisateur au niveau d’une configuration qui correspond à
ses besoins de confidentialité, d’intégrité, et autres attributs, en lui présentant de manière
concise les différents choix qui s’offrent à lui, et l’orientant vers ceux qui répondent le mieux
à ses attentes, tels que des services à protocoles chiffrés pour l’échange des données (SFTP
plutôt que FTP par exemple).

La confidentialité des données devra aussi être assurée, par des méthodes d’authentification.
Nous nous appuyerons à cet effet sur des protocoles reconnus, tels OAuth.

Qualité

34/35

Onitu
Enfin, l’application étant développée en python, elle sera facilement déployable et interopérable. Présent sur les principaux systèmes d’exploitation du marché, toute personne devrait
être en mesure de faire tourner notre solution. Nous veillons aussi, dans nos choix techniques
sur les bibliothèques utilisées, à ce que celles-ci soient de même portables et faciles à mettre
en place.

Qualité

35/35


Aperçu du document 2015_AA2_FR_onitu.pdf - page 1/39
 
2015_AA2_FR_onitu.pdf - page 3/39
2015_AA2_FR_onitu.pdf - page 4/39
2015_AA2_FR_onitu.pdf - page 5/39
2015_AA2_FR_onitu.pdf - page 6/39
 




Télécharger le fichier (PDF)


2015_AA2_FR_onitu.pdf (PDF, 2.6 Mo)

Télécharger
Formats alternatifs: ZIP Texte




Documents similaires


2015 aa2 fr onitu
tai006 ress01 v1 1
cours systemes distribues s1 du m1
zhpdiag
p8hn7l3
zhpdiag

Sur le même sujet..




🚀  Page générée en 0.009s