Equilibrio de carga basado en políticas
Tanto los equilibradores de carga de aplicaciones públicos como los privados admiten el equilibrio de carga de capa 4 y capa 7, en el que el tráfico de datos se distribuye en función de políticas y reglas configuradas. Una política define la acción que se va a emprender, es decir, la forma en que distribuye el tráfico, cuando la solicitud de entrada coincide con las reglas asociadas con la política.
Políticas de la capa 7
Puede definir políticas para escuchas HTTP y HTTPS. Para cada política, debe definir una o varias reglas. La política solo se aplica cuando todas sus reglas coinciden.
Puede conectar más de una política a un escucha. En general, se evalúa primero una política con una prioridad más baja. Cada política debe tener una prioridad diferente.
Si la solicitud de entrada no coincide con las reglas de ninguna política, la solicitud del sistema se redirige al escucha de redirección HTTPS configurado, si lo hay. De lo contrario, el sistema redirige la solicitud a la agrupación predeterminada del escucha. La redirección HTTPS tiene prioridad sobre la agrupación predeterminada en un escucha HTTP.
Se da soporte a las siguientes acciones para una política de capa 7:
- Reject: se deniega la solicitud con una respuesta 403.
- Redirect: se redirige la solicitud a un URL y un código de respuesta configurado.
- Reenviar al grupo: la solicitud se envía a un grupo de back-end específico.
- Reenviar a receptor- La solicitud se envía a un receptor de front-end específico.
- Redirección de HTTPS: la solicitud HTTP se redirige a un escucha HTTPS.
Propiedades de política
| Propiedad | Descripción |
|---|---|
| Nombre | El nombre de la política. El nombre debe ser exclusivo dentro del escucha. |
| Acción | La acción que se debe llevar a cabo cuando todas las reglas de política coinciden. Los valores válidos son reject, redirect, forward_to_pool, forward_to_listener y https_redirect. |
| Prioridad | Las políticas se evalúan por orden ascendente de prioridad. |
| Prioridad | Las políticas se evalúan por orden ascendente de prioridad. |
| URL | El URL al que se redirige la solicitud, si la acción se ha establecido como redirect. Debe proporcionar un URI completo ( URL ) o los parámetros de un URI. Cuando se utiliza un URL, todo el tráfico entrante se redirige a este
URL. Cuando se utilizan parámetros de URI, los valores de las solicitudes de tráfico entrantes se pueden conservar utilizando los valores entrantes de los parámetros. Los valores predeterminados de los parámetros URI son iguales a sus
valores entrantes originales. Para conservar los valores entrantes, proporciónelos como {protocol},{port},{host},{path}, y {query}. Por ejemplo, si el host de la solicitud
entrante es ibm.com, entonces el valor predeterminado es {host} igual al valor de la solicitud entrante ibm.com. |
| Código de estado HTTP | Código de estado de la respuesta devuelta por el equilibrador de carga de aplicación cuando la acción se establece en redirect o https_redirect. Los valores aceptables son: 301, 302,
303, 307 o 308. |
| Destino | Si la acción se establece en forward_to_pool, la solicitud se reenvía al conjunto de instancias de servidor virtual del back-end. Alternativamente, si la acción se establece en forward_to_listener, la solicitud
se reenvía a un receptor de front-end del mismo ALB. |
| Escucha | Escucha HTTPS al que se redirige la solicitud, si la acción se establece en https_redirect. |
| URI | URI relativo al que se redirige la solicitud, si la acción es https_redirect. Esta propiedad es opcional. |
Reglas de capa 7
Una regla define cómo se compara una solicitud. Se da soporte al direccionamiento basado en URI y al direccionamiento basado en parámetros. Se admiten los cinco tipos de reglas siguientes.
| Tipo | Descripción |
|---|---|
hostname |
La solicitud coincide con el dominio hostname especificado, como por ejemplo api.my_company.com. |
header |
La solicitud coincide con un campo y un valor de « HTTP » header, como por ejemplo Cookie: xxxx. |
path |
La solicitud coincide con la cadena « path » que aparece en « URL » después de « hostname », como por ejemplo /index.html. |
query |
La solicitud coincide con la cadena « query » que figura en URL, por ejemplo, x=y. La cadena « query » debe estar codificada en formato porcentual y distingue entre mayúsculas y minúsculas. |
body |
La solicitud body para la solicitud POST está codificada mediante el método «form-encoded». La solicitud coincide con el cuerpo, por ejemplo key=value. Es sensible a mayúsculas y minúsculas. |
sni_hostname |
El servidor indicado en la extensión «indicación del nombre del servidor» (SNI) durante la negociación de TLS coincide con el nombre de host SNI especificado. |
Para que coincida con una solicitud, se debe definir una sentencia condition en una regla. Se admiten las cuatro condiciones siguientes.
| Condición | Tipo de evaluación |
|---|---|
contains |
Comprueba si el valor extraído a partir de type contiene la cadena especificada en value. |
equals |
Comprueba si el valor extraído a partir de type es idéntico a la cadena especificada en value. |
matches_regex |
Compara el valor extraído según el « type » con la expresión regular especificada en el « value ». |
starts_with |
Comprueba si el valor extraído a partir de type comienza con la cadena especificada en value. |
Propiedades de regla
Esta tabla describe las propiedades de las reglas de política de la capa 7.
| Propiedad | Descripción |
|---|---|
type |
Especifica el tipo de regla. Los valores válidos son hostname, header, path, query o body. |
condition |
Especifica la condición que se utiliza para evaluar la regla. Los valores admitidos son contains, equals o matches_regex. |
field |
Especifica el nombre del campo. Este campo solo es aplicable al tipo de regla header query y body y no da soporte a la expresión regular ni a los caracteres comodín. Por ejemplo, para hacer coincidir
una cookie en la cabecera HTTP, el campo se puede establecer en cookie. Cuando el tipo de regla es query y body, este campo es opcional. Esta propiedad no es aplicable al tipo de regla sni_hostname. |
value |
La serie que se va a comparar. Este campo no admite caracteres comodín. Las expresiones regulares son compatibles cuando la opción « condition » está configurada en « matches_regex ». |
Notas:
- Si el tipo de regla es
header, no se permitirán los siguientes caracteres enfieldyvalue:"(),/:;<=>?@[\]{}'. - Si el tipo de regla es
body, no se permiten los siguientes caracteres parafieldyvalue:"'=,()&y espacio. - Si el tipo de regla es
query,fieldyvaluedebe ser una serie codificada por porcentaje.
Ejemplos: Creación de políticas y reglas
En los siguientes ejemplos de capa 7 se muestra cómo se crean las políticas y las reglas y se asocian con un escucha.
Ejemplo 1: Crear un escucha HTTPS con políticas de redirección
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"
}
]
}
]
}'
Ejemplo 2: Crear políticas para reenviar las solicitudes a agrupaciones y asociarlas con un escucha 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"
}
]
}
]
}'
Ejemplo 3: Crear un escucha HTTP con políticas de redirección 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 de nivel 4
Puedes definir políticas para los oyentes de « TCP ». Para cada política, debe definir una o varias reglas. De forma similar a las políticas de capa 7, una política de capa 4 se aplica primero con la prioridad más baja y sólo cuando coinciden todas sus reglas designadas.
Si la solicitud entrante no cumple las reglas de ninguna política, es posible que el cliente reciba un error de « SSL ».
Las siguientes acciones son compatibles con las políticas de capa 4:
- Reenviar al grupo: la solicitud se envía a un grupo de back-end específico.
- Reenviar a receptor- La solicitud se envía a un receptor front-end específico.
Normas de nivel 4
Una regla de capa 4 define cómo se emparejan las solicitudes, igual que una regla de capa 7. Sin embargo, sólo se admite el tipo sni_hostname, donde field no es aplicable y las propiedades condition y value son las mismas que para las reglas de capa 7.
La regla «SNI Hostname» solo funciona con un listener de tipo « TCP ».
SNI en un ALB IBM Cloud se adjunta al oyente y le permite enrutar el tráfico a diferentes grupos de backend en función del nombre de host. Dentro de un grupo, el tráfico siempre se equilibra entre todos los miembros utilizando el algoritmo elegido (round-robin, menos conexiones, etc.). No se puede utilizar SNI para elegir un miembro específico dentro de un pool.
Si se utiliza un pool de backend con Protocolo HTTP o HTTPs, el ALB no establecerá el SNI cuando reenvíe la petición del cliente al pool de backend. Esto se debe a que el ALB solo utiliza el SNI para tomar una decisión de reenvío (si se han configurado reglas de capa 7), y el ALB establece una conexión « TLS » independiente con el servidor de fondo (que es diferente de la conexión del usuario).
Si utilizas el protocolo TCP para el backend, en lugar de HTTP o HTTPS, el ALB configurará el SNI enviado por el consumidor. Esto se debe a que el protocolo de enlace de la capa de aplicación ( TLS ) se establecerá directamente entre el cliente y el servidor backend, en lugar de entre el ALB y el servidor backend.
Utilice una de las siguientes soluciones si utiliza HTTP / HTTPS Listener con un SNI:
- Utilice un certificado comodín en un host virtual. A continuación, configure un único nombre de host en puertos backend independientes. Por ejemplo, si desea enrutamiento por nombre de host a servidores individuales, puede crear grupos separados para cada nombre de host y utilizar el SNI para enrutar al grupo correcto.
- Utiliza el modo « TCP » para el protocolo del backend en lugar de HTTPS. TCP Este modo reenviará el SNI correctamente y seguirá permitiendo el equilibrio de carga basado en reglas de nombres de host SNI si se configura así.
Ejemplo: Crear un listener « TCP » con la regla « 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"
}
}
]
}'