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/