OpenStack Neutron LBaaS plug-in includes a NetScaler driver that enables OpenStack to communicate with the NetScaler Console. OpenStack uses this driver to forward any load balancing configuration done through LBaaS APIs, to the NetScaler Console, which creates the load balancer configuration on the desired NetScaler instances. OpenStack also uses the driver to call NetScaler Console at regular intervals to retrieve the status of different entities (such as VIPs and Pools) of all load balancing configurations from the NetScalers. NetScaler driver software for OpenStack platform is bundled along with the NetScaler Console. To download and install the drivers, you have to first install NetScaler Console and launch the application.

You have to first register OpenStack information on the NetScaler Console. Specify the OpenStack controller IP address and cloud administrative user credentials, and also the OpenStack NetScaler driver user credentials. You can later specify the same login credentials in the NetScaler_driver section of the Neutron configuration file (neutron.conf ) so that NetScaler driver in OpenStack can connect to NetScaler Console during LB configurations.

After OpenStack and NetScaler Console are registered with each other, both can talk to each other. Also, OpenStack users can use their existing credentials in OpenStack to log on to the NetScaler Console user interface to check how their LB configurations are performing in NetScalers.

In OpenStack a tenant is also called a project. A tenant is a group of users; a tenant or a project can also be defined as a set of resources (compute, network, storage, and so on) assigned to an isolated group of users.

Placement policies provide the flexibility to decide on the NetScaler instance that is used in each load balancer configuration created by users. Alternatively, the NetScaler Console also provides an option to assign a NetScaler instance based on OpenStack tenants.

Service packages are bundles that tie together policies/SLAs, devices or auto-provision configuration specifications, and tenants/placement-policies. A service package is usually defined in terms of the isolation policies that are provided to the tenant.

The following are some points related to service packages:

While LBaaS V1 driver in OpenStack supports operations from OpenStack Horizon user interface, LBaaS V2 driver supports only command line operations.

The following list shows the features supported on both LBaaS V1 and LBaaS V2 on OpenStack:

This document provides information about:

The following use-case scenario explains the workflow of integrating NetScaler Console with the OpenStack platform:

An enterprise, Example-Cloud-Provider, has used OpenStack components to set up a cloud to provide infrastructure to its tenants. Steve is the administrator of this cloud provider, while Tom is a tenant of the Example-Cloud-Provider's cloud infrastructure. Tom's organization, Example-SportsOnline.com, requires two servers S1 and S1, and Tom also requires a dedicated NetScaler device to load balance the traffic between servers S1 and S2 on OpenStack platform.

To meet this requirement, Steve has to install and configure both OpenStack and NetScaler Console, and prepare them to compatible with each other. Steve has to create a tenant account named Example-SportsOnline in OpenStack, and then allocate resources to the tenant account. Steve also has to create different log-on credentials (users) for Example-SportsOnline for managing its resources and configuration. Tom can now create the two servers S1 and S2 on OpenStack to manage the traffic in his organization.  

Steve has to register OpenStack details with NetScaler Console, and configure the NetScaler LBaaS driver in OpenStack networking component, Neutron. After the registration is complete, NetScaler Console displays the details of all tenants from the OpenStack. Steve can select Example-SportsOnline from the list who wants the NetScaler LBaaS features and configure Tom to get a dedicated NetScaler allotted for his load balancer configurations in NetScaler Console.

For this, Steve can either provision a NetScaler VPX instance on the computing layer (Nova) of OpenStack using NetScaler Console user interface or enable MAS to auto-provision a NetScaler VPX instance on demand, when Tom does his LB configuration in OpenStack. In either case, NetScaler Console manages the VPX instance. For achieving this, Steve creates a service package in NetScaler Console, and defines the conditions in the service package that were agreed in the SLA with Tom. For example, Steve selects the 'dedicated' isolation policy to provide a dedicated instance for providing load balancer configurations to Tom. That is, Steve selects a non-shared instance for Tom in the service package. He then assigns many NetScaler VPX instances to the service package, and associates Example-SportsOnline, along with other tenants, who require a dedicated NetScaler with the service package. As a result, when Tom performs his first load balancer configuration, NetScaler Console allots one of the NetScaler VPX instances in the service package to Example-SportsOnline and also deploys his configuration in that NetScaler.

Tom can now create load balancing configurations, by creating pools, virtual IPs (VIP), and health monitors using OpenStack LBaaS/UI. Pools and the VIPs in OpenStack get deployed as service groups and virtual servers on the NetScaler instance. Tom can also create health monitors to monitor the servers, and send application traffic to only those servers which are UP at any point of time and reachable from NetScaler.

The load balancing configuration created in OpenStack is now implemented on the NetScaler instance. Once fully configured, the NetScaler VPX instance then takes over the load balancing functionality and starts accepting application traffic and load balances the traffic between the servers S1 and S2 created by Tom.  

The following flowchart depicts the workflow that you need to follow when you are configuring LBaaS V1 and LBaaS V2.