Le portail francophone de la géomatique

Bonjour,

On me demande de faire des préconisations de dimensionnement (puissances de calcul, espace disque) des serveurs qui accueilleront le SIG que je mets en place.

Le truc est qu'à cette phase initiale du projet, c'est très difficile de faire une estimation.

Du coup, je me tourne vers vous pour vous demander si vous aviez des préconisations à me faire, histoire de ne pas sous estimer ni sur estimer les besoins.

A ce jour, on utiliserait la solution arcgis serveur
avec 2 administrateurs
5 clients (distant ou non, en simultané) et plus par la suite (jusqu'à 15 utilisateurs)

Je vois 4 ou 5 serveurs :

1 accueillant le SGBD (postgrès SQL), les couches d'infos rasters et vecteurs et le catalogue de données
3 serveurs fournisseurs (1 SOM / 2 SOC)
1 diffuseur

Le tout sur l'intranet, hébergé sur un cluster d'infrastructures virtuels.

Avez vous des retours sur les préconisations de dimensionnement ? Moi là, je sèche...

Merci pour votre intérêt

Dernière modification par Macaron (Thu 16 February 2012 14:13)

Bonjour Franck et merci pour tes éléments de réponse.

Ca me fait penser que je pourrais préparer une modeste contribution à partir de mon retour d'expérience, pour les autres non-spécialiste de l'informatique qui seraient confronter à ces problématiques.

Vive le GeoRezo !

Merci N314 également...

Je n'avais pas vu que le thème était traité chez les voisins d'à-côté

Bon bah yapluka

Bonjour,

je ne comprends pas pourquoi vous parlez de 5 serveurs. 2 VM suffisent (même si par le passé ESRI préconisait 2 serveurs physiques disctincts, ce n'est plus le cas), 1 pour la base de données (Oracle+SDE) l'autre pour le serveur d'appli (ArcGIS Server). Les SOC et SOM sont des comptes (SOM gère les connections et SOC représente les connections, c'est à dire 1 SOC = 1 connection), pas des serveurs. Ils disparaissent dans la prochaine version d'ArcGIS Server.
Très franchement pour 15 utilisateurs, les contraintes hardaware ne devraient pas être trop violentes puisque de toute façon vous serez plus limité par les temps d'accès aux données liés à votre réseau qu'aux réelles contraintes de ram ou autre. Cependant n'oubliez pas qu'ArcGIS Server en version 10.1 tournera en 64 bits. Quand à la taille des disques tout dépend de votre volume de données.

Cdt

Bonjour à vous deux et merci pour vos réponses de qualité.

J'avance un peu sur ce problème et du coup, je prends en compte vos remarques.

Du nombre de serveurs :

Pour les SOC / SOM, j'avais repris les éléments du cahier blanc d'esri portant sur l'étude de cas à partir de Corine Land Cover mais sans trop savoir ce que cela signifiait... Donc deux VM suffisent, un pour la base de données. L'autre pour le serveur d'application.

J'en voyais (mais sans trop m'y connaître) éventuellement un troisième, soit pour les sauvegardes, soit dans le cas où mon EPCI souhaiterait mettre à disposition des communes membres les données produites. Vous en pensez quoi ?

Des prérequis sur ArcGIS Serveur :

Dans les docs que vous m'avez fait lire, j'ai pu retrouver l'info selon laquelle ArcGIS Server 10.1 tournera en 64 bits. Donc dans mon diagnostic du dimensionnement des serveurs que je dois faire, je garde cette info fondamentale.

De la taille des disques et du volume des données :

Pour la taille du disque de la géodatabase, d'après ce que je possède, 500 giga me paraissent un maximum.

Par contre, j'ai pas retrouver l'info qui parlait de ce que prenait ArcGIS Serveur pour tourner. Vous la connaîtriez par hasard ?

Des spécificités des serveurs :

Si on part sur des serveurs de 3 Ghz / 16 GB RAM (8 core), ca vous parait suffisant ?


Merci pour votre soutien dans les moments difficiles !

Bon repos dominical,

Alban

NB : Vivement que je fasse mumuse avec les données.

Dernière modification par Macaron (Sun 19 February 2012 12:14)

Très bonne remarque.

A ce jour, d'après ce que j'ai pu récupérer en couche raster (orthophotos HD, scan 25, cadastre, raster 1000, autres), j'arrive à une trentaine de gigas.

Dans le concept, ces rasters apparaitraient en fonction de l'échelle choisie (le cadastre à grande échelle, le scan 1000 à petite échelle, par ex), en fonction des besoins de précisions des différents utilisateurs métiers (assainissement, urbanisme, etc).

Existe t'il un delta qui permettent de prévoir le volume de données nécessaire ? De quoi cela est-il fonction ? Du nombre d'utilisateurs ?

Merci N314.

Bonjour,

concernant le nombre de serveurs. Un troisième serveur pour la sauvegarde me parait essentiel, en revanche pour une diffusion externe, je ne vois pas l'intérêt. Vous pouvez utiliser votre base SDE et ArcGIS Server pour donner aux accès aux "extérieurs". Il "suffira" de gérer les accès soit dans la base SQL, soit dans SDE ou encore dans les applis web. De ce côté, je n'ai pas de rex sur le sujet, car nous diffusons uniquement en interne.

