River Tarnell embauché par Wikimedia Deutschland

River Tarnell (user:Kate) est un très vieux contributeur de Wikipédia (juin 2004) maintenant en wikiretraite, et le principal administrateur système du toolserver (ou l’un des), chose qu’il faisait jusqu’alors bénévolement sur son temps libre.

Il vient d’être embauché comme prestataire par Wikimedia Deutshland afin d’administrer le toolserver, ce qui en fait le premier administrateur système payé dans ce but (temps plein ou temps partiel, je n’ai pas trouvé). Du fait d’heures de travail fixes et dédiées, son embauche aidera à une présence technique/maintenance plus stable ; il se chargera aussi de coordonner les autres volontaires vis à vis de celle ci.

—-

Le toolserver est un groupe de machines possédant une copie (plus ou moins) à jour de la base de données des différents wikis de la Wikimedia Foundation. Il est dédié à l’exécution de scripts/bots/outils en rapport avec le projet (les compteurs d’édition par exemple) et comporte actuellement 13 serveurs. Le toolserver a vu le jour en été 2005 lorsque Sun Microsystems a fait don du premier serveur. Wikimedia Deutschland en finance la maintenance et la majeure partie des achats (historique ici).

Parmi les  bienfaiteurs, on notera :

• Sun (encore eux) qui ont donné un total de 3 serveurs : l’initial zedler, puis hemlock (via la Wikimedia Foundation) et amaranth.
• Wikimedia France (j’en ai parlé !) qui a financé l’achat de licences d’utilisation de Zeus Web Server.
• Kennisnet (le datacenter ou sont stockés les serveurs) pour la bande passante le stockage (au moins une partie des frais)

—-

Wikimedia Deutshland est une association allemande dont le but est de soutenir la Wikimedia Foundation. Vous connaissez sans doute son équivalent français (Wikimédia France) ou suisse (Wikimedia CH). Ces associations sont typiquement appelés « chapter ».

—-

(source)

Le Toolserver nouveau est arrivé, fin

La réplication de s3 est maintenant en route.

Il reste encore 35 heures à rattraper, ce qui, a la vitesse actuelle, nous donnera une base de données parfaitement à jour dans 8 à 9 heures environ.

edit 13:30 > le retard de replication est maintenant rattrapé.

Le Toolserver nouveau est arrivé, suite

ça y est !! il est lààààà !! Le cluster S3, qui avait perdu sa réplication fin décembre dernier, viens d’être remis à jour !

Un peu plus techniquement, un dump SQL viens d’être importé sur la nouvelle machine ou il se trouve (à jour  jusqu’a ~mercredi 4 mars vers 7H, GMT+1), et la réplication pour qu’il soit maintenu à jour devrait être installée incessamment sous peu.

Le toolserver nouveau est arrivé

On les attendais depuis plus d’un mois, les deux nouveaux serveurs qui viennent renforcer le Toolserver sont finalement arrivés ! (source)

Ils sont, au moment ou j’écrit ces lignes, en train d’être installés dans leur rack au datacenter d’Amsterdam

Panne sur le toolserver

il y a environ 40 minutes (22h50 à GMT+1), un problème s’est produit au niveau du toolserver (TS).

Avant de continuer, petit apparté sur le stockage actuel des bases de données sur le TS. Les bases de données (BdD) sont reparties en « clusters » sur le même modèle que leur équivalent sur les serveurs de la WikiMedia Foundation (WMF).

• le cluster S1 contient la BdD de la Wikipédia (WP) anglophone
• le cluster S2 contient la BdD de la WP germanophone et de 18 autres.
• le cluster S3 contient la BdD de notre WP francophone et celle du reste des wikis de la WMF.

Sur le TS, S1 et S3 sont stockés sur le serveur « yarrow » et S2 sur le serveur « Zedler »

Vers 22h50, donc, un bug (du kernel apparement ?) a causé un crash du service MySQL du serveur yarrow. Alertés par mes soins vers 23h05, les administrateurs ont immédiatement fait le necessaire pour réactiver MySQL, qui est actuellement en train de « s’auto-réparer » (pour assurer la consistence des BdD).

Le tout devrait être de nouveau opérationnel d’ici une vingtaine de minutes (23H50 GMT+1)

Edit 23h48 : tout est de nouveau opérationnel

Wikipédia : déménagement de serveurs et conséquences, fin

(Ce post fait référence de ce précédent message sur les problèmes du cluster d’outils web pour Wikipédia situé à Amsterdam, le toolserver, suite à son déménagement)

Donc, j’en était resté au fait que la réplication des bases de données (BdD) de la zone s3 n’étaient pas encore répliquées. J’ai demandé plus d’informations sur le sujet et ça n’est pas bien joyeux.

Afin de pouvoir répliquer les modifications faites sur les BdD de la WikiMedia Foundation (WMF), le toolserver se sert de « logs » de celle ci (le terme technique est « MySQL binlogs »). Or, ces logs prennent beaucoup de place et sont automatiquement effacés au bout de quelques jours. Les plus malins d’entre vous l’auront déjà compris, la date à laquelle s’est arrête la réplication de cette zone est plus ancienne que le plus ancien des logs encore disponible. Et donc, impossible de répliquer car il y a un « trou » sans données et cela causerait des incohérences dans la base.

Du coup, il faut donc refaire une sauvegarde complète coté WMF et la réimporter côté toolserver, et c’est une opération qui prend énormément de temps.

Le toolserver devrait recevoir 2 nouveaux serveurs début février. Comme il faudra de toute façon faire un réimport des BdD après leur installation (la répartition des bases de données va être revue), les techies locaux ont décidé d’attendre et de toute remettre en ordre à ce moment là.

