Server Load Balancer:Add an HTTP listener

Etapa 1: Configurar o listener

1. Faça login no console do CLB.

2. Selecione a região da instância.

3. Use um dos métodos a seguir para abrir o assistente de configuração de listener:

   • Na página Instances, localize a instância desejada e clique em Configure Listener na coluna Actions.

   • Na página Instances, clique no ID da instância desejada. Em seguida, na aba Listener, clique em Add Listener.

4. No assistente Protocol & Listener, preencha as configurações abaixo e clique em Next.

   Parâmetro	Descrição
   Select Listener Protocol	Selecione um protocolo de listener. Neste exemplo, selecione HTTP. Instâncias de CLB na região do México não suportam listeners HTTP. Utilize um Application Load Balancer ou uma instância de CLB em outra região.
   Backend Protocol	Quando HTTP é selecionado como protocolo do listener, o Backend Protocol é definido automaticamente como HTTP.
   Listener Port	Porta que recebe e encaminha solicitações aos servidores de back-end. Valores válidos: 1 a 65535. Porta HTTP padrão: 80.
   Tags	Selecione ou insira uma Tag Key e um Tag Value.
   Advanced Settings	Clique em Modify para expandir as configurações avançadas.
   Scheduling Algorithm	Escolha um algoritmo de agendamento. O padrão é Round Robin. Weighted Round-robin: Servidores de back-end com pesos maiores recebem mais solicitações. Round Robin: As solicitações são distribuídas sequencialmente entre os servidores de back-end. Para detalhes sobre algoritmos de agendamento e casos de uso, consulte Scheduling algorithms.
   Redirection by Listener	Quando ativado, o CLB redireciona solicitações HTTP para um listener HTTPS especificado retornando um código de status 302. Para o processo completo, consulte Redirect HTTP requests to HTTPS by using a CLB instance. Antes de ativar o redirecionamento, crie o listener HTTPS de destino e configure seu certificado. Não é possível ativar o redirecionamento em um listener HTTP existente. Exclua o listener atual e crie um novo.
   Session Persistence	A persistência de sessão vem desativada por padrão. Quando ativada, o CLB direciona solicitações do mesmo cliente para o mesmo servidor de back-end usando cookies. Cookie Option: Insert Cookie: Especifique apenas o tempo limite do cookie. Na primeira solicitação, o CLB insere um cookie (ServerId) na resposta. Solicitações subsequentes contendo esse cookie são encaminhadas ao mesmo servidor de back-end. Session Persistence Timeout Period: Se você selecionar Insert Cookie, insira um período de tempo limite para a persistência de sessão. Rewrite Cookie: Especifique um cookie personalizado para inserir na resposta. Gerencie a expiração e o ciclo de vida desse cookie nos seus servidores de back-end. O CLB substitui o cookie original pelo personalizado. Solicitações subsequentes com o novo cookie são encaminhadas ao mesmo servidor de back-end. Cookie Name: Se você selecionar Rewrite Cookie, insira um nome para o cookie.
   Access Control	O controle de acesso vem desativado por padrão. Quando ativado, selecione um método de controle de acesso e uma lista de controle de acesso (ACL) como lista de permissões ou lista de bloqueios para o listener. Whitelist: allows only trusted IP addresses to access SLB.. Apenas solicitações originadas de endereços IP ou blocos CIDR presentes na ACL selecionada são encaminhadas. Listas de permissões envolvem riscos: após a configuração, somente os endereços IP listados poderão acessar o listener. Se uma lista de permissões estiver ativada, mas a ACL estiver vazia, o listener encaminhará todas as solicitações. Blacklist: denies access from specified IP addresses to SLB.. Solicitações provenientes de endereços IP ou blocos CIDR presentes na ACL selecionada são bloqueadas. Se uma lista de bloqueios estiver ativada, mas a ACL estiver vazia, o listener encaminhará todas as solicitações. Nota Instâncias IPv6 suportam apenas ACLs IPv6, e instâncias IPv4 suportam apenas ACLs IPv4. Crie uma ACL.
   Bandwidth Throttling for Listeners	Para instâncias de CLB com pagamento por largura de banda, defina uma largura de banda máxima por listener para limitar o tráfego. A soma das larguras de banda de todos os listeners não pode exceder o total da instância. Desativado por padrão. Todos os listeners compartilham a largura de banda da instância. Consulte CLB listeners share the bandwidth of an instance. Importante Se uma instância de CLB voltada para a internet tiver uma largura de banda total de 5 Mbps e você alocar todos os 5 Mbps para o listener A e 0 Mbps para o listener B, o listener B ficará inacessível. Aloque a largura de banda de cada listener com cuidado. Se uma instância de CLB interna tiver três listeners e você alocar um total de 5.120 Mbps para os listeners A e B, o listener C restante ficará inacessível. Aloque a largura de banda de cada listener com cuidado. Instâncias com pagamento por transferência de dados não possuem largura de banda máxima padrão.
   Idle Connection Timeout Period	Tempo limite para conexões ociosas. Valores válidos: 1 a 60 segundos. Padrão: 15 segundos. Se nenhum dado for transferido dentro do período de tempo limite, o CLB fecha a conexão. Uma nova conexão é estabelecida na próxima solicitação. Nota O tempo limite máximo de ociosidade para listeners de camada 7 (HTTP/HTTPS) do CLB é de 60 segundos e não pode ser aumentado. Se sua carga de trabalho exigir um tempo limite de ociosidade maior, use um listener TCP de camada 4 (até 900 segundos) ou Application Load Balancer (ALB, tempo limite de ociosidade de até 3.600 segundos). A configuração de tempo limite de conexão aplica-se a todo o listener. Para definir um tempo limite diferente para um servidor de back-end específico, configure o servidor com um listener separado e defina o tempo limite nesse listener.
   Connection Request Timeout	Se um servidor de back-end não responder dentro deste período, o CLB retorna um erro HTTP 504 ao cliente. Valores válidos: 1 a 180 segundos. Padrão: 60 segundos. Nota O tempo limite máximo de solicitação para listeners de camada 7 (HTTP/HTTPS) do CLB é de 180 segundos e não pode ser aumentado. Para tempos limite de solicitação maiores, use Application Load Balancer (ALB, tempo limite de solicitação de até 3.600 segundos).
   GZIP Compression	Comprime tipos de arquivo específicos. Ativado por padrão. O Gzip suporta os seguintes tipos de arquivo: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml e application/xml.
   Custom HTTP Header	Selecione cabeçalhos HTTP personalizados para adicionar: Adicione o cabeçalho X-Forwarded-For para obter o endereço IP real do cliente. Nota Listeners de camada 7 do CLB usam X-Forwarded-For por padrão para obter endereços IP de clientes. Isso não pode ser desativado. Se o cabeçalho contiver vários endereços IP, o primeiro será o IP real do cliente. Retrieve client IP addresses over a Layer 7 listener. Adicione o cabeçalho SLB-ID para obter o ID da instância de CLB. Adicione o cabeçalho SLB-IP para obter o endereço IP da instância de CLB. Adicione o cabeçalho X-Forwarded-Proto para obter o protocolo do listener da instância de CLB.
   Obtain Client Source IP Address	Obtém os endereços IP reais dos visitantes. Ativado por padrão.
   Automatically Enable Listener	Define se o listener deve ser iniciado após a criação. Ativado por padrão.

