Installing Avi Vantage for OpenStack

Overview

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 instance, 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 receives the end-user traffic and provides application delivery services, while 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 represents 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 v2 - Users can either use Avi Controller API (or UI or CLI) to directly configure load balancer instances. Optionally, the OpenStack administrators can install Avi LBaaS driver on the Neutron API servers and enable Avi as a provider for Neutron LBaaS API.
  • Horizon - OpenStack administrators 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 administrators 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.

Note: LBaaS v1 is deprecated in Avi Vantage 17.2.x.

Avi Vantage integrates into an OpenStack cloud as follows:

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 such as, router service in VM [router_plugin_cisco], [vyatta_l3_plugin] or firewall service in VM, it is required by some services for VMs 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.

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 the 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

You should 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. Do not 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 that 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 that you 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 instance, “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, Ocata, Pike
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 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. Refer DevStack KVM Guide for more 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)</em>
TCP 443
TCP 5054 (if using the optional CLI shell for remote management access)


Ports Used by Controller for Network Services

The Controller can 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 allows 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.

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 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"}
    ],
    ....
}

Configuring Metadata for Avi SEs

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

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. 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

The following are the steps to install single-tenant mode:

  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 as follows:

Uploading Controller Image

The following are the steps to 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 on Create Image and fill out the form.

Creating 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 on Create Network and follow the wizard’s instructions. For instance:
    a) Network name: avi-mgmt
    b) 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 on the router to add an interface to the network.
    c) Click on Add Interface on Interfaces tab,

Creating 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 on 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

Deploying Controller and Assigning it to a Floating IP

To 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:
    a) If no floating IP address is already available, click on Allocate IP to Project.
    b) Otherwise, if a floating IP address is already available, associate it with the Avi Controller instance.

Performing 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, if a blank web page or 503 status code appears, you can wait for 5 to 10 minutes and then follow the instructions for the setup wizard.

  1. Configure basic system settings as follows:
    a) Administrator account
    b) DNS and NTP server information
    c) Email and SMTP information

    openstack install adminacct

    email_SMTP_settings

  2. Set the infrastructure type to OpenStack:

    ctlr-setup infra openstack

  3. Specify OpenStack settings:

    openstack install adminacct-162

    a) 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 use the notation “user@domain-name” for the Username field. For instance:

    openstack-v3-user-config

    b) If a username “test” is created as a Keystone v3 user in a domain named “default,” then you should specify “test@testdomain” while 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.”

    c) Using the full value in 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 screenshot below). You should disable that checkbox in a production environment, since OpenStack services should use proper, trusted certificates.

    d) Enable (check) Keystone Auth option.

    openstack-login-v2-full

    openstack-login-v3-cert

  4. In 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

  5. In Keystone Role Mapping window, select an Avi Vantage user role to use as the default user role:

    ctlr setup openstack keystonemapping

    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. If any user does not have a role that is defined on the Controller, leave the selection empty (None).

  6. In Virtual Service Placement Settings window, select Import Tenants to import from tenants Keystone and click on Next. Then, click on No in Support Multiple Tenants window.

    ctlr setup vsplacement openstack

  7. To verify installation, navigate to Infrastructure > Clouds, click on Default-Cloud, then click on Status button. If the status is green, the installation is successful.

    openstack-deploy-verify-162

Integrating Neutron SDN Plugin

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 Integration with Nuage VSD checkbox and provide the VSD host, port and authentication details.

a.1 Nuage-OpenStack-DefCloud

a.1 Nuage-OpenStack-DefCloud2

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

Nuage-OpenStack-NewCloud wizard setup

Contrail SDN

Using the Avi UI

During Cloud configuration, select 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.

Contrail OpenStack DefCloud

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

Contrail OpenStack NewCloud

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

Cloud Editor

Using the Avi CLI

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

Advanced Network Configuration Options

Cloud Editor Advanced Network Settings

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 and ICMP ingress. Since virtual services are created and placed on this SE, the corresponding service ports are added to this SG. Similarly, when the virtual services are unplaced from the SE, the corresponding service ports are removed from this SG (if no longer used by any other virtual service on the same SE). If this option is set to True, the security-groups extension will be used. If the underlying network plugin 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 filter rules on ports.

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

