Nous partirons le mardi 13H30 pour l'OMP pour le bon déroulement du TP:

• Regroupement des TP IDS le mardi après-midi et déplacement sur le campus à l'OMP pour disposer de plusieurs lignes 100 Mb
• Réservation de 2 grandes salles : Lyot et jules Vernes
• Travail en binôme : 30 connections
• Limitation des connections si besoins (OMP non prioritaires ou en trinôme)
• Vérification de la partie serveur:
  • serveur IDS INRA (Alain
  • serveur IDS CESBIO (Jérôme)
  • autres serveurs de geobretagne (Hervé)
  • (mise en place d'un géoserver localement à l'observatoire?)
• Préparation de TP avec des données légères et distribuées sur plusieurs serveurs.

TODO:

• (Roderic) Préparation du cas d'étude et du jeux de données initial et des jeux de données des étapes intermédiaires pour servir de point de reprise aux personnes en retard (IDS source)
• (Roderic, Hervé) Préparation du tranferts des données, des flux.
• Préparation des IDS
  • (Alain) INRA: transfert des données/flux, ouverture des comptes
  • laurent.drapeau gmail.com (Jerome) CESBIO: transfert des données/flux, ouverture des comptes, donner des accès à Roderic et Hervé
  • (Hervé) D'autres IDS en Bretagne de dispo?
• (Elodie Bourrec, Cedric Hillenbrand OMP) :Vérification du réseau dans les salles. Ils faut Il faut s'assurer de
  1. l'ouverture des bons ports pour:
  2. d'une bande passante suffisante: si nous partons sur 30 connections, il faudrait 10 MB par connection donc du 3 à 4 100Mb en FILAIRE!

contact: Alain Bénard, Nathalie

après accord des collègues gérant l'infrastructure physique nous avons reconfiguré l'IDS de test en partie sur les conseils, estimations et pistes que Fabrice a fourni. Voici donc comment sont répartis les services :

  Authentification ldap : serveur debian 7 sur Orléans dédié avec 1 vcpu, 2Go de mémoire et 3 disques (20 Go pour le système / 2 Go pour le swap et 10 Go pour les données  [annuaire ldap]
  Base de données postgresql : serveur centos 6 sur Nancy (serveur utilisé en production pour d'autres bases de données et hébergeant la base nécessaire à Geonetwork) - 8Go de Ram
  Serveur portail : serveur debian 7 sur orléans dédié avec 4 vcpu, 14 Go de mémoire et 3 disques (20 Go pour le système / 14 Go pour le swap [6 réellement configuré pour le swap] / 50 Go pour les données). Les applications hébergées sur ce serveur sont réparties au sein de 2 tomcat :
      Tomcat 1 : Mapfishapp (visualiseur), Security Proxy (redirection) , CAS (authentification) et éléments statiques. Ce tomcat dispose de 8 Go de mémoire pour faire tourner ces applications.
      Tomcat2 : Geonetwork uniquement. Ce tomcat dispose de 4 Go de mémoire pour faire tourner cette application.
  Serveur de carte : serveur debian 7 sur Orléans dédié avec 4 vcpu, 16 Go de mémoire et 3 disques (20 Go pour le système / 16 Go pour le swap [6 réellement configuré pour le swap] / 50 Go pour les données [c'est cet espace qui sera utilisé pour les données utilisateurs notamment des shapefile à déposer en Webdav, le webdav étant assuré par le logiciel apache du serveur portail et un lien nfs entre les 2 serveurs). Ce serveur fait tourner 4 tomcat avec chacun une seule application (en dehors des outils d'administration tomcat) geoserver. L'équilibrage de charge se fait via nginx. Les tomcat sont configurés de la façon suivante :
      tomcat 1 : geoserver avec 4 Go de mémoire.
      tomcat 2 : geoserver avec 4 Go de mémoire.
      tomcat 3 : geoserver avec 4 Go de mémoire.
      tomcat 4 : geoserver avec 3 Go de mémoire.

La configuration a donc été sérieusement musclée mais je ne sais comment mener des tests de montée en charge (Fabrice ou Hervé ou autre avez-vous une idée la dessus). Les comptes seront créés dès demain après-midi avec une authentification basée sur le ldap institutionnel INRA pour les agents INRA et un mot de passe initialisé à une valeur fixe pour les autres. Si une version plus à jour du fichier existe n'hésite pas à me la fournir.

La formation sera démarrée dans 2 semaines et nous n'avons jusqu'ici aucun scénario de défini par les personnes chargées de créer les scénarios. Il devient maintenant urgent de nous fournir les données et métadonnées que nous devons insérer dans l'IDS. (shapefile / fiche geonetwork …) et jouer au moins une fois le scénario des tp.

Nous créons donc les comptes demain et restons en attente des données de base à insérer; je pense qu'à ce stade nous serons ok avec les todo du wiki.

Salut Pascal,

Nous pouvons avoir plusieurs IDS “en ecriture” et y répartir les clients.
N'en avez-vous pas sous la main si vous faites des formations?

Oui, pas forcément des IDS mais plutôt des Geoservers

Dans quelle mesure une IDS peut etre répartie? N'est-il pas possible
d'installer un ou des geoserver localement ou regionalement sur un serveur musclé puisque c'est le gros consommateur de bande reseau et CPU serveur?

C'est l'idée

Avez-vous eu des identifiants pour l'IDS de l'INRA de la part d'Alain?

Moi oui, Fabrice et Rod demain normalement

Bonjour,

il y a 60 demandes d'inscriptions.
Nous partirions sur 15 connections.

Dixit Fabrice : “Ca peut passer avec : 4 geoserver, 8 cores, 8 Go RAM
dédiés. Ainsi on résiste bien mieux car un plantage geoserver n'est pas
ressenti.”

Nous pouvons avoir plusieurs IDS “en ecriture” et y répartir les clients.
N'en avez-vous pas sous la main si vous faites des formations?

ids.georchestra.org peut-il etre utilisé?

… sdi.georchestra.org

franchement non car 1/ ce n'est pas une pf de production mais de démo 2/ il y a peu de données dessus

Ceci dit ça peut faire l'appoint pour de la donnée légère, ou pour le visualiseur qui est en dernière génération (avec la possibilité d'éditer des couches directement depuis l'interface)

Dans quelle mesure une IDS peut etre répartie? N'est-il pas possible
d'installer un ou des geoserver localement ou regionalement sur un
serveur musclé puisque c'est le gros consommateur de bande reseau et CPU
serveur?

Si, naturellement une SDI est répartie puisque les flux sont souhaités au plus près des producteurs.

Cependant le coût d'un flux implique de la mutualisation, et dans les faits, sur 100 partenaires GéoBretagne, seuls 4 ont les moyens de publier des flux ⇒ gèrent leurs propres serveurs.

Le fait de répartir les flux n'affranchit pas d'adopter un niveau de service commun minimum, et c'est bien sur ce deuxième point que l'exercice est délicat.

Le scénario qui me paraît le plus raisonnable est de conserver les machines virtuelles actuelles en essayant de les upgrader (mémoire, cpu, nombre de tomcat) à un niveau qui réponde à la charge. Nous sommes toutefois partenaire d'une infrastructure sur laquelle je ne suis pas seul décisionnaire mais la période me paraît toutefois propice à gonfler provisoirement certaines machines virtuelles, de nouvelles machines physiques venant de compléter l'infrastructure et la plein charge n'étant donc pas atteinte. Bonne journée. Alain.

Le 17/04/2014 13:02, Pascal Dayre a écrit :

Bonjour Alain,

je suis en train de regarder l'aspect TP de la formation.at

L'idée du TP est de récupérer des données d'un certain nombres d'IDS,
de faire un traitement sur son client et de sauvegarder le résultat sur votre bac à sable.
Par la suite, les gens consultent ces données chargées pour les valider et les utiliser
puis les lier à une page web.

Voici ma perception :

  La partie traitement / client ne charge pas notre IDS (sauf pour les clients qui téléchargeront des données à partir de notre IDS mais ton scénario répartit les groupes vers diverses IDS).
  La sauvegarde sur le bac à sable implique :
      recopie d'un ou plusieurs fichiers shapefile sur la structure disque du geoserver (je ne vois pas d'autres formats excepté pour des fichiers raster que nous n'avons jamais testés à ce stade). Il ne s'agit que d'une recopie fichier que le serveur Apache / Webdav peut accepter sans problème même avec 15 utilisateurs. Si les fichiers sont volumineux le transfert sera peut-être long. (Il nous faudra avoir une idée sur la volumétrie)
      déclaration d'une carte avec un utilisateur de l'IDS habilité (on créera 15 comptes génériques mais il faudra nous fournir des adresses mails si on utilise l'extracteur). Est-ce vraiment une charge? Probablement pas très lourd.-
      création d'une fiche de métadonnée en lien avec la carte. Ici encore la charge n'est probablement pas très élevée. Fabrice a peut-être une idée de la charge mémoire/cpu d'un utilisateur de geoserver ou genonetwork sur des tâches administratives (pas de getmap)?
  La consultation / téléchargement / utilisation va quant à elle charger l'IDS car il faut que geoserver fabrique les cartes et les adresse aux clients. (idem pour le lien depuis une page web). Les informations fournies par Fabrice en bas de cet échange prennent alors tout leur sens.

Nous partons sur 60 personnes organisées en 15 groupes.

La question est de savoir quel serait la reaction de votre bac a sable:
- quelle est votre scénario de test, de validation de votre IDS. Qu'avez-vous fait ou comptez-vous faire d'ici la formation?

  Pour l'instant nous sommes sur de la démonstration de principe et nos tests se sont limités à valider l'installation et les fonctionnalités de base (ce qui n'est pas si évident même si les applis sont déployées apparemment sans erreur) :
          validation de la visualisation d'une couche
          validation du lien entre une fiche de métadonnée (geonetwork) et une carte (geoserver)
          validation de l'authentification.
          validation de l'extraction.
          nous avons aussi perdu beaucoup de temps à essayer de faire marcher tout l'ensemble en https et avons fait machine arrière (ce qui explique que l'URL en https ne marche plus). Aujourd'hui tout est en http ce qui n'est pas pleinement satisfaisant mais c'est comme ça et pour du bas à sable ou formation c'est suffisant.
          Nous devons valider que l'extracteur ne fonctionne plus du tout si certaines couches sont en accès protégé (info de collègues sur la liste de diffusion).
          D'ici la formation on souhaite jouer un peu sur l'apparence (stylage) des couches et peut-être explorer des rasters.

- Idem pour la montée en charge

  Rien à ce stade mais nous sommes preneur d'idées / scénario / outils D'autres sont-ils passés par là?? Cette étape pourrait être valorisée et venir compléter la map documentaire à laquelle nous vous avons donné récemment accès. Nous avons besoin d'éclairage / aide pour effectuer des tests de montée en charge et nous pourrons faire un retour sur cette phase.

- quelles sont les ressources physiques allouées aux machines virtuelles

  A ce stade le bac à sable est dans l'état décrit sur la map (tout en virtuel sur des solutions VMWARE Vsphere):
          Un serveur ldap dédié (centos 6) (1 vcpu, 2Go Ram et 10 Go pour la base ldap)
          Les bases de données (postgresql) sur un serveur spécifique postgresql (9.2) centos 6 (à Nancy) : 8 Go de RAM
          Un serveur portail Debian 7 (1 vcpu, 6 Go ram, 50 Go pour les data )
              1 tomcat 6 (ça ne fonctionne pas en 7) pour les applications CAS, Security Proxy et le visualiseur Mapfishapp
              1 tomcat dédié géonetwork
          Un serveur carto Debian 7 (1 vcpu, 6 Go ram, 50 Go pour les data )
              1 tomcat 6 pour les applications geoserver et l'extracteur.

  Il est probablement possible de jouer sur le nombre de tomcat ou le dimensionnement mémoire/disque/cpu des VM sans trop de difficultés.

D'apres Fabrice:
“Ca peut passer avec : 4 geoserver, 8 cores, 8 Go RAM dédiés. Ainsi on résiste bien mieux car un plantage geoserver n'est pas ressenti. ”

  Excuse mon ignorance mais s'agit-il bien de 4 geoserver ou de 4 tomcat ou les 2. Je ne vois pas comment configurer 4 geoserver adossés à l'IDS mais nous avons encore des choses à apprendre! Je viens de poser la question à Fabrice en parallèle.

Serait-il possible de muscler votre plateforme ou de deployer une autre plateforme?

  Comme indiqué plus haut on peut faire certains aménagement plus ou moins facilement : le bac à sable est hébergé sur le centre d'Orléans où nous ne maîtrisons pas l'adressage IP, le DNS, la sécurité... Le responsable de l'informatique de centre étant parti je ne connais pas le délai d'intervention sur certains items mais je vais me renseigner. Je pense qu'on devrait pouvoir tourner avec la configuration de 2 serveurs applicatifs (moyennant peut-être un redimensionnement mémoire / nb cpu??) : il serait dommage qu'on n'arrive pas à faire tourner 6 applications sur 2 machines pour 15 utilisateurs.

⇒ rajouter des geoservers qui peuvent etre deployé n'importe ou? y-a-t-il des contraintes d'authentification ldap?

  On peut rajouter des geoservers mais ils ne seront pas liés au bac à sable pour ce qui est de l'authentification unique ou alors il y a des possibilités que j'ignore.

Par clonage des MVs? Par deployement complet?

  Le déploiement de georchestra préconfigure un tas de variables et le clonage et renommage de machine qui suit généralement va poser souci. Si on en arrive là mieux vaut redéployer sur des machines préparées (la on peut cloner au niveau de la prépa : VM avec Debian 7 / Tomcat 6 par exemple)

Le point payant est la plateforme VMware:

  Je ne comprend pas la phrase ci-dessus

Dans quelle mesure ca peut se faire? A l'INRA d'Auzeville (il y a 2 inscrits à la formation qui ont des projets d'installation de la plateforme) ou autre INRA?
A l'ENSEEIHT (ecole polytechnique toulouse) si on vous fournit les MV?

on peut installer selon la map documentaire et on peut fournir certaines maquettes de VM. Ce sera toutefois difficiile pour des non initiés qu'on peut cependant aider.

Quelles sont les caracteristiques des MVs? OS? capacite disk et RAM et processeur?

  Voir ci-dessus ou map documentaire.

Pour info, je n'ai rien a l'adresse suivante:
https://ids-bas-portail.orleans.inra.fr/mapfishapp

Oui on a désactivé https

Dois-je obtenir la meme chose que:
http://sdi.georchestra.org/

  Oui c'est exactement ça.

Pascal


PS: avez-vous communiqué des identifiants aux 3 bretons afin qu'ils fassent leur test

Ca vient d'être fait


PS: la page de test pour le reseau et les TPs
http://devlog.cnrs.fr/ids2014_reseaunailloux

Estimation de la connexion

Information de fabrice:

débits montants et descendants d'un client d'un IDS.

Avec les écrans d'aujourd'hui le visualiseur va charger env. 8 Mo la première fois et 4 Mo les fois suivantes avec le cache.

Ensuite c'est bien sûr proportionnel au nb de couches mais pas tant que cela car il y a en général une seule couche raster/opaque et du vecteur léger au-dessus.

⇒ 32 mbps pour 1 seconde, 3.2 pour 10 secondes

le multiplexage entre clients peut laisser passer beaucoup de monde en consultation simple; mais en formation, il nous arrive de saturer les anti-DDOS !

En tout cas, 40 personnes qui surfent en même temps saturerait un 100bT.

le serveur, le goulot d'etranglement? Combien de clients simultanés pour un serveur?

En situation intensive, 1 geoserver = 30 getmap = 4 clients
⇒ 40 personnes intensives = 10 geoserver
⇒ 15 clients = 4 geoserver

Si nous faisons travailler les gens par 4, cela ferait 10-12 connexions simultanées.

Ca peut passer avec 2 geoserver, 4 cores, 4 Go RAM dédiés. Ainsi on résiste bien mieux car un plantage geoserver n'est pas ressenti.

Supprimer tout gros raster qui ne serait pas pyramidé sinon effondrement garanti.