This message was deleted.

lol.

Lol..... Clustering with Continuous Availability is your friend Nick ;-) I think I may have said that once before?

Nick - it's even better when no one reboots it, and they just randomly lose connection on their own...We are piloting Cloud Cache to see how that helps, and finding out lots of things about how data flows in our environment 😃 I would like to do CAFS like @Leee Jeffries recommends, except we lose backup integration and have to switch to in-guest agents (ewwww). Also, only protects against server failure, not underlying storage failure. Of course, your requirements may be different.

💥

@Tim Riegler replicate all VHDs to a third location, use that for backup and a failover in your vhd locations. Replicate using a small block level utility bvckup. Bullet proof. I've not yet pushed cloud cache into prod. I see some occasional blips. For smaller clients I may start looking at it though. I'd hope your storage was resilient at a site level though?

@Leee Jeffries: You absolutely did, and my request was denied from the server team. No real complaints about today’s incident, but I’m going to use this as an example of why certain people shouldn’t have veto rights. This will probably drive me to also look into cloud cache. My WC disk should be large enough (W10 VDAs), but I think you can also use the default directory for that in C:\ProgramData? That may be a better fit for larger containers.

Either way that's going in the write cache ;-) you may want to attach another disk or estimate your cache size through testing.

You could use a couple things for this - bvckup, Peer software, Windows native depending on OS level, etc.

I tested the built in replication on 2019, it's good but active/passive. I was hoping for a SOFS experience tbh. Have you rolled cloud cache into prod yet Jarian?

Yep builtin is more active/ passive and DR but something builtin

If you do get the opportunity I'd love to hear about it. I've had lots of people test but not use it yet.

I mainly test now given my role at Nutanix. I can say it’s getting better.

@Tim Riegler: How has your Cloud Cache testing gone? I assume that you’re using your WC drive for this purpose?

This happened to me 30 days ago. Messed up some profiles as well. My problem is... 1. Time to research how to do clustering with continuous availability. Never don't it, so I'm clueless right now. Not to hijacked the thread, any good guides?

Cluster with CA really is a tick in a box in my experience. Plenty of guides on Windows FOC out there. Only major consideration is backups as Tim said - eg. If you use Veeam or anything else that uses VMware APIs and vCenter for backup then you’re back to in-guest agents. Which let’s face it has done the job for a couple of decades so no big deal depending on your infra - just not as efficient as direct SAN vmdk backup. I like Lee’s suggestion of repl out to a non-clustered device and doing backup there.

I have dont plenty of clusters with RDM. But not any file servers.

@Nick Panaccio Well...it's going. We are learning a lot. Initially we put both profiles and ODFC on WC drive via CC, and that seems to cause problems. Underlying hypervisor is XS (7.1 LTSR), with dual (mirrored) SSDs - enterprise class, and not fast. Today we started playing around with moving profile to C: again, to take advantage of Write Cache to RAM with overflow to disk (PVS), as our current RAM cache is 12 GB / VM (based on when we were running UPM) - and since the move to FSL is only using about 1GB of that. IF we can get our profiles a little smaller, I think we'll probably keep CC on C: for profiles, and move ODFC to CAFS per @Leee Jeffries and @David Inglis. We're not worried about ODFC going offline, users can access Outlook on the Web until it comes back up.

Gotcha, thanks for the reply. All of our underlying storage is flash, so I'm not worried about performance of the WC disks. I made ours 15GB, of which 13GB are free most of the time (2GB static pagefile). Logon impact, however, is a concern. I imagine that setting up CC to use a local copy on the C: volume and sync to the network share could slow logons and possible logoffs down. I'm not sure if I'll go the CC route. Perhaps I'll just ask the Ops team to not reboot the damn server at 1:30pm.

Like the approach @Tim Riegler. Well tested so should be reliable.

SOFS with Continuous Availability actually works the way it sounds, no? If one box goes down, existing sessions are not affected? And we wouldn't need double the storage?

