Questions générales sur la mise en place d'un serveur

Bonjour, je viens vers vous pour avoir plus d’informations sur la mise en place d’un serveur de tuiles.

J’ai bien dégrossi la chose, réussi avec succès à importer les données de la france entière sur un serveur dédié, depuis geofabrik.
Me restent toujours quelques interrogations :

Quant aux spécificités du serveur, je trouvais le chargement des tuiles excessivement long avec la france entière importée, l’import d’une plus petite portion, dans les mêmes conditions, me donne des résultats sensiblement plus rapides.
J’ai fait ces essais sur un serveur OVH, Intel Xeon E3-1231v3 4c/8t 3,4 / 3,8 GHz avec 32 Go RAM DDR3 ECC 1600 MHz
Et en mémoire de stockage : 2 x 2 To RAID SOFT

A la suite de recherches il m’apparait que je ferais mieux de prendre un processeur moins cadencé, 64 Go de RAM, et surtout des disques SSD? Est-ce juste ? Est-ce une configuration viable pour une centaine à un millier d’utilisateurs ?

Sinon toujours quelques points restent abstraits dans mon esprit:
Il est dit que la planète entière fait 800-900Go, est-ce bien de la totalité de toutes les meta tiles .png qui forment la planète que l’on parle là?

Le osm.pbf de la planète entière sur geofabrik ne représente qu’une 30aine de Go, est ce suffisant d’avoir 30Go en SSD, ou vaut-il vraiment mieux avoir les 800-900Go en SSD aussi ?

Et dernière question, le système de cache des tuiles, est représenté par les meta tiles dans les dossiers x/y/z c’est bien ça ? Donc une fois une tuile chargée sur la serveur en cache, il n’y a plus besoin que postgresql fasse de requête pour la recharger ? Si oui, alors est-il possible de charger (certes ça prendrait plutôt longtemps) toutes les tuiles en cache afin que les tuiles soient affichées directement sans requête pgsql ?

Je vous remercie énormément par avance car si vous prenez la peine de me répondre il est clair que j’aurai les idées beaucoup plus claires :smiley:

Bonjour,

Avant toute chose, lis https://switch2osm.org/fr/

Et http://wiki.openstreetmap.org/wiki/FR:Aperçu_des_composants
=> ce que tu mets en place c’est la partie jaune entourée de pointillé.

Il est dit que la planète entière fait 800-900Go, est-ce bien de la totalité de toutes les meta tiles .png qui forment la planète que l’on parle là?

Quand on parle de fichier planet (sans e), il s’agit des données brutes OpenStreetMap.
http://wiki.openstreetmap.org/wiki/FR:Planet.osm

Les tuiles (raster) sont des images .png qui sont générées à la demande par un serveur de tuiles. Il réalise le rendu (passage des données à une image en fonction d’une feuille de style) et la mise en cache des tuiles. Il n’existe pas de fichier où il y aurait toutes les tuiles à tous les niveau de zoom. Personne ne l’a fait: rendre toutes les tuiles de z1à z19 nécessiterai 54 Tio d’espace disque, et ce quelque soit la taille de la base OSM. Et il y aurait beaucoup de tuiles bleues :slight_smile:
Plus de détail ici : http://wiki.openstreetmap.org/wiki/Tile_disk_usage

je trouvais le chargement des tuiles excessivement long avec la france entière importée, l’import d’une plus petite portion, dans les mêmes conditions, me donne des résultats sensiblement plus rapides

Cette étape longue n’est pas “le chargement des tuiles”, mais le chargement des données OSM brutes dans une base de données géomatique (postgis) par le programme osm2pgsql. Un SSD est très utile ici. Le CPU ? bof, c’est pas si critique. La RAM un peu plus. Et pour l’étape de rendu un tout petit CPU peut passer.

Le osm.pbf de la planète entière sur geofabrik ne représente qu’une 30aine de Go, est ce suffisant d’avoir 30Go en SSD, ou vaut-il vraiment mieux avoir les 800-900Go en SSD aussi ?

Pour le monde tu peux regerder l’infra de l’assos OSM France (le serveur osm13 je crois) : http://wiki.openstreetmap.org/wiki/FR:Servers

La base postgis de la France tiens dans 30 Gio SSD je crois. Et tu peux mettre les tuiles raster rendues sur un disque classique.
Tu peux aussi ne mettre que les index de la base postgis sur SSD.

Et dernière question, le système de cache des tuiles, est représenté par les meta tiles dans les dossiers x/y/z c’est bien ça ?

