Sobre balanceadores de carga de aplicativos

Use o IBM Cloud® Application Load Balancer for VPC (ALB) para distribuir o tráfego entre várias instâncias do servidor dentro da mesma região de seu VPC.

Se você tiver cargas de trabalho públicas e privadas e o tráfego da camada 7, use um balanceador de carga de aplicativo

Tipos de balanceadores de carga do aplicativo

Conforme discutido na Visão geral dos balanceadores de carga para VPC, é possível criar um ALB público ou privado

Esta tabela apresenta uma comparação entre recursos públicos e privados.

Comparação de balanceadores de carga públicos e privados
Recursos Balanceador de carga público Balanceador de carga privado
Acessível na internet? Sim, com um nome completo do domínio (FQDN) Não, somente clientes internos, na mesma região e VPC
Aceita todo o tráfego? True Sim
(A restrição de aceitar tráfego apenas do espaço de endereços RFC-1918 foi removida.)
Como o nome de domínio é registrado? Endereços IP públicos Endereços IP privados

Balanceador de carga do aplicativo público

A uma instância pública de balanceador de carga de aplicativos é atribuído um nome de domínio totalmente qualificado (FQDN) acessível ao público, que você deve usar para acessar seus aplicativos hospedados por trás do balanceador de carga. Este nome de domínio pode ser registrado com um ou mais endereços IP públicos.

Ao longo do tempo, o número e o valor desses endereços IP públicos podem mudar devido às atividades de manutenção e ajuste de escala. As instâncias de servidor virtual de back-end que hospedam seu aplicativo devem ser executadas na mesma região e na mesma VPC.

Use o FQDN designado para enviar tráfego para o balanceador de carga do aplicativo público para evitar problemas de conectividade em seus aplicativos durante as atividades de manutenção do sistema ou de redução de escala.

Balanceador de carga do aplicativo privado

Um balanceador de carga de aplicativo privado é acessível por meio de suas sub-redes privadas que você configurou para criar o balanceador de carga.

Semelhante a um balanceador de carga de aplicativos público, um FDQN é atribuído à sua instância de balanceador de carga de aplicativos privado. Entretanto, esse nome de domínio é registrado com um ou mais endereços IP privados.

As operações do IBM Cloud podem mudar o número e o valor de seus endereços IP privados designados ao longo do tempo, com base nas atividades de manutenção e ajuste de escala. As instâncias de servidor virtual de back-end que hospedam seu aplicativo devem ser executadas na mesma região e na mesma VPC.

Use o FQDN designado para enviar tráfego para o balanceador de carga do aplicativo privado para evitar problemas de conectividade em seus aplicativos durante as atividades de manutenção do sistema ou de redução de escala.

Métodos de balanceamento de carga

Três métodos de balanceamento de carga estão disponíveis para distribuir o tráfego entre os servidores de aplicativos back-end:

Round-robin

Round-robin é o método de balanceamento de carga padrão. Com esse método, um balanceador de carga do aplicativo encaminha conexões do cliente recebidas no modo round-robin para os servidores de back-end. Como resultado, todos os servidores de back-end recebem praticamente um número igual de conexões do cliente.

Round-robin ponderado

Com esse método, um balanceador de carga de aplicativos encaminha as conexões recebidas dos clientes para os servidores de back-end proporcionalmente ao peso atribuído a esses servidores. Um peso padrão de 50 é atribuído a cada servidor. O peso pode ser personalizado para qualquer valor dentro do intervalo 0- 100.

Por exemplo, se os servidores de aplicativos A, B e C tiverem os pesos 60, 60 e 30, os servidores A e B receberão um número igual de conexões, enquanto o servidor C receberá metade desse número de conexões.

A configuração de um peso do servidor como 0 significa que nenhuma nova conexão é encaminhada para esse servidor, mas qualquer tráfego existente continua a fluir. O uso de um peso de 0 pode ajudar a tornar inativo um servidor de forma harmoniosa e removê-lo da rotação de serviço.

Os valores de ponderação do servidor são aplicáveis somente com o método round-robin ponderado. Eles são ignorados com os métodos de balanceamento de carga de round-robin e de conexões mínimas.

