Installing Avi Vantage for OpenStack

This guide describes how Avi Vantage integrates into an OpenStack cloud and includes Avi UI installation steps for a variety of deployment modes.

Introduction

Avi Vantage is a software-based solution that provides real-time analytics as well as elastic application delivery services. Avi Vantage optimizes core web-site functions including SSL termination and load balancing. Avi Vantage also provides access to network analytics, including end-to-end latency information for traffic between end-users and the load-balanced applications.

Avi Vantage’s unique controller-based architecture with integration into virtual infrastructure and cloud orchestrators enables true automated horizontal scaling where data plane capacity expands and contracts dynamically based on workload. When deployed into an OpenStack cloud, Avi Vantage performs as a fully distributed, virtualized system consisting of the Avi Controller and Avi Service Engines (SEs), each running as a separate virtual machine (VM).

  • Avi Controller: VM that acts as a single point of control and management with OpenStack and is integrated with Nova, Keystone, Neutron, and Glance to allow seamless multitenancy support for scalable performance. Based on configuration, the Controller places new services on existing VMs if there is room, or spins up a new VM if needed. The Controller deploys an SE VM as needed when a tenant creates a virtual service or VIP for load balancing. Management access and analytics are provided through a web-based interface and REST-based API. The Controller manages the life cycles of the SEs by creating, controlling, and eventually deleting them. The Controller stores and manages all policies related to services and management. The Controller also provides a central point of contact for other cloud infrastructures, and can manage resources in multiple infrastructures simultaneously. For example, the Controller can be configured to communicate with both an OpenStack controller and a VMware vCenter server, to manage resources in each type of cloud.

  • Avi Service Engine (SE): VM that receives the end-user traffic and provides application delivery services, while also collecting real-time end-to-end metrics for traffic between end-users and applications. The Controller creates an SE VM, plumbs it into a network, and provisions it with a service policy. The service policy is required to deploy a virtual service (VS), which consists of IP address and TCP/UDP port number that together represent a load-balanced service.

OpenStack Integration

Avi Vantage integrates with OpenStack infrastructure components to provide centralized automation, monitoring, and management of application discovery and delivery.

Avi Vantage integrates with the following OpenStack services:

  • Keystone: Avi Controller uses Keystone API to authenticate any OpenStack user accessing Avi API. Also, when an OpenStack user logs in, Avi Controller can also automatically import tenant/project and role information from Keystone to provide appropriate privileges on Avi Controller.
  • Glance: Avi Controller uses Glance for storing service engine (Avi SE) image.
  • Nova: Avi Controller uses Nova API to automatically create and destroy application delivery service engines (Avi SEs) as needed to support high availability and performance guarantees.
  • Neutron: Avi Controller uses Neutron API to plug service engines into right Neutron networks for receiving and sending the application traffic.
  • Neutron LBaaS (v1 or v2): Users can either use Avi Controller API (or UI or CLI) to directly configure load balancer instances. Optionally, the OpenStack admins can install Avi LBaaS driver on the Neutron API servers and enable Avi as a provider for Neutron LBaaS API.Note for Avi Vantage 17.1.x installations; If any pre-17.1.x versions of the Neutron-LBaaS Avi driver were installed, then installing or upgrading to Avi-Vantage 17.1.x requires upgrading the corresponding Avi driver to the 17.1.x version as well. Earlier versions of the Avi driver are incompatible with Avi-Vantage 17.1.x.
  • Horizon: OpenStack admins can optionally install Avi Horizon Dashboard extensions to expose full Avi UI directly embedded in Horizon Dashboard. Users can then not only configure load balancer instances but can also access the full analytics of their applications.
  • Heat: OpenStack admins can optionally install Avi Heat package on the Heat Engine servers to expose all Avi Controller API resource types for users to use in their heat templates. In contrast to LBaaS (v1 or v2) resource types, Avi Heat resource types expose significantly advanced features.

Here is how Avi Vantage integrates into an OpenStack cloud:

Port Security and Allowed Address Pairs (AAP)

Neutron’s security group always applies anti-spoof rules to the VMs. This allows traffic to originate from and terminate at the VM as expected, but prevents traffic from passing through the VM. This is required in cases where the VM routes traffic through it. To run network services in VM instances (e.g., router service in VM [router_plugin_cisco], [vyatta_l3_plugin] or firewall service in VM), it is required by some services for VMs to be able to receive/send all packets without any kind of firewall, security group, or anti-spoofing on the port. This is a basic requirement to run network service within VMs. Services requiring it or not, depending on the type of service.

The port_security_enabled of network is used as the default attribute value at port creation. When the attribute is set to True (by default), the behavior remains same to the one without portsecurity extension, security group and anti spoofing will act as before. When the attribute is set to False, security group and anti spoofing are disabled on the port, and it is not allowed to set security group or allowedaddresspair with such ports. Since this feature is related to security, only the tenant owner is allowed to set/change the attribute.

Avi Vantage Support for Port Security

Handle port-security and allowed-address-pair (AAP) settings appropriately for the SE and Controller ports. If port-security is enabled, the ports are used in AAP mode. If port-security is disabled, the Controller ports are untouched, and the SE ports are created with security disabled.

Set port-security to False by default. Don’t use it unless explicitly requested by the configuration.

Deployment Modes

Avi Vantage can be deployed into an OpenStack cloud in one of the following modes. These modes differ depending on whether the Avi Controller and Service Engines (SEs) are placed in the same OpenStack tenant, and whether Neutron LBaaS API or Avi Vantage API is used to create load balancers.

  • Single-tenant mode: The Avi Controller and the SEs are deployed together in the same single tenant. The Avi Controller has administrator privileges within the tenant. Tenant users who have administrator privileges within the tenant can install and manage Avi Vantage. (You must use this deployment mode if you do not have administrator privileges for the cloud.)
  • Avi-managed LBaaS mode: The Avi Controller and SEs are installed in separate tenants. The Controller has administrator privileges for the cloud and can manage SEs that are in different tenants. A tenant administrator can log onto the Avi Controller to manage the infrastructure resources within her or his own tenant but cannot access the resources within other tenants. The tenant administrator can configure and manage load balancing services through the Avi Controller web interface or through the Avi REST API.
  • OpenStack-managed LBaaS mode: Similar to Avi-managed LBaaS mode, except the tenant administrator configures and manages load-balancing services through OpenStack’s Neutron service and Horizon dashboard. Neither the Controller web interface nor Avi API are used. (This mode also requires installation of an LBaaS driver and SSL extension from Avi Networks.)

