This section lists the steps to install NSX Advanced Load Balancer into an OpenStack cloud if NSX Advanced Load Balancer has no access to OpenStack, the orchestrator.

In No-Access mode, NSX Advanced Load Balancer has no access to OpenStack as an orchestrator. Only the administrator can add, remove, or modify the properties of a Service Engine manually. Servers and networks cannot be auto-discovered by NSX Advanced Load Balancer; they must be manually configured.

The following are the steps to install NSX Advanced Load Balancer in No-Access OpenStack cloud:

Prerequisites

NSX Advanced Load Balancer must be instantiated in the No-Orchestration mode.

Procedure

  1. Navigate to Infrastructure > Clouds to create an OpenStack No-Access cloud.
  2. Select the IP address management as Use IPv4 DHCP or Use IPv6 DHCP bu checking the relevant checkboxes in DHCP section.


  3. Download SE qcow2 image, as this will be pushed to Glance.


  4. Log in to the OpenStack instance under the respective tenant ('admin' in this case) and navigate to Project > Compute > Images. Click Create Image. Select QCOW2 option from Format drop-down list and provide the image file for the SE QCOW2 that was downloaded.


  5. Upload the se.qcow2 image to Glance.


    • This is needed only if there is no existing network that can be used as the NSX Advanced Load Balancer network.

    • This network will be used by SEs to communicate with the Controller. Therefore, either create a new network or use an existing network and ensure that virtual machines created on that network can reach the Controller.

  6. Navigate to Project > Network > Networks to create avimgmt network. Specify the network name in Network tab. Also provide appropriate subnet to the network in Subnet tab. This creates a subnet associated with the network.Specify the valid Network Address and Gateway IP. If Gateway IP is not specified, the first value of a network will be assigned by default. Check Disable Gateway box to disable gateway IP. Advanced configuration details can be specified in the Subnet Details tab.

    • This step is required only if a new external network needs to be created. Create the network that will be the outbound network and will provide floating IP access. For instance, you can provide the Network Name as provider1 in Network tab and provide the other details in the respective tabs.

    • This step is required only if a new router needs to be created for an external connectivity. You can create a router by providing the router name, admin state and external network details.

  7. Create a router by navigating to Project > Network > Routers. Click Create Router.


  8. Additionally, you can deploy a web server in the avimgmt network to do tests. This can be a server of an OS type, for instance, the network topology look something like this:
  9. Create a security group by navigating to Project > Network > Security Groups and associate it with the Service Engine to make sure that ICMP traffic and SSH and HTTP traffic is allowed.
  10. Create an NSX Advanced Load Balancer SE Instance by navigating to Projects > Compute > Instances. Click Launch Instance. SEs can be created using heat-templates as well. For more information on this, see Creating Service Engine using Heat-Templates in No-Access OpenStack Cloud.
  11. Select the appropriate qcow2 image for the SE that needs to be instantiated from the Source tab.
  12. Select the respective flavor for the SE from the Flavor tab. In this case it will be m1.small.
  13. Select the avimgmt network from the Networks tab for instantiating the SE.
  14. The SE gets spawned.
  15. Associate a floating IP to the instance. This step is required only where SEs are not reachable directly.
  16. Attach another interface to the SE. For instance, the data vNIC.
  17. The SE gets created with one management vNIC and one data vNIC, the latter associated with a floating IP.


    • For the SE to connect to the Controller, copy the token for the SE from NSX Advanced Load Balancer UI (outlined in Installing NSX Advanced Load Balancer for VMware vCenter section) for the respective cloud and run the script at /opt/avi/scripts/init_system.py on the SE, which will then ask for the Controller IP and the token (the token expires in 60 minutes and is for a single SE). You need root access privileges to run this script.

      root@Avi-Service-Engine:/opt/avi/scripts# ./init_system.py -h
