This post has already been read 35354 times!
Many organizations are nowadays busy with questions regarding the IT Cloud. It’s not the question if they want cloud services, but more when and how. Some organizations are still busy with Cloud strategy whilst other organizations are already embracing cloud with services like SaaS or IaaS.
One of the cloud related topics is around the virtual Desktop (DaaS). In this blog article we will be focusing on the VMware Horizon DaaS platform and why this platform is interesting for Service Providers to compete in the DaaS market.
So you are a Service Provider and maybe thinking about or already provide virtual desktops and applications to your customers. How do you provide multi-tenancy or keep the operating roles between you and your customers separated?
What is Horizon DaaS?
VMware Horizon DaaS, formally known as Desktone, is a Desktop-As-A-Service (DaaS) cloud solution built on VMware technologies and solutions to deliver cloud computing to users connected from any type of devices.
The first question around Horizon DaaS I often get from customers, is the way it differs from the Enterprise solutions like VMware View. Although many things are different between the two VMware solutions, they share the same Protocols like PCoIP and Blast. Also the agents within the virtual desktops are the same as in View. Both platforms can be used to deliver VDI desktops in a statefull (Static) or Stateless (Dynamic) scenario or deliver RDSH desktops and applications. Users have to ability to connect to their desktops from the VMware View client or use the web portal.
The table below shows a quick overview of some of the major differences between both products:
|VMware Horizon DaaS||VMware Horizon View or other broker|
|Based on Linux Appliances||Installed on Windows operating systems|
|Build for multi-tenant scenarios||Build for on premises customer scenarios|
|Automated deployment of appliances (in pairs)||Separate solution needed for automated deployment.|
|Built-in role separation by having multiple management interfaces||Single Management interface|
|Automated Installation of DaaS components||Automation have to be done with other tooling|
|Automated deployment of platform updates||Manual installation|
|Built-in load balancing mechanism||Load balancing by using 3th party solutions|
|Built-in PostgreSQL Database||Centralized SQL database needed|
|Based on OPEX models||Based on CAPEX models|
|Licensing based on allocated quota (VSPP)||Licensing on current Connection User (CCU) vs. Named User (NU) Licensing|
In this article I will explain two of most important differences for Service Providers:
- Demarcation within the platform
If you want to achieve a multi-tenant environment with VMware View or any other Enterprise VDI Solution, you probably have to have a dedicated environment per customer, resulting in many different environments with a lot of infrastructure components. All those different infrastructure servers must be managed which could be very time consuming.
The VMware Horizon DaaS platform consists of multiple Linux based virtual appliances:
- Service Provider Appliances – The Service Provider appliances provides the web based Management Console for overall management of the solution and act as a transit point for enabling SSH access to all management appliances within the data center.
- Resources Managers – The Resource Managers appliances integrates with the Virtual Infrastructure and abstracts all specifics to the tenant appliances.
- Tenant Appliances – The Tenant Appliances provides the Administrative and User portal to manage and access the customer (tenant) specific virtual desktop environment.
All appliances are managed by the Service Provider but only the Service Provider and Resource Manager appliances are part of the Service Provider network. The Service Provider network is typically a network where Active Directory, DNS and other services from the Service Provider itself are hosted. The Tenant appliances are participating in the network of the customer; this network is referred as the Tenant network.
For security reasons all appliances are connected to a backbone link local (BBLL) network for management purposes. This is a non-routable network within the 169.254.x.x IP range. The Service Provide is able to manage the Tenant Appliances from the Service Center portal (See Management Portals below) over the BBLL, however traffic between the Service Provider network and tenant networks is not possible.
To separate customer environments from each other, different vCenter (clusters), dedicated networking, storage, and compute can be used keeping things securely separated.
Tenant Appliances and virtual machines, either VDI desktops or a supporting infrastructure servers like Active Directory and File Servers, are all participating in the network and active directory domain of the customer. To enable access between the tenant environment in the cloud and the customer on-premises network, a VPN or MPLS can be used.
Another big difference between the two solutions is the way role separation is delivered. With a typical Enterprise VDI solution in a Service Provider scenario, there are a few design considerations:
- Is the VDI solution part of the Customer Active Directory?
- If the brokering platform is managed by the Service Provider, they need to have administrative permissions in the customer Active Directory.
- The way role separation is arranged within the tooling.
- How is the customer taking care of the images used in the VDI solution? vCenter access?
- What to do with Service Accounts (security issue?)
Horizon DaaS comes with three different portals in total:
The Service Provider Portal (Service Center) is used by the Service Provider and integrates with the Service Provider Active Directory. This portal is not accessible to the customers and is used for overall management of the platform.
Each enrolled tenant in the Horizon DaaS platform has its own unique Enterprise Center portal where the customer can manage their own VDI environment, such as creating or editing patterns (images), creating or editing pools etc. The portal runs on the Tenant Appliances which is part of the Customer network and the customer Active Directory. Customers must use their own AD credentials to access Enterprise Center for administration.
The end-user’s portal also runs on the Tenant appliances. Users are authenticating with their regular AD usernames and passwords. The Service Provider typically doesn’t have an account in the domain of the customer and is unable to access the Enterprise Center and user portal.
Because each portal has its own functionality and the Service Provider and Tenant portals are using their own active directory domain, there is a very clear separation of roles and responsibilities. There is no integration between the Customer and Service Provider Active Directory which is a big advantage.
The solution as described in this blog will make hosting DaaS in a multi-tenant scenario very easy and keeping roles between the providers and customers very clear. Because of its architecture and automated deployment of new appliances, VMware Horizon DaaS is very easy to scale and very easy to onboard new tenants.
If you are not a Service provider but interested in VMware Desktops in the Cloud, there are multiple options from which you can choose:
- Contact a Service Provider who has the VMware Horizon DaaS offering. For example XtraDesktop in the Netherlands
- VMware Horizon Air based on the same software technology but operated by VMware.
- VMware Horizon Air Hybrid mode, based on similar technology and enables unified management of on-premises virtual desktops and applications through a single cloud control plane.
For more information, please feel free to ask or go directly to: