DOSSIER DES PRÉCONISATIONS TECHNIQUES

DOSSIER DES PRÉCONISATIONS TECHNIQUES DOCUMENT DOSSIER DES PRÉCONISATIONS TECHNIQUES VERSION DERNIER ÉDITEUR YANNICK LOUVET DATE DE MISE À JOUR 26 MAI 2011 ÉTAT DOCUMENT DE TRAVAIL

Version modifications 1.4 Ajout du présent mécanisme de suivi des version Ajout du chapitre Flux et volumétrie associée Modification de la volumétrie dans le chapitre Préconisations matérielles Ajout de la contrainte sur le débit serveur cartographique (1.4.4) Ajout du 1.2.3 concernant les services cartographiques Modification du chapitre 1.3.4 relatif aux contraintes navigateur. Modification du chapitre 2.3 concernant l'usage d'un serveur SMTP Modification du chapitre 2.1 concernant la sécurisation du fichier plat Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 2 sur 18

TABLE DES MATIÈRES 1 Volet technique...4 1.1 Architecture fonctionnelle...4 1.2 Architecture physique...4 1.2.1 Environnement de production...4 1.2.2 Environnement de test...7 1.2.3 Cas des services cartographiques...7 1.3 Flux et volumétrie associée...8 1.3.1 Présentation...8 1.3.2 Dimensionnement stockage...10 1.3.3 Estimation des échanges...10 1.3.4 Dimensionnement des ressources systèmes...11 1.4 Préconisations matérielles...11 1.4.1 Dimensionnement des serveurs...11 1.4.2 Système d'exploitation...11 1.4.3 Volumétrie...12 1.4.4 Débits réseau...12 2 Volet Intégration...12 2.1 Authentification...12 2.2 Système d'informations géographiques...13 2.3 Serveur de messagerie...14 2.4 Personnalisation de la charte graphique...14 3 Volet Exploitation...14 3.1 Phase d'installation...14 3.2 Phase d'exploitation...15 3.2.1 Tâches d'exploitation...15 3.2.2 Niveau de sécurité...15 3.3 Documentation livrée...15 3.4 Compétences...16 3.4.1 Phase d'installation...16 3.4.2 Phase d'exploitation...17 3.5 Hébergement externe...17 Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 3 sur 18

1 VOLET TECHNIQUE 1.1 Architecture fonctionnelle Fonctionnellement, l'application Gertrude se compose de deux grands modules fonctionnels distincts autour des Dossiers Électroniques : un module du Production et un module de Diffusion/Publication. Les usages et la population ciblée n'étant pas les mêmes, ces deux modules tourneront sur deux environnements d'exécution distincts (même si, au niveau de l'architecture logicielle et du développement, ils s'appuieront sur des composants largement communs). La population d'utilisateurs comprenant des personnes qui ne sont pas agent des Régions (partenaires authentifiés pour le module Production et potentiellement tout le grand public en mode non authentifié pour le module de Diffusion/Publication), ces deux modules doivent être accessibles depuis l'internet (donc en DMZ, selon la topologie des zones de sécurité en vigueur dans chaque Région). La préconisation technique définie dans le paragraphe suivant est à traduire, par chaque Région dans son contexte propre, pour la mise en place d'une plate-forme de virtualisation équivalente. 1.2 Architecture physique Cet environnement est constitué d'une application de production des dossiers d'une application de diffusion grand public dans certains cas d'un service de cartographie (cf 1.2.3) 1.2.1 Environnement de production Cet environnement est constitué d'une application de production des dossiers d'une application de diffusion grand public Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 4 sur 18

Sur chaque serveur, plusieurs couches logicielles seront installées : une couche serveur d application (Container Java) une couche serveur de Données (SGBD Orienté Document) une couche serveur cartographique Java dans le cas où la région ne possédent pas un serveur capable de fournir du WMS et/ou WFS Ces deux applications peuvent être hébergées soit sur deux serveurs, soit sur un seul serveur. A noter que dans tous les cas il s'agit de serveur dédié. Le diagramme suivant illustre la décomposition de l'environnement Illustration 1: Architecture bi serveur Dans le cas du mono serveur ce sont les mêmes procédures d'installations et la même typologie de fonctionnement reporté sur un seul serveur. Cette configuration, mono-serveur, peut être utilisée dans un premier temps lors de la montée en Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 5 sur 18

charge de la production. Ce n'est pas une solution pérenne, les fonctionnements en production et en diffusion sont intriqués et peuvent se pénaliser mutuellement : un fort trafic sur le site de diffusion va vraisemblablement causer des ralentissements côté production des opérations métiers couteuses (recherche massive, remplacement de texte et /ou corrections sur une liste de dossier) vont impacter les performances du site de diffusion Illustration 2: Architecture mono serveur Chaque serveur devra être autonome en terme d'accès : Accès externe HTTP sur le port 80 Accès externe HTTPS sur le port 443 Tous les autres ports étant en accès localhost Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 6 sur 18

Système de fichier : l'application utilise de nombreuses ressources de type fichier (images, documents pdf ) Dans tous les cas, les serveurs devront être accessibles depuis le réseau interne comme depuis l extérieur. Les moteurs de base de données, quant à eux n'étant accédés directement que par l application elle-même. Gertrude ne possède pas de contrainte propre à la virtualisation. Seule la contrainte de performance doit être examinée en regard d'une virtualisation. La préconisation technique définie dans le paragraphe suivant sera donc à traduire pour la mise en place d'une plate-forme de virtualisation équivalente. NB : Des architectures plus largement réparties seront possibles. Toutefois, pour le déploiement de la v1 de l'application, seules les architectures décrites ci-dessus seront prévues et donneront lieu à assistance, pour un contexte de déploiement plus homogène entre Régions, facilitant le déploiement. 1.2.2 Environnement de test L' environnement de tests est mono serveur et n'est pas soumis au contrainte de performances de l'environnement de production. D'autres environnements seront peut-être nécessaires (formation, à déterminer ultérieurement), ou en fonction de la politique interne de chaque DSI (pré-production ). Une procédure standard permet de reproduire l'installation de Gertrude. 1.2.3 Cas des services cartographiques Le choix de l'interopérabilité permet de connecter à Gertrude des services web cartographique WMS et WFS, format issus de l'ogc. Pour les régions deux cas de figures se dessinent : la région possède un serveur cartographique OGC et elle décide d'y connecter Gertrude la région ne possède pas un tel serveur et dans ce cas une installation d'un Geoserver sur le serveur de production permet d'assurer un tel service. Dans tous les cas les services d'accès aux référentiels cartographiques doivent être accessibles Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 7 sur 18

pour l'application de diffusion ainsi que pour l'application de production en prévoyant des échanges de données importants (flux 1 et 2 du chapitre 1.3.1) 1.3 Flux et volumétrie associée 1.3.1 Présentation Le diagramme suivant illustre les flux entre les différents composants du projet : Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 8 sur 18

1 et 2 : flux WMS et WFS entre les applications web consultation et diffusion et les services cartographiques 3 : flux de données au format JSON 4 : ressources web : illustration et données cartographiques, feuilles de styles, javascript 5 : flux html 6 : ressources web : illustration et données cartographiques 7 : export fichier xml vers une zone de staging 8 : import fichier xml depuis une zone de staging : la production ne partage pas forcément la zone de staging de la diffusion. Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 9 sur 18