Menos conexões

Com esse método, a instância do servidor back-end que estiver atendendo ao menor número de conexões em um determinado momento recebe a próxima conexão do cliente.

Listeners de front-end e conjuntos de back-end

Os listeners de front-end são portas de aplicativo do balanceador de carga para recebimento de solicitações, enquanto os conjuntos de back-end são os servidores de aplicativos por trás dos balanceadores de carga.

Orientações para usar listeners

Revise as diretrizes a seguir para listeners de front-end:

  • É possível definir até 10 ouvintes de front-end e mapeá-los para pools de back-end nos servidores de aplicativos de back-end.
  • O FQDN designado para o seu balanceador de carga e as portas do listener de front-end são expostos à Internet pública. As solicitações recebidas de usuário são recebidas nessas portas.
  • Os protocolos de conjunto de back-ends e de listener de front-end suportados são HTTP, HTTPS e TCP.
  • É possível configurar um listener de front-end HTTP/HTTPS com um conjunto de back-end HTTP/HTTPS.
  • HTTP/2 é compatível apenas para ouvintes.
  • Os listeners e conjuntos HTTP e HTTPS são intercambiáveis.
  • É possível configurar apenas um ouvinte de front-end do tipo “ TCP ” com um pool de back-end do tipo “ TCP ”.
  • É possível anexar até 50 instâncias de servidor virtual a um conjunto de back-end. O tráfego é enviado para cada instância em sua porta de dados especificada. Esta porta de dados não precisa ser a mesma que a porta do listener de front-end.
  • Os endpoints “somente privados” para Secrets Manager não são compatíveis com os ouvintes HTTPS. Para configurar um listener HTTPS em um ALB, deve-se fazer upload dos certificados TLS para um terminal "Público e privado".

Listener de redirecionamento HTTPS

Os listeners de redirecionamento HTTPS redirecionam o tráfego de um listener HTTP para um listener HTTPS. Essa ação não requer a aplicação de nenhuma regra no ouvinte.

Por exemplo, se um serviço estiver escutando na porta 443 com HTTPS e um usuário tentar acessar o serviço na porta 80 usando HTTP, a solicitação será redirecionada automaticamente para a porta 443 com HTTPS.

Se as políticas estão presentes no listener de redirecionamento HTTPS, as políticas são avaliadas primeiro. Se não houver nenhuma política correspondente, a solicitação será redirecionada para um ouvinte HTTPS configurado.

Propriedades do listener de redirecionamento HTTPS

Propriedades do listener de redirecionamento HTTPS
Propriedade Descrição
Listener do O listener HTTPS ao qual uma solicitação é redirecionada.
Código de status HTTP O código de status da resposta retornada pelo balanceador de carga do aplicativo. Os valores aceitáveis são: 301, 302, 303, 307 ou 308.
URI A URI relativa para a qual uma solicitação é redirecionada. Esta parte é opcional.

Políticas à prova de falhas do pool de back-end

Ao editar um pool de back-end em um balanceador de carga, você pode especificar uma das seguintes ações de política à prova de falhas:

  • Encaminhar: O balanceador de carga encaminha as solicitações para um pool de backup designado. Isso fornece um caminho de failover limpo para outro conjunto de servidores de aplicativos. Você deve ter um pool de backup existente configurado e pronto para receber tráfego.
  • Drop: o balanceador de carga descarta todas as solicitações recebidas, e o cliente não recebe resposta.
  • Falha: O balanceador de carga rejeita solicitações com um código de status HTTP 503 ("Serviço indisponível"), informando ao cliente que o serviço está temporariamente fora do ar.

Você pode escolher um destino à prova de falhas em uma lista de pools de backup aplicáveis.

Requisitos do pool de destino à prova de falhas (se a ação for Encaminhar):

  • devem pertencer ao mesmo balanceador de carga
  • devem ter o mesmo protocolo ou um protocolo compatível ( TCP é compatível apenas com TCP, mas qualquer combinação de HTTP e HTTPS é compatível)

