pourquoi aucun exemple d'équilibreurs de charge logiciels évolutifs horizontalement équilibrant ssl?

J'ai un tas de questions concernant SSL, les sessions locales et l'équilibrage de charge qui semblent être interconnectés, donc je m'excuse à l'avance pour la longueur de cette question.

J'ai un site Web qui utilise des sessions basées sur des fichiers. La nature du site est que la plus grande partie est http, mais certaines sections sont en ssl. Actuellement, en raison des sessions basées sur des fichiers, il est nécessaire que toutes les requêtes ssl atteignent le même serveur que toutes les requêtes http précédentes.

En raison de contraintes de temps, je veux faire la chose la plus simple possible pour équilibrer la charge du trafic http et ssl accru.

Il semble y avoir 2 options pour les algorithmes d'équilibrage de charge persistants:

• basé sur IP
• basé sur les cookies

La solution basée sur ip fonctionnera probablement, mais l'algorithme de hachage changera potentiellement le serveur auquel un utilisateur se rend lorsqu'un serveur tombe en panne ou est ajouté, ce qui n'est pas souhaitable avec la configuration de session basée sur des fichiers actuelle. Je suppose également qu'il est techniquement possible pour un utilisateur de changer légitimement l'ips lors de la navigation sur un site Web.

L'algorithme basé sur les cookies semble meilleur, mais l'incapacité d'inspecter le cookie lorsqu'il est crypté par SSL présente apparemment ses propres problèmes.

J'ai cherché sur Google des exemples sur la façon d'équilibrer la charge ssl, et je n'arrive pas à trouver d'exemples explicites de configurations qui peuvent effectuer un équilibrage de charge basé sur les cookies ET qui peuvent faire face à une charge ssl accrue en ajoutant un autre décodeur ssl.

