3.2. Roteamento Direto por meio do LVS
As mentioned in Seção 1.4.2, “Roteamento Direto”, direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well.
- Layout da Rede
- Em uma configuração LVS de roteamento direto, o roteador LVS precisa receber as solicitações de entrada e roteá-las para o apropriado servidor real a ser processado. Os servidores reais então precisam rotear diretamente uma resposta ao cliente. Por exemplo, se um cliente estiver na Internet e enviar o pacote através do roteador LVS a um servidor real, o servidor real deve ser capaz de ir diretamente ao cliente via internet. Isto pode ser efetuado apenas configurando a entrada do servidor real para passar pacotes à Internet. Cada servidor no pool do servidor pode ter a sua própria entrada separada ( e cada entrada com a sua própria conexão de Internet ), permitindo o máximo rendimento e escalabilidade. No entanto, para configurações LVS típicas, os servidores reais podem se comunicar através de uma entrada ( e portanto uma conexão da rede ).
Importante
Não é aconselhável usar o roteador LVS como uma saída aos servidores reais, pois isto adiciona complexidades de configurações desnecessárias como também a carga da rede no roteador LVS. Esta reintroduz o afinilamento da rede existente num roteador NAT. - Hardware
- Os requerimentos do hardware de um sistema LVS usando o roteamento direto é similar às outras topologias LVS. Enquanto que o roteador precisa ser executado pela Red Hat Enterprise Linux para processar as solicitações de entrada e desempenho de balanceamento de carga para os servidores reais, onde estes não precisam ser máquinas LINUX para funcionar corretamente. Cada roteador LVS precisa de um ou dois NICs ( dependendo se há um roteador de backup ). Você pode usar dois NICs para fácil configuração e tráfego separado distinguível —as solicitações de entrada são manuseadas por um NIC e os pacotes roteados aos servidores reais por solicitação.Uma ligação à Internet é requerida, uma vez que os servidores reais contornem o roteador e enviem os pacotes de saída diretamente ao cliente. Para melhor desempenho e disponibilidade, cada servidor real pode ser conectado à sua própria entrada separada, da qual possue a própria conexão dedicada à rede portadora em que o cliente é conectado ( como por exemplo a Internet ou Intranet )
- Software
- There is some configuration outside of Piranha Configuration Tool that needs to be done, especially for administrators facing ARP issues when using LVS via direct routing. Refer to Seção 3.2.1, “Roteamento Direto e
arptables_jf” or Seção 3.2.2, “Roteamento Direto eiptables” for more information.
3.2.1. Roteamento Direto e arptables_jf
In order to configure direct routing using
arptables_jf, each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs.
Usando o método
arptables_jf, os aplicativos talvez liguem-se a cada IP individual ou portal do qual o servidor real está prestando serviço. Por exemplo, o método arptables_jf permite instâncias múltiplas do Apache HTTP Server sejam explicitamente limitadas à execução de diferentes VIPs no sistema. Existem também vantagens significantes de desempenho para usar as arptables_jf sobre a opção iptables.
No entanto, usando o método
arptables_jf, os VIPs não podem ser configurados para começar a inicialização usando as ferramentas de configuração do sistema da Red Hat Enterprise Linux padrão.
Para configurar cada servidor real com o intuito de ignorar as solicitações ARP de cada endereço IP virtual, utilize os seguintes passos:
- Crie as entradas da tabela ARP para cada endereço IP virtual em cada servidor real (o real_ip é o IP que o diretor usa para se comunicar com o servidor real; freqüentemente isto é o IP vinculado ao
eth0):arptables -A IN -d <virtual_ip> -j DROP arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
Isto induzirá os servidores reais a ignorem todas as solicitações ARP para os endereços IP virtuais, e alterarem qualquer saída de respostas ARP, que de outra forma talvez possuam o IP virtual, em vez do servidor. O único nó que deve responder às solicitações ARP, para qualquer VIPs, é o atual nó LVS ativo. - Uma vez que isto tenha sido completado em cada servidor real, salve as entradas de tabela ARP digitando os seguintes comandos em cada servidor real:
service arptables_jf savechkconfig --level 2345 arptables_jf onO comandochkconfigirá induzir o sistema a recarregar as configurações arptables na inicialização — antes da rede ser iniciada. - Configure o endereço IP virtual em todos os servidores usando
ifconfigpara criar um IP com alias. Por exemplo:#
ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 upOu usando a utilidadeiproute2ip, por exemplo:#
ip addr add 192.168.76.24 dev eth0Como visto anteriormente, os endereços IP não podem ser configurados para começar a inicialização usando as ferramentas de configuração do sistema da Red Hat. Uma maneira de trabalhar com este problema será colocando estes comandos em/etc/rc.d/rc.local. - Configure Piranha for Direct Routing. Refer to Capítulo 4, Configurando os roteadores LVS com a Piranha Configuration Tool for more information.
