Nginx баланс нагрузки с прокси php -fpm - try_files - PullRequest
Новая
       16

Nginx баланс нагрузки с прокси php -fpm - try_files

0 голосов
/ 11 февраля 2020

Я пытаюсь настроить несколько php -pm серверов для обработки трафиков c пиков.

Сейчас у меня есть одна машина, работающая Nginx + PHP7 .3-fpm + Redis (6vCPU и 16 ГБ ОЗУ) и еще один разделенный работает только php -fpm 7.3 и те же расширения.

Все хорошо, но я должен создать план для трафиков c шипов. И я не знаю, как подключить эту новую и изолированную машину для совместной работы с основным сервером без особых проблем.

Я уже много исследовал это и ничего не нашел, особенно c.

Наиболее ценные ссылки, которые я могу найти:

https://serverfault.com/questions/744124/file-issue-with-nginx-php-fpm-on-separate-servers

nginx - php -fpm кластера

https://blog.digitalocean.com/horizontally-scaling-php-applications/

Nginx для обслуживания php файлов с другого сервера

Я прочитал несколько документов об этом, но основное сомнение остается:

Могу ли я просто удалить строку try_files из всех nginx местоположений conf и установить cgi.fix_pathinfo = 0 в php .ini, поэтому мне не обязательно иметь файлы на всех серверах?

Или для безопасности лучше смонтировать силовую систему NFS, чтобы иметь каждый файл. php на всех серверах, включая выделенные серверы php -fpm?

Некоторые люди скажем «создайте NFS и подключите его ко всем php -fpm прокси-серверам или используйте rsyn c для синхронизации c файлов через серверы» и другие Говорят, что «удалите try_files, и это будет работать», но я нашел статью, которая гласит «удалите try_files и скрестите пальцы, чтобы их не взломали». : O

Какой лучший / правильный / самый безопасный способ сделать это? Нас еще можно взломать, чтобы удалить try_files в наше время?

Если я могу просто удалить try_files, будут ли работать разные места с разными программами? Допустим, у меня есть один WP в папке root и установка Xenforo в папке / forum /. try_files отличаются друг от друга.

Блок восходящего потока перед сервером {} 

        upstream backend {
            server unix:/var/run/php/php7.3-fpm.sock weight=100 max_fails=5 fail_timeout=5;
            server unix:/var/run/php/php7.3-fpm-2.sock weight=100 max_fails=5 fail_timeout=5;
            #I want to add 192.168.x.x:9000 here to balance with this origin server
        }

Пример блоков серверов: 

        location / {
                try_files $uri $uri/ /index.php;
        }

        #AMP
        location /amp/ {
                try_files $uri $uri/ /amp/index.php;
        }

        #forum
        location /forum/ {
                try_files $uri $uri/ /forum/index.php?$uri&$args;
                index index.php index.html;
        }

        location ~ \.php$ {
            include snippets/fastcgi-php.conf;
            #fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
            fastcgi_pass backend;
        }

Я также связываю php - fpm-сервер для запуска на своем внутреннем IP-адресе (не 127.0.0.1) и установлен на accpet nginx ip-прокси для listen.allowed_clients в php .ini

Также nmap работал на php -fpm- server-IP: 9000 от исходного сервера, и он говорит, что он работает и работает.

Если вы знаете, как или, может быть, есть одна ссылка, показывающая, как, пожалуйста, поделитесь. У меня есть машины в ожидании совместной работы, пожалуйста, помогите достичь этой цели.

1 Ответ

0 голосов
/ 12 февраля 2020

Поскольку у меня не было ответов, чтобы помочь, я закончил делать NFS с исходного сервера на сервер PHP только для того, чтобы получить файлы, таким образом сохраняя try_files. Я не хотел рисковать удалением try_files, не зная точно последствий для безопасности.

Поэтому на данный момент правильный ответ для меня - сделать NFS и передать запросы NGINX в масштабирование PHP -FPM. машина. Все прошло хорошо, без особых проблем. Единственной проблемой было изменение внутреннего IP-адреса в php -fpm.conf, включение внутреннего IP-адреса в NFS-сервер и включение нового внутреннего IP-адреса в NGINX восходящий пул. И, конечно же, удаление php сессий из файлов в Redis. Таким образом, зарегистрированные страницы не будут выходить из системы при переходе с исходных запросов на серверы масштабирования.

...