Ne serait-il pas intéressant de répartir l'administration des services en les dispatchant sur des serveurs virtuels indépendants (par exemple avec XEN) ? TF pourrait ainsi accepter plus facilement de nouveaux admins (en cas de problème, les dégâts sont limités) et la charge de chaque admin serait plus faible (elle se limiterait à la maintenance d'un service).
Combien d'heures par jour à l'administration, la modération, combien de jour par mois, combien de mois par an, combien d'années? Quelle vie nous leur imposons? Quel avenir pour ces jeunes? Même si c'est un choix personnel au départ, je pense que c'est maintenant un sacerdoce bien lourd à porter.
Personnellement c'est un travail à temps plein en sus de mon temps plein chez mon employeur, le temps restant je le passe à dormir. Donc c'est assez facile à calculer, ça doit faire entre 3000 et 4000 heures par an. Si ça peut vous donner une petite idée :)
Ces personnes, si généreuses au départ ne risquent-elles pas de devenir aigri et écœuré par notre attitude?
Tu ne fais pas si bien dire, je pense avoir été le premier à tirer la sonnette d'alarme lors de mon "debriefing" du salon Solution Linux 2008, c'est une vision un peu partielle car elle ne concerne qu'un seul aspect du salon mais est à mon avis généralisable.
Est ce qu'il n'y a pour le moment aucune sauvegarde ? oO
Ou juste des solutions temporaires de sauvegarde ?
Le snapshot n'est plus mis à jour depuis 2 semaines, sinon on plonge TuxFamily dans le noir :)
Le risque de perdre des données est faible, c'est un RAID5 avec des disques qui n'ont jamais posé un seul problème, les pannes du contrôleur n'entraine pas une perte des données (sauf celles qui sont encore dans le cache en écriture du VFS, et encore c'est même pas sûr vu que le journal est externalisé), si jamais elle venait à mourir définitivement on a du matériel similaire en spare capable de lire l'array.
Un petit historique pour faire face aux idées reçues:
Avant
En fait, on ne va pas s'en cacher, pendant très longtemps il n'y avait pas de backups faute de place suffisante disponible.
Le NAS secondaire était trop petit pour accueillir les données, d'ailleurs pendant longtemps il fut indisponible car 2 disques étaient morts sur l'array RAID5, un disque avait claqué quasiment après la mise en baie de la machine mais nous ne le savions pas puis un autre disque avait claqué plus d'un an après. Il y avait à ce moment là la base VHFFS dessus, le billet http://tuxfamily.info/?p=51 témoigne de la panique à bord.
Le 2ème système de stockage du NAS primaire était trop petit pour accueillir une 2ème copie complète des données.
Nous ne disposions pas d'une machine outsourcée avec suffisement de place disponible pour au moins faire une copie des données (même si la source était inutilisable en tant que telle en production).
Il y a pas si longtemps
L'année dernière, j'avais monté une machine chez mon ancien employeur pour avoir au moins une copie outsourcée, elle existe encore mais elle est bientôt pleine, ce fut la seule copie pendant longtemps.
Depuis l'été 2007
Nous avons remis en marche le NAS secondaire, qui possède aujourd'hui un snapshot d'il y a 2 semaines, donc qui sera synchronisé à nouveau quand le NAS primaire sera réparé, il reste encore de la place dessus pour un petit bout de temps.
Le NAS primaire possède assez d'espace pour contenir une 2ème copie en local, mais pas sur des médias assez rapide pour assurer suffisement en production.
Donc il y a des backups en temps normal, mais dans tous les cas il ne faut pas compter dessus, le risque de perte de données est faible mais pas nul (murphy veille toujours).
J'ai lu quelque part (mais je ne sais plus où) quelqu'un qui disait que TuxFamily c'était super car il avait pas besoin de faire des backups car on avait jamais perdu un seul fichier, c'est juste faux, il y eu un méga désastre en 2002, cf http://www.linuxfrench.net/article.php3?id_article=954 , aujourd'hui il y a peu de chance que cela arrive une nouvelle fois. Cet épisode fut d'ailleurs l'occasion d'investir beaucoup pour solidifier tout ça, aujourd'hui c'est toujours cet investissement qui est encore utilisé en production.
Il va falloir que l'on songe a changer les disques à moyen terme, a vu de pif cela devrait nous coûter dans les 2000 EUROS, le truc étant de prévoir bien avant, on peut difficilement mettre en production un système de stockage qu'on a pas testé au moins 6 mois voir 1 an, due au fait que l'accès physique est difficile et que la moindre opération sur les données prend des heures et des heures et des heures.
Pour couper court aux "oui mais le stockage centralisé c'est pas bien tout ça vous devriez faire autrement, plus personne fait ça, blablabla et blobloblo". C'est pour nous une solution simple et surtout la moins cher, un gros espace de stockage coûte moins cher que 10x plus petit avec la même assurance de ne pas perdre de données. Et celui-ci nécessite moins de maintenance et de développement. Sans oublier qu'on fournit un nombre important de services différents et non juste du web mutualisé, ce qui augmente _vraiment_ le temps de développement sur VHFFS et autres proxies applicatif.
C'est ce qu'il semble : depuis quelques heures, le serveur web des projets (web.tuxfamily.net) refuse les connexions HTTP (testé depuis deux accès différents), alors qu'il répond toujours aux ping.
Ouaip, on a un problème avec un filer, le plus chiant c'est que c'est la 2ème fois en 2 semaines...
Concernant le ping c'est un load balancer qui répond, ce n'est pas un très bon test.
Espérons, surtout pour ceux qui devront résoudre le problème, qu'il n'est pas trop grave...
On est dessus, et on espère aussi.
Dans tous les cas on a toutes nos machines à mettre à jour, donc ben c'est juste le bon moment quoi ;)
Je ne vois pas le rapport : que tu loues ou achète ton matériel, ton hébergeur n'a pas d'accès réseau à ta machine (pas de password), et a un accès physique à la machine. Dans les deux cas, il n'a contractuellement (et en pratique idem) pas le droit de regarder dans ta machine.
Qu'est-ce qui fait qu'une machine achetée hébergée pas chez toi est plus sûre coté confidentialité qu'une machine louée hébergée pas chez toi? Dans tous les cas, les données sont la propriété incessible de la personne qui achète ou loue, les données sont autant protégées : dans les deux cas, l'hebergeur viole la loi en regardant, et dans les deux cas il peut.
OK, c'est ton choix de tout acheter, mais donner des raisons comme celle la, pour moi, c'est juste du FUD contre la location que tu nous fais.
Ceci n'a plus vraiment d'objet étant donné la mise à jour de l'article. Il était bien sur question de l'accès aux données de la personne offrant sa machine a GNA! et non de l'opérateur Internet en lui même. Concernant un miroir de téléchargement ce n'est vraiment pas important et cela peut bien sûr être hébergé sur des machines tiers. TuxFamily héberge aussi ces contenus en dehors de son architecture.
Que tu remplaces par ? Non, parce que la tu critiques, mais tu ne donnes pas beaucoup de solutions...
Ce n'était en rien une critique, mais je conçois très bien le fait que cela ait fait réagir, surement trop rapidement mais c'est un bon début et c'était un peu le but, merci :). Je reviendrais plus loin sur les solutions (dont j'ai déjà un peu parlé dans mon post précédent).
Ce n'est pas lost-oasis qui va venir à me secours, car si je compare :
- Kimsufi : minimum 0¤ de frais d'install + 20¤/mois, donc ca me coûte 20¤ pour tester si ça me convient, et le débit testé est largement correct
- Dedibox : 0¤ de frais d'install + 30¤/mois, donc ca me coûte 30¤ pour tester si ça me convient, et le débit testé est largement correct
- Lost-oasis : 220¤ de frais d'install + 60¤/mois, donc ca me coûte 280¤ pour tester si ça me convient, et... Trop cher pour tester donc impossible de savoir ce que ça vaut, voir même trop cher à la base.
Dire que l'hébergement digne de ce nom coûte cher, tu as raison, une baie c'est entre 1000 et 2000 EUR/mois, 100 Mbps de bande passante c'est entre 1000 et 4000 EUR/mois chez un tier2. Quand la solution donnée est "c'est pas grave je vais m'héberger à moindre coût chez un de ces fournisseurs de dédiés à bas prix", c'est la mauvaise. Le logiciel libre est la base d'Internet et Internet est le socle du logiciel libre, la fin d'Internet entrainera celle du logiciel libre, la mort du logiciel libre signera la fin d'Internet. Hop je m'arrête de suite, j'endends déjà le "Internet ca peut pas mourir", en effet pas en tant que tel, en tout cas, pas tout de suite, mais l'Internet tel que nous le connaissons encore un petit peu aujourd'hui à déjà commencé sa décroissance il y a quelques années.
Ca me fait un peu penser coté réseau à ATM : c'est super-mega-genial-debit-garanti, n'empêche qu'aujourd'hui même les gros opérateur telecom, après étude, déploie du gigabit Ethernet de partout, leur calcul de ROI étant plus favorable à la technologie la plus pourrie. Idem pour le protocole IPv4, c'était "mais tu te rend compte, il n'y a rien de garanti, il est pourri ce protocole", n'empêche c'est une peu ce qu'on utilise partout.
C'est un peu hors du sujet. Concernant l'ATM c'est juste car il ne peut dépasser 1.5 Gbps (defective by design), ce qui ne suffit plus aujourd'hui. Je ne vois pas trop ce que ca vient faire dans une problématique "être indépendant ou non".
Pour le prix rien qu'en mensuel de Lost-Oasis (certes, ce n'est pas le même matos, mais le matos fourni pas ceux que tu critiques est amplement suffisant pour beaucoup de sites web), j'ai 1 Kimsufi et 1 Dedibox, deux réseaux à 100 Mbps certes non garantis mais que j'ai pu tester et que ça convient pas mal avec des débits soutenus a 7 Mo/s de download pendant des heures, alors que je n'arrive même pas à savoir quelle est le débit maximum mutualisé chez lost-oasis). 2 machines, 2 réseaux, avant que les deux tombent en panne en même temps... Je me considère suffisamment protégé, par rapport au prix (question de ROI, toujours... Vaut mieux avoir deux trucs à 99% sûr que un truc à 99% sûr...)
Je crois que tu m'as simplement très mal compris, je me suis surement fait mal comprendre :)
La disponibilité et le coût ce sont des problèmes secondaires. Un hébergeur qui héberge des projets libres n'a pas à assurer une dispo de 99.9%, à TuxFamily selon nagios on doit être a 99.5% de dispo ces derniers 12 mois (j'avais jamais regardé auparavant, c'est dire si c'est important...), ca fait un petit 2 jours de down cumulé par an, en comptant les nombreuses nuits sans sommeil concernant la migration de cet été.
Le matériel n'est pas important non plus, à TuxFamily nous avons de nombreuses machines de puissance inférieure à une dédibox ou à une kimsufi, ca suffit très bien pour certain services, TuxFamily est conscient des problèmes énergétique d'aujourd'hui et de demain et essaye d'y faire attention le plus possible.
bref, tu élimines sans argument deux hébergeurs, que proposes-tu à la place dans le même ordre (ou plus) de garantie pour le même prix? Pourquoi serais-je plus indépendant en prenant chez par exemple lost-oasis que si je prend 2 réseaux pas cher? Pourquoi élimines-tu comme ça ces deux hébergeurs? Qu'est-ce qui est pas bien chez eux et 100x mieux chez d'autres? (lesquels?)
L'indépendance ultime c'est de prendre son propre AS et de le gérer. C'est le choix qui a été fait chez TuxFamily. C'est la meilleure des solutions mais elle demande beaucoup d'énergie (les anciens admins de TuxFamily ont du passer la main à cause de ça, ce qui ne veut pas dire qu'ils ne sont plus présents en cas de pépins, merci a eux, vraiment ;).
Dans les tuyaux qui vont bien il y a des gens très très bien comme Gitoyen, sur lequel sont appuyé des excellentes initiatives comme globenet, FDN, Lautre.net... qui sont trop peu nombreuses à mon sens !
Sinon se faire héberger comme le font les grosses distributions dans des universités, c'est aussi très bien.
Mais oui, j'en conviens, ca demande plus d'énergie et de volonté que de louer une dédibox et/ou une kimsufi, avec une box en cadeau et 100 Mbps d'après le media de l'interface réseau à condition que tu les utilises pas et que ca reste dans le réseau que l'opérateur et/ou partent en peering gratuit, sinon gare aux limitations drastique.
(note : je laisse de coté la connexion ADSL mis dans le même panier, la comme c'est du pas sûr du tout et que le débit est pourri, les ROI est vite fait, l'hébergement à la maison est à bannir)
Non ce n'est pas à banir du tout, il y a encore un certain nombre de personnes qui s'hébergent sur leur connexions ADSL et c'est très bien, il faut vraiment qu'ils continuent. Malheureusement il y en a de moins en moins, et hélas ce n'est pas en proportion, mais en nombre, Internet (le contenu autour et les routeurs bètes au centre) à commencé sa decroissance. Tu peux regarder du côté du RHIEN, c'est très bien ce qu'ils font ces petits gens la :) (continuez les gas, vous êtes sur la bonne voie)
Qu'apporte de plus gna! par rapport à un hébergement comme tuxfamily ? Et même question en sens inverse d'ailleurs !
Je ne trouve pas la dépêche assez précise sur ce qui fait la différence.
Je ne pense pas que ce soit très important. De plus il y a déjà des analyses comparatives plutôt objectives voir totalement objectives disponibles.
Ce qui est très important, c'est la diversité, pas dans les offres non, la dessus on fournit tous plus ou moins le même service, soit plutôt orienté developpement, soit plutôt orienté en hébergement universel (et donc moins orienté developpement, en tous cas pas clef en main). TuxFamily fait dans l'hébergement mutualisé universel et ne s'occupe pas de tout ce qui concerne la gestion de projet spécifique aux projets concernant du code, on laisse cette partie la à ceux qui le font bien mieux que nous, par exemple Gna!
Donc je disais, ce qui importe surtout c'est la diversité non pas technique, mais uniquement en tant que nombre. Les gros mammouths (enfin surtout Le gros) de l'hébergement de projets libre qui comptent des dizaines de milliers de projets libres centralisent la quasi totalité du contenu libre. C'est à dire en quelques points majeur de vulnérabilité. Si un petit hébergeur d'un millier de projets tombent, c'est chiant pour les hébergés, mais c'est globalement pas grave. Si le gros mammouth tombe c'est la catastrophe, c'est tout un pan du fragile écosystème qui s'écroule.
Décentralisons le plus possible, montez des petits hébergeurs de projets digne de ce nom, faites en sorte d'être le plus indépendant de votre opérateur de transit (adieu kimsufi, adieu dédibox, adieu connex ADSL chez grosISP), voir montez carrément votre boite pour supporter votre projet, c'est pas dur !
Et aussi, comment vous allez gérer la mise à disposition d'une location de machine, l'engagement contractuel ?
Ca n'engage que moi, mais pour moi c'est une erreur. Je pense qu'il est important que tout le matériel d'un hébergeur lui appartienne, confidentialité des données, tout ça... Tout le matériel utilisé par TuxFamily est la propriété incessible de l'association TuxFamily.org, nous pensons vraiment que c'est très important.
Savez-vous s'il est question d'intégrer Mercurial (HG) aux services de Tuxfamily ?
Pour l'instant non vu qu'on a encore jamais reçu de demandes pour qu'il soit ajouté. (Et qu'il faut qu'on nous le demande plusieurs fois pour nous motiver). Pour Git, relativement peu de gens sont intéressés, en tout cas pas suffisamment pour qu'on se décide à le proposer en nouveau service de notre propre fait, c'est un amoureux de Git qui nous a fournit un patch (qui fut d'ailleurs quasi parfait) à VHFFS, il n'y avait alors plus aucune raison que ne le propose pas en nouveau service :)
Chaque service supplémentaire c'est du temps de devel (surtout), et de maintenance en plus. Pas forcément beaucoup, mais les petit ruisseaux font les grandes rivières.
Conclusion, si vous voulez un nouveau service sur TuxFamily, demandez-nous si on prêt à le mettre en production et ensuite rajoutez la gestion de ce service à VHFFS.
Si techniquement Mercurial et Git se valent et ont chacun leurs aficionados, j'ai l'impression que Git est entrain de prendre le dessus au niveau de la popularité au sein de la communauté du libre ? Me trompe-je ?
On a reçu quelques demandes pour Git et 0 pour tous les autres de son genre, vous pouvez conclure vous même :)
Dans les deux cas l'affirmation du wiki tuxfamily est totalement erronée.
C'est juste qu'il n'est pas a jour... d'ailleurs c'est un wiki tu peux te loguer puis le modifier et contribuer utilement !
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.
Si le stockage n'est pas centralisé, cela complique la gestion. Deja l'architecture décentralisé est plus complexe, il faut donc plus de gens pour la gérer (et oui). Ensuite, il faut plus de matériel, car cela sous entend d'avoir du stockage sur chaque serveur web, et de le dupliquer (et j'imagine même pas comment gérer simplement le basculement d'une panne d'un serveur web sur un autre en cas de problème, les solutions libres ne sont vraiment pas encore au point, et TuxFamily n'utilise que du libre, par principe). Un problème final s'ajoute à cela, le cout, si tu as 10K Euros à nous donner pour qu'on mette cela en place, on les prend sans problème et on le met en place ! Et pour finir, actuellement on a très peu d'accès disque, on a déplacé la grosse consommation d'accès disque (aka les gros fichiers statiques, iso, ...) sur une 2ème architecture et on a énormement de cache sur le serveur NFS (et oui, payer plusieurs GB de mémoire une fois on peut se le permettre, 10x on peut pas).
Ah oui aussi, même si le service web est le plus consommateur, ca fait juste parti d'un des services qu'on fournit, ca complique légérement la décentralisation (sans oublier la gestion des quotas) :-)
Et pour la croissance on gère, aujourd'hui ça va, demain, on verra !, le problème n'est pas technique, il est de temps et d'argent ! :)
Ils sont rigolos les guignols de chez TuxFamily. Je cite :
"Pour PHP, en cas de gros soucis de charge, on peut utiliser eaccelerator, avec perl et python on est coincés."
Alors qu'eaccelerator n'est un cache de bytecode, qui existe en standard avec Python (fichiers .pyc)
C'est toujours agréable ces gentils mots... mais bon passons
Bon alors en finalité, php est si rapide à compiler son code que les performances sont plutôt moins bonne (en tous cas ça ne change presque rien) si on va lire le bytecode en cache disque (même sur des disques SCSI à 10K). Ce n'est pas vrai si le bytecode est stocké en mémoire en shared memory, mais pour cela en mutualisé il faut plusieurs giga de mémoire sur chaque serveur web, ou alors distribuer les sites sur les noeuds, mais ce n'est pas dans la philosophie de TuxFamily de brider un site sur un seul serveur web (service équivalent pour tout le monde, n'importe quand).
De memoire le serveur de linuxfr c'est un hexaproc, un load de 6 sur un hexaproc ca veut dire qu'il y a un process qui attend du CPU ou une reponse a un I/O par CPU. Comprendre: c'est une petite charge, ca pourrait monter a 40 sans probleme.
Ceci dit il ne faut pas oublier que ce n'est pas le seul site qui tourne sur la machine de linuxfr (uucpssh, ...), j'ai oublie si le load indique dans un vserver est celui de la ""VM"" ou de la machine totale.
Francofolibre possède un serveur dédié 100 Mb/s (UP et Down)
C'est faux, la bande passante n'est pas dédié sur les dedibox, il s'agit de bande passante mutalisé. Les machines sont raccordées sur le réseau local en Fast Ethernet (donc 100 Mbits.s-1), donc il s'agit de la bande passante atteignable dans le meilleur des cas, et je suppose qu'elle ne l'est pas (en tout cas plus le temps passera et moins ca le sera).
Par rapport a un mégadrive, le proc et 10 à 30 fois plus rapide.
Humm... comparer un pic a un 68k quelle horreur !
Vous avez pense a utiliser un coldfire a la place du pic ? Ca coute pas tres tres cher et les performances sont vraiment au rendez-vous. Le PCB est pas forcement facile a realiser mais c'est pas insurmontable non plus.
C'est une archi mutu tout fait standard, exactement la meme que celle trouve chez tout les hébergeurs mutu de masse/discount, au niveau logiciel c'est du vhffs avec ses outils par défaut
> ainsi que les généreux donnateurs de ressources. Je suppose qu'elle existe.
Excellente remarque, faut que nous songions a la refaire :)
Hummm c'est possible en effet, quand nous avions vu avec eux, ils étaient entrain de monter quelque chose de plus officiel pour ces hébergements gracieux, je les recontacterais pour avoir plus d'informations à ce sujet :)
arf.. ils les louent si tu preferes, et effectivement ca change tout a propos de la modifications de sources sous licences GPL sans redistribution des modifications.
Exactement, free un principalement un fournisseur d'accès, donc ils ont beaucoup plus de download que d'upload, en conséquence ils ont de l'upload disponible (la bande passante est payé sur le plus gros des deux). C'est pour ca qu'il peuvent fournir ce genre de service gracieusement (attention il faut quand meme être une association relativement connue), c'est aussi pour ca qu'il peuvent vendre des dedibox par cher, en plus la majorité du traffic doit être utilisé par des abonnées free, pas bête ;).
Comme indiqué, free offre juste le transit (et aussi l'alimentation électrique), le matériel appartient donc à TuxFamily. D'autres machines d'associations siègent au sein de cet espace réservé à cet usage, notamment vlc, l'apinc, l'aduf, ...
[^] # Re: Fondation Free ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Les temps sont durs chez TuxFamily.org. Évalué à 2.
On a bien 2 machines à la fondation free depuis plus de 10 ans ;-) Avant même que la fondation existe d'ailleurs.
On doit pas être assez important pour être indiqué, on a vraiment que 2U dans un petit coin.
Sylvain
[^] # Re: sources?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche TuxFamily.org, l'hébergeur chat-l'heureux. Évalué à 1.
[^] # Re: et le rhien ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Entretien avec l'hébergeur Toile Libre. Évalué à 2.
Et en effet, tu as biaisé l'interview du fait de tes questions trop ciblées.
Sylvain
[^] # Re: "Esclave" du Libre????
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative. Évalué à 3.
Ça existe vraiment ailleurs que sur la fiche de paie ? :-)
C’est une honte de cumuler 3 emplois alors qu’il y a tant de chômage !
Surtout quand on le fait bénévolement, c'est la honte ces gens qui travaillent pour pas un rond ! :>
[^] # Re: tuxfamilly
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative. Évalué à 2.
C'est déjà le cas.
[^] # Re: "Esclave" du Libre????
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative. Évalué à 5.
Personnellement c'est un travail à temps plein en sus de mon temps plein chez mon employeur, le temps restant je le passe à dormir. Donc c'est assez facile à calculer, ça doit faire entre 3000 et 4000 heures par an. Si ça peut vous donner une petite idée :)
Ces personnes, si généreuses au départ ne risquent-elles pas de devenir aigri et écœuré par notre attitude?
Tu ne fais pas si bien dire, je pense avoir été le premier à tirer la sonnette d'alarme lors de mon "debriefing" du salon Solution Linux 2008, c'est une vision un peu partielle car elle ne concerne qu'un seul aspect du salon mais est à mon avis généralisable.
http://lists.parinux.org/pipermail/village-assoces/2008-Febr(...)
Sylvain
[^] # Re: tuxfamilly
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche L'hébergeur TuxFamily appelle les adeptes du libre à soutenir leur initiative. Évalué à 4.
Ou juste des solutions temporaires de sauvegarde ?
Le snapshot n'est plus mis à jour depuis 2 semaines, sinon on plonge TuxFamily dans le noir :)
Le risque de perdre des données est faible, c'est un RAID5 avec des disques qui n'ont jamais posé un seul problème, les pannes du contrôleur n'entraine pas une perte des données (sauf celles qui sont encore dans le cache en écriture du VFS, et encore c'est même pas sûr vu que le journal est externalisé), si jamais elle venait à mourir définitivement on a du matériel similaire en spare capable de lire l'array.
Un petit historique pour faire face aux idées reçues:
Avant
En fait, on ne va pas s'en cacher, pendant très longtemps il n'y avait pas de backups faute de place suffisante disponible.
Le NAS secondaire était trop petit pour accueillir les données, d'ailleurs pendant longtemps il fut indisponible car 2 disques étaient morts sur l'array RAID5, un disque avait claqué quasiment après la mise en baie de la machine mais nous ne le savions pas puis un autre disque avait claqué plus d'un an après. Il y avait à ce moment là la base VHFFS dessus, le billet
http://tuxfamily.info/?p=51 témoigne de la panique à bord.
Le 2ème système de stockage du NAS primaire était trop petit pour accueillir une 2ème copie complète des données.
Nous ne disposions pas d'une machine outsourcée avec suffisement de place disponible pour au moins faire une copie des données (même si la source était inutilisable en tant que telle en production).
Il y a pas si longtemps
L'année dernière, j'avais monté une machine chez mon ancien employeur pour avoir au moins une copie outsourcée, elle existe encore mais elle est bientôt pleine, ce fut la seule copie pendant longtemps.
Depuis l'été 2007
Nous avons remis en marche le NAS secondaire, qui possède aujourd'hui un snapshot d'il y a 2 semaines, donc qui sera synchronisé à nouveau quand le NAS primaire sera réparé, il reste encore de la place dessus pour un petit bout de temps.
Le NAS primaire possède assez d'espace pour contenir une 2ème copie en local, mais pas sur des médias assez rapide pour assurer suffisement en production.
Donc il y a des backups en temps normal, mais dans tous les cas il ne faut pas compter dessus, le risque de perte de données est faible mais pas nul (murphy veille toujours).
J'ai lu quelque part (mais je ne sais plus où) quelqu'un qui disait que TuxFamily c'était super car il avait pas besoin de faire des backups car on avait jamais perdu un seul fichier, c'est juste faux, il y eu un méga désastre en 2002, cf http://www.linuxfrench.net/article.php3?id_article=954 , aujourd'hui il y a peu de chance que cela arrive une nouvelle fois. Cet épisode fut d'ailleurs l'occasion d'investir beaucoup pour solidifier tout ça, aujourd'hui c'est toujours cet investissement qui est encore utilisé en production.
Il va falloir que l'on songe a changer les disques à moyen terme, a vu de pif cela devrait nous coûter dans les 2000 EUROS, le truc étant de prévoir bien avant, on peut difficilement mettre en production un système de stockage qu'on a pas testé au moins 6 mois voir 1 an, due au fait que l'accès physique est difficile et que la moindre opération sur les données prend des heures et des heures et des heures.
Pour couper court aux "oui mais le stockage centralisé c'est pas bien tout ça vous devriez faire autrement, plus personne fait ça, blablabla et blobloblo". C'est pour nous une solution simple et surtout la moins cher, un gros espace de stockage coûte moins cher que 10x plus petit avec la même assurance de ne pas perdre de données. Et celui-ci nécessite moins de maintenance et de développement. Sans oublier qu'on fournit un nombre important de services différents et non juste du web mutualisé, ce qui augmente _vraiment_ le temps de développement sur VHFFS et autres proxies applicatif.
Sylvain
[^] # Re: Effectivement
Posté par Sylvain Rochet (site web personnel) . En réponse au journal TuxFamily HS ?. Évalué à 5.
# Glouglou
Posté par Sylvain Rochet (site web personnel) . En réponse au journal TuxFamily HS ?. Évalué à 9.
C'est ce qu'il semble : depuis quelques heures, le serveur web des projets (web.tuxfamily.net) refuse les connexions HTTP (testé depuis deux accès différents), alors qu'il répond toujours aux ping.
Ouaip, on a un problème avec un filer, le plus chiant c'est que c'est la 2ème fois en 2 semaines...
Concernant le ping c'est un load balancer qui répond, ce n'est pas un très bon test.
Espérons, surtout pour ceux qui devront résoudre le problème, qu'il n'est pas trop grave...
On est dessus, et on espère aussi.
Dans tous les cas on a toutes nos machines à mettre à jour, donc ben c'est juste le bon moment quoi ;)
[^] # Re: Erreur a la compilation
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Le code source de SimCity libéré. Évalué à 2.
[^] # Re: Hébergement
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche gna.org à la recherche de machines hébergées. Évalué à 2.
Ceci n'a plus vraiment d'objet étant donné la mise à jour de l'article. Il était bien sur question de l'accès aux données de la personne offrant sa machine a GNA! et non de l'opérateur Internet en lui même. Concernant un miroir de téléchargement ce n'est vraiment pas important et cela peut bien sûr être hébergé sur des machines tiers. TuxFamily héberge aussi ces contenus en dehors de son architecture.
[^] # Re: Hébergement
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche gna.org à la recherche de machines hébergées. Évalué à 2.
Ce n'était en rien une critique, mais je conçois très bien le fait que cela ait fait réagir, surement trop rapidement mais c'est un bon début et c'était un peu le but, merci :). Je reviendrais plus loin sur les solutions (dont j'ai déjà un peu parlé dans mon post précédent).
Dire que l'hébergement digne de ce nom coûte cher, tu as raison, une baie c'est entre 1000 et 2000 EUR/mois, 100 Mbps de bande passante c'est entre 1000 et 4000 EUR/mois chez un tier2. Quand la solution donnée est "c'est pas grave je vais m'héberger à moindre coût chez un de ces fournisseurs de dédiés à bas prix", c'est la mauvaise. Le logiciel libre est la base d'Internet et Internet est le socle du logiciel libre, la fin d'Internet entrainera celle du logiciel libre, la mort du logiciel libre signera la fin d'Internet. Hop je m'arrête de suite, j'endends déjà le "Internet ca peut pas mourir", en effet pas en tant que tel, en tout cas, pas tout de suite, mais l'Internet tel que nous le connaissons encore un petit peu aujourd'hui à déjà commencé sa décroissance il y a quelques années.
C'est un peu hors du sujet. Concernant l'ATM c'est juste car il ne peut dépasser 1.5 Gbps (defective by design), ce qui ne suffit plus aujourd'hui. Je ne vois pas trop ce que ca vient faire dans une problématique "être indépendant ou non".
Je crois que tu m'as simplement très mal compris, je me suis surement fait mal comprendre :)
La disponibilité et le coût ce sont des problèmes secondaires. Un hébergeur qui héberge des projets libres n'a pas à assurer une dispo de 99.9%, à TuxFamily selon nagios on doit être a 99.5% de dispo ces derniers 12 mois (j'avais jamais regardé auparavant, c'est dire si c'est important...), ca fait un petit 2 jours de down cumulé par an, en comptant les nombreuses nuits sans sommeil concernant la migration de cet été.
Le matériel n'est pas important non plus, à TuxFamily nous avons de nombreuses machines de puissance inférieure à une dédibox ou à une kimsufi, ca suffit très bien pour certain services, TuxFamily est conscient des problèmes énergétique d'aujourd'hui et de demain et essaye d'y faire attention le plus possible.
L'indépendance ultime c'est de prendre son propre AS et de le gérer. C'est le choix qui a été fait chez TuxFamily. C'est la meilleure des solutions mais elle demande beaucoup d'énergie (les anciens admins de TuxFamily ont du passer la main à cause de ça, ce qui ne veut pas dire qu'ils ne sont plus présents en cas de pépins, merci a eux, vraiment ;).
Dans les tuyaux qui vont bien il y a des gens très très bien comme Gitoyen, sur lequel sont appuyé des excellentes initiatives comme globenet, FDN, Lautre.net... qui sont trop peu nombreuses à mon sens !
Sinon se faire héberger comme le font les grosses distributions dans des universités, c'est aussi très bien.
Mais oui, j'en conviens, ca demande plus d'énergie et de volonté que de louer une dédibox et/ou une kimsufi, avec une box en cadeau et 100 Mbps d'après le media de l'interface réseau à condition que tu les utilises pas et que ca reste dans le réseau que l'opérateur et/ou partent en peering gratuit, sinon gare aux limitations drastique.
Non ce n'est pas à banir du tout, il y a encore un certain nombre de personnes qui s'hébergent sur leur connexions ADSL et c'est très bien, il faut vraiment qu'ils continuent. Malheureusement il y en a de moins en moins, et hélas ce n'est pas en proportion, mais en nombre, Internet (le contenu autour et les routeurs bètes au centre) à commencé sa decroissance. Tu peux regarder du côté du RHIEN, c'est très bien ce qu'ils font ces petits gens la :) (continuez les gas, vous êtes sur la bonne voie)
[^] # Re: Information complémentaire
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche gna.org à la recherche de machines hébergées. Évalué à 8.
Je ne pense pas que ce soit très important. De plus il y a déjà des analyses comparatives plutôt objectives voir totalement objectives disponibles.
Ce qui est très important, c'est la diversité, pas dans les offres non, la dessus on fournit tous plus ou moins le même service, soit plutôt orienté developpement, soit plutôt orienté en hébergement universel (et donc moins orienté developpement, en tous cas pas clef en main). TuxFamily fait dans l'hébergement mutualisé universel et ne s'occupe pas de tout ce qui concerne la gestion de projet spécifique aux projets concernant du code, on laisse cette partie la à ceux qui le font bien mieux que nous, par exemple Gna!
Donc je disais, ce qui importe surtout c'est la diversité non pas technique, mais uniquement en tant que nombre. Les gros mammouths (enfin surtout Le gros) de l'hébergement de projets libre qui comptent des dizaines de milliers de projets libres centralisent la quasi totalité du contenu libre. C'est à dire en quelques points majeur de vulnérabilité. Si un petit hébergeur d'un millier de projets tombent, c'est chiant pour les hébergés, mais c'est globalement pas grave. Si le gros mammouth tombe c'est la catastrophe, c'est tout un pan du fragile écosystème qui s'écroule.
Décentralisons le plus possible, montez des petits hébergeurs de projets digne de ce nom, faites en sorte d'être le plus indépendant de votre opérateur de transit (adieu kimsufi, adieu dédibox, adieu connex ADSL chez grosISP), voir montez carrément votre boite pour supporter votre projet, c'est pas dur !
Ca n'engage que moi, mais pour moi c'est une erreur. Je pense qu'il est important que tout le matériel d'un hébergeur lui appartienne, confidentialité des données, tout ça... Tout le matériel utilisé par TuxFamily est la propriété incessible de l'association TuxFamily.org, nous pensons vraiment que c'est très important.
[^] # Re: Et mercurial ?
Posté par Sylvain Rochet (site web personnel) . En réponse au journal GIT dispo chez TuxFamily.org. Évalué à 3.
Pour l'instant non vu qu'on a encore jamais reçu de demandes pour qu'il soit ajouté. (Et qu'il faut qu'on nous le demande plusieurs fois pour nous motiver). Pour Git, relativement peu de gens sont intéressés, en tout cas pas suffisamment pour qu'on se décide à le proposer en nouveau service de notre propre fait, c'est un amoureux de Git qui nous a fournit un patch (qui fut d'ailleurs quasi parfait) à VHFFS, il n'y avait alors plus aucune raison que ne le propose pas en nouveau service :)
Chaque service supplémentaire c'est du temps de devel (surtout), et de maintenance en plus. Pas forcément beaucoup, mais les petit ruisseaux font les grandes rivières.
Conclusion, si vous voulez un nouveau service sur TuxFamily, demandez-nous si on prêt à le mettre en production et ensuite rajoutez la gestion de ce service à VHFFS.
On a reçu quelques demandes pour Git et 0 pour tous les autres de son genre, vous pouvez conclure vous même :)
[^] # Re: Incompatibilités ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 5.
C'est juste qu'il n'est pas a jour... d'ailleurs c'est un wiki tu peux te loguer puis le modifier et contribuer utilement !
Pour ce qui est de la RAM elle coûte de moins en moins cher, aucune raison de s'en priver, d'autant que vu le working set d'un hébergement mutualisé il vaut mieux en avoir de la RAM...
Il me semble que c'est ce que fait n'importe quel hébergeur qui pense un peu à se prémunir de la croissance du nombre d'utilisateurs. La solution de tout mettre sur un gros disque réseau partagé (type NFS) me semble totalement injustifiée vu les dégradations probables en performances et robustesse.
Si le stockage n'est pas centralisé, cela complique la gestion. Deja l'architecture décentralisé est plus complexe, il faut donc plus de gens pour la gérer (et oui). Ensuite, il faut plus de matériel, car cela sous entend d'avoir du stockage sur chaque serveur web, et de le dupliquer (et j'imagine même pas comment gérer simplement le basculement d'une panne d'un serveur web sur un autre en cas de problème, les solutions libres ne sont vraiment pas encore au point, et TuxFamily n'utilise que du libre, par principe). Un problème final s'ajoute à cela, le cout, si tu as 10K Euros à nous donner pour qu'on mette cela en place, on les prend sans problème et on le met en place ! Et pour finir, actuellement on a très peu d'accès disque, on a déplacé la grosse consommation d'accès disque (aka les gros fichiers statiques, iso, ...) sur une 2ème architecture et on a énormement de cache sur le serveur NFS (et oui, payer plusieurs GB de mémoire une fois on peut se le permettre, 10x on peut pas).
Ah oui aussi, même si le service web est le plus consommateur, ca fait juste parti d'un des services qu'on fournit, ca complique légérement la décentralisation (sans oublier la gestion des quotas) :-)
Et pour la croissance on gère, aujourd'hui ça va, demain, on verra !, le problème n'est pas technique, il est de temps et d'argent ! :)
[^] # Re: Incompatibilités ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 3.
"Pour PHP, en cas de gros soucis de charge, on peut utiliser eaccelerator, avec perl et python on est coincés."
Alors qu'eaccelerator n'est un cache de bytecode, qui existe en standard avec Python (fichiers .pyc)
C'est toujours agréable ces gentils mots... mais bon passons
Bon alors en finalité, php est si rapide à compiler son code que les performances sont plutôt moins bonne (en tous cas ça ne change presque rien) si on va lire le bytecode en cache disque (même sur des disques SCSI à 10K). Ce n'est pas vrai si le bytecode est stocké en mémoire en shared memory, mais pour cela en mutualisé il faut plusieurs giga de mémoire sur chaque serveur web, ou alors distribuer les sites sur les noeuds, mais ce n'est pas dans la philosophie de TuxFamily de brider un site sur un seul serveur web (service équivalent pour tout le monde, n'importe quand).
# Load
Posté par Sylvain Rochet (site web personnel) . En réponse au journal Un peu de blé pour linuxfr.. Évalué à 8.
Ceci dit il ne faut pas oublier que ce n'est pas le seul site qui tourne sur la machine de linuxfr (uucpssh, ...), j'ai oublie si le load indique dans un vserver est celui de la ""VM"" ou de la machine totale.
# Dedibox...
Posté par Sylvain Rochet (site web personnel) . En réponse au journal francofolibre : portail communautaire libre. Évalué à 4.
C'est faux, la bande passante n'est pas dédié sur les dedibox, il s'agit de bande passante mutalisé. Les machines sont raccordées sur le réseau local en Fast Ethernet (donc 100 Mbits.s-1), donc il s'agit de la bande passante atteignable dans le meilleur des cas, et je suppose qu'elle ne l'est pas (en tout cas plus le temps passera et moins ca le sera).
[^] # Re: À propos de games.tuxfamily.net
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Open Arena finit de libérer Quake III. Évalué à 2.
[^] # Re: Recompiler un jeu pour le PIC ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche projet Dogs : ordinateur - console de jeux libre. Évalué à 2.
Humm... comparer un pic a un 68k quelle horreur !
Vous avez pense a utiliser un coldfire a la place du pic ? Ca coute pas tres tres cher et les performances sont vraiment au rendez-vous. Le PCB est pas forcement facile a realiser mais c'est pas insurmontable non plus.
[^] # Re: Lien Gigabit
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Tuxfamily propose un nouveau service de téléchargement. Évalué à 2.
C'est une archi mutu tout fait standard, exactement la meme que celle trouve chez tout les hébergeurs mutu de masse/discount, au niveau logiciel c'est du vhffs avec ses outils par défaut
> ainsi que les généreux donnateurs de ressources. Je suppose qu'elle existe.
Excellente remarque, faut que nous songions a la refaire :)
[^] # Re: Lien Gigabit
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Tuxfamily propose un nouveau service de téléchargement. Évalué à 1.
[^] # Re: p2p ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Tuxfamily propose un nouveau service de téléchargement. Évalué à 2.
[^] # Re: p2p ?
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Tuxfamily propose un nouveau service de téléchargement. Évalué à 7.
[^] # Re: Lien Gigabit
Posté par Sylvain Rochet (site web personnel) . En réponse à la dépêche Tuxfamily propose un nouveau service de téléchargement. Évalué à 7.