1.3.2 Dimensionnement stockage Le système nécessite 200 Go pour son fonctionnement : OS, sauvegarde, application et entrepôt de donnée sans illustrations. La variable du dimensionnement est le nombre d'illustrations. En terme de stockage on a 4 fichiers pour une illustration :V, P,format supérieur et format vecteur. En moyenne une photo jpeg 2000*3000 à la sortie d'un appareil numérique pèse 2,15 Mo En 800*600 : 250 Ko En vignette de 192*128 : 60 Ko Pour 100 000 illustrations nous obtenons donc les tailles «macro» suivantes : format vignette : 5Go format plein écran : 24 Go *2 pour la prise en compte du format vecteur, soit 50 Go format supérieur : 210 Go Soit un total de 265 Go. A ceci on ajoute le facteur de stockage, 15%, qui permet de prendre en compte la différence entre la taille absolue et la taille en stockage (soit 40 Go) et un facteur d'incertitude de 10 % sur les postulats de taille initiaux (soit 30 Go). On obtient alors pour la taille totale des illustrations de 265 + 40 + 30 = 335 Go, soit une capacité serveur de 535 Go 1.3.3 Estimation des échanges L'application de production est une application purement javascript, la page est chargée une première fois puis des flux sont échangés avec le serveur pour fournir telle ou telle fonction. Les éléments consommateurs de flux sont principalement les images : pour les illustrations et pour la partie cartographie. La taille de ces flux n'est pas mesurable à priori mais à titre d'exemple une application cartographique standard, comme le sera Gertrude, utilise 2Mo d'échange pour le «chargement d'une page». A cette taille il faut ajouter les illustrations avec les éléments de réponse fournis plus haut. Les échanges de données entre les serveurs sont de deux types : entre les serveurs de production et de diffusion et le navigateur du client (flux 3,4,5 et 6 sur le diagramme ci dessus) Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 10 sur 18

entre le serveur cartographique et les serveurs de diffusion et de production (flux 1 et 2 sur le diagramme ci dessus) Côté diffusion, la technologie mise en œuvre est différente mais les contraintes sont sensiblement les mêmes. 1.3.4 Dimensionnement des ressources systèmes Sur le poste client, l'application tournera intégralement dans le navigateur. Il sera donc nécessaire de disposer d'un poste et d'un navigateur capable de supporter l'usage des applications web récentes, l'application faisant une utilisation intensive de Javascript.. Il est conseillé de disposer de 300 à 500Mo de RAM mobililisable par le navigateur, sur les postes clients, ainsi que d'un processeur relativement récent (moins de 3 ans). Pour fixer les idées, un bon test concerne l'utilisation du Géoportail (www.geoportail.fr) avec une dizaine de couches activées (parcelles, ortho, cartes, ). En v1 de Gertrude, seul FF4 sera supporté. L implémentation de HTML5/CSS3 est en effet encore trop fraîche dans les différents navigateurs, et nous préférons consacrer notre énergie à fournir les bonnes fonctionnalités dans Gertrude qu à batailler pour que tous les navigateurs du moment fonctionnent correctement. En contrepartie, évidemment, la v1 de Gertrude sera maintenue pour fonctionner à 100% sur les lors des mises à jour successives de Firefox 4 qui apparaîtront pendant le déploiement. La prise en compte d autres navigateurs HTML5/CSS3 pourra se faire ultérieurement, après le déploiement total dans les Régions, si leurs implémentations de HTML5 sont devenues stables. Il revient aux DSI des Régions d assurer la présence de FF4 sur les postes clients des utilisateurs de Gertrude, préalablement au déploiement du logiciel. Pour les Régions qui n ont pas déjà FF4 comme navigateur de référence et qui ne souhaitent pas que ce déploiement perturbe quoi que ce soit, il est naturellement possible de ne pas l activer comme navigateur par défaut. La carte graphique du PC ne sera pas sollicitée autrement qu'au travers du navigateur. Ses capacités de calcul 3D ne seront donc pas sollicitées directement par l'application. Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 11 sur 18

1.4 Préconisations matérielles Ces préconisations matérielles permettent de déterminer l'environnement physique optimal. Elles sont par serveur dédié. Dans le cas d'un mono-serveur il n'est pas utile (quand cela est possible) de doubler ces capacités, la montée en charge se faisant par l'ajout d'un nouveau serveur. 1.4.1 Dimensionnement des serveurs Processeur : Intel Xéon double coeur 2,93 Ghz et 8 Mo de mem cache RAM : 16 Go (DDR3) Disque Dur : stockage de base à 300 Go SAS à 15000 T/min, se référer au chapitre dimensionnement. contrôleur RAID 10 (1+0) 1.4.2 Système d'exploitation CentOS 64 bits, comme déterminé par la conférence des DSI fin 2008 L'application sera a priori portable sur d'autres systèmes d'exploitation, compte-tenu de sa conception, mais ce point n'est pas garanti 1.4.3 Volumétrie Disque dur SAS à 15000 T/min avec un châssis de capacité de 2 To. A définir en fonction des besoins des régions,, se référer au chapitre dimensionnement. 1.4.4 Débits réseau débit serveur - navigateur: à partir de 4 Mbit/s et sans limitation sur le nombre de hit/s débit serveur cartographique serveur Gertrude : 1 Gbit recommandé (cf 1.3.3). Cette préconisation n'a rien d'absolu, dans la mesure où la bande passante est fonction du nombre d'utilisateurs simultanés, de l'usage, des ressources manipulées,. Elle identifie les débits pour un fonctionnement optimal de l'application. Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 12 sur 18

