Server Load Balancer:Grupos de servidores CLB

Grupo de servidores primário/secundário

1. Acesse a página CLB – Instances, clique em no ID da instância alvo, selecione Primary/Secondary Server Groups e clique em Create Primary/Secondary Server Group.

2. Add servidores:

   • Defina Server Type e Resource Group para filtrar os recursos disponíveis.

   • Para adicionar uma ENI, primeiro ative o modo avançado e, em seguida, clique em no ícone de adição ao lado da instância ecs com a ENI vinculada para localizar a ENI alvo. Selecione a ENI e escolha o IP.

   • Apenas dois servidores de backend podem ser adicionados.

4. Configure a Port para os servidores selecionados. Clique em Add Port para atribuir múltiplas portas diferentes ao mesmo servidor de backend. Após adicionar, selecione Primary Server para definir a relação primário/secundário.

API

Grupo de servidores padrão

• Chame AddBackendServers para adicionar servidores de backend.

• Chame SetBackendServers para definir os pesos dos servidores de backend.

• Chame RemoveBackendServers para remover servidores de backend.

Grupo de servidores vServer

• Chame CreateVServerGroup para crie um grupo de servidores vServer e adicionar servidores de backend com configurações de porta e peso.

• Chame AddVServerGroupBackendServers / RemoveVServerGroupBackendServers para adicionar ou remover servidores de backend de um grupo de servidores vServer especificado.

• Chame DeleteVServerGroup para exclua um grupo de servidores vServer.

Grupo de servidores primário/secundário

• Chame CreateMasterSlaveServerGroup para crie um grupo de servidores primário/secundário.

• Chame DeleteMasterSlaveServerGroup para exclua um grupo de servidores primário/secundário.

FAQ

Posso ajustar o número de instâncias ecs enquanto a instância CLB está em execução?

• Grupo de servidores padrão e grupo de servidores vServer: É possível adicionar ou remover instâncias ecs de backend a qualquer momento e alternar entre diferentes instâncias ecs. Para garantir a estabilidade do service, ative as verificações de integridade antes de realizar essas operações e garanta que pelo menos uma instância ecs íntegra permaneça no backend.

• Grupo de servidores primário/secundário: Não suportado.

As instâncias ecs de backend podem usar sistemas operacionais diferentes?

Sim, elas podem ser diferentes.

O CLB não restringe os sistemas operacionais das instâncias ecs de backend, desde que os serviços de aplicação e os dados sejam consistentes. Recomendamos usar o mesmo sistema operacional para facilitar o gerenciamento e a manutenção.

Posso usar instâncias ecs de regiões diferentes como servidores de backend?

O CLB não suporta a vinculação direta de servidores de backend entre regiões. Para implementar implantação entre regiões, use uma das seguintes soluções:

• Implante o Global Traffic Manager acima do CLB e implante múltiplas instâncias CLB em várias regiões. Alterne entre as instâncias CLB para alcançar a vinculação entre regiões.

• Use o Application Load Balancer (ALB) ou o Network Load Balancer (NLB), que suportam vinculação de backend entre regiões.

Por que há requisições frequentes de IPs começando com 100 para minha instância ecs?

Essas requisições vêm das verificações de integridade e monitoramento de disponibilidade do balanceador de carga.

• Origem: Bloco CIDR reservado da alibaba cloud 100.64.0.0/10.

• Segurança: Este bloco CIDR é reservado pela alibaba cloud e não pode ser alocado para outros usuários; portanto, não representa risco de segurança.

• Recomendação: Garanta que o iptables dos seus servidores de backend ou outros softwares de segurança de terceiros não bloqueiem este bloco CIDR para manter a disponibilidade do service.

Se as verificações de integridade falharem, consulte How do I troubleshoot health check failures?

Minha instância ecs não tem compressão ativada, mas as respostas http do CLB estão compactadas. Por quê?

• Motivo: A compressão Gzip está ativada na configuração do listener do CLB e o navegador do cliente suporta compressão.

• Ação: Para desativá-la, desligue a compressão Gzip nas configurações do listener no console do CLB ou mude para um listener TCP.

Uma instância ecs usando http/1.0 suporta codificação de transferência fragmentada (chunked)?

Sim.

Por que minha instância ecs de backend do CLB recebe frequentemente requisições com User-Agent KeepAliveClient?

• Observação: O ecs de backend recebe muitas requisições GET de endereços ip internos com User-Agent KeepAliveClient.