Yeah. You also don't need SOFS to do Continuous Availability - we run it on simple file server role on normal Failover Clusters. It is suitable for use with files that don't get opened/closed a lot - so VHDs are perfect, mounted in the morning and unmounted at close of play. Don't use Continuous Availability for normal general purpose file server scenario. We use it for hosting FSLogix, PVS vDisks, HyperV VHDs (all of which thinking about it are VHDs :)). Works great.

SOFS is just basically active/active clustering using storage spaces direct for replication. As David states, you can use CA with a standard failover cluster. I'd only use SOFS on prem if I had multiple underlying storage to amalgamate/spread the load or on cloud services where's VMs have number of disk/size limitations.

Which we don't, so a normal MS cluster with CA sounds like it should work. I really, really hate having to revisit stuff like this, especially after an incident, but I'd rather this be resolved one way or the other.

Regarding login times - our current FSLogix profiles for our CC test users are around 1.5 GB on average, and logon times are still in the 12-14s range. Logoffs DO take a mite longer, which is also good, as users can't just start a new session (non-persistent SBC desktop) and jack up their profile.

Do you disable the 'fast logoff' feature in WEM?

12-14s from the user clicking on the desktop in SF to them seeing their full desktop?

@Nick Panaccio it's reliable and has worked for me everytime.

Looks pretty straightforward, assuming this article is still valid: https://blogs.technet.microsoft.com/clausjor/2012/06/07/smb-transparent-failover-making-file-shares-continuously-available/

Yeah once you have your cluster built, add a fileserver role and tick the CA box! 💥

💥 is what I'm trying to avoid. 😉

@David Inglis Yes, we have disabled "fast logoff" in WEM. Had it enabled for a very long time.

We use vmware VMs for this - the caveats are - for cluster-across-boxes (ie. DRS anti-afinity rules and running each node on a different vmware host) you need to use in-guest ISCSI. If you don't mind both your MS cluster nodes being on the same ESXi box, you can use virtual-mode RDM. I think that's still accurate, i will dig out the link.

Yep, found that link right after asking. Nice!

You can use rdm's with the VMs on different nodes.... You use a pointer to the second one. Caveat, all hosts must see the storage of course.

@Tim Riegler We are playing with disabling fast logoff - exactly so users don't reconnect too quickly. But then we get old Doreen and Gladys in Timbuktu office complaining they miss their bus because they're waiting for it to log off! 🤣

Lol

@Leee Jeffries Is that a supported config now? I will have to re-read. We stuck to guest ISCSI so we could have MS nodes on different ESXi hosts, which causes us backup pains as you can imagine, so some RDM would be good (can't believe i'm saying that...). Ie. Veeam.

I love Veeam and in my scenario it is the same. I followed a VMware article I believe.

Guess it depends on where you fall on 'it works' vs 'it's supported'. We also love Veeam and would love to do fast direct-san backups rather than in-guest agent. If you have anything that even remotely hints that it is vaguely supported then i can use that internally to attempt change 🙂

https://kb.vmware.com/s/article/1821 section 2 of the table - clustered rdm. Uses a label.

We use CC in production for several months now and I can’t complain. You have to pay attention, but it works if you do your homework. A good planning is the prerequisite. And keep it simple. Use two Windows 2019 servers with ReFS storage for CC and SSD local storage as cache disks for your VDA’s.

@Dennis Why ReFS? Is this on VMware? If so, are you using the NVMe SCSI adapter? Or pvSCSI?

ReFS due to the speed of merging the writes into the VHDs I reckon. It near instant.

Man, this isn't going to be fun. Not only am I going to have to get these guys to build new servers and configure CA, they'll probably have to assign new LUNs. We'll have to create brand new Profile and ODFC shares, copy the existing 250GB of profiles to the new shares, and then change the paths in my GPO in order to take effect. Nice.

Why? We aren't using ReFS on ours - we switched to NTFS when we were having all of our problems, to rule out ReFS on VMware. Turns out it wasn't related to ReFS or NVMe at all.

@Nick Panaccio if it was easy everyone would be doing it ;-)

True, though we're making it complicated by changing course post-go live. 😕