Bonjour, Je rejoins Philippe sur l'importance mondiale qu'a prit le projet OSM. Il serait temps de définir une politique accompagnée de ses moyens techniques pour être à la hauteur de toutes ces contributions qui font d'OSM un fabuleux projet mondial. Un genre d'architecture distribuée semble la voix à explorer.
Mes 2 centimes de techos Cyrille. Le 1 avril 2012 17:22, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Ce n'est pas lié directement au changement de licence (qui était déjà > en place puisqu'on ne pouvait plus contribuer en CC-BY-SA), ni au > nettoyage des données (qui aura lieu après le redémarrage du service, > en tâche de fond), mais lié à un changement de serveur. > > Malgré tout, un changement de serveur de base de données aurait pu > avoir lieu bien avant et pourra encore avoir lieu à l'avenir. Je ne > comprends pas la nécessité d'arrêter le service pendant 4 jours, alors > qu'une solution de réplication aurait pu être utilisée, même si elle > prenait du temps pour tout resynchroniser, sans même arrêter le > service. > > Je comprends la nécessité de passer à un serveur plus puissant. Pas > celle d'arrêter le service pendant 4 jours. Cela donne l'impresion > forte que le service n'est pas solide et tehniquement pas au point. Au > lieu de charger le nouveau serveur pendant 4 jours, il aurait > peut-être fallu 15 jours jusqu'à ce que le nouveau serveur soit prêt > (avec juste un lag time de quelques minutes, vite rattrapé quand > l'ancien serveur a arrêté d'accepter les nouvelles données), et > ensuite il n'aurait fallu qu'une interruption de quelques minutes pour > faire la bascule du nouveau serveur miroir en tant que serveur > principal, le temps de reconfigurer routeurs parefeux ou adresses IP > et redémarrer les serveurs. > > L'ancien servant alors de serveur de secours ou pour héberger des > services hors-ligne tels que des l'exécution de certains scripts de > maintenance, ou l'hébergement d'une solution comparable à OSMI/Osmose, > ou l'exécution de tâches comme la génération et la compression des > dumps, ou encore pour augmenter la charge utile de certaines API. > > Bref le projet a besoin depuis longtemps de développer une solution de > réplication en ligne, et cette solution n'a pas été développée. La > solution de l'arrêt complet c'est la solution de facilité mais elle > nuit au projet. > > De meˆme la bses de données aurait pu être splittée en plusieurs > parties, par secteur angulaire, un serveur frontal collectant les > données de l'un ou l'autre pour les accès en lecture (avec un minimum > d'objets stocké dans les deux quand il y a des références mutuelles, > pour l'intégrité référencielle). Pour cela il aurait juste fallu qu'au > delà d'une certaine tranche d'identifiants, chacun puisse générer ses > propres identifiants uniques dans des blocs de numéros préalloués pour > chacun d'eux. > > Si à la prpchaine panne du serveur il faut encore 4 jours pour > remonter un autre serveur, c'est que le projet n'est pas assez solide. > La réplication avec consolidation aurait du être en place depuis > longtemps, vu la taille du projet. > > Le 1 avril 2012 11:03, Christian Quest <cqu...@openstreetmap.fr> a écrit : >> Effet(s) de bord de la migration... >> >> - plus possible de se connecter sur osm.org >> - plus possible d'envoyer des messages à d'autres contributeurs >> >> Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-fr > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
