Forum Linux.général Cherche solution de load balancing

Posté par  . Licence CC By‑SA.
0
29
août
2015

Bonjour,

Je travaille actuellement sur un site Internet qui devra, entre autre, héberger beaucoup de vidéos.
Je vais commencer avec 4 serveurs :
- 2 machines qui hébergent le site Internet + la base de données SQL
- 2 machines qui hébergent les fichiers (MongoDB) et qui ont chacune l'ensemble des données

Mon problème est de faire un load balancing fiable, avec notion de poids (à terme toutes les machines n'auront pas forcément la même puissance) et bascule rapide.
Je bloque un peu sur la solution à mettre en œuvre.

J'ai d'abord réfléchi à un proxy WEB qui dirige le flux vers N machines mais le problème est la réponse vers le client. En effet, si la machine PROXY dirige le flux vers DOWNLOAD1 et DOWNLOAD2 mais que le retour de DOWNLOAD1 et DOWNLOAD2 traverse PROXY alors le goulot d'étranglement est au niveau de PROXY. Admettons que l'hébergeur fournisse 100 Mbps par machine j'ai bien 200 Mbps de flux possible mais réduit à 100 Mbps en traversant PROXY.
Du coup, première question : est-il possible de dire à Apache de retourner la réponse directement à l'utilisateur et non au proxy ? L'idéal serait même d'avoir un proxy sur DOWNLOAD1 qui envoie sur l'Apache de DOWNLOAD1 et un proxy sur DOWNLOAD2 qui envoie sur l'Apache de DOWNLOAD2 pour éviter d'exposer Apache. Le schéma serait donc :
=> PROXY GENERAL => PROXY DOWNLOAD1 => APACHE1 => client
=> PROXY GENERAL => PROXY DOWNLOAD2 => APACHE2 => client

L'avantage de cette solution est de répartir la charge vers N serveurs. Au début j'en aurais que 2 mais à terme si j'ai 10 serveurs et qu'un est HS, alors les 9 autres se répartissent sa charge.

J'ai ensuite réfléchi à une solution via le DNS et les entrées de type SRV. Dans ce cas de figure je pense allouer des adresses IP supplémentaires au serveur et en cas de défaillance d'un nœud je bascule son adresse IP sur une autre machine le temps de rétablir le service.
Cette solution a un inconvénient : dans l'exemple juste avant (10 machines ; 1 HS) c'est pas 9 machines qui se répartissent le boulot mais UNE machine qui va devoir bosser double.

Si la solution Apache n'est pas possible, vous auriez une autre solution à me suggérer ?
Je vous remercie d'avance.

  • # network load balancing

    Posté par  (site Web personnel) . Évalué à 1.

    Du coup, première question : est-il possible de dire à Apache de retourner la réponse directement à l'utilisateur et non au proxy ?

    Non, ce n'est pas possible. En tout cas, pas avec HTTP. Certains protocoles (comme le FTP) permettent se genre de chose). Mais le HTTP utilise TCP et de se fait, quand le client envoie une requête à un serveur, le serveur peux lui répondre. Pour que ton APACHE1 (ou 2) puisse répondre directement à ton client, il faudrait qu'il y ait une connexion entre le client et APACHE1. Et seul le client peut initier cette connexion, mais il l'aura initié avec le PROXY GENERAL.

    Une autre possibilité, car ton problème semble surtout être la congestion du réseau (network load balancing) plus que la puissance de calcul des serveurs (server load balancing), c'est d'effectuer un routage dynamique pour les vidéos. Par exemple, la page pour la vidéo toto va charger la vidéo un coup depuis video1.monserveur.com, un coup depuis video2.monserveur.com. video1.monserveur.com correspondant à ton PROXY DOWNLOAD1 (et idem pour 2). Ainsi, le client initie la connexion avec le serveur et tu pourras ainsi éviter le goulot d'étranglement lié au PROXY GENERAL.

    Sinon, au niveau du DNS, il est possible de faire du round-robin (pas besoin de proxy general dans ce cas).

    Un autre truc pour, toujours au niveau DNS dans le cas où les clients seront répartis géographiquement, c'est de les servir avec le serveur le plus proche. Cela peut se faire de manière assez simple
    proxy1.monserveur.com A X.X.X.X
    proxy2.monserveur.com A Y.Y.Y.Y
    monserveur.com NS proxy1.monserveur.com
    monserveur.com NS proxy2.monserveur.com

    Le truc ici, est d'assigner 2 hotes à monserveur.com. Lors de la résolution DNS, il semblerait qu'en général, le serveur le plus proche soit résolu plus vite. C'est une méthode que j'ai trouvé en faisant quelques recherches, mais j'avoue être sceptique (je n'ai pas encore creusé). En effet, la résolution DNS dépend des serveurs DNS, pas de la localisation des serveurs ! Il est tout à fait possible de résoudre monserveur.com même si X.X.X.X et Y.Y.Y.Y sont tous les deux down. Si quelqu'un a plus d'info la dessus, je suis preneur :)

    • [^] # Re: network load balancing

      Posté par  (site Web personnel) . Évalué à 1.

      Certains fournisseurs DNS te permettent du faire du round robin DNS avec des poids, ce qui peut donc répondre à ta problématique d'avoir des poids différents dans ta répartition de charge.
      Un exemple avec Route53. Avec ce fournisseur tu peux aussi faire du round-robin basé sur la latence de tes serveurs (donc le client résoudra un serveur à priori plus proche de lui).
      Tu peux combiner ça avec des répartiteurs de charge mais ça évite de faire passer trop de trafic sur un seul élément.

  • # Avec le SRV

    Posté par  (site Web personnel) . Évalué à 2.

    Si je ne me trompe pas, si une machine est HS, le client piochera au hasard une des 9 autres. Il suffit de ne rien faire pour que ça fonctionne comme tu le veux.

    • [^] # Re: Avec le SRV

      Posté par  . Évalué à 1.

      J'essaie de configurer le SRV mais ça ne fonctionne pas ; j'ai peut être loupé quelque chose.
      Voici ma zone exemple :
      $TTL 3600
      $ORIGIN example.local.

      @      IN      SOA      ns1.example.local.             contact.example.local.      (
                                                                              2015090801
                                                                              21600
                                                                              3600
                                                                              604800
                                                                              86400
      )
      
      example.local.                                                 IN    NS     ns1.example.local.
      example.local.                                                 IN    NS     ns2.example.local.
      
      ns1.example.local.                                             IN    A      192.168.1.3
      ns2.example.local.                                             IN    A      192.168.1.4
      
      www1.example.local.                                            IN    A      192.168.1.3
      www2.example.local.                                            IN    A      192.168.1.4
      
      _http._tcp.www.example.local.                                  IN  SRV  0         2     80  www1.example.local.
                                                                     IN  SRV  0         1     80  www2.example.local
      

      Hors, si je pointe mon PC vers ce serveur DNS :
      - www1.example.local résout bien avec nslookup
      - www2.example.local résout bien avec nslookup
      - www.example.local n'est pas résolu
      - une connexion sur http://www.example.local/ avec Firefox ne donne rien

      Est-ce qu'il me manque quelque chose dans la zone ?

  • # renvoi direct au client plutot que via le proxy

    Posté par  . Évalué à 3.

    c'est possible,

    cela s'appelle le direct source routing (DSR) dans les documentations (haproxy par exemple)

    en gros, il suffit que tes serveurs :
    - aient une route directe vers l'exterieur,
    - recoivent l'IP du client de la part du proxy

  • # Keep it simple

    Posté par  (site Web personnel) . Évalué à 2.

    Ou alors ton site web redirige vers un des deux serveurs de download à chaque fois qu'un client demande un fichier (soit avec une redirection HTTP, soit en lui servant directement une URL avec le bon serveur).

    L'avantage de cette solution c'est que ça scale très bien et que tu peux implémenter le load balancing que tu veux (en fonction du débit de sortie de chaque serveurs, des clients simultanés, des fichiers qu'il mirror etc), il suffit juste de collecter des métriques depuis chaque serveur de download et de choisir le meilleur en fonction. Mais un simple choix aléatoire ou un round robin peut déjà le faire pour commencer, par contre tu devras gérer le fait qu'un serveur puisse être offline.

  • # CDN ?

    Posté par  . Évalué à 1.

    La réponse ne serait-elle pas "tout simplement" un CDN (https://fr.wikipedia.org/wiki/Content_delivery_network) ?

    Tu te focalise sur ton métier et tu délègue à un autre sa partie, si c'est pour un paquet de vidéos ça me semble assez "basique" pour faire appel à un CDN … ça aurait été pour un site a fort "calcul local avant retour de données à l'utilisateur" j'aurais proposé de creuser haproxy.

    a+
    Éric

    eric.linuxfr@sud-ouest.org

  • # Haproxy

    Posté par  (site Web personnel) . Évalué à 2.

    Dans ce cas de figure je pense allouer des adresses IP supplémentaires au serveur et en cas de défaillance d'un nœud je bascule son adresse IP sur une autre machine le temps de rétablir le service.

    Faire du roundrobin DNS est le moyen le plus simple de gérer plusieurs points d'entrée. La tolérance de panne doit être assurée avec un logiciel tiers tel que keepalived.

    Cette solution a un inconvénient : dans l'exemple juste avant (10 machines ; 1 HS) c'est pas 9 machines qui se répartissent le boulot mais UNE machine qui va devoir bosser double.

    Il est impératif de prévoir le coup ou les machines tombent en cascade les unes après les autres car ton mécanisme de tolérance de panne déplace le stress sur ton réseau. En général on limite le nombre de reprises possibles. Avoir plusieurs points d'entrée DNS est utile dans ces cas là.

    Si la solution Apache n'est pas possible, vous auriez une autre solution à me suggérer ?

    Avant de déterminer ton archi, je pense qu'il est souhaitable que tu jettes un oeil à haproxy, varnish, nginx (en particulier nginx-rtmp-module), LVS et keepalived qui sont les choses qu'on trouve en général sur les frontaux web à répartition de charge / tolérance de panne.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.