Chapter 7. Creating insecure HTTP load balancers


In Red Hat OpenStack Services on OpenShift (RHOSO) environments, you can create load balancers for insecure HTTP network traffic.

For networks that are not compatible with Red Hat OpenStack Services on OpenShift (RHOSO) Networking service (neutron) floating IPs, create a load balancer to manage network traffic for insecure HTTP applications. Create a health monitor to ensure that your back-end members remain available.

Prerequisites

  • A shared external (public) subnet that you can reach from the internet.
  • The administrator has created a project for you and has provided you with a clouds.yaml file for you to access the cloud.
  • The python-openstackclient package is on your workstation.

    $ dnf list installed python-openstackclient

Procedure

  1. Confirm that the system OS_CLOUD variable is set for your cloud:

    $ echo $OS_CLOUD
    my_cloud

    Reset the variable if necessary:

    $ export OS_CLOUD=my_other_cloud

    As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

  2. Create a load balancer (lb1) on a public subnet (public_subnet).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.

    Example
    $ openstack loadbalancer create --name lb1 \
    --vip-subnet-id public_subnet --wait
  3. Create a listener (listener1) on a port (80).

    Example
    $ openstack loadbalancer listener create --name listener1 \
    --protocol HTTP --protocol-port 80 lb1 --wait
  4. Verify the state of the listener.

    Example
    $ openstack loadbalancer listener show listener1

    Before going to the next step, ensure that the status is ACTIVE.

  5. Create the listener default pool (pool1).

    Example
    $ openstack loadbalancer pool create --name pool1 \
    --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
  6. Create a health monitor (healthmon1) of type (HTTP) on the pool (pool1) that connects to the back-end servers and tests the path (/).

    Health checks can help to avoid a false positive. If no health monitor is defined, the member remains in the NO_MONITOR state and is considered available to receive traffic, regardless of its actual operational status.

    Example
    $ openstack loadbalancer healthmonitor create --name healthmon1 \
    --delay 15 --max-retries 4 --timeout 10 --type HTTP --url-path / \
    pool1 --wait
  7. Add load-balancer members (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the default pool.

    Example

    In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2:

    $ openstack loadbalancer member create --name member1 --subnet-id \
    private_subnet --address 192.0.2.10 --protocol-port 80 pool1 --wait
    
    $ openstack loadbalancer member create --name member2 --subnet-id \
    private_subnet --address 192.0.2.11 --protocol-port 80 pool1 --wait

Verification

  1. View and verify the load-balancer (lb1) settings:

    Example
    $ openstack loadbalancer show lb1
    Sample output
    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2024-01-15T11:11:09                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2024-01-15T11:12:13                  |
    | vip_address         | 198.51.100.12                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. When a health monitor is present and functioning properly, you can check the status of each member.

    A working member (member1) has an ONLINE value for its operating_status.

    Example
    $ openstack loadbalancer member show pool1 member1
    Sample output
    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.2.10                           |
    | admin_state_up      | True                                 |
    | created_at          | 2024-01-15T11:16:23                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                | member1                              |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2024-01-15T11:20:45                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

To manage traffic for insecure HTTP applications, create a load balancer with a virtual IP (VIP) that uses a floating IP. The floating IP gives you control of the assigned IP so that you can move, delete, or re-create the load balancer.

You should also create a health monitor so that your back-end members remain available.

Note

Floating IPs do not work with IPv6 networks.

Prerequisites

  • A floating IP to use with a load-balancer VIP.
  • A RHOSO Networking service (neutron) shared external (public) subnet that you can reach from the internet to use for the floating IP.
  • The administrator has created a project for you and has provided you with a clouds.yaml file for you to access the cloud.
  • The python-openstackclient package is on your workstation.

    $ dnf list installed python-openstackclient

Procedure

  1. Confirm that the system OS_CLOUD variable is set for your cloud:

    $ echo $OS_CLOUD
    my_cloud

    Reset the variable if necessary:

    $ export OS_CLOUD=my_other_cloud

    As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

  2. Create a load balancer (lb1) on a private subnet (private_subnet).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.

    Example
    $ openstack loadbalancer create --name lb1 \
    --vip-subnet-id private_subnet --wait
  3. In the output from the previous step, record the value of load_balancer_vip_port_id, because you must provide it in a later step.
  4. Create a listener (listener1) on a port (80).

    Example
    $ openstack loadbalancer listener create --name listener1 \
    --protocol HTTP --protocol-port 80 lb1 --wait
  5. Create the listener default pool (pool1).

    Example

    The command in this example creates an HTTP pool that uses a private subnet containing back-end servers that host insecure HTTP applications on TCP port 80:

    $ openstack loadbalancer pool create --name pool1 \
    --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP --wait
  6. Create a health monitor (healthmon1) of type (HTTP) on the pool (pool1) that connects to the back-end servers and tests the path (/).

    Health checks can help to avoid a false positive. If no health monitor is defined, the member remains in the NO_MONITOR state and is considered available to receive traffic, regardless of its actual operational status.

    Example
    $ openstack loadbalancer healthmonitor create --name healthmon1 \
    --delay 15 --max-retries 4 --timeout 10 --type HTTP --url-path / \
    pool1 --wait
  7. Add load-balancer members (192.0.2.10 and 192.0.2.11) on the private subnet to the default pool.

    Example

    In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2:

    $ openstack loadbalancer member create --name member1 --subnet-id \
    private_subnet --address 192.0.2.10 --protocol-port 80 pool1 --wait
    
    $ openstack loadbalancer member create --name member2 --subnet-id \
    private_subnet --address 192.0.2.11 --protocol-port 80 pool1 --wait
  8. Create a floating IP address on the shared external subnet (public).

    Example
    $ openstack floating ip create public
  9. In the output from step 8, record the value of floating_ip_address, because you must provide it in a later step.
  10. Associate this floating IP (203.0.113.0) with the load-balancer vip_port_id (69a85edd-5b1c-458f-96f2-b4552b15b8e6).

    Example
    $ openstack floating ip set --port 69a85edd-5b1c-458f-96f2-b4552b15b8e6 203.0.113.0

Verification

  1. Verify HTTP traffic flows across the load balancer by using the floating IP (203.0.113.0).

    Example
    $ curl -v http://203.0.113.0 --insecure
    Sample output
    * About to connect() to 203.0.113.0 port 80 (#0)
    *   Trying 203.0.113.0...
    * Connected to 203.0.113.0 (203.0.113.0) port 80 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.29.0
    > Host: 203.0.113.0
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Content-Length: 30
    <
    * Connection #0 to host 203.0.113.0 left intact
  2. When a health monitor is present and functioning properly, you can check the status of each member.

    A working member (member1) has an ONLINE value for its operating_status.

    Example
    $ openstack loadbalancer member show pool1 member1
    Sample output
    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.02.10                          |
    | admin_state_up      | True                                 |
    | created_at          | 2024-01-15T11:11:23                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                | member1                              |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2024-01-15T11:28:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+

To manage network traffic for insecure HTTP applications, you can create load balancers that track session persistence.

Session persistence ensures that when a request comes in, the load balancer directs subsequent requests from the same client to the same back-end server. Session persistence optimizes load balancing by saving time and memory.

Prerequisites

  • A shared external (public) subnet that you can reach from the internet.
  • The insecure web applications whose network traffic you are load balancing have cookies enabled.
  • The administrator has created a project for you and has provided you with a clouds.yaml file for you to access the cloud.
  • The python-openstackclient package is on your workstation.

    $ dnf list installed python-openstackclient

Procedure

  1. Confirm that the system OS_CLOUD variable is set for your cloud:

    $ echo $OS_CLOUD
    my_cloud

    Reset the variable if necessary:

    $ export OS_CLOUD=my_other_cloud

    As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

  2. Create a load balancer (lb1) on a public subnet (public_subnet).

    Note

    Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.

    Example
    $ openstack loadbalancer create --name lb1 \
    --vip-subnet-id public_subnet --wait
  3. Create a listener (listener1) on a port (80).

    Example
    $ openstack loadbalancer listener create --name listener1 \
    --protocol HTTP --protocol-port 80 lb1 --wait
  4. Create the listener default pool (pool1) that defines session persistence on a cookie (PHPSESSIONID).

    Example

    The command in this example creates an HTTP pool that uses a private subnet containing back-end servers that host insecure HTTP applications on TCP port 80:

    $ openstack loadbalancer pool create --name pool1 \
    --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP \
    --session-persistence type=APP_COOKIE,cookie_name=PHPSESSIONID --wait
  5. Create a health monitor (healthmon1) of type (HTTP) on the pool (pool1) that connects to the back-end servers and tests the path (/).

    Health checks can help to avoid a false positive. If no health monitor is defined, the member remains in the NO_MONITOR state and is considered available to receive traffic, regardless of its actual operational status.

    Example
    $ openstack loadbalancer healthmonitor create --name healthmon1 \
    --delay 15 --max-retries 4 --timeout 10 --type HTTP --url-path / \
    pool1 --wait
  6. Add load-balancer members (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the default pool.

    Example

    In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2:

    $ openstack loadbalancer member create --name member1 --subnet-id \
    private_subnet --address 192.0.2.10 --protocol-port 80 pool1 --wait
    
    $ openstack loadbalancer member create --name member2 --subnet-id \
    private_subnet --address 192.0.2.11 --protocol-port 80 pool1 --wait

Verification

  1. View and verify the load-balancer (lb1) settings:

    Example
    $ openstack loadbalancer show lb1
    Sample output
    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | admin_state_up      | True                                 |
    | created_at          | 2024-01-15T11:11:58                  |
    | description         |                                      |
    | flavor              |                                      |
    | id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
    | listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
    | name                | lb1                                  |
    | operating_status    | ONLINE                               |
    | pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | provider            | amphora                              |
    | provisioning_status | ACTIVE                               |
    | updated_at          | 2024-01-15T11:28:42                  |
    | vip_address         | 198.51.100.22                        |
    | vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
    | vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
    | vip_qos_policy_id   | None                                 |
    | vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    +---------------------+--------------------------------------+
  2. When a health monitor is present and functioning properly, you can check the status of each member.

    A working member (member1) has an ONLINE value for its operating_status.

    Example
    $ openstack loadbalancer member show pool1 member1
    Sample output
    +---------------------+--------------------------------------+
    | Field               | Value                                |
    +---------------------+--------------------------------------+
    | address             | 192.0.02.10                          |
    | admin_state_up      | True                                 |
    | created_at          | 2024-01-15T11:11:23                  |
    | id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
    | name                | member1                              |
    | operating_status    | ONLINE                               |
    | project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
    | protocol_port       | 80                                   |
    | provisioning_status | ACTIVE                               |
    | subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
    | updated_at          | 2024-01-15T11:28:42                  |
    | weight              | 1                                    |
    | monitor_port        | None                                 |
    | monitor_address     | None                                 |
    | backup              | False                                |
    +---------------------+--------------------------------------+
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top