A mon avis, ce coup-ci, une chose au moins risque d'être perdue, ce sont les mails, car même les redirects ne marchent plus, j'en déduis donc (peut-être à tort) que les serveurs SMTP ont été arrêtés, donc il y a des chances que certains mails (quand le serveur SMTP envoyeur a été configuré un peu scrictement) soient définitivement perdus...
Je devine que le problème doit être que les comptes mails en POP3 sont hébergés sur le serveur de stockage qui a planté, et que, considérant le nombre de développeurs (1058) utilisant TF (dont une partie significative a dû choisir le POP3 et s'abonner à quelques mailing-listes de projets libres, comme la lkml, plus peut etre bugtraq ou autres), la queue entrante des serveurs SMTP s'est retrouvée remplie (ou à peu près), et qu'ils ont préféré les stopper. A leur place, je supprimerait la possibilité d'avoir du POP3, ça soulagerait un peut le serveur de stockage qui doit être méchamment chawaté à cause de ça... Mais bon, tout ça ne sont que devinettes. Quelqu'un confirme/infirme/explique ?
En conclusion, et à mon avis encore, TF est vistime de son succès. Vaut mieux leur donner de l'argent si on veut qu'ils continuent.
Non, nous avons un MX secondaire qui stocke les mails en attendant.
Concernant les pbs, c'est, à mon avis, plus des problèmes physiques de disques (qui sont pas mal sollicités) que des services qui sont offerts.
Il est vrai que notre maigre budget ne nous permets pas d'avoir des bêtes de courses (quoi que ;)) et que l'essentiel des contraintes se trouvent sur la machine de stockage. N'ayant pas les moyens de nous offrir autre chose que du raid soft, nous en subissons, malheureusement, les conséquences, qui étaient, somme toute, inattendues.
okay :-) c'est dommage quand même que le MX secondaire de relaie pas les forwards au moins... en plus, ça augmenterait ça capacité de stockage pour les comptes POP3... enfin c'est pas très important, du moment que les mails ne sont pas perdus...
de plus, en quoi le RAID logiciel pose un problème ? que les disques plantent, ça je peux comprendre (surtout si ce sont des IBMs ;-)), mais le RAID logiciel par rapport au RAID matériel, quel est le problème ? Dans ma boite les serveurs internes sont en RAID1 sous Linux, et ça marche plutôt bien...
en tous cas, je suis rassuré, mais je réitère: bon courage ! :-)
En ce qui concerne le MX secondaire il est là pour ces coups durs. Donc si le stockage est inaccessible, il temporise, c'est son but.
Le fait que ce soit du RAID soft engendre quelques contraintes:
- le raid soft n'est pas aussi performant que le raid hard;
- le raid soft c'est pas cher;
- le raid soft avec des disques IBM c'est pas bien ;)
En fait tout dépend du niveau de sollicitation des données. Mais nous ne sommes pas insatisfait du raid soft. Nous l'utilisons donc nous l'aimons ;)
a ca propos, est-ce que toutes ces cartes meres avec ide-raid font bien du raid HARD.
j'ai entendu dire que certaines faisaient du raid SOFT (codé dans le bios -- utilise le cpu -- c'est mal).
le raid soft n'est pas aussi performant que le raid hard
Quelle différence de performance as-tu réellement constaté ? Ou tu parles juste à priori ?
J'ai été surpris des faibles performances d'une carte IBM ServeRAID 3L, dans un Netfinity bi-PIII 733 MHz. Alors que le débit brut (mesuré avec hdparm) sur un seul disque faisait 20 Mo/s (des IBM SCSI 9 Go 7200 tr/min), les 2 disques en *miroir* (RAID-1) avaient un débit de 7 à 10 Mo/s (et 14 en écriture, à n'y rien comprendre).
donc il y a des chances que certains mails (quand le serveur SMTP envoyeur a été configuré un peu scrictement) soient définitivement perdus...
Aucun FAI digne de ce nom ne laisse un timeout inferieur a 3 jours. Il se peut que des fous bouncent les mails en quelques heures mais je doute que ca soit des FAIs majeurs/serieux.
Donc ca va spooler chez les serveurs des FAIs meme si le reseau devient injoignable.
Evidemment, si la panne depasse quelques jours, les mails vont bouncer mais les envoyeurs recevront alors un message pour signaler que le message original n'a pas ete delivre.
Ce n'est pas pour rien que j'ai mis digne de ce nom.
Je sais tres bien que certains font n'importe quoi avec le mail de leurs abonnés mais ce n'est pas parce que ce sont des "gros" (en terme du nombre d'abonnés actifs) que cela devient acceptable ou recommandé.
On ne peut qu'esperer que ce type de configuration stupide leur coute suffisamment de clients pour qu'ils se sentent obliges de faire des progres.
je suis d'accord avec toi, mais j'ai bien peur que Yahoo, justement, soient tellement gros qu'ils n'en ont rien à foutre....
Nerim s'est fait blacklister par erreur un MX par Yahoo il y a quelques temps, et ils ont jamais réussi à en ressortir de la blacklist.
C'est par parce que Yahoo c'est de la m... qu'ils ont pas une base d'utilisateurs énorme, hélas... Quand à ce qui est acceptable ou recommandé, je crois que parfois il faut savoir s'adapter, sans quoi on se ghettoise, du moins jusqu'à ce qu'on soit d'un poids suffisant pour faire changer les autres. De plus Yahoo c'est les champions de l'incohérence, avec un business model plutot proprio, mais des serveurs sous FreeBSD et Linux...
"c'est les champions de l'incohérence, avec un business model plutot proprio, mais des serveurs sous FreeBSD et Linux..."
ben non. une entreprise est là pour entretenir le culte de l'argent, Yahoo, comme d'autres, prend ce qu'il y a de plus économique, de plus rentable à chaque fois.
S'ils se sont tournés vers Linux et FreeBSD, c'est parceque c'était ce qui leur revenait le moins cher, à service équivalent, par rapport à d'autres solutions.
Ca n'a donc rien d'incohérant, c'est juste qu'ils ne sont pas là pour entretenir la philosophie du Libre mais pour faire du fric.
Ou si vous voulez à quoi le malheur peut-il servir ?
L'équipe de Tux Family a maintenant acquis une solide expérience sur les techniques de sauvegarde et de restauration.
La preuve est que le dernier crash a été restauré plus vite que celui d'avant. Le vrai professionalisme quoi... Bravo Igor !
J'en profite pour vous donner cet adage de vieil informaticien (parce qu'il n'y a pas de vieil adage en informatique ;) qui dit que :
«Un système informatique n'a pas d'autre valeur que celle de ses sauvegardes».
Ca y est, on a isolé le problème (c'est un bien grand mot), on a du procéder au remplacement de la carte mère, processeur, mémoire de la machine de stockage. Tout les problèmes précedents découlent certainement de d'une de ces parties qui c'est mise à dysfonctionner de plus en plus gravement jusqu'à ne plus pouvoir booter jusqu'a la fin le noyau FreeBSD.
Il y a de la perte dans les bases de données, mais tout semble de retour pour ce qui est des CVS et des sites Web.
Merci de votre compréhension, on s'est battu toute la nuit pour essayer de réparer le système, pour finalement, après nombre de changement de paramètres de configuration, reconstruction de l'array raid, recopie des données et reboot, ce rendre compte le lendemain matin; qu'elle ne voulait plus booter...
Ca y est le problème c'est enfin dévoilé dans toute sa gravité ... et on y a remédié avec les moyens du bord.
PS: Si vous avez une carte mère SMP bi PIII avec les PIIIs qui vont avec, l'association est preneuse (don, ou vente à vraiment pas cher)
# choses perdues...
Posté par anonyme512 . Évalué à 10.
Je devine que le problème doit être que les comptes mails en POP3 sont hébergés sur le serveur de stockage qui a planté, et que, considérant le nombre de développeurs (1058) utilisant TF (dont une partie significative a dû choisir le POP3 et s'abonner à quelques mailing-listes de projets libres, comme la lkml, plus peut etre bugtraq ou autres), la queue entrante des serveurs SMTP s'est retrouvée remplie (ou à peu près), et qu'ils ont préféré les stopper. A leur place, je supprimerait la possibilité d'avoir du POP3, ça soulagerait un peut le serveur de stockage qui doit être méchamment chawaté à cause de ça... Mais bon, tout ça ne sont que devinettes. Quelqu'un confirme/infirme/explique ?
En conclusion, et à mon avis encore, TF est vistime de son succès. Vaut mieux leur donner de l'argent si on veut qu'ils continuent.
Bon courage les gars...
[^] # Re: choses perdues...
Posté par Igor Genibel (site web personnel) . Évalué à 10.
Concernant les pbs, c'est, à mon avis, plus des problèmes physiques de disques (qui sont pas mal sollicités) que des services qui sont offerts.
Il est vrai que notre maigre budget ne nous permets pas d'avoir des bêtes de courses (quoi que ;)) et que l'essentiel des contraintes se trouvent sur la machine de stockage. N'ayant pas les moyens de nous offrir autre chose que du raid soft, nous en subissons, malheureusement, les conséquences, qui étaient, somme toute, inattendues.
Voilà pour les éclaircissement
[^] # Re: choses perdues...
Posté par anonyme512 . Évalué à 10.
de plus, en quoi le RAID logiciel pose un problème ? que les disques plantent, ça je peux comprendre (surtout si ce sont des IBMs ;-)), mais le RAID logiciel par rapport au RAID matériel, quel est le problème ? Dans ma boite les serveurs internes sont en RAID1 sous Linux, et ça marche plutôt bien...
en tous cas, je suis rassuré, mais je réitère: bon courage ! :-)
[^] # Re: choses perdues...
Posté par Igor Genibel (site web personnel) . Évalué à 10.
Le fait que ce soit du RAID soft engendre quelques contraintes:
- le raid soft n'est pas aussi performant que le raid hard;
- le raid soft c'est pas cher;
- le raid soft avec des disques IBM c'est pas bien ;)
En fait tout dépend du niveau de sollicitation des données. Mais nous ne sommes pas insatisfait du raid soft. Nous l'utilisons donc nous l'aimons ;)
[^] # Re: choses perdues...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
nicO
"La première sécurité est la liberté"
[^] # Re: choses perdues...
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
nicO
"La première sécurité est la liberté"
[^] # Re: choses perdues...
Posté par Igor Genibel (site web personnel) . Évalué à 8.
[^] # Re: choses perdues...
Posté par PLuG . Évalué à 4.
j'ai entendu dire que certaines faisaient du raid SOFT (codé dans le bios -- utilise le cpu -- c'est mal).
alors ?
[^] # Re: choses perdues...
Posté par Yann Droneaud (site web personnel) . Évalué à 3.
[^] # Re: choses perdues...
Posté par Olivier Jeannet . Évalué à 2.
Quelle différence de performance as-tu réellement constaté ? Ou tu parles juste à priori ?
J'ai été surpris des faibles performances d'une carte IBM ServeRAID 3L, dans un Netfinity bi-PIII 733 MHz. Alors que le débit brut (mesuré avec hdparm) sur un seul disque faisait 20 Mo/s (des IBM SCSI 9 Go 7200 tr/min), les 2 disques en *miroir* (RAID-1) avaient un débit de 7 à 10 Mo/s (et 14 en écriture, à n'y rien comprendre).
[^] # Re: choses perdues...
Posté par Ben A. . Évalué à 5.
Aucun FAI digne de ce nom ne laisse un timeout inferieur a 3 jours. Il se peut que des fous bouncent les mails en quelques heures mais je doute que ca soit des FAIs majeurs/serieux.
Donc ca va spooler chez les serveurs des FAIs meme si le reseau devient injoignable.
Evidemment, si la panne depasse quelques jours, les mails vont bouncer mais les envoyeurs recevront alors un message pour signaler que le message original n'a pas ete delivre.
[^] # Re: choses perdues...
Posté par anonyme512 . Évalué à 3.
Tu as entendu parler de Yahoo ?
Ok, c'est meme pas un FAI, c'est juste un exemple, mais, hélas...
[^] # Re: choses perdues...
Posté par Ben A. . Évalué à 9.
Je sais tres bien que certains font n'importe quoi avec le mail de leurs abonnés mais ce n'est pas parce que ce sont des "gros" (en terme du nombre d'abonnés actifs) que cela devient acceptable ou recommandé.
On ne peut qu'esperer que ce type de configuration stupide leur coute suffisamment de clients pour qu'ils se sentent obliges de faire des progres.
[^] # Re: choses perdues...
Posté par anonyme512 . Évalué à 5.
Nerim s'est fait blacklister par erreur un MX par Yahoo il y a quelques temps, et ils ont jamais réussi à en ressortir de la blacklist.
C'est par parce que Yahoo c'est de la m... qu'ils ont pas une base d'utilisateurs énorme, hélas... Quand à ce qui est acceptable ou recommandé, je crois que parfois il faut savoir s'adapter, sans quoi on se ghettoise, du moins jusqu'à ce qu'on soit d'un poids suffisant pour faire changer les autres. De plus Yahoo c'est les champions de l'incohérence, avec un business model plutot proprio, mais des serveurs sous FreeBSD et Linux...
[^] # Re: choses perdues...
Posté par Arnaud (site web personnel) . Évalué à 0.
ben non. une entreprise est là pour entretenir le culte de l'argent, Yahoo, comme d'autres, prend ce qu'il y a de plus économique, de plus rentable à chaque fois.
S'ils se sont tournés vers Linux et FreeBSD, c'est parceque c'était ce qui leur revenait le moins cher, à service équivalent, par rapport à d'autres solutions.
Ca n'a donc rien d'incohérant, c'est juste qu'ils ne sont pas là pour entretenir la philosophie du Libre mais pour faire du fric.
# Après la pluie le beau temps !
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
L'équipe de Tux Family a maintenant acquis une solide expérience sur les techniques de sauvegarde et de restauration.
La preuve est que le dernier crash a été restauré plus vite que celui d'avant. Le vrai professionalisme quoi... Bravo Igor !
J'en profite pour vous donner cet adage de vieil informaticien (parce qu'il n'y a pas de vieil adage en informatique ;) qui dit que :
«Un système informatique n'a pas d'autre valeur que celle de ses sauvegardes».
# Finis
Posté par Yann Droneaud (site web personnel) . Évalué à 3.
Il y a de la perte dans les bases de données, mais tout semble de retour pour ce qui est des CVS et des sites Web.
Merci de votre compréhension, on s'est battu toute la nuit pour essayer de réparer le système, pour finalement, après nombre de changement de paramètres de configuration, reconstruction de l'array raid, recopie des données et reboot, ce rendre compte le lendemain matin; qu'elle ne voulait plus booter...
Ca y est le problème c'est enfin dévoilé dans toute sa gravité ... et on y a remédié avec les moyens du bord.
PS: Si vous avez une carte mère SMP bi PIII avec les PIIIs qui vont avec, l'association est preneuse (don, ou vente à vraiment pas cher)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.