Somente os balanceadores de carga de aplicativos permitem que você associe mais de um pool a um único ouvinte. Certifique-se de que haja pelo menos um pool já existente no balanceador de carga.

Em uma configuração de balanceador de carga, um ouvinte é considerado o recurso principal. Você pode associar pools a esse ouvinte de duas maneiras: fazendo referência a eles direta ou indiretamente. Para associação direta, configure o pool como o ouvinte default_pool. Para associação indireta, faça referência ao pool de outro pool por meio de um relacionamento failsafe_policy.target, garantindo que o outro pool já esteja vinculado ao ouvinte.

Elasticidade

O balanceador de carga do aplicativo amplia a escala ao incluir recursos de cálculo quando a carga aumenta.

Transferência de SSL e autorizações necessárias

O descarregamento de Secure Sockets Layer ( SSL ) permite que o balanceador de carga de aplicativos termine todas as conexões HTTPS recebidas.

Quando um listener HTTPS é configurado com um conjunto HTTP, a solicitação de HTTPS é finalizada no front-end e o balanceador de carga estabelece uma comunicação HTTP de texto sem formatação com a instância do servidor de back-end. Com essa técnica, os handshakes SSL com uso intensivo de CPU e as tarefas de criptografia ou decriptografia são deslocados das instâncias do servidor de back-end, permitindo que eles usem todos os seus ciclos de CPU para processar o tráfego de aplicativos.

A transferência SSL requer que você forneça um certificado SSL para o balanceador de carga do aplicativo para executar tarefas de transferência SSL. É possível gerenciar os certificados SSL por meio do IBM Cloud Secrets Manager.

Você pode criar uma autorização por meio das Autorizações do IAM. Certifique-se de escolher Serviços de infraestrutura VPC como o serviço de origem e selecione Recursos específicos. Clique Selecione um atributo e escolha Tipo de recurso da lista. Selecione “Load Balancer para VPC ” como tipo de recurso e clique em “Avançar ”. Para o serviço de destino, selecione Secrets Manager. Defina o acesso à instância do serviço de destino como “Todas as instâncias” ou como sua instância específica do IBM Cloud Secrets Manager. Designe a função de acesso de serviço Gravador. Para obter mais informações, consulte Concedendo acesso entre serviços.

Para evitar erros, deve-se estabelecer a autorização necessária entre o seu balanceador de carga e o IBM Cloud Secrets Manager. Além disso, a atualização de certificados em Secrets Manager não atualiza automaticamente seu ALB. Para que seu balanceador de carga reflita quaisquer mudanças no certificado, faça uma pequena atualização (como a mudança do intervalo de verificação de funcionamento ou do valor de tempo limite) para causar uma atualização. Esta ação atualiza o certificado no seu balanceador de carga para corresponder ao certificado em Secrets Manager. Em seguida, é possível reverter quaisquer mudanças feitas de volta para seus valores originais.

O Transport Layer Security (TLS) 1.2 e o 1.3 são suportados. No entanto, TLS 1.3 é usado por padrão, a menos que você configure especificamente o lado do cliente para usar 1.2. Os balanceadores de carga de aplicativos aceitam todas as cifras TLS 1.3 compatíveis que são enviadas pela solicitação do lado do cliente.

A seguir são listadas as cifras suportadas (em ordem de precedência):

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Localizando o certificado CRN

Ao configurar a autenticação para um balanceador de carga de aplicativos durante o provisionamento no console, você pode optar por especificar o certificado Secrets Manager e SSL ou o CRN do certificado. Talvez seja recomendável fazer isso caso você não consiga visualizar o “ Secrets Manager ” no menu suspenso, o que significa que você não tem acesso à instância “ Secrets Manager ”. Lembre-se de que você deve inserir o CRN se estiver usando a API para criar um ALB.

Para obter o CRN, é necessário ter permissão para acessar a instância do Secrets Manager.

