SEnthavong Chanthala
Transcription
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