According to Wikipedia, multi-tenancy is defined as:
“Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants) … With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance.”
If you are a Citrix Service Provider (CSP) or considering joining the program, you need multi-tenancy so that you can deploy and manage a single instance of Citrix infrastructure (thus saving costs) while continuing to meet the individual expectations of your tenants like:
- Isolation: Isolating users from users of other tenants to prevent leakage of sensitive information or from getting affected by any malicious activities of other tenants.
- Performance Guarantees: Ensuring that performance of one tenant is not negatively affected by activities of other tenants.
- Customized Experience: Enabling each tenant to feel like their hosted environment was specifically designed for them.
- Self-Service Administration: Providing the ability for tenants to be able to perform some level of administration themselves.
- Cost: Delivering the right mix of the above capabilities at an appropriate cost.
So what is XenApp’s story is this space? Can a single instance of XenApp be deployed to serve multiple tenants?
The answer is YES! The latest XenApp 6 architecture supports several options for multi-tenancy that provide different blends of isolation, performance management, customization, self-service and cost. As a CSP, you can determine which of these meet the needs of your customers, and develop offerings and price-points to match them.
In this blog, I am going to describe three methods of XenApp deployment to support multiple tenants.
In a Shared deployment (Fig 1), there is one XenApp farm such that the infrastructure components as well as the session hosts are shared between tenants.
The key characteristics of such a deployment are shown in Fig 2:
- Users from multiple tenants can have sessions on a single XenApp session host. The XenApp session hosts must be appropriately locked down in such an environment – so that the possibility of a user of one tenant negatively affecting the users of another tenant can be minimized. However, there is still a chance that a user may be able to compromise a server (thus impacting users of another tenant).
- You can guarantee performance to users by using the CPU Utilization Management feature in XenApp.
- A separate Web Interface site can be created with custom branding for each tenant. In addition, Windows and Citrix policies can be configured in Active Directory to provide a highly customized experience to users. (e.g., wallpaper, theme, Citrix HDX settings, etc.).
- This method of multi-tenancy is extremely cost effective because all of the infrastructure costs can be spread across multiple tenants.
Partial Isolation Deployment
In a Partial Isolation deployment (Fig 3), there is one XenApp farm such that the infrastructure components are shared between tenants – but the session hosts are not.
The key characteristics of such a deployment are shown in Fig 4:
- There is a dedicated pool of session hosts per tenant, such that only users from the same tenant can have sessions on a particular XenApp server. The XenApp features of Worker Groups and Worker Group Preference help easily create such a deployment. You should still lockdown the XenApp session hosts, so that users are only allowed to see/touch what they need to.
- Since users from one tenant can have sessions only on designated XenApp servers, a user cannot negatively impact users of another tenant in terms of performance. You can further guarantee performance to users by using the CPU Utilization Management feature in XenApp.
- In addition to the customization capabilities mentioned in the Shared deployment, you can have custom machine images for XenApp session hosts for a tenant.
- You can also allow the tenant to perform some-level of administration for their pool of session hosts e.g., helpdesk activity which involves viewing which users are logged onto which servers, and assisting with troubleshooting via shadowing or resetting a session.
- Though each tenant has dedicated session hosts, the costs may not be much higher than that of the Shared deployment method, if the session hosts are adequately loaded. Hence, a range is shown on the slider in Fig 4.
This deployment method offers a good blend of multi-tenancy capabilities at a very reasonable cost and hence should be preferred.
Full Isolation Deployment
In a Full Isolation deployment (Fig 5), one XenApp farm with dedicated infrastructure is deployed per tenant. None of the components are shared.
The key characteristics of such a deployment are shown in Fig 6:
- Tenants are completely isolated as even the brokering operations are serviced by dedicated infrastructure servers for a tenant.
- The performance guarantees are pretty much the same as that of the Partial Isolation deployment.
- The custom-experience aspects remain the same as that of the “Partial Isolation” deployment.
- As a service provider, you have the option to allow the tenant to perform a much higher level of self-service administration e.g., helpdesk activity, managing session hosts, managing applications, etc.
- The costs are higher for this method of deployment as the infrastructure components are not shared between tenants.
In summary, the XenApp 6 architecture supports multiple deployment methods that allow you to achieve multi-tenancy while meeting tenant expectations to varying degrees. The method you choose should be based upon your tenant’s expectations of isolation, self-service, performance guarantees, custom experience and costs. You should check out Calvin Hsu’s blog “Multi-tenancy in Practice for Cloud Service Providers” to find out what we are actually seeing in practice.
We in the Cloud App Delivery group are working on further enhancing isolation and improving experience for a multi-tenant XenApp deployment as well as making it easier and economical to deploy and manage multiple instances of completely isolated environments.
To learn more, visit us at Synergy 2011