Etapa 2: Adicionar servidores de back-end

Adicione servidores de back-end para processar as solicitações. Use o grupo de servidores padrão ou crie um grupo de vServer. Consulte Grupos de servidores. Este exemplo utiliza o grupo de servidores padrão.

1. Na etapa Backend Servers, selecione Default Server Group e clique em Add More.

2. Na etapa Servers, selecione os servidores de back-end que deseja adicionar e clique em Next.

3. Na etapa Ports/Weights, defina o peso e clique em Add.

   Nota

   • O peso padrão é 100. Servidores de back-end com pesos maiores recebem mais solicitações.

   • Um servidor com peso 0 não recebe novas solicitações.

4. Especifique a porta que cada servidor de back-end (instância ECS) usará para receber solicitações e clique em Next. Valores válidos: 1 a 65535.

   Nota

   Vários servidores de back-end na mesma instância de CLB podem usar a mesma porta.

Etapa 3: Configurar verificações de integridade

O CLB usa verificações de integridade para determinar a disponibilidade dos servidores de back-end, melhorando a confiabilidade geral do service.

1. Opcional: Na etapa Health Check, clique em Modify para alterar as configurações e clique em Next. Configure e gerencie verificações de integridade do CLB.

2. Na etapa Confirm, revise a configuração do listener. Clique em Modify caso precise alterar alguma configuração.

