The Core Requirement for Datacenter Deployments
Has become the ability to run multiple services or instances on same infrastructure. The end customer use case for doing so results into the definition of Multi-tenancy. It has been a requirement from many years and we were the first ADC vendor to introduce True and Complete Multi-tenant solution with NetScaler SDX platform.
NetScaler SDX defines Multi-tenancy across the software and hardware layers of NetScaler ADC.
Particularly, where every instance of NetScaler VPX runs on its own Core using defined Memory and Interface queues. In this model every NetScaler is version inde
pendent and could run different maintenance operations at same time. Hence if you are looking at True Multi-tenant solution then SDX is your platform and today we can run 80 VPX instances on single SDX platform.
Second form of Multi-tenancy was defined in NetScaler using Traffic Domains focusing on network layer.
This order of Multi-tenancy helped us to enable the IP overlapping use cases for different Enterprise requirements. It helped create separate network paths and routing tables such that your traffic goes through in isolation with respect to other tenants hosted on the same appliance.
We got these solutions in place… so Why Admin. Partitions???
While we got the 2 explained approaches, they were kind of 2 different extremes. Over the years we have experienced that customers want software level Multi-tenancy which is easy to define, control, operate and manage without getting into the hardware level details. Essentially you can call this as Logical ADC where you can isolate ADC services, configuration, entities, network path etc. without getting into hardware hard-walling. Also as Citrix works very closely with Cisco on replacing the ACE appliances, we needed a Multi-tenant model which was very close to the ACE context model. Following is the representation of “Why”
As we understand the core reason behind why we created this new infrastructure, different customers have different reason and use cases for using Admin Partitions. Let us look through the key use cases it enables.
Enterprise Use Cases:
- IP overlapping
- Virtual Routing
- Entity space separation
- Authentication and Authorization
- 1 admin – multiple Partitions
Service Provider Use Cases
- Many of Enterprise Use Cases
- GUI/CLI/API Separation
- Monitoring and Stats Separation
- Unique configuration file per Partition
- Audit Logs for every Partition
- Conn/Throughput/Memory limits
- External RBA for Partition Access
Cloud Deployment Use Cases
- Many of the ones defined above
- API driven definition of Partitions
- Ability to tie Applications to Partitions
- Integration with Orchestration layer
Here is how current Enterprise NetScaler deployment looks without a Partition where a central administrator manages the entire deployment including all Apps being load balanced through NetScaler.
The same deployment changes with having individual Admin Partition for every Application associated with their own administrators.
All these Application specific administrators get their own login UI and a way to cleanly manage their App without knowing about the co-existence of other Apps or administrators on same appliance. The administrators can define their own SNMP managers and also the remote management aspect for Partitions. Configuration isolation is another major aspect which is taken care of as every Partition maintains its own ns.conf file. Hence it becomes very easy to manage their application deployment through Partitions.
Admin Partitions are defined in software
Thus we can define many more Partitions without getting into any hard limit. On the upper hand you can configure 512 Admin Partitions on any NetScaler appliance. When we say “Any”, we really mean it as you can use Admin Partitions on any NetScaler appliance like MPX, VPX and VPXonSDX. The GA release for Admin Partition is available at:
There is lot more interesting stuff around Admin Partitions which we will cover in next set of blogs. Do provide us your feedback!