[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   |

Anti-Affinity (default=’True’)

Computer 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.


# nova server-group-get 93d1e819-3029-4090-825e-207786ca7d83

+------------+------------------------------------------------------------------------------------+
| Id         | 93d1e819-3029-4090-825e-207786ca7d83                                               |
| Name       | avi-aasg-serviceenginegroup-bed543dc-1f89-4f98-9be1-76a31b197632                   |
| Project Id | a578db892e7a4cf6b5f79ee242957bcc                                                   |
| User Id    | e71a7bd86889427baf83dc375e17c2c0                                                   |
| Policy     | soft-anti-affinity                                                                 |
| Rules      | {}                                                                                 |
| Member     | [u'8ce80c2e-972c-464b-827c-4029c32abd7e', u'1a2f39f2-ea69-4b4a-85b9-1003704b3712'] |                    
+------------+------------------------------------------------------------------------------------+

root@pybot-rocky:~# nova list | grep -E '8ce80c2e|1a2f39f2' 
| 8ce80c2e-972c-464b-827c-4029c32abd7e | Avi-se-avjin | ACTIVE | -          | Running     | vip4=10.0.2.4; mgmt=10.0.1.22                            |
| 1a2f39f2-ea69-4b4a-85b9-1003704b3712 | Avi-se-tmctb | ACTIVE | -          | Running     | data4=10.0.3.12; vip4=10.0.2.3, 10.0.2.10; mgmt=10.0.1.4 |

External Networks (default=False)

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

Metadata Provisioning (default=’config-drive’)

OpenStack allows metadata to be passed on to VMs as follows:

  • 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. 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.

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 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.

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 enables or disables packet filtering on Neutron networks and/or ports. If the underlying network plugin does not 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 instance, the following code 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 completes any anti-spoof and packet filtering on that port. For instance, the following code 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       | 
                                                                                              

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.

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 it is set to False, the RBAC shared networks are not included in the ‘usable’ list.

Usable-networks (default=’None’)

By default, Avi Vantage only displays the ‘usable’ list of networks for a tenant as described in the above step. In some deployments, it is 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 follows:

Cloud Editor Advanced Network Settings

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.
  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 as follows:

Creating 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 on 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 (For instance, “avi-tenant”).

    b) Click on Project Members tab.

    c) Add an user account to Project Members and assign the “admin” role to the account.

    d) Click on 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

Creating Multiple Flavors of Controller Image

Use these steps to create multiple flavors of Avi Vantage:

  1. In the Horizon dashboard, navigate to Admin > System > Flavors and click on Create Flavor.
  2. Create an appropriate flavor for Service Engine. Refer to Service Engine Sizing guide to check minimum and recommended resources required for Service Engine.
  3. Create appropriate flavor for Controller. Refer to Controller Sizing guide to check minimum and recommended resources required for Controller.

You can manually configure the flavor if you want to use flavors other than recommended flavor using CLI.

Note: The OpenStack flavour name should be specified and not the flavor ID or UUID.

Uploading 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 on Create Image and fill out the form. Use at least these resource allocations:
    a) Minimum disk: 64 GB
    b) Minimum memory: 24 GB

Creating 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 on Create Network and follow the wizard’s instructions. For instance,
    a) Network name: avi-mgmt
    b) 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 on the router to add an interface to the network.
    c) Click on Interfaces tab; then click on Add Interface.

Creating 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 on Create Security Groups.
  2. Add rules as shown in the following example, where 192.168.10.0/24 is the management network.

Deploying Controller and Assign it to 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:
    a. If no floating IP address is already available, click on Allocate IP to Project.
    b. Otherwise, if a floating IP address is already available, associate it with the Avi Controller instance.

Performing 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:
    a) Administrator account
    b) DNS and NTP server information
    c) Email and SMTP information

    openstack install adminacct 162

    email_SMTP_settings

  2. Set the infrastructure type to OpenStack:

    ctlr-setup-infra-openstack-161

  3. Enter OpenStack settings:
    a) Tenant user credentials (username, password)
    b) IP address of Keystone server
    c) Enable (check) Keystone Auth option.

    openstack-deploy-openstacklogin-selectkeystone

  4. In 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

  5. In Keystone Role Mapping window, select an Avi Vantage user role to use as the default user role:

    ctlr-setup-openstack-keystonemapping


    a) 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. If any user does not have a role that is defined on the Controller, leave the selection empty (None).

    b) In Virtual Service Placement Settings window, select Import Tenants to import from tenants Keystone and click on Next. Then, in Support Multiple Tenants window, click on Yes.
    ctlr-setup-vsplacement-openstack

  6. In Tenant Settings window, select the following settings:
    a) Per tenant IP route domain
    b) Service Engines are managed within the provider context, shared across tenants
    c) Tenant has Read Access to Service Engines
    openstack-deploy-openstackmulttenantsettings

  7. Navigate to Infrastructure > Clouds and select Default-Cloud.
    a) Click on Service Engine Group tab.
    b) Click the edit icon on the right end of Default-Group.
    c) 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

    d) To verify installation, navigate to Infrastructure > Clouds, click on Default-Cloud, then click on 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.

Performing 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 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).

Notes:

  • If preferred, the LBaaS driver can be installed alone without the virtual environment files that the script also installs. (For more information and instructions, refer LBaaSv2 Driver.)

  • 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.

The following are the steps to install Avi LBaas Installation:

  • 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 LBaaSv2 driver, specify the option “–v2” to the following install command.

Note: If installing only the driver without the virtual environment files, refer LBaaSv2 Driver.

[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 Valid Certificate on Avi Controller

This section explains the 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 Avi Controller web interface.
  2. Navigate to Templates > Security.
  3. Click on New on SSL/TLS Certificates menu.
  4. Click on Import to import the new certificate and key.
  5. After uploading the new certificate and key, configure the Avi Controller to use them:
    a) Navigate to Administration > Settings > Access Settings.
    b) Click on the edit icon.
    c) Select the imported certificate and click on Save.

Installing Avi Heat Package

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