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.
[^] # Re: Forte charge
Posté par tarreau willy . 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