NSX Native Load Balancer vs BIG IP Load Balancer

[rajeevsrikant]

NSX has it own native load balancer functionality & it can also be integrated with 3rd party load balancer like BIG IP.

Is there any comparison between these 2 types in terms of features & functionality.

I need to know the technical comparison between these 2 solutions to judge which is the ideal load balancer to choose from.

[bayupw]

In case you haven't read this, there's a guide on NSX deployment with F5 here: NSX F5 Design Guide v1.6.pdf‌

NSX LB features is listed here VMware NSX for vSphere 6.2 Documentation Center - Load Balancing

Based on my experiences on migrating F5 BIG-IP to NSX LB, common LB functionality can be fulfilled by NSX.

Once it comes to advanced load balancing, advanced health checks, this will need to be reviewed one by one, case by case

Especially when using advanced/very complex F5 iRules for example an iRule that needs to check a file that has a list of array which stored in the BIG-IP, etc

Or maybe some advanced health check that need to run a script that is also stored in the BIG-IP.

There's a good doc here NSX-6.2 - LB configuration examples that provides some samples covering basic & advanced health checks, basic & advanced L4/L7 load balancing, and some application rules using HAProxy rules/ACLs

Do you have any list of LB features & functionality that you are looking for?

[rajeevsrikant]

Thanks Bayu

I am in phase of designing the NSX LB deployment in our environment.

We have physical load balancers (BIG IP LTM) which we would like to replace with NSX LB.

I am in phase of collecting what features are enabled in BIG IP LTM so that i can check if those are available with NSX LB.

Also in parallel i am trying to find out what features in NSX LB is lacking from the features offered by BIG IP LTM.

[RaymundoEC]

Hi there sir,

IHO is evident that BIG IP will have lots of features more than NSX LB, nevertheless from design perspective BIG IP is used for more specific requirements and for big demand on performance, NSX LB just works and works fine so one big difference could be that you don't have to pay for having any number of ESG in LB mode, and you can satisfy most of applications LB requirements as well as demand on consumption , scale and future grows.

there is a LB session open to everyone and it is on youtube as well

VMworld 2016 USA

NET9029

NET5612

also check this document: https://f5.com/Portals/1/Premium/Architectures/RA-VMware-NSX-Design-Guide.pdf

this can help you to build a technical contex from NL perspective.

hope this helps.

[rajeevsrikant]

I was comparing the features what we have enabled in our F5 load balancer and checking if the same is available with NSX load balancer.

Below are the items which I need to compare

BIG IP (Virtual Server) - Connection Mirror, Loose Initiation/Close and FastL4

I found that FastL4 is supported in NSX load balancer.

What about Connection Mirro and Loose Initiation/Close. Are they supported in NSX LB

If so could you please share the document or link relevant to this.

[Dimitri Desmidt]

Connection Mirror:

NSX-Edge-LB doesn't support connection mirror (only persistence mirror).

In other words, in the unlikely case of Edge failure (or ESXi failure) clients accessing the VIP will have to re-establish new connections.

Note: The backend server persistence is synched between NSX-Edge-LB active/standby so in case of persistence configured, clients new connections will go to the same backend servers used previously.

Loose Initiation/Close Initiation:

NSX-Edge-LB doesn't support Loose Initiation/Close Initiation

But do you really have:

. Loose: Need on the load balancer to load balance new sessions even in case the first packet seen is NOT TCP SYN (what TCP application do you have not doing a proper TCP SYN handshake?)

. Close: Need on the load balancer to flush LB sessions after seeing the first TCP FIN packet (instead of the full FIN handshake)?

FastL4

If your definition of K5 FastL4 is: "load balancer with higher performance for applications that don't require HTTP/HTTPS load balancing"

Then I agree NSX-Edge-LB has also that with Acceleration Enabled.

Dimitri

[rajeevsrikant]

NSX-Edge-LB doesn't support connection mirror (only persistence mirror).

In other words, in the unlikely case of Edge failure (or ESXi failure) clients accessing the VIP will have to re-establish new connections.

Note: The backend server persistence is synched between NSX-Edge-LB active/standby so in case of persistence configured, clients new connections will go to the same backend servers used previously.

- From the above explanation it looks that both connection mirror & persistence mirror behavior looks the same. Not able to clearly understand the difference.

Is there any documentation from VMware explaining this.

[rajeevsrikant]

Correct me if my understanding is wrong.

BIG IP Supports both connection mirror and persistence mirror.

NSX supports only persistence mirror.

Connection Mirror - The existing connections/sessions on the Active Device is mirrored in the standby device. In case of active device failure the connections/sessions are maintained in the standby device. No session disconnection and the user does not require to re-establish the connection.

But the connection can land on any of the servers in the pool. (since persistence mirror not enabled). If persistence mirror is enabled it will land on the same member pool.

Persistence Mirror - In case of active device failure the connections/sessions are lost and new session needs to be established.

But the connection will land on the same member pool server.

Let me know if my above understanding is right.

[Dimitri Desmidt]

You're 100% right :smileyhappy:

[rajeevsrikant]

thanx

is there any reference document from VMware which explains this.

If so please share the same.....

[Dimitri Desmidt]

We don't clearly say "LB Persistence table is synched" in our Admin Guide.

However we say in the HA section:

NSX Edge HA synchronizes the connection tracker of the statefull firewall, or the statefull information held by the load balancer.

Dimitri