Post on 05-Oct-2018
Implementação de um balanceador de carga utilizando
o Linux Virtual Server
Caciano MachadoEverton FoscariniFernando Macedo
Roteiro● Conceitos básicos● Problemas/Motivações● Alternativas estudadas● Arquitetura da Solução● Topologia da Rede● Failover automático● Resultados● Conclusões
Conceitos básicos
Balanceador de Carga● Clientes vêem apenas 1
servidor● permite redundância e
escalabilidade
● VIP - IP virtual - IP do serviço● Realserver - Servidor real -
destino do balanceamento
realservers
Clientes
Problemas/Motivações● Entre 2004 e 2012 foi utilizada funcionalidade do
roteador principal da Universidade○ Enterasys ALB○ Cisco SLB
● Roteador não tem hardware dedicado para balanceamento
● Implementado através de NAT
● Comprometimento do roteador em picos de carga / DoS
● Cisco SLB não tem suporte ao IPv6
Problemas/Motivações● Divulgação do Vestibular 2012 (Janeiro)
Alternativas estudadas● Cisco Content Switching Module
○ Módulo do roteador Cisco utilizado na UFRGS● Prós:
○ Hardware dedicado○ Configurações semelhantes (familiaridade
para equipe)○ Contrato de suporte, consultoria para
configurações● Contras:
○ Ponto único de falha○ Não suporta IPv6○ Aprisionamento tecnológico○ Custo de aquisição
Alternativas estudadas● Linux Virtual Server
○ Balanceador TCP/UDP implementado no Kernel Linux
● Prós:○ Suporta IPv6○ Custo zero○ Permite redundância○ 7 algoritmos de escalonamento○ Probes avançados e personalizáveis (Perl)
● Contras:○ Solução precisa ser customizada○ Custo operacional de desenvolvimento
Algoritmos de escalonamento● Round-Robin Scheduling● Weighted Round-Robin Scheduling● Least-Connection Scheduling● Weighted Least-Connection Scheduling● Locality-Based Least-Connection Scheduling● Locality-Based Least-Connection with Replication Scheduling● Destination Hashing Scheduling● Source Hashing Scheduling● Shortest Expected Delay Scheduling● Never Queue Scheduling
Arquitetura da Solução● LVS Primário + LVS Standby
○ Elimina ponto único de falha
● Replicação de estado○ Failover transparente para
clientes, conexões mantidas
● Monitoramento entre LVS○ Standby assume serviços
ao detectar falha do primário
Topologia da rede● Topologia LVS-DR (Direct Routing)
● 2 segmentos de rede (VLANs)○ Roteador -> LVS○ LVS -> Realserver -> Roteador
● Pacote IP endereçado ao VIP○ Balanceamento feito em nível 2
● VIP está na interface loopback do LVS e de todos os RealServers
● Tráfego de retorno não passa pelo LVS
Failover Automático● Implementado através de
SLA/Track○ Escolhido pela simplicidade
da implementação e menor acoplamento
● Roteador tem rotas para VIP com pesos diferentes
● LVS Standby muda rotaao subir interface eth0:0
● Outras soluções○ Heartbeat○ OSPF
Serviços em produção
● www.ufrgs.br (3 realservers)● smtp.ufrgs.br (2)● radius (2)● LDAP (4)● matricula.ufrgs.br (3)
Próximos serviços● Intranet● proxy● webmail
Especificações● Máquinas virtuais em hosts Citrix XenServer
○ 2 vCPUs com 512MB de RAM○ 2 interfaces de rede
● CentOS Linux 6
● ipvsadm (similar a iptables)
● ldirectord (probes, ativação e desativação de RealServer)
● Implementação de failover in-house
Resultados
Teste de cargaLVS
Vestibular 2012Cisco SLB
Resultados
Monitoramento do servidor LVS durante teste de carga
Resultados
Tráfego de rede do serviço testado
Resultados
Vestibular 2013
Conclusões
● Aumento de 4 vezes no número de conexões por segundo
● Atingimos limite do pool de servidores web
● Nenhum impacto no desempenho dos equipamentos de rede
● Serviço web teve throughput de 1.5Gbit (2 servidores)
Conclusões● LVSs redundantes permitem manutenções em
horário comercial
● Independência de hardware
● Controle total da solução
● Troubleshooting requer apenas conhecimento de TCP/IP e Linux
Dúvidas
Caciano Machado - caciano@cpd.ufrgs.br
Everton Foscarini - foscarini@cpd.ufrgs.br
Fernando Macedo - fmacedo@cpd.ufrgs.br
http://www.ufrgs.br/viiwticifes/