let's look at the architecture of Workspace ONE UEM formerly known as AirWatch
and as a reminder this is an overview video, all the full detail is
available in the reference architecture guide on text on techzone.vmware.com
initially it let's look at the cloud-based architecture so this is
fairly straightforward. We're going to consume a SaaS tenant of UEM
from the cloud and connect our devices and users to consume policies derived there
now usually what we will want to do is also integrate this into an
on-premises Active Directory so to do this will deploy AirWatch Cloud Connectors
in on-premises to talk back to our Active Directory domain controllers and then an
outbound connection to send that information to the Workspace ONE UEM tenant
now obviously we want scalability we want more than one AirWatch Cloud Connector for
redundancy as well so we need to install several here the number really
depends on how many users and how many devices you are actually going to host
so it's a relatively straight forward architecture when we consume as a SaaS. Let's move on
and let's look at the on-premises when you deploy this in your own data centers
now we need to kind of breakout than what we delivered as a cloud service and
deliver that on-premises. So a few main components. We've got the admin console
we've got the device services and we've got that in AirWatch cloud connector just
as we did in the SaaS environment but we're also going to have a database we need
to store the device and environmental data so that's going to be a SQL
database sitting in an environment and depending on the scale we might have
some other components we might have a memcached server an API server and an AWCM server
so that's understanding the individual components
let's look you see what happens when we need to scale this out for size
the documentation has full guidance in terms of how you scale out depending
on what size of environment you're designing for. In this sample picture
we've actually designed out an environment and this is what we did in
the reference architecture guide. This environment is capable handling fifty
thousand users so to do that we need four device services we also need to
separate out the API and the AWCM on two separate services and all those
components will normally live within the DMZ. We need three admin console servers
as well and we're going to separate out and have memcached server as well and two for
redundancy is best practice here as well. And three AirWatch Cloud Connectors, sized
very very similar to how we sized them when we were doing SaaS. And of course that
database because we need to own that data. But when you're deploying UEM
on-premises what we need to think of is multi-site. How is my disaster recovery
if I lose my primary site how am I going to deliver the service from another
site? So first layer of the service to look at is actually the database. So we're
going to use SQL always-on and it's important to recognize here the way that
SQL always-on is used, as one of the instances, one of the servers is my
read and write, the other are really completely passive there they're getting
copies of the data just in case. Now we're going to use a SQL always-on
listener and have instances across both our locations so we've got local
redundancy and site redundancy of that date layer. And then we're going to layer
on the scaled out environment that we showed earlier. Our device services and
our API and AWCM in the DMZ and our internal components. And to provide
complete site redundancy we need to scale up and provide an equivalent
environment. The first thing we're going to do because we're doing more than one
site is we're gonna add a global load balancer. This is very important in terms
of controlling which site is actually active. So from the global load balancer
we're going to have an active connection going down to my site one device
services that's where it's going to send all that
the device traffic. We come to the second site then we're going to build an
equivalent set of servers or device services and this time we're going to set
up the global load balancer to have a stand connection so it's not actively
going to send any traffic down to site 2. It's there for us to fail over - now
obviously we need to build in all the other several components into site 2 as well.
in a failover scenario we need to do a couple of things. First thing we
need to do is make sure SQL fails over to a secondary node and make that
the primary for our failover of the data layer and the second thing we need to do
is on a global load balancer is disable referrals down to site 1 and activate them to site 2.
When deployed on-premises Workspace ONE UEM is really an active passive service, from the users perspective
One site is going to be our active site and deliver all the services
now we're going to replicate data and we're going to have a set of standby servers in our other site, in site 2
ready to start the service and deliver it from there if needed
For full detail an architecting Workspace ONE UEM please see the relevant sections
of the reference architecture on techzone.vmware.com
you