2 VOLET INTÉGRATION 2.1 Authentification L'application Gertrude est fournie avec une mire de connexion pour la récupération des identifiants. La validation de ces identifiants peut s'appuyer (possibilités offertes par Jetty) sur un fichier plat 1, une base de données relationnelle, JAAS 2, ou un module personnalisé. JAAS permet de configurer une liste de modules d'authentification (fichier plat, base de données relationnelle, annuaire LDAP) avec différentes configurations de chaînage de ces modules. Il sera donc possible de configurer l'authentification des utilisateurs sur différentes sources, par exemple certains utilisateurs sur l'annuaire de la région et d'autres (les partenaires) dans un fichier plat. Dans le cas où le ou les modules d'authentification configurés, par exemple, l'annuaire LDAP, ne pourrait fournir la liste des rôles à donner à un utilisateur et ne servirait alors qu'à valider les identifiants, Gertrude fournit un module JAAS permettant de configurer (dans un fichier plat) cette association entre les utilisateurs et leurs rôles. Le serveur d'applications pourra également être configuré pour utiliser un mécanisme SSO existant, soit en s'appuyant sur l'api de Jetty, soit sur la norme JASPI (JSR 196 3 ). On remplace ici le mécanisme de récupération des identifiants (et la plupart du temps celui de la validation de ces identifiants, les mécanismes SSO n'envoyant que des jetons aux applications, à revalider auprès du serveur SSO). Ce mécanisme sera testé spécifiquement avec le SSO JASIG CAS qui est le système majoritaire suite à l'enquête menée auprés des CODEP DSI. Moyennant l'intégration du connecteur adéquat, il sera également possible de déléguer l'authentification à d'autres mécanismes (Atlassian Crowd, NTLM/SPNEGO/Kerberos, etc.), voire utiliser une authentification par certificats clients. 1 La sécurisation des données stockées dans le fichier plat s'effectue selon deux axes : les mots de passe peuvent être cryptés (MD5) et le fichier qui doit être lisible par jetty doit posséder une stratégie de modification sécuritaire (droits écriture réduit à root par exemple) 2 http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html 3 http://www.jcp.org/en/jsr/detail?id=196 Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 13 sur 18

Jetty * 1 1 WebApp SecurityHandler LoginService Jetty * LoginModule JAAS 2.2 Système d'informations géographiques Gertrude consomme nativement les services WFS et WMS de la région. Si la région n en possède pas, un module WMF, WFS sera livré (GGS) pour livrer les fonds de carte raster ou vecteur avec les caractéristiques suivantes. Un système de projection unique pour une région (Lambert 93 pour la France métropolitaine). Prise en compte des types de fichier vecteur : SHP, postgis Prise en compte des types de fichier raster : ArcGrid, GeoTiff, Gtopo30, ImageMosaic et WorldImage Si les régions ont déjà des services web de cartographie le serveur GGS n'aura pas d'utilité. Il reste à définir les préconisations de système de projection pour chaque site ultra marin. 2.3 Serveur de messagerie Si besoin de notification, l'application de production doit être en mesure d'envoyer un mail et donc de se connecter au serveur SMTP de messagerie de la région. Toutefois, il n a pas été identifié à l heure actuelle, de "besoin de notification". Pour l heure, il n est donc pas nécessaire de prévoir d activer ce protocole. Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 14 sur 18

2.4 Personnalisation de la charte graphique Une partie des feuilles de style CSS sont «sur qualifiable» par un mécanisme d'héritage permettant aux régions de personnaliser Gertrude sans modifier les fichiers de l'application. 3 VOLET EXPLOITATION 3.1 Phase d'installation L'infrastructure (serveurs et OS) sera réputée opérationnelle avant l'installation de Gertrude. La phase d'installation consiste en la mise en place par ATOL sur la configuration de production choisie par la région : des composants logiciels nécessaires (conteneur Java, SGBD, Serveur cartographique ) des applications Gertrude (production et diffusion) Le paramétrage applicatif s'effectuera dans la foulée de l'installation. Un paramétrage métier par défaut sera livré avec Gertrude. Après sa formation l'administrateur sera en situation de réaliser son paramétrage spécifique (dont une part peut faire partie de la formation) 3.2 Phase d'exploitation 3.2.1 Tâches d'exploitation Un manuel d'exploitation (cf chapitre suivant) précise les informations nécessaires à l'exploitation du système : Points de vérification de l'ordre de marche de la plate-forme Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 15 sur 18

Journaux de log des différents composants Procédures de sauvegarde et identification des fichiers de backup à sauvegarder sur une plate-forme externe (robot, serveur de backup...) Pour chaque version, une notice explicative détaillant les actions à effectuer pour la mise à jour sera livrée. Chaque région aura la charge de mettre à jour sa plate-forme Gertrude. Les procédures d'exploitations industrialisables comme les backup ou les tests d'ordre de marche sont livrées sous forme de scripts exécutables. 3.2.2 Niveau de sécurité L'application de production est soumise à authentification (via un module JAAS ou SSO), celle de diffusion est grand public. Les deux peuvent être externes et donc subir potentiellement des attaques de toutes sortes (DDoS, buffer overflow, spoofing ). La mise en place de SSL, à la charge de chaque Région qui le souhaitera, la surveillance du réseau côté hébergement (stratégie de mises à jour des paquets, alarmes intrusions..) et l'utilisation d'un framework côté développement permet d'apporter un premier niveau de sécurité 3.3 Documentation livrée Le manuel d'exploitation documente les points suivants : l'installation et le paramétrage du container Java l'installation et le paramétrage du stockage des données l'installation et le paramétrage de l'application dédiée à la production des DE l'installation et le paramétrage de l'application dédiée à la consultation des DE exploitation du système : sauvegarde (file system, base de données, index de recherche, ), restauration, Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 16 sur 18

supervision organisation des données : file system, SGBD la procédure de mise à jour de l'application et des composants logiciels utilisés Il explicitera les points de contrôle à effectuer sur l'application et listera les journaux de log utilisés par l'application et ses composants (serveur application, données..) Il n'est pas prévu d'api de supervision dans le développement de Gertrude. Les modalités de réplication de la donnée d un environnement à l autre pour facilement recréer ou rafraîchir un environnement de test ou de formation à partir de l'environnement de production seront également décrites. NB : Le manuel d'exploitation et les scripts seront fait pour CentOS. Toute l'application est à priori portable mais hors périmètre du projet Gertrude. 3.4 Compétences 3.4.1 Phase d'installation Le service informatique possède les compétences pour prendre en charge : l'installation matérielle. l'installation du système d exploitation centos la mise en ordre de marche du/des serveurs dans le contexte d'hébergement du SI 3.4.2 Phase d'exploitation Etre familier de centos et de sa gestion (sauvegarde, taches planifiées, gestion disque, gestion mémoire, surveillance système...) Suivre le manuel d'exploitation pour les procédures de mises à jour et être en situation de comprendre / analyser les éventuels messages d'erreur Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 17 sur 18

L'accès aux données via la base de donnée n'est pas nécessaire voire déconseillé. Un mécanisme d'export XML permet l'accès aux données brutes. Le travail sur ces données nécessite des compétences XML et XSL-T. 3.5 Hébergement externe L'hébergement externe n'est pas initialement identifiée dans le programme fonctionnel. Cependant la solution technique et la documentation livrée permet d'envisager cette typologie d'hébergement, ce document pouvant servir de cahier des charges. La région devra prévoir dans cette typologie l'intégration avec son système d'information. (Annuaire, droits et données SIG). Date création : 09/10/2009 Dossier des préconisations techniques Édition : Date modification : 26/05/2011 Document de travail Page 18 sur 18