Page Notifications Off
Share page
  1. CloudStack Docs and Knowledge Base
  2. CloudStack Documentation
  3. Design Documents
  4. Netscaler Integration
Was this article helpful?

Netscaler Integration

Modified 18:46, 2 Nov 2011 by David Nalley | Page History
  1. 1. Introduction
    1. 1.1. Purpose
    2. 1.2. Scope
    3. 1.3. Conventions & terminology:
  2. 2. 2. Functional Requirements
    1. 2.1. System Context Diagram
    2. 2.2. DB changes
    3. 2.3. API changes
    4. 2.4. Use Cases
      1. 2.4.1. Adding Netscaler load balancer into a zone
      2. 2.4.2. Implement a guest network 
      3. 2.4.3. Add LB rule to the public IP
      4. 2.4.4. Assign/Unassign VM to LB rule
      5. 2.4.5. Delete a LB rule
      6. 2.4.6. Shutdown a guest network
      7. 2.4.7. Delete load balancer from zone
    5. 2.5. Netscaler LB device support disparity
      1. 2.5.1. Assumptions
      2. 2.5.2. Limitations
      3. 2.5.3. Open issues
      4. 2.5.4. Backward compatibility
  3. 3. Related

Introduction

Cloudstack provides load balancing service for the guest VM’s in virtual networking mode. By default load balancing capability is provided by the virtual router’s HA proxy that is created for the account. Cloudstack also supports to configure external network elements in to a zone, which can provide the capabilities like firewall and load balancer. Currenlty cloudstack offers support for Juniper SRX as external firewall device and F5 BigIP as external load balancer device.
Citrix’s Netscaler available as a network device or as a virtual appliance is a leading load balancer and application firewall with rich capability set. Netscaler is available in three different appliance options. Netscaler MPX a hardware offering, Netscaler VPX a software based virtual appliance which can run on Vmware ESXi, Citrix Xen server and Microsoft Hyper-V and Netscaler SDX fully multi-tenant solution which can run multiple instance of netscaler on single appliance.
It is imperative for cloudstack to support Netscaler offering’s as external load balancer to enable customers build their cloud solution using Xen server, Cloudstack and Netscaler.

Purpose

The purpose of this document is to present functional requirements for the support of Netscaler load balancer appliances as external load balancer device into cloudstack.

Scope

Scope of this document is restricted to Netscaler as a load balancer device and other capabilities like application firewall and SSL termination are beyond scope of this document. Sticky session support using Netscaler load balancer is dealt in functional spec corresponding to bug 10796. Scope of this document is restricted to what will be achieved in Acton release of cloudstack.

Conventions & terminology:

Netscaler load balancer: For the rest of the document term ‘Netscaler load balancer’ will be used to represent all flavours of Netscaler load balancer devices i.e. MPX, VPX and SDX. Differences in functionality support with respect to a specific device will be addressed in later sections.
in-line load balancer mode: It’s a mode of configuring external load balancer in cloudstack which enables load balancer device to be placed behind firewall. direct load balancer mode: In this mode external load balancer is configured to be part of public network and does not reside behind the firewall
LB Virtual Server: A virtual sever in Netscaler load balancer is logical concept which represents one or more application in server farm and entity that external client can access to reach the load balanced service.
Service: Service in Netscaler load balancer represents an instance of load balanced service.
Server: Server is a physical/virtual server on which load balanced service is running.
Service binding: Service binding is a mechanism to associate a service with LB virtual server. One or more services need to be bind to a virtual server, to actually activate load balancing virtual server.

