SOGo Université de Strasbourg Direction Informatique Mercredi 23 mars 2011 Christophe PALANCHÉ Guillaume SCHREINER
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Introduction Contexte Fusion des universités et de l'iufm au 1er janvier 2009 Services existants hétérogènes Besoin d'un outil unique de groupware
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Les objectifs 1/2 Les fonctionnalités souhaitées Calendrier partagé partage et délégation des calendriers invitation, Freebusy interface web Carnet d'adresses carnet d'adresses personnel carnet d'adresses global interface web
Les objectifs 2/2 Mobilité synchronisation client mobile (iphone) synchronisation client lourd multi-plateforme webmail Contraintes supporter 100 000 comptes commune aux étudiants, enseignants chercheurs et personnels haute disponibilité respecter les standards s'intégrer à l'architecture de messagerie Osiris / annuaire être accessible depuis l 'ENT Support de CAS
Comparatif groupware Darwin Calendar Server Zimbra Exchange OBM SOGo Calendrier Carnet d'adresse NON Webmail NON Client lourd? Respect standards NON? Haute disponibilité?? Intégration à l'existant NON NON NON Support CAS NON? NON? Extensibilité??
La solution retenue 1/3 SOGo Solution libre de groupware soutenue par la société Inverse Agenda et carnet d'adresses partagés, webmail Intégration simple à l'architecture de messagerie Osiris et d'annuaire Architecture permettant le passage à l'échelle Intégration possible dans l'ent
La solution retenue 2/3 SOGo Client léger web Synchronisation avec les clients lourds compatibles CalDAV Synchronisation avec Thunderbird grâce aux plugins SOGo Synchronisation avec les mobiles iphone CalDAV autres possibilité d'installer un serveur Funambol
La solution retenue 3/3 SOGo : une architecture modulaire
SOGo en quelques dates 01/2009 : début du projet 02/2009 : tests de différentes solutions 05/2009 : choix de SOGo 02/2010 : déploiement des serveurs SOGo 06/2010 : mise en production 09/2010 : ouverture du service aux étudiants 09/2011 : fusion des webmails 11/2011 : migration Exchange
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Implantation Physique Load-Balancer (Actif) Load-Balancer (Passif) OpenBSD PF Relayd CARP OpenBSD PF Relayd CARP Backend Backend SOGo SOGo Ubuntu Ubuntu Apache Apache sogod sogod LDAP Ubuntu OpenLDAP Memcache (Actif) Ubuntu memcached repcached BDD (Actif) Ubuntu PostgreSQL DRDB Pacemaker Serveur de VMs Backend Backend SOGo SOGo Ubuntu Ubuntu Apache Apache sogod sogod Memcache (Passif) Ubuntu memcached repcached BDD (Passif) LDAP Ubuntu PostgreSQL Ubuntu DRDB OpenLDAP Pacemaker Serveur de VMs
Infrastructure SOGo 2 load balancers mutualisés 2 serveurs de VMs 4 VMs pour les Backends SOGo 2 VMs pour les bases de données 2 VMs pour Memcached 2 VMs pour les réplicats LDAP
Architecture système agenda.unistra.fr agenda-cas.unistra.fr OpenBSD PF Relayd VM SOGo VM LDAP VM MEM MASTER Linux KVM PFSync VM SOGo VM BDD MASTER OpenBSD PF Relayd VM SOGo synchro DRDB + pacemaker synchro repcached VM SOGo VM BDD SLAVE VM MEM SLAVE Linux KVM VM LDAP
Mise en production Trois infrastructures Test test rapide des nouvelles versions et fonctionnalités permet de valider la création du modèle de VM SOGo Pré-production copie de l'architecture de la plateforme de production valide le déploiement du nouveau modèle de VM SOGo Production plateforme en production bascule entre 2 pools de VMs SOGo lors d'une mise à jour
Haute Disponibilité 1/3 Redondance et équilibrage de charge Matérielle : 2 serveurs redondés Géographique : 2 sites distants Logicielle : Load balancer CARP + Relayd + PFSync SOGo équilibrage Round Robin Mémoire Partagée équilibrage Actif/Passif BDD : PostgreSQL + DRDB + Pacemaker Mémoire Partagée : Synchronisation applicative Repcached
Haute Disponibilité 2/3 Pourquoi faire des VMs Evolution commune à tous les services de l'université Souplesse d administration, de tests et de déploiement Indépendance vis à vis des problèmes matériels Répartition de la charge plus fine Passage à l'échelle en rajoutant des VMs Pourquoi faire du load balancing niveau 3 Rationalisation des méthodes de load balancing
Haute Disponibilité 3/3 4 serveurs physiques 2 load balancers 1x Intel Xeon CPU X5550 @ 2,67GHZ (4 cœurs) 4 Go de RAM 2x 146 Go RAID 1 2 serveurs de virtualisation 2x Intel Xeon CPU X5550 @ 2,67GHZ (4 cœurs) 24 Go de RAM 7x 146 Go RAID 6
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Retour d'utilisation Web Quelques problèmes d'encodage Problèmes de frames Popups CAS dans l'ent Interface intuitive, proche de Thunderbird Peu de problèmes en réalité Bugs régulièrement corrigés avec les mises à jour
Retour d'utilisation Client Lourd Thunderbird + extensions SOGo Inverse d'abord support de Thunderbird 2 puis de Thunderbird 3 intégration complète des fonctionnalités de SOGo Web problèmes de stabilités liées aux évolutions de Thunderbird ical agenda uniquement bonne synchronisation pas de complétion des adresses emails pour les invitations Autres : Korganizer, Evolution quelques retours utilisateurs positifs
Retour d'utilisation Smartphones iphone application Calendrier support natif du standard CalDAV (Calendrier) application Contacts support de CardDAV en test (Contacts) Android pas de support natif de CalDAV Possibilité d'utiliser Funambol : non testé
Retour d'utilisation Expérience utilisateur Interface web facile à prendre en main pour les nouveaux utilisateurs Complexité des partages de ressources (calendriers, carnets d'adresses) création d'une documentation en ligne Difficulté d'utilisation pour les usagers du calendrier Outlook + Exchange Globalement, les gens sont satisfaits du service réelle attente de la fonctionnalité d'agenda partagé
Retour d'utilisation Quelques chiffres Nombre d'utilisateurs différents ayant utilisé le service 20 000 Nombre d'utilisateurs journaliers 3 000 1500 via l'ent (CAS) 1500 hors ENT (Web + clients lourds + smartphones) Le service est ouvert à tous les établissements Osiris (UdS, INSA, CROUS, Archi, BNUS,...)
Quelques captures d'écrans
Quelques captures d'écrans
Quelques captures d'écrans
Quelques captures d'écrans
Quelques captures d'écrans
Quelques captures d'écrans
Quelques captures d'écrans
Quelques captures d'écrans
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Retour d'exploitation SOGo est dépendant des services associés LDAP IMAP BDD Une défaillance d'un des services provoque des lenteurs rendant le service inutilisable
Retour d'exploitation Architecture (Test/Pré-Production/Production) Inconvénients création d'un modèle de VM SOGo pour chaque mise à jour déploiements des VMs clones du modèle MAJ des configurations sur toutes les VMs SOGo Avantages retour en arrière rapide possible test de pré-production simplifié passage à l échelle facilité : clonage d'une nouvelle VM à partir du modèle
Retour d'exploitation Évolutions Utilisation d'un outil de gestion de configuration Puppet, CFEngine Création d'outils pour automatiser les opérations courantes sur les ressources restauration/nettoyage des calendriers
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Migration 2 migrations différentes Webmails Exchange La migration des webmails impacte tous les usagers (environ 80 000) La migration Exchange impacte une minorité d'usagers (environ 700)
Migrations des webmails Contexte Suite à la fusion des universités et de l'iufm héritage de 5 webmails différents Horde Roundcube SquirrelMail Vdesk (SquirrelMail) OWA Nécessité d'harmoniser simplification d'exploitation support utilisateur simplifié
Migrations des webmails Plan de migration Plan de communication Ouverture d'une interface web de migration l'utilisateur choisit les ressources à migrer Deadline pour la rentrée septembre 2011 extinction des anciens webmails
Migrations des webmails Difficultés de la migration Export/Import des données carnets d'adresses calendriers pour certains 5 webmails vers SOGo = 5 outils différents à développer
Migration Exchange Contexte Suite à la fusion des universités et de l'iufm héritage d'un serveur Exchange 700 comptes service de messagerie Osiris 80 000 comptes Nécessité d'harmoniser la messagerie vers un seul système commun pour tous les comptes simplification d'exploitation support utilisateur simplifié
Migration Exchange Plan de migration Plan de communication Migration des comptes Exchange en masse Deadline novembre 2011
Migration Exchange Difficultés de la migration Export/Import des données emails agendas carnets d'adresses Conservation du client lourd Outlook habitudes archives des emails déploiement du connecteur OpenChange pour SOGo
Plan Objectifs Architecture du service Retour d'utilisation Retour d'exploitation Migration Bilan
Bilan du projet : investissements Plus de 200 jours homme à l'uds Sponsoring chez Inverse de plusieurs fonctionnalités CAS Drag'n'Drop dans l'interface Web CardDAV Différenciation des événements (publics, privés, confidentiels) Plugins Thunderbird 3.1 Amélioration de l'ergonomie du webmail OpenChange
Bilan par rapport aux objectifs initiaux 1/2 Fournir un service de groupware aux usagers d'osiris OK La solution retenue doit Supporter 100 000 comptes OK Haute disponibilité OK Respecter les standards OK S'intégrer à l'architecture de messagerie Osiris / annuaire OK Être accessible depuis l 'ENT OK Webmail OK
Bilan par rapport aux objectifs initiaux 2/2 Calendrier partagé Partage et délégation des calendriers OK Invitation, Freebusy OK Interface web OK Carnet d'adresses Carnet d'adresses personnel OK Carnet d'adresses global OK Interface web OK Synchronisation client mobile (iphone) OK Synchronisation client lourd multi-plateforme OK
Conclusion Objectifs atteints Intégration à l'architecture de messagerie réussie Fonctionnalité calendrier partagé attendue et appréciée Outil indispensable Moins d'agendas papier, on a sauvé des arbres Encore un long travail de migration