Bilanciamento del carico basato su criteri
I bilanciatori di carico delle applicazioni, sia pubblici che privati, supportano il bilanciamento del carico di livello 4 e 7, in cui il traffico di dati viene distribuito in base a criteri e regole configurati. Una policy definisce l'azione da intraprendere, ovvero le modalità di distribuzione del traffico, quando la richiesta in entrata soddisfa le regole associate alla policy stessa.
Politiche di livello 7
Puoi definire politiche per i listener HTTP e HTTPS. Per ogni politica, è necessario definire una o più regole. La politica viene applicata solo quando viene rilevata una corrispondenza a tutte le sue regole.
Puoi collegare più di una politica a un listener. In generale, una politica con la priorità più bassa viene valutata per prima. Ciascuna politica deve avere una priorità differente.
Se la richiesta in arrivo non corrisponde alle regole di nessuna policy, la richiesta di sistema reindirizza al listener di reindirizzamento HTTPS configurato, se presente. Altrimenti, il sistema reindirizza la richiesta al lotto predefinito del listener. Il reindirizzamento HTTPS ha una priorità maggiore rispetto al pool predefinito su un listener HTTP.
Per una politica di livello 7 sono supportate le seguenti azioni:
- Rifiuto- La richiesta viene respinta con una risposta 403.
- Reindirizzamento- La richiesta viene reindirizzata a un URL e a un codice di risposta configurati.
- Inoltro al pool- La richiesta viene inviata a un pool di back-end specifico.
- Inoltrare all'ascoltatore- La richiesta viene inviata a un ascoltatore front-end specifico.
- HTTPS redirect- La richiesta HTTP reindirizza a un listener HTTPS.
Proprietà delle politiche
| Proprietà | Descrizione |
|---|---|
| Nome | Il nome della politica. Il nome deve essere univoco all'interno del listener. |
| Azione | L'azione da eseguire quando tutte le regole della politica corrispondono. I valori accettabili sono reject, redirect, forward_to_pool, forward_to_listener e https_redirect. |
| Priority (Priorità) | Le politiche vengono valutate in base all'ordine crescente di priorità. |
| Priority (Priorità) | Le politiche vengono valutate in base all'ordine crescente di priorità. |
| URL | L'URL a cui viene reindirizzata la richiesta, se l'azione è impostata su redirect. Devi fornire un indirizzo URI completo ( URL ) o i parametri di un URI. Quando si utilizza un URL, tutto il traffico in entrata viene reindirizzato
a questo URL. Quando si utilizzano parametri URI, i valori delle richieste di traffico in entrata possono essere conservati utilizzando i valori in entrata dei parametri. I valori predefiniti dei parametri URI sono uguali ai valori originali
in entrata. Per conservare i valori in entrata, fornirli come {protocol},{port},{host},{path}, E {query}. Ad esempio, se l'host della richiesta in arrivo è ibm.com,
il valore predefinito è {host} uguale al valore dell' ibm.com e in arrivo. |
| Codice di stato HTTP | Codice di stato della risposta restituita dal bilanciatore di carico dell'applicazione quando l'azione è impostata su " redirect " o " https_redirect". I valori ammessi sono: 301,
302, 303, 307 o 308. |
| Destinazione | Se l'azione è impostata su forward_to_pool, la richiesta viene inoltrata al pool back-end di istanze di server virtuali. In alternativa, se l'azione è impostata su forward_to_listener, la richiesta viene inoltrata
a un ascoltatore front-end dello stesso ALB. |
| Listener | L'ascoltatore " HTTPS " a cui viene reindirizzata la richiesta, se l'azione è impostata su " https_redirect". |
| URI | L'URI relativo a cui viene reindirizzata la richiesta, se l'azione è https_redirect. Questa proprietà è facoltativa. |
Regole Livello 7
Una regola definisce le modalità di corrispondenza di una richiesta. Sono supportati sia l'instradamento basato su URI che l'instradamento basato sui parametri. Sono supportati i seguenti cinque tipi di regole.
| Tipo | Descrizione |
|---|---|
hostname |
La richiesta corrisponde all' hostname specificato, ad esempio api.my_company.com. |
header |
La richiesta corrisponde a un campo e a un valore di tipo “ HTTP ” header, ad esempio Cookie: xxxx. |
path |
La richiesta corrisponde alla stringa " path " contenuta nel campo " URL " dopo " hostname", ad esempio /index.html. |
query |
La richiesta corrisponde alla stringa " query " presente in URL, ad esempio x=y. La stringa " query " deve essere codificata in formato percentuale e distingue tra maiuscole e
minuscole. |
body |
La richiesta body relativa alla richiesta POST è codificata in formato form-encoded. La richiesta corrisponde al corpo, ad esempio key=value. È sensibile al maiuscolo / minuscolo. |
sni_hostname |
Il server indicato nell'estensione "server name indication" durante la negoziazione dell' TLS e corrisponde al nome host SNI specificato. |
Per corrispondere a una richiesta, in una regola deve essere definita un'istruzione condition. Sono supportate le seguenti quattro condizioni.
| Condizione | Tipo di valutazione |
|---|---|
contains |
Verifica se il valore estratto in base all' type contiene la stringa specificata nell' value. |
equals |
Verifica se il valore estratto in base a type è identico alla stringa specificata in value. |
matches_regex |
Confronta il valore estratto in base all' type con l'espressione regolare specificata nell' value. |
starts_with |
Verifica se il valore estratto in base all' type inizia con la stringa specificata nell' value. |
Proprietà delle regole
Questa tabella descrive le proprietà delle regole di policy del livello 7.
| Proprietà | Descrizione |
|---|---|
type |
Specifica il tipo di regola. I valori accettabili sono hostname, header, path, query o body. |
condition |
Specifica la condizione utilizzata per valutare la regola. I valori supportati sono contains, equals o matches_regex. |
field |
Specifica il nome del campo. Questo campo è applicabile solo al tipo di regola header query e body e non supporta l'espressione regolare e i caratteri jolly. Ad esempio, per la messa in corrispondenza
a un cookie nell'intestazione HTTP, il campo può essere impostato su cookie. Quando il tipo di regola Š query e body, questo campo Š facoltativo. Questa proprietà non è applicabile al tipo di regola
sni_hostname. |
value |
La stringa da confrontare. Questo campo non supporta i caratteri jolly. Le espressioni regolari sono supportate quando l' condition è impostato su matches_regex. |
Note:
- Se il tipo di regola è
header, i seguenti caratteri non sono consentiti perfieldevalue:"(),/:;<=>?@[\]{}'. - Se il tipo di regola è
body, i seguenti caratteri non sono consentiti perfieldevalue:"'=,()&e spazio. - Se il tipo di regola è
query,fieldevaluedevono essere una stringa codificata in percentuale.
Esempi: Creazione di politiche e regole
Gli esempi relativi al livello 7 riportati di seguito illustrano come vengono create le politiche e le regole e come vengono associate a un listener.
Esempio 1: Crea un listener HTTPS con le politiche di reindirizzamento
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"
}
]
}
]
}'
Esempio 2: Crea le politiche per inoltrare le richieste ai pool ed eseguine l'associazione a un listener esistente
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"
}
]
}
]
}'
Esempio 3: Creare un listener di tipo " HTTP " con criteri di reindirizzamento 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"
}
]
}
]
}'
Politiche di livello 4
È possibile definire criteri per i listener dell' TCP. Per ogni politica, è necessario definire una o più regole. Analogamente ai criteri di livello 7, un criterio di livello 4 viene applicato per primo con la priorità più bassa e solo quando tutte le sue regole designate vengono soddisfatte.
Se la richiesta in arrivo non soddisfa le regole di nessuna politica, il client potrebbe ricevere un errore " SSL ".
Per i criteri di livello 4 sono supportate le seguenti azioni:
- Inoltra al pool- La richiesta viene inviata a un pool di back-end specifico.
- Inoltrare all'ascoltatore- La richiesta viene inviata a un ascoltatore front-end specifico.
Regole di livello 4
Una regola di livello 4 definisce il modo in cui le richieste vengono abbinate, allo stesso modo di una regola di livello 7. Tuttavia, è supportato solo il tipo sni_hostname, dove field non è applicabile e le proprietà
condition e value sono le stesse delle regole di livello 7.
La regola "SNI Hostname" funziona solo con un listener TCP.
L'SNI in un ALB IBM Cloud è collegato all'ascoltatore e consente di instradare il traffico verso pool di backend diversi in base al nome dell'host. All'interno di un pool, il traffico è sempre bilanciato tra tutti i membri utilizzando l'algoritmo scelto (round-robin, meno connessioni, ecc.). Non è possibile utilizzare l'SNI per selezionare un membro specifico all'interno di un pool.
Se si utilizza un pool di backend con il protocollo HTTP o HTTP, l'ALB non imposterà l'SNI quando inoltra la richiesta del client al pool di backend. Questo perché l'ALB utilizza l'SNI solo per decidere come inoltrare il traffico (se sono configurate regole di livello 7) ed esegue una procedura di handshake separata TLS con il backend (che è diversa da quella del client).
Se per il backend si utilizza un protocollo TCP anziché HTTP /HTTPs, l'ALB imposterà l'SNI inviato dal client. Questo perché la procedura di handshake dell' TLS e avverrà direttamente tra l'utente finale e il backend, anziché tra l'ALB e il backend.
Utilizzare una delle seguenti soluzioni se si utilizza HTTP / HTTPS Listener con un SNI:
- Utilizzare un certificato wildcard su un host virtuale. Quindi configurare un solo nome host su porte backend separate. Ad esempio, se si desidera un instradamento per hostname verso i singoli server, si possono creare pool separati per ogni hostname e usare l'SNI per instradare verso il pool corretto.
- Utilizza la modalità TCP per il protocollo di backend al posto di HTTPS. TCP Questa modalità inoltrerà correttamente l'SNI e consentirà comunque il bilanciamento del carico in base alle regole relative al nome host SNI, se configurata.
Esempio: creare un listener " TCP " con la regola " 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"
}
}
]
}'