Citrix ADC Admin Partitions Validated Reference Design

Feature overview

Citrix ADC Admin Partitions enables multi-tenancy at the software level in a single Citrix ADC instance. Each partition has its own control plane and network plane.

The key benefits of Admin Partitions are:

1. Control Plane – Isolated configuration and management
2. Data Plane – Key partition data and files tightly controlled within partition boundary
3. Network plane – Traffic is isolated with its own network configuration. Two partitions on same Citrix ADC do not see the same traffic passing through each partition

This document covers the typical use cases in detail that are enabled by Admin Partitions and guidelines for using Admin Partitions in customer environment.

Admin partitions use cases

Enterprise use case for admin partitions

Citrix ADC admins can partition a Citrix ADC into multiple ADCs and assign the partitions to different application administrators like Microsoft SharePoint and Microsoft Lync. Each application administrator/owner can make his own configuration changes.

IP overlapping: The key benefit of IP Overlapping is that the same IP range can be used across different Admin Partitions without any IP conflict. For the backend servers, you can use the same set of private IP address. In an IP Overlapping scenario, the VLANs cannot be shared.

Virtual routing: Routing configuration is unique to each partition and each partition owner can configure their own routing protocols.

Name space isolation: Entity names are unique across different partitions, so you can use the same names across different Admin Partition.

Reference diagram:

Single Nic – Multiple Vlans

IP overlapping:

Service provider use case for admin partitions

Service Providers can partition a Citrix ADC and assign it to individual clients based on their bandwidth requirements and number of concurrent connections.

Service Providers can develop orchestration tools using NITRO APIs to get input from their individual clients on their bandwidth requirements and concurrent connections, create partitions and assign them to their clients.

Below is a set of isolations that aid Service Providers:

Filesystem: Each partition is assigned part of a file system and files stored in that respective partition space are not visible to other partitions. SSL certs/keys are stored in that partition and are not visible to other partition owners, thereby making each partition secure.

Shared VLAN: In a typical Service Provider with a multi-tenant deployment, the end customers might not have independent VLANs for incoming traffic. The Shared VLAN feature shares the VLAN when it is not possible to have dedicated VLAN.

VLAN tagging: A single interface can be shared across multiple admin partitions and isolated by using a tagged VLAN. For an untagged VLAN, use a shared VLAN.

Troubleshooting and debugging: Admins can see traffic stats of each partition independently and separate out the logs by filtering by the partition ID. The trace function ensures partition independence since the trace fired from one partition will never see packets from another partition.

Reference diagram

Guidelines for implementing admin partitions

Admin Partitions enable the sharing of resources including bandwidth, memory and concurrent connections, and provides isolation at the network, data, and management plane.

Partition of resources

ADC admins need the following details for configuring admin partition:

1. Connections – (Number of TCP Connections)
2. Memory
3. Bandwidth Requirements

The number of connections and bandwidth requirements depends on the application and the traffic handled by the respective partition. The ADC admin in consultation with the application admin will get the connections/bandwidth for a partition.

Memory allocation guidelines

The amount of memory allocated to a default partition should be a minimum of 50% of total memory available for the following reasons:

1. To provide flexibility to the customer in the future for increasing the memory of other partitions in case the limit is reached.
2. The integrated caching memory for all partitions is taken from the default partition.

Total Memory that can be consumed by a PE is 4 GB. So total of 2 GB can be allocated to all partitions excluding admin partition.

Memory assigned to admin partition is used for two purposes:

1. Storing static objects (configuration, SSL keys)
2. Dynamic objects – depending on the list of features enabled and the number of connections the memory allocated for dynamic objects vary

The ADC admin uses the connections and bandwidth requirements from the app owner and the below guidelines to come up with the memory estimation.

Guidelines for allocating static memory for config

Table 1 lists the commonly used configs and the required memory.

Table 1

The configurations are replicated across PE’s, so the above requirement needs to be multipled by the number of PE’s.

Guidelines for dynamic memory

Table 2

Dynamic memory = sum of the memory calculated from each of the above row in the above table.

Add a buffer of 10-20% to the total memory calculated.

