Ce qui est pénible avec l'IPv6, c'est que le plus petit réseau est normalement un /64 mais le plus petit noeud reste un /128. On en effet peut parfaitement avoir 1000 machines dans un DC sur un même /64. On pourrait se dire que c'est le même LAN donc la même autorité qui les exploite et qui en est responsable, mais dans de l'hébergement massif de type dedibox, on peut être intéressé de faire la différence entre de multiples noeuds du même LAN.
Une bonne approche pourrait consister à garder le /128 comme identifiant de noeud mais déterminer des critères de groupement en fonction des sources d'attaques. Si 10 attaques (par exemple) proviennent de /128 dans le même /64, peut-être qu'on peut considérer ce /64 comme n'étant plus sous contrôle et donc comme étant malveillant.
Le même principe peut alors être utilisé pour tenter de remonter à la taille de la plage allouée à l'attaquant. Par exemple chez moi j'ai du /48 avec Nerim, ça me donne 64k réseaux (c'est beaucoup, c'est gâché mais IPv6 a été conçu pour ça).
Donc je pense que l'approche devrait être un premier saut de /128 vers /64, puis remonter d'un en un au moins jusqu'au /48 qui est normalement la plage individuelle la plus large.
Non ce n'est pas ridicule. L'académie définit le Français tel qu'il est enseigné à l'école. Apprendre aux gamins à faire des fautes inutiles, c'est ça qui est ridicule.
Je suis d'accord avec le fait que la langue évolue, il n'en reste pas moins que faire des cas particuliers par effets de styles dénature la langue. Surtout quand ces styles sont propres à chaque mot et ne suivent même pas une logique commune, et créent donc à nouveau des exceptions, la bête noire de ceux qui apprennent la langue.
La langue bouge surtout par l'import de mots étrangers, par la création de nouvelles expressions, mais très peu au niveau de la graphie, à part lorsqu'il s'agit de la remettre en correspondance avec la prononciation (et même là c'est parfois discutable dans la mesure où la prononciation change avec les régions et les personnes). On trouve aussi quelques cas de mots transgenres comme le mot "bogue" qui s'est vu devenir masculin suite aux abus des journalistes qui ne savaient pas écrire "bug" alors qu'ils savent bien écrire "via".
Alors ils ont pris le mot français de prononciation la plus proche (mais toutefois différente) et lui on changé le genre et le sens…
Plus on invente de mots ou de sens, plus on a de mal à se faire comprendre. C'est dommage, notre langue est très riche et permet de dire tant de choses avec précision!
J'ai moi-même contribué un article dont certains mots avaient été changés sans me prévenir il y a quelques années, au point que quelques personnes me connaissant bien s'étaient demandé si j'en étais vraiment l'auteur car le vocabulaire de remplacement n'était pas le mien.
Je suis d'accord avec M.Bernard, je suis moi aussi exaspéré par cette pratique pédante consistant à utiliser publiquement et de manière ostentatoire une langue dérivée du français et définie par un petit groupe idéologique, comme pour montrer son appartenance à ce groupe. Il en est de même pour d'autres dérives comme le verlan, le louchebem ou le javanais. Pour moi ici c'est comme si l'article de M.Bortzmeyer avait subi des corrections arbitraires introduisant du verlan pour certains mots que quelques uns utilisent plus communément sous cette forme.
C'est irrespectueux pour les contributeurs mais aussi pour les lecteurs car c'est une manière de leur rappeler qu'ils ne font pas partie du petit groupe en question. Il est probable que les personnes portant peu d'attention à l'orthographe n'y prêtent guère attention, mais personnellement je me sens agressé lorsque je vois des fautes, encore plus lorsqu'elles sont délibérées. Et oui, il m'arrive d'en faire, d'autant plus quand on écrit 4 fois plus en anglais qu'en français, et quand je les vois j'ai honte de ce que j'ai écrit.
Alors s'il vous plaît, veuillez faire preuve d'un peu de respect pour notre langue naturellement riche et précise. Ce n'est pas parce que le site traite de sujets informatiques que l'on doit faire plein de fautes comme des informaticiens.
Merci pour cet excellent article. Il répond mieux aux questions des utilisateurs que je ne parviens à le faire. A l'avenir je les redirigerai vers cet article pour savoir ce qui a changé dans la 1.5 :-)
Oui bien sûr. Tu sais, tu veux montrer à un consultant que sa solution de filtrage d'URL n'est pas très efficace, tu vas exprès sur ogrish.com à travers le proxy tout neuf qu'il t'a installé et tu cliques sur la première video que tu trouves. Bah franchement, moi qui étais totalement insensible à toute la collection rotten, ça m'a travaillé un moment.
Dans la même séance, on avait pu voir une vidéo d'une scène de torture où deux militaires à visage découvert coupaient avec un sécateur rouillé la partie du corps la plus sensible d'un gars qui manifestement n'avait pas envie de leur parler.
Je vois qu'ogrish a fermé depuis (il n'y avait absolument aucune censure dessus, j'étais impressionné que ce site arrive à rester en place), mais des sites comme ça il y en a de nouveaux qui naissent régulièrement pour satisfaire la curiosité de certains ou bien pour titiller un peu la faible sensibilité de ceux qui se prennent pour des durs.
Je me rappelle aussi d'un collègue qui, testant le même produit, avait découvert tout un filon de sites neo-nazis incitant au crime et tout… On n'en revenait pas, tous les liens passaient! Et là on a réalisé que lorsque ce sont des humains qui doivent qualifier des sites, il est compréhensible qu'ils passent beaucoup plus de temps sur des sites de boules que sur des sites de haine ou de "viande", il préfèrent quitter leur travail avec mal au poignet que mal au ventre.
Et donc oui, je prétends et je maintiens qu'il est absolument nécessaire de pouvoir effectuer du filtrage pour éviter que des internautes ne tombent là-dessus malgré eux et sans avoir été prévenus (en revanche je suis pour le fait qu'ils puissent forcer à passer malgré la mise en garde, et que leur demande soit journalisée pour qu'ils ne viennent pas se plaindre ensuite).
C'est bien beau de vouloir le monde libre et idéal pour tous, mais ce n'est déjà pas celui qui se trouve dehors alors c'est complètement utopique d'imaginer qu'il sera plus joli vu à travers des fibres optiques.
Mais avec quoi crois-tu q'on arrive à faire chauffer les tuyaux de l'AMS-IX à 1.5 Tbps et ceux du DE-CIX à 2 Tbps ? (Je ne sais même pas quel est le débit cumulé qui traverse l'atlantique mais je suis sûr que ça dépasse le Tbps également). La réponse est simple : c'est du cul. Et qu'est-ce qui paie le cul ? la pub. Oh y'a bien certainement des abonnements premium, mais je pense que la majorité des gens qui fréquentent ces sites préfèrent éviter de devoir justifier des lignes apparaissant sur un relevé de compte.
Donc avec des sites monstrueux pour remplir les tuyaux, on est en mesure de financer des infrastructures avec lesquelles on peut surfer occasionnellement sur le web et faire du SSH et autre, qui représentent un débit ridicule par rapport à tout ce qui passe. C'est pour ça que je dis qu'en bout de chaîne c'est la pub qui paie pratiquement tout. On n'est pas obligés de trouver ça bien, et on peut préférer revenir au début des années 90 où les abonnements coûtaient très cher pour quelques heures en modem RTC. Mais je pense qu'on est à peu près tous bien contents de pouvoir avoir un internet qui revient bien moins cher.
Note que je ne parle pas de l'évolution des technos, l'évolution est naturelle, on a toujours des moyens croissants pour un même coût. Là je parle bien de la baisse sensible des coûts d'accès par rapport à ce que c'était il y a 15-20 ans, à l'époque où Lycos et Altavista se partageaient les recherches du web et où la pub était rare et très mal vue et où les universités ne donnaient pas un accès complet au net aux étudiants parce que ça coûtait trop cher.
Bon en fait ceux qui paient vraiment, ce sont les clients des annonceurs de pub, parce qu'il faut bien que quelqu'un paie cette pub ! Moralité, si tu ne veux pas payer indirectement ton accès internet, il ne faut pas acheter les produits des entreprises qui font de la pub sur le net :-)
Désolé si tes enfants utilisent Internet comme une télé 2.0 mais les miens auront un père qui leur apprendra à développer leur libre arbitre.
Quand ils auront regardé sur un équivalent d'ogrish une seule video d'une scène de torture ou d'un journaliste qui se fait décapiter au canif avec un zoom sur la zone de "travail", faudra pas t'étonner qu'ils fassent des cauchemars pendant plusieurs mois et qu'ils aient du mal à t'en parler. Je suis pour le libre arbitre, mais il faut déjà que l'intéressé soit préparé à se faire sa propre opinion.
Idem pour la protection des postes de travail, puisque les sites web sont bourrés de malwares, il faut bien protéger un minimum les utilisateurs qui s'en foutent complètement et qui participent passivement aux botnets qui nous détruisent le net.
C’est sûr, responsabiliser les utilisateurs ça serait vraiment dangereux !
Non c'est indispensable, de même que les former. Mais tu ne dois pas exiger de chacun d'être expert dans tout ce qu'il utilise. Tant que des utilisateurs chevronnés se feront piéger, il n'y aura pas de moyen de considérer que tout est de la faute de l'utilisateur. C'est comme si on te disait que c'est de ta faute si ta voiture française neuve tombe toute seul en panne sur la route parce que le système d'injection électronique n'a pas été assez bien conçu. C'est vrai, après tout, tu pourrais aussi t'y connaître en système d'injection pour savoir qu'à un régime très précis et avec quelques conditions remplies simultanément, tu risques de casser ton moteur.
Quant à la pub… Aujourd'hui c'est elle qui finance 100% de l'internet.
J’avais pas l’impression que ma connexion à Internet était gratuite.
Essaie d'estimer tout ce que coûte l'infrastructure qui est entre toi et tes sites favoris, compte les gens qui la maintiennent, la font évoluer, assurent des astreintes etc… Divise ça par le nombre d'abonnés de ton ISP et demande-toi si tes 30 EUR/mois suffisent à payer tout ça. Je suis tout à fait certain que non. Ca paie grosso-modo l'entretien de la ligne cuivre entre chez toi et l'opérateur ainsi que les reversements dûs à la téléphonie sur laquelle on ne t'envoie pas de pub (un provider avait essayé mais ça n'avait pas pris).
D'ailleurs si ça suffisait, on aurait bien plus de fournisseurs d'accès qu'on n'en a, parce qu'il suffirait d'avoir 10 clients pour se lancer. Là, t'es obligé d'avoir plein de gros sous au départ pour acheter le matos, et c'est du matos que tu renouvelles très très souvent à la vitesse où les débits croissent.
Enfin, regarde de quoi vivent les plus gros générateurs de trafic du net : google, yahoo, facebook, youtube, … Y'a pas photo. Mais si tu veux t'abonner à leurs services de manière payante et éviter la pub, pour certains c'est possible. C'est juste une question de choix.
C'est incroyable de lire encore des trucs pareils en 2012 !
Quiconque touche un peu de près ou de loin à la sécurité sait que le filtrage est nécessaire pour protéger d'abord l'utilisateur. Quand tu auras des gamins et qu'ils iront à l'école, tu seras bien content que le proxy de l'école applique du filtrage de contenu pour éviter de leur délivrer des images choquantes ou qui ne sont pas de leur âge.
Idem pour la protection des postes de travail, puisque les sites web sont bourrés de malwares, il faut bien protéger un minimum les utilisateurs qui s'en foutent complètement et qui participent passivement aux botnets qui nous détruisent le net.
Quant à la pub… Aujourd'hui c'est elle qui finance 100% de l'internet. C'est facile de la critiquer, ça fait bien, ça fait révolutionnaire ou gars engagé, mais si tu ne veux pas de pub sur le net, on retourne à l'internet des années 80. Je pense qu'à cette époque tu n'y avais pas accès, donc au final tu peux juste te dispenser de ton accès pour ne plus voire cette pub qui te dérange et qui paie ton accès internet et la plupart des sites que tu visites.
Justement pour maintenir l'Internet comme on l'aime, il faut permettre tous les usages, ce qui passe par autoriser des blaireaux à raconter leur vie sur facebook et se goinfrer de pub, car la consommation de pub de ces gens-là te permet d'avoir un accès internet pas cher sur lequel tu peux faire du SSH et les autres protocoles que tu aimes bien. Ce qu'il ne faut pas faire, c'est décider pour les gens comment ils doivent l'utiliser, car on se retrouve à leur imposer des usages qui ne sont pas les leurs et qui nécessiteront d'abandonner cet internet pour en refaire un autre.
En fait pour être un peu plus précis, en Gigabit et 10GE, la taille minimale des trames sur le fil est de 512 octets. Mais on peut concaténer plusieurs trames de moins de 512 octets dans un slot de 512 ou plus, donc le problème ne se pose que pour les réseaux où il n'y a pas assez de trafic pour remplir ces slots, ou bien avec les protocoles en ping-pong où on doit envoyer un paquet pour avoir une réponse avant d'en envoyer un autre (ex: ping flood).
Donc dans la pratique, vu des couches du dessus, tu peux considérer que la taille minimale reste à 64 octets.
Toutes les pistes que tu évoques sont nécessaires, on ne peut pas se contenter d'un petit peu. Autant j'adore les protocoles en clair, autant je suis bien placé pour savoir combien ils sont coûteux à traîter, à cause de l'extrème tolérance qu'ils demandent, justement pour permettre à des humains de les utiliser de manière un peu légère et parfois en croyant connaître. La grande majorité des développeurs web se croient capables d'écrire des requêtes HTTP valides et pourtant quand on voit ce qu'on trouve dans des traces réseau, on a la preuve du contraire. Et les équipements qui voient passer ces requêtes sont bien obligés de faire avec. C'est ainsi qu'on se retrouve à devoir accepter un LF seul au lieu d'un CRLF à la fin des lignes (à cause de telnet), des nombres d'espaces multiples partout (à cause des utilisateurs), des espaces autour du "=" dans les cookies (à cause des développeurs qui concatènent bêtement des chaînes), etc…
Le premier problème posé par la taille du texte est le volume montant sur les liens 3G. Rien que pour émettre les 100 requêtes que comportent la plupart des sites web aujourd'hui, il faut plusieurs allers-retours parce que les requêtes sont très volumineuses. Ces allers-retours se traduisent en secondes. Des vraies secondes! C'est là où SPDY excelle, en ramenant ces requêtes à un faible nombre d'octets, capables d'être émis en une fois sans attendre d'acquittements.
C'est désagréable de travailler avec des protocoles binaires quand on est développeur, mais on n'a vraiment pas le choix. Et personnellement, je préfère des protocoles bien formatés qu'on peut décoder visuellement quand on en a l'habitude (comme on lit aujourd'hui les entêtes IP et du TCP dans un dump hexa), plutôt qu'un blob inintelligible nécessitant d'abord un coup de inflate().
Je trouve ça très bien que quelqu'un se soit lancé là-dedans. Personnellement, j'ai été sollicité à quelques reprises dernièrement pour me lancer dans une telle aventure. Même si je trouve le sujet passionnant, je n'ai vraiment pas de temps à y consacrer, et je me disais "plus tard peut-être". Le fait de voir que quelqu'un s'est lancé et l'a fait en couvrant a priori largement le sujet me ravit d'autant plus ! Les utilisateurs auront enfin une bible à se mettre sous le coude!
Félicitations donc à Sébastien pour ce travail qui, j'imagine, a dû être conséquent.
Dans l'article «sociétés apparaissant au classement Fortune 500 pour servir des millions de pages chaque jour ». Quelqu'un a un exemple plus précis sur ce type d'architecture ? une comparaison avec des switch du genre nortel alteon/passport ? Difficile de se lancer dans un test en situation réelle pour ce genre d'application
Je ne peux bien entendu pas donner de détails et encore moins de noms, mais ce que je peux dire, c'est que c'est rentré sur un très gros site bancaire ainsi qu'un gros opérateur de téléphonie mobile pour sauver dans l'urgence des alteon à l'agonie sur la prod. A chaque fois, l'alteon était configuré pour traiter le niveau 7, et à chaque fois, les symptômes ont été les mêmes : ralentissements sensibles sur l'ensemble des applis, puis impossibilité subite pour les clients d'établir des connexions, retour à la normale après un reboot puis dégradation à nouveau après quelques minutes...
En fait, y'a pas de mystère, si les applis commencent à ramer un peu, le pauvre powerpc de management qui traite également le niveau 7 n'a pas assez de RAM pour stocker les données relatives à toutes les sessions en attente, donc commence à perdre des paquets, aggravant du coup les temps de réponse, d'où l'effet d'avalanche. C'est donc une erreur de l'utiliser pour faire ça, mais il faut se faire piéger en prod pour le comprendre. D'autres constructeurs comme Foundry ont bien compris le problème et séparé très clairement les fonctions L4 (ASIC) et L7 (processeurs monstrueux rackables pour s'adapter au besoin).
Bref, du coup, on racke deux PC 1U pour faire le boulot, et l'alteon se met à bosser en niveau 4 uniquement (c'est l'ASIC qui travaille et ça va vite) et assure ainsi le LB et la HA entre les PC avec des tests simples mais efficaces. Le résultat est surprenant de stabilité et scalabilité, et fournit des infos d'une richesse inégalée auparavant grâce aux logs. Même avec 2 bons vieux AD3 et 2 PC P3 1GHz, on peut assez facilement monter à 8000 hits/s en niveau 7. Avec des AAS 3408 et deux opteron 2.6 GHz, compter environ 30000 hits/s, ce qui est souvent bien au-delà des besoins même pour de très gros sites, même si on divise par deux pour compter avec une panne.
L'autre avantage, c'est que les équipes réseau n'ont plus à se soucier des détails applicatifs, et se content d'affecter et de gérer des adresses et ports, ce qui se rapproche plus de leur métier d'origine que les bricolages de headers HTTP pour faire marcher les applis.
Le dernier schéma d'architecture dans mon article représente en fait une approximation simplifiée à l'extrème (mais fonctionnelle) de ce qu'on fait sur le terrain, en mettant "alteon" à la place de "L4LB". Y'a plus qu'à imaginer la même archi répliquée sur plusieurs étages avec des firewalls à chaque fois entre les étages pour avoir une meilleure idée.
Pour faire des tests sans casser la prod, rien de plus simple : comme ça marche en proxy, on positionne le haproxy à côté des applis, on lui fait sa conf, et au début on teste en se connectant directement sur le haproxy depuis un navigateur. On regarde aussi les logs de l'appli, etc... Une fois que ça fonctionne, on crée un real serveur et une VIP (ou juste un nouveau port) sur l'alteon qui référence le haproxy, et on vérifie depuis un navigateur que la VIP de l'alteon fournit bien le même service. On peut alors tester depuis plusieurs endroits, valider la persistance, l'absence de croisements de sessions, etc... Après, y'a plus qu'à échanger les deux services dans l'alteon (l'ancien et le nouveau) et le tour est joué sans prendre de gros risques avec un retour arrière facile en cas de pépin. Faut quand même faire gaffe au tuning (timeouts, nb sessions, ...) mais ça peut se faire de manière réfléchie et propre. Ensuite, l'alteon qui ne fait plus de niveau 7 va tellement mieux qu'il se découvre une nouvelle jeunesse et peut traiter 5 fois plus d'applis qu'avant !
Mais bon, l'article est avant tout une présentation de principes généraux à respecter, et absolument pas une recommandation pour tel ou tel produit, d'où la raison pour laquelle aucun nom de produit n'est cité. De plus, rien ne dit que pour de nouveaux déploiements avec de nouveaux besoins, les mêmes choix de produits seraient faits.
Est-il possible de mettre 2 HAProxy en maître/esclave ( pour palier à des problèmes de disques par exemple ) ?
Si oui est-il possible de garder les connections ( VRRP ? ) ?
Pour la première question, oui on peut faire ça avec du VRRP. Mais si possible, on évite de mettre des disques dans des machines qui assurent ce genre de fonctions lorsqu'elles sont vitales.
Pour la seconde question, oui et non :
- on ne peut pas garder les connexions TCP vu qu'elles sont établies par une machine et que l'autre ne les a pas dans sa table, et ne connait pas les données, les numéros des séquence TCP, tailles de fenêtres, etc...
- par contre, pour la persistance niveau 7, ça ne pose pas de problème lorsqu'on utilise des algorithmes déterministes comme l'insertion de cookie. Les deux répartiteurs ont la même conf, et lorsque le client présente son cookie désignant le serveur 2, les deux comprennent de quel serveur il s'agit.
Sur du HTTP, d'une manière générale, on ne se soucie pas de la reprise de sessions TCP, les sessions sont bien trop éphémères, et leur contenu rejouable, parfois même par le navigateur lui-même. De plus, le surcoût lié à la synchronisation (p.ex sur des firewalls) est énorme sur des sites à fort trafic.
Si vous voulez expérimenter avec le VRRP, je recommande keepalived ( http://www.keepalived.org/ ) (en particulier la version 1.1.13, à laquelle j'ai ajouté des fonctionnalités de tests de process locaux et de priorités flottantes précisément pour mieux le coupler à haproxy). En plus, son auteur (Alex Cassen) est français également, et bien que peu bavard sur son produit, a créé un excellent framework le rendant très extensible.
s'il y'en a qui veulent de l'info, c'est vachement simple :
- une ligne ADSL 512/128 chez nerim (fiabilité et IPv6)
- un firewall linux/netfilter + quelques règles TC pour calmer un peu le HTTP sortant (limité à 110 kbps) + limitation du MSS TCP à 512 octets pour améliorer la latence d'un facteur 3 (appréciable quand on travaille en SSH à distance). Le temps de ping est monté de 45 à 80-90 ms pendant que les curieux gloutonnaient le site :-)
- un haproxy en DMZ sur un pauvre vieux VAX gonflé à 24 Mo de RAM, et qui doit tourner aux alentours de 30 MHz. Il joue surtout le rôle de régulateur de trafic, car j'en avais marre qu'apache se ramasse à chaque fois que des gens cliquaient sur une image ISO même petite. Là, vous êtes montés en pointe à 38 connexions simultanées seulement, ce qui est très petit sachant que sur des GROS sites, on a déjà atteint les 10000 (mais pas sur le même matériel).
- serveur web apache sur une autre DMZ sur une vieille station PARISC 712/60 (60 MHz), gonflée elle à 96 Mo et en NFSROOT (diskless)
Tout ça, ça plafonne à 5-6 hits/s tout de même ! Mais au moins, ça consomme rien, ça fait pas de bruit et c'est totalement increvable comme matos. Quand ça a déjà tourné 10 ans non stop, ça peut bien encore en faire 10 de plus ! Là, le problème, c'est que mes pages sont lourdes, et l'article est découpé en 10 pages complètes, donc ça fait du volume sur le lien, ce qui rend le site assez lent (enfin, mes stats web haproxy répondent en moins de 5 secondes lors des consultations à distance, donc je ne me plains pas).
Ironie du sort, l'article désigné traitait de la répartition de charge alors dans ce dont on parle là, il n'y en a même pas. Comme quoi il y a bien un gros boulot de tuning avant même de se lancer dans le load balancing !
Voila, comme quoi y'a pas forcément besoin d'un P4/2GHz pour héberger un site en ADSL ;-)
s'il y'en a qui veulent de l'info, c'est vachement simple :
- une ligne ADSL 512/128 chez nerim (fiabilité et IPv6)
- un firewall linux/netfilter + quelques règles TC pour calmer un peu le HTTP sortant (limité à 110 kbps) + limitation du MSS TCP à 512 octets pour améliorer la latence d'un facteur 3 (appréciable quand on travaille en SSH à distance). Le temps de ping est monté de 45 à 80-90 ms pendant que les curieux gloutonnaient le site :-)
- un haproxy en DMZ sur un pauvre vieux VAX gonflé à 24 Mo de RAM, et qui doit tourner aux alentours de 30 MHz. Il joue surtout le rôle de régulateur de trafic, car j'en avais marre qu'apache se ramasse à chaque fois que des gens cliquaient sur une image ISO même petite. Là, vous êtes montés en pointe à 38 connexions simultanées seulement, ce qui est très petit sachant que sur des GROS sites, on a déjà atteint les 10000 (mais pas sur le même matériel).
- serveur web apache sur une autre DMZ sur une vieille station PARISC 712/60 (60 MHz), gonflée elle à 96 Mo et en NFSROOT (diskless)
Tout ça, ça plafonne à 5-6 hits/s tout de même ! Mais au moins, ça consomme rien, ça fait pas de bruit et c'est totalement increvable comme matos. Quand ça a déjà tourné 10 ans non stop, ça peut bien encore en faire 10 de plus ! Là, le problème, c'est que mes pages sont lourdes, et l'article est découpé en 10 pages complètes, donc ça fait du volume sur le lien, ce qui rend le site assez lent (enfin, mes stats web haproxy répondent en moins de 5 secondes lors des consultations à distance, donc je ne me plains pas).
Ironie du sort, l'article désigné traitait de la répartition de charge alors dans ce dont on parle là, il n'y en a même pas. Comme quoi il y a bien un gros boulot de tuning avant même de se lancer dans le load balancing !
Voila, comme quoi y'a pas forcément besoin d'un P4/2GHz pour héberger un site en ADSL ;-)
Regarde le code du client NFS, il sait manipuler des sockets UDP et TCP.
Toutefois, vu qu'il n'y a pas de pb de perfs, ça vaudrait effectivement le coup
de voir à passer ce code en userland avec des redirections d'ioctl. Il y avait
un driver qui faisait exactement ça dans le temps, ça s'appelait des ports
série virtuels. Je crois que le plus emmerdant à traiter était la gestion des TTY.
Il faut avoir une approche débit pour ne pas se poser trop de questions.
En fait, ce que tu cherches, c'est copier 40 fois 500 Mo en 5 minutes,
c'est à dire 20 Go en 5 minutes, soit 66 Mo/s en sortie vers le pool
de clés USB.
C'est totalement jouable avec du PCI express (2.5 Gbps sur du x1, compter
moins de 2 Gbps utiles, ce qui correspond justement au débit max d'une
carte 4 ports USB2), mais il va falloir expérimenter sur la répartition des
clés par nombre de ports et de cartes. Pour les clés, ça te fait 1.6 Mo/s en
écriture par clé, ce qui semble tout à fait raisonnable, même pour des clés
de piètre qualité.
Ensuite, les disques : c'est tout à fait envisageable de tenir 66 Mo/s sur du
RAID0 avec deux disques récents. Même sur un seul disque, avec les
données au début, ça peut se faire mais c'est juste juste. Par contre, on
se rend facilement compte que c'est bel et bien le disque qui risque d'être
le facteur limitant. Donc deux propositions :
- avoir suffisamment de RAM dans la machine pour que le fichier tienne en
cache ou en RAMDISK. Avantage: on néglige les limites en lecture, et on
plafonne aux 6 Mo/s du hub USB, ce qui, en admettant que les clés les
supportent, ramène le temps de copie à moins de 1mn30.
- réduire le nombre de clés simultanées pour atteindre les limites du disque
avec moins de logistique et connectique à gérer.
La première proposition est la plus intéressante, car 500 Mo de RAM ne
coûtent rien, et la solution devient scalable vu qu'elle est limitée par le
nombre de clés par hub USB. Il te suffit alors d'ajouter des cartes USB
pour aller plus vite, et mettre moins de clés par hub, ou augmenter le
nombre de clés traitées simultanément.
Très honnêtement, je craindrais plus pour la stabilité du système (très forte
contention dans les drivers USB et SCSI, blocage de tous les accès à
chaque branchement d'une clé, etc...) que pour la capacité des bus à
véhiculer de telles quantités de données. D'où l'intérêt peut-être de
réduire un peu le nombre de clés pour les faire écrire plus vite et les
changer plus rapidement.
Par exemple, si chaque clé est capable d'écrire à 12 Mo/s (à tester), alors
tu peux n'en mettre que 20 et les remplir en 45 secondes, c'est à dire que
tu remplaces une clé toutes les 2 secondes.
sur notre distrib Formilux, on utilisait ZSH il y a 5 ans pour tous les scripts d'init et de gestion des services. Triple avantage :
- il était ultra rapide (parser des fichiers de confs en ZSH était presque aussi rapide qu'en awk)
- il est bien plus compact que bash, car certainement mieux écrit
- il gère très bien les tableaux, ce qui est pratique pour stocker des paramètres de services
Seulement, on a souvent besoin de débugger des scripts de démarrage, surtout lorsqu'une distrib est jeune. Il est alors indispensable d'avoir le même shell que celui des scripts, car on a vite fait de faire des tas de copiers-collers de commandes partielles pour voir ce qui merde.
Or, il s'est avéré qu'en production, les clients habitués à KSH étaient complètement perdus avec ZSH, en particulier avec le mode de complétion qui affiche tout sous le curseur et qui fait remonter le prompt (assez déroutant, et on n'a jamais trouvé comment le remettre comme bash). Quelques autres différences majeures que je n'ai plus en tête leur faisaient penser à des gadgets plus qu'à des serveurs sérieux.
On est alors revenus à du bash bien plus classique comme shell par défaut, et on a vite compris que les scripts de démarrage allaient devoir être convertis très vite, d'une part parce que ça prenait plein de place d'avoir 2 shells (300 ko chacun) et d'autre part pour la raison de debugging évoquée ci-dessus.
Cependant, je persiste à penser que pour certains usages spécifiques (développement de programmes d'installation et/ou de configuration, génération de règles de firewalls, etc...), ce shell est absolument fabuleux et vraiment très rapide. On dispose aussi d'accès réseaux très puissants avec multiplexage de sockets, ce qui est bien sympa pour des outils d'install.
Voilà, je continue de soutenir pleinement ce shell de très grande qualité, même si je reconnais m'en servir très rarement de nos jours.
le pavé numérique est un élément très important sur un clavier, c'est généralement ce qui fait l'efficacité de certaines personnes pour un métier donné. Par exemple, il me faut moins de 3 secondes pour taper 192.168.45.0/24 sur un pavé numérique, et plus du double de temps sur mon portable. Les gens qui font beaucoup de configuration réseau (ceux qui ont en ce moment même un câble série relié au routeur qu'ils étaient en train de configurer savent de quoi je parle) ont vraiment besoin de ça. Je me suis déjà retrouvé à saisir des adresses IP bourrées de virgules sur un PC windows, ça m'a un peu énervé !
A l'inverse, des caissières ont absolument besoin de la virgule à la place du point sur le pavé numérique, et apprécieraient même sans doute la présence du double zéro que l'on ne trouve plus depuis au moins 20 ans sur nos machines. On ne peut pas leur demander de dépositionner leur main droite pour aller chopper la virgule toutes les 2 opérations.
Je pense donc que l'idée d'avoir des variantes est très bonne. Par contre, pour ce qui concerne le choix par défaut, à mon avis le plus important est de ne rien changer par rapport aux inscriptions. Une personne qui ne trouve pas comment configurer son clavier et qui se retrouve avec des caractères sans rapport avec ce qui est indiqué aura bien raison de se plaindre. On voit déjà des gens râler lorsqu'ils se retrouvent avec un clavier qwerty, et dans ce cas, le pavé numérique est leur sauveur (pour le '/' et le '*').
Dernier point : ne pas négliger l'existence des portables dépourvus de pavé numérique. C'est déjà très chiant de taper dessus, et il ne faudrait pas que certains caractères inhabituels passent dans la map centrale sous prétexte que la forme standard du caractère reste accessible sur le pavé numérique.
NB: la fonction scroll lock n'est (à ma connaissance) jamais utilisée et fournit une LED bien pratique. N'est-ce pas là le moment de la recycler pour jongler entre deux maps par défaut, tel qu'on le faisait au bon vieux temps du DOS avec le CAPS LOCK ?
Si tu laisses altgr appuyé trop longtemps c'est comme si tu laisses ctrl ou shift appuyé trop lontemps, ça donne n'importe quoi et c'est bien normal.
Si vraiment ça pose problème, demande à ton shell d'évoluer et de bien le considérer comme un espace (parce que bon, c'en est un).
Certainement pas !!! Il a un code ASCII différent !!!
Il est proprement scandaleux que deux caractères différents et d'usage différents soient représentés exactement de la même manière à l'écran, au point que l'utilisateur n'ait aucun moyen de les comparer. Le pire est que le clavier les produit tout seul. Si tu tapes sur un clavier de portables, tu verras que les touches de modification comme alt-gr ont une certaine latence lorsqu'on les relâche, et il n'est pas normal que l'utilisateur doive penser à s'arrêter une demi seconde lorsqu'il sait qu'il vient de toucher à l'une de ces touches. Je veux bien un caractère à la con lorsque j'appuie dessus, mais il faut qu'il soit matérialisé dans ma police pour que je puisse corriger ma faute de frappe.
je voyais un -march i686 , or, l'ordi sur lequel le système va tourner est un vieux pc (un bon vieux i386)
Tu vas être embêté. Certaines instructions comme BSWAP qui font l'équivalent de htonl() en une instruction sur 486 n'existent pas sur 386. L'instruction CMOV qui fait en gros in if/then sur PPro et au-delà n'existait pas sur le pentium ni avant.
Si tu choisis bien 386 comme modèle dans la sélection du processeur vers
le début de la conf, tu ne dois jamais voir apparaitre -march=i686.
Autre avantage de mettre '386', le code sera plus petit (moins d'alignements, etc...), ce qui est intéressant sur des petites machines. J'en ai eu un qui m'a servi de firewall pendant 3 ans avec 5 Mo de RAM, et bien j'étais content d'arriver à l'optimiser pour gagner jusqu'à 200 ko de RAM avec des kernels ultra-patchés !
Ah mais je n'avais pas vu, ton fichier s'appelle "entry.s" au lieu de "entry.S", autrement dit, ce n'est pas la même extension, donc make utilise la règle correspondant à l'extension ".s" au lieu de celle de ".S". C'est donc normal que tu aies ce comportement.
N'aurais-tu pas transféré tes fichiers sur un file-system FAT qui aurait supprimé les majuscules, ou bien les aurais-tu recopiés à partir d'un fichier ZIP ?
En attendant, renomme le fichier "entry.s" en "entry.S", ça devrait aller mieux, mais rien ne dit si ça ira jusqu'au bout, vu que je trouve 540 fichiers avec cette extension chez moi !
Bon courage !
PS: si c'est pour mettre sur une machine et laisser tourner, tu devrais récupérer la mise à jour 2.4.33-rc3 qui corrige pas mal de pb et de vulnérabilités.
Lorsque ld se plaint d'un paramète "-Wl," c'est que c'est GCC qui était attendu à sa place. Ce paramètre dit à GCC de passer le flag suivant au linker. Dans ton cas, "-Wl,-elf2flt" dit à gcc d'appeler ld avec "-elf2flt". En somme, quelque part, dans un makefile, il doit y avoir inscrit LD=ld alors que tu aurais besoin de LD=gcc. Essaie de changer ça dans le makefile principal. En fait, tu peux compiler en faisant "make LD=gcc" mais je pense que tu as autre chose que simplement "gcc" vu que tu fais de la cross-compilation.
je ne crois pas un seul instant que tu n'aies pas binutils. Ce package fournit entre autres ld, as, strip, objdump, nm, ... bref, plein de choses indispensables dès lors qu'on veut compiler quoi que ce soit.
Tu peux savoir ta version de binutils en faisant "ld -V" (ça marche aussi avec nm, strip, objdump, mais avec as, il faut mettre --version).
Normalement, c'est censé fonctionner à partir de binutils 2.9.1.0.25, mais je ne me souviens plus à quand remonte ma dernière compilation avec une telle version. Dans la pratique, 2.11 à 2.16.1 fonctionnent très bien.
En fait, ce qui m'inquiète dans ta capture, c'est que l'assembleur n'aurait pas dû être invoqué de cette manière (prise dans Rules.make), c'est la règle suivante qui aurait dû être utilisée (dans arch/i386/kernel/Makefile) :
.S.o:
$(CC) $(AFLAGS) -traditional -c $< -o $*.o
Vérifie donc la version de make (make --version). Ca marche normalement avec 3.79.1 à 3.81, et je crois me souvenir de problèmes occasionnels avec les versions antérieures, bien que ça remonte trop loin pour que je puisse en être sûr.
[^] # Re: IPv6 ?
Posté par tarreau willy (site web personnel) . En réponse à la dépêche CrowdSec : la cybersécurité collaborative, open source et gratuite pour Linux. Évalué à 3.
Ce qui est pénible avec l'IPv6, c'est que le plus petit réseau est normalement un /64 mais le plus petit noeud reste un /128. On en effet peut parfaitement avoir 1000 machines dans un DC sur un même /64. On pourrait se dire que c'est le même LAN donc la même autorité qui les exploite et qui en est responsable, mais dans de l'hébergement massif de type dedibox, on peut être intéressé de faire la différence entre de multiples noeuds du même LAN.
Une bonne approche pourrait consister à garder le /128 comme identifiant de noeud mais déterminer des critères de groupement en fonction des sources d'attaques. Si 10 attaques (par exemple) proviennent de /128 dans le même /64, peut-être qu'on peut considérer ce /64 comme n'étant plus sous contrôle et donc comme étant malveillant.
Le même principe peut alors être utilisé pour tenter de remonter à la taille de la plage allouée à l'attaquant. Par exemple chez moi j'ai du /48 avec Nerim, ça me donne 64k réseaux (c'est beaucoup, c'est gâché mais IPv6 a été conçu pour ça).
Donc je pense que l'approche devrait être un premier saut de /128 vers /64, puis remonter d'un en un au moins jusqu'au /48 qui est normalement la plage individuelle la plus large.
[^] # Re: Commentaire consensuel !
Posté par tarreau willy (site web personnel) . En réponse à la dépêche Joyce Reynolds est morte :-(. Évalué à 2.
Non ce n'est pas ridicule. L'académie définit le Français tel qu'il est enseigné à l'école. Apprendre aux gamins à faire des fautes inutiles, c'est ça qui est ridicule.
Je suis d'accord avec le fait que la langue évolue, il n'en reste pas moins que faire des cas particuliers par effets de styles dénature la langue. Surtout quand ces styles sont propres à chaque mot et ne suivent même pas une logique commune, et créent donc à nouveau des exceptions, la bête noire de ceux qui apprennent la langue.
La langue bouge surtout par l'import de mots étrangers, par la création de nouvelles expressions, mais très peu au niveau de la graphie, à part lorsqu'il s'agit de la remettre en correspondance avec la prononciation (et même là c'est parfois discutable dans la mesure où la prononciation change avec les régions et les personnes). On trouve aussi quelques cas de mots transgenres comme le mot "bogue" qui s'est vu devenir masculin suite aux abus des journalistes qui ne savaient pas écrire "bug" alors qu'ils savent bien écrire "via".
Alors ils ont pris le mot français de prononciation la plus proche (mais toutefois différente) et lui on changé le genre et le sens…
Plus on invente de mots ou de sens, plus on a de mal à se faire comprendre. C'est dommage, notre langue est très riche et permet de dire tant de choses avec précision!
[^] # Re: Commentaire consensuel !
Posté par tarreau willy (site web personnel) . En réponse à la dépêche Joyce Reynolds est morte :-(. Évalué à 2.
J'ai moi-même contribué un article dont certains mots avaient été changés sans me prévenir il y a quelques années, au point que quelques personnes me connaissant bien s'étaient demandé si j'en étais vraiment l'auteur car le vocabulaire de remplacement n'était pas le mien.
Je suis d'accord avec M.Bernard, je suis moi aussi exaspéré par cette pratique pédante consistant à utiliser publiquement et de manière ostentatoire une langue dérivée du français et définie par un petit groupe idéologique, comme pour montrer son appartenance à ce groupe. Il en est de même pour d'autres dérives comme le verlan, le louchebem ou le javanais. Pour moi ici c'est comme si l'article de M.Bortzmeyer avait subi des corrections arbitraires introduisant du verlan pour certains mots que quelques uns utilisent plus communément sous cette forme.
C'est irrespectueux pour les contributeurs mais aussi pour les lecteurs car c'est une manière de leur rappeler qu'ils ne font pas partie du petit groupe en question. Il est probable que les personnes portant peu d'attention à l'orthographe n'y prêtent guère attention, mais personnellement je me sens agressé lorsque je vois des fautes, encore plus lorsqu'elles sont délibérées. Et oui, il m'arrive d'en faire, d'autant plus quand on écrit 4 fois plus en anglais qu'en français, et quand je les vois j'ai honte de ce que j'ai écrit.
Alors s'il vous plaît, veuillez faire preuve d'un peu de respect pour notre langue naturellement riche et précise. Ce n'est pas parce que le site traite de sujets informatiques que l'on doit faire plein de fautes comme des informaticiens.
# Excellent article
Posté par tarreau willy (site web personnel) . En réponse à la dépêche HAProxy 1.5. Évalué à 4.
Merci pour cet excellent article. Il répond mieux aux questions des utilisateurs que je ne parviens à le faire. A l'avenir je les redirigerai vers cet article pour savoir ce qui a changé dans la 1.5 :-)
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 1.
Oui bien sûr. Tu sais, tu veux montrer à un consultant que sa solution de filtrage d'URL n'est pas très efficace, tu vas exprès sur ogrish.com à travers le proxy tout neuf qu'il t'a installé et tu cliques sur la première video que tu trouves. Bah franchement, moi qui étais totalement insensible à toute la collection rotten, ça m'a travaillé un moment.
Dans la même séance, on avait pu voir une vidéo d'une scène de torture où deux militaires à visage découvert coupaient avec un sécateur rouillé la partie du corps la plus sensible d'un gars qui manifestement n'avait pas envie de leur parler.
Je vois qu'ogrish a fermé depuis (il n'y avait absolument aucune censure dessus, j'étais impressionné que ce site arrive à rester en place), mais des sites comme ça il y en a de nouveaux qui naissent régulièrement pour satisfaire la curiosité de certains ou bien pour titiller un peu la faible sensibilité de ceux qui se prennent pour des durs.
Je me rappelle aussi d'un collègue qui, testant le même produit, avait découvert tout un filon de sites neo-nazis incitant au crime et tout… On n'en revenait pas, tous les liens passaient! Et là on a réalisé que lorsque ce sont des humains qui doivent qualifier des sites, il est compréhensible qu'ils passent beaucoup plus de temps sur des sites de boules que sur des sites de haine ou de "viande", il préfèrent quitter leur travail avec mal au poignet que mal au ventre.
Et donc oui, je prétends et je maintiens qu'il est absolument nécessaire de pouvoir effectuer du filtrage pour éviter que des internautes ne tombent là-dessus malgré eux et sans avoir été prévenus (en revanche je suis pour le fait qu'ils puissent forcer à passer malgré la mise en garde, et que leur demande soit journalisée pour qu'ils ne viennent pas se plaindre ensuite).
C'est bien beau de vouloir le monde libre et idéal pour tous, mais ce n'est déjà pas celui qui se trouve dehors alors c'est complètement utopique d'imaginer qu'il sera plus joli vu à travers des fibres optiques.
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 3.
Mais avec quoi crois-tu q'on arrive à faire chauffer les tuyaux de l'AMS-IX à 1.5 Tbps et ceux du DE-CIX à 2 Tbps ? (Je ne sais même pas quel est le débit cumulé qui traverse l'atlantique mais je suis sûr que ça dépasse le Tbps également). La réponse est simple : c'est du cul. Et qu'est-ce qui paie le cul ? la pub. Oh y'a bien certainement des abonnements premium, mais je pense que la majorité des gens qui fréquentent ces sites préfèrent éviter de devoir justifier des lignes apparaissant sur un relevé de compte.
Donc avec des sites monstrueux pour remplir les tuyaux, on est en mesure de financer des infrastructures avec lesquelles on peut surfer occasionnellement sur le web et faire du SSH et autre, qui représentent un débit ridicule par rapport à tout ce qui passe. C'est pour ça que je dis qu'en bout de chaîne c'est la pub qui paie pratiquement tout. On n'est pas obligés de trouver ça bien, et on peut préférer revenir au début des années 90 où les abonnements coûtaient très cher pour quelques heures en modem RTC. Mais je pense qu'on est à peu près tous bien contents de pouvoir avoir un internet qui revient bien moins cher.
Note que je ne parle pas de l'évolution des technos, l'évolution est naturelle, on a toujours des moyens croissants pour un même coût. Là je parle bien de la baisse sensible des coûts d'accès par rapport à ce que c'était il y a 15-20 ans, à l'époque où Lycos et Altavista se partageaient les recherches du web et où la pub était rare et très mal vue et où les universités ne donnaient pas un accès complet au net aux étudiants parce que ça coûtait trop cher.
Bon en fait ceux qui paient vraiment, ce sont les clients des annonceurs de pub, parce qu'il faut bien que quelqu'un paie cette pub ! Moralité, si tu ne veux pas payer indirectement ton accès internet, il ne faut pas acheter les produits des entreprises qui font de la pub sur le net :-)
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 1.
Quand ils auront regardé sur un équivalent d'ogrish une seule video d'une scène de torture ou d'un journaliste qui se fait décapiter au canif avec un zoom sur la zone de "travail", faudra pas t'étonner qu'ils fassent des cauchemars pendant plusieurs mois et qu'ils aient du mal à t'en parler. Je suis pour le libre arbitre, mais il faut déjà que l'intéressé soit préparé à se faire sa propre opinion.
Non c'est indispensable, de même que les former. Mais tu ne dois pas exiger de chacun d'être expert dans tout ce qu'il utilise. Tant que des utilisateurs chevronnés se feront piéger, il n'y aura pas de moyen de considérer que tout est de la faute de l'utilisateur. C'est comme si on te disait que c'est de ta faute si ta voiture française neuve tombe toute seul en panne sur la route parce que le système d'injection électronique n'a pas été assez bien conçu. C'est vrai, après tout, tu pourrais aussi t'y connaître en système d'injection pour savoir qu'à un régime très précis et avec quelques conditions remplies simultanément, tu risques de casser ton moteur.
Essaie d'estimer tout ce que coûte l'infrastructure qui est entre toi et tes sites favoris, compte les gens qui la maintiennent, la font évoluer, assurent des astreintes etc… Divise ça par le nombre d'abonnés de ton ISP et demande-toi si tes 30 EUR/mois suffisent à payer tout ça. Je suis tout à fait certain que non. Ca paie grosso-modo l'entretien de la ligne cuivre entre chez toi et l'opérateur ainsi que les reversements dûs à la téléphonie sur laquelle on ne t'envoie pas de pub (un provider avait essayé mais ça n'avait pas pris).
D'ailleurs si ça suffisait, on aurait bien plus de fournisseurs d'accès qu'on n'en a, parce qu'il suffirait d'avoir 10 clients pour se lancer. Là, t'es obligé d'avoir plein de gros sous au départ pour acheter le matos, et c'est du matos que tu renouvelles très très souvent à la vitesse où les débits croissent.
Enfin, regarde de quoi vivent les plus gros générateurs de trafic du net : google, yahoo, facebook, youtube, … Y'a pas photo. Mais si tu veux t'abonner à leurs services de manière payante et éviter la pub, pour certains c'est possible. C'est juste une question de choix.
[^] # Re: Filtrage
Posté par tarreau willy (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 3.
C'est incroyable de lire encore des trucs pareils en 2012 !
Quiconque touche un peu de près ou de loin à la sécurité sait que le filtrage est nécessaire pour protéger d'abord l'utilisateur. Quand tu auras des gamins et qu'ils iront à l'école, tu seras bien content que le proxy de l'école applique du filtrage de contenu pour éviter de leur délivrer des images choquantes ou qui ne sont pas de leur âge.
Idem pour la protection des postes de travail, puisque les sites web sont bourrés de malwares, il faut bien protéger un minimum les utilisateurs qui s'en foutent complètement et qui participent passivement aux botnets qui nous détruisent le net.
Quant à la pub… Aujourd'hui c'est elle qui finance 100% de l'internet. C'est facile de la critiquer, ça fait bien, ça fait révolutionnaire ou gars engagé, mais si tu ne veux pas de pub sur le net, on retourne à l'internet des années 80. Je pense qu'à cette époque tu n'y avais pas accès, donc au final tu peux juste te dispenser de ton accès pour ne plus voire cette pub qui te dérange et qui paie ton accès internet et la plupart des sites que tu visites.
Justement pour maintenir l'Internet comme on l'aime, il faut permettre tous les usages, ce qui passe par autoriser des blaireaux à raconter leur vie sur facebook et se goinfrer de pub, car la consommation de pub de ces gens-là te permet d'avoir un accès internet pas cher sur lequel tu peux faire du SSH et les autres protocoles que tu aimes bien. Ce qu'il ne faut pas faire, c'est décider pour les gens comment ils doivent l'utiliser, car on se retrouve à leur imposer des usages qui ne sont pas les leurs et qui nécessiteront d'abandonner cet internet pour en refaire un autre.
[^] # Re: Entêtes binaires???
Posté par tarreau willy (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 5.
En fait pour être un peu plus précis, en Gigabit et 10GE, la taille minimale des trames sur le fil est de 512 octets. Mais on peut concaténer plusieurs trames de moins de 512 octets dans un slot de 512 ou plus, donc le problème ne se pose que pour les réseaux où il n'y a pas assez de trafic pour remplir ces slots, ou bien avec les protocoles en ping-pong où on doit envoyer un paquet pour avoir une réponse avant d'en envoyer un autre (ex: ping flood).
Donc dans la pratique, vu des couches du dessus, tu peux considérer que la taille minimale reste à 64 octets.
[^] # Re: Entêtes binaires???
Posté par tarreau willy (site web personnel) . En réponse à la dépêche En route pour HTTP/2.0. Évalué à 7.
Toutes les pistes que tu évoques sont nécessaires, on ne peut pas se contenter d'un petit peu. Autant j'adore les protocoles en clair, autant je suis bien placé pour savoir combien ils sont coûteux à traîter, à cause de l'extrème tolérance qu'ils demandent, justement pour permettre à des humains de les utiliser de manière un peu légère et parfois en croyant connaître. La grande majorité des développeurs web se croient capables d'écrire des requêtes HTTP valides et pourtant quand on voit ce qu'on trouve dans des traces réseau, on a la preuve du contraire. Et les équipements qui voient passer ces requêtes sont bien obligés de faire avec. C'est ainsi qu'on se retrouve à devoir accepter un LF seul au lieu d'un CRLF à la fin des lignes (à cause de telnet), des nombres d'espaces multiples partout (à cause des utilisateurs), des espaces autour du "=" dans les cookies (à cause des développeurs qui concatènent bêtement des chaînes), etc…
Le premier problème posé par la taille du texte est le volume montant sur les liens 3G. Rien que pour émettre les 100 requêtes que comportent la plupart des sites web aujourd'hui, il faut plusieurs allers-retours parce que les requêtes sont très volumineuses. Ces allers-retours se traduisent en secondes. Des vraies secondes! C'est là où SPDY excelle, en ramenant ces requêtes à un faible nombre d'octets, capables d'être émis en une fois sans attendre d'acquittements.
C'est désagréable de travailler avec des protocoles binaires quand on est développeur, mais on n'a vraiment pas le choix. Et personnellement, je préfère des protocoles bien formatés qu'on peut décoder visuellement quand on en a l'habitude (comme on lit aujourd'hui les entêtes IP et du TCP dans un dump hexa), plutôt qu'un blob inintelligible nécessitant d'abord un coup de inflate().
# Très bonne initiative
Posté par tarreau willy (site web personnel) . En réponse à la dépêche Linux : Solutions de Haute Disponibilité. Évalué à 3.
Félicitations donc à Sébastien pour ce travail qui, j'imagine, a dû être conséquent.
[^] # Re: Forte charge
Posté par tarreau willy (site web personnel) . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 3.
Je ne peux bien entendu pas donner de détails et encore moins de noms, mais ce que je peux dire, c'est que c'est rentré sur un très gros site bancaire ainsi qu'un gros opérateur de téléphonie mobile pour sauver dans l'urgence des alteon à l'agonie sur la prod. A chaque fois, l'alteon était configuré pour traiter le niveau 7, et à chaque fois, les symptômes ont été les mêmes : ralentissements sensibles sur l'ensemble des applis, puis impossibilité subite pour les clients d'établir des connexions, retour à la normale après un reboot puis dégradation à nouveau après quelques minutes...
En fait, y'a pas de mystère, si les applis commencent à ramer un peu, le pauvre powerpc de management qui traite également le niveau 7 n'a pas assez de RAM pour stocker les données relatives à toutes les sessions en attente, donc commence à perdre des paquets, aggravant du coup les temps de réponse, d'où l'effet d'avalanche. C'est donc une erreur de l'utiliser pour faire ça, mais il faut se faire piéger en prod pour le comprendre. D'autres constructeurs comme Foundry ont bien compris le problème et séparé très clairement les fonctions L4 (ASIC) et L7 (processeurs monstrueux rackables pour s'adapter au besoin).
Bref, du coup, on racke deux PC 1U pour faire le boulot, et l'alteon se met à bosser en niveau 4 uniquement (c'est l'ASIC qui travaille et ça va vite) et assure ainsi le LB et la HA entre les PC avec des tests simples mais efficaces. Le résultat est surprenant de stabilité et scalabilité, et fournit des infos d'une richesse inégalée auparavant grâce aux logs. Même avec 2 bons vieux AD3 et 2 PC P3 1GHz, on peut assez facilement monter à 8000 hits/s en niveau 7. Avec des AAS 3408 et deux opteron 2.6 GHz, compter environ 30000 hits/s, ce qui est souvent bien au-delà des besoins même pour de très gros sites, même si on divise par deux pour compter avec une panne.
L'autre avantage, c'est que les équipes réseau n'ont plus à se soucier des détails applicatifs, et se content d'affecter et de gérer des adresses et ports, ce qui se rapproche plus de leur métier d'origine que les bricolages de headers HTTP pour faire marcher les applis.
Le dernier schéma d'architecture dans mon article représente en fait une approximation simplifiée à l'extrème (mais fonctionnelle) de ce qu'on fait sur le terrain, en mettant "alteon" à la place de "L4LB". Y'a plus qu'à imaginer la même archi répliquée sur plusieurs étages avec des firewalls à chaque fois entre les étages pour avoir une meilleure idée.
Pour faire des tests sans casser la prod, rien de plus simple : comme ça marche en proxy, on positionne le haproxy à côté des applis, on lui fait sa conf, et au début on teste en se connectant directement sur le haproxy depuis un navigateur. On regarde aussi les logs de l'appli, etc... Une fois que ça fonctionne, on crée un real serveur et une VIP (ou juste un nouveau port) sur l'alteon qui référence le haproxy, et on vérifie depuis un navigateur que la VIP de l'alteon fournit bien le même service. On peut alors tester depuis plusieurs endroits, valider la persistance, l'absence de croisements de sessions, etc... Après, y'a plus qu'à échanger les deux services dans l'alteon (l'ancien et le nouveau) et le tour est joué sans prendre de gros risques avec un retour arrière facile en cas de pépin. Faut quand même faire gaffe au tuning (timeouts, nb sessions, ...) mais ça peut se faire de manière réfléchie et propre. Ensuite, l'alteon qui ne fait plus de niveau 7 va tellement mieux qu'il se découvre une nouvelle jeunesse et peut traiter 5 fois plus d'applis qu'avant !
Mais bon, l'article est avant tout une présentation de principes généraux à respecter, et absolument pas une recommandation pour tel ou tel produit, d'où la raison pour laquelle aucun nom de produit n'est cité. De plus, rien ne dit que pour de nouveaux déploiements avec de nouveaux besoins, les mêmes choix de produits seraient faits.
Willy
[^] # Re: config maitre / esclave
Posté par tarreau willy (site web personnel) . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 4.
Pour la première question, oui on peut faire ça avec du VRRP. Mais si possible, on évite de mettre des disques dans des machines qui assurent ce genre de fonctions lorsqu'elles sont vitales.
Pour la seconde question, oui et non :
- on ne peut pas garder les connexions TCP vu qu'elles sont établies par une machine et que l'autre ne les a pas dans sa table, et ne connait pas les données, les numéros des séquence TCP, tailles de fenêtres, etc...
- par contre, pour la persistance niveau 7, ça ne pose pas de problème lorsqu'on utilise des algorithmes déterministes comme l'insertion de cookie. Les deux répartiteurs ont la même conf, et lorsque le client présente son cookie désignant le serveur 2, les deux comprennent de quel serveur il s'agit.
Sur du HTTP, d'une manière générale, on ne se soucie pas de la reprise de sessions TCP, les sessions sont bien trop éphémères, et leur contenu rejouable, parfois même par le navigateur lui-même. De plus, le surcoût lié à la synchronisation (p.ex sur des firewalls) est énorme sur des sites à fort trafic.
Si vous voulez expérimenter avec le VRRP, je recommande keepalived ( http://www.keepalived.org/ ) (en particulier la version 1.1.13, à laquelle j'ai ajouté des fonctionnalités de tests de process locaux et de priorités flottantes précisément pour mieux le coupler à haproxy). En plus, son auteur (Alex Cassen) est français également, et bien que peu bavard sur son produit, a créé un excellent framework le rendant très extensible.
Willy
[^] # Re: 128kbs d'uplink....
Posté par tarreau willy (site web personnel) . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 4.
willy
[^] # Re: 128kbs d'uplink....
Posté par tarreau willy (site web personnel) . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 10.
s'il y'en a qui veulent de l'info, c'est vachement simple :
- une ligne ADSL 512/128 chez nerim (fiabilité et IPv6)
- un firewall linux/netfilter + quelques règles TC pour calmer un peu le HTTP sortant (limité à 110 kbps) + limitation du MSS TCP à 512 octets pour améliorer la latence d'un facteur 3 (appréciable quand on travaille en SSH à distance). Le temps de ping est monté de 45 à 80-90 ms pendant que les curieux gloutonnaient le site :-)
- un haproxy en DMZ sur un pauvre vieux VAX gonflé à 24 Mo de RAM, et qui doit tourner aux alentours de 30 MHz. Il joue surtout le rôle de régulateur de trafic, car j'en avais marre qu'apache se ramasse à chaque fois que des gens cliquaient sur une image ISO même petite. Là, vous êtes montés en pointe à 38 connexions simultanées seulement, ce qui est très petit sachant que sur des GROS sites, on a déjà atteint les 10000 (mais pas sur le même matériel).
- serveur web apache sur une autre DMZ sur une vieille station PARISC 712/60 (60 MHz), gonflée elle à 96 Mo et en NFSROOT (diskless)
Tout ça, ça plafonne à 5-6 hits/s tout de même ! Mais au moins, ça consomme rien, ça fait pas de bruit et c'est totalement increvable comme matos. Quand ça a déjà tourné 10 ans non stop, ça peut bien encore en faire 10 de plus ! Là, le problème, c'est que mes pages sont lourdes, et l'article est découpé en 10 pages complètes, donc ça fait du volume sur le lien, ce qui rend le site assez lent (enfin, mes stats web haproxy répondent en moins de 5 secondes lors des consultations à distance, donc je ne me plains pas).
Ironie du sort, l'article désigné traitait de la répartition de charge alors dans ce dont on parle là, il n'y en a même pas. Comme quoi il y a bien un gros boulot de tuning avant même de se lancer dans le load balancing !
Voila, comme quoi y'a pas forcément besoin d'un P4/2GHz pour héberger un site en ADSL ;-)
Willy
[^] # Re: 128kbs d'uplink....
Posté par tarreau willy (site web personnel) . En réponse à la dépêche HAProxy, le répartiteur de charge fiable et performant. Évalué à 2.
s'il y'en a qui veulent de l'info, c'est vachement simple :
- une ligne ADSL 512/128 chez nerim (fiabilité et IPv6)
- un firewall linux/netfilter + quelques règles TC pour calmer un peu le HTTP sortant (limité à 110 kbps) + limitation du MSS TCP à 512 octets pour améliorer la latence d'un facteur 3 (appréciable quand on travaille en SSH à distance). Le temps de ping est monté de 45 à 80-90 ms pendant que les curieux gloutonnaient le site :-)
- un haproxy en DMZ sur un pauvre vieux VAX gonflé à 24 Mo de RAM, et qui doit tourner aux alentours de 30 MHz. Il joue surtout le rôle de régulateur de trafic, car j'en avais marre qu'apache se ramasse à chaque fois que des gens cliquaient sur une image ISO même petite. Là, vous êtes montés en pointe à 38 connexions simultanées seulement, ce qui est très petit sachant que sur des GROS sites, on a déjà atteint les 10000 (mais pas sur le même matériel).
- serveur web apache sur une autre DMZ sur une vieille station PARISC 712/60 (60 MHz), gonflée elle à 96 Mo et en NFSROOT (diskless)
Tout ça, ça plafonne à 5-6 hits/s tout de même ! Mais au moins, ça consomme rien, ça fait pas de bruit et c'est totalement increvable comme matos. Quand ça a déjà tourné 10 ans non stop, ça peut bien encore en faire 10 de plus ! Là, le problème, c'est que mes pages sont lourdes, et l'article est découpé en 10 pages complètes, donc ça fait du volume sur le lien, ce qui rend le site assez lent (enfin, mes stats web haproxy répondent en moins de 5 secondes lors des consultations à distance, donc je ne me plains pas).
Ironie du sort, l'article désigné traitait de la répartition de charge alors dans ce dont on parle là, il n'y en a même pas. Comme quoi il y a bien un gros boulot de tuning avant même de se lancer dans le load balancing !
Voila, comme quoi y'a pas forcément besoin d'un P4/2GHz pour héberger un site en ADSL ;-)
Willy
[^] # Re: mettre ça en userland ?
Posté par tarreau willy (site web personnel) . En réponse au message Ouvrir une socket dans un module. Évalué à 1.
Toutefois, vu qu'il n'y a pas de pb de perfs, ça vaudrait effectivement le coup
de voir à passer ce code en userland avec des redirections d'ioctl. Il y avait
un driver qui faisait exactement ça dans le temps, ça s'appelait des ports
série virtuels. Je crois que le plus emmerdant à traiter était la gestion des TTY.
willy
# Approche débit / bande passante
Posté par tarreau willy (site web personnel) . En réponse au message Copie de fichier sur n clé USB. Évalué à 2.
En fait, ce que tu cherches, c'est copier 40 fois 500 Mo en 5 minutes,
c'est à dire 20 Go en 5 minutes, soit 66 Mo/s en sortie vers le pool
de clés USB.
C'est totalement jouable avec du PCI express (2.5 Gbps sur du x1, compter
moins de 2 Gbps utiles, ce qui correspond justement au débit max d'une
carte 4 ports USB2), mais il va falloir expérimenter sur la répartition des
clés par nombre de ports et de cartes. Pour les clés, ça te fait 1.6 Mo/s en
écriture par clé, ce qui semble tout à fait raisonnable, même pour des clés
de piètre qualité.
Ensuite, les disques : c'est tout à fait envisageable de tenir 66 Mo/s sur du
RAID0 avec deux disques récents. Même sur un seul disque, avec les
données au début, ça peut se faire mais c'est juste juste. Par contre, on
se rend facilement compte que c'est bel et bien le disque qui risque d'être
le facteur limitant. Donc deux propositions :
- avoir suffisamment de RAM dans la machine pour que le fichier tienne en
cache ou en RAMDISK. Avantage: on néglige les limites en lecture, et on
plafonne aux 6 Mo/s du hub USB, ce qui, en admettant que les clés les
supportent, ramène le temps de copie à moins de 1mn30.
- réduire le nombre de clés simultanées pour atteindre les limites du disque
avec moins de logistique et connectique à gérer.
La première proposition est la plus intéressante, car 500 Mo de RAM ne
coûtent rien, et la solution devient scalable vu qu'elle est limitée par le
nombre de clés par hub USB. Il te suffit alors d'ajouter des cartes USB
pour aller plus vite, et mettre moins de clés par hub, ou augmenter le
nombre de clés traitées simultanément.
Très honnêtement, je craindrais plus pour la stabilité du système (très forte
contention dans les drivers USB et SCSI, blocage de tous les accès à
chaque branchement d'une clé, etc...) que pour la capacité des bus à
véhiculer de telles quantités de données. D'où l'intérêt peut-être de
réduire un peu le nombre de clés pour les faire écrire plus vite et les
changer plus rapidement.
Par exemple, si chaque clé est capable d'écrire à 12 Mo/s (à tester), alors
tu peux n'en mettre que 20 et les remplir en 45 secondes, c'est à dire que
tu remplaces une clé toutes les 2 secondes.
Bon courage en tout cas :-)
Willy
# scripts d'init en ZSH
Posté par tarreau willy (site web personnel) . En réponse à la dépêche À la (re)découverte de Zsh. Évalué à 3.
sur notre distrib Formilux, on utilisait ZSH il y a 5 ans pour tous les scripts d'init et de gestion des services. Triple avantage :
- il était ultra rapide (parser des fichiers de confs en ZSH était presque aussi rapide qu'en awk)
- il est bien plus compact que bash, car certainement mieux écrit
- il gère très bien les tableaux, ce qui est pratique pour stocker des paramètres de services
Seulement, on a souvent besoin de débugger des scripts de démarrage, surtout lorsqu'une distrib est jeune. Il est alors indispensable d'avoir le même shell que celui des scripts, car on a vite fait de faire des tas de copiers-collers de commandes partielles pour voir ce qui merde.
Or, il s'est avéré qu'en production, les clients habitués à KSH étaient complètement perdus avec ZSH, en particulier avec le mode de complétion qui affiche tout sous le curseur et qui fait remonter le prompt (assez déroutant, et on n'a jamais trouvé comment le remettre comme bash). Quelques autres différences majeures que je n'ai plus en tête leur faisaient penser à des gadgets plus qu'à des serveurs sérieux.
On est alors revenus à du bash bien plus classique comme shell par défaut, et on a vite compris que les scripts de démarrage allaient devoir être convertis très vite, d'une part parce que ça prenait plein de place d'avoir 2 shells (300 ko chacun) et d'autre part pour la raison de debugging évoquée ci-dessus.
Cependant, je persiste à penser que pour certains usages spécifiques (développement de programmes d'installation et/ou de configuration, génération de règles de firewalls, etc...), ce shell est absolument fabuleux et vraiment très rapide. On dispose aussi d'accès réseaux très puissants avec multiplexage de sockets, ce qui est bien sympa pour des outils d'install.
Voilà, je continue de soutenir pleinement ce shell de très grande qualité, même si je reconnais m'en servir très rarement de nos jours.
--Willy
# Pavé numérique = sacré !
Posté par tarreau willy (site web personnel) . En réponse à la dépêche [RFC] Évolution du clavier « fr-latin9 ». Évalué à 9.
le pavé numérique est un élément très important sur un clavier, c'est généralement ce qui fait l'efficacité de certaines personnes pour un métier donné. Par exemple, il me faut moins de 3 secondes pour taper 192.168.45.0/24 sur un pavé numérique, et plus du double de temps sur mon portable. Les gens qui font beaucoup de configuration réseau (ceux qui ont en ce moment même un câble série relié au routeur qu'ils étaient en train de configurer savent de quoi je parle) ont vraiment besoin de ça. Je me suis déjà retrouvé à saisir des adresses IP bourrées de virgules sur un PC windows, ça m'a un peu énervé !
A l'inverse, des caissières ont absolument besoin de la virgule à la place du point sur le pavé numérique, et apprécieraient même sans doute la présence du double zéro que l'on ne trouve plus depuis au moins 20 ans sur nos machines. On ne peut pas leur demander de dépositionner leur main droite pour aller chopper la virgule toutes les 2 opérations.
Je pense donc que l'idée d'avoir des variantes est très bonne. Par contre, pour ce qui concerne le choix par défaut, à mon avis le plus important est de ne rien changer par rapport aux inscriptions. Une personne qui ne trouve pas comment configurer son clavier et qui se retrouve avec des caractères sans rapport avec ce qui est indiqué aura bien raison de se plaindre. On voit déjà des gens râler lorsqu'ils se retrouvent avec un clavier qwerty, et dans ce cas, le pavé numérique est leur sauveur (pour le '/' et le '*').
Dernier point : ne pas négliger l'existence des portables dépourvus de pavé numérique. C'est déjà très chiant de taper dessus, et il ne faudrait pas que certains caractères inhabituels passent dans la map centrale sous prétexte que la forme standard du caractère reste accessible sur le pavé numérique.
NB: la fonction scroll lock n'est (à ma connaissance) jamais utilisée et fournit une LED bien pratique. N'est-ce pas là le moment de la recycler pour jongler entre deux maps par défaut, tel qu'on le faisait au bon vieux temps du DOS avec le CAPS LOCK ?
[^] # Re: ls | more --> more: command not found (???)
Posté par tarreau willy (site web personnel) . En réponse à la dépêche [RFC] Évolution du clavier « fr-latin9 ». Évalué à 0.
Si tu laisses altgr appuyé trop longtemps c'est comme si tu laisses ctrl ou shift appuyé trop lontemps, ça donne n'importe quoi et c'est bien normal.
Si vraiment ça pose problème, demande à ton shell d'évoluer et de bien le considérer comme un espace (parce que bon, c'en est un).
Certainement pas !!! Il a un code ASCII différent !!!
Il est proprement scandaleux que deux caractères différents et d'usage différents soient représentés exactement de la même manière à l'écran, au point que l'utilisateur n'ait aucun moyen de les comparer. Le pire est que le clavier les produit tout seul. Si tu tapes sur un clavier de portables, tu verras que les touches de modification comme alt-gr ont une certaine latence lorsqu'on les relâche, et il n'est pas normal que l'utilisateur doive penser à s'arrêter une demi seconde lorsqu'il sait qu'il vient de toucher à l'une de ces touches. Je veux bien un caractère à la con lorsque j'appuie dessus, mais il faut qu'il soit matérialisé dans ma police pour que je puisse corriger ma faute de frappe.
[^] # Re: paramètre march
Posté par tarreau willy (site web personnel) . En réponse au message Problème lors de la compilation d'un noyau 2.4.32. Évalué à 10.
Tu vas être embêté. Certaines instructions comme BSWAP qui font l'équivalent de htonl() en une instruction sur 486 n'existent pas sur 386. L'instruction CMOV qui fait en gros in if/then sur PPro et au-delà n'existait pas sur le pentium ni avant.
Si tu choisis bien 386 comme modèle dans la sélection du processeur vers
le début de la conf, tu ne dois jamais voir apparaitre -march=i686.
Autre avantage de mettre '386', le code sera plus petit (moins d'alignements, etc...), ce qui est intéressant sur des petites machines. J'en ai eu un qui m'a servi de firewall pendant 3 ans avec 5 Mo de RAM, et bien j'étais content d'arriver à l'optimiser pour gagner jusqu'à 200 ko de RAM avec des kernels ultra-patchés !
willy
[^] # Re: binutils
Posté par tarreau willy (site web personnel) . En réponse au message Problème lors de la compilation d'un noyau 2.4.32. Évalué à 2.
N'aurais-tu pas transféré tes fichiers sur un file-system FAT qui aurait supprimé les majuscules, ou bien les aurais-tu recopiés à partir d'un fichier ZIP ?
En attendant, renomme le fichier "entry.s" en "entry.S", ça devrait aller mieux, mais rien ne dit si ça ira jusqu'au bout, vu que je trouve 540 fichiers avec cette extension chez moi !
Bon courage !
PS: si c'est pour mettre sur une machine et laisser tourner, tu devrais récupérer la mise à jour 2.4.33-rc3 qui corrige pas mal de pb et de vulnérabilités.
# Re: uCLinux
Posté par tarreau willy (site web personnel) . En réponse au message uCLinux. Évalué à 1.
Willy
[^] # Re: binutils
Posté par tarreau willy (site web personnel) . En réponse au message Problème lors de la compilation d'un noyau 2.4.32. Évalué à 1.
Tu peux savoir ta version de binutils en faisant "ld -V" (ça marche aussi avec nm, strip, objdump, mais avec as, il faut mettre --version).
Normalement, c'est censé fonctionner à partir de binutils 2.9.1.0.25, mais je ne me souviens plus à quand remonte ma dernière compilation avec une telle version. Dans la pratique, 2.11 à 2.16.1 fonctionnent très bien.
En fait, ce qui m'inquiète dans ta capture, c'est que l'assembleur n'aurait pas dû être invoqué de cette manière (prise dans Rules.make), c'est la règle suivante qui aurait dû être utilisée (dans arch/i386/kernel/Makefile) :
.S.o:
$(CC) $(AFLAGS) -traditional -c $< -o $*.o
Vérifie donc la version de make (make --version). Ca marche normalement avec 3.79.1 à 3.81, et je crois me souvenir de problèmes occasionnels avec les versions antérieures, bien que ça remonte trop loin pour que je puisse en être sûr.
Willy