This section illustrates examples of executing common management tasks with the NSX Advanced Load Balancer CLI.
CLI: Virtual Service and Pool Creation
During virtual service creation, a pool must be configured. This pool has to be created before creating the virtual service.
Create the following using the CLI:
The Pool
The VsVIP
The Virtual Service
The examples below shows only the minimum configuration required to successfully deploy a new application. Many additional options are available for customizing virtual services and pools.
Create the Pool
: > configure pool Test : pool> servers ip 10.1.1.100 port 80 : pool:servers> save : pool> servers ip 10.1.1.101 port 80 : pool:servers> save : pool> where Tenant: admin +------------+------------+ | Field | Value | +------------+------------+ | name | Test | | servers[1] | | | ip | 10.1.1.100 | | port | 80 | | servers[2] | | | ip | 10.1.1.101 | | port | 80 | +------------+------------+ : pool> save
Create the VsVIP
: > configure vsvip Test_vsVip : vsvip> vip ip_address 10.10.10.10 : vsvip:vip> save : vsvip> save
Create the Virtual Service
: > configure virtualservice Test_VS : virtualservice> vsvip_ref Test_vsVip : virtualservice> pool_ref Test : virtualservice> services port 80 : virtualservice:services> save : virtualservice> save
Modify Pool Servers
A common task is to add and remove servers from an existing pool or to activate or deactivate servers within the pool. While servers can be added to a pool without specifying a port (they will inherit the port of the pool or virtual service), the CLI requires the IP and port to manipulate the server for tasks such as enable and disable.
The following commands will delete the .101 server and add a new .102 server to the pool named Test.
configure pool Test no servers ip 10.1.1.101 port 80 servers ip 10.1.1.102 port 80 [admin]: pool:servers save
The following commands will enter the sub-mode for the .100 server and disable it.
ip 10.1.1.100 port 80 where Tenant: admin +-------+------------+ | Field | Value | +-------+------------+ | ip | 10.1.1.100 | | port | 80 | +-------+------------+ no enabled +---------+------------+ | Field | Value | +---------+------------+ | ip | 10.1.1.100 | | port | 80 | | enabled | False | +---------+------------+ save
Export / Import Configuration
The NSX Advanced Load Balancer Controller has a database to store its configuration information. This includes all configurations related to tenants, virtual services, pools, policies, and accounts. Export this configuration as a JSON file for backup or to migrate parts of the config to another NSX Advanced Load Balancer Controller.
The configuration may be backed up or moved to another Controller cluster through the CLI. The exported configuration might be the entire system configuration, a more limited version based on the access rights of the current user and tenant of the administrator, or a single virtual service and its child properties.
To export only a single virtual service and its child objects, such as pools, use the virtualservice flag instead of the configuration flag with the export command.
The following commands will export the configuration to a file named config_export, SCP it to a remote location, and then return it to the NSX Advanced Load Balancer shell.
export configuration file config_export Completed writing the export configuration to config_export bash pwd /home/admin ls config_export scp ./config_export [email protected]:/root [email protected]'s password: config_export 100% 232KB 431.8KB/s 00:00 exit
Before starting a configuration import:
- Ensure that all Controller members of the cluster are up and the cluster leader has the following configuration:
-
Admin Account
-
Cluster Configuration
-
OpenStack Infrastructure (OpenStack only)
-
- Edit the configuration file and remove the _last_modified field.
The following commands will import a backed-up configuration to a Controller cluster.
import configuration file /home/admin/myconfig keep_uuid Successfully imported the configuration file
You can restore this configuration information to an empty NSX Advanced Load Balancer Controller. The restoration steps are:
Deploy three new Controller nodes; the image type (OVA, qcow2, ami) should match that of the original Controller node from which the configuration was exported.
Choose one Controller as the leader and go through the initial setup page to enter the initial setup information and the redundant Controller cluster information.
Use the CLI or API to import the configuration.
After these steps, the cluster will return to the same running state as the original one.
Export Configuration Filters
You can also tune the exported file by using filters. The following filters are supported:
Filter Name |
Description |
|---|---|
full_system |
Exports the complete configuration (including persistent runtime) in the format documented in Restore Configuration. This configuration cannot be imported through the CLI or the REST API. |
obj_type |
Limits exported objects to a specific set of object types. |
recurse |
Exports the entire tree of dependencies (including some runtime) for objects in filtered config. |
passphrase |
Encrypts sensitive data. The same passphrase must be provided to import the configuration. |
search |
Only exports objects that contain a certain string. |
skip_default |
Prunes defaulted values of objects in exported configuration. |
tenant_ref |
Only exports objects in the specified tenant. |
Examples
To export all virtual services and dependencies, use the following command:
export configuration file config\_export obj\_type virtualservice recurse
To export all objects in tenant t1 and filter out defaulted values, use the following command:
export configuration file config\_export tenant\_ref t1 skip\_default
Packet Capture
The NSX Advanced Load Balancer Controller provides a convenient mechanism to capture data plane traffic processed by SEs. An administrator can initiate a capture command from the Controller CLI while the actual capture occurs on the SEs. The packet capture is saved in pcap format on the Controller. The SE captures packets on both the client-side and server-side of the SE. If a virtual service is scaled across multiple SEs, then all applicable SEs will participate in the packet capture. The Controller will aggregate the captures and sort the entries according to time. Once a capture is complete, it is uploaded to a personal computer or other systems for analysis with an appropriate tool such as tcpdump or Wireshark.
Enter the packet capture sub-mode for the specified virtual service:
debug virtualservice Test-VS Updating an existing object. Currently, the object is: +-------+--------------------+ | Field | Value | +-------+--------------------+ | uuid | virtualservice-0-1 | | name | Test-VS | +-------+--------------------+
Parameters may be defined for the packet capture. By default, the capture is performed within the context of the selected virtual service, and it is also performed on all SEs handling the virtual service traffic, including the packets from the client and server sides.
Parameter Name |
Description |
|---|---|
capture_params duration |
Time, in minutes. Default is unlimited. |
capture_params num_pkts |
Maximum number of packets to collect. Default is unlimited. |
capture_params pkt_size |
Packet size, or snap length, to capture. Default is unlimited. |
debug_ip addrs |
IP4 Address format <x.x.x.x> |
debug_ip prefixes |
IP4 Prefix format <x.x.x.x/x> |
By default, no maximum packets, or duration of time to be captured are defined. It is recommended to include a maximum packet capture, as shown in the following example. Without a limit, the capture will run until the SE disk is filled, potentially disrupting the service.
Specify parameters, including the maximum number of packets to capture:
capture_params num_pkts 1000 debug_ip addrs 10.10.10.10 save
Begin capturing based on the previously configured parameters:
capture save +----------------+--------------------+ | Field | Value | +----------------+--------------------+ | uuid | virtualservice-0-1 | | name | Test-VS | | debug_ip | | | addrs[1] | 10.10.10.10 | | capture | True | | capture_params | | | duration | 0 mins | | num_pkts | 1000 | +----------------+--------------------+
Re-enter the packet capture sub-mode and stop an ongoing packet capture:
debug virtualservice Test-VS no capture save
Export the packet capture to a remote system to view it using tools such as tcpdump or Wireshark:
show debug virtualservice Test-VS capture Please specify the destination directory: /tmp Downloaded the attachment to /tmp/vs_virtualservice.20141205_192033.pcap bash scp /tmp/vs_virtualservice.192033.pcap [email protected]:/tmp
Monitor Concurrent Connections to a Server
To track the number of concurrent connections to a server, the server must be viewed within the context of a pool. By prepending the watch command in front of the show, it is possible to see a near real-time updates of the connection count. Keep in mind there is some delay between the time the connection is established and the polling interval when the SE sends information back to the Controller. Cancel the watch with Ctrl+C.
watch show pool Test-pool server detail | grep -e 'ip\|open_conns' | ip_addr | 10.1.1.17 | | open_conns | 50 | | ip_addr | 10.1.1.16 | | open_conns | 49 |