Memory requirements for some features like AppQoE are not provided because the memory consumed from the partition memory is negligible for these features and the buffer of 10-20% is sufficient to handle them.

Total Memory = Static Memory*No of PE’s + Dynamic Memory

Let’s assume we come to a conclusion that the memory required is 1 GB and number of packet engines are 4. Then, for that particular partition, the amount of memory needed is derived by the below formula:

Admin Partition memory configuration = (Amount of Memory required/Number of Packet Engines)

Admin Partition Memory = 1GB/4 = 250 MB

Behaviors when the resource limit is reached

1. Connections – new connections will be dropped
2. Bandwidth – new traffic will be dropped
3. Memory – new traffic will get dropped

You can configure SNMP alerts which are triggered if the particular partition’s resources are exhausted. List ofSNMP Traps are given in the Additional Resources Section.

Network plane

VLAN: Configure and assign different VLANS to Admin Partitions to maintain network-level isolation.

Routing: Routing configuration is unique per partition.

The ADC admin in consultation with the network admin (with input from application admin) define the VLAN and routing-related configurations based on the network topology.

L3 Parameters: Can be partition specific. Some of the L3 parameters are Drop DF Packets, ICMP err threshold, overridernat, etc., and the input should come from the network or ADC admin.

Control plane: User experience

Admin Partitions provide isolation at different levels allowing the user to securely manage an isolated ADC instance.

Different levels of isolation include:

1. UI Page – Configuration, stats displayed only for the partition
2. Diagnostics – Trace isolation. Trace will not capture the traffic of other partitions
3. SNMP Alerts - configured at the partition level
4. Log-level isolation

UI-level isolation can be configured using the following method:

1. In the respective partition, enable mgmt. access for one SNIP and use that SNIP to access the GUI. This will provide UI-level isolation and visibility only into that partition.

Table 3

Administration partition for enterprise use case

This section describes an enterprise customer use case with four applications using Admin Partitions.

Customer Requirements

• Needs to host 4 applications

• Each application has its own administrator and a different set of ADC requirements. The table below lists the applications and their unique requirements.

Table 4

From the above requirements table, it is clear that each of the applications needs a different set of configurations to realize the complete benefits of Citrix ADC. It’s recommended to partition the Citrix ADC and assign those partitions to the respective application owners.

Bandwidth and connections estimation

Outlook and SharePoint

Bandwidth for the enterprise applications like SharePoint, Exchange, and Lync are dependent on the:

1. Number of concurrent users
2. Type of usage
   1. Exchange – average size and number of messages
   2. SharePoint – type of files, ratio of read vs. write

The application admin calculates the bandwidth requirements using the above two factors and provide the information to Citrix ADC admin for configuration of the admin partition.

Examples:

Bandwidth for Outlook 2010: Types of users (light, medium, heavy, etc.). For medium users, send 10 emails, receive 40 emails, avg. msg. size 50 kb = 2.15 Kbps. For 1,000 users, the required bandwidth is 2,150 Kbps.

Bandwidth for SharePoint: Number of Users = 1,000. Assuming 20% of users are active at any point in time and the average page load size is 100 KB and accessing around 10 pages during a period of 1 hour:

= 100 KB * 200 * 10 per hour = 200000 KB/hr = 200000*8(8 bits per byte)/3600(no of seconds)

= 444 Kbps

Connections per sec = Number of active users * 10

MSSQL

Based on the rate of queries and size of response, derive the bandwidth and connections.

Enterprise website

Bandwidth Requirements: Average page size * Max number of users at any time * 2

Connections: Max number of users * number of connections per user

Example:

Bandwidth: 4KB10002 = 48000 Kbps

Max Number of Users = 1000 and number of connections per user = 10. The connections = 10K

If most of the users are from HTTP/1.1, then the number of connections per user would be 2–3, but if the mix is tilted more towards HTTP/1.0, then the number of connections would be 10–15. The multiplicative factor num-ber of connections per user varies 3–15 depending on the traffic/client mix.

Memory to be configured depends on:

