Link to Online Topic Content
CMP Effects Load Balancing Methods
CMP should not be confused with Symmetric Multi-Processing (SMP). SMP architecture is used in multiple operating systems. SMP operates by allowing operating systems and software applications that are optimized for SMP to use the multiple processors
available to the operating system. SMP performs this operation by spreading multiple threads across multiple processors, which allows for faster processing and more efficient use of system resources, as multiple threads can be processed simultaneously instead of waiting in a queue to be processed. CMP uses a similar approach to leverage multiple processing units by spawning a separate instance of the TMM process on each processing unit available to the system. While SMP may be used for any process, CMP processing is available only to the BIG-IP TMM process for the sole purpose of providing more dedicated resources to manage load balanced traffic. With multiple TMM
instances simultaneously processing traffic, system performance is enhanced, and traffic management capacity is expanded.
The CMP feature is automatically enabled on CMP-capable platforms, ensuring that all instances of TMM are available to process application traffic as follows:
2 TMM processes running on a dual-CPU BIG-IP 8400 system
4 TMM processes running on a dual-core, dual-CPU BIG-IP 8800 system
32 TMM processes running on a VIPRION platform with four 2100 blades
Load balancing behavior on CMP enabled virtual servers
Connections on a CMP enabled virtual server are distributed among the available TMM processes. The load balancing algorithm, specified within the pool associated with the CMP enabled virtual server, is applied independently in each TMM. Since each TMM handles load balancing independently from the other TMMs, distribution across the pool members may appear to be incorrect when compared with a non-CMP enabled virtual server using the same load balancing algorithm.
Consider the following example configuration:
Virtual Server: 172.16.10.10:80 Pool with 4 members: 10.0.0.1:80 10.0.0.2:80
10.0.0.3:80 10.0.0.4:80
Pool Load Balancing Method: Round Robin Scenario 1: Virtual server without CMP enabled
Four connections are made to the virtual server. The BIG-IP system load balances the four individual connections to the four pool members based on the Round Robin load balancing algorithm:
--Connection 1--> | | --Connection 1--> 10.0.0.1:80 --Connection 2--> |-> BIG-IP Virtual Server ->| --Connection 2--> 10.0.0.2:80 --Connection 3--> | | --Connection 3--> 10.0.0.3:80 --Connection 4--> | | --Connection 4--> 10.0.0.4:80 Scenario 2: Virtual server with CMP enabled on a BIG-IP 8800
Four connections are made to the virtual server, unlike the first scenario where CMP was disabled, the BIG-IP distributes the connections across the multiple TMM processes.
The BIG-IP 8800 with CMP enabled can use four TMM processes. Since each TMM handles load balancing independently of the other TMM processes, it is possible that all four connections are directed to the same pool member.
--Connection 1--> | | --Connection 1--> TMM0 --> 10.0.0.1:80 --Connection 2--> |-> BIG-IP Virtual Server ->| --Connection 2--> TMM1 --> 10.0.0.1:80 --Connection 3--> | | --Connection 3--> TMM2 --> 10.0.0.1:80 --Connection 4--> | | --Connection 4--> TMM3 --> 10.0.0.1:80 The CMP feature is designed to speed up connection handling by distributing
connections across multiple TMM processes. While initially this behavior may appear to favor one or several servers, over time the load will be distributed equally across all servers.
1.16 - Explain the effect of OneConnect/MBLB on load balancing
Link to Online Topic Content
OneConnect
The BIG-IP OneConnect feature can increase network throughput by efficiently managing connections created between the BIG-IP system and back end nodes.
OneConnect allows the BIG-IP system to minimize the number of server-side TCP
connections by making existing idle connections available for reuse by other clients. The OneConnect source mask setting manages connection reuse, and is applied to the server-side source IP address of a request to determine its eligibility for connection reuse.
Overview of the OneConnect Mask
OneConnect applies a mask (much like applying an independent subnet mask) to client source IP addresses on server-side connections. This mask determines the availability of an existing idle TCP connection for the request on the selected destination server. The following list displays the idle TCP port reuse behavior. To simplify things, regarding these explanations, F5 assumes that a previous TCP request has established a
connection on the destination server, the connection is idle, and the same destination server has been selected for a subsequent client request.
OneConnect
Mask OneConnect masking behavior
255.255.255.255 The entire client IP address is evaluated. A request from the same address reuses an established idle TCP connection.
255.255.255.0 Octets 1-3 are evaluated client addresses matching this subset and reuse an existing idle TCP connection.
255.255.0.0 Client addresses are evaluated based on the first and second octets when selecting an idle TCP connection for reuse.
255.0.0.0 Only the first octet of a client IP address is evaluated when selecting an idle TCP connection for reuse.
0.0.0.0 The all zeros mask (the default setting) looks for any open idle TCP connection on the destination server. The main difference is OneConnect does not attempt to group the request based on octets matched, but uses open idle TCP connections in a highly efficient manner.
Effects of modifying the source mask
The following three scenarios describe the effects of using different source masks:
Using a OneConnect profile with a 0.0.0.0 source mask
A OneConnect profile with a source mask of 0.0.0.0 shares idle connections across all client requests in the following manner:
Client A with source IP address 10.10.10.10 connects to a virtual server.
The BIG-IP system load-balances the connection and applies the source mask to the request on the server-side flow, finds no suitable connection for reuse, and creates a TCP connection to server A in the pool.
Client B with source IP address 10.20.20.20 connects to the same virtual server.
The BIG-IP system load-balances the connection, applies the source mask to the server-side flow, and finds an eligible idle TCP connection.
The BIG-IP system aggregates the request from client B over the existing TCP connection created for client A.
Using a OneConnect profile with a 255.255.255.0 source mask
A OneConnect profile with a source mask of 255.255.255.0 aggregates connections from client IP addresses sharing the same last octet in the following manner:
Client A with a source IP address of 10.10.10.10 connects to a virtual server.
The BIG-IP system load-balances the connection and applies the source mask to the request on the server-side flow, finds no suitable connection for reuse, and creates a TCP connection to server A in the pool.
Client B with a source IP address of 10.10.10.100 connects to the same virtual server.
The BIG-IP system load-balances the connection, applies the source mask to the server-side flow, and finds an eligible idle TCP connection.
The BIG-IP system aggregates the request from client B over the existing TCP connection created for client A.
Client C with source IP address 10.10.20.10 connects to the same virtual server.
The BIG-IP system load-balances the connection, applies the source mask to the server-side flow, and finds no suitable connection for reuse.
The BIG-IP system creates a new TCP connection to the selected pool member.
Using a OneConnect profile with a 255.255.255.255 source mask
A OneConnect profile with a source mask of 255.255.255.255 will only aggregate connections originating from the same server-side client IP address.