Balanceamento de carga baseado em políticas
Os balanceadores de carga de aplicativos públicos e privados oferecem suporte ao balanceamento de carga das camadas 4 e 7, em que o tráfego de dados é distribuído com base em políticas e regras configuradas. Uma política define a ação a ser tomada, o que significa como o tráfego é distribuído, quando a solicitação recebida corresponde às regras que estão associadas à política.
Políticas da camada 7
É possível definir políticas para listeners HTTP e HTTPS. Para cada política, deve-se definir uma ou mais regras. A política é aplicada somente quando todas as suas regras são correspondidas.
É possível anexar mais de uma política a um listener. Em geral, uma política com a prioridade mais baixa é avaliada primeiro. Cada política deve ter uma prioridade diferente.
Se a solicitação recebida não corresponder às regras para qualquer política, a solicitação do sistema será redirecionada para o listener de redirecionamento HTTPS configurado, se presente. Caso contrário, o sistema redirecionará a solicitação para o conjunto padrão do listener. O redirecionamento HTTPS tem uma precedência maior sobre o conjunto padrão em um listener HTTP.
As ações a seguir são suportadas para uma política de camada 7:
- Rejeitar - A solicitação é negada com uma resposta 403.
- Redirecionar - A solicitação é redirecionada para uma URL configurada e um código de resposta.
- Encaminhar para o pool — A solicitação é enviada para um pool de back-end específico.
- Encaminhar para o ouvinte- A solicitação é enviada para um ouvinte de front-end específico.
- Redirecionamento HTTPS - A solicitação HTTP é redirecionada para um listener HTTPS.
Propriedades da política
| Propriedade | Descrição |
|---|---|
| Nome | O nome da política. O nome deve ser exclusivo dentro do listener. |
| Ação | A ação a ser tomada quando todas as regras de política são correspondidas. Os valores aceitáveis são reject, redirect, forward_to_pool, forward_to_listener e https_redirect. |
| Prioridade | As políticas são avaliadas com base na ordem crescente de prioridade. |
| Prioridade | As políticas são avaliadas com base na ordem crescente de prioridade. |
| URL | A URL para a qual a solicitação será redirecionada se a ação estiver configurada como redirect. Você deve fornecer um URL completo ou os parâmetros de um URI. Ao usar um URL, todo o tráfego de entrada é redirecionado para
esse URL. Ao usar parâmetros URI, os valores das solicitações de tráfego de entrada podem ser retidos usando os valores de entrada dos parâmetros. Os valores padrão dos parâmetros URI são iguais aos valores originais de entrada. Para
reter os valores recebidos, forneça-os como {protocol},{port},{host},{path}, e {query}. Por exemplo, se o host da solicitação recebida for ibm.com, o valor
padrão será {host} igual ao valor de ibm.com recebido. |
| Código de status HTTP | Código de status da resposta retornado pelo balanceador de carga do aplicativo quando a ação é configurada como redirect ou https_redirect. Os valores aceitáveis são: 301, 302, 303,
307 ou 308. |
| Target | Se a ação for definida como forward_to_pool, a solicitação será encaminhada para o pool de back-end de instâncias de servidores virtuais. Como alternativa, se a ação for definida como forward_to_listener, a solicitação
será encaminhada para um ouvinte front-end do mesmo ALB. |
| Listener do | O listener HTTPS para o qual a solicitação é redirecionada, se a ação for definida como https_redirect. |
| URI | A URI relativa para a qual a solicitação será redirecionada, se a ação for https_redirect. Esta parte é opcional. |
Regras da camada 7
Uma regra define como uma solicitação é identificada. Tanto o roteamento baseado em URI e o roteamento baseado em parâmetro são suportados. São suportados os cinco tipos de regras a seguir.
| Tipo | Descrição |
|---|---|
hostname |
A solicitação corresponde ao endereço hostname especificado, como, por exemplo, api.my_company.com. |
header |
A solicitação corresponde a um campo e valor do tipo “ HTTP ” header, como, por exemplo, Cookie: xxxx. |
path |
A solicitação corresponde à parte “ path ” na “ URL ” após “ hostname ”, como, por exemplo, /index.html. |
query |
A solicitação corresponde à string “ query ” na URL, por exemplo, x=y. A string query deve estar codificada em formato percentual e distingue maiúsculas de minúsculas. |
body |
A solicitação body para a solicitação POST está codificada no formato form-encoded. A solicitação corresponde ao corpo, por exemplo, key=value. É maiúsculas e minúsculas. |
sni_hostname |
O servidor fornecido na extensão “indicação do nome do servidor” durante a negociação d TLS a corresponde ao nome de host SNI especificado. |
Para corresponder a uma solicitação, uma instrução condition deve ser definida em uma regra. São suportadas as quatro condições a seguir.
| Condição | Tipo de avaliação |
|---|---|
contains |
Verifica se o valor extraído com base no type contém a sequência de caracteres especificada no value``. |
equals |
Verifica se o valor extraído com base no type é idêntico à string especificada no value``. |
matches_regex |
Compara o valor extraído com base no type com a expressão regular especificada no value``. |
starts_with |
Verifica se o valor extraído com base no type começa com a sequência de caracteres especificada em value``. |
Propriedades de regra
Esta tabela descreve as propriedades das regras de política da camada 7.
| Propriedade | Descrição |
|---|---|
type |
Especifica o tipo de regra. Os valores aceitáveis são hostname, header, path, query ou body. |
condition |
Especifica a condição utilizada para avaliar a regra. Os valores aceitos são contains, equals ou matches_regex. |
field |
Especifica o nome do campo. Esse campo é aplicável apenas aos tipos de regra header query e body e não suporta expressão regular e caracteres curinga. Por exemplo, para corresponder a um cookie no
cabeçalho de HTTP, o campo pode ser configurado como cookie. Quando o tipo de regra for query e body, este campo será opcional. Essa propriedade não se aplica ao tipo de regra sni_hostname. |
value |
A sequência a ser correspondida. Este campo não aceita caracteres curinga. As expressões regulares são suportadas quando a opção “ condition ” está definida como “ matches_regex ”. |
Notas:
- Se o tipo de regra for
header, os caracteres a seguir não serão permitidos parafieldevalue:"(),/:;<=>?@[\]{}'. - Se o tipo de regra for
body, os caracteres a seguir não serão permitidos parafieldevalue:"'=,()&e espaço. - Se o tipo de regra for
query,fieldevaluedeverão ser uma sequência codificada em porcentagem.
Exemplos: Criando políticas e regras
Os exemplos da camada 7 a seguir mostram como as políticas e as regras são criadas e associadas a um listener.
Exemplo 1: criar um listener HTTPS com políticas de redirecionamento
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners" \
-d '{
"certificate_instance": {
"crn": "crn:v1:bluemix:public:cloudcerts:us-south:a/1111111111111111111111111111:22222222-3333-4444-5555-666666666666:certificate:77777777777777777777777777777777"
},
"connection_limit": 2000,
"port": 443,
"protocol": "https",
"policies": [
{
"name": "hostname_header",
"action": "redirect",
"priority": 1,
"target": {
"url": "https://www.examples.com/",
"http_status_code": 307
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "hostname",
"value": "abc.com"
}
]
},
{
"name": "header_cookie",
"action": "redirect",
"priority": 5,
"target": {
"url": "https://www.mycookies.com/",
"http_status_code": 302
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "header",
"field": "cookie",
"value": "flavor=oatmeal"
}
]
},
{
"name": "path_hostname",
"action": "redirect",
"priority": 10,
"target": {
"url": "https://www.myexamples.com/",
"http_status_code": 301
},
"rules": [
{
"condition": "contains",
"type": "hostname",
"value": "abc"
},
{
"condition": "equals",
"value": "/test",
"type": "path"
}
]
},
{
"name": "uri_redirect",
"action": "redirect",
"priority": 10,
"target": {
"url": "https://{host}:8080/{path}?{query}",
"http_status_code": 301
},
"rules": [
{
"condition": "contains",
"type": "hostname",
"value": "pqr"
}
]
}
]
}'
Exemplo 2: criar políticas para encaminhar solicitações para conjuntos e associá-las a um listener existente
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners/$listenerId/policies" \
-d '{
"policies": [
{
"action": "forward",
"priority": 1,
"target": {
"id": "7df616da-4dd6-43d3-881d-801ae29e29fe"
},
"rules": [
{
"condition": "equals",
"type": "header",
"field": "cookie",
"value": "flavor=oatmeal"
}
]
},
{
"action": "forward",
"priority": 5,
"target": {
"id": "0738-8061c411-0d50-4c79-b475-102666796434"
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
}
]
},
{
"action": "forward",
"priority": 10,
"target": {
"id": "0738-62914e09-3928-4d89-b7f7-1bb7a6d7fe85"
},
"rules": [
{
"condition": "matches_regex",
"type": "hostname",
"value": "abc[a-z]*.com"
}
]
},
{
"action": "forward",
"priority": 6,
"target": {
"id": "0738-62914e09-3928-4d89-b7f7-1bb7a6d7fe85"
},
"rules": [
{
"condition": "equals",
"type": "path",
"value": "/test/testtest"
}
]
}
]
}'
Exemplo 3: Criar um listener HTTP com políticas de redirecionamento HTTPS
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners" \
-d '{
"connection_limit": 2000,
"port": 80,
"protocol": "http",
"policies": [
{
"name": "hostname_header",
"action": "https_redirect",
"priority": 1,
"target": {
"listener": {
"id": "0134-d578be10-31e3-46b3-8513-79babb852319"
},
"http_status_code": 307
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "hostname",
"value": "abc.com"
}
]
},
{
"name": "header_cookie",
"action": "https_redirect",
"priority": 2,
"target": {
"listener": {
"id": "0456-a578be10-31e3-46b3-8513-79babb852398"
},
"http_status_code": 302
},
"rules": [
{
"condition": "contains",
"type": "header",
"field": "aheader",
"value": "avalue"
},
{
"condition": "equals",
"type": "header",
"field": "cookie",
"value": "flavor=oatmeal"
}
]
},
{
"name": "path_hostname",
"action": "https_redirect",
"priority": 5,
"target": {
"listener": {
"id": "0386-d898be10-21e3-66b3-9513-69babb852390"
},
"http_status_code": 301,
"uri": "/test/sample"
},
"rules": [
{
"condition": "contains",
"type": "hostname",
"value": "abc"
},
{
"condition": "equals",
"value": "/test",
"type": "path"
}
]
}
]
}'
Políticas da camada 4
Você pode definir políticas para os ouvintes d TCP. Para cada política, deve-se definir uma ou mais regras. Semelhante às políticas da camada 7, uma política da camada 4 é aplicada com a prioridade mais baixa primeiro e somente quando todas as suas regras designadas forem correspondidas.
Se a solicitação recebida não corresponder às regras de nenhuma política, o cliente poderá receber um erro de " SSL ".
As seguintes ações são compatíveis com as políticas da camada 4:
- Encaminhar para o pool- A solicitação é enviada para um pool de back-end específico.
- Encaminhar para ouvinte- A solicitação é enviada para um ouvinte de front-end específico.
Regras da camada 4
Uma regra da camada 4 define como as solicitações são correspondidas, da mesma forma que uma regra da camada 7. No entanto, somente o tipo sni_hostname é compatível, onde field não é aplicável e as propriedades condition e value são as mesmas das regras da camada 7.
A regra "SNI Hostname" só funciona com um ouvinte do tipo " TCP ".
O SNI em um ALB IBM Cloud é anexado ao ouvinte e permite que você encaminhe o tráfego para diferentes pools de back-end com base no nome do host. Em um pool, o tráfego é sempre balanceado em todos os membros usando o algoritmo escolhido (round-robin, menos conexões etc.). Não é possível usar o SNI para escolher um membro específico em um pool.
Se você estiver usando um pool de back-end com o protocolo HTTP ou HTTPs, o ALB não definirá o SNI ao encaminhar a solicitação do cliente para o pool de back-end. Isso ocorre porque o ALB utiliza o SNI apenas para tomar uma decisão de encaminhamento (caso haja regras de camada 7 configuradas), e o ALB realiza um handshake de " TLS " separado com o backend (que é diferente do handshake do consumidor).
Se você estiver usando o protocolo TCP para o backend, em vez de HTTP /HTTPs, o ALB definirá o SNI enviado pelo consumidor. Isso ocorre porque o handshake do protocolo TLS será feito diretamente entre o consumidor e o backend, e não entre o ALB e o backend.
Use uma das seguintes soluções alternativas se você usar HTTP / HTTPS Listener com um SNI:
- Use um certificado curinga em um host virtual. Em seguida, configure apenas um único nome de host em portas de back-end separadas. Por exemplo, se você quiser roteamento por nome de host para servidores individuais, poderá criar pools separados para cada nome de host e usar o SNI para rotear para o pool correto.
- Use o modo TCP para o protocolo de backend em vez de HTTPS. TCP Esse modo encaminhará o SNI corretamente e ainda permitirá o balanceamento de carga com base nas regras de nome de host do SNI, caso você o configure.
Exemplo: Criar um ouvinte do tipo “ TCP ” com a regra “ sni_hostname ”
curl -H "Authorization: Bearer $iam_token" -X POST
"$vpc_api_endpoint/v1/load_balancers/$lbId/listeners" -d '{
"connection_limit": 2000,
"port": 443,
"protocol": "tcp",
"policies": [
{
"action": "forward_to_listener",
"name": "listener-forward-policy",
"priority": 4,
"rules": [
{
"condition": "equals",
"type": "sni_hostname",
"value": "www.example.com"
}
],
"target": {
"id": "r006-20275400-825e-4d9b-8177-076fdb4134cc"
}
}
]
}'