Comment configurer l'équilibrage de charge dans Apache

Qu'est-ce que l'équilibrage de charge ? Comment configurer l’équilibrage de charge dans Apache ? L'article suivant vous présentera la méthode de configuration de l'équilibrage de charge Apache. J'espère qu'il vous sera utile.

Qu'est-ce que l'équilibrage de charge

L'équilibrage de charge fait partie de la conception de l'architecture de système distribué. L'un des facteurs qui doivent être pris en compte, il s'agit généralement de allouer les requêtes/données [de manière uniforme] à plusieurs unités opérationnelles pour exécution. La clé de l'équilibrage de charge est [de manière uniforme] .

Solutions courantes d'équilibrage de charge

Les architectures distribuées Internet courantes sont comme ci-dessus, divisées en Couche client, couche nginx de proxy inverse, couche site, couche service, couche données. On peut voir que chaque aval a plusieurs appels en amont. Tant que chaque amont accède à chaque aval de manière égale, il peut parvenir à « distribuer uniformément les demandes/données à plusieurs unités opérationnelles pour exécution ».

Équilibrage de charge de [Couche client->Couche proxy inverse]

[Couche client] Équilibrage de charge vers la [couche proxy inverse] est obtenue via "interrogation DNS" : le serveur DNS est configuré avec plusieurs adresses IP de résolution pour un nom de domaine, et chaque demande de résolution DNS est accédée. Le serveur DNS interrogera et renvoie ces IP pour garantir que la probabilité de résolution de chaque IP est la même. Ces IP sont les IP du réseau externe de nginx, de sorte que la répartition des requêtes de chaque nginx soit également équilibrée.

Équilibrage de charge de [couche de proxy inverse->couche de site]

[couche de proxy inverse] Équilibrage de charge à la [couche site] est réalisé via "nginx". En modifiant nginx.conf, diverses stratégies d'équilibrage de charge peuvent être mises en œuvre :

1) Interrogation des requêtes : Semblable à l'interrogation DNS, les requêtes sont acheminées tour à tour vers chaque serveur Web

2) Le moins de routage de connexion : quel serveur Web a le moins de connexions, vers quel serveur Web est acheminé

3) Hachage IP : acheminez le serveur Web en fonction de la valeur de hachage IP de l'utilisateur qui accède, comme tant que la distribution IP de l'utilisateur est uniforme et que les demandes sont théoriquement uniformes, la méthode d'équilibrage du hachage IP peut y parvenir. La demande du même utilisateur tombera toujours sur le même serveur Web. Cette stratégie convient aux services avec état, tels que. session (58 remarques de Chen Jian : vous pouvez le faire, mais ce n'est fortement pas recommandé. L'apatridie au niveau du site est l'un des principes de base de la conception d'architecture distribuée. Il est préférable de stocker les sessions dans la couche de données)

4)…

Équilibrage de charge de [couche site->couche de service]

L'équilibrage de charge [couche site] vers [couche service] est obtenu via le "Pool de connexions de service".

Le pool de connexions en amont établira plusieurs connexions avec les services en aval, et chaque requête sélectionnera « au hasard » une connexion pour accéder au service en aval.

L'article précédent « Détails d'implémentation du client RPC » contient des descriptions détaillées de l'équilibrage de charge, du basculement et du traitement des délais d'attente. Vous êtes invités à cliquer sur le lien pour l'afficher et ne le développerez pas ici.

Équilibrage de charge de [couche de données]

Dans le cas d'une grande quantité de données, puisque la couche de données (db, cache) implique une segmentation horizontale des données, donc L'équilibrage de charge de la couche de données est plus compliqué. Il est divisé en "équilibrage des données" et "équilibrage des demandes" .

L'équilibre des données signifie : pour chaque service (base de données, cache) après segmentation horizontale, la quantité de données est presque la même.

L'équilibre des requêtes signifie : pour chaque service (db, cache) après segmentation horizontale, le volume des requêtes est quasiment le même.

Il existe plusieurs méthodes de segmentation horizontale courantes dans l'industrie :

1. Segmentation horizontale selon la plage

Chaque service de données,

stocke une certaine plage de données, comme le montre l'image ci-dessus :

service user0, stocke la plage UID 1-1kw

service utilisateur1, plage d'uid de stockage 1kw-2kw

Les avantages de cette solution sont :

(1) Les règles sont simples, le service n'a qu'à déterminer la plage d'uid vers laquelle acheminer le service de stockage correspondant

(2) L'équilibre des données est meilleur

(3) Il est relativement facile d'étendre un service de données avec uid [2kw, 3kw] à tout moment.

Les inconvénients sont :

