Équilibrage de charge basé sur des règles
Les équilibreurs de charge d'application publics et privés prennent en charge l'équilibrage de la couche 4 et de la couche 7, où le trafic de données est distribué sur la base de politiques et de règles configurées. Une stratégie définit l'action à entreprendre, c'est à dire la façon dont le trafic est distribué quand la demande entrante correspond aux règles associées à cette stratégie.
Politiques de la couche 7
Vous pouvez définir des stratégies pour les écouteurs HTTP et HTTPS. Pour chaque stratégie, vous devez définir une ou plusieurs règles. La stratégie n'est appliquée que lorsque toutes ses règles correspondent.
Vous pouvez connecter plusieurs stratégies à un écouteur. En général, la stratégie dont la priorité est la moins élevée est évaluée en premier. Chaque stratégie doit avoir une priorité différente.
Si la demande entrante ne correspond pas aux règles d'une stratégie, la demande du système est redirigée vers l'écouteur de redirection HTTPS configuré, le cas échéant. Sinon, le système redirige la demande vers le pool par défaut de l'écouteur. La redirection HTTPS a une priorité plus élevée que le pool par défaut sur un écouteur HTTP.
Les actions suivantes sont prises en charge pour une stratégie de couche 7 :
- reject - La demande est refusée avec une réponse 403.
- redirect - La demande est redirigée vers une URL configurée et un code de réponse.
- Transfert vers un pool: la requête est envoyée à un pool de serveurs back-end spécifique.
- Transférer à l'auditeur- La demande est envoyée à un auditeur frontal spécifique.
- HTTPS Redirect - La demande HTTP est redirigée vers un écouteur HTTPS.
Propriétés de politique
| Propriété | Description |
|---|---|
| Nom | Nom de la stratégie. Le nom doit être unique au sein de l'écouteur. |
| Action | Action à entreprendre lorsque toutes les règles conditionnelles correspondent. Les valeurs acceptées sont : reject, redirect, forward_to_pool, forward_to_listener et https_redirect. |
| Priorité | Les stratégies sont évaluées par ordre croissant de priorité. |
| Priorité | Les stratégies sont évaluées par ordre croissant de priorité. |
| URL | Adresse URL vers laquelle la demande est redirigée, si l'action est définie sur redirect. Vous devez fournir soit une adresse URL complète ( URL ), soit les paramètres d'une adresse URL. Lors de l'utilisation d'un URL, tout
le trafic entrant est redirigé vers cette URL. Lors de l'utilisation de paramètres URI, les valeurs des demandes de trafic entrantes peuvent être conservées en utilisant les valeurs entrantes des paramètres. Les valeurs par défaut des
paramètres URI sont égales à leurs valeurs entrantes d'origine. Pour conserver les valeurs entrantes, fournissez-les comme {protocol},{port},{host},{path}, et {query}.
Par exemple, si l'hôte de la requête entrante est ibm.com, alors la valeur par défaut est {host} égale à la valeur d' ibm.com e entrante. |
| Codes de statut HTTP | Code de statut de la réponse renvoyée par l'équilibreur de charge de l'application lorsque l'action est définie sur redirect ou https_redirect. Les valeurs admises sont : 301, 302, 303,
307 ou 308. |
| Cible | Si l'action est définie sur forward_to_pool, la demande est transmise au pool d'instances de serveurs virtuels du back-end. Par ailleurs, si l'action est définie sur forward_to_listener, la demande est transmise
à un auditeur frontal du même ALB. |
| Programme d'écoute | Ecouteur HTTPS vers lequel la demande est redirigée, si l'action est définie sur https_redirect. |
| URI | URI relatif vers lequel la demande est redirigée, si l'action est https_redirect. Cette propriété est facultative. |
Règles de couche 7
Une règle définit la manière dont une requête est mise en correspondance. Le routage basé sur l'URI et le routage basé sur les paramètres sont tous deux pris en charge. Les cinq types de règles suivants sont pris en charge.
| Type | Description |
|---|---|
hostname |
La requête correspond à l' hostname spécifiée, telle que api.my_company.com. |
header |
La requête correspond à un champ et à une valeur de type « HTTP » header, par exemple Cookie: xxxx. |
path |
La requête correspond à l' path e figurant dans l' URL e après le hostname, par exemple /index.html. |
query |
La requête correspond à la chaîne « query » figurant dans le fichier URL, par exemple x=y. La chaîne « query » doit être encodée en pourcentage et respecte la casse. |
body |
La requête body pour la requête POST est encodée au format « form-encoded ». La demande correspond au corps (par exemple, key=value). Il est sensible à la casse. |
sni_hostname |
Le serveur indiqué dans l'extension « Server Name Indication » (SNI) lors de la négociation du protocole TLS correspond au nom d'hôte SNI spécifié. |
Pour faire correspondre une demande, une instruction condition doit être définie dans une règle. Les quatre conditions suivantes sont prises en charge.
| Condition | Type d'évaluation |
|---|---|
contains |
Vérifie si la valeur extraite à partir de l' type contient la chaîne de caractères spécifiée dans l' value. |
equals |
Vérifie si la valeur extraite à partir de l' type est identique à la chaîne spécifiée dans l' value. |
matches_regex |
Compare la valeur extraite à partir de l' type, à l'expression régulière spécifiée dans le fichier value. |
starts_with |
Vérifie si la valeur extraite à partir de l' type commence par la chaîne de caractères spécifiée dans l' value. |
Propriétés de règle
Ce tableau décrit les propriétés des règles de politique de couche 7.
| Propriété | Description |
|---|---|
type |
Spécifie le type de règle. Les valeurs autorisées sont : hostname, header, path, query ou body. |
condition |
Spécifie la condition utilisée pour évaluer la règle. Les valeurs prises en charge sont : contains, equals ou matches_regex. |
field |
Indique le nom de zone. Cette zone est uniquement applicable aux types de règle header, query et body et ne prend pas en charge les expressions régulières et les caractères génériques. Par exemple,
pour rechercher un cookie dans l'en-tête HTTP, la zone peut être définie sur cookie. Si le type de règle est query ou body, cette zone est facultative. Cette propriété ne s'applique pas au type
de règle sni_hostname. |
value |
Chaîne à rechercher. Ce champ n'accepte pas les caractères génériques. Les expressions régulières sont prises en charge lorsque l' condition est défini sur « matches_regex ». |
Remarques :
- Si le type de règle est
header, les caractères suivants ne sont pas autorisés pourfieldetvalue:"(),/:;<=>?@[\]{}'. - Si le type de règle est
body, les caractères suivants ne sont pas autorisés pourfieldetvalue:"'=,()&et espace. - Si le type de règle est
query,fieldetvaluedoivent correspondre à une chaîne encodée en pourcentage.
Exemples : création de stratégies et de règles
Les exemples de couche 7 suivants montrent comment les stratégies et les règles sont créées et associées à un écouteur.
Exemple 1: Création d'un écouteur HTTPS avec des stratégies de redirection
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"
}
]
}
]
}'
Exemple 2 : Création de stratégies pour réacheminer les demandes vers des pools et les associer à un écouteur existant
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"
}
]
}
]
}'
Exemple 3 : Création d'un écouteur HTTP avec des stratégies de redirection 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"
}
]
}
]
}'
Politiques de la couche 4
Vous pouvez définir des règles pour les écouteurs d' TCP. Pour chaque stratégie, vous devez définir une ou plusieurs règles. Comme pour les politiques de la couche 7, une politique de la couche 4 est appliquée avec la priorité la plus faible en premier lieu et uniquement lorsque toutes les règles qu'elle a désignées sont respectées.
Si la requête entrante ne correspond à aucune règle d'une politique, le client peut recevoir une erreur « SSL ».
Les actions suivantes sont prises en charge pour les stratégies de niveau 4 :
- Transférer vers un pool: la requête est envoyée à un pool de serveurs back-end spécifique.
- Transférer à l'auditeur- La demande est envoyée à un auditeur frontal spécifique.
Règles de la couche 4
Une règle de couche 4 définit la manière dont les demandes sont traitées, de la même manière qu'une règle de couche 7. Toutefois, seul le type sni_hostname est pris en charge, field n'étant pas applicable et les propriétés
condition et value étant les mêmes que pour les règles de la couche 7.
La règle « SNI Hostname » ne fonctionne qu'avec un écouteur de type « TCP ».
Le SNI dans un ALB IBM Cloud est attaché à l'auditeur et vous permet d'acheminer le trafic vers différents pools de backend en fonction du nom d'hôte. Au sein d'un pool, le trafic est toujours réparti entre tous les membres selon l'algorithme choisi (round-robin, moins de connexions, etc.). Vous ne pouvez pas utiliser SNI pour sélectionner un membre spécifique dans un pool.
Si vous utilisez un pool de backend avec le protocole HTTP ou HTTP, l'ALB ne définira pas le SNI lorsqu'il transmettra la demande du client au pool de backend. TLS En effet, l'ALB utilise uniquement le SNI pour prendre une décision de redirection (si des règles de couche 7 sont configurées), et il établit une connexion SSL distincte avec le serveur backend (qui diffère de celle établie avec l'utilisateur).
Si vous utilisez le protocole TCP pour le backend, au lieu de HTTP /HTTPs, l'ALB configurera le SNI envoyé par le client. En effet, la négociation de connexion TLS s'effectuera directement entre l'utilisateur et le serveur backend, et non entre l'ALB et le serveur backend.
Utilisez l'une des solutions suivantes si vous utilisez HTTP / HTTPS Listener avec un SNI :
- Utiliser un certificat de type "wildcard" sur un hôte virtuel. Configurez ensuite un seul nom d'hôte sur des ports distincts. Par exemple, si vous souhaitez un routage par nom d'hôte vers des serveurs individuels, vous pouvez créer des pools distincts pour chaque nom d'hôte et utiliser la SNI pour router vers le bon pool.
- Utilisez le mode TCP pour le protocole de fond à la place de HTTPS. TCP Ce mode transmettra correctement le SNI tout en permettant l'équilibrage de charge basé sur les règles de nom d'hôte SNI si vous le configurez.
Exemple : Créer un écouteur « TCP » avec la règle « 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"
}
}
]
}'