2. Functional Requirements

  1. Netscaler load balancers will be supported as a external load balancer device only in zones configured for virtual networking
  2. Current external network element support in cloudstack restricts single external load balancer per zone. Accordingly there can only be one Netscaler external load balancer that can be configured per zone.
  3. Once a Netscaler load balancer configured for a zone, Netscaler load balancer will be shared by the all the virtual guest networks for their load balancing needs.
  4. Virtual router created for the account should not serve the load balancing rules configured for the guest VM’s of that account when Netscaler load balancer is added in to the zone.
  5. When a Netscaler load balancer is added in a zone, only Netscaler load balancer should serve the load balancing rules configured for the guest VM’s
  6. Netscaler load balancer device is expected to configured with two interfaces with one interface to be part of the public network, and another interface to be part of the private network. Cloudstack will only work with public and private interfaces of Netscaler load balancer device to implement the load balancer rules.
  7. Netscaler load balancer should not be allowed to be added in to a zone when there are already deployed LB rules on the guest VM’s in the zone.
  8. Netscaler load balancer should not be allowed to deleted from the zone as long as atleast one load balancer rule over the guest VM’s in guest virtual network in the zone is configured.
  9. Netscaler load balancer should be added in to a zone irrespective of the firewall provider for the zone. i.e Netscaler load balancer should allowed to be added in to a zone independent of the zone’s firewall provider is Juniper SRX or Virtual router 
  10. When Netsclaer load balancer is added in to a zone, cloudstack should deny creating load balanced rules using default public IP associated with an account
  11. Only public IP that is allocated/fetched but not used for source nat or one-to-one nat can be used to create load balancing rule when Netscaler external load balancer is used in the zone
  12. Netscaler should support round robin, least connection load balancing methods 
  13. A Netscaler load balancer should be added in to the zone in either direct or in-line mode. In direct mode, Netscaler load balancer does not sit behind the firewall. In inline mode Netscaler load balancer will be behind the firewall provider for the zone.
  14. Load balancing rules be allowed to create on public IP’s independent of the mode (direct or in-line) in which Netscaler LB device is configured
  15. Netscaler load balancer should track load balancing usage stats like bytes sent and received per lb rule.

System Context Diagram

nslb1.png
Following system context diagram depicts how support for Netscaler load balancer devices will be integrated in to cloudstack.
Existing NetworkElement framework shall be used and a new network element for Netscaler load balancer will be added in to cloudstack. Existing agent framework will be leveraged for Netscaler load balance device support and device will be managed as a server resource 
from cloudstack. Except for below changes in the API to specify external load balancer device is of type Netscaler, existing end-to-end scenarios and functionality of cloudstack with external load balancer load balancer remain unchanged.

DB changes

There are no expected DB schema changes that are required in supporting Netscaler LB device as external load balancer.

API changes

addExternalLoadBalancer: This existing API will be used to add Netscaler LB device into cloudstack. To accommodate both F5 and Netscaer LB devices and future devices that cloudstack will support,with same API, new string parameter named “type” will be accepted
in the API call with the possible values ‘F5BigIP’ and ‘NetscalerMPX’ for the acton release.
listExternalLoadBalancer: This existing API will be enhanced to return “type” which will be either ‘F5BigIP’ and ‘NetscalerMPX’ depending on the load balancer added in the zone in the acton release.

Use Cases

Following are the use cases and expected action in cloudstack when a Netscaler load balancer is added in to the zone as external load balancer.

Adding Netscaler load balancer into a zone

● When a Netscaler load balancer is added in to cloudstack, lb_provider of the zone will be configured as netscaler lb type
● if there is existing a external load balancer in the zone then adding new external load balancer action should fail
● before accepting the netscaler load balancer device into cloudstack as external load balancer, login credentials need to be valid. In case of invalid credentials this action should fail.
● public interface and private interface details provided should be validated before accepting specified Netscaler device as external load balancer.
● Netscaler load balancer should be validated if it has load balancing feature enabled

Implement a guest network 

When a guest virtual network is provisioned in the zone with Netscaler load balancer , following action need to be taken
● Private interface of Netscaler device should be configured to make it part of the virtual guest nework by binding the interface to the VLAN and subnet allocated for the virtual guest nework
● Private interface should be associated with a self-ip (second IP in the subnet) from the guest subnet.

Add LB rule to the public IP

When a LB rule is added on public IP, then LB virtual server will be created on the Netscaler LB device using the public IP and port.

Assign/Unassign VM to LB rule

From the cloudstack when a guest VM is assigned to a LB rule, a server and service
instance is created using guest VM’s IP and port number on the Netscaler LB device, and
created service is bound to lb virtual server corresponding to lb rule.
From the cloudstack when a guest VM is unassigned from a LB rule, service corresponding
to guest VM’s IP and port will unbound to the Lb virtual server, and both service and server
instance will be deleted

Delete a LB rule

When a LB rule in deleted from cloudstack following action will be taken on the Netscaler LB device
● All services associated with LB virtual server corresponding this rule will unbound.
● LB virtual server will be deleted on the Netscaler LB device.
● All services that were associated with lb virtual server will be deleted

Shutdown a guest network

On account deletion, virtual guest network for the account will be tear down. Following action are taken on the Netscaler LB device.
● Private interface on the netscaler LB device will be unbound to vlan and subnet
● all the service instance and the servers that are part of this vlan, that were created on the Netscaler device as part of applying LB rules will be destroyed.
● any lb virtual server that is created using this public IP allocated for the account will be destroyed

