Couple weeks back we started with brainstorming the notion of “Application Networking in Cloud” and here we have the CloudStack 3.0 release which deeply integrates with NetScaler MPX, NetScaler VPX and NetScaler SDX appliances.
The Application Delivery leader NetScaler is supported as physical appliance MPX, virtual appliance VPX and service delivery appliance SDX. This is what makes NetScaler special and helps provide various deployment models for Cloud based use cases. You can deploy the NetScaler appliances in shared mode versus dedicated mode based on the requirement. The SDX appliance can particularly be deployed in Hybrid mode having multiple VPXs run through in shared or dedicated mode.
In terms of network deployment with the Firewall, the NetScaler can be deployed in Inline and Parallel mode. In the “Inline” mode NetScaler sits behind the Network firewall and does not interface with public network directly. While in “Parallel” mode of deployment NetScaler is deployed in parallel to the network Firewall interfacing the public network directly.
With CloudStack 3.0 you can deploy NetScaler with core Load Balancing rules. The core protocols like TCP, HTTP and UDP are supported and you can use the load balancing algorithms like Round Robin, Source IP and Least connection. It also supports session persistency based on Source IP and Cookie.
You can add NetScaler as load balancer into the Zone with provider type as NetScalerMPX, NetScalerVPX or NetScalerSDX.
While adding the NetScaler, CloudStack validates login credentials, public/private interface details and ensures that LB feature is enabled. Similarly you can remove NetScaler from a zone if there is no LB rule deployed. Adding a Load Balancing rule is next major step which defines the parameters for load balancing logic.
The LB rule is deployed on the public (external) IP and triggers LB vserver creation on NetScaler. Key parameters like IP, Port, Protocol, LB method and Session persistency mode are taken from the LB rule. A guest VM is assigned to the LB rule where the server resource exists or is created. Based on the server resource the service definition on NetScaler is done. The rule deployment ends up with valid services and front-ending LB vserver setup. When you delete a LB rule, it internally unbinds the services from LB vserver, deletes the services and also the vserver. Thus there is end to end automated support for NetScaler deployment through CloudStack. Here is how you provide the persistency or stickiness for Load Balancing:
The trick with persistency is that selecting AppCookie or LbCookie internally marks the TCP based vserver as HTTP.
For the NetScaler SDX appliance, CloudStack provides services right from:
- The ability to spin up a VPX appliance on SDX
- Provisioning of VPX appliance from scratch
- Load Balancing rule deployment on the VPX
- Ability to use the VPX in shared versus dedicated mode
- De-provisioning the VPX appliance as needed
Thus the entire VPX life cycle can be managed with CloudStack integration.
Overall it is a very useful integration of these 2 rock solid products in Citrix product family. Now you must be thinking about what next… ;). Yes we are working on the next level of integration where the value will be beyond the core load balancing and related functionality. Given the logical control point NetScaler gets deployed at, there is a lot of value which can be brought in with the ability to detect and sense the need for scale for your Application deployment. One of the key benefits of Cloud is the ability to meaningfully control the App or Server deployment with right set of resources serving the clients. There are various reasons why dynamism is needed in such deployments:
- What happens if the client request rate goes up
- How would the same set of servers handle additional load
- What if one of the server goes down due to some system issue
- Who will take up the additional load of the server going down
- Continuing to work with limited servers will introduce slowness and latency
There are many more such questions which can only be answered with solid integration that looks beyond just load balancing facts and that is where we want to get to… soon … 🙂