Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: Points questions techniques [ Répondre ] Par : Jean Roc MORREALE on 2010-10-13 20:34 | [forum:473846] |
|
Merci beaucoup de votre réponse, Quand vous dites ne pas faire pas de sauvegardes des rasters, incluez-vous dans ce lot les rasters envoyés par vos utilisateurs pour partage via votre géocatalogue ? La configuration présentée par Lydie VINSONNEAU est assez puissante, après un an de mise en service quels sont vos retours au niveau de l'utilisation (CPU,i/o, etc.) de la machine virtuelle hébergeant GéoBretagne ? Notre collectivité (CG) envisageant l'utilisation de cette plateforme dans le cadre d'un projet-métier, toute information est bienvenue pour appuyer la décision. |
|
| RE: Points questions techniques [ Répondre ] Par : Fabrice Phung on 2010-10-12 07:33 | [forum:473808] |
|
Bonjour, Oui, en utilisant simplement rsync. Les fichiers de configuration sont légers, il s'agit surtout de les regrouper pour en faciliter la sauvegarde. Les données existent essentiellement sous forme de shapefiles donc peuvent être sauvegardées en mode fichier. Les bases de données postgresql : liferay, geonetwork, avec un dump. La base osm et les tuiles ne sont pas sauvegardés, ils peuvent être régénérés. Les raster ne sont pas sauvegardés non plus. |
|
| RE: Points questions techniques [ Répondre ] Par : Jean Roc MORREALE on 2010-10-06 10:52 | [forum:473748] |
|
Bonjour, Avez-vous mis en place un système de sauvegarde distinct du serveur de production ? |
|
| Points questions techniques [ Répondre ] Par : Lydie VINSONNEAU on 2009-12-09 11:43 | [forum:471922] |
|
Question : Je suis à la recherche d’info sur le coût de mise en œuvre et d’hébergement d’une plate-forme tel que GéOrchestra. Pour vous aider à chiffrer, j’ai essayé de quantifier un peu notre besoin (nombre de partenaires, volumes de données, etc.). Réponse : Il faut distinguer trois choses là-dedans : 1) la plate-forme qui héberge le logiciel et les données. Il s'agit classiquement d'un serveur d'application, virtuel ou réel, avec des potentiels de stockage et de traitement finis. 2) l'environnement autour qui optimise le fonctionnement. Il s'agit de caches, de proxies, de pare-feux et de sauvegardes. Il permet de protéger la plate-forme centrale des menaces, mais aussi de la charge, en déportant certains traitements. 3) évidemment, les techniciens en charge du fonctionnement Dans georchestra nous avons tenté d'apporter une réponse à ces trois points. 1) en uniformisant la technique, c'est à dire en demandant une architecture J2EE. L'hébergement de celle-ci peut se trouver sur étagère, car le prestataire n'a pas besoin d'être familier avec la géomatique. 2) en intégrant à l'architecture certains modules d'optimisation, notamment le cache raster. Sans ce cache, une machine peine à délivrer plus de 10 images/seconde. Avec le cache, on peut saturer sans problème n'importe quelle liaison gigabit avec une machine modeste. 3) même réponse que 1 pour la partie système, dans la mesure où l'administration J2EE peut faire partie de la prestation d'hébergement. Pour la partie administration du logiciel, il est bien sûr indispensable de désigner quelqu'un. J'en viens au dimensionnement : * espace de stockage du logiciel et des lots : n'importer quel disque dur suffit aujourd'hui à héberger les lots données nécessaires à la bretagne. Les disques dur ultrarapides SAS arrivent aujourd'hui avec des capacités de 320 Go, plus que nécessaire. * espace de stockage du cache : on investira dans celui-ci proportionnellement au succès escompté. L'important est de pouvoir dégager de l'espace disque un jour, mais pas forcément au début. Nous avons compté 2 To, ce qui ne se trouver pas souvent. * débit réseau : même si l'application est fortement optimisée, le débit réseau est souvent le facteur limitant, plus que la machine. S'il y a des sites distants, il faut soigner ce point. La solution que je vois à coût optimisé, sur l'internet : * choisir un hébergeur virtuel, c'est à dire un prestataire qui propose des "parts" de serveur que l'on peut augmenter ou diminuer à loisir. On ajustera la charge avec des bons de commande, en fonction du succès. Bien vérifier que cet hébergeur est susceptible de délivrer beaucoup d'espace disque (couvertures rasters non compressées X 10) * choisir un intégrateur spécialisé dans J2EE, qui n'aura pas de mal à optimiser un serveur J2EE et installer l'application dessus (si c'est georchestra :) De cette façon on limite le sur ou sous-investissement initial, on s'adapte à la demande. Dans le cas de georchestra nous avons cette approche car le serveur final, opéré par le centre support mutualisé, n'est pas dédié. Si d'aventure nous devions externaliser cocmplètement la prestation, nous pourrions procéder comme ci-avant. Question : Une autre approche que je souhaiterais aborder serait de partir en sens inverse : à partir des caractéristiques serveur, de voir la charge supportable et le service qui peut être rendu. Réponse : Comme je le disais précédemment, les services d'optimisation autour du serveur autant, voire davantage d'importance que le serveur lui-même. Compter sur un bon proxy peut par exemple aider beaucoup en distribuant la charge. Question : Aussi, te serait-il possible de me transmettre les caractéristiques globales du ou des serveurs qui hébergent GéoBretagne ? (nombre de serveur, nombre de processeurs, fréquence, quantité de mémoire, volume des disques, vitesse réseau en upload et download, etc.) Réponse : 1 seul serveur non dédié, 64 Go RAM, 4 bi-processeur 3 GHz, 3.5 To disques dur SAS 15000 Tr/mn, vitesse réseau virtuellement illimitée (hébergé en datacenter SFR). l'aspect non dédié est important, je pense qu'à l'heure actuelle il faut installer ces produits sur des serveurs virtuels pour migrer facilement sur plus gros ou plus léger. Question : ainsi que le nombre de connexions et les volumes de téléchargement envisagés et théoriquement supporté par cette infrastructure ? Réponse : aucune idée pour ma part. on s'attache plutôt à ce que l'architecture soit en capacité de suivre la charge, car on se méfie des estimations. Question : Pourrais-tu me confirmer que GeOrchestra fonctionne sur un serveur TomCat ? Réponse : oui tout à fait Question : As-tu des éléments sur l’installation de la solution, les applications nécessaires, les versions pour compléter la réponse à la question précédente ? Réponse : nous utilisons actuellement : * debian 5.0 lenny (noyau 2.6.*-amd64-bigmem) * postgresql 8.3 + extensions postgis (paquets debian) * java jdk sun 1.6 64 bits * apache 2.2 (paquets debian) * tomcat 5.5 (paquets debian) on peut être amené à faire tourner plusieurs tomcat pour bien séparer les applications Question : Par exemple, quelle base de données utilise le site éditorial et l’espace collaboratif ? Est-ce qu’une seule base de données (Postgresql ?) suffit ? Réponse : un seul cluster postgresql suffit mais il faudra plusieurs bases de données |
|
