Deploy a NetScaler VPX instance on Microsoft Azure
Note:
This tech preview feature is provided for evaluation purposes only and is not intended for production use.
Overview
NetScaler VPX 15.1 Tech Preview introduces the Linux-based NetScaler VPX platform on Microsoft Azure. Azure supports several NIC and IP architectures, so begin by selecting the architecture that matches the applications and the level of traffic separation you want to evaluate.
Choose an Azure architecture
| Architecture | Recommended use | Key design characteristic |
|---|---|---|
| Single NIC, single IP | Quick functional evaluation and simple publishing | One internal IP performs the NSIP, SNIP, and VIP functions. Azure port mapping exposes services. |
| Single NIC, multiple IPs | Standalone application delivery with multiple VIPs and separated IP roles | One NIC contains multiple Azure IP configurations used by the NSIP, VIP, and SNIP. |
| Multiple NICs, multiple IPs | Traffic separation, enterprise evaluation, and high availability (HA) | Management, client, and server traffic can use separate NICs, subnets, and IP configurations. |
Single NIC, single IP
This is the simplest Azure model. One NIC and one internal address perform the management, server-side, and virtual-server functions. Azure translates public traffic to the internal address and a mapped private port. Use this model when the goal is to become familiar with the Linux NetScaler VPX image or to validate a small number of services without managing several Azure IP configurations. This mode is specific to Azure.
For more information, see Configure a standalone VPX instance.
Single NIC, multiple IPs
Use this architecture when a standalone NetScaler VPX needs distinct addresses for management, client, and server traffic but separate NICs are unnecessary. The first private IP configuration becomes the NSIP. Add more Azure IP configurations to the NIC, and then configure the corresponding private addresses on the NetScaler VPX instance as VIPs or SNIPs. Public IP association is optional for server-side addresses.
For more information, see Configure multiple IP addresses on a standalone VPX.
Multiple NICs, multiple IPs
Use this architecture for stronger separation of management, client, and server traffic, and for active-standby HA. Any NIC can contain one or more private or public IP configurations. For Azure deployments, create a VLAN for each data interface without tagging, and bind the primary Azure NIC address as documented to avoid MAC moves and interface mutes.
For more information, see Azure VPX architecture options.
Choose an availability model
| Deployment model | When to use | Traffic handling mechanism |
|---|---|---|
| Standalone | Node redundancy is not required for the evaluation | One NetScaler VPX instance processes application traffic. |
| HA using an availability set | You want protection from host or rack-level failures in a region | Azure Load Balancer probes both nodes and forwards traffic to the node that responds as primary. |
| HA using availability zones | You want zone-level resilience in a supported region | The HA pair spans fault-isolated zones and uses Azure Load Balancer for traffic steering. |
Active-standby HA
Azure HA uses two NetScaler VPX instances in Independent Network Configuration (INC) mode and Azure Load Balancer health probes. Only the primary answers the probe. After failover, the new primary responds and the load balancer directs traffic to it. The documented multi-NIC template creates management, client, and server subnets with a NIC for each node in each subnet. Choose an availability set or availability zones based on the required failure boundary and regional support.
For more information, see Configure Azure HA with multiple IP addresses and NICs.
For non-INC high availability that uses secondary IP configurations, see Deploy an HA pair on Azure with secondary IP configurations.
Plan networking and access
- Create a resource group, virtual network, subnets, and network security groups before deployment.
- Allow every required management and application port through the network security group.
- Do not configure an Azure public IP as a NetScaler VPX VIP. Configure the internal IP and use Azure NAT or load-balancer rules.
- Assign a static internal IP if the VM might be deallocated, to prevent the address from changing when it restarts.
- For throughput above 1 Gbps, use a supported VM size with Azure accelerated networking.
For more information, see Azure network architecture and port guidance.
Sizing and licensing
Use a VM size with at least two virtualized cores and at least 4 GB of memory for the Tech Preview. Select the VM size according to the licensed throughput and NIC count. The Azure deployment documentation provides sizing recommendations up to 10 Gbps. Apply a BYOL license and perform a warm restart before making configuration changes. The preview also includes the Dsv6 and Dsv7 instance families.
For more information, see Azure performance and VM sizing.
Limitations
- The Azure architecture does not support GARP, L2 mode, tagged VLAN, dynamic routing, virtual MAC, USIP, and clustering.
- For throughput above 3 Gbps, the actual network throughput might not match the licensed rate, although SSL throughput and SSL transaction rates might improve.
- The Azure deployment ID is not visible in Azure Resource Manager (ARM) and cannot be used to deploy the appliance.
- IPv6 back-end autoscaling is not supported.
- IPv6 is not supported for NetScaler VPX HA deployment.
- Public IP does not support protocols that open port mappings dynamically, such as passive FTP or ALG.
- HA does not work for traffic that uses a public IP associated directly with a NetScaler VPX instance instead of a public IP (PIP) configured on Azure Load Balancer.
For complete deployment guidance, see NetScaler VPX on Microsoft Azure.