170 Avenue Jean Jaurès, 21000 Dijon

+33 3 73 27 02 86

contact@cadoles.com

Mse

Système & infrastructures

Architecture et infrastructure de la plateforme MSE

Le CNOUS a lancé le 15 janvier 2015 un portail d’accès unique à tous les services des œuvres universitaires à destination des étudiants, la plateforme MSE.

Ce service supporte aujourd’hui 5500 connexions simultanées et ce nombre se vera augmenté sous peu pour atteindre 8000.

L’architecture a été pensé afin de permettre à la plateforme MSE une forte résilience, pour qu’elle puisse fonctionner en cas de panne d’une partie des équipements, d’incident intentionnel ou non ou de sollicitation extrême. Cette résilience est assurée par la séparation des machines et des services en sous entités cohérentes.

L’architecture est basée sur le principe de la séparation des activités, à savoir 3 activités principales :

  • Le « portail » à destination des étudiants et des administrateurs (FrontOffice et BackOffice) ;
  • Les services web à destination des partenaires (AGLAE, ParcoursSup, CitéU…);
  • Le fournisseur d’identité utilisé par les utilisateurs et certains partenaires.

Ces activités créent et utilisent des données, qui sont distribuées sur 3 ressources différentes :

  • une base de données (cluster Galera MariaDB) ;
  • un annuaire LDAP ;
  • un espace de stockage NFS (DRBD).

L’infrastructure globale de production dispose de 2 plateformes MSE complètes.

Chacune des 2 entités dispose donc de tous les services nécessaires pour faire fonctionner la plateforme MSE. Si l’une des entités subit une panne ou un arrêt de service l’autre est capable de fournir le service malgré tout. Cette répartition permet de disposer d’un système adaptatif capable d’absorber des dysfonctionnements d’une des 2 entités jusqu’au retour à un état stable.

Des répartiteurs de charge HAProxy peuvent distribuer la charge sur l’une ou l’autre des entités ce qui permet de couvrir les demandes en période de forte affluence. Des serveurs Redis accueillent le cache des sessions ainsi que le cache doctrine. La grappe LDAP est constituée de 2 nœuds actif/actif pouvant fonctionner indépendamment. Chaque nœud a donc la capacité d’enregistrer et de servir des données de l’annuaire. Certains services ne nécessitant pas de machine physique sont hébergés dans un cluster OpenNebula installé en mode haute disponibilité avec une grappe GlusterFS actif/actif, ce qui fait que chaque nœud à la capacité d’écrire sur le FileSystem partagé. Les comptes utilisateurs sont créés via les mécaniques de playbook d’Ansible.

Nous utilisons l’outil Prometheus pour collecter et archiver les statistiques. Grafana est utilisé pour la mise en forme des statistiques sous forme de tableau de bord. Afin de simplifier la surveillance, nous pouvons surveiller la PROD et la PréPROD depuis une même interface en un simple clic. En plus des graphiques disponibles depuis l’interface de Grafana, des alertes mails ont été mises en place afin de recevoir directement les dysfonctionnements via l’outil « AlertManager ». Le module Zéphir propose une solution normalisée pour faciliter le déploiement, la surveillance et la maintenance des modules EOLE utilisés dans cette infrasctrure. Nous disposons d’une centralisation des configurations de tous les serveurs et de certains fichiers personnalisés que nous pouvons déployer de manière automatique en temps réel ou de manière différée. Tous les journaux importants de tous les serveurs physiques et virtuels sont remontés automatiquement sur un serveur de supervision.