Jump to content

Recommended Posts

  • Employee
Posted (edited)

High availability because downtime is not on my agenda today.

Power goes out, Internet connectivity goes down, it is just a way of life. We have more trustworthy grids, but outages do happen occasionally and, in some areas, more than others. With outages comes loss of productivity and negative user experience. Omnissa Horizon 8 is designed to make sure outages are not impacting your experience and productivity, learn more about how in this blog.

Keep your friends close; keep your data closer.

Employees are not just working from the headquarters (HQ) office but also from branch offices. Employees in branch offices need access to data just as employees in HQ. In the EUC industry it is a well-known design principle that says that employees should be close to the data they work with. The reason for that is that everything that travels distance will start to see latency, and latency equals bad user experience.

Quick lesson on latency “Distance equals latency, with latency comes a lower throughput. Keep your desktops and data close. TCP is unforgiving”.

To access data stored at HQ, they could connect to a desktop through the main datacenter and work with the data there. But let’s be honest, that would just be silly to do. The design principles that apply to data also apply to virtual desktops. Virtual desktops and apps should be in proximity to the users who should be close to the data. Anything to keep the latency monster at bay. Because of this, we designed Omnissa Horizon 8 to work in a multi-datacenter setup with Cloud pod architecture (CPA). We will call it CPA from here on forward.

Latency and user experience aren’t the only reason for multi-datacenter design. Think of downtime and the impact that has on productivity. What if you can take the risk of downtime away by building independent datacenters? Independent but connected, or connected but independent, if we look at it from a downtime perspective. Omnissa Horizon 8 CPA is an independent but connected / connected but independent high availability solution built for enterprises. Let’s dig a bit deeper into this.

What is the magic behind this?

Omnissa Horizon 8 is deployed in what is called a POD. A grouping of components to deliver brokering and gateway functionality while provisioning desktops and apps. Multiple PODs can be grouped into sites, just for logical reasons of management.

image.png.292bdff54455b989839c4948466ee1d8.png

Figure 1 Omnissa Horizon Pod design.

A POD is, at a minimum, a collection of the following components.

  • Brokering servers, called connection server,
  • Access Gateways called Unified Access Gateway,
  • A platform with management to run your workloads on.

Together these components enable you to create and deploy desktops and applications, allow users to connect to them from any device, any location, any time. The diagram below shows the basics, employees connect either through a gateway or directly to the broker depending on their whereabouts. Requests are brokered and desktops or apps are assigned to employees.

image.png.f03e8f256fa44fbb8642246276a3212d.png

Figure 2 Omnissa Horizon Logical components.

What about high availability?

The question of course is, how do I make sure that resources are available, also when there are connectivity issues between datacenters?

We just keep it simple; Horizon 8 enables you to deploy up to seven (7) Connection servers. Whether you need seven is up to you, fewer will most certainly be able to manage the load as well but depending on your high availability requirements, you might want to deploy more. There is no conclusive answer, N+1 is the minimum, but you need to ask yourself how impactful the downtime is. If it is, deploy more and spread them over the hosts. Connection servers share a database to keep up with everything that is going on in the Horizon 8 environment. You can add or remove a Connection server very quickly if required. One or more Connection servers going down (depending on the number you have deployed) will not affect the working of the environment.

While we never design for maximums, there is no where to go once you reach that, they are there and good to have knowledge of. One Connection server can manage 4000 instant clone desktops and a logon rate of 1 user per second. It also can manage 4000 active sessions alone, adding more Connection servers will very quickly bring up the number of sessions the environment can service. Check out this page for all config maximums.

The same goes for the Unified Access Gateways, if your users are primarily internally located, then high availability beyond N+1 isn’t really necessary. If your users are hybrid, things change.  There are good Tech Zone documents about this topic, please familiarize yourself with this before deploying. Horizon 8 is a very robust solution, but it still needs a proper design. Tech Zone resources are shared at the end of the blog post.

Cloud Pod Architecture (CPA), where the magic happens.

In the previous section I explained the components and how it works in one POD (for ease of explanation say, in one datacenter). But we live in a bigger world and organizations are larger and ever expanding. Let’s say we have a NY office with a Branch office in LA. Desktop, Apps and data are located in both datacenters. How do we connect them to make sure users can work from either location, or use desktop locally but also remotely in the other datacenters?

This is when Cloud Pod Architecture walks on stage.

image.png.347fe59ccd2ff13f4dfa60ccf25151df.png

Figure 3 Omnissa Horizon Cloud Pod Architecture

The diagram shows the most basic form of CPA. Both sites have independent connection servers running. CPA enables the ability to link together multiple PODs to provide a single large desktop and application brokering and management environment. It adds a Global Data Layer that activates inter-POD communication between the connection servers of different PODs.

By adding CPA, you enable entitling employees to desktops in multiple PODs, your world suddenly got bigger, and management is done centrally. No more need for locally assigned desktops. For more information about the abbreviations used in the diagram, check out the sources listed at the end of the blog post.

Remote agents