(1) La charge des demandes n'est pas forcément équilibrée. De manière générale, les utilisateurs nouvellement enregistrés seront plus actifs que les anciens utilisateurs, et la pression sur les demandes de services à large portée sera plus importante

2. Selon la segmentation horizontale id Hash

Chaque service de données, stocke une partie des données après avoir haché une certaine valeur clé , comme indiqué ci-dessus Par exemple :

service user0, stocke même les données uid

service user1, stocke les données uid impaires

Les avantages de cette solution sont :

(1) Les règles sont simples, le service n'a besoin que de hacher l'uid pour être acheminé vers le service de stockage correspondant

(2) Le solde des données est bon

(3) Le l'uniformité des demandes est bonne

Les inconvénients sont :

(1) Il n'est pas facile d'étendre un service de données, lorsque la méthode de hachage change, une migration des données peut être nécessaire

.

Résumé

L'équilibre de charge est l'un des facteurs qui doivent être pris en compte dans la conception de l'architecture d'un système distribué. Il fait généralement référence à l'allocation des requêtes/données [de manière uniforme] à plusieurs unités opérationnelles. pour l'exécution. La clé de l'équilibrage de charge est [evenly] .

(1) L'équilibrage de charge de [Couche client] à [Couche proxy inverse] est obtenu via « interrogation DNS »

(2) Équilibrage de charge [Couche proxy inverse] à [Couche site] est obtenu via "nginx"

(3) L'équilibrage de charge [Couche site] à [Couche service] est obtenu via le "pool de connexions de service"

(4) Pour l'équilibrage de charge de [couche de données ], deux points doivent être pris en compte : "l'équilibrage des données" et "l'équilibrage des demandes". Les méthodes courantes incluent la "segmentation horizontale par plage" et la "segmentation horizontale par hachage"

Paramètre d'équilibrage de charge Apache. méthode

De manière générale, l'équilibrage de charge consiste à décharger les requêtes des clients vers divers serveurs réels sur le backend pour atteindre l'objectif d'équilibrage de charge. Une autre méthode consiste à utiliser deux serveurs, l'un comme serveur principal (Maître) et l'autre comme serveur de secours (Hot Standby). Toutes les requêtes sont transmises au serveur principal. Lorsque le serveur principal tombe en panne, il est immédiatement basculé vers le serveur principal. serveur de sauvegarde. Afin d'améliorer les performances globales du système

J'ai été surpris lorsque j'ai vu ce titre pour la première fois, Apache peut réellement effectuer l'équilibrage de charge ? C'est tellement puissant. Après quelques recherches, j'ai découvert que c'était effectivement possible et que la fonctionnalité n'était pas mauvaise du tout. Tout cela grâce au module mod_proxy. C'est en effet un Apache puissant.

Sans plus attendre, expliquons comment mettre en place l’équilibrage de charge.

De manière générale, l'équilibrage de charge consiste à distribuer les requêtes des clients à divers serveurs réels sur le backend pour atteindre l'objectif d'équilibrage de charge. Une autre méthode consiste à utiliser deux serveurs, l'un comme serveur principal (Maître) et l'autre comme serveur de secours (Hot Standby). Toutes les requêtes sont transmises au serveur principal. Lorsque le serveur principal tombe en panne, il est immédiatement basculé vers le serveur principal. serveur de sauvegarde. pour améliorer la fiabilité globale du système.

1. Paramètres d'équilibrage de charge

1). Configuration de base

Apache peut répondre aux deux besoins ci-dessus. Voyons d'abord comment effectuer l'équilibrage de charge. Supposons que le nom de domaine d'un serveur Apache soit www.a.com. Tout d'abord, vous devez activer plusieurs modules d'Apache :

Le code est le suivant :

LoadModule proxy_module modules/mod_proxy.so 
 LoadModule proxy_balancer_module modules/mod_proxy_balancer.so 
 LoadModule proxy_http_module modules/mod_proxy_http.so

mod_proxy. fournit la fonction de serveur proxy et mod_proxy_balancer fournit la fonctionnalité d'équilibrage de charge, mod_proxy_http permet aux serveurs proxy de prendre en charge le protocole HTTP. Si mod_proxy_http est remplacé par d'autres modules de protocole (tels que mod_proxy_ftp), il pourra peut-être prendre en charge l'équilibrage de charge d'autres protocoles. Les amis intéressés peuvent l'essayer eux-mêmes.
Ajoutez ensuite la configuration suivante :

Le code est le suivant :

