Let's take a look at an example topology I've created for us here.
The deployment workflow for Azure File Sync Service involves creating an
instance of what Microsoft calls the Storage Sync Service.
Now, you might be fine with just one Storage Sync Service.
This is the top level of the Azure File Sync object model.
And within the single Storage Sync Service,
you create what are called sync groups.
And what a sync group is,
its one and only one file share from a general purpose
storage account in your Azure subscription mapped to one
or more registered file servers.
These are Windows servers that will be running a service,
an agent,
that links that machine to their sync group and supports that
two‑way synchronization between the local file system and the
file share in the sync group.
Questions like now are you going to need to edit drive mappings,
will this affect work folders, will this affect mapped network drives,
these sorts of things?
No.
The Azure File Sync engineers were very sensitive in terms of they wanted
Azure File Sync to help your IT staff and indirectly,
of course, the users.
But ultimately, they didn't want to impact the users' connectivity at all.
So no drive mappings or anything like that will be disrupted at all.
They will continue. Those users and applications locally will continue to
access those files shares locally as they always do.
It's just behind the scenes, we have this hybrid cloud stuff going on,
this cloud synchronization and cloud tiering with Azure File Sync.
Now to answer specific questions, well,
what if we have a catastrophic failure or what if we need to take a file
server down for maintenance and you're not currently using,
say, Windows Server failover clustering to do scale out file server?
What if my singleton file server goes down?
I'm going to immediately cause a denial of service, aren't I?
Well, yeah, in the short run,
but that run is going to be much shorter with Azure File Sync because you
literally can install the AFS agent on another machine in your domain and
then recreate the shared folders from the appropriate sync groups that are
running in your Storage Sync Service.
Isn't that awesome?
Another thing to consider is what if your file server
is running short of storage space?
That's a perpetual problem for systems administrators.
Optionally,
we have the ability to do cloud tiering where the users and applications will
see files in file listings on those shared folders locally,
but those resources may have been offloaded to the cloud. And at first
access, the AFS agent will retrieve that resource, so there may be a
little bit of latency depending upon the speed of your internet
connection to retrieve that offloaded file.
But it is there. It shows up in directory listings.
It's just that you're immediately saving space on that
local file server's file system.
Lastly,
if you're using distributed file system, particularly DFS
replication to replicate file shares across sites in your
organization, can you combine Azure File Sync and DFS?
Yes, you can.
Like I said, we're going to cover this in much more detail in the next module.
One hazard though is, during the migration, you want to
be careful not to use cloud tiering.
That can cause some confusion and some problems between
AFS on one hand and DFSR on the other.
But again,
we have to remember one of the guiding business propositions of AFS is to help businesses evolve or migrate past DFS.