Note: The Avi-managed LBaaS option is recommended for its ease of use and advanced feature accessibility.

The following table compares each deployment mode:

Single-tenant Mode Avi-managed LBaaS Mode OpenStack-managed LBaaS Mode
Administrator privileges for cloud required No Yes Yes
Managed by tenant user No Yes Yes
Automated tenant creation N/A Yes Yes
Advanced load-balancing features Yes Yes Limited
Analytics service Yes Yes Yes
Avi LBaaS driver install required No No Yes
Avi extension for Horizon dashboard required No No Yes (required for SSL offload and analytics)

Deployment Prerequisites

The physical and software requirements differ depending on the deployment mode.

Virtual Machine Requirements

The following table lists the minimum requirements for the VMs on which the Avi Controller and SEs are installed.

Component Memory vCPUs HD
Avi Controller 24 GB 8 64 GB
Service Engine 2 GB 2 10 GB

Add 3 GB for each additional vCPU in a Controller. Add 1 GB for each additional vCPU in an SE.

If you allocate more than the minimum number of vCPUs required, make sure to also allocate at least the minimum required additional memory. Cloud administrators can create multiple flavors of the Avi Vantage Controller image with different resource allocations (for example, “avi_ctrl.small” with the minimum required resources, and “avi_se.medium” with more resources).

Software Requirements

The following table lists the software requirements.

Software Version
Avi Controller 17.2
OpenStack (and Neutron service) One of the following: Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton
Neutron extension for allowed-address-pair and/or port-security
Avi LBaaS driver 17.2
Avi SSL extension for OpenStack Horizon 17.2

The Avi Vantage image is available as a QCOW2 or raw image of the Controller and SEs. The SE software is embedded in the Controller image and does require separate installation.

The Avi LBaaS driver is required only for OpenStack-managed LBaaS mode. The SSL extension for OpenStack Horizon is required only for OpenStack-managed LBaaS mode. (This driver adds tabs to Horizon for accessing the Controller.)

Note: Installation of Avi Vantage into DevStack is supported only if the DevStack/Nova-launched Virtual Machine (VMs) can run in Kernel-based Virtual Machine (KVM) mode, as opposed to Quick Emulator (QEMU) mode. Please see the DevStack KVM Guide for information.

Protocol Ports Used by Avi Vantage for Management Communication

In an OpenStack deployment, the Avi Controller and Avi Service Engines use the following ports for management. The firewall should allow traffic for these ports.

Traffic Source Traffic Destination Ports To Allow
Avi Controller Avi Controller TCP 22 (SSH)
TCP 443
TCP 8443
TCP 5054
Avi Service Engine TCP 22
Management Net See section below the table.
Avi Service Engine Avi Controller TCP 22
TCP 8443
UDP 123
Management Net TCP 22
TCP 80 (optional)
TCP 443
TCP 5054 (if using the optional CLI shell for remote management access)

Ports Used by Controller for Network Services

The Controller may send traffic to the following UDP ports as part of network operation:

  • TCP 25 (SMTP)
  • UDP 53 (DNS)
  • UDP 123 (NTP)
  • UDP 162 (SNMP traps)
  • UDP 514 (syslog)

The firewall also should allow traffic from the Controller to these ports.

Importing User Accounts from Keystone

Using the Avi REST API, user roles can be exported from Keystone into the Avi Controller and directly mapped to role names in the Controller. The accounts do not need to be recreated on the Controller. Here is an example:

"openstack_configuration":
{
    ....
    "role_mapping": [
       {"os_role": "admin",
        "avi_role": "Tenant-Admin"},
       {"os_role": "_member_",
        "avi_role": "Tenant-Admin"},
       {"os_role": "*",
        "avi_role": "Application-Operator"}
    ],
    ....
}