La plupart des exemples explicites que j'ai vus ont le décodeur SSL (généralement du matériel, apache_mod_ssl ou nginx) situé entre le client du navigateur et l'équilibreur de charge. Les exemples semblent généralement avoir quelque chose comme ça (modifié depuis http://haproxy.1wt.eu/download/1.3/doc/architecture.txt ):

      192.168.1.1 192.168.1.11-192.168.1.14
 ------- + ----------- + ----- + ----- + ----- +
        | | | | |       
     + - + - + + - + - + + - + - + + - + - + + - + - +    
     | LB1 | | A | | B | | C | | D |    
     + ----- + + --- + + --- + + --- + + --- +    
     serveurs web bon marché apache 4
     mod_ssl
     haproxy 

La partie de décodage ssl dans l'exemple ci-dessus semble être un goulot d'étranglement potentiel qui n'est pas évolutif horizontalement.

J'ai regardé haproxy, et il semble avoir une option 'mode tcp' qui permettrait quelque chose comme ça, qui vous permettrait d'avoir plusieurs décodeurs SSL:

              haproxy
                 |
            -------------
            | |
ssl-decoder-1 ssl-decoder2
            | |
        -------------------
        | | |  
      web1 web2 web3

Cependant, dans une telle configuration, il semble que vous perdriez l'IP du client car haproxy ne décode pas le SSL: https://cloud-support.engineyard.com/discussions/problems/335-haproxy-not-passing-x-forwarded -pour

J'ai également regardé nginx, et je ne vois pas non plus d'exemples explicites de décodeurs SSL à échelle horizontale. Il semble y avoir de nombreux exemples de personnes ayant nginx comme goulot d'étranglement potentiel. Et au moins ce lien semble suggérer que nginx n'a même pas l'option de la configuration de type haproxy où vous perdriez l'ip en disant que nginx "ne prend pas en charge la transmission transparente des connexions TCP à un backend" Comment passer Apache Trafic SSL via le proxy Nginx? .

Des questions:

• Pourquoi ne semble-t-il pas y avoir plus d'exemples de configurations ajoutant plus de décodeurs SSL pour faire face à l'augmentation du trafic?
• Est-ce parce que l'étape de décodage SSL n'est qu'un goulot d'étranglement théorique, et pratiquement, un décodeur suffira essentiellement, sauf pour les sites au trafic ridicule?
• Une autre solution possible qui vient à l'esprit est peut-être que toute personne ayant de tels besoins SSL a également un magasin de sessions centralisé, donc peu importe le serveur Web que le client frappe sur les demandes séquentielles. Ensuite, vous pouvez activer mod_ssl ou équivalent sur chaque serveur Web.
• La solution haproxy citée ci-dessus semble fonctionner (en plus du problème d'IP client), mais quelqu'un a-t-il rencontré une solution d'équilibrage de charge logicielle basée sur des cookies qui fonctionnerait en augmentant le nombre de décodeurs tout en conservant l'IP du client, ou est-ce peut-être pas techniquement non possible (car vous devez décoder la demande pour obtenir l'adresse IP du client, auquel cas, nous avons un goulot d'étranglement du décodeur).

En supposant que tout ce que j'ai dit est vrai, cela semble être mes options:

• utiliser le hachage IP (mauvais pour les utilisateurs qui peuvent potentiellement légitimement changer d'ips, et pour les scénarios d'ajout et de suppression de serveur)
• utiliser nginx ou mod_ssl comme 1er programme touchant la requête ssl, ce sera un goulot d'étranglement de décodage ssl potentiel
• utiliser haproxy comme 1er programme touchant la requête ssl, obtenant une évolutivité horizontale ssl, mais vivant sans ips enregistré au niveau du serveur web pour les requêtes ssl (probablement temporairement ok)
• à plus long terme, optez pour un magasin de sessions mobile ou centralisé, rendant les sessions persistantes inutiles

La «chose la plus simple», en toute sérieux, est de passer à un magasin de sessions centralisé. Vous devez configurer toute cette plomberie avec des équilibreurs de charge, haproxy, SSL et le reste, lorsque chaque bit de code de gestion de session que j'ai jamais vu rend presque insignifiant le branchement de différents moteurs de stockage, donc un peu de code et très, très peu de complexité supplémentaire résout tous vos problèmes.

womble a raison sur le magasin de sessions partagées, ce qui rend les choses beaucoup plus faciles tout autour. En plus de sa réponse, je peux développer un peu les parties de l'équilibrage de charge de la question:

Pourquoi ne semble-t-il pas y avoir plus d'exemples de configurations ajoutant plus de décodeurs SSL pour faire face à l'augmentation du trafic?

Les PC multicœurs modernes peuvent effectuer plusieurs milliers de transactions SSL par seconde. Et si cela devient un goulot d'étranglement, une appliance dédiée de F5 , Citrix, Cisco ou similaire peut être encore plus rapide. Ainsi, la plupart des sites ne dépassent jamais une bonne solution SSL et d'équilibrage de charge pour un seul appareil.

En supposant que tout ce que j'ai dit est vrai, cela semble être mes options:

Il existe des options pour faire évoluer le décryptage SSL horizontalement, si vous en avez besoin.

L'approche courante consiste à utiliser DNS Round Robin pour des paires d'accélérateurs SSL hautement disponibles, c'est-à-dire publier plusieurs adresses IP pour le domaine, chaque adresse IP pointant vers une paire d'accélérateurs SSL.

Dans ce cas, vous pourriez vous inquiéter de l'expiration du délai TTL DNS au milieu d'une session utilisateur, ce qui entraînerait l'utilisateur vers un autre serveur d'applications. Cela ne devrait pas être un phénomène courant, mais cela pourrait arriver. Un magasin de sessions partagées est la solution courante, mais il peut être géré de différentes manières.

À titre d'exemple, vous pouvez séparer le déchiffrement SSL de l'équilibrage du serveur d'applications. La gestion SSL est plus gourmande en ressources processeur que l'équilibrage de charge de base, donc un seul équilibreur de charge devrait être capable de saturer quelques accélérateurs SSL. Comme ça:

Internet --> DNS round robin to multiple SSL accelerators --> plain HTTP to a single HTTP load balancer --> plain HTTP to multiple application servers

Comme mentionné au début, un magasin de sessions partagées simplifie beaucoup de choses et est presque certainement une meilleure solution à long terme que de mettre beaucoup de complexité dans votre couche SSL / équilibrage de charge.

C'est amusant de répondre à des questions de 2 ans comme celle-ci lorsque les produits ont évolué. À l'heure actuelle, haproxy prend en charge le protocole PROXY, ce qui lui permet de passer l'IP du client au saut suivant, même en mode TCP pur. Il prend également en charge SSL natif, ainsi que l'adhérence SSL si vous souhaitez l'utiliser comme première couche devant une batterie SSL (éventuellement à partir de serveurs haproxy). Il semble donc que votre demande ait été un peu en avance et que les implémentations ont rattrapé le retard :-)

Je suis d'accord avec womble et Jesper ici. La voie la plus simple / la meilleure consiste à corriger le code. Bien sûr, en tant qu'administrateurs système, nous n'avons souvent pas cette option, mais même dans ce cas, il y a suffisamment de trucs que vous pouvez tirer pour obtenir un matériel moderne relativement bon marché pour évoluer suffisamment, même s'il n'est pas vraiment horizontal.

Je voulais juste poster pour commenter où vous craignez de perdre l'IP client. Dans l'une des principales solutions L7 / proxy, vous pouvez insérer un en-tête X-Forwarded-For (ou tout ce que vous voulez) dans la demande. Ensuite, sur le serveur Web principal qui reçoit la demande, vous pouvez modifier le format du fichier journal pour consigner cette valeur dans le même espace dans le fichier qu'il a utilisé pour consigner l'IP du client layer3. De cette façon, tout logiciel d'analyse de journaux ne voit pas la différence (et vous ne le faites pas non plus).

Il y a des compromis à tout et nous n'avons pas suffisamment entendu parler de votre configuration pour le savoir, mais avec le trio vous-ne pouvez pas vous tromper de ha-proxy, nginx et vernis, c'est probablement une bonne idée de déplacer votre équilibrage de charge à un outil de couche proxy. Cela résoudra votre problème SSL et vous offrira une multitude de nouvelles options comme la mise en cache, la commutation de contenu et la manipulation d'en-tête.

Quelques pensées aléatoires;)

Tout d'abord, tirez sur la personne qui a décidé d'utiliser des données de session basées sur des fichiers. Il n'y a aucun moyen que la lecture / écriture de données à partir d'un système de fichiers soit plus rapide que le simple retour à la source pour extraire les données dont vous avez besoin. Il s'agit de la pire façon de procéder.

Personnellement, je n'ai jamais vu de situation où stocker des données dans une session était mieux que de les extraire directement de la base de données si nécessaire. Cela dit, j'ai vu où l'utilisation de memcache ou de stratégies de mise en cache similaires peut aider un site à évoluer vers des millions d'utilisateurs, mais ce n'est même pas dans la même situation que l'utilisation de sessions.

Deuxièmement, vous venez de trouver la première raison de ne pas utiliser les sessions: l'équilibrage de charge. FYI - Collant ne signifie pas coincé. Même avec les sessions Sticky activées, vous courez la possibilité très réelle que l'utilisateur soit transféré vers un autre serveur au milieu de l'utilisation de votre application. Cela se produira aux moments les plus inopportuns. Sticky signifie simplement que l'équilibreur de charge tentera de repousser l'utilisateur vers le serveur sur lequel il a commencé, mais ce n'est en aucun cas une garantie.

Ce point conduit généralement les gens à stocker la session dans la base de données ... Ce qui, je pense, est un échec complet . Pour que la session fonctionne, elle doit être chargée et écrite sur chaque demande de page. Lorsqu'il est stocké dans une base de données (nécessaire pour les serveurs à charge équilibrée), cela nécessite deux requêtes de serveur: la première pour obtenir les données, la seconde pour écrire les mises à jour.

La partie d'échec est que les gens utilisent généralement des sessions afin qu'ils n'aient pas à retourner dans la base de données pour extraire des choses comme le nom des utilisateurs ... Mais si la page doit interroger la base de données pour charger une session, alors ... eh bien, vous devriez pouvoir voir le problème logique ici.

Seulement c'est pire avec les sessions ... parce que le processeur de pages doit réécrire les données de session dans la base de données à la fin du cycle de vie des pages ... au cas où quelque chose changerait. Ce qui signifie qu'au lieu d'une seule requête pour extraire le nom de cet utilisateur, vous vous retrouvez avec deux. Pour chaque chargement de page unique. De plus, cela signifie sérialiser et désérialiser les données qui ont leur propre impact sur les performances.

Mon point est le suivant: la session est mauvaise et vous êtes généralement mieux sans elle. Les sites à faible trafic qui ne fonctionnent que sur un seul serveur Web n'ont pas besoin de l'amélioration des performances qui peut se produire; et les sites à fort trafic s'exécutant sur une batterie de serveurs Web sont limités en termes de mise à l'échelle en raison de cela.

Plutôt que d'utiliser Haproxy à l'avant, vous pouvez utiliser le DNS à tour de rôle pour effectuer un équilibrage grossier entre plusieurs décodeurs SSL, puis le transmettre à haproxy pour un équilibrage de charge approprié.