So in this video we'll discuss the architecture and design of horizon 7
As a reminder this is a companion to the full reference architecture that has a
complete section on the architecture of horizon 7 on techzone.vmware.com
So let's start by looking at the core components of horizon 7. So the typical
connection we're going to have a horizon client either installed or using the
HTML access client on the browser and it's going to authenticate to our
horizon connection server. Now the Horizon connection server will then use active directory
to authenticate as well as optionally other methods. Once we have authenticated
and chosen a resource that we're entitled to, the client will then be
instructed to form a protocol session out to wherever the agent is running
either inside our virtual desktop or our RDSH server if we are using published
applications. So then if we're using an external connection, so the users coming
from either the internet inbound or between different security zones
internally. The horizon client will communicate through the unified access
gateway to do that authentication in a very similar manner and also when it forms a
protocol session the protocol session will go via the unified access gateway
so for more detailed and unified access gateway in the architecture of that we
have a separate video on our complete separate design section in the reference
architecture. So one key concept when we look at
architecting horizon 7 is pod and block architecture. With this what
we're trying to do is use a repeatable way of designing to get predictable
performance. So in the block we have a virtual Center controlling one or more
vSphere clusters this is where we're going to run our workloads our desktops
or our RDSH servers. Now we can only go up to certain scale and we'll get into
those numbers in a minute but once we want more than that virtual Center and
those vSphere clusters are able to handle we repeat and this is where the
predictability and scalability comes in so we can just add more and more blocks
up until we get to a certain point where we want to kind of define what we call
the pod and the pod really is defined by a certain scale I can get to and is
defined by those connection servers how many connections can I drive through
those connections servers. So there is a best practice knowledge-based article
that will give you guidance on this and we recommend you go out and look at this
So for the block, really think about it's being bound by the virtual Center
server. How many virtual machines can I comfortably drive through that Virtual
Center. How can it handle provisioning tasks, creating tasks, power on tasks, if that's
happening, and any other kind of tasks that we're going to ask the Virtual
Center to take on. So different numbers depending of what type of clones
were using. The pod that, as I mentioned earlier, is bound by those connection
servers. How many connections can I drive through the total number of connection
servers. So best practice, each connection server should handle roughly about two
thousand connections. We can go all the way up to seven connection servers
within a pod but typically we want to keep the pod to about 10,000 connections
When we want to go up above 10,000 in a pod what we do is we use cloud pod architecture
and this allows it to federate multiple pods together to give a global
entitlement across those pods so either within a site where I've got to a large
environment and I've got multiples of 10,000 I can group those individual pods
together and then entitle people to them at a global level. But also very useful
when I go across sites so if I'm doing disaster recovery or multiple sites
again I maybe don't really care where I place my users I just use a global
entitlement to group all my environments together. Now where I do care about
placing my users we've got additional control with home sites and scope
policies to help you kind of tailor where a user gets directed to
What this looks like then when we look at a multi-site design is we want to see
each site with this own set, it's own pod. So own set of connection servers and each
individual site should have a completely separate pod with its own set of
connection servers as well. Now what we will then do is federate
them together with cloud pod architecture so we can then give global entitlements
use home sites and scope etcetera to control how we direct people
now our users can be active active or active passive. Typically we're going to
see actor passive. Where we're going to say this user or this group of users
will by default get delivered out of site 1. For in a recovery scenario,
absolutely I'll recover them and give them the service out of site 2. Active
active, as a comparison, I don't really care where that user gets serviced from
either site 1 our site 2. Now the challenge with that approach
with the user is making sure their data their files etc
is available in either site 1 or site 2
if we don't care where we're going to give them a desktop from
how do we make sure their data is available for them in that site as well
that's typically the big challenge
what is not supported when we come to multi-site is stretching a pod
or the connection servers between two locations
so we don't want to see connection servers existing in site 1 and site 2
they belong to the same pod. We're going to run into communication issues between
the connection servers and really for this reason we do not recommend this
don't want to see this in production and just to be clear not supported
Now a stretched option that is supported is using VSAN Stretched cluster
And really we're stretching at the storage layer here. The key here is one set of
connection servers and they all exist in one place at one time. So in the diagram
I've got all my connection servers in site 1. If I had a failure or some
outage in site 1, all those connection servers would be restarted in site 2
So I'm never stretching my pod. I'm never having connection server as
active in site 1 and site 2 at the one time. I'm going to control that using
vSphere HA and rules but they're only be active in one site at that time
So for more detail on this please refer to the reference architecture on techzone.vmware.com