[OSM-talk-fr] rendu inconsistant des caches de tuiles OSM.org

[Philippe Verdy]

Il semble que le cache de tuiles à problems soit "london-02". Le
problème semble être qu'il ne parvient pas à recevoir les tuiles à
jour (problème de connexion ou de stockage local) et qu'un système de
repli lui fait renvoyer les anciennes copies qu'il a, mais avec une
date de validité remise à jour. Mais en cas de surcharge sur un des
serveurs, il semble que les autres caches peuvent aller reprendre ces
copies anciennes et ne s'aperçoivent pas que ce qu'on leur donne n'est
pas un rafraichissement mais une copie plus ancienne qui vient écraser
une version pourtant plus récent qu'un serveur de cache avait... d'où
le "yoyo" et les rendus inconsistants.

Il semble que rien n'indique dans les métadonnées tuiles quand elles
ont été réellement générées sur un serveur de rendu source avant
d'être répliquées, il n'y a pas de conservation des métadonnées et
cela semble s'appuyer uniquement sur les dates locales de création ou
modification fichiers, ce qui n'est pas du tout la même chose : le
fait de modifier un fichier en y enregistrant des données venant d'un
autre serveur vient inscrire la date actuelel et non la date HTTP
d'origine: la datation est corrompue.

Je n'ai aucun idée comment la réplication des tuiles entre les cache
se fait mais si cela utilise les mêmes requêtes HTTP que nous tous,
les métadonnées HTTP devraient être gardées et la date locale des
fichiers n'a aucune valeur et ne devrait pas être utilisée du tout
(surtout si le système de fichier local n'est lui-même pas à l'heure
sur un serveur sans synchro NTP).

En tout cas quelquechose ne marche pas, et il y a plusieurs sources
possibles et toutes les vérifications ne sont pas en place et les
protocoles (ou logiciels sensés les utiliser) ne semble pas au point.
Il y a un bogue et ça finit par couter globalement cher en ressources
réseau et en surcharge sur les serveurs de rendu.

Le lun. 24 févr. 2020 à 19:22, Philippe Verdy <verdyp at gmail.com> a écrit :
>
> Il semble que certains des caches de tuiles du rendu Carto d'OSM.org
> ne fonctionnent pas correctement et ne cessent de se renvoyer des
> copies d'anciens rendus venant écraser les nouveaux reçus d'autres
> serveurs.
> Cela semble indiquer que certains serveurs ne sont pas correctement
> datés et ne parviennent pas à interpréter les dates d'expiration
> correctement dans les entêtes HTTP.
> Et cela pourrait expliquer aussi la surcharge actuelle des serveurs de
> rendu qui recalculent sans arrêt les mêmes zones sans parvenir à
> synchroniser les caches.
> Et cela se voit sur la carte finale (avec des vas-et-viens d'une
> version à l'autre des mêmes tuiles, même sans changement dans les
> données de la base OSM).
> Ou alors certains serveurs de rendus sont désynchronisés avec le flux
> des minute diff et ont à faire des "corrections" ou appliquent dnals
> leur propre base des données inconsistantes ne correspondant plus du
> tout à ce qui est dans la base principale, et incapables de prendre en
> compte des nouveaux changements (exemple: référence de certains ways à
> des noeuds inexistants marqués comme supprimés).
> Y-a-t-il des problèmes de synchro pour la réplication des bases et
> a-t-on un service qui permette de contrôler que tous les serveurs de
> bases (principale et esclaves), de rendus, et de caches sont bien
> synchronisés avec NTP et que leurs horloges sont cohérentes ainsi que
> les horloges internes des serveurs web (Apache ou Squid) ?
> Y a-t-il une programmation permettant de redémarrer les serveurs un
> par un régulièrement et vérifier leur intégrité et synchronisation,
> pour éviter ces "yoyos" très préjudiciables et aussi finalement
> limiter les requêtes et la consommation de bande passante et de
> ressources CPU/disque sur ces serveurs ?
> En tout cas la synchro entre serveurs ne semble pas sécurisée du tout,
> tout semble se faire sans aucune métadonnée de contrôle qui pourrait
> éviter d'écraser constamment des données correctement mises à jour par
> des données anciennes qui ne devraient plus être là.
> C'est peut-être un problème des systèmes de fichiers montés
> (particulièrement si le stockage des images se fait en réseau): des
> "fsck" réguliers semblent s'imposer aussi.