There is one more feature to talk about, it goes beyond what we talked about before. Omnissa Horizon 8 Remote agent, for when you want to connect outside of your POD to a remote location. Omnissa Horizon 8 remote agent supports connecting to resources running in locations without a connection server. This can be used when you need extra capacity fast.

image.png.d8635540dd74e9fc7d982e746401225a.png

Figure 4 Omnissa Horizon Remote Agent design.

Enough talk already, how does it work when my connection is down?

Let’s go into a real-life scenario, let’s play a game of what happens when….?

What happens when my primary datacenter and my branch office datacenter get disconnected? As you read earlier in this blog, the beauty of a CPA is that it is connected but independent. That means that in case of a loss of connection, nothing happens to either environment. Nothing, absolutely nothing.

Desktops and applications running in LA won’t be reachable from NY but that is because the connection is down. Desktop and applications in NY will be available for employees in NY, and similar for LA desktop and applications, they are available for local employees.

The only thing that is lost is the connection between the two Pods’. There is no global assignment anymore. The possibility to connect to desktops on the other side is gone, but for local usage, nothing changes.

The difference cannot be bigger. Consider our competition where their management console and ability to create assignments is no longer accessible. When the connection between two Horizon PODs goes down, everything in that POD remains functional, it is just the connection to the other POD and thus global connections that are gone. The management console is still available, all virtual machines are still manageable, can be refreshed, deployed, and assignments can be made. There is nothing in that local POD that stops working with Omnissa Horizon. A vastly different outcome compared to our competition where management consoles and new assignments are unavailable, and where machines are in an unknown power state.

Is latency going to be an issue?

The question was asked if latency would be an issue with CPA? Latency is always an issue when your solution depends on connectivity with the main site. As mentioned before, distance will have a negative impact on latency.

The good news is that Omnissa Horizon 8 CPA does not have that limitation, there is no direct communication required to keep the localized environments up and running, as said “connected but independent”.

What is the catch?

There is no catch, the limitations in a Cloud POD architecture are limits in connections, sessions, PODs and total connection server. But guess what? That isn’t your issue because these are the limits, you won’t reach them. As mentioned before, please don’t scale for maximums, leave headroom.

image.png.befd633c8d85309d860184aca32cdbc3.png

And image the scalability when you can connect NY with LA, London, Berlin, Amsterdam, Atlanta and so on, 50 PODs over 15 sites all connected but independent.

What if all my brokers go down?

I can see the concern, which would be bad, right? We need to go back in time and talk about the birth of hypervisors and how they introduced a feature called High availability. When deploying multiple connection server instances, you make sure they are not residing on one host, that is rule 1. If a host is experiencing a failure, high availability of that hypervisor will move the VM’s on that host to another host. You can set priority for certain VM’s to be moved first, that is Rule 2. Remember, you can deploy seven and you have high availability with your hypervisor. Rule 3 is that you deploy more than one (N+1) and will deploy a number that honors your HA requirements with a maximum of seven.

To summarize:

  • Rule 1: Spread out your connection servers over your hosts, not all eggs in one basket.
  • Let the hypervisor high availability feature do its job.
  • Rule 2: Set priority to move the connection servers early on.
  • Rule 3: Deploy enough connection servers to honor your HA requirements.

If all hosts are down? If all hosts are down, you have bigger issues. Chances are your datacenter is down as well. Even if this happens, we have a solution, Horizon Cloud could be the way to go, with the On-Ramp feature you can have desktops assigned in Horizon Cloud. With your on-premises datacenters down, cloud desktops with universal brokering are available.

We run heavy applications in our London datacenter, is that an issue?

An Omnissa Horizon 8 POD is an independent running environment, there is no dependency on any other POD. We know that other solutions require different setups depending on the applications that are deployed but we don’t want to make life harder than it is, you can run whatever you like in a POD. Just make sure your data is close enough for good user experience.

Extra infrastructure is worse for my TCO, right?

Any solution out there that enables employees to work locally, when the connection is gone, will have infrastructure deployed on site. There is no magic in the world to connect an endpoint to a virtual desktop without components to manage that.

The components required to set this up for Omnissa Horizon 8 are just two connection servers, that’s all. You can extend that with a database for event logging, a Unified Access Gateway for external connections, but you don’t have to. It will work with just two connection servers, even with one if you like to gamble on availability.

Competing solutions require multiple gateway servers for internal access, connectors to manage the brokering when the broker is not reachable anymore, and external proxy servers for external access. That, to me, sounds like a bigger hit to your TCO than with Horizon 8.

Enterprise ready, designed to operate under any condition.

In this blog we discussed Omnissa Horizon 8 and its high availability design, how it operates and how it deals with a disaster and how to scale your environment. Omnissa Horizon 8 is built to deal with outages and disconnects of environments, deploy it and evaluate it.

Resources on Tech Zone

Useful resources are available on Tech Zone, learn how the architecture works before you deploy it.

 

 

Edited by Rob Beekmans
  • Like 6
  • Insightful 6
  • Rob Beekmans changed the title to High availability because downtime is not on my agenda today.
Posted

A very intressting topic would be, how can you manage and share all the applications from AppVolume including the Writable Disk accross the data centers. Or how you can distribute golden master images with various snapshots accross pods 🙂 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...