Balanceie o tráfego entre múltiplas origens
Distribua as requisições de uma aplicação entre vários endereços de origem com um connector com Load Balancer e uma regra do Rules Engine que o define.
Você pode distribuir as requisições de uma aplicação entre vários servidores de origem ao habilitar Load Balancer em um connector. Uma regra do Rules Engine então envia as requisições a esse connector, e Load Balancer as distribui entre os endereços dele com um algoritmo de balanceamento. Para conectar uma aplicação a uma única origem, consulte Conecte uma aplicação a uma origem.
Uma conta que não migrou para a API v4 configura o balanceamento de carga nas Origins legadas da aplicação. Para mais informações, consulte Origins.
Escolha a interface em que você trabalha. Os pré-requisitos e os procedimentos mudam conforme a sua escolha.
Pré-requisitos
- Uma aplicação servida por um workload. Para criar os dois, consulte Primeiros passos com Applications.
- Dois ou mais servidores de origem que guardam o mesmo conteúdo e estão configurados da mesma forma para a aplicação.
- Acesso ao Azion Console. Para entrar, consulte Acesse Azion Console.
Planeje os endereços
O exemplo desta página balanceia três servidores de origem. Cada um está hospedado em um provedor de armazenamento ou serviço de cloud diferente, porque quedas de servidor raramente ocorrem ao mesmo tempo. Os três guardam o mesmo conteúdo e estão configurados da mesma forma para a aplicação. Dois deles dividem o tráfego, e o terceiro fica de reserva para manutenção e picos de tráfego.
| Endereço | Servidor | Capacidade de carga | Peso | Função do servidor | Ativo |
|---|---|---|---|---|---|
example.com | Primário | Alta | 3 | primary | Sempre |
example.net | Secundário | Média, suficiente para grandes picos de tráfego | 2 | primary | Sempre |
example.org | Backup | Baixa | 1, o padrão quando o peso fica em branco | backup | Apenas durante uma manutenção ou um pico de tráfego |
O peso acompanha a capacidade de carga de cada servidor. Tanto example.com quanto example.net são primários, e o peso maior faz de example.com o endereço preferido para conexões. example.org fica inativo até que uma manutenção ou um pico precise dele. Para saber como o peso, a função do servidor e o estado ativo distribuem as requisições, consulte Load Balancer.
Crie um connector com Load Balancer
Load Balancer pertence ao connector, em attributes.modules na API. Um connector criado sem Load Balancer o mantém desabilitado até que você habilite o Load Balancer no connector. Este é o objeto attributes.modules de um connector HTTP que a API criou sem balanceamento de carga:
Para balancear os três endereços do exemplo com o algoritmo Round-Robin, o connector traz estes valores. Cada chave fica em attributes:
| Chave | Valor no exemplo |
|---|---|
type | http |
modules.load_balancer.enabled | true |
modules.load_balancer.config.method | round_robin |
modules.load_balancer.config.max_retries | 0 |
modules.load_balancer.config.connection_timeout | 60 |
modules.load_balancer.config.read_write_timeout | 120 |
addresses[].address | example.com, example.net e example.org |
addresses[].modules.load_balancer.weight | 3, 2 e 1 |
addresses[].modules.load_balancer.server_role | primary, primary e backup |
addresses[].active | true, true e false |
connection_options.transport_policy | preserve |
connection_options.host | ${host}, que encaminha o header Host da requisição do usuário |
No Azion Console, você configura connectors no menu Connectors, e não em uma aba da aplicação. Para cada campo, consulte Load Balancer e Configurações de connector.
Para criar o connector com a API, envie os valores da tabela em uma requisição POST para /v4/workspace/connectors. Copie o ID do connector, que a API retorna em data.id. A regra que envia as requisições ao connector o identifica por esse ID.
Envie as requisições ao connector
Um connector não recebe nenhuma requisição até que uma regra o defina. A regra desta seção é executada na fase de requisição da aplicação. O critério dela corresponde a todos os paths, com a variável ${uri}, o operador starts_with e / como argumento, então o connector serve a aplicação inteira. O behavior dela define o connector.
A variável ${uri} funciona em todas as aplicações. Um critério com ${request_uri} precisa de Application Accelerator ativado na aplicação. Para todas as variáveis e todos os operadores, consulte Rules Engine para Applications.
Para criar a regra com a API, envie uma requisição POST ao endpoint request_rules da aplicação. Substitua <application-id> pelo ID da sua aplicação e <connector-id> pelo ID do connector:
A API responde 202 e retorna a regra:
A regra é a primeira da fase de requisição da aplicação, com order 0.
Para o behavior e os atributos dele, consulte Set Connector.
Confirme que a aplicação responde
A regra leva alguns minutos para se propagar. Até lá, a aplicação responde como respondia antes de a regra existir.
Para confirmar a rota, envie uma requisição ao domínio do seu workload, com esse domínio no lugar de <your-workload-domain>:
A resposta vem de um dos endereços ativos do connector. O domínio de um workload termina em .map.azionedge.net, e a API o retorna em workload_domain quando cria o workload. Se a resposta ainda não vier dos seus servidores de origem, envie a requisição novamente até que venha. Se nunca vier, consulte Solucionar problemas de Applications.