Traduction pour les non geeks : pas d’editcount à jour pour vous jusqu’a février !

Wikipédia : déménagement de serveurs et conséquences, suite

J’annonçais tantôt que le Toolserver était en rade suite au déménagement du cluster de la Wikimedia Foundation situé à Amsterdam.

Donc mise à jour : tout est presque rentré dans l’ordre

• Le serveur est de nouveau en ligne depuis 2/3 jours, donc les scripts ne nécessitant pas de base de données (comme les miens) pouvaient déjà refonctionner sans souci.
• Les bases de données (BdD) des zones  s1 et s3 sont finalement de nouveau en ligne¹ depuis aujourd’hui.
• Cependant, la « réplication » de la zone  s3 n’a pas encore été relancée  – cela veux dire  que tout ce qui date d’avant le 29/12 vers 16H est présent, mais que les éditions faites ensuite n’ont pas encore été recopiées².

————-

1 : pour plus d’information sur « quelle BdD est dans quelle zone », voir ce message et cette page. Pour les plus flemmards d’entre vous, la BdD de la Wikpédia francophone est sur s3

2 : en temps normal, les données sont répliquées en permanence  sur les BdD du toolserver à partir des BdD des serveurs de la WikiMedia Foundation, afin de les maintenir à jour (2/3 infos ici en anglais)

Wikipédia : déménagement de serveurs et conséquences

Je le disais tantôt, la WMF déménage actuellement une partie de ses serveurs.

Conséquence à laquelle je n’avais pas pensé, le toolserver est hors ligne, et donc les nombreux outils facilitant la vie sur Wikipédia qu’il contient ne sont plus accessible. Pour être précis, ces serveurs ont déjà été déplacés au nouvel emplacement et rebranchés,  mais il s’est pour l’instant avéré impossible d’en remettre une partie en état de marche (je n’ai pas tout compris, mais c’est une histoire de serveur NFS )

En ce qui me concerne, le système de bienventuage automatique, ainsi que la suppression automatique des liens vers medias effacés ne sont plus opérationnels.

Je tente de pallier au problème en lançant ces scripts depuis ma machine, mais c’est loin d’être pratique. J’espère  que cette panne du toolserver ne durera pas trop.

Wikipédia et Toolserver

Le Toolserver (TS) est un petit groupe de serveurs géré par Wikimedia Deutschland (détails ici). Il héberge un bon nombre de scripts aux utilités diverses (par exemple, c’est là que je fait tourner mon système de bienvenutage automatique, ainsi qu’un système retirant dans les articles les liens pointant sur des images supprimées)

le TS est un énorme plus pour les projets Wikimedia a plus d’un titre, mais je reste avec l’impression que ses ressources sont mal utilisées.

Voici une petite analyse, prise pendant l’écriture de ce billet, des programmes lancés sur le TS, classés par plus utilisation de mémoire. Pour simplifier, je n’ai gardé que les ~15 premiers. Pour correspondance, 1% de la mémoire correspond à 80Mo. J’ai traduit certaines commandes en quelque chose de compréhensible pour le plus grand nombre.
%MEM COMMAND
5.1 interwiki.py
4.3 interwiki.py
3.9 interwiki.py
3.6 interwiki.py
2.9 (tomcat)
2.6 (pircbot)
1.8 (manageur java)
1.5 (pircbot)
1.5 (pircbot)
1.4 (pircbot)
1.4 (pircbot)
1.3 (pircbot)
1.2 interwiki.py
1.2 (un script python inconnu)
1.1 (linky)
1.0 (linky)
1.0 (pircbot)

Petite explication et consommation mémoire cumulée :

• interwiki.py (13% de la mémoire sur cet échantillon, soit ~1040Mo)
• pircbot et linky (12.8% de la mémoire sur cet échantillon, soit ~1024Mo)

Mon analyse rejoint globalement celle faite sur le blog du toolserver : ces deux éléments plombent plus du quart des ressources mémoire du TS, et pour quels avantages ?

linky/pircbot

Linky et pircbot sont deux bots IRC. Et un bot IRC, ça n’est rien de plus qu’un gadget pour geeks. Vu les fonctionnalités (afficher un lien http lorsque quelqu’un tape un [[lien]] sur le chan, etc), le fait que chaque instance prenne entre 80Mo (1%) et 208Mo (2.6%) de mémoire est tout simplement ridicule. Je suis conscient que c’ets en java, mais quand même, faut pas pousser, là…

Interwiki.py

interwiki.py est un robot interwiki. Contrairement aux bots sus-nommés, l’utilité d’un script interwiki est reconnue. Mais dans le même temps, il n’est pas absolument nécessaires qu’ils tournent en permanence (contrairement, par exemple, à un script qui reverte les vandales en temps réel, comme celui de Salebot).

Par conséquent, les faire tourner sur le TS n’est pas indispensable, surtout vu la charge qu’ils causent. Et ça, il serait grand temps que ses utilisateurs sur TS s’en rendent compte (avec une mention spéciale pour le type qui le lance en double…)
Pour comparer, j’utilise moi même interwiki.py , sur mon ordinateur personnel : il se lance le matin quand j’allume mon ordi, et s’arrête chaque soir lorsque je l’éteind (soit 16H de fonctionnement/jour). Rien de bien sorcier, et ça marche très bien. On ne me fera pas croire qu’il faut une bête de course pour le faire fonctionner, vu que ça fonctionnait très bien sur mon ancien portable, qui était du matos « premier prix » datant de 2002.

Bref : Utilisateurs du TS, pensez un peu aux autres !