Comment Layer 7 Load Balance WordPress Backend et Frontend?

Question

J'ai un programme d'équilibrage de charge de couche 7 utilisant HAProxy pour WordPress Multisite.

Je souhaite que tout ce qui a trait au backend WordPress soit servi à partir d'un groupe de serveurs spécifique (tout ce qui est en A/K/A dans /wp-admin/), tout en servant l'interface des sites Web WordPress à partir d'un autre groupe de serveurs.

Dois-je modifier quelque chose dans wp-config.php pour modifier les noms de cookies afin qu'ils incluent l'identifiant du serveur? ou vérifier l'ID du serveur dans le cookie WordPress? Je pense que les problèmes nos 1 et 2 sont liés aux cookies. Je ne sais pas pourquoi # 3 se passe. Mes serveurs ne sont pas du tout en retard et devraient réagir très rapidement.

Avec ma configuration actuelle, je suis confronté à quelques problèmes:

Il semble en effet que je me connecte au serveur d’administration approprié. Cependant, après un certain temps dans le tableau de bord. Le formulaire de connexion WordPress apparaît, me demandant de me reconnecter.
La plupart des pages d’administration fonctionnent très bien, mais de temps en temps, comme pour le n ° 1, la connexion WordPress apparaît et me demande de me reconnecter.
De temps en temps, je reçois un "délai d'attente de la passerelle 504 - le serveur n'a pas répondu à temps".

Voici à quoi ressemble ma configuration:

defaults log global mode http option httplog option dontlognull errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http retries 3 option redispatch maxconn 2000 timeout connect 5000 timeout check 5000 timeout client 30000 timeout server 30000 frontend http-in bind *:80 option httplog option http-server-close acl has_domain hdr(Host) -m found acl has_www hdr_beg(Host) -i www. use_backend live_servers if has_domain has_www acl has_admin path_beg /wp-admin acl has_login path_beg /wp-login.php acl has_custom_login path_beg /manage use_backend admin_servers if has_admin or has_login or has_custom_login default_backend live_servers backend live_servers mode http stats enable stats uri /haproxy?stats balance roundrobin option httpclose option forwardfor cookie SERVERID insert indirect nocache server s1 1.1.1.1:80 check cookie s1 server s2 2.2.2.2:80 check cookie s2 backend admin_servers mode http stats enable stats uri /haproxy?stats balance roundrobin option httpclose option forwardfor cookie SERVERID insert indirect nocache server s1 1.1.1.1:80 check cookie s1

Je suis disposé à fournir une prime assez lourde pour cela. Si certains paramètres me manquent ou si vous pensez pouvoir améliorer ma configuration, veuillez fournir une configuration complète incluant tous les paramètres appropriés dans votre réponse.

Edit: J'utilise actuellement HAProxy 1.6.x et souhaite passer à la dernière version si cela est nécessaire pour obtenir une solution valide.

MinhTri · Answer

Le problème # 1 & # 2 :

Je ne sais pas pourquoi vous devez ajouter et valider des cookies supplémentaires, mais pour moi, c'est simple et assez simple:

C’est ce que j’ai essayé sur les boîtes de dialogue et avec la structure par défaut de WordPress:

1 . Préparez 6 serveurs séparés

111.111.1.10 - serveur MySQL
111.111.1.11 - serveur HAProxy
111.111.1.12 & 111.111.1.13 - pour les URL d'administration
111.111.1.14 & 111.111.1.15 - pour les URL non-admin

Configurations HAProxy (v1.6):

defaults log global mode http option httplog option forwardfor option dontlognull option http-server-close timeout connect 5000 timeout client 50000 timeout server 50000 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http frontend http-revolver bind 111.111.1.11:80 acl url_is_wp_admin path_beg /wp-admin /wp-login.php /manage use_backend admin-servers if url_is_wp_admin default_backend public-servers backend public-servers server s1 111.111.1.12:80 check server s2 111.111.1.13:80 check backend admin-servers server s3 111.111.1.14:80 check server s4 111.111.1.15:80 check listen stats bind 111.111.1.11:1984 stats enable stats scope http-revolver stats scope public-servers stats scope admin-servers stats uri / stats realm Haproxy\ Statistics stats auth user:password

2 . Utilisez wpms.dev comme domaine de démonstration et pointez-le sur 111.111.1.11 dans /etc/hosts de la machine hôte.

3 . Installez une boîte de base avec ubuntu/trusty64 (pile LAMP + WP multisite) sur le serveur 111.111.1.12.

L'étape la plus importante pour éviter le problème # 1 & # 2 est car certains cookies WordPress dépendent des chemins , nous devons nous assurer que ces constantes sont cohérentes sur tous les serveurs:

define('WP_HOME', 'http://wpms.dev'); define('WP_SITEURL', 'http://wpms.dev'); define('DOMAIN_CURRENT_SITE', 'wpms.dev'); define('PATH_CURRENT_SITE', '/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);

Pour ce faire, il suffit de l'ajouter à wp-config.php dans cette boîte de base.

4 . Emballez la boîte de base et dupliquez-la sur d’autres serveurs: 111.111.1.13, 111.111.1.14 et 111.111.1.15. Maintenant, vagrant up pour tous les serveurs et vérifiez-le.

Si vous avez un échec d'authentification ssh, vous devez pointer config.ssh.private_key_path sur le private_key de la boîte de base dans Vagrantfiles des boîtes dupliquées.

Le problème # 3 est trop étranger et peut être hors sujet ici. Cela peut être une erreur de stockage, une erreur de configuration du serveur ... Vous devez le demander sur un site réseau approprié. :-)

cjbj · Answer

La plupart de votre question semble être liée au serveur et serait hors sujet ici, mais voici mes cinq sous sur la partie relative à WordPress.

WP a un cookies de connexion assez simples système. Il stocke trois cookies, un pour l'URL principale, un pour le répertoire wp-admin et un pour wp-content\plugins. Ils ne contiennent que le nom d'utilisateur et un mot de passe à double hachage. Aucun serveur lié. Ainsi, si l’installation se trouve à l’URL de droite, ces cookies ne bloqueront rien sauf s’ils expirent, un événement dont le plug-in est contrôlable .

Vous semblez signaler des déconnexions irrégulières. De ce qui précède, il s'ensuit que deux choses pourraient se produire. Soit un plugin déconne le délai d’expiration du cookie, soit l’URL ne correspond pas.

Concernant le premier. Beaucoup de plugins (e-commerce) utilisent PHP sessions pour stocker des données. Ces données peuvent être stockées côté serveur. Si le plug-in déconnecte l'utilisateur de la session lorsque des données de session sont manquantes, vous serez déconnecté lorsque votre équilibreur de charge décide de vous rediriger vers un autre serveur. Cela expliquerait les déconnexions irrégulières.

Concernant le second. Cela impliquerait une redirection vers une URL différente entre les serveurs. Pour moi, cela semble moins probable.