[OSM-talk-fr] (sans objet)

[Philippe Verdy]

Vous avez vu cet appel de l'OSMF ?

https://blog.openstreetmap.org/2018/02/19/osmf-request-for-proposals-data-centre-2018/

Ils recherchent une nouvelle colocation en Europe (probablement parce que
certains serveurs de tuiles sont surchargés, notamment celui de Baku en
Azerbaijan et qui dessert toute l'Asie du Sud où la situation semble encore
plus critique avec des temps de réponse dépassant maintenant les 300 ms).

Il faudrait aussi revoir la répartition des serveurs du CDN d'OSM.org, ils
sont trÚs déséquilibrés avec certains serveurs sous-utilisés, et d'autres
visiblement beaucoup trop.

Peut-on contacter des hébergeurs candidats en France ou faire appel à leur
générosité (et les couts sont-ils compatibles?) et pas nécessairement
seulement la fondation Free (ou France-IX qui dessert maintenant beaucoup
mieux l'Afrique), afin de soulager les serveurs espagnols ? On pourrait
même proposer alors de desservir l'Afrique du Sud depuis France-IX à
Marseille plutÎt que les Pays-Bas, et rapatrier à Amsterdam le service de
certains autres pays européens.

Il semble qu'OSM.org manque d'outils pour suivra la capacité et
l'équilibrage de ses serveurs, et reconfigurer facilement et plus
dynamiquement son CDN (avec en conséquence un service de plus en plus
instable, des tuiles qui ne se mettent pas à jour, et des écarts de plus en
plus important selon les caches).

De plus les caches d'OSM.org semblent ne pas être synchronisés (les heures
affichées, les dates de péemtpion et de renouvellement ne sont pas
correctes, il arrive de plus en plus souvent que la même tuile demandée
affiche une seconde avant une nouvelle tuile, puis aprÚs une ancienne et
les écarts dépassent l'heure: il semble bien que ces serveurs ont des
problÚmes de mise à jour de leurs horloges, voire des bogues dans la
gestion des décalages pour le passage à l'heure d'été, ou des difficultés
de connexion à un serveur de temps). Il est par conséquent de plus en plus
difficile d'avoir un rendu homogÚne des cartes (et ceci indépendamment de
la charge et des serveurs de rendus)

[Philippe Verdy]

Notez aussi que le service depuis la Russie cause aussi de sévÚres
problÚmes depuis le blocage de millions d'adresses IP par les autorités
russes (affaire liée à Telegram: ils bloquent tous les VPN, et bon nombre
d'adresses utilisées par les gros hébergeurs et transitaires
internationaux), la connectivité s'est considérablement dégradée. Je pense
que le service de l'Estonie devrait être rapidement fait depuis un autre
pays européen.
En conséquence, la Russie voit son service OSM entiÚrement rapatrié en
Russie sur les serveurs russes qui eux ont une croissance rapide de charge
(il semble qu'un certin nombre de serveurs de tuiles d'OSM ne répondent
plus depuis la Russie ou sont devenus trÚs lents).

Je pense que c'est toute l'infrastructure d'OSM.org qui doit être
reconsolidée et cela justifie aussi l'appel à de nouveaux hébergeurs pour
l'Europe et l'Asie du Sud. Et l'Afrique du Sud qui avait ses serveurs ne
les a plus, et est maintenant servie depuis Amsterdam (les performances
sont nettement moins bonnes).

On voit le danger que nos campagnes de promotion et développement en
Afrique et Asie du Sud virent à des opportunités pour des services
cartographiques commerciaux (notamment Google) et que cela vienne freiner
les efforts soutenant l'OpenData, et pourtant iul y a tant à faire en
Afrique et en Asie du Sud (notamment l'Inde et le Bengladesh) et que les
efforts humanitaires actuels (HOT ou autres) peuvent en souffrir.

Comment consolider les services internet d'OSM.org et mieux se prémunir de
changements brutaux de connectivité dans le monde (ou parer à ces ruptures
accidentelles ou des attaques distribuées): cela devrait être une question
à poser au prochain State of the Map international et à discuter avec les
chapitres pour voir ce qu'ils peuvent faire pour isoler, et contourner ces
problÚmes. L'infrastructure internet d'OSM.org est encore trÚs fragile,
indépendamment des ressources serveurs disponibles. On a trop de goulots et
de maillons faibles dont on dépend fortement, et les temps de résolution de
ces problÚmes sont encore beaucoup trop longs quand ils surviennent car on
n'a pas beaucoup de solutions de secours et on manque certainement d'outils
de gestion de charge et de mesure continue de la qualité de service à
l'échelle du monde (cela n'est réellement surveillé que depuis le
Royaume-Uni et pour les utilisateurs britanniques, cela manque de
concertation, on n'a pas de procédures et outils de gestion efficace des
incidents et de supervision de la qualité, si ce n'est quelques outils de
mesure comme Munin, qui sont pourtant sous-utilisés).

Post by Philippe Verdy
Vous avez vu cet appel de l'OSMF ?
https://blog.openstreetmap.org/2018/02/19/osmf-request-
for-proposals-data-centre-2018/
Ils recherchent une nouvelle colocation en Europe (probablement parce que
certains serveurs de tuiles sont surchargés, notamment celui de Baku en
Azerbaijan et qui dessert toute l'Asie du Sud où la situation semble encore
plus critique avec des temps de réponse dépassant maintenant les 300 ms).
Il faudrait aussi revoir la répartition des serveurs du CDN d'OSM.org, ils
sont trÚs déséquilibrés avec certains serveurs sous-utilisés, et d'autres
visiblement beaucoup trop.
Peut-on contacter des hébergeurs candidats en France ou faire appel à leur
générosité (et les couts sont-ils compatibles?) et pas nécessairement
seulement la fondation Free (ou France-IX qui dessert maintenant beaucoup
mieux l'Afrique), afin de soulager les serveurs espagnols ? On pourrait
même proposer alors de desservir l'Afrique du Sud depuis France-IX à
Marseille plutÎt que les Pays-Bas, et rapatrier à Amsterdam le service de
certains autres pays européens.
Il semble qu'OSM.org manque d'outils pour suivra la capacité et
l'équilibrage de ses serveurs, et reconfigurer facilement et plus
dynamiquement son CDN (avec en conséquence un service de plus en plus
instable, des tuiles qui ne se mettent pas à jour, et des écarts de plus en
plus important selon les caches).
De plus les caches d'OSM.org semblent ne pas être synchronisés (les heures
affichées, les dates de péemtpion et de renouvellement ne sont pas
correctes, il arrive de plus en plus souvent que la même tuile demandée
affiche une seconde avant une nouvelle tuile, puis aprÚs une ancienne et
les écarts dépassent l'heure: il semble bien que ces serveurs ont des
problÚmes de mise à jour de leurs horloges, voire des bogues dans la
gestion des décalages pour le passage à l'heure d'été, ou des difficultés
de connexion à un serveur de temps). Il est par conséquent de plus en plus
difficile d'avoir un rendu homogÚne des cartes (et ceci indépendamment de
la charge et des serveurs de rendus)
_______________________________________________
Talk-fr mailing list
https://lists.openstreetmap.org/listinfo/talk-fr