pool-create and update with SOURCE_IP LB method assigns wrong algorithm in BIG-IP

alonsocamaro commented 8 years ago

OpenStack Release

Mitaka

Description

Hi

The following pool

root@node-1:~# neutron lbaas-pool-create --lb-algorithm SOURCE_IP --listener ha-3 --protocol HTTP --name ha-3
Created a new pool:
+---------------------+------------------------------------------------+
| Field               | Value                                          |
+---------------------+------------------------------------------------+
| admin_state_up      | True                                           |
| description         |                                                |
| healthmonitor_id    |                                                |
| id                  | d17da29b-ae23-416e-afbd-4c9e9021e369           |
| lb_algorithm        | SOURCE_IP                                      |
| listeners           | {"id": "dbf356ab-adf9-40b4-84db-98812660dab8"} |
| loadbalancers       | {"id": "bd15ab75-d201-4e8d-8ecc-c0dd5ea18817"} |
| members             |                                                |
| name                | ha-3                                           |
| protocol            | HTTP                                           |
| session_persistence |                                                |
| tenant_id           | 1bcf7ba13bcb496196d72f481bfebb5c               |
+---------------------+------------------------------------------------+

Assigns the the least-connections-node LB method in the BIG-IP

root@(bigip1)(cfg-sync Changes Pending)(Standby)(/Project_1bcf7ba13bcb496196d72f481bfebb5c)(tmos)# list ltm pool ha-3
ltm pool ha-3 {
    load-balancing-mode least-connections-node
    partition Project_1bcf7ba13bcb496196d72f481bfebb5c
}

without specifying a source based persistence method. This is not the expected behavior.

I find that the F5 way of achieving the expected LBaaSv2 spec would be by using source persistence using CARP. This would achieve the functionality in a stateless fashion

Many thanks

Ulises

Agent Version

9.0.2

Operating System

Mirantis 9.0

jgruber commented 8 years ago

Please list the virtual service and confirm you see:

persist {
        source_addr {
            default yes
        }
    }

If you do, please close the item.

This will enable persistence affinity based on the client source IP address. Traditionally at f5 this was called simple persistence.

For an explanation of simple persistence please reference:

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-profiles-reference-12-1-0/4.html#conceptid

Just a note: As for statefulness, the src_addr persistence profile has a default timeout of 180 seconds. For any connections from the same source IP address for that period, the load balancing decision will be overridden by the stateful persistence entry established when a client source IP address first created a connection with the virtual server. As you mention, the BIG-IP hash persistence profile using the IP Source as the hash key can provide persistence without a stateful timeout. Please let us know if you have a firm requirement for IP source persistence to a pool member which goes beyond 180 seconds. If you do we can consider changing the persistence method used. We'll label the issue an enhancement request.

alonsocamaro commented 8 years ago

Hi

Source persistence is not being applied:

root@(bigip1)(cfg-sync Not All Devices Synced)(Standby)(/Project_1bcf7ba13bcb496196d72f481bfebb5c)(tmos)# list ltm virtual ha-3
ltm virtual ha-3 {
    destination 10.0.2.183:http
    ip-protocol tcp
    mask 255.255.255.255
    partition Project_1bcf7ba13bcb496196d72f481bfebb5c
    pool ha-5
    profiles {
        /Common/tcp { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vs-index 11
}

I have checked this also happens in version 9.0.3

In the other hand, I find that by implementing a stateful / timer behavior is not what I would expect from a load balancing algorithm that it is expected to be based on IP address.

I have checked that haproxy/the reference implementation uses stateless/hashing algorithm. Here you have a couple of references: http://www.diogogmt.com/load-balancers and https://answers.launchpad.net/neutron/+question/271975

Moreover if a timer approach is desired then LBaaS SOURCE_IP session persistence is already in place

I find that if we are not stateless we will be eventually generating issues to the customers. My feeling is that they will not expect this behavior either.

jlongstaf commented 7 years ago

The F5 agent fails to add source_addr persistence to the virtual server associated with the pool. This is a bug and will be fixed.

As a work around, users can include SOURCE_IP session persistence when creating their pool. For example:

neutron lbaas-pool-create --name pool1 --listener vip1 --lb-algorithm SOURCE_IP --protocol HTTP --session-persistence type=SOURCE_IP

When session-persistence is included in the pool create command, the F5 agent will add the a source_addr persistence profile to the virtual server associated with the pool. As noted in the discussion above, the profile /Common/source_addr has a timeout of 180 seconds by default, which may not be ideal.

F5Networks / f5-openstack-agent