1. List of configs in the respective admin partition – static memory. Refer to Table 1 for more details.
2. Dynamic Memory – Number of connections and type of connections (HTTP vs. SSL) – Please refer to Table 2 for more details.
3. Number of Packet Engines. Memory = (static memory + dynamic memory)/(number of packet engines)

Steps for ADC admin

1. Collect the bandwidth and connections for each application
2. Create three partitions for SharePoint, Database, and Outlook respectively. Use the bandwidth and connections from the previous step and assign it to respective partition. The enterprise website can be hosted on default partition if the customer needs AppFW as AppFW is only supported on default partitions.
3. Create users for each of the partitions and share the credentials.

4. Enable Integrated caching and set the cache memory. Cache memory is taken from the cache memory configured in the default partition. For detailed information on the allocation, refer to the appendix section of IC.

   1. Assign cache memory after consulting with the ADC admin. Try to allocate 30–40% of the total cache memory in the system. If the total allocated is 10 GB, allocate around 3-4 GB for cache in the SharePoint partition.
   2. Application owners should initially monitor the caching statistics to check the level of benefits.
   3. Check the Caching Objects Hit ratio and, if large number of cache objects have a high hit, increase the size of IC memory for that particular partition.
5. Enable Compression
   1. SharePoint will publish files of different types (Excel, PowerPoint, Word) and the same files, if compressed and delivered to clients, will result in reduced bandwidth usage.

Database user

1. Configure the CS, VIP, and the backend servers.
2. Use Content Switching to split the read/write requests and redirect to the respective set of servers.

Enterprise website

1. Configure the VIP and backend servers.

2. Enable integrated caching.

   1. Enterprise website is in the default partition so the unused cache memory from other partitions is available for Enterprise website. So assuming SharePoint and Outlook each consume 35%, then total consumed would be 70% leaving the remaining 30% to default partition (Enterprise website). If total cache memory is 10 GB, the default partition would have 3 GB of cache memory.
   2. Application owners should initially monitor the caching statistics to check the level of benefits.
   3. Check the Caching Objects Hit ratio, and if large number of cache objects have a high hit, then increase the size of IC memory for that particular partition.
3. Enable front-end optimization.
4. Enable AppFW.

Service provider admin partitions use case

The Service Provider hosts Microsoft applications and provides the IIS, SharePoint, and MSSQL applications as a service. Their customers typically have these requirements:

Customer requirements

• Customer 1: Accesses database server and their read/write split is 90:10 and end customer wants to configure custom SQL-related filters

• Customer 2: Accesses web app through SSL and end customer wants control over their SSL certificates

• Customer 3: Accesses hosted SharePoint from Service Provider

The Service Provider hosts a portal for their customer to:

1. Select the application it wants to host
2. Bandwidth requirements

The Service Provider hosts a portal for their customer to:

1. Select the application it wants to host
2. Bandwidth requirements
3. Connections

Based on the selection, the Service Provider can configure the appropriate partitions with configurations related to specific applications in the back-end using NITRO APIs.

Based on the application selected by the customer, choose the appropriate option.

1. Web app using SSL
   1. SSL certificate option to be bound to VIP
   2. HTTP to HTTPS redirect
   3. SSL Profile related parameters
2. SQL
   1. SQL related filters that customer wants to configure
3. SharePoint
   1. Caching memory limit and rules
   2. Compression policies

The Service Provider follows one of the two options to implement the exact requirements after the creation of Admin Partitions.

Configuration option 1:

The Service Provider gathers the requests from the customer and executes them on the respective partition.

Configuration option 2:

Automate Admin Partitions using NITRO APIs. Inputs can be gathered from front-end portal and in the back-end NITRO APIs can be executed to configure the partitions.

Feature considerations

Feature Support: Admin Partition is supported for most of the features and only not supported for a few features. For the exact list, refer to Citrix Docs and check in the particular software release. It will contain a table which lists the supportability matrix.

Configuration limitations. Administration Partitions is not supported in:

1. Clustering

2. MPX-FIPS appliance

Conclusion

The key benefit of Admin Partitions is to enable the separation of the ADC at the software level and provide a secure, isolated user experience to each partition owner.

Additional resources

Troubleshooting tools

Common Issues in Admin Partition:

