Cloud Cache Overview

Cloud Cache is a feature that works with Profile and ODFC containers to provide resiliency and high availability. Cloud Cache uses the locally mounted container to provide periodic updates to the remote storage providers. Cloud Cache is designed to insulate users from short-term or intermittent local (inner-region, close proximity) storage issues. Based on the configuration, it can also be used as part of a Business Continuity or Disaster Recovery (BCDR) plan when using remote storage providers in different regions. Using Cloud Cache puts a performance and storage requirement on the virtual machine to accommodate the extra I/O operations and storage required by the local cache.

Cloud Cache considerations:

• Cloud Cache uses storage providers based on the order of entries in CCDLocations.
• Storage providers should be listed in order of proximity, then preference.
• Only one (1) provider is used when data is hydrated from the storage provider.
• Data is written to all storage providers regardless of which provider is used during data hydration.
• Performance (latency, utilization, bottlenecks) of a storage provider affects its sync status with the local copy.
• Having one (1) or more provider that is behind in updates from local cache could be an indicator of an under performing storage provider.
• Ping or Test-NetConnection command results are not the same as transactional I/O and are bad indicators of how a storage provider will or can perform.

^{Figure 1: Detailed diagram showing Cloud Cache components}

Cloud Cache Components

Local Cache

Cloud Cache is able to insulate a user from connectivity issues to the remote storage providers because the container used for the user's profile is created and stored local to the virtual machine (local cache). During a first-time sign-in, FSLogix creates the container for the user in C:\ProgramData\FSLogix\Cache and mounts the container to the virtual machine. Next, FSLogix sets up all the necessary redirections for the user's profile. Then the User Profile Service creates the user's profile into the local cache. All data written to the user's profile is temporarily stored as block-level cache objects in the same directory. Those block-level cache objects are then committed to the local cache. Before the block-level cache objects are created, the writes into the user's profile are processed in memory through a proxy file.

During a 2^nd or N^th sign-in, FSLogix attempts to find and mount any previous local cache VHD(s) stored on the virtual machine. Looking for a local cache is the default configuration setting and may not be desired as it may lead to low disk space events. Review the Cloud Cache settings reference page for more settings.

^{Figure 2: Cloud Cache Local Cache}

Remote Storage Providers (hydrate, flush, clone)

Cloud Cache operates the user's profile from the local cache during the user's session and must be configured with one or more remote storage providers as specified in CCDLocations. These remote storage providers store copies of the local cache and are used during the current session and for subsequent sign ins. If all providers become unhealthy during the user's session, the local cache continues to operate and grow¹ until one or more provider returns to a healthy state.

^{1 The local cache will only grow up to the maximum size of the container as specified in the SizeInMBs setting.}

Hydrate

When the local cache doesn't contain the data requested by the file system, Cloud Cache hydrates (reads and copies) the data from 1 of the remote storage providers to the local cache. This operation is also part of the sign in process when populating the local cache for the user's profile.

Flush

The flush operation commonly occurs in three ways.

1. On a lazy asynchronous operation, Cloud Cache flushes the changes to all storage providers simultaneously as each provider is flushed on its own thread. FSLogix doesn't throttle this operation and utilizes as much throughput as the system will allow.
2. During sign out when one or more providers don't contain all the updates, the user's sign out is delayed² until all providers are at the same sequence.
3. During a user's session when the connection to any storage provider becomes unhealthy, FSLogix queues up all the changes and then flushes them to the providers when they return to a healthy state.

^{2 A user's sign out is delayed based on how Cloud Cache is configured using the HealthyProvidersRequiredForUnregister value.}

Clone

A full VHD(x) clone is performed when Cloud Cache determines, at sign in, that a storage provider isn't at the same sequence. During this operation, all pending writes are kept in the local cache until all storage providers are at the same sequence. Once complete, the flush operation begins sending new data to the storage providers.

Indexing (timed write cache)

Cloud Caches makes use of indexing within the local cache. Timed write cache, are files that represent writes that have yet to be committed to the local cache. These files are notated using a numerical extension. Once the index has been committed to the local cache, it's converted to a cache object.

Index files must be considered anytime a virtual machine is unexpected shutdown or reboot. These files would represent data that hasn't been committed to the local cache and could lead to loss of data; at worst a corrupted container. In non-persistent or multi-session environments, once a virtual machine recovers from the unexpected event, the user typically doesn't connect to the same virtual machine. In these cases, the data that wasn't properly committed and flushed to the storage providers could be lost and lead to an issue with the users profile container.

Proxy File

Cloud Cache uses the concept of a proxy file, represented as Profile_%username%.vhd though it isn't a true VHD file. The proxy file is used as a means to collect and process all I/O writes destined for the local cache. The I/O writes are buffered in memory and tracked via the proxy file before they're written out as block-level cache objects in the cache directory. While the proxy file has the same size as the local cache file, the actual size on disk is zero, as no data is written to this file.

^{Figure 3: Cloud Cache Proxy File}

Auxiliary Files

Cloud Cache makes use of two (2) auxiliary files in order to maintain control and sequence of the local cache.

Note

These auxiliary files are used by FSLogix and are not meant to be opened or used outside of the product. Any relevant information in those files will be made available through our log files or event log entries.

Lock File

The lock file is what its name might imply, a file use to determine which virtual machine has an I/O lock on the container. Cloud Cache uses this information to determine ownership of the container for a given provider. The lock file mechanism is critical when using Cloud Cache with ProfileType set to '3' (Multiple or concurrent sessions).

Meta File

The meta file is a multi-purpose file where we track the state of the container. Inside the meta file, Cloud Cache uses a sequence numbering system to determine which provider has the most recent data.

Storage Providers

FSLogix isn't a storage provider, rather we rely on underlying architecture of the storage provider(s). For more information on the storage providers FSLogix supports, review our Container Storage Options.

Next steps

High Availability or Container Resiliency Options using Cloud Cache