• Motivo: O protocolo do listener é TCP, mas o protocolo de verificação de integridade está definido como http. Quando um listener TCP usa verificações de integridade http, ele usa o método GET por padrão.

• Solução: Alinhe o protocolo do listener e o protocolo de verificação de integridade (por exemplo, use ambos TCP ou ambos http).

Posso modifique a porta do servidor no grupo de servidores padrão?

A modificação direta não é suportada.

• Restrição: A porta para o grupo de servidores padrão só pode ser definida ao criar o listener, e todos os servidores de backend sob o mesmo listener devem usar a mesma porta.

• Solução: Para configure portas de backend diferentes para o mesmo listener, use um grupo de servidores vServer.

O listener de Camada 4 do CLB suporta o uso da mesma instância ecs como servidor de backend e cliente?

Não. Essa configuração causa um loop.

Alternativas:

• Use um listener de Camada 7 do CLB (http/HTTPS).

• Use uma instância NLB e desative a preservação de ip do cliente para o grupo de servidores. Consulte How can an ECS instance serve as both a backend server and a client in NLB?

Por que meu backend do CLB tem muitas conexões TIME-WAIT, enquanto o ALB tem poucas?

O Classic Load Balancer (CLB) e o Application Load Balancer (ALB) usam mecanismos de conexão diferentes ao interagir com servidores de backend.

• Classic Load Balancer (CLB): Usa conexões http de curta duração por padrão. O CLB insere o cabeçalho Connection: close nas requisições http. Após processar a requisição, o servidor de backend envia um pacote FIN para fechar a conexão com base neste cabeçalho. Cada fechamento entra no estado TIME-WAIT (padrão de 60 segundos), levando a um acúmulo rápido sob alta concorrência.

• Application Load Balancer (ALB): Suporta conexões persistentes http (keep-alive) por padrão. Uma única conexão TCP lida com múltiplas requisições, reduzindo os fechamentos de conexão e, consequentemente, as conexões TIME-WAIT.

Para reduzir o acúmulo de TIME-WAIT, considere estas opções:

• Mude para um listener de Camada 4 (TCP) do CLB. As verificações de integridade de Camada 4 enviam um pacote RST após um handshake bem-sucedido para fechar a conexão sem entrar em TIME-WAIT.

• Migre para o ALB para aproveitar seu mecanismo padrão de reutilização de conexões persistentes http.

Por que o tráfego está distribuído de forma desigual entre os servidores de backend?

Causa comum	Descrição	Solução de problemas e solução
Persistência de sessão	Com a persistência de sessão ativada, as requisições do mesmo cliente sempre vão para o mesmo servidor de backend. Com poucos clientes (por exemplo, durante testes de estresse com clientes limitados), o tráfego se concentra em servidores específicos.	Verifique se a persistência de sessão está ativada e avalie se seu service realmente a exige.
Conexões persistentes	As conexões persistentes estabelecidas não são redistribuídas quando os pesos mudam. Em cenários de conexão persistente, o tráfego muda lentamente após ajustes de peso.	Realize dimensionamento ou ajustes de peso fora dos horários de pico e aguarde o fechamento natural das conexões antigas. Garanta configurações consistentes de TCP Keepalive nos servidores de backend para evitar acúmulo de conexões em alguns servidores.
Falhas ou flutuações na verificação de integridade	Alguns servidores de backend falham nas verificações de integridade e não conseguem aceitar requisições, ou seu status de integridade flutua entre íntegro e não íntegro, causando distribuição instável de tráfego.	Revise os logs de verificação de integridade para identificar flutuações de status. Aumente ligeiramente o intervalo de verificação de integridade e o limiar de não integridade para reduzir falsos positivos. Verifique se a configuração do código de resposta da verificação de integridade está correta.
Baixo volume total de requisições	Verifique as métricas de monitoramento do CLB. Pequenos desequilíbrios são normais quando o volume total de requisições é baixo.	Observe a distribuição de tráfego após aumentar o volume de requisições. Se o desequilíbrio persistir sob alta carga, investigue outras causas.
Configuração de peso inadequada	Os pesos dos servidores não correspondem à capacidade real de processamento, fazendo com que alguns servidores fiquem sobrecarregados enquanto outros permanecem ociosos.	Confirme se você está usando um algoritmo de agendamento ponderado (round-robin ignora pesos). Defina os pesos de acordo com a capacidade real de processamento de cada servidor de backend.
Algoritmo de agendamento Consistent Hashing (CH)	Quando um listener usa o algoritmo de agendamento consistent hashing (CH) baseado em ip de source, as requisições do mesmo ip de source são sempre encaminhadas para o mesmo servidor de backend. Quando o número de clientes é pequeno ou os IPs de source estão concentrados, alguns servidores de backend podem não receber tráfego. O CH é adequado para cenários que exigem afinidade de sessão com IPs de cliente distribuídos uniformemente. Quando os IPs de source estão concentrados, considere mudar para um algoritmo de agendamento diferente.	Faça login no console do CLB, acesse a página de detalhes da instância, clique em na aba Listener, clique em no listener alvo para visualize seus detalhes e verifique se o Scheduling Algorithm está definido como Consistent Hashing (CH). Se estiver, considere mudar para Weighted Round Robin (WRR) ou Round Robin (RR) para melhorar a distribuição de tráfego.

