Kemp LoadMaster Guia Prático 2014 v1.1 Renato Pesca
renato.pesca@alog.com.br 1. Topologias One Armed Balancer Figura 1: Topologia single-armed. Esta topologia mostra que as máquinas reais fazem parte da mesma rede dos nós virtuais. Não faz sentido trabalhar com SNAT em configurações como esta, assim como não se aplica a configuração em DSR (visto adiante).
A transparência não funcionará com clientes localizados na mesma rede lógica do Load Balance em uma configuração DSR. Ela também não é suportada quando os clientes estão localizados na mesma rede lógica e o Load Balance em uma configuração de NAT. Two-Armed e Multi-Armed Balancer Figura 2: Topologia two-armed.
Figura 3: Topologia two-armed em HA. Direct Server Return (DSR)
Figura 4: Topologia single-armed para DSR. Neste caso, as seguintes etapas ocorrem: Requisição é recebida pelo Load Balance Requisição é roteada para o Server 1 (exemplo) Server 1 responde diretamente ao cliente, sem retornar pelo Load Balance Obs: esta característica só deve ser utilizada se o servidor real puder responder aos clientes diretamente, sem atravessar o Load Balance; a única opção de persistência suportada é aquela baseada no IP fonte da requisição ( Source IP Address ); DSR é uma opção de Layer 4, ou seja, não é possível balancear usando a camada de aplicação (Layer 7).
2. Acesso à Internet dos Real Servers Em topologias two-armed e multi-armed é interessante que os nós tenham acesso à Internet através do balancer. Usando SNAT o balancer mapeará todas as conexões originadas dos servidores reais fazendo-as parecer como tendo sido originadas nele através do IP configurado na interface eth0 ou do IP associado ao VIP. Obs: o uso de SNAT em configurações single-armed não é recomendado. Figura 5: Topologia two-armed.
3. Balanceamento de Servidores não-pertencentes às Subredes Configuradas no Appliance Balanceamento de serviços localizados em redes que não fazem parte das interfaces locais também é permitido. Para tal, em uma configuração de Virtual Service marque a caixa Force L7 Habilite balancing de servidores que não residem na mesma subrede do appliance em System Configuration > Miscellaneous Options > Network Options > Enable Non-Local Real Servers.
Figura 6: Topologia two-armed para servidores não pertencentes à sub-rede do Load Balance. 4. Algoritmos de Balanceamento Round Robin As requisições são distribuídas sequencialmente entre as máquinas disponíveis no pool. Atente-se de que os servidores devem suportar a demanda de forma equilibrada, caso contrário máquinas incapazes de atender a todas as requisições podem ser sobrecarregadas.
Weighted Round Robin Atribui pesos aos nós reais em Round Robin. Exemplo: para um servidor com peso 100 e outro com peso 50, antes que o segundo receba a primeira requisição, o primeiro já recebeu duas consecutivas. Least Connection As requisições são distribuídas com base nas conexões que cada servidor mantém até o momento. O servidor no cluster com menor número de conexões automaticamente recebe o próximo pedido. Weigthed Least Connection Se os servidores possuírem diferentes capacidades de carga a atribuição de pesos proporciona o consumo mais optimizado de recursos. Este algoritmo utiliza a taxa do número de conexões para definir o peso atribuído ao servidor. Agent Based Adaptative Balancing
Checa o estado dos servidores em intervalos regulares de tempo independentemente dos pesos configurados. O balancer periodicamente checa o load do sistema em todos os servidores, onde cada máquina deve fornecer um arquivo que contém um valor numérico entre 0 e 99 representando o load atual (o balancer requisita este arquivo através do método HTTP GET). Em período de baixo tráfego o balancer usa o algoritmo Weighted Round Robin, quando o load de todos os servidores alcança um valor definido pelo administrador; acima deste valor ele altera o algoritmo para Adaptative Balancing. Em períodos normais o algoritmo calcula os pesos baseado nos loads coletados de todos os servidores. Fixed Weighted Quanto maior o peso atribuído a um nó, maior prioridade ele terá no recebimento das próximas requisições. 5. Persistência Persistência consiste em requisições de um cliente individual enviadas para um mesmo servidor no pool de máquinas. Ela não é ativa por padrão, aparece como uma opção configurável para cada Virtual Service.
Sem persistência o LoadMaster direcionará o tráfego de acordo com o algoritmo de balanceamento utilizado. Figura 7: Acessos sem persistência.
Figura 8: Acessos com persistência. O ajuste é feito por Virtual Service, na tela de edição do Virtual Service sob o grupo Standard Options, menu drop-down que mostra todas as opções disponíveis para persistência. Para cada método de persistência há um parâmetro de timeout que pode ser configurado. 5.1. Métodos de Persistência Layer 4 Source IP Address Método mais simples de persistência, que considera o endereço IP de origem para diferenciar os usuários, operando com todos os protocolos TCP, inclusive aqueles que não são baseados em HTTP.
Source IP Netmask Determina quão preciso o LoadMaster será com o endereço IP origem para definir a persistência, baseado na máscara de rede. Figura 9: Configuração de persistência em Source IP Address. Desvantagens (drawback) Há situações para as quais o método Source IP Address não trabalha bem: muitos usuários conectando do mesmo IP origem um usuário trocando seu IP A persistência em Layer 7 resolveria estes problemas, porém somente para o protocolo HTTP (ou HTTPS quando a sessão é encerrada pelo LoadMaster). 5.2. Métodos de Persistência em Layer 7 Source IP Address Usado com uma chave (key) para a persistência junto com a máscara de rede: netmask+k. Quando a máscara é 255.255.255.255 (padrão), isso define uma persistência para cada endereço IP individual, caso contrário cada grupo de endereços IP será redirecionado para o mesmo servidor real.
Super HTTP O balancer checa os campos User-Agent e Authorization Header do protocolo HTTP, se presentes, onde conexões com a mesma combinação de headers são associadas com o mesmo servidor real. URL Hash Persistence O LoadMaster enviará as requisições com a mesma URL para o mesmo servidor real. HTTP Host Header O balancer enviará à mesma máquina real requisições com o campo HTTP Host configurado para ele. Hash of HTTP Query Item Todas as queries com o mesmo Query Item serão associadas ao mesmo servidor real. Obs: Query Item representa uma inspeção na URL (URL Query String) para um determinado valor. Selected Header O balancer checa os campos User-Agent e Authorization Header do protocolo HTTP, se presentes, onde conexões com a mesma combinação de headers são associadas com o mesmo servidor real. Considerações sobre HTTPS/SSL
Se a conexão SSL não é intermediada pelo LoadMaster as únicas opções disponíveis são Source IP Address e SSL Session ID Persistence, caso contrário (o LoadMaster intermedia as conexões) todas as opções de persistência podem ser utilizadas. 6. Criação de HTTP Virtual Services i Do menu principal, selecione Virtual Services. Em Virtual Services, clique no botão Add New. Para o campo Virtual Address, digite o IP e defina a porta 80. Clique no botão Add this Virtual Service para configurar Properties for x.y.z.w:80. Defina o Service Nickname, clicando no botão Set Nickname em seguida. Clique no botão Add New em Real Server para adicionar o primeiro nó real. Digite o IP para Real Server Address e clique no botão Add this Real Server. Clique na opção View/Modify sob a aba Virtual Services no menu principal. Verifique se o Virtual Service aparece com IP virtual e porta corretos, e o status dos real servers (Up ou Down). 7. Criação de HTTPS Virtual Services ii Do menu principal, selecione Virtual Services. Em Virtual Services, clique no botão Add New. Para o campo Virtual Address, digite o IP e defina a porta 443. Clique no botão Add this Virtual Service para configurar Properties for x.y.z.w:443.
Defina o Service Nickname, clicando no botão Set Nickname em seguida. Marque a caixa Enable para SSL Acceleration na seção Properties Caso apareca a mensagem There is no SSL certificate file currently available for Virtual Service x.y.z.w. A temporary certificate will be used until a valid certificate is installed, ignore-a. Clique no botão Add New em Real Server para adicionar o primeiro nó real. Digite o IP para Real Server Address e clique no botão Add this Real Server, e mantenha a porta 80. Clique na opção View/Modify sob a aba Virtual Services no menu principal. Verifique se o Virtual Service aparece com IP virtual e porta corretos, e o status dos real servers (Up ou Down). 8. Front-End Services Proporcionam melhor uso da banda e recursos dos servidores. Consiste em: Cache Poupa processamento e banda, pois reduz o número de requisições aos servidores reais. Pode ser ativado para HTTP Virtual Services e HTTPS Virtual Services em Advanced Properties do Virtual Service, habilitando a caixa Enable Caching. Obs: somente conteúdo estático será armazenado; requisições com header no-cache não sofrerão cache de
acordo com a RFC 2616; não há monitoração para mudanças nos arquivos, ou seja, ou você utiliza F5 para recarregar a página atualizada no seu navegador, ou então desabilita e habilita a caixa Enable Caching. A quantidade de memória para o cache pode ser configurada em Advanced Properties do Virtual Service em questão. Figura 10: Acessos com e sem cache. Figura 11: Configuração de cache. Compressão de Dados Figura 12: Ajuste de tamanho de cache.
Utiliza compressão gzip, reduzindo assim a quantidade de dados trafegada entre o LoadMaster e os navegadores e consequentemente o consumo da banda. Este recurso é suportado para todos os arquivos, porém o navegador deve suportar compressão. O recurso pode ser ativado em Advanced Properties do Virtual Service, ativando a caixa Enable Compression. 9. Considerações sobre SSL Figura 13: Acessos com e sem utilização de compressão. SSL Acceleration faz com que a sessão SSL seja estabelecida no LoadMaster. Isso permite que os servidores reais não usem SSL e que o LoadMaster efetue balanceamento na camada de aplicação (Layer 7 Balancing).
Sem isso os headers não podem ser lidos já que SSL implica encriptação de todos os dados de acesso. 10. Health Checking O LoadMaster utiliza Layer3, Layer4 e Layer7 para monitorar a disponibilidade dos servidores reais. Quando um servidor não responde em um intervalo de tempo um determinado número de vezes, é considerado indisponível e seu peso é ajustado para zero. Isso significa que ele é removido da lista de servidores reais do Virtual Service, retornando quando o health check considerar que ele está disponível novamente. Health checks baseados em serviços (Layer 7) impedem que uma máquina real seja removida do pool de todos os Virtual Services caso os health checks sejam diferentes. Segue abaixo uma tabela que mostra os tipos disponíveis e as camadas associadas a eles: Camada Tipo 3 ICMP 4 TCP 7 FTP 7 TELNET 7 SMTP 7 HTTP 7 HTTPS 7 POP3 7 NNTP 7 IMAP 7 DNS 7 RPD 11. Configurações via Interface Gráfica de Usuário
Login Figura 14: Acesso à Interface Gráfica de Configuração. Criação de Virtual Service Figura 15: Virtual Services.
Figura 16: Parâmetros de um Virtual Service. Adição de Real Server Figura 17: Parâmetros de um Real Server. Modificando um Virtual Service Existente
Figura 18: Configurações detalhadas de um Virtual Service. Compreendendo o status de Virtual Servers
No mínimo há um servidor real disponível. Não há servidores reais disponíveis. Todos os servidores reais estão down e o tráfego está sendo roteado por um servidor em separado. O servidor foi administrativamente desabilitado. Foi configurada uma resposta de redirecionamento. Foi configurada uma mensagem de erro.
O administrador desabilitou a checagem dos servidores reais.
i Este passo-a-passo pode ser utilizado para criar um Virtual Service que também sirva requisições HTTPS caso Layer 7 esteja ativo. Para isso, em Extra Ports configure a porta 443. ii Conexões intermediadas pelo LoadMaster, ou seja, haverá necessidade de instalar certificados digitais no appliance. Esta não é a forma mais utilizada na ALOG.