Admin partition on VPX on ESX:

• Non-default partition not reachable when custom MAC address is configured.

• Solution: promiscuous mode needs to be enabled on ESX for the non-default partition to work.

Configuration failure:

• Configuration might fail to throw the error Input files not present.

• Relative path needs to be used and not the absolute path.

VLAN configuration:

• Admin Partition VLAN supports tagged VLAN, so when the VLAN is tagged, the switch to which the Citrix ADC Interface is connected should be configured with appropriate VLAN. For untagged VLAN, use the shared VLAN configuration

Integrated cache memory allocation

To configure integrated caching (IC) on a partitioned Citrix ADC, after defining the IC memory on the default partition, the super user can configure the IC memory on each admin partition such that the total IC memory allocated to all admin partitions does not exceed the IC memory defined on the default partition. The memory that is not configured for the admin partitions remains available for the default partition.

For example, if a Citrix ADC appliance with two admin partitions has 10 GB of IC memory allocated to the default partition, and IC memory allocation for the two admin partitions is as follows:

• Partition1: 4 GB

• Partition2: 3 GB

Then, the default partition has 10 - (4 + 3) = 3 GB of IC memory available for use.

Note:

If all IC memory is used by the admin partitions, no IC memory is available for the default partition.

Commands for checking memory usage

• Stat system memory within partition will show aggregated system level memory allocation for the partition and stat partition name will show the percentage of memory used within partition.

>add partition p1
Done
>switch partition p1
Done
p1> stat system memory
done

Citrix ADC Memory Information:
Maximum Memory Available (MB): 50
Memory Currently Available (MB): 50
Memory Allocated (MB) 7
Memory Allocated (%) 14.95
InUse Memory  (MB) 7
InUse Memory (%) 14.95
Free Memory (MB) 42

>stat partition p1

Partition(s) Summary
   MinBW MaxBW MaxConn MaxMem

p1 10240 10240  1024  10

Partition Stats:

                       Rates (/s)   Total
Current Bandwidth         --          0
Current Connections       --          0
Memory Usage (%)          --          14
Total Packet Drops        0           7
Total Drops (KB)          0           0
Total Connection Drops    0           0
<!--NeedCopy-->

• Configuration memory: Since each configuration is replicated in every Packet Engine accordingly memory gets allocated inside every Packet Engine. For example, if “add lb vserver” command takes around 10KB in peach Packet Engine and we created 10MB partition in a 5 – Packet Engine system, then in total it consumes 50KB of partition memory.
• Precise value of memory requirement for a specic configuration can be measured by applying the configuration and running following command on Citrix ADC shell:

root@ns# nsconmsg -s nsppeid=0 -s nspartid=1 -g mem_cur_usedsize -d current
Displaying performance information
Citrix ADC V20 Performance Data
Citrix ADC NS11.0: Build 65.572.nc, Date: Apr 7 2016, 10:32:51

reltime:mili second between two records Thu Feb 23 13:45:18 2017
 Index rtime totalcount-val delta rate/sec symbol-name&device-no
    0  22681     1597631     8965  5333     mem_cur_usedsize partition_ctx(p1) (PART-1)
<!--NeedCopy-->

In this experiment, around 9KB of memory is used in PPE-0 for Partition ID 1. Every Partition configured on Citrix ADC has a unique ID.

The following command allows to measure memory estimation for complete system (including all Packet Engines) for a given Partition.

root@ns# nsconmsg -s nspartid=1 -g mem_cur_used -d current
Displaying performance information
Citrix ADC V20 Performance Data
Citrix ADC NS11.0: Build 65.572.nc, Date: Apr 7 2016, 10:32:51

reltime:mili second between two records Thu Feb 23 13:44:27 2017
Index rtime totalcount-val delta rate/sec symbol-name&device-no
 0   7000    7881865       6403    5333    mem_cur_usedsize partition_ctx(p1) (PART-1)
<!--NeedCopy-->

List of SNMP traps introduced in Citrix ADC 12.0

Additional references

Exchange Client Network Bandwidth Calculator Beta

How Much Bandwidth do I Need to run Microsoft Online Services