Apache Mod_Proxy como Front-End de acesso e balanceamento de diversas aplicações web
Já pensou em ter que disponibilizar uma porta 80 ou 443 para cada aplicação web? Não seria nada barato e nem prático. Mesmo que você tenha um range de IPs fixos para isso, não seria muito interessante. Então, conheça (caso ainda não) o Apache Mod_Proxy para resolver este problema!
Parte 6: Front-End e balanceamento para aplicações PHP
Para o próximo exemplo temos mais alguns detalhes a mais, pois são 2 servidores back-end, ou seja, as requisições serão distribuídas entre ambos.
Veja a configuração do segundo exemplo:
Observe que o acesso das 2 aplicações que estão disponíveis nestes servidores, é configurado dentro do mesmo VirtualHost. Caso houvesse mais servidores back-end, bastaria incluí-los como BalancerMember's e não necessariamente para todas as aplicações, poderia ser apenas para 1 delas.
Se tivéssemos uma terceira aplicação, esta poderia ser inclusa dentro do mesmo VirtualHost e, não necessariamente, ser distribuída por 2 ou mais servidores back-end, poderia ser indicada para ser atendida apenas por um dos servidores back-ends, teríamos o mesmo caso do primeiro exemplo que mostramos com o servidor IIS.
Uma observação em relação às instruções "stickysession" e "route" no balanceamento, é que no exemplo que estamos mostrando, o balanceamento é realizado de forma simples. A "stickysession" (no caso de PHP) se utilizada com cookie de sessão, pode ser alterada para "PHPSESSID" e a instrução "route" pode ser alterada para a identificação do servidor. Mais detalhes sobre estas instruções podem ser encontradas na documentação oficial.
Veja a configuração do segundo exemplo:
<VirtualHost *:80>
ServerName nome2.site.com # Nome do site
ServerAlias nome2.site.com # URL que o site é acessado
ProxyRequests Off
ProxyPreserveHost On
ErrorLog logs/nome2_site_error_log # Arquivo de logs de erro especifico para o site
TransferLog logs/nome2_site_access_log # Arquivo de logs de acessos especifico para o site
LogLevel warn
<Proxy 192.168.1.1:80> # Permissão para o servidor front-end (proxy)
Order deny,allow
Allow from all
</Proxy>
#ProxyPass /balancer-manager ! # Não é permitido acessar o balanceador através do front-end
# APP1
ProxyPass /app1 balancer://balancer/app1
ProxyPassReverse /app1 balancer://balancer/app1
<Proxy balancer://balancer/app1 stickysession=ROUTEID lbmethod=byrequests nofailover=off>
BalancerMember http://192.168.1.3 min=10 max=100 loadfactor=1 route=1
BalancerMember http://192.168.1.4 min=10 max=100 loadfactor=1 route=2
</Proxy>
# APP2
ProxyPass /app2 balancer://balancer/app2
ProxyPassReverse /app2 balancer://balancer/app2
<Proxy balancer://balancer/app2 stickysession=ROUTEID lbmethod=byrequests nofailover=off>
BalancerMember http://192.168.1.3 min=10 max=100 loadfactor=1 route=1
BalancerMember http://192.168.1.4 min=10 max=100 loadfactor=1 route=2
</Proxy>
# Visualização do balanceamento entre os 2 servidores back-end
<Location /balancer-manager>
Order deny,allow
Deny from all
Allow from 192.168.1. # Quem pode acessar o balanceador para visualizar as estatísticas
SetHandler balancer-manager
</Location>
</VirtualHost>
ServerName nome2.site.com # Nome do site
ServerAlias nome2.site.com # URL que o site é acessado
ProxyRequests Off
ProxyPreserveHost On
ErrorLog logs/nome2_site_error_log # Arquivo de logs de erro especifico para o site
TransferLog logs/nome2_site_access_log # Arquivo de logs de acessos especifico para o site
LogLevel warn
<Proxy 192.168.1.1:80> # Permissão para o servidor front-end (proxy)
Order deny,allow
Allow from all
</Proxy>
#ProxyPass /balancer-manager ! # Não é permitido acessar o balanceador através do front-end
# APP1
ProxyPass /app1 balancer://balancer/app1
ProxyPassReverse /app1 balancer://balancer/app1
<Proxy balancer://balancer/app1 stickysession=ROUTEID lbmethod=byrequests nofailover=off>
BalancerMember http://192.168.1.3 min=10 max=100 loadfactor=1 route=1
BalancerMember http://192.168.1.4 min=10 max=100 loadfactor=1 route=2
</Proxy>
# APP2
ProxyPass /app2 balancer://balancer/app2
ProxyPassReverse /app2 balancer://balancer/app2
<Proxy balancer://balancer/app2 stickysession=ROUTEID lbmethod=byrequests nofailover=off>
BalancerMember http://192.168.1.3 min=10 max=100 loadfactor=1 route=1
BalancerMember http://192.168.1.4 min=10 max=100 loadfactor=1 route=2
</Proxy>
# Visualização do balanceamento entre os 2 servidores back-end
<Location /balancer-manager>
Order deny,allow
Deny from all
Allow from 192.168.1. # Quem pode acessar o balanceador para visualizar as estatísticas
SetHandler balancer-manager
</Location>
</VirtualHost>
Observe que o acesso das 2 aplicações que estão disponíveis nestes servidores, é configurado dentro do mesmo VirtualHost. Caso houvesse mais servidores back-end, bastaria incluí-los como BalancerMember's e não necessariamente para todas as aplicações, poderia ser apenas para 1 delas.
Se tivéssemos uma terceira aplicação, esta poderia ser inclusa dentro do mesmo VirtualHost e, não necessariamente, ser distribuída por 2 ou mais servidores back-end, poderia ser indicada para ser atendida apenas por um dos servidores back-ends, teríamos o mesmo caso do primeiro exemplo que mostramos com o servidor IIS.
Uma observação em relação às instruções "stickysession" e "route" no balanceamento, é que no exemplo que estamos mostrando, o balanceamento é realizado de forma simples. A "stickysession" (no caso de PHP) se utilizada com cookie de sessão, pode ser alterada para "PHPSESSID" e a instrução "route" pode ser alterada para a identificação do servidor. Mais detalhes sobre estas instruções podem ser encontradas na documentação oficial.