3. Confirme a configuração e clique em Submit. Após a criação do listener, clique em OK.

   O novo listener aparece na página.

Cabeçalhos de resposta removidos por listeners de camada 7

Para oferecer suporte à persistência de sessão, o CLB modifica cabeçalhos de resposta como Date, Server, X-Pad e X-Accel-Redirect provenientes dos servidores de back-end.

Alternativas:

• Adicione prefixos aos cabeçalhos de resposta personalizados (por exemplo, xl-server, xl-date) para evitar que o CLB os processe.

• Mude de um listener HTTP de camada 7 para um listener tcp de camada 4.

O cabeçalho Transfer-Encoding: chunked nas respostas

Sintoma:

Após mapear um nome de domínio para um balanceador de carga de camada 7, o cabeçalho "Transfer-Encoding: chunked" aparece nas respostas HTTP quando acessadas de uma máquina local. Esse cabeçalho está ausente quando o servidor de back-end é acessado diretamente.

Causa:

O balanceamento de carga de camada 7 usa o proxy reverso Tengine, que aplica codificação de transferência fragmentada (chunked) ao corpo da resposta.

Suporte a WebSocket em listeners do CLB

Os listeners HTTP do CLB suportam WebSocket por padrão. Use CLB to enable real-time messaging with WebSocket.

Como configuro o CLB para permitir apenas nomes de domínio específicos ou bloquear acesso direto por IP?

Os listeners HTTP/HTTPS (camada 7) do CLB suportam regras de encaminhamento baseadas em domínio e url, mas o CLB não fornece um recurso nativo de lista de permissões ou bloqueios de domínios. É possível implementar indiretamente o controle de acesso no nível de domínio combinando regras de encaminhamento com grupos de vServer. Note que isso é controle de acesso, não proteção de segurança. Para defesa contra ataques como CC e injeção de SQL, utilize o Web Application Firewall (WAF).

Bloquear domínios não correspondentes ou acesso direto por IP (política de fallback)

1. Crie um grupo de vServer vazio, sem servidores de back-end adicionados.

2. Defina o destino de encaminhamento padrão do listener (o grupo de servidores que recebe tráfego quando nenhuma regra de encaminhamento corresponde) como esse grupo de vServer vazio.

3. Configure regras de encaminhamento baseadas em domínio que direcionem o tráfego correspondente aos seus domínios-alvo para o grupo de vServer de back-end real.

Com essa configuração, as solicitações que correspondem a uma regra de encaminhamento são roteadas para o grupo de vServer de back-end correspondente, enquanto as solicitações que não correspondem a nenhuma regra — incluindo acesso direto por IP e solicitações de domínios não reconhecidos — caem no grupo de vServer vazio definido como destino de encaminhamento padrão e não conseguem alcançar um back-end, pois nenhum servidor de back-end está disponível.

Bloquear acesso de um domínio específico

Utilizando o grupo de vServer vazio criado no cenário anterior, crie uma regra de encaminhamento que direcione o domínio que você deseja bloquear para esse grupo de vServer vazio. As solicitações desse domínio serão então bloqueadas porque nenhum servidor de back-end estará disponível.