[OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

En gros tu proposes un proxy plus intelligent que Squid (qui ne différencie
pas les zones à afficher ni la géolocalisation des clients).

Je pense que la différenciation des zones à afficher sur des serveurs
dédiés serait utile à l'échelle continentale au mieux, mais qu'ici le but
est de réduire les coûts en bande passante et donc d'utiliser en priorité
la géolocalisation des clients.

Et pour ce dernier objectif (géolocalisation des clients, ou plutôt
détermination de la route IP par laquelle ils arrivent), il vaut mieux
s'appuyer sur un serveur DNS dynamique (qui retournera l'adresse du bon
serveur à utiliser selon la géolocalisation du client, en retournant un nom
de domaine alternatif par une entrée "CNAME").

Ce sera beaucoup plus efficace qu'un proxy "intelligent" qui aura son lien
amont (accès par les clients) surchargé et pas réparti en bande passante,
même si son lien aval (du côté des serveurs de rendu) il va faire faire des
économies aux serveurs de rendu : là on gagnera réellement de la bande
passante au niveau des routeurs d'entrée (et notamment sur les liaisons de
peering, entre lesquelles on pourra gérer la répartition des bandes
passantes).

Ensuite ce qu'on met au bout des adresses redirigées par le proxy peut être
un gros serveur de rendu avec un petit cache Squid frontal, ou un petit
serveur de rendu et un gros cache Squid frontal (mais dans les deux cas une
date de péremption bien plus rapide, pour les réponses HTTP émises du
serveur de rendu vers Squid, puisque entre les deux, le frontal Squid et
le(s) serveurs de tuiles et de rendus cela peut se faire sur une boucle
locale à coût voisin de zéro en terme de bande passante utilisée).




Le 19 décembre 2012 19:56, sly (sylvain letuffe) <liste at letuffe.org> a
écrit :

> On mercredi 19 décembre 2012, Jocelyn Jaubert wrote:
> > Je me demandais: est-ce que avoir un serveur de rendu dédié à une région
> > spéciale (genre la France) serait une solution envisageable ?
>
> Jocelyn, tu penses à tout ;-)
>
> Je pense que ça peut se creuser, y'a de l'idée et j'ai même commencé à
> mettre
> sur papier quelques idées, mais j'ai peur que ça soit un peu délicat et pas
> super robuste (en tout cas avec mes bidouilles à deux balles que j'ai en
> tête), il faut que je chercher voir si squid, ou apache peut nous faire ça
> en
> mode proxy.
>
> De prim abord, je pense que la puissance nécessaire à faire un rendu sur la
> terre, bien que pas vraiment possible avec mon smartphone, n'est pas non
> plus
> impossible. Je prouverais (dès que cquest c'est occupé de ma VM au lieu de
> jouer avec des kernels :-p ) , que c'est possible avec les serveurs que la
> fondation free a eu le bon goût de nous fournir.
> (j'ai peur de découvrir toutefois qu'un SSD aurait vraiment été bien,
> auquel
> cas je ferais mon malin à dire "J'l'avais dis" :-p)
>
> Et cette croyance actuelle que j'ai m'incite à ne pas m'éparpiller à coller
> des bouts des ficelles entre eux mais partir sur une "vrai" solution, avec
> une babasse qui dépotte
>
> > En gros, l'idée serait d'avoir un serveur de rendu par région, qui ne
> > contiendrait qu'un petit terrain, et sur les zoom élevés. Ça devrait
> > permettre
> > de diminuer grandement la taille de la machine nécessaire, en la mettant
> là
> > où
> > c'est le plus nécessaire. Avec les diffs locaux, ça pourrait être
> possible.
>
> Oui, je le crois tout à fait réaliste en terme de puissance, moins en
> terme de
> réalisation.
> Pour info, je continue à faire un rendu europe à jour real time avec des
> vieux
> style mal optimisés sur un 4-coeur + 8GO de RAM sans SSD, donc oui, j'y
> crois
> et ce, en grande partie grâce à ce que tu as développé pour les europe
> diffs)
>
> En quoi j'ai peur de la réalisation ?
> le protocole utilisé est TMS, on l'appel comme ça :
> http://duchmol/zoom/x/y.png
>
> Et, hélas pas, ainsi : http://zone-[bbox max].duchmol/zoom/x/y.png
> Ou il aurait été bien plus facile de préparer un cluster géographique
> réparti
> ou chaque serveur annonce quelle bbox il peut couvrir et le client
> openlayers
> supportant ce faux TMS se charge d'interroger le bon serveur de la bonne
> zone
>
> En clair avec le vrai TMS, on tombe sur un seul serveur, et lui ne sait pas
> encore s'il peut ou non servir la requête, l'idée que j'ai est donc un
> proxy
> (non cache) intelligent que je préfère nommer "le dispatcher"
>
> Son rôle et de transmettre la demande au bon serveur qui gère la bonne
> zone,
> il doit :
> - maintenir une liste des serveurs ordonnés de zone et la zone qu'ils
> couvrent
> - faire le calcul, à partir d'une URL TMS afin de déterminer dans quelle
> zone
> elle se trouve
> - Proxier/ou rediriger par un HTTP 301 la demande de l'internaute vers le
> serveur le plus adapté
>
> Bigre, rien qu'a l'écrire, je me dis que ça n'est pas si compliqué que ça
> et
> que ça pourrait largement trop bien le faire.
> (cadeaux bonux, mise en cache des zoom 0 à 9 les plus souvent demandés)
>
>
> --
> sly, DWG member since 11/2012
> Coordinateur du groupe [ga]
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20121219/7f24e89e/attachment-0001.html>