usage: init_system.py [-h] -c CONTROLLER [-d] [-i MGMT_IP] [-m MGMT_MASK]
[-g GATEWAY] [-t TOKEN] [-r]
optional arguments:
-h, --help show this help message and exit
-c CONTROLLER, --controller CONTROLLER
Controller IP address.
-d, --dhcp DHCP
-i MGMT_IP, --mgmt-ip MGMT_IP
IP address for Management Interface (eg.
192.168.10.10)
-m MGMT_MASK, --mgmt-mask MGMT_MASK
Subnet mask for Management interface (eg. 24 or
255.255.255.0)
-g GATEWAY, --gateway GATEWAY
Default gateway
-t TOKEN, --token TOKEN
Auth token generated in the Controller for this SE
-r, --restart Restart SE for changes to take effect
root@Avi-Service-Engine:/opt/avi/scripts# ./init_system.py -c 172.16.0.10 -d -i 172.16.0.7 -m 255.255.255.0 -g 172.16.0.1 -t c708a2cd-69e2-4057-923d-a09de94914f6 -r

      Reboot the SE for it to connect to the Controller.

  18. Wait for the NSX Advanced Load Balancer SEs to show up in the UI's Infrastructure > Cloud Resources > Service Engine list under the respective cloud.
  19. Edit each SE and enable DHCP for each data network.


  20. Create a virtual service and choose an IP address from the data network.

    Since this is a no-Access cloud, you cannot configure a 'floating VIP' in the virtual service configuration. For the Controller to communicate with OpenStack Nova to assign an allocated floating IP to virtual IP address, you need to create a binding association as shown below through the CLI for the Neutron port with the VIP.

    If you need a floating IP for the VIP address, create a port in the network where the VIP address lies.

    $> neutron port-create --fixed-ip subnet_id=subnet ID of the network in which VIP is placed,ip_address=VIP IP --name anyname network ID in which the VIP is being placed

    An example for the above syntax is as follows:

    $> neutron port-create --fixed-ip subnet_id=55daee6b-32b7-4f9c-945e-bcd2acb7272f,ip_address=172.16.0.231 --name test200vip f14eb427-4087-4dce-8477-479e10804ba1

    Create a floating IP and associate it with that VIP address.

    $> neutron floatingip-associate bf7c870e-6608-4512-b73d-faab5b18af04 ff67ae44-9874-43e6-a194-f336b9b1d7b5


  21. Create a pool of server(s) to be associated with the virtual service created above. In this case, this will be the server created using the Horizon UI in step 16.




    You cannot use the select-servers-by-network feature, as you do not have access to the infra manager. Therefore, specify the IP addresses manually.

  22. The virtual service should be up and running as shown below:


  23. Check the respective Service Engine to verify that the VIP is associated with it.


    • The allowed-address-pairs Neutron extension allows traffic with specific CIDRs to egress from a port. NSX Advanced Load Balancer uses this extension to place VIPs on SE data ports, thereby allowing VIP traffic to egress these data ports.

    • Add allowed-address-pairs on the SE ports so that security groups do not drop the packets. For the ML2/ OVS plug-in, you can add allowed-address-pairs with 0.0.0.0/0 once for each of the SE ports or specific VIP IP address.

      neutron port-update da0e1e9a-312d-41c2-b15f-f10ac344ef03 --allowed-address-pairs type=dict list=true ip_address=192.168.1.222/32

    • If True, the allowed-address-pairs extension will be used. If the underlying network plug-in does not support this feature, then VIP traffic will not work unless there are other means to achieve the same effect. This option can be turned off if the underlying network supports turning off security/ firewall/ spoof filter rules on ports.

    • In cases where port-security is available, you can deactivate port-security on the SE's data vNIC Neutron port. This is another alternative for above. Make sure that you can SSH into one of the instances (Service Engines) as can be seen below:



  24. Optional: If use of NSX Advanced Load Balancer IPAM is required, then the same can be done by creating an IPAM network, IPAM template and associate the same to the cloud, and hence the auto-allocation of the IPs for the VIP can take place.