Como removo com segurança uma instância ecs de backend do CLB?

Remover uma instância ecs diretamente pode causar desconexões transitórias. Primeiro, defina o peso da instância ecs como 0. Aguarde a conclusão das conexões existentes antes de remover a instância. Para detalhes sobre o comportamento do peso quando definido como 0, consulte a seção Configuração de peso acima.

Se as requisições de negócios continuarem após a remoção da instância ecs, verifique o seguinte:

• Se a instância ecs também está vinculada a outras instâncias CLB.

• Se a instância ecs fornece outros serviços diretamente. Use o comando netstat para verificar o status de escuta da porta.

Por que nenhum tráfego é encaminhado para um servidor de backend recém-adicionado?

Se o CLB não encaminhar tráfego para um servidor de backend recém-adicionado, verifique o seguinte:

• Falha na verificação de integridade: A porta do servidor de backend está inacessível ou a aplicação não está escutando na porta esperada, causando falha na verificação de integridade. No console do CLB, confirme o status de verificação de integridade do servidor e verifique a escuta da porta e o status da aplicação no servidor de backend. Se as verificações de integridade falharem, consulte How do I troubleshoot health check failures?

• Peso definido como 0: Servidores com peso 0 não recebem novo tráfego de requisições. Verifique o peso do servidor no grupo de servidores e garanta que seja maior que 0. Para detalhes, consulte a seção Configuração de peso acima.

• Adicionado ao grupo de servidores errado: Cada listener do CLB é vinculado a um grupo de servidores específico (padrão ou vServer). Se o novo servidor for adicionado a um grupo não vinculado ao listener alvo, ele não receberá tráfego para esse listener. Confirme o grupo de servidores realmente vinculado ao listener e adicione o servidor ao grupo correto.

• iptables ou software de segurança de terceiros bloqueia o bloco CIDR de verificação de integridade: As verificações de integridade do CLB usam o bloco CIDR 100.64.0.0/10. Se o iptables ou outro software de segurança de terceiros no servidor de backend bloquear este bloco CIDR, as verificações de integridade falharão e o CLB tratará o servidor como não íntegro. Garanta que as regras relevantes não bloqueiem este bloco CIDR.

• Janela de verificação de integridade não atingida: Após adicionar um servidor de backend, o CLB aguarda uma verificação de integridade bem-sucedida antes de encaminhar tráfego. Aguarde brevemente e verifique se o tráfego flui normalmente.

• O algoritmo de agendamento Consistent Hashing (CH) impede a alocação de tráfego: Quando um listener usa o algoritmo de agendamento consistent hashing (CH) baseado em ip de source, as requisições são atribuídas a servidores específicos com base no resultado do hash do ip de source. Após adicionar um novo servidor, apenas as requisições cujo hash do ip de source mapeia para o novo servidor são encaminhadas para ele. Se o número de clientes for pequeno ou os IPs de source estiverem concentrados, o novo servidor pode não receber tráfego por um longo período. No console do CLB, acesse a página de detalhes da instância, clique em na aba Listener e verifique o algoritmo de agendamento para o listener correspondente. Se estiver definido como Consistent Hashing (CH), considere mudar para Weighted Round Robin (WRR) ou Round Robin (RR).

Qual protocolo o CLB usa para encaminhar requisições aos servidores de backend para listeners de Camada 7?

Independentemente de o listener de Camada 7 usar http ou HTTPS, o CLB sempre encaminha requisições aos servidores de backend usando o protocolo http. O mapeamento de versão http é o seguinte:

• Se a requisição do cliente usar http/1.1 ou http/2.0, o listener de Camada 7 acessa os servidores de backend usando http/1.1.

• Se a requisição do cliente usar uma versão diferente de http/1.1 ou http/2.0, o listener de Camada 7 acessa os servidores de backend usando http/1.0.