ProxyRequests Off 
 <Proxy balancer://mycluster> 
 BalancerMember http://node-a.myserver.com:8080 
 BalancerMember http://node-b.myserver.com:8080 
 </Proxy> 
 ProxyPass / balancer://mycluster/ 
 # 警告：以下这段配置仅用于调试，绝不要添加到生产环境中！！！ 
 <Location /balancer-manager> 
 SetHandler balancer-manager 
 order Deny,Allow 
 Deny from all 
 Allow from localhost 
 </Location>

Remarque : node-a.myserver.com, node-b.myserver.com sont les noms de domaine de les deux autres serveurs. Pas le nom de domaine du serveur actuel

Comme le montre ProxyRequests Off ci-dessus, l'équilibreur de charge est en fait un proxy inverse, mais son adresse de transfert de proxy n'est pas un serveur spécifique, mais un protocole balancer:// :

L'adresse du protocole ProxyPass / balancer://mycluster peut être définie arbitrairement. Ensuite, définissez le contenu du protocole d'équilibrage dans la section 11951de53252afd7f744ef2dcc6c9390 La directive BalancerMember peut ajouter l'adresse réelle du serveur dans le groupe d'équilibrage de charge.

Le paragraphe suivant ba087f03004fe4f66fd7615e84a09336 est utilisé pour surveiller l'état de fonctionnement de l'équilibrage de charge. Vous pouvez l'ajouter pendant le débogage (utilisation interdite dans un environnement de production !), puis visiter http:/. /localhost/ balancer-manager/ pour voir l’état de fonctionnement de l’équilibrage de charge.

OK, après avoir effectué les modifications, redémarrez le serveur et visitez l'adresse de votre serveur Apache (www.a.com) pour voir l'effet d'équilibrage de charge.

出错提示: 
访问网页提示Internal Serveral Error,察看error.log文件

Error.log code

[warn] proxy: No protocol handler was valid for the URL /admin/login_form. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.

La raison est que la configuration : # ProxyPass / balancer://mycluster peut en manquer un /

2).

Ouvrez l'interface équilibreur-gestionnaire et vous pourrez voir que les demandes sont réparties uniformément.

如果不想平均分配怎么办？给 BalancerMember 加上 loadfactor 参数即可，取值范围为1-100。比如你有三台服务器，负载分配比例为 7:2:1，只需这样设置： 

Httpd.conf代码 

ProxyRequests Off 
 <Proxy balancer://mycluster> 
 BalancerMember http://node-a.myserver.com:8080 loadfactor=7 
 BalancerMember http://node-b.myserver.com:8080 loadfactor=2 
 BalancerMember http://node-c.myserver.com:8080 loadfactor=1 
 </Proxy> 
 ProxyPass / balancer://mycluster

3).负载分配算法 

默认情况下，负载均衡会尽量让各个服务器接受的请求次数满足预设的比例。如果要改变算法，可以使用 lbmethod 属性。如： 

代码如下:

ProxyRequests Off 
 <Proxy balancer://mycluster> 
 BalancerMember http://node-a.myserver.com:8080 loadfactor=7 
 BalancerMember http://node-b.myserver.com:8080 loadfactor=2 
 BalancerMember http://node-c.myserver.com:8080 loadfactor=1 
 </Proxy> 
 ProxyPass / balancer://mycluster 
 ProxySet lbmethod=bytraffic

lbmethod可能的取值有： 

• lbmethod=byrequests 按照请求次数均衡(默认) 

• lbmethod=bytraffic 按照流量均衡 

• lbmethod=bybusyness 按照繁忙程度均衡(总是分配给活跃请求数最少的服务器) 

各种算法的原理请参见Apache的文档。 

2. 热备份(Hot Standby) 

热备份的实现很简单，只需添加 status=+H 属性，就可以把某台服务器指定为备份服务器： 

代码如下:

ProxyRequests Off 
 <Proxy balancer://mycluster> 
 BalancerMember http://node-a.myserver.com:8080 
 BalancerMember http://node-b.myserver.com:8080 status=+H 
 </Proxy> 
 ProxyPass / balancer://mycluster

从 balancer-manager 界面中可以看到，请求总是流向 node-a ，一旦node-a挂掉， Apache会检测到错误并把请求分流给 node-b。Apache会每隔几分钟检测一下 node-a 的状况，如果node-a恢复，就继续使用node-a。

apache负载均衡的安装和实现方法

