in this video we'll cover the architecture of VMware Workspace ONE
Access, formerly called VMware Identity Manager. now this video is an overview
please for the full details see the relevant sections in the reference
architecture document on TechZone. VMware.com
so let's start with the cloud-based or SaaS based architecture so this is a very
simple architecture here you consume a cloud-based service with the SaaS based
tenant and connect your users and device to consume that service most customers
will typically want to connect this to resources such as Active Directory or
other things that may reside or be located on-premises to do this you'll deploy
workspace one connectors in the locations where those resources are if
there are multiple locations you might want to spread out the workspace one
connectors to those multiple locations so you get your site redundancy back to
resources such as Active Directory controllers the workspace 1 connectors
do an out-bound connection to the SaaS tenant so there's no in-bound direct connection
communication now obviously you want to scale for redundancy so we will be
putting multiple workspace - and connectors to provide both scale for
load and for redundancy in case you have failure with the release of workspace
one access version 20.01 there is a new version of the connector at the time
of this recording this should only be used in apartments for a connectivity to
VMware Horizon or Citrix environments is not going to be planned
when integration to horizon or Citrix environment is planned the current
recommendation is to use a prior to version 19.03 so version
20.01 introduced three new services that run on workspace one access connector the
directory sync which synchronizes Microsoft Active Directory or LDAP users
and groups into the Workspace ONE Access service the user authentication
which performs Active Directory user and password or radius or RSA SecurID
authentication and lastly the Kerberos authentication service which performs
Microsoft Active Directory Kerberos identification with version 20.01 of the
connector you can choose to locate all three of those connector services on the
same Windows server or to separate them out sizing for 20.01 version the
character is given on the screen right now and also in the documentation when
you install all three services onto the same instance of a server and this gives
the supported number of users and groups along with the CPU memory resources to
allocate on those VMs and some tuning parameters of the services as well then
for high availability you would want to provide an N plus one to ensure service
continuity in the event of a failure so typically we would see two connectors
for site resiliency and to provide disaster recovery this will be repeated
in a failover site with a further two connectors located there the directory
sink and the user authentication services are load balanced by the
servers the Kerberos authentication servers however requires a separate load
balancer now as I mentioned you can choose to separate out some of the
services well on to other servers you can choose to separate out the directory
sync service to run in a different window server away from the user
authentication and the Kerberos authentication services sizing for this
scenario is given on the screen and again also in the documentation when you
install all three services onto different servers and this again gives
the supporting number users and groups along with this resources and CPU memory
to allocate to those VMs along with the relevant tuning parameters again for
high availability you want to provide an n plus one for service continuity and
the event of a server failure to typically two connectors of each
then you would double that out for your site resiliency into your second site
as mentioned currently if integrating with horizon or citrix environments the
recommendation is use the version 19.03 of the connector sizing for the 19.03
version of the connector is given on the screen and again in relevant
documentation this gives the supporting number users
and the resources CPU memory to allocate to those connectors VMs if you're using
both workspace one access and workspace one UEM you might be running both the
workspace one connectors and also the AirWatch cloud connectors you can run
them on separate servers or you can co-locate them on the same windows
servers if you co-locate them do make sure to double up and add on additional
resources for both connector services so a relatively straightforward and simple
architecture there with the cloud based now let's look at the architecture if
you want to deploy this on-premises to do that the services that are provided
by the cloud servers now need to be designed sized and run locally
on-premises so first let's look at the first layer of the workspace one access
service this runs on workspace one access appliances to provide the tenant
services typically these will be deployed behind a load balancer in the
DMZ you have still got those connectors they are talking to internal sources
such as Active Directory they run on separately and they'll sit in the
internal network and communicate with stuff like Active Directory they will do an
outbound connection towards the workspace one appliances towards the
local tenant obviously you need somewhere to store the data so you will
need a database and that's going to be Microsoft SQL and then we start
scaling it to start you need a minimum of three workspace one appliance nodes
normally again located in the DMZ there are several reasons why you need three
appliances not only will this help avoid stuff like split brain but it also
ensures some of the internal services like eh cache or elastic search work
properly even when you have a server failure
and you will need at least two workspace one connectors sized to handle the load
and also to ensure redundancy in the event of a failure as the database is
where you're storing all the state data you want to make sure that it's highly
available so typically you would use a Microsoft SQL always-on configuration
in terms of the number of workspace one appliance nodes well really three is all
will typically see in environment but you will alter the amount of resources
and CPU and memory you would actually allocate to them depending on the scale
environment you can go above three and typically we'd see that in an odd number
but if you're in that situation please contact VMware for assistance and
guidance with that so let's look now at how you design this for multi-site
deployment if you're running this on premises you need to make this redundant against
the site failure starting at the bottom layer the data layer you're going to use
SQL always-on here as previously shown but we're going to deploy this
across both our sites now it's important you understand when you use SQL
always-on as one of the SQL servers it's going to be the read and the
write that's our primary the others are really secondary and you're gonna
passively copy data there you're not actually going to use them until you
need to failover to one of them in our first site you're going to place those
three workspace one appliance nodes again three is the minimum for a
production environment and three is a recommendation up to 100,000 users
because you do multi-site you're going to have a global load balancer and
that's where you're going to direct the users and devices that global load
balancer is going to have an active connection sending traffic down to site
one that's where you're actively sending user traffic so site one becomes your
active site to create a DR environment we're gonna
set up another three nodes in a separate cluster on site 2 your global load
balancer though will only have a passive or standby connection site 2 you're not
actively sending any traffic down to during normal operations you then need
to add in the workspace one connectors you'll need those two connectors that we
showed earlier in site one when we built at that scaled environment and again
they are going to communicate with either the local load balancer in site
one or actually more typically directed to the global load balancer so then you can
configure all the connectors using a common namespace and of course you need
site redundancy so the connectors in site 2 are going to have a similar set
of two connectors again pointing to that same namespace in the global load
balancer now what you end up with is this from a user's perspective an
active/passive service the workspace one access service when it's delivered
on-premises is going to be actively served out of one site all of the users
are going to consume from site one typically you replicate the data and
have standby appliances and connectors in site 2 that you can fail the service
over to in the event of a site outage for more guidance on architecting
workspace one access please see the relevant sections of the reference
architecture document on TechZone.vmware.com