Balanceamento de carga em GNU/Linux O que temos e o que falta? Fernanda G Weiden
Google's mission To organize the world s information and make it universally accessible and useful
Introdução Serviço no mundo digital Disponibilidade Escalabilidade Velocidade de crescimento às vezes não é previsível Combinar melhor custobenefício também na compra de hardware Downtime para manutenção não traz clientes felizes
Balanceamento de carga Muitas máquinas (backends) efetuando a mesma tarefa Escalabilidade sem downtime Possibilidade de crescimento rápido sem necessidade de renovação de hardware Melhor utilização de recursos de hardware Tolerância a falhas Alta disponibilidade
Balanceamento de carga Load Balancer máquina(s) que recebem e distribui as requisições Virtual Server combinação de IP:porta configurados no Load Balancer Backend servidor real (físico ou não) Cliente quem requisita o serviço VIP é o endereço IP conhecido pelo cliente RIP endereço IP do backend (real server) CIP endereço IP do cliente
DNS round robin DNS based load balancing cluster configurado no servidor de nomes. Maneira mais fácil de criar um cluster de servidores. www.google.com. 60 IN A 10.0.0.1 www.google.com. 60 IN A 10.0.0.2 www.google.com. 60 IN A 10.0.0.3 www.google.com. 60 IN A 10.0.0.4
Global Server Load Balancing Distribui o tráfego entre um cluster geograficamente distribuído, baseado na localização do cliente e na disponibilidade do servidor/cluster DNS based Routing based
Dispatcher based load balancing cluster É o método tradicional de balanceamento de carga O usuário só conhece o VIP, e não todos os backends Baseado em IP ou aplicação Tolerância a falha Grande controle sob as conexões e utilização dos backends (estado, persistência)
Madonna-like
O que temos em GNU/Linux? DNS round robin Routing based GSLB ip_vs - dispatches LB cluster
ip_vs Layer 4 switch half NAT tunneling DSR
NAT NAT muda o endereço de destino do pacote, e redireciona ao backend. A conexão passa pelo director antes de retornar ao cliente.
Tunneling TUN Túnel entre o Load Balancer e os Backend Necessária configuração e suporte a túneis em todos os backends.
Direct server response DSR o backend responde a requisição direto ao cliente, sem passar pelo director (no retorno). Backends e LB no mesmo segmento de rede. Requer non-arp interface nos backends.
Algoritmos para Scheduling Define a distribuição das requisições entre os backends. RR: Round Robin WRR: Weighted Round Robin LC: Least Connection WLC: Weighted Least Connection
Persistência Source IP conexões de um mesmo IP de origem são direcionadas ao mesmo backend. Cookie Insertion (http) o load balancer adiciona um cookie no header http, que vai conter informação sobre qual backend utilizar SSL session ID persistência baseado no ID da sessão, que faz parte do SSL handshake
Heartbeat Gerenciamento de recursos entre os nodes de um cluster de alta disponibilidade
Monitoramento de backends ldirectord nao tem monitoramento paralelo instancias individuais por VIP keepalived nao tem instancias individuais por VIP
IPv6 mainstream no linux 2.6.28 ip_vs movido de net/ipv4/ipvs para net/netfilter/ipvs adicionada interface netlink para comunicacao interprocesso
O que falta? monitoramento paralelo de backends full NAT/proxy (+ failback) checar status atual de um VIP e seus backends read-only mode (ipvsadm funciona somente como root) suporte IPv6 espelhamento de configuracao entre HA nodes
nanda@localhost> sh vserver mywebserver mywebserver (192.168.1.66:80) - ANY Type: ADDRESS State: UP Effective State: UP Client Idle Timeout: 120 sec Method: LEASTCONNECTION Mode: MAC Persistence: NONE Backup: mybackupcluster Connection Failover: DISABLED 1) backend1_http (192.168.1.1:80) - ANY State: UP Weight: 1 2) backend2_http (192.168.1.2:80) - ANY State: UP Weight: 1 3) backend3_http (192.168.1.3:80) - ANY State: UP Weight: 1 Done
pfrost@localhost> sh service backend1_http backend1_http (192.168.1.1:80) - ANY State: UP Server Name: backend1.mydomain Max Conn: 0 Max Req: 0 Max Bandwidth: 0 kbits Use Source IP: YES Client Keepalive(CKA): NO Access Down Service: NO TCP Buffering(TCPB): NO HTTP Compression(CMP): NO Idle timeout: Client: 120 sec Server: 120 sec Client IP: DISABLED Server ID : 0 Monitor Threshold : 0 1) Monitor Name: http State: UP Weight: 1 Probes: 1064893 Failed [Total: 2979 Current: 0] Last response: Success - 200 OK. 2) Monitor Name: ping State: UP Weight: 1 Probes: 2128057 Failed [Total: 637 Current: 0] Last response: Success - TCP syn+ack received.
Perguntas?