其实无论是分布式,数据缓存,还是负载均衡,无非就是改善网站的性能瓶颈,在网站源码不做优化的情况下,负载均衡可以说是最直接的手段了｡其实抛开这个名词,放开了说,就是希望用户能够分流,也就是说把所有用户的访问压力分散到多台服务器上,也可以分散到多个tomcat里,如果一台服务器装多个tomcat,那么即使是负载均衡,性能也提高不了太多,不过可以提高稳定性,即容错性｡当其中一个主tomcat当掉,其他的tomcat也可以补上,因为tomcat之间实现了Session共享｡待tomcat服务器修复后再次启动,就会自动拷贝所有session数据,然后加入集群｡这样就可以不间断的提供服务｡如果要真正从本质上提升性能,必须要分布到多台服务器｡同样tomcat也可以做到｡网上相关资料比较多,可以很方便的查到,但是质量不算高｡我希望可以通过这篇随笔,系统的总结｡

本文的 例子是同一台服务器上运行两个tomcat,做两个tomcat之间的负载均衡｡其实多台服务器各配置一个tomcat也可以,而且那样的话,可以使用安装版的tomcat,而不用是下文中的免安装的tomcat,而且tomcat端口配置也就不用修改了｡下文也会提到｡ 

tomcat的负载均衡需要apache服务器的加入来实现｡在进行配置之前请先卸载调已安装的tomcat,然后检查apache的版本｡我这次配置使用的是apache-tomcat-6.0.18免安装版本,我亲自测试后推断安装版的tomcat在同一台机子上会不能启动两个以上,可能是因为安装版的tomcat侵入了系统,导致即使在server.xml里修改了配置,还是会引起冲突｡所以我使用tomcat免安装版｡ 

apache使用的是apache_2.2.11-win32-x86-no_ssl.msi｡如果版本低于2.2Apache负载均衡的配置要有所不同,因为这个2.2.11和2.2.8版本集成了jk2等负载均衡工具,所以配置要简单许多｡别的版本我没有具体测试,有待考究｡这两个软件可以到官方网站下载｡ 

把Apache安装为运行在80端口的Windows服务,安装成功后在系统服务列表中可以看到Apache2.2服务｡服务启动后在浏览器中输入http://localhost进行测试,如果能看到一个"It works!"的页面就代表Apache已经正常工作了｡把tomcat解压到任意目录,赋值一个另命名｡起名和路径对配置没有影响｡但要保证端口不要冲突,如果装有Oracle或IIS的用户需要修改或关闭相关接口的服务｡当然jdk的配置也是必须的,这个不再过多叙述｡ 

想要达到负载均衡的目的，首先,在Apache安装目录下找到conf/httpd.conf文件,去掉以下文本前的注释符(#)以便让Apache在启动时自动加载代理(proxy)模块｡

代码如下:

LoadModule proxy_module modules/mod_proxy.so 
 LoadModule proxy_ajp_module modules/mod_proxy_ajp.so 
 LoadModule proxy_balancer_module modules/mod_proxy_balancer.so 
 LoadModule proxy_connect_module modules/mod_proxy_connect.so 
 LoadModule proxy_ftp_module modules/mod_proxy_ftp.so 
 LoadModule proxy_http_module modules/mod_proxy_http.so

向下拉动文档找到794ea01c23a0d5c1a7b2f169e4879de9节点,在DirectoryIndex index.html后加上index.jsp,这一步只是为了待会配置完tomcat后能看到小猫首页,可以不做｡继续下拉文档找到Include conf/extra/httpd-vhosts.conf,去掉前面的注释符｡ 

然后打开conf/extra/httpd-vhosts.conf,配置虚拟站点,在最下面加上 

代码如下:

<VirtualHost *:80> 
 ServerAdmin 管理员邮箱 
 ServerName localhost 
 ServerAlias localhost 
 ProxyPass / balancer://sy/ stickysession=jsessionid nofailover=On 
 ProxyPassReverse / balancer://sy/ 
 ErrorLog "logs/sy-error.log" 
 CustomLog "logs/sy-access.log" common 
 </VirtualHost>

然后回到httpd.conf,在文档最下面加上 

代码如下:

ProxyRequests Off 
 <proxy balancer://sy> 
 BalancerMember ajp://127.0.0.1:8009 loadfactor=1 route=jvm1 
 BalancerMember ajp://127.0.0.1:9009 loadfactor=1 route=jvm2 
 </proxy>

ProxyRequests Off 是告诉Apache需要使用反向代理,ip地址和端口唯一确定了tomcat节点和配置的ajp接受端口｡loadfactor是负载因子,Apache会按负载因子的比例向后端tomcat节点转发请求,负载因子越大,对应的tomcat服务器就会处理越多的请求,如两个tomcat都是1,Apache就按1:1的比例转发,如果是2和1就按2:1的比例转发｡这样就可以使配置更灵活,例如可以给性能好的服务器增加处理工作的比例,如果采取多台服务器,只需要修改ip地址和端口就可以了｡route参数对应后续tomcat负载均衡配置中的引擎路径(jvmRoute)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!