Atualmente, estou tentando chegar ao cerne de um problema em que minha
LVS-director parece deixar cair um pacote vindo de um cliente de vez em quando
Tempo. Nós temos esse problema em nossos sistemas de produção e podemos reproduzir
o problema no estadiamento.
Eu postei este problema na lista de discussão lvs-users e não obtive resposta até agora.
Nossa configuração:
Estamos usando o ipvsadm com o Linux CentOS5 x86_64 em um PV XEN-DomU.
Detalhes da versão atual:
- Kernel: 2.6.18-348.1.1.el5xen
- ipvsadm: 1.24-13.el5
LVS-Setup:
Usamos o IPVS no modo DR, para gerenciar as conexões em execução que usamos
lvs-kiss.
ipvsadm está sendo executado em um cluster heartbeat-v1 (dois nós virtuais), mestre
e backup estão sendo executados constantemente em ambos os nós.
Para os serviços LVS, usamos IPs lógicos sendo configurados por pulsação
(active / passive-clustermode)
Os servidores reais são máquinas Linux físicas.
Configuração de Rede:
A VM atuando como diretora está sendo executada como XEN-PV-DomU em um Dom0 usando redes em ponte.
Redes "em jogo":
- abn-network (rede de teste, usada para conectar o cliente ao diretor),
usado pelos servidores reais para enviar a resposta aos clientes (abordagem de roteamento direto),
usado para ipvsadm slave / master multicast-traffic
- lvs-network: Esta é uma VLAN dedicada que conecta diretor e servidores reais
- DR-arp-problem: resolveu a supressão de respostas arp nos servidores reais para o service-ip
- O IP de serviço é configurado como IP lógico na interface lvs nos servidores reais.
- Nesta configuração, ip_forwarding não é necessário em nenhum lugar
diretor, nem no servidor real).
Detalhes da VM:
1 GB de RAM, 2 vCPUs, carga de sistema quase 0, memória livre de 73M, buffers de 224M, cache de 536M, sem troca.
top mostra quase sempre 100% ocioso, 0% us / sy / ni / wa / oi / si / st.
Detalhes da configuração:
ipvsadm -Ln do serviço em questão mostra:
TCP x.y.183.217:12405 wrr persistent 7200
-> 192.168.83.234:12405 Route 1000 0 0
-> 192.168.83.235:12405 Route 1000 0 0
x.y os dois primeiros octetos são da nossa classe B interna.
Usamos 192.168.83.x como lvs-network para teste.
Configuração de ipvsadm persistente:
/ etc / sysconfig / ipvsadm : --set 20 20 20
Configuração de cluster:
/etc/ha.d/haresources : $ primary_directorname lvs-kiss x.y.183.217
lvs-kiss-configuration-snippet para o serviço acima:
<VirtualServer idm-abn:12405>
ServiceType tcp
Scheduler wrr
DynamicScheduler 0
Persistance 7200
QueueSize 2
Fuzz 0.1
<RealServer rs1-lvs:12405>
PacketForwardingMethod gatewaying
Test ping -c 1 -nq -W 1 rs1-lvs >/dev/null
RunOnFailure "/sbin/ipvsadm -d -t idm-abn:12405 -r rs1-lvs"
RunOnRecovery "/sbin/ipvsadm -a -t idm-abn:12405 -r rs1-lvs"
</RealServer>
<RealServer rs2-lvs:12405>
PacketForwardingMethod gatewaying
Test ping -c 1 -nq -W 1 rs2-lvs >/dev/null
RunOnFailure "/sbin/ipvsadm -d -t idm-abn:12405 -r rs2-lvs"
RunOnRecovery "/sbin/ipvsadm -a -t idm-abn:12405 -r rs2-lvs"
</RealServer>
</VirtualServer>
idm-abn, rs1 e rs2 resolvem via / etc / hosts .
Sobre o serviço:
Este é um serviço da web do Soa.
Como reproduzimos o erro:
De um cliente, executamos chamadas constantes para o serviço da web em um intervalo de uma chamada em três segundos.
De tempos em tempos, haverá uma conexão redefinida do diretor para o cliente.
Interessante: isso acontece em n x 100 + 1 tentativas - interessante é o único.
O que fizemos para rastrear o problema:
- Verificado / proc / sys / net / ipv4 / vs : todos os valores são definidos como padrão, portanto, drop_packet NÃO está no lugar (= 0)
- tcpdump no cliente, fronteado / abn do diretor, backend / lvs do diretório, lvs e abn dos servidores reais
Neste tcpdump nós pudemos ver uma requisição do cliente, respondida por um
conexão-reset pelo diretor.
O pacote NÃO foi encaminhado via LVS.
Congratulo-me com quaisquer ideias sobre como rastrear este problema mais abaixo.
Se alguma informação não estiver clara / faltando para detalhar o problema - por favor
pergunte.