A tarefa era implementar uma solução tolerante a falhas para dois servidores da Web e, se possível, implementar o balanceamento de carga entre servidores da Web, pois às vezes um banco de dados não era capaz de lidar com todas as solicitações. Não foi possível comprar equipamento especial, em relação ao qual o esquema a seguir foi inventado. Talvez a ideia não seja original, mas na Internet não encontrei nada parecido. Nossa topologia é a seguinte:
Há um roteador Cisco que traz servidores da Web para a Internet. Dois servidores web no Centos 7 com nginx. Os endereços IP do primeiro e do segundo servidor Web são 192.168.20.176/24 e 192.168.20.177/24, respectivamente. Para implementar o plano, os servidores da Web precisam definir o mesmo endereço IP secundário. Pode ser qualquer endereço IP privado que não seja usado na sua rede. Selecionei 192.168.120.175 e o registrei com o endereço IP secundário da interface principal eth0 dos servidores web. No Centos, isso é feito criando o arquivo eth0: 0 no diretório / etc / sysconfig / network-scripts /. Conteúdo do arquivo:
TYPE="Ethernet" DEVICE=eth0:0 BOOTPROTO="static" IPADDR=192.168.120.175 NETMASK=255.255.255.255 ONBOOT="yes"
É importante observar que a máscara 255.255.255.255 é usada e isso evita conflitos de IP, pois os servidores da Web não a utilizam para gerar tráfego. Por assim dizer, teremos interfaces Loopback em servidores web.
Depois disso, o roteador pode implementar o balanceamento de carga usando o roteamento estático. Essa tecnologia é implementada usando IP Cef em roteadores Cisco. Link
aqui . Outros fornecedores podem ter certas nuances.
Na Cisco, a distribuição de threads pode ser de duas maneiras:
- Por destino (padrão). Nós precisamos dessa opção. Todos os pacotes de um fluxo serão enviados para um dos dois servidores. O princípio da operação é que o hash seja calculado pelos endereços IP de origem e destino e, dependendo desse hash, a primeira rota (servidor) ou a segunda é selecionada. Em seguida, modificaremos levemente esse comportamento.
- Por pacote. Essa opção não nos convém, pois o balanceamento ocorrerá nos pacotes. Grosso modo, o primeiro pacote na primeira rota, o segundo pacote na segunda.
Nós prescrevemos duas rotas com a ajuda dos comandos:
ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.176 ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.177
Assim, as duas rotas serão instaladas na tabela de roteamento e a distribuição de carga será realizada ao longo delas:
Também verificamos se o método de balanceamento está selecionado corretamente:
O endereço IP de origem será alterado e o IP de destino será sempre deixado em paz. Isso pode afetar a uniformidade de balanceamento, considerando o NAT. Para otimização, você pode considerar a porta de origem, que será aleatoriamente diferente, dependendo da sessão do cliente. Para fazer isso, use o seguinte comando:
ip cef load-sharing algorithm include-ports source
Você também precisa configurar o NAT estático para redirecionar solicitações da Web para o endereço 192.168.120.175:
ip nat inside source static tcp 192.168.120.175 80 interface GigabitEthernet0/1 80
O que nós ganhamos? Solicitações de usuários da Internet irão para o nosso roteador, que as distribuirá entre nossos servidores por fluxos, dependendo da porta de origem no TCP. Quando você abre uma nova sessão, o cliente pode acessar o novo servidor.
O que acontece se um dos servidores travar? A rota que levou a este servidor será removida da tabela de roteamento. Para otimizar esse processo, você pode usar o SLA IP. Monitore o status dos servidores executando ping a cada 10 segundos:
ip sla 10 icmp-echo 192.168.20.176 frequency 10 ip sla schedule 10 life forever start-time now ip sla 20 icmp-echo 192.168.20.177 frequency 10 ip sla schedule 20 life forever start-time now
Em seguida, adicione monitoramento às rotas apropriadas:
ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.176 track 10 ip route 192.168.120.175 255.255.255.255 GigabitEthernet0/0 192.168.20.177 track 20
O IP SLA nos roteadores Cisco também permite o monitoramento por solicitações HTTP GET, o que ajudará a determinar a falha do servidor da web não apenas por sua ausência na rede, mas também quando o serviço da web estiver inoperante.
Portanto, construir esse esquema não requer equipamento adicional nem software para servidores da web. Tudo que você precisa é de um roteador com a capacidade de equilibrar o tráfego.