To access the Service Engine group editor:

  1. Navigate to Infrastructure > Service Engine Group

  2. Click the pencil icon to edit a pre-existing SE group, or click the blue button to create a new one.

  3. Start your specification for the SE group by giving it a name (or accept the default name, which is Default-Group).

Real-Time Metrics

At the top right of the Basic Settings tab you can turn on real-time metrics, which causes SEs in the group to upload SE-related metrics to the Controller once every 5 seconds, as opposed to once per five minutes or longer. After clicking the box, select the duration in minutes for real-time updating to last. A value of 0 is interpreted to mean “forever.”

For more information on metrics, see metrics-upload intervals.

High Availability & Placement Settings

The high availability mode of the SE group controls the behavior of the SE group in the event of an SE failure. It also controls how the load is scaled across SEs. Selecting a particular HA mode will change the settings and options that are exposed in the UI. These modes span a spectrum, from the use of the fewest virtual machine resources on one end to providing the best high availability on the other.
Legacy HA Active/Standby Mode

This mode is primarily intended to mimic a legacy appliance load balancer for easy migration to NSX Advanced Load Balancer. Only two Service Engines might be created. For every active virtual service configured on one, a standby service is configured on the other to readily take over, in the event of a failure of the active SE. There is no Service Engine scale out in this HA mode.

Elastic HA N + M Mode

This default mode permits up to N active SEs to deliver virtual services, with the capacity equivalent of M SEs within the group ready to absorb SE failure(s).

Elastic HA Active/Active Mode

This HA mode distributes virtual services across a minimum of two SEs.

For additional considerations for SE high availability, including VS placement, see Overview of NSX Advanced Load Balancer High Availability.

VS Placement across SEs

When the placement is compact (previously referred to as “Compactor”), NSX Advanced Load Balancer prefers to spin up and fill up the minimum number of SEs; it tries to place virtual services on SEs which are already running. When the placement is distributed, NSX Advanced Load Balancer maximizes VS performance by avoiding placements on existing SEs. Instead, it places virtual services on newly spun-up SEs, up to the maximum number of Service Engines. By default, placement is compact for elastic HA N+M mode and legacy HA active/standby mode. By default, placement is distributed for elastic HA active/active mode.

Virtual Services per Service Engine

This parameter establishes the maximum number of virtual services the Controller cluster can place on any one of the SEs in the group.

Per-app SE mode

Select this option to deploy dedicated load balancers per application, i.e., per virtual service. In this mode, each SE is limited to a maximum of 2 virtual services. vCPUs in per-app SEs count towards licensing at a 25% rate.

SE Self-Election

Checking this option enables SEs in the group to elect a primary SE amongst themselves in the absence of connectivity to a Controller. This ensures SE high availability in handling client traffic even in headless mode. For more information, refer to the Service Engine Self Election article.

Service Engine Capacity and Limit Settings

Max Number of Service Engines

[Default = 10, range = 0-1000] Defines the maximum SEs that may be created within an SE group. This number, combined with the virtual services per SE setting, dictates the maximum number of virtual services that can be created within an SE group. If this limit is reached, it is possible new virtual services may not be able to be deployed and will show a gray, un-deployed status. This setting can be useful to prevent NSX Advanced Load Balancer from consuming too many virtual machines.

Memory per Service Engine

[Default = 2 GB, min = 1 GB] Enter the amount of RAM, in multiples of 1024 MB, to allocate to all new SEs. Changes to this field will only affect newly-created SEs. Allocating more memory to an SE will allow larger HTTP cache sizes, more concurrent TCP connections, better protection against certain DDoS attacks, and increased storage of un-indexed logs. This option is only applicable in write access mode deployments.

Memory Reserve

[Default is ON] Reserving memory ensures an SE will not have contention issues with over-provisioned host hardware. Reserving memory makes that memory unavailable for use by another virtual machine, even when the virtual machine that reserved those resources is powered down. NSX Advanced Load Balancer strongly recommends reserving memory, as memory contention may randomly overwrite part of the SE memory, destabilizing the system. This option is applicable only for deployments in write access mode. For deployments in read access mode deployments or no access mode, memory reservation for the SE VM must be configured on the virtualization orchestrator.

vCPU per Service Engine

[Default = 1, range = 1-64] Enter the number of virtual CPU cores to allocate to new SEs. Changes to this setting do not affect existing SEs. This option is only applicable in write access mode. Adding CPU capacity will help with computationally expensive tasks, such as SSL processing or HTTP compression.

CPU Reserve

[Default is OFF] Reserving CPU capacity with a virtualization orchestrator ensures an SE will not have issues with over-provisioned host hardware. Reserving CPU cores makes those cores unavailable for use by another virtual machine, even when the virtual machine that reserved those resources is powered down. This option is only applicable in write access mode deployments.

Disk per Service Engine

[min = 10 GB] Specify an integral number of GB of the disk to allocate to all new SEs. This option is only applicable in write access mode deployments. The value appearing in the window is either:

  • 10 GB (the absolute minimum allowed), or

  • a value auto-calculated by the UI as follows: 5 GB + 2 x memory-per-SE, or

  • a number explicitly keyed in by the user (values less than 5 GB + 2 x memory-per-SE will be rejected)

Host Geo Profile

[Default is OFF] Enabling this provides extra configuration memory to support a large geo DB configuration.

Connection Memory Percentage

The percentage of memory reserved to maintain connection state. It comes at the expense of memory used for HTTP in-memory cache. Sliding the bar causes the percentage devoted to the connection state to range between its limits, 10% minimum and 90% maximum.

For information on hyper-threading modes, refer to Hyper-Threading Modes.

Datapath Heartbeat and IPC Encap Configuration

In NSX Advanced Load Balancer version 20.1.3, the following datapath heartbeat and IPC encap config knobs are moved to the segroup:

  • dp_hb_frequency

  • dp_hb_timeout_count

  • dp_aggressive_hb_frequency

  • dp_aggressive_hb_timeout_count

  • se_ip_encap_ipc

  • se_l3_encap_ipc

The seproperties based APIs for these config knobs will only work for the NSX Advanced Load Balancer version prior to 20.1.3 and they will not take any effect from 20.1.3 onwards. Likewise, SE group based APIs for these config knobs will take effect starting from NSX Advanced Load Balancer version 20.1.3.

However, upgrade from pre-20.1.3 seproperties based configuration to 20.1.3 will automatically migrate the config to segroup as a part of the upgrade migration routine.


License Tier

Specifies the license tier to be used by new SE groups. By default, this field inherits the value from the system configuration.

License Type

If no license type is specified, NSX Advanced Load Balancer applies default license enforcement for the cloud type. The default mappings are maxed SEs for a container cloud, cores for OpenStack and VMware, and sockets for Linux.

Instance Flavor

Instance type is an AWS term. In a cloud deployment, this parameter identifies one of a set of AWS EC2 instance types. The flavor is the analogous OpenStack term. Other clouds (especially public clouds) may have their terminology for essentially the same thing.