Pour la taille des disques du serveur d'applications (ArcGIS Server proprement dit), il n'y a pas besoin d'un gros volume, vous stockez les cartes publiées et les applications développées plus les installations liées à ArcGIS Server (la base de données et les données sont stockées ailleurs).
Cependant si vous souhaitez gérer les rasters en dehors de SDE, il faut les mettre sur le serveur où est installé ArcGIS Server. Lors de l’installation d’ArcGIS server, nous créons automatiquement un répertoire partagé accessible à la fois par le serveur et par les administrateurs d’arcgis server. Création d’une arborescence en local, Création d’une géodatabase fichier à la racine de l’arborescence, Copie des fichiers rasters dans les sous dossiers, Création des catalogues rasters en mode non managé, Import des rasters dans les catalogues, Copie de l’arborescence sur le server, Publication des services de cartes.

Pour les processeurs de vos serveurs, j'attire votre attention sur le fait qu'ESRI facture la licence ArcGIS Server pour 4 coeurs, et qu'il faut payer une taxe pour chaque coeur supplémentaire (prix vraiment élevé).

Sur ce dernier point j'attire votre attention sur le budget à mettre face à un projet tel que celui-là. Au-delà des aspects purement achat de matériel (serveurs + licences Windows serveur 2008, sql serveur, ArcGIS Serveur...) il y aussi l'aspect humain. C'est à dire le temps nécessaire pour tout installer et mettre en place. De plus le développement d'applications web pour diffuser vos données est également une tâche qui prend du temps.
Sur ce point (budget + temps de ce type de projet), j'ai un bon retour d'expérience sur le sujet....

Vous devriez contacter ESRI pour qu'ils vous aident à dimensioner votre projet. Ils sont de bon conseils. (Je ne travaille pas pour eux)

Cdt

Dernière modification par benulti (Mon 20 February 2012 11:39)

De très bonnes infos ici : http://www.vmware.com/files/pdf/ESRI-De … e-v1.0.pdf

Je vous en fait la synthèse après.

Merci Franck. La version que j'avais ce matin était pour la V9.3.

Je vous tiens au jus.

- Nombre d'applications Web : C'est quoi ça (celles d'esri du type webmapping, geospatial explorer, mobile) ?
Dans ton cas, tu utilises ArcGIS Server pour publier des services de carte (mapservice) basés sur des mxd/msd réalisés avec ArcGIS Desktop (ArcView/ArcEditor/ArcInfo selon le niveau de licence retenu).
Un mxd est constitué d'une à plusieurs couches de ton SIG. Une couche peut être le scan 25, une table contenant des objet ponctuel, ... Dans ton mxd tu dois définir la symbologie, les plages d'échelle de chaque couche. Une phase de tuning sera nécessaire pour vérifier que ton MapService répond rapidement quelque soit l'échelle d'affichage. Si le temps de réponse d'ArcGIS Server à chaque requête est de l'ordre de plusieurs seconde, ton application sera inutilisable.
Ces MapService doivent être ensuite consommés dans une application web, construite à partir d'un SDK de webmapping : flex (from scratch ou à partir du flex viewer qui est un template d'application web), silverlight ou javascript. Ton application web utilisera les composants fournis par le sdk : une carte qui consomme tes MapService, des outils : pan, zoom, ...

- Nombre Moyen de Map Services métiers par Application
                Nombre en dynamique?
                Nombre en CACHE ?
                Nombre avec édition en ligne ? (feature service)

La notion de dynamique est à comprendre de la façon suivante : lorsque l'application demande une image de la carte à ArcGIS Server, celui-ci la calcule systématiquement à partir des données de la geotadabase, même si un utilisateur à fait exactement la même demande 1 seconde plus tôt.
Les services en cache seront ceux de type fond de plan : scan25, scan 1000, ortho, éventuellement le cadastre... Personnellement, je trouve plus simple de gérer un MapService par fond de plan : un MapService pour le scan 25, un pour le scan 1000 et ainsi de suite.
Les services dynamiques sont habituellement ceux publiant des données métier. D'une part il est très couteux de les mettre en cache si l'utilisateur peut choisir d'afficher/masquer certaines couches du service. D'autre part si les données publiées par le service sont amenées à être modifiées, il faudrait à chaque modification d'une donnée recalculer le cache...
Tes services accessibles en tant que feature service seront ceux publiant des données éditables par les utilisateurs.

Je médite toujours sur vos réflexions et je reviens pour évoquer quelques points :

J'ai compris que le map service est composé par des couches rasters et vecteurs et que celui-ci est consommé par une application web.

Mais une application web, c'est ce qui permet à l'utilisateur de zoomer, de choisir les couches qui veut faire apparaitre, les échelles,  de faire des requêtes sur les données attributaires et des analyses thématiques ?

Concernant la notion de dynamisme et de cache : Ai-je intérêt à mettre en dynamique ce qui doit être modifié par l'utilisateur et à mettre en cache ce qui n'est pas modifiable (typiquement, les rasters) ?

Merci

Ça dépendra aussi de la fréquence de mise à jour des services de cartes pour des adaptations : à chaque changement de symbologie, de niveaux d'échelle dans ton mapservice il faudra recalculer ton cache sans quoi tes utilisateurs ne verront jamais les mises à jour.

D'où le fait que dans la vraie vie, il est peu courant de mettre autre chose que du fond de plan en cache (rasters, scan, orthophotos, ...).

Merci...

Je potasse toujours...