The role_mapping parameter is an ordered list, where each item specifies how a Keystone role (os_role) maps to a role in the Controller (avi_role). A default mapping can be defined for any Keystone role by specifying the “ /* ” wildcard for the os_role field. In the above example, roles admin and member from Keystone are mapped to the role Tenant-Admin in the Controller. Further, any other role from Keystone is mapped to role Application-Operator on the Controller.

In the following example, only users with role lbaas_project_admin are allowed to access the Controller:

"openstack_configuration":
{
    ....
    "role_mapping": [
       {"os_role": "lbaas_project_admin",
        "avi_role": "Tenant-Admin"}
    ],
    ....
}

Metadata Instead of config_drive for Avi SEs

In some OpenStack environments, “config_drive” support is either absent or not installed well. Also, sometimes customers prefer that Avi SEs not use config_drive, since using it to configure the VM might prevent SE migration under certain conditions.

Starting in Avi Vantage release 16.2, a new Avi Vantage OpenStack configuration option uses metadata instead of config_drive for SE VMs. To have Avi Vantage use metadata, disable “config_drive.” At this point, this can be done only via the CLI or the REST API:

CLI Example


: > configure cloud Default-Cloud
: cloud> openstack_configuration
: cloud:openstack_configuration> no config_drive
: cloud:openstack_configuration> save
: cloud> save

Deploying Single-tenant Mode

This section provides the steps for deploying Avi Vantage into an OpenStack cloud in single-tenant mode.

OpenStack-deploy-topo-tenantmode

In single-tenant mode, the Avi Controller and SEs are installed in the same tenant, and have member privileges for that tenant. The member privilege grants the Avi Controller full access to the tenant so that it can automatically spin-up and spin-down an SE. Each tenant is responsible for installing and operating Avi Vantage.

Deployment Process

Single-tenant installation requires the following procedure.

  1. Add the Avi Controller QCOW2 or raw image into the tenant from Glance.
  2. Create a management network for the Avi Controller and SEs.
  3. Create a security group.
  4. Deploy an Avi Controller instance and assign a floating IP address to it.
  5. Create a security group to allow Avi management traffic.
  6. Use the setup wizard to perform initial configuration of the Controller.

Detailed steps are provided below.

Upload Controller Image

  1. Copy the Avi Vantage Controller image onto your hard drive.
  2. Log into the OpenStack tenant account on the Horizon dashboard.
  3. Navigate to Project > Images.
  4. Click Create Image and fill out the form.

Create Management Network

A management network is required for communication between the Avi Controller and the SEs. An existing network can be used but a dedicated management network is recommended.

  1. On the Horizon Dashboard, navigate to Network > Networks.
  2. Click Create Network and follow the wizard's instructions. For this example:
    • Network name: avi-mgmt
    • DHCP: Enabled
  3. Connect the network to your neutron router.
    a. Navigate to Network > Routers.
    b. On the Name column in the router list, click the router to add an interface to the network.
    c. Click the Interfaces tab, then click Add Interface.

Create Security Group

A security group is required to allow the Controller and SEs to exchange management traffic. The group specifies the protocol ports for which traffic will be allowed.

  • For ingress traffic, the group must allow these ports.
  • For egress traffic, the group can allow all ports.

Note: The Controller automatically creates a security group for the SEs.

To create a security group (in this example, “Avi-mgmt-sg”) to allow management traffic:

  1. On the Horizon Dashboard, navigate to Project > Access & Security, and click Create Security Groups.
  2. Add rules as shown in the following example, where 192.168.10.0/24 is the management network.
    openstack-portgroup-excerpt

Deploy Controller and Assign It a Floating IP

Deploy an Avi Controller instance:

  • Flavor: Deploy m1.xlarge or bigger.
  • Network: Use avi-mgmt to attach the Controller to the management network.
  • Security group: Use avi-mgmt-sg to allow management traffic.
  • Enable config-drive.

To assign a floating IP address to the Controller:

  1. On the Horizon Dashboard, navigate to Project > Compute > Access & Security.
  2. Assign the floating IP address:
    • If no floating IP address is already available, click Allocate IP to Project.
    • Otherwise, if a floating IP address is already available, associate it with the Avi Controller instance.

Perform Initial Controller Setup

This section shows how to perform initial configuration of the Avi Controller using its deployment wizard. You can change or customize settings following initial deployment using the Avi Controller’s web interface.

Note: While the system is booting up, a blank web page or 503 status code may appear. In this case, wait for 5 to 10 minutes; then follow the instructions for the setup wizard.

  1. Configure basic system settings:
    • Administrator account
    • DNS and NTP server information
    • Email and SMTP information

    email_SMTP_settings

  2. Set the infrastructure type to OpenStack: ctlr-setup-infra-openstack-161
  3. Enter OpenStack settings:
    • Provide the tenant user credentials (username, password). If you are using Keystone V3 and want to provide an user in the non-Default domain, then please use the notation "user@domain-name" for the Username field. Please refer to following example:
      openstack-v3-user-config
    • If a username "test" is created as a Keystone v3 user in a domain named "default," then explicitly specify "test@testdomain" when logging into the Avi Controller. If the domain name is not specified, Keystone looks for a domain with UUID "testdomain" and not the name "testdomain." Since no domain with a UUID of "testdomain" exists, Keystone fails, returning the error "invalid user/password."
    • Using the full value in the Keystone Auth URL field, Avi Vantage determines the Keystone API version automatically. When the auth URL is a secure URL (HTTPS), an option to either allow or disallow self-signed certificates will show up (as seen in the right screenshot below). Please disable that checkbox in a production environment, since OpenStack services should use proper, trusted certificates.
    • Enable (check) the Keystone Auth option.

    openstack-login-v2-fullopenstack-login-v3-cert

  4. In the Management Network window, select a tenant. In this deployment, it should be the same tenant into which the Avi Controller is deployed. Choose the management network created previously. ctlr-setup-mgmtnetwork-161
  5. In the Keystone Role Mapping window, select an Avi Vantage user role to use as the default user role:
    If an Avi Vantage user who logs in with valid Keystone credentials, but with a role that does not have the same name as any of the user roles defined on the Controller, the default role is assigned to the user. To instead disallow access by any user who does not have a role that is defined on the Controller, leave the selection empty (None).
  6. In the Virtual Service Placement Settings window, select Import Tenants to import from tenants Keystone and click Next. Then, in the Support Multiple Tenants window, click No.
  7. To verify installation, navigate to Infrastructure > Clouds, click Default-Cloud, then click the Status button. If the status is green, the installation is successful.
    openstack-deploy-verify-162

Neutron SDN Plugin Integration

Avi Vantage integrates with the following Neutron SDN plugins to provide VIP placement and floating-IP (FIP) association to VIP.

Nuage SDN

During cloud configuration, select the “Integration with Nuage VSD” checkbox and provide the VSD host, port and authentication details.

a.1 Nuage-OpenStack-DefClouda.1 Nuage-OpenStack-DefCloud2

If you are creating a new cloud, the wizard looks as below:

Nuage-OpenStack-NewCloud wizard setup

Contrail SDN

Using the Avi UI

During Cloud configuration, select the “Integration with Contrail” checkbox and provide the endpoint URL of Contrail VNC api-server. The Keystone credentials from the OpenStack configuration will be used to authenticate with the api-server service.

Note: Contrail-Interface-IP is handled gracefully by Avi Vantage. So, creating and editing the cloud should be left intact while integrating Contrail SDN under Network Settings.

b.1 Contrail-OpenStack-DefCloud

If you are creating a new cloud, the wizard looks as below:

b.2 Contrail-OpenStack-NewCloud

If you are editing an existing cloud, the cloud editor looks as below:

cloud editor

Using the Avi CLI


configure cloud oscontrail
vtype cloud_openstack
openstack_configuration

privilege write_access
username admin
password xxxyyyzzz
admin_tenant admin
mgmt_network_name avi-mgmt
region RegionOne
use_keystone_auth
import_keystone_tenants
no use_admin_url
auth_url http://172.16.11.50:5000/v2.0
no neutron_rbac
contrail_endpoint http://10.10.10.100:8082
role_mapping os_role * avi_role Tenant-Admin
New object being created
save
save
save

Advanced Network Configuration Options

cloud-editor.advanced-network-settings.png

1. Security Groups (default=’True’)

The security-groups Neutron extension supports the specification of whitelist rules for both ingress and egress. Avi Vantage uses this extension to create one SG per Avi SE. This SG is created with ALL egress and SSH & ICMP ingress. Since virtual services are created and placed on this SE, the corresponding service ports are added to this SG. Similarly, when the VSes are unplaced from the SE, the corresponding service ports are removed from this SG (if no longer used by any other VS on the same SE). If this option is set to True, the security-groups extension will be used. If the underlying network plugin doesn’t 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 filter rules on ports.

The following example shows the SG of an SE with a VS with service port ‘80’ placed on it.


[root@sivacos ~(keystone_admin)]# neutron security-group-list
[root@sivacos ~(keystone_admin)]# neutron security-group-list
| 5544b75d-2a57-4f56-b1d0-ef68242293ba | avi-se-30af06c4-09c6-4c94-92be-f39d4dfddf91 | egress, IPv4                                      |
|                                      |                                             | egress, IPv6                                      |
|                                      |                                             | ingress, IPv4,22/tcp, remote_ip_prefix: 0.0.0.0/0 |
|                                      |                                             | ingress, IPv4,80/tcp, remote_ip_prefix: 0.0.0.0/0 |
|                                      |                                             | ingress, IPv4,icmp, remote_ip_prefix: 0.0.0.0/0   |

2. Anti-Affinity (default=’True’)

Compute uses the nova-scheduler service to determine the host to launch a VM based on various criteria and filters. One such filter, ServerGroupAntiAffinityFilter, ensures that each instance in an anti-affinity group executes on a different host. Avi Vantage uses one anti-affinity group per SE group, thereby enabling each SE in the SE group to be placed on different hosts for better isolation of SEs in the event of host failures.

If set to False, anti-affinity filters will not be used. This option can be turned off, if nova-compute has only 1 compute node.

The following example shows an anti-affinity group of SE group, serviceenginegroup-37dac996-7c88-4761-a920-6dc9d265c786, in a tenant with two SE VMs.

Note: For the sake of readability, command output has been changed from its normal 7-column appearance to 2-column.


root@node-17:~# nova server-group-list
+------------+------------------------------------------------------------------------------------+
| Id         | c605a898-86fa-457f-80c8-f1db21dfb68a                                               |
| Name       | avi-aasg-serviceenginegroup-37dac996-7c88-4761-a920-6dc9d265c786                   |
| Project Id | fefb594ef03e4670beaffe3305440e24                                                   |
| User Id    | aba3667db25e44afb5aff73f3f363027                                                   |
| Policies   | [u'anti-affinity']                                                                 |
| Members    | [u'd7509390-6afe-4865-ade2-231e9a664421', u'1867c24e-8495-4cbf-80d0-06a2328656c6'] |
| Metadata   | {}                                                                                 |
+------------+------------------------------------------------------------------------------------+

root@node-17:~# nova list | egrep "d7509390|1867c24e"| d7509390-6afe-4865-ade2-231e9a664421 | cc_os-se-ozmkj                    | ACTIVE | -          | Running     | avimgmt=10.10.44.231                                                                                                                                                                                             || 1867c24e-8495-4cbf-80d0-06a2328656c6 | cc_os-se-xmrzn                    | ACTIVE | -          | Running     | network-80.21=10.80.21.13;avimgmt=10.10.44.230

3. External Networks (default=False)

Setting this option to True enables selection of OpenStack networks marked as ‘external’ for Avi management, VIP or data networks.

4. Metadata Provisioning (default=’config-drive’)

OpenStack allows metadata to be passed on to VMs using:

  • Config-drive: Metadata is written to a special configuration drive that attaches to the instance when it boots. The instance can mount this drive and read the data. Please refer to OpenStack’s Store metadata on a configuration drive article for further details.
  • Metadata-service: Instances can access the metadata-service at http://169.254.169.254 to retrieve instance-specific data.

Avi Vantage supports both options, with config-drive preferred over metadata-service and requires the OpenStack deployment to support one of these options.

5. VIP Placement (default=’allowed-address-pairs’)

Avi Vantage supports multiple VIP placement methodologies using:

  • Allowed-address-pairs (default=True), a Neutron extension enabling traffic with specific CIDRs to egress from a port. Avi Vantage uses this extension to “place” VIPs on SE data ports, thereby allowing VIP traffic to egress these data ports. If set to True, the allowed-address-pairs extension will be used. If the underlying network plugin doesn’t 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.

Example: On OVS with iptables, the a rule for ‘172.24.10.7’ would be added to the Avi data port with UUID prefix 019ec61b.


[root@sivacos ~(keystone_admin)]# neutron port-show 019ec61b-3be2-4e25-a4a8-d48740ffa3ad+-----------------------+--------------------------------------------------------------------------------------------------+| Field                 | Value                                                                                           |+-----------------------+--------------------------------------------------------------------------------------------------+| admin_state_up        | True                                                                                            || allowed_address_pairs | {"ip_address": "172.24.10.7", "mac_address": "fa:16:3e:47:a2:0e"}                               || binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}                                                  |
                  || device_id             | c32926e6-6c86-49a0-90a4-9e634a7ac6dd                                                            || device_owner          | compute:None                                                                                    || fixed_ips             | {"subnet_id": "b679630f-f3d1-4a32-86ca-04ef04534adc", "ip_address":"172.24.10.11"}              || id                    | 019ec61b-3be2-4e25-a4a8-d48740ffa3ad                                                            || mac_address           | fa:16:3e:47:a2:0e                                                                               |[root@sivacos ~(keystone_admin)]# iptables -S | grep -i fa:16:3e:47:a2:0e-A neutron-openvswi-s019ec61b-3 -s 172.24.10.7/32 -m mac --mac-source FA:16:3E:47:A2:0E -m comment --comment "Allow traffic from defined IP/MAC pairs." -j RETURN-A neutron-openvswi-s019ec61b-3 -s 172.24.10.11/32 -m mac --mac-source FA:16:3E:47:A2:0E -m comment --comment "Allow traffic from defined IP/MAC pairs." -j RETURN
  • Port-security (default=False), a Neutron extension enabling or disabling packet filtering on Neutron networks and/or ports. If the underlying network plugin doesn’t support this feature, then VIP traffic will not work unless there are other means to achieve the same effect. By default, on an OpenStack network and/or port, port_security_enabled is True, which activates the rules defined by the port’s security_groups and allowed_address_pairs on that port. For example, the following shows an Avi SE data interface with a VIP placed on it via allowed-address-pairs.

root@node-17:~# neutron port-show b264479e-5c2c-49ff-86fc-ed6c044785e4+-----------------------+-----------------------------------------------------------------------------------------------------------+| Field                 | Value                                                                                                    |+-----------------------+-----------------------------------------------------------------------------------------------------------+| admin_state_up        | True                                                                                                     || allowed_address_pairs | {"ip_address": "10.80.59.150", "mac_address": "fa:16:3e:de:e5:5b"}                                       || device_id             | 6b558e67-c593-4c7b-a921-ad973ec05e45                                                                     || device_owner          | compute:None                                                                                             || fixed_ips             | {"subnet_id": "2deddcd7-1ddf-463d-86e1-d725cb7d98ef", "ip_address":"10.80.59.34"}                        || id                    | b264479e-5c2c-49ff-86fc-ed6c044785e4                                                                     || mac_address           | fa:16:3e:de:e5:5b                                                                                        || name                  | Avi-Data:cluster-f02ac01e-0de3-4b6b-9a06-4caff55c1e46:cloud-3a7bcd5f-7842-448a-86cc-aa21e2361bc2          || network_id            | 71bd03e1-db0e-419f-899b-754c9058ed12                                                                     || port_security_enabled | True                                                                                                     || security_groups       | 83454846-4eb2-4b43-94b7-dd4e90a27916                                                                     |

If port_security_enabled is False on a port, then neither security_groups nor allowed_address_pairs are associated with that port. This completely any anti-spoof and packet filtering on that port. For example, the following shows an Avi SE data interface with a VIP placed on it via port-security.


root@node-17:~# neutron port-show 9fcac544-20ef-4744-82ec-ebd93c8620c9+-----------------------+--------------------------------------------------------------------------------------------------------------+| Field                 | Value                                                                                                       |+-----------------------+--------------------------------------------------------------------------------------------------------------+| admin_state_up        | False                                                                                                       || allowed_address_pairs |                                                                                                             || device_id             | 6e15f087-f2a8-4e1a-a54c-6fef3b641c94                                                                        || device_owner          | compute:None                                                                                                || fixed_ips             | {"subnet_id": "810fd752-cb67-486d-95e1-845fe316362b", "ip_address":"192.168.10.5"}                          |
"192.168.10.5"}                          || id                    | 9fcac544-20ef-4744-82ec-ebd93c8620c9                                                                        || mac_address           | fa:16:3e:c8:d7:c0                                                                                           || name                  | Avi-Data:cluster-f02ac01e-0de3-4b6b-9a06-4caff55c1e46:cloud-3a7bcd5f-7842-448a-86cc-aa21e2361bc2             || network_id            | f221556d-d204-4906-8fe7-1312d841df7d                                                                        || port_security_enabled | False                                                                                                       || security_groups       |                                                                                                
  • Interface-secondary-ips (default=False), a method that adds secondary IP addresses to a Neutron port, thereby allowing traffic to/from the port without any special extension support. This mode is supported only in tenant-mode SE configuration (and not in provider-mode SE).

root@node-17:~# neutron port-show 9fcac544-20ef-4744-82ec-ebd93c8620c9+-----------------------+--------------------------------------------------------------------------------------------------------------+| Field                 | Value                                                                                                       |+-----------------------+--------------------------------------------------------------------------------------------------------------+| admin_state_up        | True                                                                                                        || device_id             | 6e15f087-f2a8-4e1a-a54c-6fef3b641c94                                                                        || device_owner          | compute:None                                                                                                || dns_assignment        | {"hostname": "host-192-168-10-5", "ip_address": "192.168.10.5", "fqdn": "host-192-168-10-5.openstacklocal."} ||                       | {"hostname": "host-192-168-10-6", "ip_address": "192.168.10.6", "fqdn": "host-192-168-10-6.openstacklocal."} || fixed_ips             | {"subnet_id": "810fd752-cb67-486d-95e1-845fe316362b", "ip_address":"192.168.10.5"}                          ||                       | {"subnet_id": "810fd752-cb67-486d-95e1-845fe316362b", "ip_address":"192.168.10.6"}                          || id                    | 9fcac544-20ef-4744-82ec-ebd93c8620c9                                                                        || mac_address           | fa:16:3e:c8:d7:c0                                                                                           || name                  | Avi-Data:cluster-f02ac01e-0de3-4b6b-9a06-4caff55c1e46:cloud-3a7bcd5f-7842-448a-86cc-aa21e2361bc2             || network_id            | f221556d-d204-4906-8fe7-1312d841df7d                                                                        |

6. Map-admin-to-cloudadmin (default=’False’)

By default, the Avi admin tenant maps to the OpenStack admin tenant. If this option is set to True, then the Avi admin tenant maps to the admin_tenant configured in the Avi cloud. This directly maps the load-balancer-related operations onto the corresponding tenant in OpenStack.

7. Neutron-rbac (default=’True’)

By default, Avi Vantage consults the Neutron role-based-access-control (RBAC) rules to retrieve the ‘usable’ list of networks for a tenant. This list would normally include the tenant’s own networks, any non-tenant networks widely shared with ‘all’ and any non-tenant networks explicitly shared with the tenant using RBAC. This flag is useful in provider-mode SE configuration and if False, the RBAC shared networks are not included in the ‘usable’ list.

8. Usable-networks (default=’None’)

By default, Avi Vantage only displays the ‘usable’ list of networks for a tenant as described in (7) above. In some deployments, it maybe required to have some extra networks visible to the tenant. This repeated field allows such a configuration.

NOTE: the networks listed here must still be accessible by the admin-user configured in the Avi cloud; this is verified at every network listing and is determined by the OpenStack role of admin-user in that tenant.

If you are editing an existing cloud, the cloud editor looks as below:

cloud editor

Deploying Avi-managed LBaaS Mode

This section provides the steps for deploying Avi Vantage into an OpenStack cloud in Avi-managed LBaaS mode.

OpenStack-deploy-topo-avilbaas

Avi-managed LBaaS mode provides tenant users with the advantages of Avi Vantage, without the need for them to perform deployment or maintenance of Avi Vantage. Instead, the cloud administrator deploys and manages Avi Vantage. The Controller and SEs in the administrative tenant are shared by other tenants. Users of those tenants are able to secure and optimize their applications using the Avi Vantage resources that reside in the administrative tenant.

Note: Although using an existing tenant instead of creating a new one also is supported, creating a new tenant is recommended for easy maintenance.

Deployment Process

Deployment of Avi-managed LBaaS mode requires the following procedure.

  1. Create a tenant for the Controller and SE.
  2. (Optional) Create multiple flavors of the Avi Vantage image, with different resource allocations to fit different sizes of user tenant. (For example: "avi_ctrl.small" and "avi_se.medium".)
  3. Upload the Avi Controller QCOW2 or raw image into the tenant from Glance.
  4. Create a management network for the Avi Controller and SEs.
  5. Create a security group to allow Avi management traffic.
  6. Deploy an Avi Controller instance and assign a floating IP address to it.
  7. Use the setup wizard to perform initial configuration of the Controller.

Detailed steps are provided below.

Create a Tenant for the Controller and SEs

  1. Log into the OpenStack Horizon dashboard with an account that has cloud administrator privileges.
  2. Navigate to Identity > Projects.
  3. Click New Project and follow the wizard's instructions.
  4. Follow the instructions of the tenant creation wizard. For Avi Vantage deployment, use the following settings:
    a. Enter a project name (e.g., "avi-tenant”).
    b. Click the Project Members tab.
    c. Add a user account to Project Members and assign the “admin” role to the account.
    d. Click the Quota tab and modify the maximum resources. These settings allow for three Avi Controllers (for redundancy), up to 1000 SEs and some other managerial instances, if required.

Screen Shot 2017-02-07 at 11.37.13 AM

Create Multiple Flavors of Controller Image

Use these steps to create multiple flavors of Avi Vantage, avi_ctrl.small and avi_se.medium.

  1. In the Horizon dashboard, navigate to Admin > System > Flavors and click Create Flavor.
  2. Fill out the forms for flavor avi_ctrl.small. Assign minimal resources to this flavor.
  3. Repeat for avi_se.medium but assign more resources to this flavor than to the avi_ctrl.small flavor.

Upload Controller Image

  1. Copy the Avi Vantage Controller QCOW2 image onto your hard drive.
  2. In the Horizon dashboard, navigate to Project > Images.
  3. Click Create Image and fill out the form. Use at least these resource allocations:
    • Minimum disk: 64 GB
    • Minimum memory: 24 GB

Create Management Network

A management network is required for communication between the Avi Controller and the SEs. An existing network can be used but a dedicated management network is recommended.

  1. On the Horizon Dashboard, navigate to Network > Networks.
  2. Click Create Network and follow the wizard's instructions. For this example:
    • Network name: avi-mgmt
    • DHCP: Enabled
  3. Connect the network to your Neutron router.
    a. Navigate to Network > Routers.
    b. On the Name column in the router list, click the router to add an interface to the network.
    c. Click the Interfaces tab; then click Add Interface.

Create Security Group

A security group is required to allow the Controller and SEs to exchange management traffic. The group specifies the protocol ports for which traffic will be allowed. For ingress traffic, the group must allow these ports.

For egress traffic, the group can allow all ports.

Note: The Controller automatically creates a security group for the SEs.

To create a security group (in this example, “Avi-mgmt-sg”) to allow management traffic:

  1. Navigate to Project > Access & Security, and click Create Security Groups.
  2. Add rules as shown in the following example, where 192.168.10.0/24 is the management network.

Deploy Controller and Assign it a Floating IP

Deploy an Avi Controller instance:

  • Flavor: Deploy avi_ctrl.small or bigger.
  • Network: use avi-mgmt to attach the Controller to the management network.
  • Security group: use avi-mgmt-sg to allow management traffic.
  • Enable config-drive.

To assign a floating IP address to the Controller:

  1. On the Horizon Dashboard, navigate to Project > Compute > Access & Security.
  2. Assign the floating IP address:
    • If no floating IP address is already available, click Allocate IP to Project.
    • Otherwise, if a floating IP address is already available, associate it with the Avi Controller instance.

Perform Initial Controller Setup

This section shows how to perform initial configuration of the Avi Controller using its deployment wizard.

You can change or customize settings following initial deployment using the Avi Controller’s web interface.

  1. Configure basic system settings:
    • Administrator account
    • DNS and NTP server information
    • Email and SMTP information

    email_SMTP_settings

  2. Set the infrastructure type to OpenStack:ctlr-setup-infra-openstack-161
  3. Enter OpenStack settings:
    • Tenant user credentials (username, password)
    • IP address of Keystone server
    • Enable (check) the Keystone Auth option.

    openstack-deploy-openstacklogin-selectkeystone

  4. In the Management Network window, select a tenant. In this deployment, it should be the same tenant into which the Avi Controller is deployed. Choose the management network created previously. ctlr-setup-mgmtnetwork-lbass-mgdmode-161
  5. In the Keystone Role Mapping window, select an Avi Vantage user role to use as the default user role: ctlr-setup-openstack-keystonemapping-161
    If an Avi Vantage user logs in with valid Keystone credentials, but with a role that does not have the same name as any of the user roles defined on the Controller, the default role is assigned to the user. To instead disallow access by any user who does not have a role that is defined on the Controller, leave the selection empty (None).
  6. In the Virtual Service Placement Settings window, select Import Tenants to import from tenants Keystone and click Next. Then, in the Support Multiple Tenants window, click Yes.ctlr-setup-vsplacement-openstack-161
  7. In the Tenant Settings window, select the following settings:
    • Per tenant IP route domain
    • Service Engines are managed within the provider context, shared across tenants
    • Tenant has Read Access to Service Engines

    openstack-deploy-openstackmulttenantsettings

  8. Navigate to Infrastructure > Clouds and select Default-Cloud.
  9. Click the Service Engine Group tab.
  10. Click the edit icon on the right end of Default-Group.
  11. Ensure that compact placement is selected and Max Number of Service Engines is high enough to meet the needs of all tenants.Screen Shot 2016-07-13 at 12.50.49 PM
  12. To verify installation, navigate to Infrastructure > Clouds, click Default-Cloud, then click the Status button. If the status is green, installation is a success.
    openstack-deploy-verify-162

Deploying OpenStack-managed LBaaS Mode

OpenStack-managed LBaaS mode includes the same deployment steps as Avi-managed LBaaS mode. In addition, installation of the Avi LBaaS driver and Avi extension for Horizon dashboard are required. The tenant administrator accesses and manages Avi Vantage through the Horizon dashboard instead of the Avi Controller web interface.

OpenStack-deploy-topo-openstacklbaas

Deployment Process

Deployment of OpenStack-managed LBaaS mode requires the following procedure.

  1. Deploy Avi-managed LBaaS mode.
    a. Create a tenant for the Controller and SE.
    b. (Optional) Create multiple flavors of the Avi Vantage image, with different resource allocations to fit different sizes of user tenant ("avi_ctrl.small" and "avi_se.medium").
    c. Upload the Avi Controller qcow2 or raw image into the tenant from Glance.
    d. Create a management network for the Avi Controller and SEs.
    e. Deploy an Avi Controller instance and assign a floating IP address to it.
    f. Create a security group to allow Avi management traffic.
    g. Use the setup wizard to perform initial configuration of the Controller.
  2. Install the Avi LBaaS driver.
  3. Install the Avi extension for the Horizon dashboard.
  4. Install a valid certificate on the Avi Controller.

Note: Replacing the Controller’s self-signed certificate with a valid one allows access to the Avi Controller through the Horizon dashboard. Alternatively, the tenant user or administrator can log onto the Avi Controller’s web interface directly, accept the self-signed certificate presented by the Controller. After this, the user or administrator can access the Controller through Horizon.

Perform OpenStack-managed LBaaS Mode Deployment

To begin, perform all the steps in Deploying Avi-managed LBaaS Mode. These steps also are required for OpenStack-managed LBaaS mode.

Install Avi LBaaS Driver

Installing / Upgrading LBaaS driver using script

Avi Networks provides a script for installing or upgrading the LBaaS plugin driver (v1 or v2). The script makes the necessary OpenStack configuration changes automatically. Download the Avi LBaaS driver installation package (avi_openstack_package.tar.gz) from the Avi Networks portal website (https://portal.avinetworks.com).

Note: If preferred, the LBaaS driver can be installed alone without the virtual environment files that the script also installs. (For more information and instructions, see the README file in the avi_openstack_package.tar.gz package.)

Note: An account with root privileges for the Neutron API server is required. This account is different from the account used by the Controller to access the OpenStack infrastructure.

Note: If any pre-17.1.x versions of the Neutron-LBaaS Avi driver were installed, then installing or upgrading to Avi Vantage 17.1.x requires upgrading the corresponding Avi driver to the 17.1.x version as well. Earlier versions of the Avi driver are incompatible with Avi Vantage 17.1.x.

  • Copy the package onto the OpenStack Neutron API host.
  • Log into the Neutron API server.
  • On the OpenStack Neutron API server, back up neutron.conf.
  • Unzip and untar the driver package: tar -xzf avi_openstack_package.tar.gz
  • Run the Avi LBaaS installation script. To install LBaaS v2 driver, specify the option “–v2” to the following install command. In the following example of v1 driver installation, 10.10.22.44 is the IP address for the Avi Controller cluster. The login credentials for the Controller are admin, avinetworks. Make sure to replace the IP address in the example with the cluster IP address.

 

Note: If installing only the driver without the virtual environment files, see the README file in the avi_openstack_package.tar.gz on the Avi Networks customer portal.

[root@sivacos openstack_lbplugin(keystone_admin)]# ./install.sh --aname my_lbaas --aip 10.10.22.44 --auser admin --apass avinetworks
12/06/2016 13:58:37 INFO: logging initialized
12/06/2016 13:58:37 WARNING: Using auth_url IP 10.130.128.110 as keystone IP
12/06/2016 13:58:37 INFO: OS distribution: Fedora
12/06/2016 13:58:38 INFO: Neutron process check...OK
12/06/2016 13:58:38 INFO: neutron path '/usr/lib/python2.7/site-packages/neutron'...OK
12/06/2016 13:58:38 INFO: neutron_lbaas path '/usr/lib/python2.7/site-packages/neutron_lbaas'...OK
12/06/2016 13:58:43 INFO: Local: Avi Controller '10.10.22.44' check using provided credentials...OK
12/06/2016 13:58:44 INFO: Local: Avi Controller cloud 'Default-Cloud' check...OK
--> Install SeLinux module 'avi_lbaas'? (y/n)y
12/06/2016 13:58:49 INFO: SeLinux module Install in progress...
12/06/2016 13:59:05 INFO: SeLinux module 'avi_lbaas' install...OK
12/06/2016 13:59:05 INFO: Horizon Load-Balancer tab already enabled
12/06/2016 13:59:37 INFO: Horizon HTTP server restart...OK
--> Configure Neutron Server with Avi LBaaS provider 'my_lbaas' with driver 'avi'? (y/n)y
12/06/2016 13:59:46 INFO: Neutron Avi LBaaS configure provider 'my_lbaas'...OK
12/06/2016 13:59:46 INFO: Neutron Avi LBaaS driver 'avi' setup...OK
12/06/2016 13:59:58 INFO: neutron-server restart...OK
12/06/2016 13:59:58 INFO: Neutron Avi LBaaS configuration setup...OK
12/06/2016 13:59:58 INFO: Refer '/tmp/openstack_lbplugin/avi_os_setup.log' for install log
  • To upgrade the existing driver, if any, specify the option “–update” to the above install command.
[root@sivacos openstack_lbplugin(keystone_admin)]# ./install.sh --aname my_lbaas --aip 10.10.22.44 --auser admin --apass avinetworks --update
12/06/2016 14:04:08 INFO: logging initialized
12/06/2016 14:04:08 WARNING: Using auth_url IP 10.130.128.110 as keystone IP
12/06/2016 14:04:08 INFO: OS distribution: Fedora
12/06/2016 14:04:08 INFO: Neutron process check...OK
12/06/2016 14:04:09 INFO: neutron path '/usr/lib/python2.7/site-packages/neutron'...OK
12/06/2016 14:04:09 INFO: neutron_lbaas path '/usr/lib/python2.7/site-packages/neutron_lbaas'...OK
12/06/2016 14:04:19 INFO: Local: Avi Controller '10.10.22.44' check using provided credentials...OK
12/06/2016 14:04:20 INFO: Local: Avi Controller cloud 'Default-Cloud' check...OK
12/06/2016 14:04:23 INFO: SeLinux module 'avi_lbaas' already installed
12/06/2016 14:04:23 INFO: Horizon Load-Balancer tab already enabled
12/06/2016 14:04:54 INFO: Horizon HTTP server restart...OK
--> Configure Neutron Server with Avi LBaaS provider 'my_lbaas' with driver 'avi'? (y/n)y
12/06/2016 14:05:03 INFO: Neutron Avi LBaaS configure provider 'my_lbaas'...OK
12/06/2016 14:05:04 INFO: Neutron Avi LBaaS driver 'avi' setup...OK
12/06/2016 14:05:16 INFO: neutron-server restart...OK
12/06/2016 14:05:16 INFO: Neutron Avi LBaaS configuration setup...OK
12/06/2016 14:05:16 INFO: Refer '/tmp/openstack_lbplugin/avi_os_setup.log' for install log

Installing LBaaS v1 driver from Avi UI

Note: Only LBaaS v1 driver installation is supported using the Avi UI. Please use the script method detailed in the previous section for installing v2 driver.

      1. In the Avi Vantage web interface, navigate to Infrastructure > Clouds.
      2. Click on Default-Cloud, then click on the plugin icon: openstack-lbaas-plugin-install-icon
      3. Fill in the fields, then click Install.

openstack-install-lbaas-driver-162

Install Avi Extension for Horizon Dashboard

This part of the installation requires an account for access to the OpenStack Horizon server. We distribute our software as Python PIP packages and Debian packages. Either the pip utility or a Debian package installer tool (such as dpkg) is required to be available on the Horizon server.

If you have LBaaSv1 installed and need Avi Horizon extensions to support SSL certificates, multiple listener ports per VIP, and analytics, please follow the installation instructions at Avi Horizon Tabs README.

If you have LBaaSv2 installed or want to expose full Avi UI, please follow the installation instructions at Avi Horizon Panel README.

Important! Don't forget to restart the Horizon service after installing the extension.

New Horizon Tabs for Avi Vantage

If LBaaSv1 is in use and the Avi extension for Horizon for tabs is installed, one or more of the following new tabs appear on the Load Balancers menu of the Horizon dashboard:

  • Certificates: Allows management of SSL certificates. Through this tab, certificates can be uploaded to the Controller and associated with a VIP for SSL offload.openstack-deploy-hortabs-cert
  • Analytics: Provides detailed operational and performance information about virtual services and related traffic. openstack-deploy-hortabs-analytics

Full Avi Controller UI as a Horizon panel: With Avi Horizon Panel plugin, a new panel is added under Network section that enables access to the entire Avi Controller web interface from within Horizon: openstack-deploy-hortabs-uiaccess

Note: Avi Horizon plugins use iFrames to render the Avi Controller’s web pages within Horizon. This requires replacement of the Controller’s self-signed certificate (see below). If the Controller’s self-signed certificate is not replaced with a valid one, Avi-related pages may not appear in several common browsers.

Install Valid Certificate on Avi Controller

This section gives steps for replacing the Controller’s self-signed certificate with one signed by a Certificate Authority (CA). The Controller requires a CA-signed certificate to access the Avi Controller through the Horizon dashboard.

      1. Log into the Avi Controller web interface.
      2. Navigate to Templates > Security.
      3. Click New on the SSL/TLS Certificates menu.
      4. Click Import to import the new certificate and key.
      5. After uploading the new certificate and key, configure the Avi Controller to use them:
        1. Navigate to Administration > Settings > Access Settings.
        2. Click the edit icon.
        3. Select the imported certificate and click Save.

Installing Avi Heat Package

Admins can optionally install Avi Heat package to enable users to use Avi resource types in their heat templates. Please follow the installation steps available online at Avi Heat README .

Updated: 2017-12-15 14:07:07 +0000