So got a customer who is using Cloud Cache. They seem to think that Cloud Cache means there is a copy of the VHDX taken on a local disk and there is therefore zero I/O to the network at all which then just "syncs back" at logoff. AFAIK this is not how Cloud Cache works - it just caches "hot blocks" locally and then uses them in outage scenarios, IIRC. Or has it evolved somewhat and I am missing the point? They certainly seem convinced that Cloud Cache is some miracle "local profile" tech

Straight from MS marketing: 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.

Oh there is IO, there is much IO

So I could have the profile mounted locally, obliterate the remote storage and everything would be hunky-dory? (in terms of session UX)

Yeah, that's not right. There is more I/O, profile writes are local on a cache disk and then also pushed to all cloud cache locations. Yes it does store some reads and writes but not much. Never tested it like that, should be quick.

So customer in question seems to think that having it "local" is great because (and I can't verify this) there is "very little I/O to the storage account now". Problem is the management is convoluted and I think the performance is suffering.

i was always under the impression it could work for a period of time from the local cache . Similar to how PVS targets work for a period of time if you shut down the streaming services on the PVS servers before eventually hanging and bluescreening the targets

If it needs anything from the remote disk though it's going to screw up. Be interesting to find out what counts as "hot blocks"

It will cache the profile locally. So you pull reads from the local cache, then it will load IO locally for writes (in the cache directory) and blast it back to all locations that are available (per Leee). If you lose storage, you keep going fine, you queue writes in the local cache. When storage comes up, you blast all writes back to storage. If you run out of space locally, then bye bye Cloud cache looks awesome until you scale it

What happens at scale, then?

sh1t blows up really quickly. Imagine hundreds or thousands of users with pending IO build up on their local machines, blasting back all at the same time to storage backends as they come back online Even in normal operations, you have a constant build/flush pattern happening constantly to backend storage, more users, more flushing, more IO punishment. There are other mechanisms at play probing for health states etc as well - it ain't pretty

Bear in mind, standard FSLogix on a file server completely offloads the I/O of profiles over the network. Cloud cache is great if you must have profiles written to multiple locations but, it needs proper planning. If you're seeing issues with performance, definitely take a look at disk queue metrics. Cloud Cache is expensive for write I/O because its writing locally and then also to each CC location.

Interesting - this particular customer seems to think local I/O rather than I/O to the storage account share is good

Well, the whole idea of FSLogix originally was to offload outlook I/O caching to a remote location 🤷🏻

Yeah, I get the feeling that these lot are trying to use Cloud Cache as "local profile with replication to remote file shares for redundancy" but to me they kind of seem to be missing the point. I'm of the mind to say go back to VHDLocations

If you have fast local storage to serve the IO, you can somewhat protect the user experience from bad backend storage performance

Yeah that's what they're driving at. But I'm not entirely sure it adds up in practice

Caveats everywhere with that logic though - particularly logon and logoff

Not really, you could provision a local location C:\Profiles on the machine, then have additional locations. Make's me feel sick in my mouth a bit though.

Why you gotta say such nasty things @Leee Jeffries

Forget I said it......

The internet never forgets

Slack will forget in 90 days

We have linen….

Brilliant, immortalised for my nasty things. It's a novelty for me though, I'm usually nice.

It’s got us all mate, no escape