Implementação de um balanceador de carga utilizando o Linux Virtual Server. Caciano Machado Everton Foscarini Fernando Macedo

Transcrição

1 Implementação de um balanceador de carga utilizando o Linux Virtual Server Caciano Machado Everton Foscarini Fernando Macedo

2 Roteiro Conceitos básicos Problemas/Motivações Alternativas estudadas Arquitetura da Solução Topologia da Rede Failover automático Resultados Conclusões

3 Conceitos básicos Clientes 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

4 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

5 Problemas/Motivações Divulgação do Vestibular 2012 (Janeiro)

6 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

7 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

8 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

9 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

10 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

11 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 rota ao subir interface eth0:0 Outras soluções Heartbeat OSPF

12 Serviços em produção (3 realservers) smtp.ufrgs.br (2) radius (2) LDAP (4) matricula.ufrgs.br (3) Próximos serviços Intranet proxy webmail

13 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

14 Resultados Vestibular 2012 Cisco SLB Teste de carga LVS

15 Resultados Monitoramento do servidor LVS durante teste de carga

16 Resultados Tráfego de rede do serviço testado

17 Resultados Vestibular 2013

18 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)

19 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

20 Dúvidas Caciano Machado - caciano@cpd.ufrgs.br Everton Foscarini - foscarini@cpd.ufrgs.br Fernando Macedo - fmacedo@cpd.ufrgs.br