Les tuiles rendues sont bien dans x/y/z.
Une meta tile est un concept lié au rendu : plutot que de récupérer les données de la base présentes dans la petite zone d’une tuile, on récupére une zone plus grande et on rend toutes les tuiles de cette meta-tuile.

alors est-il possible de charger (certes ça prendrait plutôt longtemps) toutes les tuiles en cache afin que les tuiles soient affichées directement sans requête pgsql ?

Il y a un script pour pré-rendre les tuiles sur une zone géographique et sur une plage de zoom. On l’utilise pour les faibles niveau de zoom, car le rendu y est plus long vu la quantité de données pouvant être présente dans la zone d’une tuile. Le nom du script m’échappe, mais Christian va passer par là !


Sinon il y a des point que tu n’a pas évoqué, comme la mise à jour régulière de ta base postgis avec les données OSM, ou l’expiration des tuile dans le cache.
Bruno

Si tu veux générer des tuiles à la volée, sur une emprise importante (base Europe ou Monde), le SSD me semble aujourd’hui indispensable.
C’est souvent plus côté I/O qu’on est limité que côté CPU.
Regarde les stats du serveur de tuiles d’OSM-France (osm13): http://munin.openstreetmap.fr/munin/openstreetmap.fr/osm13.openstreetmap.fr/index.html
C’est une base monde, la base postgres est sur un SSD, le cache de tuiles sur un autre SSD.

Sinon toujours quelques points restent abstraits dans mon esprit:
Il est dit que la planète entière fait 800-900Go, est-ce bien de la totalité de toutes les meta tiles .png qui forment la planète que l’on parle là?

Non pas du tout, on parle ici plutôt de la taille de la base de données qui sur osm13 fait actuellement 550Go.

Le volume du cache de tuiles est variable. Personne ne pré-calcule l’ensemble des tuiles c’est beaucoup trop volumineux et long… et il faut sans arrêt les mettre à jour vu que les données OSM changent sans arrêt.

Pour osm13, les zoom 0 à 12 sont précalculés sur le monde entier, puis le zoom 13-14 est précalculé sur la France, le reste généré là où c’est demandé, conservé en cache, qu’on vide en fonction du zoom, de la fréquence de consultation, de la fréquence de mise à jour.

Le osm.pbf de la planète entière sur geofabrik ne représente qu’une 30aine de Go, est ce suffisant d’avoir 30Go en SSD, ou vaut-il vraiment mieux avoir les 800-900Go en SSD aussi ?

Une fois remis en base postgres avec osm2pgsql, tu auras une base d’environ 500-600Go.

Et dernière question, le système de cache des tuiles, est représenté par les meta tiles dans les dossiers x/y/z c’est bien ça ? Donc une fois une tuile chargée sur la serveur en cache, il n’y a plus besoin que postgresql fasse de requête pour la recharger ? Si oui, alors est-il possible de charger (certes ça prendrait plutôt longtemps) toutes les tuiles en cache afin que les tuiles soient affichées directement sans requête pgsql ?

Les meta-tuiles stockées en cache sont stockées dans des dossiers z/a/b/c/d à 5 niveaux et pas 3, histoire de ne pas avoir de dossiers avec trop de fichiers.

Une fois une meta-tuile calculée, elle est stockée dans le cache. Ensuite lorsqu’on met à jour sa base (avec les diff), osm2pgsql génère une liste des tuiles impactées par les nouvelles données et là on peut soit recalculer les meta-tuiles correspondantes, soit noter qu’elles sont invalides (en leur mettant une date de modif très ancienne), soit en les supprimant pour forcer leur recalcul. Si on ne met pas à jour sa base (ou très rarement), on pourrait juste garde les meta-tuiles… sauf que…

Calculer toutes les meta-tuiles est envisageable jusqu’à un certain niveau de zoom ou pour une emprise limitée.
Comme à chaque niveau de zoom on a 4 fois plus de tuiles, on atteint vite des volumes ingérables… au zoom 18 ça fait 1 073 741 824 metatuiles sur le monde entier :wink:

Je vous remercie énormément par avance car si vous prenez la peine de me répondre il est clair que j’aurai les idées beaucoup plus claires > :smiley:

Pour te conseiller il faudrait avoir une meilleure idée de tes contraintes:

  • quelle emprise
  • quel zoom maximum
  • quelle fréquence de rafraichissement (5mn, jour, mois, plus ?)
  • quel traffic envisagé…
  • quel style (détaillé façon OSM/OSM-FR ou light par exemple sans les bâtiments ou l’occupation des sols)