Delete load balancer from zone

● This operation should only permitted if there are no LB rules deployed in the zone
● On deleting the Netscaler LB device, zone is configured back to use virtual router for lb services

Netscaler LB device support disparity

As detailed earlier Netscaler load balancers comes in 3 flavors. Following table differentiates
the capabilities and the support added from the cloudstack for each of the device flavour.
Device Flavour Capability CloudStack support in Acton
MPX
Physcial appliance capable of doing deep packet inspection and provides rich functionality as application firewall and load balancer
  • Cloudstack will leverage the load balancer capabilities of the MPX to realize load balancing scenarios supported from cloudstack
  • MPX will be supported with out any limitations
VPX
Virtual appliance which can run as a VM on top of Xenserver, ESXi and Hyper-V hypervisors. Functionally in parity with
MPX
  • Support for VPX will be similar to MPX. Cloudstack will not differentiate between the VPX and MPX and will just treat as same device type.
SDX Physical appliance that is targetted for multi-tenent scenarios where on-demand netscaler VPX can be created. Upto 20 netscaler VPX instances can be created on a SDX appliance with each instance given full isolation. 
  • For Acton release SDX's multi-tenent capabilities will not be leveraged, and it will be expected that admin provisions VPX instance on the SDX device. Provisioned VPX instance on the SDX appliance will be supported just like MPX and VPX appliance
 

Assumptions

● It is assumed that virtual guest network that are deployed in the zone will use non-overlapping IP ranges. Since a single load balancer will be shared across multiple virtual guest networks, overlapping IP will range will result in clashing routes and ARP response etc breaking the functionality
● Netscaler LB device will be not dependent on the firewall provider for the zone in both in-line and direct modes. It should work with both virtual router and SRX configured as firewall for the zones.
● Although Netscaler LB device can support multiple load balancing methods, cloudstack framework permits configuring round robin, least connection lb methods, hence support for only round robin and least connection methods will be added for Netscaler lb device.

Limitations

● F5 load balancer supports notion of routing domains, where all the object created for deploying a LB rule are bound to a VLAN, which provides better isolation boundaries when F5 load balancer is used inline with SRX. There is no such mechanism in Netscaler lb device, and will not provide same level of isolation as F5, however functionally there is parity when Netscaler is used in-line with SRX.
● VPX will be supported only when running on ESXi. Admin needs to configure a port group which part of vlan 4095 on ESXi, and private interface of the VPX needs to be attached to this port group.

Open issues

● An interface in VPX needs to be part of multiple VLAN’s for cloud stack LB rules to work. VPX running on Xen sever has a limitation where an interface in the VM can not be made part of multiple VLAN’s. A possible solution to use vSwtich to over come this limitation is under investigation. If the limitation is overcome, then VPX running on the Xen server can be supported. However MPX and VPX running on
ESXi will be supported with out any limitation.
● SDX appliance has similar limitation as of VPX. Solution arrived for VPX running on the Xenserver might have to be evaluated againest SDX to consider the support feasibility.
● Default public IP associated with virtual guest network is used for source NAT traffic in the virtual guest network. Current support for external load balancer support in cloudstack requires that default public IP can not be used for load balancing purpose when external balancer is added in to cloudstack. In a zone configured with external load balancer it is always required to fetch a new public IP to apply load balancer rules. This constraints remains valid even in case of in-line load balancer. Incase of in-line load balancer fetching new public IP for applying load balancing rules from user perspective is confusing and seems unreasonable ask. I solution need to be
arrived to overcome this limitation.

Backward compatibility

For existing deployments with zone configured with F5 load balancer, upgrading to actonrelease will not hinder any functionality.
 
 
Was this article helpful?
Page statistics
2329 view(s), 17 edit(s) and 16454 character(s)

Tags

This page has no custom tags set.

Comments

Viewing 1 of 1 comments: view all
#1
Chris_Kleban says:
Its great that cloudstack will now support netscalers. However, there are two 'functional requirements' above that are not good:

- you can only have one netscaler per zone (how is that scalable?)
- you can't add a netscaler to a zone that already has LB rules (this doesn't make 'adding the netscaler' easy for existing deployments
Posted 15:24, 7 Nov 2011
Viewing 1 of 1 comments: view all
You must to post a comment.

Attach file

Attachments

FileVersionSizeModifiedOptions
  • nslb1.png
  • v1
  • 72.01 KiB
  • 18:33, 2 Nov 2011
  •