Para localizar o CRN de um certificado, siga estas etapas:

  1. No console do IBM Cloud, acesse o ícone do menu de navegação ícone do menu de navegação > Lista de recursos.
  2. Clique para expandir “ Segurança ” e, em seguida, selecione o “ Secrets Manager ” cujo CRN você deseja encontrar.
  3. Selecione em qualquer lugar na linha da tabela do certificado para abrir o painel lateral Detalhes do certificado. O CRN do certificado está listado.

Criptografia SSL de ponta a ponta

A configuração de um listener HTTPS com um conjunto HTTPS permite a criptografia SSL de ponta a ponta. O ALB encerra a solicitação de tipo “ HTTPS ” recebida no ouvinte do front-end e estabelece uma conexão do tipo “ HTTPS ” com as instâncias do back-end. A criptografia de ponta a ponta permite que todo o tráfego que passa pelo balanceador de carga com destino aos membros do back-end seja criptografado por meio de HTTPS.

Para configurar a criptografia SSL de ponta a ponta:

  1. Configure um ouvinte de front-end do HTTPS com seu certificado SSL, da mesma forma que faria ao configurar o offloading do SSL.
  2. Configure um conjunto de back-end HTTPS.
  3. Inclua sua instância do membro de back-end no conjunto de back-end HTTPS. Certifique-se de que as instâncias dos membros do back-end estejam configuradas para lidar com o tráfego do HTTPS.
  4. Configure a verificação de funcionamento com o tipo HTTPS para executar verificações de funcionamento criptografadas com seus membros de back-end.

Um balanceador de carga do aplicativo não verifica os certificados SSL das instâncias do membro de back-end.

Escala horizontal

Um balanceador de carga do aplicativo ajusta sua capacidade automaticamente de acordo com a carga. Quando esse ajuste ocorrer, será possível ver uma mudança no número de endereços IP associados ao nome de DNS do balanceador de carga.

Suporte do MZR

O IBM Cloud Application Load Balancer for VPC suporta Regiões Multizona (MZRs). É possível obter alta disponibilidade e redundância ao implementar um balanceador de carga do aplicativo com sub-redes de diferentes zonas. Quando as sub-redes de diversas zonas são usadas para provisionar um balanceador de carga do aplicativo, os dispositivos de balanceador de carga são implementados em diversas zonas.

Integração com grupos de instâncias

O IBM Cloud Application Load Balancer for VPC se integra com grupos de instâncias, que podem auto scale seus membros de back-end. Os membros do conjunto são incluídos e excluídos dinamicamente com base em seu uso e requisitos.

Encaminhamento de log do caminho de dados

Quando o registro de logs do caminho de dados está ativado, os logs do balanceador de carga são encaminhados para o IBM Cloud Logs serviço, onde você pode visualizar seus logs de caminho de dados.

HTTP2 suporte

Os balanceadores de carga de aplicativos suportam o tráfego HTTP2 de ponta a ponta e trabalham com protocolos de ouvinte definidos como HTTPS ou TCP.

WebSocket

WebSocket fornece canais de comunicação full-duplex em uma única conexão TCP. Os balanceadores de carga de aplicativos suportam WebSocket com todos os tipos de protocolo de ouvinte ( HTTP / HTTPS / TCP ).

Alta disponibilidade e balanceadores de carga de aplicativos

Para garantir que a alta disponibilidade (HA) funcione com seu ALB, conecte três sub-redes de zonas diferentes ao ALB e implante dispositivos nessas zonas. Para isso, primeiro você seleciona suas sub-redes durante o processo de criação do ALB. Você pode selecionar duas sub-redes em zonas diferentes (como us-south-1 e us-south-2). Isso cria os endereços IP do ALB (como os IPs do dispositivo) em duas sub-redes diferentes.

Você também pode fazer isso com ALBs já existentes. Vá para a seção Attached Resources (Recursos anexados ) na página de detalhes do balanceador de carga. Na seção Subnet, clique em Edit subnets (Editar sub-redes). Em seguida, conecte mais sub-redes. O ALB entra no estado "Migrando". Quando a migração for concluída, você receberá um novo IP para o dispositivo da sub-rede que acabou de anexar. Agora você tem dois endereços IP de sub-redes diferentes em zonas diferentes.