WordPressのバックエンドとフロントエンドのレイヤー7ロードバランス

Question

WordPress Multisite用にHAProxyを使用したLayer 7 Load Balancerの設定があります。

私はWordPressバックエンドに関連するものが特定のサーバーグループから提供されるようにしたいと考えています（A/K/A /wp-admin/内のもの）。

サーバーIDが含まれるようにCookie名を変更するためにwp-config.php内の何かを調整する必要がありますか？それともWordPressのクッキーでサーバーIDを確認しますか？私は問題＃1と＃2がクッキーに関連しているように感じます。私はなぜ＃3が起こっているのかわかりません。私のサーバーは全く遅れているわけではなく、十分に早く応答しているはずです。

現在の設定では、ここでいくつかの問題に直面しています。

私を適切な管理サーバーに接続しているように見えます。ただし、ダッシュボードでしばらくしてから。 WordPressのログインフォームが表示され、もう一度ログインし直すように求められます。
たいていの管理者ページはたまたまうまく動作しますが、やはり＃1と同じように、WordPressのログインがポップアップ表示され、もう一度ログインするように求められます。
そのたびに、「504ゲートウェイタイムアウト - サーバーが間に合わなかった」というメッセージが表示されます。

私の設定はこんな感じです：

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

私はこれにかなりの多額の恩恵を提供していく所存です。不足している設定がある場合、または自分の設定を改善できると思われる場合は、回答に適切な設定をすべて含めた完全な設定を指定してください。

編集：私は現在HAProxy 1.6.xを使用しており、それが有効な解決策を得るために必要なものであれば最新バージョンにアップグレードしても構わないと思っています。

MinhTri · Answer

問題＃1と＃2 ：

追加のCookieを追加して検証する必要がある理由はわかりませんが、私にとっては、それは簡単で非常に簡単です。

これは私がvagrant boxとデフォルトのWordPress構造で試したものです。

1 。 6台のサーバーを用意する

111.111.1.10 - MySQLサーバ
111.111.1.11 - HAProxyサーバー
111.111.1.12＆111.111.1.13 - 管理URL用
111.111.1.14＆111.111.1.15 - 管理者以外のURLの場合

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 。デモドメインとしてwpms.devを使用し、それをホストマシンの111.111.1.11内の/etc/hostsを指すようにします。

3 。サーバubuntu/trusty64に111.111.1.12（LAMP stack + WP multisite）を付けてベースボックスをインストールします。

＃1と＃2の問題を回避するための最も重要な手順は、 いくつかのWordPressクッキーはパスに依存しているため 、これらの定数がすべてのサーバーで一貫していることを確認する必要があります。

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);

それを行うには、このベースボックスのwp-config.phpに追加するだけです。

4 。ベースボックスをパッケージ化して、他のサーバー（111.111.1.13、111.111.1.14、および111.111.1.15）に複製します。今すぐすべてのサーバーのvagrant upとそれをチェックしてください。

Ssh認証に失敗した場合は、複製ボックスのVagrantfilesでconfig.ssh.private_key_pathをベースボックスのprivate_keyに指定する必要があります。

問題＃3 は海外にありすぎてここでは話題にならないかもしれません。ストレージエラー、サーバー設定エラーなどが考えられます。適切なネットワークサイトで確認してください。 :-)

cjbj · Answer

あなたの質問の大部分はサーバーに関連しているように思われ、ここでは話題になりませんが、WordPress関連の部分についての私の5セントです。

WPはとても単純なログインクッキー systemを持っています。メインのURL用、wp-adminディレクトリ用、wp-content\plugins用の3つのCookieが格納されています。ユーザー名と二重ハッシュパスワードのみが含まれています。サーバーには関係ありません。そのため、インストールが正しいURLで見つかった場合、これらのCookieは期限切れにならない限りブロックしません。プラグイン制御可能なイベントはです。

不規則なログアウトを報告しているようです。上記から、2つのことが起こり得ることがわかります。プラグインがCookieの有効期限を混乱させているか、URLが一致しません。

第一について。多くの（eコマース）プラグインは PHP sessions を使ってデータを保存します。そのデータはサーバ側に格納されてもよい。セッションデータが欠落しているときにプラグインが何らかの理由でユーザーをログアウトさせると、ロードバランサーが別のサーバーにリダイレクトすることを決定したときにログアウトされます。これは不規則なログアウトを説明するでしょう。

第二について。これは、サーバー間で別のURLにリダイレクトすることを含みます。私にはこれは可能性が低いようです。