Équilibrage de la charge de l'application Web PHP avec trois serveurs

Question

J'ai 2 serveurs Web et 1 serveur destiné à être utilisé comme proxy inverse ou équilibreur de charge. 2 serveurs Web ont des adresses IP réelles/publiques ainsi que l'équilibreur de charge. Le serveur Load Balancer n'est pas encore configuré car je n'ai pas décidé quelle option serait la meilleure pour mes applications Web. Je suis conscient d'un équilibreur de charge est risqué parce que "point de défaillance unique", mais je veux aller avec.

2 serveurs Web contiennent plus d'une application PHP/vhost (Apache + fastcgi) avec le même domaine et différents sous-domaines. Ils utilisent tous des sessions, des cookies et certains d'entre eux nécessitent SSL. Mon objectif principal est de diviser les connexions entrantes en deux et de les transférer vers deux nœuds web. Et si un nœud Web est déconnecté, l'autre doit accepter toutes les connexions. Et je pense que si nécessaire, nous pouvons faire un partage de session avec memcache.

J'ai lu sur Nginx, HaProxy et toute autre application que je peux trouver sur le net. Mais je ne peux pas décider parce que:

1) J'ai 1 serveur que je peux utiliser comme équilibreur de charge mais toute la configuration que j'ai trouvé sur le net nécessite 2 nœuds d'équilibreur de charge. 2) Je ne sais pas où installer les certificats SSL (sur l'équilibreur de charge ou les nœuds Web) et quelle est la meilleure solution lors de l'utilisation des connexions HTTPS.

Toute aide/idée est nécessaire, merci beaucoup.

Answer 1

J'ai utilisé HAProxy dans une configuration similaire et je le recommande fortement. Il peut très bien fonctionner sur un seul serveur et vous n'avez besoin que de deux serveurs pour l'équilibrage de la charge au cas où vous souhaiteriez une haute disponibilité.

Il existe de nombreux tutoriels tels que this qui fournit des explications détaillées sur la façon de le configurer dans la configuration que vous recherchez.

Answer 2

Je viens de créer hier une configuration où le serveur NGINX en tant qu'équilibreur de charge, derrière lequel il y a 2 serveurs PHP-FPM, 1 serveur Memcache et 1 serveur MySQL. Nginx a été configuré en utilisant la fonction upstreaming et les lignes de configuration liées sont quelque chose comme ceci:

html { 

    ... 

    # loadbalancing   
    upstream myLoadBalancer { 
     ip_hash; # makes sure same user uses the same server, not 100% effective - application 
       # should handle this; in my case 1 Memcached and 1 MySQL servers commonly used 
       # by all App-servers work just fine. I store sessions in Memcache, so Session 
       # management isn't a problem at all. Its shared across all App-servers. 
     server 192.168.1.10:9000; # location of my first php-fpm server 
     server 192.168.1.11:9000; # second php-fpm server 
     # server aaa.bbb.ccc.ddd:80; # let's say, an Apache server 
    } 

    #vhost 
    server { 
     listen 80; 
     server_name mydomain.com; 
     index index.php; 

     location ~* \.php$ { 
      gzip on; 
      try_files $uri =404; 
      include fastcgi_params; 
      fastcgi_pass myLoadBalancer; 
      fastcgi_index index.php; 
      fastcgi_param SCRIPT_FILENAME /path/to/webdir$fastcgi_script_name; 
      fastcgi_param PATH_INFO $fastcgi_script_name; 
     } 
    } 
} 

HTTPS: Ils doivent être installés sur équilibreur de charge NGINX si je ne me trompe pas - jamais essayé moi-même. Une fois la demande du client transmise au serveur d'applications, il la traite, récupère la demande et la renvoie à NGINX. Et NGINX, avant de relayer la réponse au client, cryptera le contenu. C'est une théorie bien sûr. Mais je suis 100% positif NGINX peut gérer le SSL assez facilement. C'est le proxy/équilibreur le plus rapide et le plus robuste et le bon serveur Web lorsqu'il est combiné avec les capacités FASTCGI de diverses CLI.

REMARQUE: Il ne s'agit pas d'une configuration pour l'environnement de production, mais d'un scénario de test. L'environnement de production nécessiterait des paramètres très sécurisés. les ressources suivantes pourraient être utiles:

• Top 20 NGINX Webserver Best Security Practices
• PHP-FPM and NGINX

Answer 3

Dans toute situation où vous voulez HTTPS à plus de 1 serveur web, votre solution idéale serait d'avoir Nginx installé devant vos serveurs Web. Il peut également être utilisé pour l'équilibrage de la charge, mais si vous avez besoin d'options de configuration plus complexes, il est recommandé d'envoyer les demandes Nginx à votre instance HAProxy. Les deux services utilisent des ressources minimales, donc ne vous inquiétez pas d'exécuter les deux.

Je suis familier avec l'idée de n'avoir que 3 serveurs et ne pas vouloir de load-balancers redondants. J'ai en fait écrit un eBook pour les architectures de mise à l'échelle et il inclut quelques exemples avec 2-3-4 serveurs et seulement 1 load-balancer. Peut-être qu'il peut fournir plus d'informations et vous aider à démarrer.

Answer 4

Vous pouvez faire ce dont vous avez besoin avec un seul nœud HAProxy (bien que cela vous laisse toujours avec un seul point de défaillance).

J'ai écrit un tutorial for installing HAProxy on Rackspace Cloud, qui peut être adapté à n'importe quelle configuration d'Ubuntu. En utilisant l'option cookie vous pouvez également appliquer la persistance de session, donc pas besoin de partager des sessions entre les boîtes, les utilisateurs ne perdront leur session que si la boîte sur laquelle ils se trouvent descend à mi-session. Une fois que votre trafic HTTP standard est équilibré via HAProxy, vous pouvez également envoyer votre SSL via l'option mode tcp. Cela ne peut pas insérer de cookies dans la demande, utilisez le mode balance de source. Cette balance est basée sur l'adresse IP de l'utilisateur, donc ne changera pas en cours de session à moins que vous n'ajoutiez des noeuds supplémentaires. Vos certificats SSL sont ensuite installés sur vos deux nœuds Web car HAProxy ne fait qu'équilibrer le trafic TCP. Incidemment, vous pouvez utiliser ce mode de balance avec tout ce qui est sur TCP, y compris les connexions MySQL pour certaines solutions à haute disponibilité.