Varnish

128kbs d'uplink....

• [^]Re: 128kbs d'uplink....

  Posté par FRLinux (page perso, ) le 05/12/2006 à 19:09. (lien). Évalué à 1.

  Sans dévoiler tous les secrets, y'a t'il un détail de votre topologie quelque part ? J'aime bien lire sur ce sujet.
  
  

  • [^]Re: 128kbs d'uplink....

    Posté par cedric (Jabber id, ) le 05/12/2006 à 21:54. (lien). Évalué à 1.

    pas de detail de topologie c'est le site de Willy Tarreau, celui de l'article:

    The load balancing article has been linked to from LinuxFR. The small 128 kbps uplink is currently running at full speed but the site is still responding thanks to haproxy queuing the connections to smoothen the traffic. Next time, I should also write an article on setting up the QoS with tc, because typing remotely with SSH is still very responsive under full load :-)

    ca doit etre de l'adsl ou du rnis double

    • [^]Re: 128kbs d'uplink....

      Posté par tarreau willy (page perso, ) le 05/12/2006 à 22:32. (lien). Évalué à 10.

      Salut !
      
      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 (page perso, ) le 05/12/2006 à 22:30. (lien). Évalué à 2.

      Salut !
      
      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 (page perso, ) le 05/12/2006 à 22:39. (lien). Évalué à 4.

        désolé pour le double post, la première fois j'ai abandonné au bout d'une minute, ça ne me répondait pas.
        
        willy

        • [^]Re: 128kbs d'uplink....

          Posté par JereMe () le 06/12/2006 à 10:00. (lien). Évalué à 4.

          Y aurait besoin d'un ou deux VAX pour booster linuxfr ;)

config maitre / esclave

• [^]Re: config maitre / esclave

  Posté par tarreau willy (page perso, ) le 05/12/2006 à 22:50. (lien). Évalué à 4.

  
  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.
  
  Willy

Forte charge

• [^]Re: Forte charge

  Posté par tarreau willy (page perso, ) le 06/12/2006 à 21:42. (lien). Évalué à 3.

  
  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.
  
  Willy

  • [^]Re: Forte charge

    Posté par Miguelito Loveless (page perso, ) le 07/12/2006 à 08:57. (lien). Évalué à 1.

    Merci pour cette longue réponse, j'imagine plus ou moins un scénario de ce type avec certainement une redondance vrrp pour les Haproxy.
    
    Il me faudra planifier un test.

libevent