SEnthavong Chanthala

UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL
SENTHAVONG CHANTHALA
SYSTÈMES DE COURRIERS ÉLECTRONIQUES À
GRANDE ÉCHELLE SUR LE CLOUD
HỆ THỐNG THƯ TÍN ĐIỆN TỬ KÍCH THƯỚC LỚN
TRÊN ĐÁM MÂY ĐIỆN TOÁN
MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE
HANOI – 2015
Sommaire
Remerciements
iii
Résumé
iv
Abstract
v
Table des figures
vi
Liste des tableaux
viii
Introduction Générale
1
1 État de l’Art
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Système courriels . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Architecture générale d’un Système de Courriers électroniques . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Protocoles et Fonctionnement des Systèmes Emails . .
1.2.3 Structure d’un courriel . . . . . . . . . . . . . . . . .
1.3 Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Architectures de Zimbra . . . . . . . . . . . . . . . . .
1.3.2 Composants de la suite collaborative Zimbra . . . . .
1.3.3 Comparatif Zimbra et autres solutions . . . . . . . . .
1.3.4 Déploiement du système à grande échelle . . . . . . .
1.4 Cloud Infrastructure . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Virtualisation . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Le Cloud Computing . . . . . . . . . . . . . . . . . .
1.4.3 Solutions Existantes du Cloud . . . . . . . . . . . . .
1.4.4 Openstack . . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
i
3
4
5
6
7
10
13
16
17
17
19
21
24
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Solution Implémentée
2.1 Concept . . . . . . . . . . . . . . . . .
2.1.1 Concept pour Openstack . . . .
2.1.2 Concept pour Zimbra . . . . . .
2.2 Implémentation . . . . . . . . . . . . .
2.2.1 Installation d’OpenStack . . . .
2.2.2 Création des machines virtuelles
2.2.3 Installation de Zimbra . . . . . .
3 Expérimentations
3.1 Administration
3.2 Administration
3.3 Test d’envoi de
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
33
34
36
37
43
45
sur le Système
49
d’OpenStack . . . . . . . . . . . . . . . . . . 49
de Zimbra . . . . . . . . . . . . . . . . . . . . 51
Mail . . . . . . . . . . . . . . . . . . . . . . . 53
4 Conclusion
55
Bibliographie
56
Annexes
60
4.1 Annexe A - Première connexion à une instance OpenStack
après son démarrage . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Annexe B - Création d’une Instance de Machine virtuelle . . 62
ii
Remerciements
Je tiens à remercier tout d’abord les professeurs de l’Institut Francophone
International (IFI) et précisément Monsieur Nguyen Hong Quang, Professeur
d’informatique, qui m’a conseillé ce stage et m’a assisté lors des difficultés
que j’ai rencontrées.
Je tiens également à remercier l’entreprise Netnam, là où je suis restée
près de 6 mois pour réaliser ce stage, et plus précisément mon responsable à
Netnam Mr Le Anh Tuan monsieur le directeur, Nguyen Thanh Thai, Tân
Nguyen Van, Hieu Vo Trung tous les membres de l’équipe Network.
Finalement, merci à tous mes amis étudiants de l’IFI avec qui j’ai passé
des bons moments et des moments difficiles, et aussi ma famille qui m’a
toujours apporté leur soutien.
iii
Résumé
Parmi les nombreux moyens de communications apparus avec Internet,
figure le courrier électronique ou e-mail. Il s’agit d’un moyen de communication fonctionnant de façon similaire aux traditionnelles lettres en papier : une
personne possède une adresse, et peut envoyer un texte virtuel par Internet
ou un réseau à une autre personne via son adresse. Cependant, le fait que
de plus en plus de personnes utilisent Internet et les ordinateurs a amené les
fournisseurs de ce moyen de communication à se poser des questions sur les
ressources que cela pourrait nécessiter.
La virtualisation a amené une autre dimension intéressante sur ces systèmes, tout en utilisant les possibilités d’Internet grâce au Cloud, en permettant aux administrateurs de pouvoir gérer à distance, leurs serveurs. Dans le
cadre de notre stage, nous nous sommes intéressés à la mise en place d’un
système de courriers électroniques sur le Cloud possédant une grande échelle
en terme du nombre d’utilisateurs.
Nous avons proposé une solution utilisant la suite collaborative opensource Zimbra pour s’occuper de la partie Système de Courriels et le logiciel
open-source OpenStack pour la partie virtualisation et Cloud computing.
Après avoir mis en place les différents serveurs, et installer notre système,
nous avons effectués une expérimentation d’envois et de réceptions de mails
afin de voir le bon fonctionnement de notre système prototype.
Mots-clés : Système grande échelle pour courrier électronique, Cloud computing, zimbra.
iv
Abstract
Among the communication technologies appeared with Internet, figure
the e-mail. It is a communication technology working like the old letter in
paper : someone has an address, and can send a virtual text thanks to Internet or an other network to someone else by its address. However, the fact of
having more and more Internet users and computers users asks to the providers of these communication technologies questions about the resources that
it could need.
Virtualization provides an other interesting dimension on these systems,
still using Internet possibilities thanks to the Cloud, allowing the admins
to manage servers remotely. In the context of our internship, we have been
interested in the design of a mailing system on the Cloud, having a large
scale of users.
We proposed a solution using the open-source groupware Zimbra to manage the mailing system part, and the open-source software OpenStack for
the virtualization and Cloud computing part. After setting the different servers, and install our system, we made experiments of sending and receiving
mails to see the good execution of our prototype.
Keywords : System large-scale for electronic mail, Cloud computing, Zimbra.
v
Table des figures
1.1 Montre l’architecture ordinaire d’un système de courriers électroniques (abréviation courriels)[3] . . . . . . . . . . . . . . .
1.2 Protocoles principaux utilisés par les systèmes de courriels
modernes[3] . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Structure d’un Email[3] . . . . . . . . . . . . . . . . . . . . .
1.4 Architecture Serveur[7] . . . . . . . . . . . . . . . . . . . . .
1.5 Architecture Cliente[7] . . . . . . . . . . . . . . . . . . . . .
1.6 Composants possibles dans Zimbra[7] . . . . . . . . . . . . .
1.7 Schéma d’un Hyperviseur[11] . . . . . . . . . . . . . . . . . .
1.8 Fonctionnement des deux types d’Hyperviseur[10] . . . . . . .
1.9 Contenu du Cloud[12] . . . . . . . . . . . . . . . . . . . . . .
1.10 Architecture Générale d’OpenStack[23] . . . . . . . . . . . .
1.11 Architecture Détaillée d’OpenStack[24] . . . . . . . . . . . . .
1.12 Minimal Architecture Example- Network Layout OpenStack
Networking(Neutron)[24] . . . . . . . . . . . . . . . . . . . .
1.13 Minimal Architecture Example - Service Layout OpenStace
Networking(Neutron)[24] . . . . . . . . . . . . . . . . . . . .
4
5
6
8
9
11
18
18
19
25
26
27
28
2.1
2.2
2.3
2.4
2.5
Architecture Globale du Système choisi . . .
Architecture du système Zimbra implémenté
Diagramme de cas d’utilisation . . . . . . . .
Résultat d’installation . . . . . . . . . . . . .
Architecture des Machines Virtuelles . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
34
37
42
44
3.1
3.2
3.3
3.4
3.5
Interface d’Authentification sous OpenStack
Vue Générale d’OpenStack . . . . . . . . .
Vue de la Topologie d’Openstack . . . . . .
Interface d’authentification sous Zimbra . .
Interface en Administrateur sous Zimbra . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
50
51
52
52
vi
.
.
.
.
.
3.6 Interface en Utilisateur sous Zimbra . . . . . . . . . . . . . .
53
4.1 Annexes- Configuration de notre Interface . . . . . . . . . . .
4.2 Annexes- Génération d’une paire de clé administrateur côté
admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Annexes- Génération d’une paire de clé administrateur côté
OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Annexes- Création d’une image de Système d’Exploitation . .
4.5 Annexes- Création d’une instance de machine virtuelle . . . .
4.6 Annexes- Protocoles Extérieurs . . . . . . . . . . . . . . . .
4.7 Annexes- Création d’une IP publique . . . . . . . . . . . . .
60
vii
61
61
62
63
63
64
Liste des tableaux
1.1
1.2
1.3
1.4
Tableau Comparatif des Suites Collaboratives . . . .
Tableau des serveurs requis pour Zimbra . . . . . . .
Tableau des Capacités par Service de Zimbra . . . .
Comparaison entre les logiciels du Cloud Computing
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.1
2.2
2.3
2.4
2.5
2.6
Ressources Nécessaires pour Zimbra avec 1.000.000 d’utilisateurs
Serveurs Nécessaires pour Zimbra avec 1.000.000 d’utilisateurs
Ressources Nécessaires pour Zimbra avec 10.000 d’utilisateurs
Ressources Nécessaires pour ce système . . . . . . . . . . . .
Logiciels Nécessaires dans chaque Noeud . . . . . . . . . . . .
Modules Zimbra présents dans chaque Serveur . . . . . . . .
3.1 Tableau Comparatif deux différents systèmes . . . . . . . . .
viii
15
16
17
23
30
31
31
32
34
35
54
Introduction Générale
Contexte et Cadre d’étude
Ce rapport a été réalisé durant les travaux de notre stage de fin de formation de Master Réseaux et Systèmes Communicants de l’Institut Francophone International, en double diplômation avec l’Université Claude Bernard
de Lyon. Le stage a été effectué au sein du service " Réseaux Recherche et
Développement " de l’entreprise Netnam 1 . Netnam est un fournisseur d’accès à Internet mais aussi à des services en ligne et des services déjà géré par
l’entreprise. Elle fut la première entreprise à introduire le service de courriel
au Vietnam en 1994, et est composée de 170 employés répartis entre Hanoi
et Ho Chi Minh Ville.
Le sujet que nous étudierons au sein de ce rapport concerne les systèmes
de courriers électroniques et la virtualisation. En effet, Internet étant de
plus en plus utilisés, les services qu’ils proposent ont étés multipliés, et nous
avons vus différents types de systèmes de courriels apparaître. Très souvent,
les utilisateurs privilégient les systèmes déjà gérés par une entreprise comme
Gmail pour Google, Yahoo, ou bien des solutions logicielles comme Outlook
de Microsoft.
Cependant, certains utilisateurs comme les gouvernements, l’armée ou
certaines grandes entreprises ont une préférence pour un système qu’ils administrent eux mêmes, et ceux pour des raisons comme la liberté, la confidentialité ou encore la sécurité. Mais ces systèmes sont très complexes et
coûteux autant en terme de mise en place, que de maintenance, surtout à
grande échelle.
1. Netnam company : http ://www.netnam.vn/
1
Problématique
L’apport de la virtualisation dans ce domaine permet une souplesse en
terme d’échelle utilisateur et de simplicité du système, si bien que plusieurs
systèmes de courriels sont déjà présents dans le Cloud[1], cependant, leurs
performances et leur mise en place sont toujours à étudier. Les problématiques qui ont été soulevées concernent la disponibilité des services, leurs
performances mais aussi l’optimisation du stockage des données de ces systèmes à grande échelle.
Objectifs du stage
Les objectifs de notre stage sont diverses, mais nous pouvons les regrouper
en deux grandes parties. Dans un premier temps, nous effectuerons une partie
orientée recherche conséquente sur les différents technologies Open-source
existantes afin d’essayer de devenir expert dans le domaine des systèmes
courriels, de la virtualisation, de stockage et des logiciels existants dans le
but de dresser un comparatif. Puis nous commencerons la deuxième partie de
ce stage, qui consiste en l’implémentation du système, plus précisément dans
son installation, sa configuration qui sont des étapes cruciales, mais aussi les
différents tests effectués pour vérifier le bon fonctionnement de notre système
à grande échelle, soit plus d’un million d’utilisateurs.
Organisation du mémoire
Ce rapport sera divisé en deux parties : une première qui introduira le
sujet et dressera un état de l’art en terme de conception de systèmes de
courriels, avec une présentation de leur architecture, suivie par une sous partie
portée sur le logiciel Zimbra et terminée par un descriptif du Cloud, plus
précisément de OpenStack, logiciel qui nous aura permis la virtualisation.
Nous continuerons avec une deuxième partie plus centrée sur le système que
nous aurons réalisé, avec les différents concepts qui ont été retenus et nous
nous concentrons sur l’implémentation de ce système, autant au niveau du
système de courriels que la partie virtualisation, enfin, nous terminerons cette
deuxième partie par l’énonciation des différents résultats obtenus.
2
1 État de l’Art
1.1
Introduction
Au sein de cette partie, nous étudierons ensemble les différents logiciels
et systèmes de courriers électroniques utilisés durant nos travaux. Nous présenterons dans un premier temps le fonctionnement des systèmes d’envois
de courriers électroniques de façon détaillée. Nous continuerons ensuite en
faisant un descriptif de l’architecture du système utilisé durant nos travaux,
Zimbra, tout en dressant un comparatif entre celui-ci et les différents systèmes d’envois de courriers électroniques. Puis, nous aborderons plus facilement le domaine de la virtualisation, en nous intéressant de plus près au
Cloud Computing. Cela nous amènera à réaliser de nouveau un comparatif
entre le logiciel choisi, c’est à dire OpenStack, et les différents autres logiciels
existants, non sans avoir présenter OpenStack au préalable.
1.2
1.2.1
Système courriels
Architecture générale d’un Système de Courriers
électroniques
Les systèmes de courriels électroniques [2] ou encore système E-mail, sont
des systèmes composés d’un ensemble d’éléments permettant de transmettre
un courrier électronique[3]. Ils sont aussi considérés comme un service de
transmission de messages écrits et de documents envoyés électroniquement,
que ce soit sur le réseau de l’émetteur de message et du récepteur comme sur
Internet. Nous pouvons envoyer des e-mails à plusieurs personnes grâce à Internet n’importe où et n’importe quand (à conditions d’avoir une connexion).
3
Figure 1.1 – Montre l’architecture ordinaire d’un système de courriers
électroniques (abréviation courriels)[3]
MUA (Mail User Agent ou Agent Utilisateur d’E-mail) : qui permet à
l’utilisateur de recevoir et envoyer des courriels
MTA (Mail Transfer Agent ou Agent de Transfert d’E-mail) : qui permet
la communication entre le client et le serveur, deux MTA sont nécessaires
(coté client et coté serveur)
MAA (Mail Access Agent ou Agent d’Accès aux E-mail) : qui gère l’authentification et l’accès aux courriels des utilisateurs
SMTP (Simple Mail Transfer Protocol ou Protocole Simple de Transfert
d’E-mail) qui assure la communication entre deux MTA
1.2.2
Protocoles et Fonctionnement des Systèmes Emails
Le fonctionnement du courrier électronique est basé sur l’utilisation d’une
boîte à lettres électronique.(Voir dans la figure 1.2 )
4
Figure 1.2 – Protocoles principaux utilisés par les systèmes de courriels
modernes[3]
Dans la figure 1.2, nous avons constaté lorsque nous réalisons l’envoi d’un
email, le message est acheminé de serveur en serveur, jusqu’au serveur de
messagerie du destinataire. Plus exactement, le message est envoyé au serveur
de courrier électronique chargé du transport (nommé MTA), jusqu’au MTA
du destinataire. Le protocol SMTP, Simple Mail Transfer Protocol, est un
protocole de communication utilisé pour transférer le courrier électronique
vers les serveurs de messagerie, grâce à ce protocole sur internet, les MTA
communiquent entre-eux et sont logiquement appelés serveurs SMTP (parfois
serveur de courrier sortant). Le serveur MTA du destinataire délivre alors le
courrier au serveur de courrier électronique entrant (nommé Mail Delivery
Agent ou MDA), qui conserve alors le courrier en attendant que l’utilisateur
vienne le récupérer.
Il existe deux principaux protocoles permettant de récupérer du courrier
sur un MDA : le protocole POP3, Post Office Protocol, le plus ancien, permettant de relever son courrier et éventuellement d’en laisser une copie sur le
serveur, et le protocole IMAP4, Internet Message Access Protocol, qui permet une synchronisation de l’état des courriers (lu, supprimé, déplacé) entre
plusieurs clients de messagerie, et réalisant une copie de tous les messages
qui est conservée sur le serveur afin de pouvoir assurer la synchronisation.
1.2.3
Structure d’un courriel
Les courriers électroniques sont divisés en deux sous parties : l’en-tête(Header)
et le corps (Body).(Voir dans la figure1.3)
5
Figure 1.3 – Structure d’un Email[3]
Les deux parties principales [5] sont l’en-tête(header) et le corps(body)
de l’E-mail, quand le MUA veut envoyer des emails, la partie l’en-tête, elle
va générer automatiquement, conserver les informations sur la date, le destinataire, l’expéditeur et enfin le sujet du mail. Le corps du courriel contient
le contenu du message. L’en-tête et ce corps sont séparés par une ligne vide,
alors que les paramètres du header sont séparés par des retours à la ligne.
Chaque ligne aura une longueur maximum de 1,000 bytes, et la taille d’un
courriel ne doit pas dépasser 64 Kilobyte[6].
Le courriel passera au moins deux fois le MTA, la première lors de l’envoi
du mail au serveur, et la deuxième, après avoir trouvé le destinataire, lors de
l’envoi du serveur vers la boîte électronique du destinataire. Nous venons de
voir le fonctionnement d’un système de courriers électroniques, nous allons
désormais nous intéresser au logiciel qui a été utilisé lors de ce stage : la suite
collaborative Zimbra.
1.3
Zimbra
Nous allons présenter dans cette sous-partie la suite collaborative Zimbra[7].
Mais avant d’entrer dans les détails de son architecture, nous allons effectuer
une courte présentation de cette suite, non sans préciser ce qu’est une suite
6
collaborative. Une suite collaborative est un logiciel d’applications destiné à
aider les utilisateurs participant à une même tâche de travail à atteindre leurs
objectifs en leur fournissant des produits comme les courriers électroniques,
les calendriers, les agendas, les chats et tout ce qui pourrait être utilisé par
un groupe de travail.
Quant à Zimbra, il s’agit d’une suite collaborative comprenant un serveur
de messagerie mais aussi un client web. Cette suite possède deux versions :
la première est gratuite, et a des composants Open-Source uniquement, la
deuxième, appelée " Network Edition " est payante, qui intègre des composants propriétaires (Closed-Source) pour les services d’échanges web par
exemple. Il est possible de faire son propre package en prenant des composants Open-Source principalement, et ne payer que pour certains composants
Closed-Source.
La suite prend en charge les courriers électroniques, les contacts, les calendriers de groupe et de tâches ainsi que le partage de document. Nous
venons de faire un bref descriptif de Zimbra, nous allons maintenant voir ensemble son architecture, en commençant par l’architecture coté serveur puis
l’architecture coté client.
1.3.1
Architectures de Zimbra
Serveur Zimbra : Les différents composants du logiciel Zimbra, sont montrés dans la Figure 1.4.
Premièrement, le MTA. Mail Transfer Agent ou Agent pour le Transfert
d’E-mail en français, il s’agit d’un serveur qui va prendre en charge l’envoi
et la réception des courriers interne et externe à Internet grâce à SMTP, et
peut fonctionner en mode Actif ou Passif. Il est utilisé dans Zimbra en tant
que point de relai pour l’archivage des courriels, et est placé sur un serveur
Anti-SPAM/ Anti-Viral (ASAV).
Le transfert avec la boîte de courriers électroniques est assuré grâce aux
protocoles SMTP et LMTP (Local Mail Transfer Protocol ou Protocol Local
de Transfert d’E-mail). SMTP est utilisé pour les courriers électroniques provenant du serveur et allant vers le Cloud, alors que LMTP est utilisé pour les
courriers allant du Cloud vers le Serveur. Cela permet de libérer la queue des
messages entrants si jamais un message ne peut être immédiatement distribué
à son destinataire (LMTP).
7
Figure 1.4 – Architecture Serveur[7]
Ensuite, il y a le serveur MailBoxD, qui est un serveur web applicatif
qui est basé sur la Servlet Jetty, le conteneur de logiciel Zimbra. Ce serveur
contrôle tout, de la partie Interface Web Cliente des utilisateurs, pour qu’ils
puissent voir leur boîte de réception, aux réponses à envoyer aux autres clients
mails qui effectuent des requêtes POP et IMAP, ainsi qu’à leur livraison.
Le serveur conserve aussi les messages et fournit des index pour ces messages grâce au système de gestion de base de données MariaDB (développé
par ceux qui ont fait MySQL suite au rachat de MySQL par Oracle). C’est
pareil ailleurs MariaDB qui gère les agendas, les tâches et les contacts des
utilisateurs. Dans l’image, nous pouvons voir la présence de deux MailBoxD :
une pour gérer le contenu dynamique avec des données enregistrées au niveau
de l’Interface Utilisateur, et une autre pour gérer le contenu statique.
Nous allons désormais nous intéresser au principal composant de l’architecture Zimbra, que tout implémentation Zimbra doit avoir : Zimbra Open
LDAP. Il s’agit d’un service qui s’occupe des informations nécessaires en
terme de configuration à l’éxécution de l’environnement Zimbra. En plus de
cela, les informations sur les utilisateurs sont stockées dans ce composant,
8
comme les mots de passe, les identifiants, leurs préférences, ou encore le serveur sur lequel se situe leurs boîtes de réception. LDAP s’occupe aussi de
la gestion en terme d’informations de domaines. Pour chaque domaine, une
information sur la configuration est incluse, sur la façon dont les utilisateurs
s’identifient par exemple.
Puis nous avons le proxy, qui sépare ce qui est exposé à Internet de ce
qui est protégé par un pare-feu. Le serveur Proxy et le serveur MTA sont
normalement placés dans la DMZ (Zone démilitarisée). Le serveur proxy
attend des requêtes des clients et les envoie aux différents serveurs de la
boîte de réception. Le proxy fournit principalement une couche de sécurité.
Les protocoles utilisés et ecoutés par le proxy sont les protocoles HTTPS
(HyperText Transfer Protocol Secure) , IMAPS (Interactive Message Access
Protocol Secure) et POP3s (Post Office Protocol Secure) qui permettent
d’assurer une certaine sécurité sur les transferts.
Cliente Zimbra : L’Architecture cliente Zimbra est décrite dans la Figure1.5.
Figure 1.5 – Architecture Cliente[7]
Nous allons expliquer l’architecture cliente, de la même façon que nous
l’avons fait dans la sous partie précédente. Le premier composant auquel
nous allons nous intéresser est le composant Zimbra-Collaboration. Il s’agit
du processus de MailBoxD, qui écoute les différents protocoles pour répondre
aux requêtes clientes (POP, IMAP, LMTP, CardDAV, etc).
9
Le navigateur du client effectue une requête SOAP (Simple Object Access Protocol) pour récupérer des informations qui seront alors envoyées au
navigateur. Il y a ensuite la partie Navigateur du Client, dans lequel deux
modes sont possibles : le premier, HTML où l’information est affichée avec
le langage HTML, et le second en AJAX, qui utilise un framework AJAX et
permet des fonctionnalités supplémentaires telles que le Glisser-Déposer.
Les clients bureaux permettent une collaboration entre Zimbra et les
clients mails tels que Thunderbird grâce au protocol IMAP, POP ou CalDAV ou Outlook. Cependant, pour Outlook, la version payante de Zimbra
est nécessaire car Outlook est un logiciel closed-source et utilise un protocole
MAPI qui provient de l’API Microsoft.
Les clients mobiles peuvent communiquer avec Zimbra, les Blackberrys peuvent grâce au Blackberry Enterprise Server, mais les autres mobiles
peuvent utiliser activesync, cependant, tous sont présents uniquement dans
la version payante de Zimbra.
Enfin nous pouvons remarquer la présence de Zimlet, qui sont une possibilité d’extension de l’interface web pour intégrer des services externes à
Zimbra. Il n’est pas recommandé d’un point de vue sécurité de présenter des
informations dans un client à travers des domaines, cependant il existe une
Zimlet nommée Zimlet Web Service Proxy pour prévenir ce manque de sécurité. Une autre Zimlet nommée Zimlet JSP Tags communique quant à elle
des informations sur le navigateur grâce à l’interface MailBoxD.
1.3.2
Composants de la suite collaborative Zimbra
Nous allons voir dans la figure 1.6, les différents composants individuels
qui peuvent constitués Zimbra, d’abord nous allons presenter dans "Key for
ZCS(Zimbra Collaboration Server)8.5". En orange (Z) les composants du
système Zimbra, les fonctionnalités que Zimbra a créé et a ajoutée à son
architecture. En blanc (3p)"3rd party FOSS" sont les logiciels Open-source,
celles fournient par des parties tierces. et en blanc (NE)"ZCS NE Only" celles
disponibles dans la version Payante Network Edition.
10
Figure 1.6 – Composants possibles dans Zimbra[7]
En utilisant les protocoles standards voici les composants : premièrement,
pour Zimbra MTA. Nous avons Postfix, un agent de transfert de message
(MTA) qui renvoient les emails reçus par SMTP ou LMTP comme ce client
implement les deux[4]. Il y a aussi Zimbra Archiving, qui est une fonctionnalité optionnelle. Il possède la fonctionnalité de recherches qui peut être
utilisée dans la boîte réception active mais aussi celle archivée. L’Anti-Virus
et Anti-Spam comprennent un scanner anti-virus (Clam AV), et un filtre mail
pour identifier les Spam (SpamAssassin ou DSpam au choix).
— Postfix est un serveur de messagerie électronique et un logiciel libre développé par Wietse Venema et plusieurs contributeurs.(Voir plus détaillé
dans le site "http ://www.postfix.org/").
— DSPAM : DSPAM est un filtre anti-spam open-source à échelle modulable désigner pour les systèmes d’entreprises possédant plusieurs utilisateurs. (Voir le site "http ://dspam.nuclearelephant.com")
— OpenDKIM : OpenDKIM est une implémentation du système authentification d’émetteur DKIM proposé par le E-mail Signing Technology
Group (ESTG) (Voir le site "http ://www.opendkim.org")
11
— Cyrus SASL : Cyrus est un système d’E-mail entreprise à grande échelle
conçu pour les environnements d’entreprises de différentes tailles et différentes technologies.(Voir "https ://cyrusimap.org/index.php")
Le composant Zimbra Proxy utilise un server IMAP/POP3 qui permet
à des mails d’un domaine d’être partagé à travers plusieurs serveurs Zimbra sur une base par utilisateur. Ce proxy inclut Nginx, un serveur proxy
IMAP/POP3 de très bonne qualité qui peut gérer les requêtes POP/IMAP
entrantes. Le composant Zimbra Proxy peut être utilisé comme un proxy
inverse pour les requêtes HTTP. Ce composant est optionnel. Le composant Zimbra Memcache est un package séparé du composant Zimbra Proxy
et qui est automatiquement sélectionné quand le package Zimbra Proxy est
installé. Un serveur doit fonctionné avec Zimbra Memcache quand le proxy
est en cours d’éxécution. Tous les proxys peuvent utiliser un même serveur
Memcache.
Le composant mailbox UI est utilisé uniquement si l’interface de mailboxd
est dans un noeud séparé, ce qui n’est pas requis comme nous en avons parlé
dans l’architecture serveur. Ce composant possède un processus Jetty qui
fournit des services pour les répertoires Zimbra et les informations Zimlet.
Le composant MailboxD est l’application serveur basée sur Jetty dans lequel le logiciel Zimbra est éxécuté, Jetty étant une servlet éxécutant Zimbra.
Il possède la base de données MariaDB, qui est un logiciel qui représente le
stockage de méta-données où sont conservées les identifiants de boîte de réception liées aux comptes utilisateurs. Elle contient aussi les étiquettes définies
par l’utilisateur, ses dossiers, son calendrier et ses contacts ainsi que tous les
statuts des messages (Lu, Non Lu). MailboxD contient aussi Lucene qui est
un moteur de recherche et d’indexation de texte open source, qui maintient
les fichiers d’indexation de chaque boîte mail. Il contient aussi le package
optionnel Zimbra Logger qui permet de traquer les messages, LibreOffice
pour avoir un affichage des documents de haute résolution et RRDTool pour
bénéficier de graphe pour les statistiques.
Le composant Zimbra Spell est un composant optionnel qui permet de
vérifier l’orthographe des courriers électroniques. Le composant Convertd est
un package installé sur le serveur de stockage Zimbra, et contient une fonctionnalité source qui convertit les fichiers liés dans un mail en HTML.
12
Le composant OpenLDAP software est une implémentation open-source
du protocole LDAP qui fournit une authentification utilisateur. Chaque utilisateur a un identifiant de boîte de réception unique qui sert de point de référence au compte utilisateur. (Voir plus détaillé dans le site "http ://www.openldap.org/"
Le composant DNS Cache a pour but d’améliorer les performances des
serveurs MTA en créant un cache local pour le DNS ce qui évite à Zimbra
de s’adresser à un serveur DNS externe.
Le composant "Connecteurs" s’occupent de la réaliser la compatibilité
Outlook(NE) et Zimbra, et propose une solution pour réaliser la migration
des données sous un serveur Microsoft Exchange, mais pour ce service il faut
payer. Le dernier composant permet le "Monitoring" c’est à dire un logiciel
de surveillance grâce à l’implémentation logicle libre Swatch(en savoir plus
http ://sourceforge.net/projects/swatch/).
1.3.3
Comparatif Zimbra et autres solutions
En comparaison avec d’autres logiciels avec des fonctionnalités vers les
utilisateurs mobiles, sur le web, Zimbra fournit une interface webmail, professionnelle et de la flexibilité. Le tableau 1.1 [8] compare les caractéristiques
du système Zimbra avec les systèmes e-mail de collaboration comme Kolab,
Zarafa ou encore OBM[9]. Présentons tout d’abord les différents logiciels.
Kolab est une suite collaborative open-source tenue par le Consortium
Kolab, un consortium allemand, qui permet de gérer les mails et carnets
d’adresse d’une organisation, le but principale de Kolab et de tout conserver
dans un serveur IMAP (mails comme carnets, notes, agendas, fichiers, etc).
Le serveur gère les droits d’accès et la synchronisation du clients. Il utilise
des normes open-sources et connues pour être compatible avec beaucoup de
logiciels. ( Pour plus d’information, aller sur "https ://kolab.org/")
OBM est une suite collaborative, développée par Linagora, qui permet à
ses utilisateurs de conserver, organiser et partager des rendez-vous, des mails,
des contacts ou encore des documents. Le serveur est compatible avec de nombreux navigateurs, et des clients pour l’annuaire. Les fonctionnalités d’OBM
sont aussi accessibles grâce à des connecteurs pour Thunderbird ou Outlook.
Cette plate-forme peut être intégrée à un système d’information existant facilement. (Voir plus information dans ce site "http ://www.obm.org/")
Zarafa est elle aussi une suite collaborative open-source, développée par
13
Connectux initialement (renommée Zarafa), qui fournit des services de stockage de courriers électroniques sur un serveur, et des clients AJAX ou
HTML. Des versions commerciales existent et rendent disponibles des services avancés. Le serveur gère un carnet de contacts personnel, un calendrier,
des notes et des tâches et un dossier Public avec un calendrier partagé disponible autant pour des utilisateurs internes ou externes.(Voir plus information
dans ce site "https ://www.zarafa.com/")
Zentyal est un serveur de réseau unifié open-source, qui peut servir pour
gérer l’infrastructure du réseau, faire face aux menaces de sécurité, faire office
de passerelle internet, de serveur bureautique ou encore de serveur de communications, en plus de Framework pour le développement de nouveaux services
UNIX. Il a été développé par eBox Technologies.(Voir plus information dans
ce site "http ://www.zentyal.org/")
Le dernier logiciel qui va nous servir de comparatif est Gmail, qui certes
n’est pas une suite collaborative en lui même, mais la suite Google (Drive,
Docs, Calendar et Gmail) peuvent être considéré comme une suite collaborative.
Nous avons donc le tableau comparatif suivant :
14
Feature
MTA
Stockage
Mail
Zimbra
Oui
Custom
Postfix
Base
avec Indexation
Customisé
Kolab
OUI Postfix
OBM
OUI Postfix
IMAP et
KolabXML
Cyrus et
Dovecot
OUI
Ics
OUI
iCal
et
KolabXML
IMAP,
iCal
et
HTML
OUI
OUI
OUI
OUI sauf
pour les
composantes
closedsource
OUI
Serveur
IMAP
IMAP
Non
Partagé
Calendrier iCal
Calendrier iCal
Partagé
Fichier
Partagé
Antivirus
et Antispam
Gratuit
Zentyal
OUI Postfix
Gmail
OUI
OBM DB
Zarafa
OUI Postfix Exim
Qmail
MySQL
Serveur
IMAP
MariaDB
OUI
OUI
Dovecot
OUI
OUI
Dossier
Public
Outlook et
iCal
NON
Payant
Outlook et
iCal
Google
Agenda
Ics
Outlook et
Webaccess
Outlook et
Webaccess
Google
Agenda
OUI mais
limité
OUI
NON
NON
OUI
OUI
OUI
OUI
OUI mais
assistance
Payante
NON
NON
OUI
mais
pas
toutes
les fonctionnalités
Table 1.1 – Tableau Comparatif des Suites Collaboratives
Pour résumé, le premier choix qui est de définir un système de courriel
open-source avec sa propre base de données sur un serveur propre vient d’un
besoin de confidentialité et de sécurité des données. Lorsque nous utilisons
un logiciel tel que GMAIL 1 , les informations sont conservées sur les serveurs
Google et nous ne pouvons pas être sûrs de qui a accès à ces informations.
Le système doit être open-source pour pouvoir être personnalisé, et gratuit
pour éviter d’avoir des licences à gérer. Le choix s’est porté sur Zimbra pour
ces raisons principalement, mais aussi pour des raisons de confiance du fait
de son nombre d’utilisateurs (500 millions de téléchargements, 100 millions
d’utilisateurs pour la version payante).
1. Savoir plus sur Gmail "https ://www.google.com/intl/fr/mail/help/about.html"
15
1.3.4
Déploiement du système à grande échelle
Pour Zimbra : En utilisant les informations disponibles, et en utilisant
les précédentes expériences de Netnam en terme de système de courriers
électroniques, nous pouvons résumer l’installation de Zimbra dans le tableau
suivant :
Small
(<1,000
Users)
Tous les composants sur un serveur
Medium (1,000 à
2,500)
Large (2,500
15,000)
— LDAP
et
BDD Message
sur un serveur
— MTA sur un
serveur
— autres MTA
sur
autres
serveurs
à
— LDAP sur un
serveur
— Un ou plusieurs serveurs
de
boîtes
mails
Très
(>15,000)
Large
— Un
serveur
LDAP comme
Master
— Plusieurs Répliques
du
LDAP
— Un ou Plusieurs serveurs
MTA
— Plusieurs serveurs de boîtes
Mails
— Un ou plusieurs serveurs
Proxy
— Plusieurs serveurs MTA
— Plusieurs serveurs Proxy
Table 1.2 – Tableau des serveurs requis pour Zimbra
Selon les differents taille du système (Voir dans la table 1.2), avec 1.000.000
de compte, on doit utiliser le dernier " très lagre ", avec plusieur serveur,
comme serveur LDAP , serveur Boites de mails, serveur MTA, et serveur
Proxy. Nous voudrons etre sure que s’il y a un serveur qui ne marche plus,
et le client peut toujour connecter dans notre systeme et peut utiliser des
informations.
Caractéristiques techniques du système : Quelque caractéristiques de
systèmes email, qu’on doit savoir pour voir un peu près ce qu’il va arriver
dans norte systeme. (Voir dans la table 1.3 )
16
Service
Capacité
pour
1,000,000
Chaque compte peut augmenter sa capacité (se- 500Mb à 2Gb
lon Admin)
Dans les boîtes mails, les utilisateurs activent 80% = 800.000
réellement
comptes
Taille maximale d’un mail reçu
500kb
Envoyer et recevoir quotidiennement
10.000 Mails et
500.000 Mails
Taille moyenne des fichiers attachés
700kb
Taille maximale des fichiers attachés
20Mb
Moyenne de stockage utilisé des boîtes Mails
50%
Utilisateurs utilisant POP ou IMAP
50%
Nombre de mails envoyés par minute
100
Table 1.3 – Tableau des Capacités par Service de Zimbra
Pour un compte email, on peux configurer des au debut et c’est possible
si on veut augmenter, tout les utilisateurs 1.000.000, on sait qu’ils vont pas
active tout en meme temps peut etre 80 pourcentage, et aussi chaque minute
des mails envoyés 100 mails.
1.4
1.4.1
Cloud Infrastructure
Virtualisation
La virtualisation[10] consiste à faire fonctionner un ou plusieurs systèmes
d’exploitation, applications comme un simple logiciel, sur un ou plusieurs
ordinateurs-serveurs, au lieu de ne pouvoir en installer qu’un seul par machine. Alors que les machines virtuelles ne peuvent lancer qu’un certain
nombre d’opérations par seconde , la virtualisation permet de lancer plus
d’opérations que la somme des opérations des machines virtuelles qui la composent. Chaque copie d’un système d’exploitation est installée sur une machine virtuelle dans le but d’ajouter des applications au système virtualisé.
Chaque machine aura donc sa propre mémoire, ses propres ressources et sa
carte réseau virtuel, la rendant indépendante : si une machine virtuelle ne
fonctionne plus, aucun impact n’aura lieu sur les autres machines virtuelles
du système.(Voir dans la figure1.7)
17
Figure 1.7 – Schéma d’un Hyperviseur[11]
L’Hyperviseur est une couche logicielle située entre la partie Matérielle et
le système d’exploitation qui va interagir avec le matériel et les ressources,
fournir une interface afin de partager les ressources disponibles dans les différents conteneurs virtuels. Deux types d’hyperviseur existent : le premier,
Bare-Metal, concerne les hyperviseurs directement installés dans le serveur
physique, aucune application ou système d’exploitation n’a besoin d’être installé. Le second, appelé Hosted, fonctionne de la même manière qu’une application installée sur un système d’exploitation.(Voir dans la figure1.8)
Figure 1.8 – Fonctionnement des deux types d’Hyperviseur[10]
18
1.4.2
Le Cloud Computing
Maintenant que nous avons vu la base de la virtualisation, nous allons
nous intéresser au Cloud Computing[14]. Le Cloud Computing (ou Nuage
Informatique) fournit des services ou des applications informatiques en ligne,
accessibles partout à tout moment, de n’importe quel terminal dès qu’on
a un accès Internet. Pour être plus précis, le Cloud Computing permet de
partager, chez un fournisseur d’offres Cloud, une infrastructure, une solution
applicative ou encore une plateforme à tout utilisateur qui en fait la demande
via un simple site internet (aussi appelé portail) en libre-service.(Voir dans
la figure1.9)
Figure 1.9 – Contenu du Cloud[12]
Caractéristiques du Cloud : Le modèle Cloud Computing possède cinq
caractéristiques essentielles, qui sont :
— Un Accès par l’utilisateur à la demande :
La mise en oeuvre des systèmes est entièrement automatisée et la mise en
place ainsi que la configuration des systèmes est faîte par l’utilisateur, à
distance.
— Un Accès réseau à large bande :
Les centres de traitement du Cloud Computing sont généralement raccordés directement sur les dorsales d’Internet pour bénéficier d’une excellente
19
connectivité. Les grands fournisseurs répartissent les centres de traitement
sur la planète pour fournir un accès aux systèmes en moins de 50ms de
n’importe quel endroit.
— Réservoir de ressources (non localisées) :
La plupart de ces centres comportent des dizaines de milliers de serveurs
et de moyens de stockage pour permettre des montées en charge rapides.
Il est souvent possible de choisir une zone géographique pour mettre les
données à "proximité" des utilisateurs.
— Redimensionnement rapide :
La mise en ligne d’une nouvelle instance de serveur est réalisée en quelques
minutes, l’arrêt et le redémarrage en quelques secondes. Toutes ces opérations peuvent s’effectuer automatiquement par des scripts. Ces mécanismes de gestion permettent de bénéficier de la prochaine caractéristique
en adaptant la puissance de calcul au trafic instantané.
— Facturation à l’Usage :
Il n’y a généralement pas de coût de mise en service (c’est l’utilisateur qui
réalise les opérations). La facturation est calculée en fonction de la durée
et de la quantité de ressources utilisées. Une unité de traitement stoppée
n’est pas facturée.
Positionnement du Cloud Computing : Les offres de Cloud Computing sont définies par rapport à la répartition des rôles qui est effectuée entre
le fournisseur de service Cloud et l’entreprise. Trois modèles [15] existent :
— IaaS (Infrastructure as a Service) :
Dans le modèle IaaS, seul le matériel (serveurs, baies de stockage, réseaux)
qui constitue l’infrastructure est hébergé chez un prestataire ou un fournisseur. Avec le modèle IaaS, l’entreprise bénéficie d’une infrastructure
mutualisée (pour des raisons évidentes de coûts des matériels) et automatisée. Avec un modèle IaaS très flexible, l’entreprise peut diminuer ou
augmenter ses ressources IT en fonction de ses besoins actuels et futurs.
— Paas (Platform as a Service) :
Le modèle PaaS se place à un niveau supérieur du modèle IaaS en offrant
aux entreprises un environnement leur permettant de déployer leurs développements. Le PaaS fournit ainsi des langages de programmation, des
20
bases de données et différents services pour faire fonctionner leurs applications. De plus, il automatise entièrement le déploiement (mises à jour,
correctifs, etc) et la montée en charge.
— SaaS (Software as a Service) :
Le modèle SaaS fournit des applications à l’utilisateur sous la forme d’un
service prêt à l’emploi qui ne nécessite aucune maintenance : les mises à
jour étant régulièrement faites par l’éditeur. Il est donc perçu, à juste titre
par les utilisateurs, comme un modèle de consommation des applications.
Cloud privé et Cloud public : De manière générale, un Cloud public se
compose d’un service ou d’un ensemble de services achetés par une entreprise
ou une structure et livrés via Internet par un fournisseur tiers. Ces services
utilisent de l’espace de stockage et des processeurs qui ne sont pas la propriété
de l’entreprise qui les achète. Au lieu de cela, cette capacité (sous la forme
de serveurs et centres de données) peut être détenue soit par le fournisseur
direct (par exemple, une entreprise de stockage/sauvegarde en ligne) ou par
un fournisseur d’infrastructure Cloud.
Un Cloud privé est essentiellement une extension du centre de données
traditionnel d’une entreprise, optimisée pour offrir capacité de stockage et
puissance de traitement à tout un éventail de fonctions. Le terme "privé"
renvoie au fait que ce type de plate-forme n’est pas partagé et non à un
éventuel avantage en termes de sécurité.
1.4.3
Solutions Existantes du Cloud
Nous allons faire la comparaison des solutions libres du Cloud Computing
existantes :
— Eucalyptus : est un logiciel Open-Source pour l’implémentation du cloud
computing sur une grappe de serveurs[16][17].
— OpenNebula : est une plateforme purement Open-Source permettant de
déployer des Clouds privés, hybrides et publiques[18].
— Openstack : est une offre d’IaaS 100 pourcent open-source encore en
développement qui a livré son code source récemment et qui permet aux
sociétés de développer leurs propres solutions d’infrastructure du Cloud
Computing[19].
21
— ClouStack : cela commence avec Cloud.com. L’objectif était de permettre
aux fournisseurs de services aux entreprises de créer et d’exploiter des
Clouds publics ou privés[20].
Comparaison entre les logiciels du Cloud Computing : Nous avons
présenté une liste de logiciels permettant de créer des solutions Cloud. Il est
à présent temps de faire le choix de celui qui nous convient le mieux. Une
comparaison est menée dans le tableau 1.4, selon plusieurs critères choisis en
fonction des conseils trouvés. [21] [22].
22
But
Architecture
Système
d’exploitation
Langage
Interface
utilisateur
Openstack
Cloud public
et Cloud privé
Intégration
des
deux
composants
OpenStackobject
et
OpenStackcompute
Linux
(Ubuntu, Fedora, CentOS,
OpenSUSE
et Debian)et
récemment
Windows
Python
Eucalyptus
Cloud public
et privé
Hiérarchique,
Cinq
composants,
Supporte multiple cluster,
Minimum
deux serveurs
Linux
OpenNubela
Cloud privé
CloudStack
Cloud privé
Centralisé,
Trois
composants,
Minimum
deux serveur
Intégration
des
storage(pod),
network,
cluster
et
manage
Open-Source
Windows, Linux
Java, C, et
Python
Interface Web EC2-soap WS
API and S3,
Elastic Block
Store (EBS)
Tolérance Replication
aux
pannes
Emplace- OpenStack
ment des Compute
VMs
Java, Ruby,
C++
EC2,
Sunstone,vCloud,
API
OCCI
(storage, virtualization,
network)
Séparation
Database
des clusters backend (encontrollers
registre
les
informations
des machines
virtuelles)
Node control- Cluster node
ler
Java
web interface
replication
Cluster
Table 1.4 – Comparaison entre les logiciels du Cloud Computing
Nous avons finalement choisi OpenStack pour plusieurs raisons :
— Open source sécurisée (Sous licence libre)
— Facile à installer et déployer
— Extensible
23
— Modulaire et innovante
— S’adaptant à tous types d’infrastructures existantes
— S’adressant à toutes les tailles d’entreprise
— Bien documenté
— Jeune
1.4.4
Openstack
OpenStack est un projet récent[19], composé d’un système d’exploitation
Open-Source qui sert de couverture pour gérer les ressources pour les phases
de Traitement(Compute), Stockage(storage) et de Réseaux(Network) pour
les Data Center, et qui offre une haute performance. Le travail est divisé
en différents modules ayant leur propres fonctions, pour faciliter la gestion
des ressources de chaque côté et maintenir une efficacité maximale dans le
fonctionnement du système. Des versions sont développées tous les six mois,
et nous pouvons compter un regroupement de plus de 360 sociétés et 15.000
membres individuels. Il offre la possibilité d’implémentation pour un Cloud
Public avec les trois différents modèles : IaaS, PaaS et SaaS.
Nous avons choisi OpenStack pour plusieurs raisons : tout d’abord, OpenStack est Open-Source, ensuite, il s’agit d’une solution Cloud facile à déployer
sur des machines virtuelles avec une interface, ensuite les utilisateurs peuvent
utiliser le service par eux mêmes, avec un système pour gérer les ressources
partagées de manière efficace.
Architecture Générale Nous pouvons voir plusieurs composants dans
cette architecture, que nous allons décrire ensemble.(Voir dans la figure1.10)
24
Figure 1.10 – Architecture Générale d’OpenStack[23]
Tout d’abord, pour la partie Traitement(Compute) : elle est composée
des processeurs, du disque de stockage et de l’interface réseau. C’est sur
cette composante qu’est exécutée la virtualisation, et c’est ici que sont les
ressources qui seront réparties dans les différentes machines virtuelles.
Ensuite il y a la composante Réseau(Network), qui permet aux utilisateurs
de se connecter au système OpenStack, mais aussi qui permet aux services et
machines virtuelles de communiquer entre elles et rend possible la connection
du système OpenStack à Internet.
Le composant Stockage(Storage) s’occupe de la sauvegarde de données,
avec deux types de stockages : un stockage Objet, où il est possible de stocker
un nombre infini d’objets, limité par la taille pour enregistrer les données à
l’image d’un répertoire ; un stockage en Bloc, qui fonctionne de la même façon
qu’un volume ou qu’une clé USB. Enfin le dernier composant, le Tableau de
Bord, est une interface utilisateur qui permet à ceux-ci de se connecter à
OpenStack.
Architecture Détaillée Nous allons désormais entrer plus en détails dans
l’architecture d’OpenStack.(Voir dans la figure 1.11)
25
Figure 1.11 – Architecture Détaillée d’OpenStack[24]
Comme nous pouvons le voir dans l’image, nous pouvons dénombrer 9
composants. Le premier que nous allons présenter, est le module Keystone.
Keystone s’occupe de la partie authentification de l’utilisateur lors de sa
connexion au système ainsi que de l’identification de son rôle.
Ensuite, nous avons le module Cellometer, qui sert de moniteurs à l’utilisateur sur les modules Nova, Glance, Neutron et Cinder. Cinder est le composant qui fournit des volumes de stockages pour les machines virtuelles et
est de type Bloc. Le module Nova gère quant à lui les ressources en terme
de processeurs, de RAM pour les machines virtuelles, alors que le composant
Glance fournit les images des systèmes exploitations pour les machines virtuelles, qui sont stockées dans le module Swift qui bénéficie d’un espace de
stockage de type Objet grâce à Cinder.
Le composant Neutron s’occupe de fournir une connexion réseau aux ma26
chines virtuelles. Ensuite, le module Horizon s’occupe de fournir des interfaces utilisateurs à ceux-ci pour voir les différents modules Keystone, Swift,
Glance, Nova, Neutron et Cinder. Tout ceci est géré par le dernier composant,
le composant Heat.
Noeuds dans OpenStack Au sein d’OpenStack, il y a la présence de ce
que nous pouvons appeler des noeuds, qui représentent des composants de
l’architecture OpenStack.
Figure 1.12 – Minimal Architecture Example- Network Layout OpenStack
Networking(Neutron)[24]
Il y a trois principaux Noeuds [25] : Contrôleur(Controller Node), Réseau(Network Node) et Traitement(Compute Node). Le noeud Contrôleur
représente le composant qui permet à l’utilisateur d’administrer le système,
c’est pour cela qu’il y a l’interface de Management dedans, qui est présente
dans tous les autres composants, mais ce noeud ne peut pas se connecter à
Internet. Ensuite, il y a le noeud Réseau, qui comprend le Tunnel réseau qui
permet de faire le lien entre les différentes machines virtuelles contenues dans
le noeud Traitement, en plus d’une interface pour permettre à Openstack et
27
aux utilisateurs d’accéder à Internet ou au système. Enfin, le noeud Traitement possède les informations de stockage, qui peuvent facultativement être
des noeuds de type Bloc(Block storage) ou Objet(Object storage).
Caractéristiques disponibles dans chaque noeud dans OpenStack
Nous venons de voir les différents noeuds présents dans OpenStack, nous
allons désormais nous intéresser à leur contenu, en décrivant les principaux
services de chaque noeud.
Figure 1.13 – Minimal Architecture Example - Service Layout OpenStace
Networking(Neutron)[24]
Dans le noeud Contrôleur, nous avons la base de données SQL qui va
conserver les informations et les identifiants des utilisateurs. Nous avons ensuite la queue de messages qui est faîte pour conserver les données qui ne
peuvent pas toutes être envoyées en même temps à cause de limite de tailles,
en attendant qu’un autre processus puisse s’occuper d’envoyer les données,
dans le cas contraire, les données seront renvoyées et nous aurons un cas de
"time-out". Le service de Temps Réseau s’occupe des noeuds de synchronisation avec différents noeuds. Le service Identité est utilisé pour identifié
le client pour qu’il utilise un autre service. Le service Image est un service
28
qui s’occupe de la gestion et du stockage des différentes images des systèmes
d’exploitation installables sur les machines virtuelles.
Le noeud Réseau est composé principalement de composants virtuels similaires à un réseau réel. Nous avons par exemple le service Open vSwitch qui
est un logiciel qui éxécute la virtualisation d’une carte réseau en utilisant la
fonction NAT pour connecter les switch. Le service Networking ML2 Plug-in
s’occupe de la création de switch virtuels. Le service L3 Agent s’occupe de la
création des routeurs, des connections entre les différents machines virtuelles
entre elles grâce aux switch virtuels, alors que le Networking Open vSwitch
est un agent qui gère le service Open vSwitch. L’agent Networking DHCP
est l’agent qui attribue des adresses IP de façon automatique aux machines
virtuelles. Le dernier agent est l’agent de métadonnées qui s’occupe, comme
son nom l’indique, des données associées aux images, et le traitement ainsi
que l’analyse des images.
Le dernier Noeud est le noeud de Traitement, qui est le noeud responsable de l’éxécution d’OpenStack. Il comprend notamment l’Hyperviseur qui
s’occupe de la création des machines virtuelles.
1.5
Conclusion
Nous venons de voir le fonctionnement d’un système de courrier électronique tout en dressant un comparatif des différents systèmes d’envoi et de
reception de courriels, qui nous a permis de choisir le système Open-Source
Zimbra, pour des raisons de confiance du fait du grand nombre d’utilisateurs de cette plateforme mais aussi de son contenu qui est personnalisable
facilement.
Ensuite, notre intérêt s’est porte sur la virtualisation et plus précisément
le cloud computing, pour présenter de manière approfondie le logiciel que
nous avons choisi : OpenStack. OpenStack a été choisi car il permet de réaliser
de la virtualisation avec une grande échelle en ce qui concerne le nombre de
machines virtuelles, ce qui nous intéresse car c’est exactement ce que nous
souhaitons.
29
2 Solution Implémentée
Nous allons voir dans cette partie la façon dont nous avons procédé pour
implémenter le système que nous avons réalisé durant ce stage.
2.1
Concept
Avant d’entrer dans la partie implémentation du système, il est important
d’effectuer les calculs afin de savoir quelles sont les ressources nécessaires pour
l’exécution de notre système. Nous avons souhaité résumer ces informations
dans un tableau, et nous détaillerons les calculs ensuite.
Service
Stockage des données Utilisateurs
Données dans la Base Mail
Zimbra Redo Log
Index
Zimbra System Log
Zimbra Program
Total
Requis
800.000 Gb
40,000 Gb
40 Gb
200.000 Gb
10 Gb
30 Gb
1.040.080 Gb
Table 2.1 – Ressources Nécessaires pour Zimbra avec 1.000.000 d’utilisateurs
En ce qui concerna la partie Stockage des données, nous avons environ
1.000.000 d’utilisateurs, chaque utilisateur aura 1 GB de stockage, sauf que
80% des comptes seulement sont actifs, ce qui nous donnent le résultat :
1.000.000 * 1 * 0,8 = 800.000 GB.
Pour les données MySQL, nous considérons que seulement 5% des données de chaque utilisateur concernera les mails (les autres pourcentages représentent les fichiers, les tâches, etc), nous obtenons donc le calcul suivant :
0,05 * 800.000 = 40.000 Gb.
Le dernier calcul est celui de l’Index, nous savons que 25% des données
servent à l’indexation, ce qui fait donc 0,25*800.000 = 200.000 Gb.
30
Serveur
Détails
MTA,LDAP,Proxy
— Nombre : 2 ou plus
— Processeurs : 2 * 2 GHz vCPUs
— Ram : 8Gb
Boîte Mail
— Nombre : 666
— Processeurs : 8 * 2 GHz vCPUs
— Ram : 8Gb
Table 2.2 – Serveurs Nécessaires pour Zimbra avec 1.000.000 d’utilisateurs
Concernant le nombre de serveurs pour les boîtes mails, nous voulons
un système avec 1.000.000 utilisateurs. Or, Netnam de par son expérience
nous a conseillé de ne pas dépasser plus de 3.000 utilisateurs par serveur de
boîte mail, auquel cas il pourrait y avoir des problèmes pour la gestion des
connexions utilisateurs. Donc en effectuant le calcul 1.000.000 / 3.000 = 666
serveurs.
Comme nous pouvons le constater, le total de l’espace nécessaire uniquement pour Zimbra est de plus de 1.000.000 Gb en plus de 666 serveurs pour
les boîtes mails. Nous n’avons malheureusement pas assez de ressources, c’est
pourquoi nous avons décider de diminuer le nombre d’utilisateurs en le passant de 1.000.000 à 10.000. Nous avons donc un système utilisant Zimbra 8.6,
avec 10.000 comptes de 1 Gb avec des fonctionnalités anti-spam et anti-virus.
Nous obtenons donc alors le système suivant :
Service
Stockage des données Utilisateurs
Données dans la Base Mail
Zimbra Redo Log
Index
Zimbra System Log
Zimbra Program
Total
Requis
8.000 Gb
400 Gb
40 Gb
2.000 Gb
10 Gb
30 Gb
10.480 Gb
Table 2.3 – Ressources Nécessaires pour Zimbra avec 10.000 d’utilisateurs
Maintenant, comme nous savons qu’une boîte mail peux avoir 3.000 utili31
sateurs, afin d’avoir une haute disponibilité de serveurs, nous allons prendre 6
serveurs au lieu de 4 requis. Nous allons donc calculer les coûts en ressources
de la virtualisation OpenStack.
Noeud
Contrôleur
Réseau
Traitement
Stockage
Total
Serveur
sique
2
2
2
2
8
Phy- Ram (Gb)
4
4
70
80
158
Processeurs
2
2
32
32
68
Table 2.4 – Ressources Nécessaires pour ce système
Maintenant que nous avons vu les ressources nécessaires pour notre système, nous allons pouvoir nous intéresser à l’architecture globale de notre
système.
Figure 2.1 – Architecture Globale du Système choisi
Nous avons donc 3 grandes parties comme nous pouvons le voir dans
l’image. Nous avons installer OpenStack pour créer des machines virtuelles.
Ces machines virtuelles vont démarrer sur une image d’un système d’exploitation (Ubuntu, CentOS,...). Une fois ceci fait, nous ajoutons Zimbra sur un
32
couple de machines virtuelles créés et ajoutons le noeud Zimbra que nous
voulons en lançant un script personnalisé pour chaque composant logiciel.
Le protocole NFS (Network File System) joue le rôle de transfert de données au NAS (Network Attached Storage). Ce NAS est basé sur le serveur
physique, et est composé de plusieurs parties lui aussi. Tout d’abord, il va stocker des données dans différents sous-composants, mais il va aussi conserver
des machines virtuelles dans différents répertoires associés à chaque machine
virtuelle. Il possède aussi le protocole ISCSI (Internet Small Computer System Interface) qui s’occupe du transfert de données Volume, son rôle est
aussi le même que NFS sauf qu’il est limité en ce qui concerne le transfert
des données. Pour la partie Zimbra, nous avons une partie de sauvegarde des
e-mails, mais il y a aussi de l’espace associé à cet objectif dans la partie NAS.
2.1.1
Concept pour Openstack
Nous allons donc devoir installer 4 noeuds dans notre système, mais
pour préparer le système, nous devons ajouter la partie communication dans
chaque noeud, en utilisant le Modular Layer 2, responsable de cette communication inter-noeuds. Dans le noeud Contrôleur, nous aurons en plus le
composant Keystone afin d’authentifier et Cinder qui est similaire à un stockage externe, qui va utiliser le protocole ISCSI pour transférer ces données,
en plus du Modular Layer 2.
Le noeud réseau aura quant à lui le composant Modular Layer 3 qui
représente la carte réseau permettant au système de se connecter à Internet,
en plus du Modular Layer 2 qui jouera le rôle de switch local. Le noeud de
Traitement aura les composants Nova pour l’hyperviseur, qui s’occupera de
répartir les ressources du système, et le composant Neutron pour le réseau,
en plus du Modular Layer 2.
Enfin le stockage aura le protocole NFS pour se connecter aux données, le
NAS pour stocker les données dans chaque répertoire des machines virtuelles
et comme toujours, le Modular Layer 2 pour la communication. Nous aurons
donc les logiciels suivants :
33
Contrôleur
(Controller
Node)
Traitement(Compute
Réseau(Network Stockage(storage)
Node)
Node)
— Keystone
— Nova
— ML2
— ML2
— Cinder
— Neutron
— ML3
— NAS
— ML2
— ML2
— NFS
Table 2.5 – Logiciels Nécessaires dans chaque Noeud
2.1.2
Concept pour Zimbra
Pour Zimbra, nous avons opté pour une solution sécurisée et à haute
disponibilité en couplant des serveurs afin d’avoir un mode actif-actif ou actifpassif dans le cas où un serveur a un problème, ce qui permettra de pouvoir
toujours se connecter au système par l’intermédiaire du serveur miroir qui
prendra alors le relai. Nous aurons donc le système Zimbra suivant :
Figure 2.2 – Architecture du système Zimbra implémenté
Comme nous pouvons le constater, chaque serveur a sa réplique en miroir
qui assure le bon fonctionnement du système même dans le cas d’une panne
34
d’un serveur. Nous aurons dans chaque serveur des modules qui lui seront
installés, on aura donc Zimbra installé dans chaque machine virtuelle des
serveurs mais seulement quelques composants seront présents.
Composant
Serveur de boîtes Mails
Modules Installés
— zimbra-core
— zimbra-logger
— zimbra-snmp
— zimbra-store
— zimbra-apache
— zimbra-spell
Serveur MTA
— zimbra-core
— zimbra-mta
— zimbra-snmp
Serveur LDAP
— zimbra-core
— zimbra-ldap
— zimbra-snmp
Serveur Proxy
— zimbra-core
— zimbra-snmp
— zimbra-memcached
— zimbra-proxy
Table 2.6 – Modules Zimbra présents dans chaque Serveur
Comme nous pouvons le constater dans la table 3.1, les composants MTA,
LDAP, Proxy, Mailbox, auront tous un Zimbra installé mais avec des options
différentes que nous choisirons dans l’interface dans "Modules installés". Nous
devons le faire ainsi afin d’avoir un meilleur contrôle de gestion du système.
35
2.2
Implémentation
Dans cette partie, nous allons présenter les utilisateurs du système et
ensuite implémenter la solution en commençant tout d’abord par OpenStack sous un système d’exploitation Ubuntu 14.04 64 bits avec QEMU( ou
Quick Emulator) comme hyperviseur en Multi-Noeuds (Contrôleur, Réseau
et Traitement) afin de pouvoir créer des Machines Virtuelles.
Utilisateurs du système
Pour notre solution, il existe deux types d’utilisateurs L’administrateur
du système et les utilisateurs.
Administrateur L’administrateur joue le role très important de gestionnaire du système, et doit être capable d’effectuer les actions suivantes :
— Ajouter de nouveaux administrateurs
— Supprimer des administrateurs
— Ajouter de nouveaux utilisateurs
— Supprimer des utilisateurs
— Créer un projet
— Créer de nouvelles machines virtuelles
— Gérer et créer un réseau
Chaque utilisateur possède un login et un mot de passe unique, modifiable
à volonté par le concerné.
Utilisateur Ce rôle utilisateur sera attribués aux utilisateurs du systèmes
et aussi aux responsables d’entreprise, et doit pouvoir :
— Stocker des données dans la limite de ses possibilités
— Instancier des machines virtuelles
36
Figure 2.3 – Diagramme de cas d’utilisation
Diagramme
2.2.1
Installation d’OpenStack
Préparation du Noeud Contrôleur Après avoir installé Ubuntu LTS
server 14.04 sur une machine virtuelle considérée comme notre serveur, nous
devons installer OpenStack. Tout d’abord il est nécessaire d’installer Keystone, Glance, Neutron et Nova. Une fois les services installés, nous pouvons
préparer le nouveau Noeud.
Nous devons modifier le fichier "etc/network/interfaces", afin d’effectuer
la configuration des cartes réseaux.
37
#Nous allons ajouter l’adresse IP pour les interfaces
#dans le fichier vi/etc/network/interfaces
#Réseau Externe
auto eth0
iface eth0 inet static
address 10.30.12.71
netmask 255.255.255.0
gateway 11.30.0.1
#Réseau de Gestion
auto eth1
iface eth1 inet static
address 10.30.0.10
netmask 255.255.255.0
gateway 10.30.0.1
#Ensuite il faut redémarrer la partie réseau pour
#prendre en compte ces modifications
$ service networking restart
#On ajoute un nom de domaine
$hostname controller
Nous avons maintenant le noeud Contrôleur qui est opérationnel, nous allons
donc installer des paquets pour avoir les applications nécessaires.
#Install the supporting services (NTP, MySQL and RabbitMQ) #Install
NTP $apt-get install ntp #Puis nous installons le serveur MySQL $apt-get
install python-mysqldb mysql-server #Nous installons ensuite le serveur de
messagerie
#Installation du service RabbitMQ(Message Queue) qui permet aux composants OpenStack de communiquer entre eux. $apt-get install rabbitmq-server
#Installation de Keystone
$apt-get install Keystone python-keystoneclient #Installation de Glance
$apt-get install glance
Il faut savoir que MySQL est nécessaire pour le stockage des données
car c’est un pré-requis d’OpenStack. Cette base de données servira de base
38
en fin de traitement. L’étape de changement de configuration de MySQL
est optionnelle dans le cas d’une installation avec un seul noeud, cependant,
comme nous sommes dans une installation multi-noeuds, MySQL devra démarrer sur toutes les interfaces, pas seulement sur localhost. Concernant le
serveur de messagerie, il faut savoir que OpenStack a besoin d’un service de
messagerie pour réaliser les communications entre ses services, RabbitMQ,
QPid et 0MQ sont supportés par OpenStack. Nous avons désormais notre
Noeud Contrôleur qui est prêt pour l’installation d’OpenStack.
Préparation du Noeud Traitement Le noeud Traitement doit bénéficier de deux interfaces réseaux : une pour la connexion au réseau eht0 et une
autre pour l’utilisation du réseau interne de gestion.
#vi /etc/network/interfaces
#Réseau de Gestion
auto eth0
iface eth0 inet static
address 10.30.0.20
netmask 255.255.255.0
gateway 10.30.0.1
#Réseau de Données
auto eth1
iface eth1 inet static
address 10.30.12.73
netmask 255.255.255.0
gateway 11.30.0.1
#Ensuite il faut redémarrer la partie réseau pour
#prendre en compte ces modifications
$ service networking restart
#On ajoute un nom de domaine
$hostname compute
Maintenant, nous avons notre noeud Traitement prêt, nous devons lui installer les logiciels, en ajoutant les paquets du Cloud et les librairies MySQL
et MySQL Python, car comme nous l’avons dit précédemment, MySQL doit
être présent dans tous les noeuds.
39
#Installation des nouvelles versions de Cloud
$apt-get install python-software-properties
$add-apt-repository cloud-archive :havana
$apt-get dist-upgrade (Optional)
#Puis nous installons le client MySQL et la librairie MySQL Python
$apt-get install python-mysqldb
#install NTP
$apt-get install ntp
#Install Compute packages
$ apt-get install nova-compute sysfsutils
Nous avons donc nos deux noeuds Traitement et Contrôleur qui sont fonctionnels, nous allons effectuer la même chose pour le noeud Réseau.
Préparation du Noeud Réseau Cette fois ci, nous avons un noeud
avec trois interfaces réseaux : une pour la connexion au réseau eth0, une autre
pour l’utilisation du réseau interne et la dernière pour la connexion entre les
machines virtuelles.
40
#vi /etc/network/interfaces
#Réseau Externe
auto eth0
iface eth0 inet static
address 192.168.100.30
netmask 255.255.255.0
gateway 192.168.100.1
#Réseau de Gestion
auto eth1
iface eth1 inet static
address 192.168.0.72
netmask 255.255.255.0
gateway 192.0.0.1
#Réseau de Données
auto eth2
iface eth2 inet static
address 11.0.0.10
netmask 255.255.255.0
gateway 11.0.0.1
#Ensuite il faut redémarrer la partie réseau pour
#prendre en compte ces modifications
$ service networking restart
#On ajoute un nom de domaine
$hostname network
Et comme pour le noeud précédent, nous devons installer les dernières versions du Cloud et la librairie MySQL Python.
41
#Installation des nouvelles versions de Cloud
$apt-get install python-software-properties
$add-apt-repository cloud-archive :havana
$apt-get dist-upgrade (Optional)
#Puis nous installons le client MySQL et la
#librairie MySQL Python
$apt-get install python-mysqldb
#Installation Quantum pour Neutron
$apt-get install neutron-server neutron-plugin-ml2 python-neutronclient
neutron-l3-agent neutron-dhcp-agent
Nous avons donc nos trois noeuds qui sont prêts pour l’éxécution d’OpenStack.
Figure 2.4 – Résultat d’installation
Installation d’Horizon Dans le contrôleur Node nous avons installer
Dashboard Horizon qui permet de simplifier l’administration du serveur et
des projets. Pour pouvoir accéder à partir d’un navigateur web pointant à
l’adresse du serveur.
42
#Installation des paquets Horizon :
$apt-get install openstack-dashboard memcached
#Puis Redémarrage des services apache et memcached :
$service apache2 restart ;
$service memcached restart
Voici les résultat obtenus, pour accéder à l’interface d’administration :
http ://10.30.0.22/horizon
user : admin
password : mot de pass
Nous allons maintenant réaliser la création des machines virtuelles qui
contiendront Zimbra.
2.2.2
Création des machines virtuelles
Nous venons d’installer OpenStack et les différents noeuds pour notre
système, nous devons désormais ajouter l’architecture miroir du système.
Nous pouvons représenter le système comme voici :
43
Figure 2.5 – Architecture des Machines Virtuelles
Nous pouvons remaquer la présence de trois niveaux dans cette architecture :
— Le Réseau Public : le Cloud ou Internet
Nous avons deux couples miroirs Proxy et MTA. Ce niveau permet aux
deux types de serveurs de se connecter à l’extérieur mais aussi de se
connecter au système OpenStack et utilise SSH (Secure Shell) pour se
connecter aux machines virtuelles locales. Le couple de Proxys utilise des
adresses IP virtuelles (VIP) pour s’assurer que les clients sont toujours
capables de se connecter aux systèmes avec une balance de chargement
pour protéger des cas d’échecs ou de tailles de fichiers trop grandes.
— Le Réseau Privé
Cela permet aux serveurs de se connecter entre eux de façon locale, mais
aussi avec Internet en passant par les Proxys de la couche supérieure. C’est
dans cette couche que sont situées les machines virtuelles des serveurs de
boîtes mails et de LDAP.
— Le Réseau Externe
Cette couche s’occupe de faire l’accès à Internet pour les machines virtuelles afin qu’elles puissent envoyer des courriers électroniques mais pas
44
en recevoir (il est nécessaire de passer dans la couche 1 pour recevoir).
2.2.3
Installation de Zimbra
Pour installer Zimbra, il faut au préalable installer NTP (Network Time
Protocol) sur tous les serveurs afin de bénéficier des différentes zones temporelles. Nous devons installer aussi les DNS sur les serveurs MTA et créer
un environnement "chroot" afin de changer la place du répertoire root des
serveurs dans un autre serveur.
#Installation de NTP sur tous les serveurs
# pour un temps synchronisé
$apt-get install ntp
#Puis nous préparons les serveurs MTA
#En installant le DNS
$yum install bind* -y
#En mettant en place un environnement
# chroot pour les répertoires différents
$yum-y install bind-chroot
$service named restart
Nous venons de préparer les serveurs MTA à l’installation de Zimbra, nous
allons pouvoir passer à cette étape, en installant Zimbra dans les serveurs
LDAP et MTA.
Installation de Zimbra dans MTA et LDAP Grâce à l’interface de
Zimbra, nous pouvons choisir les composants propres à chaque serveur (voir
tableau 3.1 à la page 54). Nous obtenons ainsi le système suivant :
45
Common Configuration
+Hostname : mta01.chanthala.vn
+Ldap master host : ldap01.chanthala.vn
+Ldap port : 389
+Ldap Admin password : SET
+LDAP Base DN : cn=zimbra
+Secure interprocess communications : yes
+TimeZone : Asia/Bangkok
+IP Mode : ipv4
+Default SSL digest : sha256
zimbra-mta : Enabled
+Enable Spamassassin : yes
+Enable Clam AV : yes
+Enable OpenDKIM : yes
+Notification address for AV alerts : [email protected]
+Bind password for postfix ldap user : SET
+Bind password for amavis ldap user : SET
zimbra-snmp : Enabled
Installation de Zimbra dans les Boîtes Mails Comme dans les parties
précédentes, l’installation de Zimbra se fait grâce aux interfaces du logiciel
lors de l’installation. Après avoir installé Zimbra dans les Boîtes Mails, nous
obtenons le fichier système suivant :
46
Common Configuration
+Hostname : chanthala.vn
+Ldap master host : ldap01.chanthala.vn
+Ldap port : 389
+Ldap Admin password : SET
+LDAP Base DN : cn=zimbra
+Secure interprocess communications : yes
+TimeZone : Asia/Bangkok
+IP Mode : ipv4
+Default SSL digest : sha256
+Statut : Enabled
+Create Admin User : yes
+Admin Password : set
Anti-virus Quarantine user : [email protected]
Enable automated spam training : yes
Spam training user : [email protected]
Non-Spam(Ham) training user : [email protected]
SMTP host : chanthala.vn
Web server HTTP port : 80
Web server HTTPS port : 443
Web server mode : https
IMAP Server port : 143
IMAP Server SSL port : 993
POP Server port : 110
POP Server SSL port : 995
Use spell check server : yes
Spell server URL : http ://chanthala.vn :7780/aspell.php
Configure for use with mail proxy : FALSE
Configure for use with web proxy : FALSE
Enable Version update checks : TRUE
Enable Version update notifications : TRUE
Version update notifications email : [email protected]
Version update source email : [email protected]
Install mailstore (service webapps) : yes
Install UI (zimbra, zimbraAdmin webapps) : yes
Il ne nous reste plus qu’ à créer les proxys avec l’interface fournie par zimbra
et installer ainsi que configurer le protocol NFS.
Nous venons de finir l’implémentation de notre système, nous avons donc
un système composé de machines virtuelles dans Openstack, réparties dans
différents noeuds et possédant différents composants de la suite collaborative
47
de Zimbra. Toutes ces machines possèdent un réseau interne qui leur permet
de communiquer entre elles, mais aussi d’accéder aux réseaux externes comme
Internet ou encore le Cloud. Nous allons pouvoir désormais effectuer quelques
expérimentations sur le système conçu.
48
3 Expérimentations sur le Système
Nous venons d’implémenter un système complexe basé sur la virtualisation des serveurs grâce à OpenStack pour l’architecture d’un système de
courrier électronique de la suite collaborative Zimbra. Pour les expérimentations, nous allons tout simplement essayer d’entrer dans le système en tant
qu’administrateur et envoyer un email à une autre adresse.
3.1
Administration d’OpenStack
Interface d’authentification Lorsque nous tapons dans notre navigateur
l’adresse du réseau pour accéder à l’outil de gestion Openstack (10.30.0.22/horizon/ où horizon est le composant s’occupant de l’affichage des interfaces utilisateurs et 10.30.0.22 représente l’adresse IP du serveur possédant le système
OpenStack) nous avons donc l’interface suivante :
Figure 3.1 – Interface d’Authentification sous OpenStack
Cette interface permet à l’utilisateur OpenStack de s’authentifier pour
49
accéder aux différentes interfaces de gestion et de synthèse d’OpenStack.
Exemples de modules accessibles L’utilisateur, une fois authentifié,
peut accéder aux modules de gestion d’OpenStack, tels que la vue générale
d’Openstack.
Figure 3.2 – Vue Générale d’OpenStack
Cette vue présente les différentes Instances et Ressources contenues par
le système de virtualisation OpenStack et permet aussi de voir un résumé
d’utilisation sur une période donnée.
50
Figure 3.3 – Vue de la Topologie d’Openstack
L’utilisateur administrateur peut aussi avoir une vue de la topologie
d’OpenStack, avec un bref descriptif de chaque machine virtuelle pour savoir son activité, et a la possibilité d’afficher plus de détails ou même de
terminer l’instance.
3.2
Administration de Zimbra
Les interfaces pour résumer l’état de service de Zimbra dans les différentes instances sont aussi présentes, mais elles nécessitent aussi une authentification sur le serveur en utilisant un navigateur par exemple, à l’adresse
https ://webmail.chanthala.vn.
51
Figure 3.4 – Interface d’authentification sous Zimbra
Si l’utilisateur qui a été authentifié est un administrateur, il accède à une
interface spéciale qui lui permet de voir l’état du système Zimbra.
Figure 3.5 – Interface en Administrateur sous Zimbra
Comme nous pouvons le voir dans l’image, nous avons l’état des différents
services regroupés selon les serveurs sur lesquels ils sont situés.
52
3.3
Test d’envoi de Mail
Nous venons de voir dans la partie précédente la façon dont nous pouvons
administrer le système, nous allons désormais voir si celui-ci fonctionne en envoyant un email et en recevant un email. Après s’être connecté via l’interface
que nous avons vue pour s’authentifier dans l’image 3.4 à la page 52 , l’utilisateur va accéder à un client web mail. Nous avons donc décidé d’envoyer
un mail sur l’adresse [email protected] pour tester le bon fonctionnement
du système et ensuite d’y répondre.
Figure 3.6 – Interface en Utilisateur sous Zimbra
Comme nous pouvons le voir, les mails ont bien été envoyés et reçus
par le système. Cependant, durant le test, un problème avait été rencontré
et résolu : Nous avons envoyer les courriers électroniques de notre système
zimbra à une boite mail extérieure comme Gmail et une adresse de messagerie
de l’IFI : nous recevons bien les Emails mais nous ne pouvons pas en envoyer
à l’adresse qui nous les a envoyés. Ceci est dû au DNS, qui ne permet par
aux adresses externes de connaître notre adresse IP et considère comme un
spam notre message. Ce problème a été résolu en achetant une clé publique
pour le DNS afin que les boîtes mails sachent vers quel serveur envoyer le
53
mail, étant donné qu’avant cet achat, la destination leur était inconnue.
Comparaison entre Installation de Machines Virtuelles sur le
Cloud et sur un Ordinateur Physique : Si nous souhaitons utiliser
le système dans une entreprise qui a un nombre d’employés inférieur à 1.000,
il est possible d’installer Zimbra sur un serveur physique, mais dans le cas
d’un nombre conséquent d’utilisateurs, comme pour une université ou une
gouvernement, il est préférable d’utiliser le service cloud car il ne demandera
qu’un court délai pour augmenter ou diminuer la taille du système, alors que
physiquement il faudrait acheter plusieurs serveurs,etc.
Capacité
Un parc de serveurs
Utilisation du serveur
un serveur physique
contient
beaucoup de capacité de stockage et
de puissance mais
peut entraîner un
gaspillage en cas
de sous utilisation
Augmenter ou Diminuer la taille Possible mais diffidu système
cile si l’infrastructure de base ne suffit pas
Employer un administrateur
Oui
Électricité pour les serveurs avec Oui
salle à bonne température
Travailler à distance
Non
Coût des serveurs
Élevé
Un fournisseur de
service
100 %, avec le
Cloud car il est
possible de choisir et payer uniquement selon ses besoins
Facile d’ajouter et
diminuer
Pas nécessaire
Pas Besoin
Oui
Par Forfait
Table 3.1 – Tableau Comparatif deux différents systèmes
54
4 Conclusion
En conclusion, à travers ce document, nous avons présenté différents logiciels open-sources permettant de réaliser un système de courriers électroniques, et nous avons dressé un comparatif entre les différentes solutions existantes dans cette catégorie. Nous nous sommes interrogés sur les systèmes de
virtualisation et du Cloud Computing et nous les avons comparés dans le but
de coupler un système de virtualisation avec un système de courriers électronique à grande échelle afin de concevoir un système sur le Cloud permettant
un accès partout aux utilisateurs ainsi qu’une haute disponibilité, mais aussi
une facilité de gestion et une bonne sécurité pour les administrateurs.
Nous avons donc proposé un système virtuel basé sur OpenStack en ce
qui concerne la partie Cloud Computing et virtualisation , et nous avons
opté pour Zimbra pour le système de courriers électroniques. Après avoir
vu la quantité de ressources que prendrait le système, nous avons préféré
redescendre à une échelle plus abordable avec 10.000 utilisateurs pour tester
notre prototype. Après avoir conçu l’architecture serveur et installé les deux
logiciels open-source, nous avons expérimenté notre solution en faisant un
envoi et une réception de mails sur nos serveurs, par contre nous avons dû
payer un DNS pour que l’Internet connaisse l’adresse IP de notre serveur.
Les résultats de notre système sont encourageants et nous ont ouverts
vers d’autres perspectives avant de finaliser le prototype : nous voudrions
tout d’abord modifier le filtre anti-spam afin de l’optimiser le plus possible,
ce qui est possible de par l’avantage que nous offre la possibilité Open-Source.
Enfin, nous souhaiterions augmenter la sécurité du système afin de protéger
au maximum les données contenues sur le serveur.
55
Bibliographie
[1] Wikipedia, “Listes des serveurs de mail.” https://fr.wikipedia.org/
wiki/Liste_de_serveurs_de_mail, 2015.
[2] R. E. Headers, “Courrier électronique.” https://fr.wikipedia.org/
wiki/Courrier_Ãľlectronique, 2015.
[3] B. A.Forouzan, TCP/IP Protocol suite / Behrouz A. Forouzan.âĂŤFourth Edition. (McGraw-Hill, 2010) BBS.
[4] J. R. Wietse Venema, “Smtp.” http://www.postfix.org/lmtp.8.
html.
[5] K. Lucke, “Reading email headers.” http://www.owlriver.com/spam/
stop-spam.html, 27 Apr 2004.
[6] D. H. Crocker, “Rfc 822, standard for arpa internet text messages.”
https://www.ietf.org/rfc/rfc0822.txt.
[7] V. Zimbra, “Zcs administrator guide 8.0, network edition.” https://
www.zimbra.com.
[8] Wikipedia, “Comparison of mail servers.” https://en.wikipedia.org/
wiki/Comparison_of_mail_servers, 2015.
[9] Wikipedia, “List of collaborative software.” https://en.wikipedia.
org/wiki/List_of_collaborative_software, 2015.
[10] K. Mani and D. Sullivan, “Introduction to oracle databases on virtual infrastructure.” http://www.pearsonitcertification.com/articles/
article.aspx?p=2256453, Oct 22, 2014.
[11] A.
Computing,
“Virtualisation
for
schools.”
http://www.
adm-computing.co.uk/education/virtualisation-for-schools/,
2013.
[12] Wikipedia, “Cloud computing.” https://en.wikipedia.org/wiki/
Cloud_computing, 2015.
56
[13] CludTweaks,
“Cloud
computing
email
service.”
http://cloudtweaks.com/2010/08/
top-10-cloud-computing-email-services-for-enterprise-businesses/,
August 18, 2010.
[14] I. Barrie Sosinsky, Published by Wiley Publishing, Cloud Computing
Bible. 2011.
[15] “understanding the cloud computing stack saas paas iaas,” 2015 Rackspace US, Inc.
[16] E.
site.
http://www8.hp.com/us/en/cloud/
helion-eucalyptus-overview.html.
[17] Eucalyptus.
(informatique).
https://fr.wikipedia.org/wiki/Eucalyptus_
[18] http://opennebula.org.
[19] “Openstack.” https://www.openstack.org/.
[20] “Cloudstack.” https://express.ikoula.com/fr/cloudstack.
[21] “Comparison
cloud.”
http://www.networkworld.com/article/
2189981/tech-primers/cloud-platform-comparison--cloudstack--eucaly
html.
[22] John, “Community analysis.” http://www.qyjohn.net/?p=2233.
[23] OpenStack, “Software.” http://www.openstack.org/software/.
[24] OpenStack, “Openstack installation guide for ubuntu 14.04.”
http://docs.openstack.org/juno/install-guide/install/apt/
content/ch_overview.html, 2015-11-17.
[25] OpenStack, “Openstack operations guide.” http://docs.openstack.
org/openstack-ops/openstack-ops-manual.pdf.
57
Liste des symboles
AP I Application Programming Interface
CP U Central Processing Unit
DHCP Dynamic Host Configuration Protocol
DHCP Dynamic Host Configuration Protocol
DN S Domain Name System
EC2 Elastic Compute Cloud
HT T P S HyperText Transfer Protocol Secure
IAAS Infrastructure as a Service
IM AP 4 Internet Message Access Protocol 4
IP
Internet Protocol
ISCSI Internet Small Computer System Interface
LDAP − T LS Lightweight Directory Access Protocol - StartTLS
LT S Long Term Support
M AA Mail Access Agent
M DA Mail Delivery Agent
M L2 Modular layer 2
M L3 Modular layer 3
M T A Mail Transfer Agent
M U A Mail User Agent
N AS Network Attached Storage
58
N F S Network File System
OpenLDAP Open Lightweight Directory Access Protocol
OS Operating System
P AAS Platform as a Service
P OP 3 Post Office Protocol 3
RAM Random Access Memory
SAAS Software as a Service
SM T P Simple Mail Transfer Protocol
SSH Secure Shell
U SB Universal Serial Bus
V IP virtual IP address
ZCS8.5 Zimbra Collaboration Server 8.5
59
Annexes
4.1
Annexe A - Première connexion à une instance OpenStack après son démarrage
Figure 4.1 – Annexes- Configuration de notre Interface
60
Figure 4.2 – Annexes- Génération d’une paire de clé administrateur côté
admin
Figure 4.3 – Annexes- Génération d’une paire de clé administrateur côté
OpenStack
61
4.2
Annexe B - Création d’une Instance de
Machine virtuelle
Figure 4.4 – Annexes- Création d’une image de Système d’Exploitation
62
Figure 4.5 – Annexes- Création d’une instance de machine virtuelle
Figure 4.6 – Annexes- Protocoles Extérieurs
Ces protocoles nous permettent de pinger la machine (ICMP) et de faire
un tunnel SSH avec celle-ci (TCP)
63
Figure 4.7 – Annexes- Création d’une IP publique
64