https://worldofeuc.com logo
Join Slack
Powered by
This message was deleted.
# microsoft-fslogix
s
This message was deleted.
p
Scale-Out File Server would be for VHDX, UPDs, or even Veeam backups. It's SMB based shared storage usually for either a compute cluster or a RDS Farm.
It is not for general use file serving.
n
That's what I'm referring to here - FSLogix VHDX storage.
p
Then SOFS would be the one.
General Use would be for endpoint/user files and folders.
n
Okay, that's kinda what I figured. It's been frustrating to convince these guys to go the SoFS route.
p
Azure Stack HCI can be set up for some pretty good performance numbers for profile disks to limit impact during logon storms.
Too much "voodoo" black box kind of thinking?
n
We've apparently had issues with traditional MS file clusters, namely them running chkdsk after an unplanned outage. The underlying hypervisor of this environment is VMware, so I'm not sure if that plays into it at all.
p
Ah
"Unplanned Outage" meaning power loss?
n
They wouldn't expand on that, so part of me wants to assume that they also mean user error that caused an outage.
p
No root cause analysis published I take it?
n
Nope, nada.
p
That's not good. Silos suck.
n
I agree. They're probably just trying to cover their own rear end, but we all have to deal with one another. I've offered to help with anything they need.
I just need resiliency for FSLogix. Can't have profiles crashing in the middle of sessions because we have a single point of failure.
Especially in healthcare.
p
Yup. Two node SOFS cluster with affinity on the VMware setup would do that.
*Node affinity
n
Is there a KB/guide on the node affinity config in VMware, in case I'm asked? I'm setting up another meeting with our teams to discuss all options, and I know that nobody here has done anything with SoFS before.
p
We do Microsoft clusters. VMware was something we looked into but documentation was not great and we didn't have the time to burn on figuring things out.
b
If you have multiple VMWare clusters, as long as they have similar storage performance it would be good to put one node of the FSLogix cluster on each physical cluster, to spread out the fault domains.
n
Yeah, this would be a Microsoft cluster (SoFS on Server 2016), all on ESX.
b
Recommend making it a 2019 cluster. Storage spaces direct has more optimizations for 2 node cluster in 2019.
But put node A of the SOFS cluster on VMWare cluster 1, and put node B of the SOFS cluster on VmWare cluster 2.
the two nodes of the FSLogix cluster will use storage spaces direct over the network for their clustered storage.
j
I don’t want to hijack the post, but why not use NetApp or EMC cluster with CA...
l
Sorry chaps, missed this and obviously you've all been talking. Heavily. NetApp or EMC are fine options but also pricey and if you've already got a storage solution and windows license clustering makes sense. CA is a feature that's been around since 2012R2 let's put it in context though. It's about SMB sessions. What it does in replicate SMB session information to other nodes (doesn't matter if active/active or active/passive) this is the reason why it's not for general file server usage because the replication of this information kills environments.
So here are the scenarios for failover clustering or SOFS. If your backend SAN can take the load of your file services then go with a failover cluster active/passive and continuous availability. It'll give you a seamless failover between nodes. As for chkdsk - it'll be very fast. The files will all be large. I've never heard this as an objection, that's bonkers.
p
Of note: SMB and SOFS behaves differently in 2019.
l
For SOFS, if your backend storage cannot support the load required then you need to spread that load between multiple storage locations. That's what SOFS does. It's uses storage spaces direct to replicate data and continuous availability to ensure seamless failover. SOFS is especially useful in cloud scenarios where you are hitting IOPS limits on Azure VHDs. Storage spaces will allow you to RAID VHDs together for aggregated throughput and iops. Couple that with SOFS and you have a highly scalable (but costly, in the cloud) solution.
@Nick Panaccio - DM me if you want to discuss or setup a PoC so you can test the behaviour and answer the questions for yourself. Me and @Ray Davis were planning a blog post on this exact setup.
👍 1
r
Yea thats still my plan. Just was going to do a rdm CAB with CA for FSlogix.
CAB in vcenter (esxi)
At the moment im using BVCKUP2. For a cheap replication until i can get CA going. Its not bad. Put the second profile server in the profile container, setup a job and data get created on a second files server with vhdx. First server failes. Seconds one has all the data (it has a generic Continuous replication. If the primary does fail the secondary node will pick up. But you have to set the job up reverse now at this point.
l
No need for SOFS though if you only have one set of physical storage.
k
Hi, we are working on a solution for FSLogix with SoFS in a site redundant setup with aprox. 20.000 users. And your thred looks interesting. Where we come short, is the understanding of how it will work with site redundance, as it looks like we will have a lot of cross site traffic to consider. first from VDA to File Server, and then to storage that again is replicated. Can we konfigure it so that users on one site will connect to fileservers on the same site and what are the requirement to make the fileserver conect to the storage on the same site, when the LUN is access from both sites?
l
What method of replication will you be using???
You are using SOFS right so I am assuming you know it'll hand the replication? What's the link speed in-between the data centers?
k
I could use a little info on the difference from a "normal" cluster. We usually have replicated SAN with a LUN visible on all cluster nodes. How is this different in SoFS?
The link speed is unknown, but should be enof, as other Storage replication is allready in production.
l
With SOFS it handles the replication for you. If you can setup asynchronous replication with storage and two separate clusters at each site you can use environment variables in the vhd location path to direct users to their local cluster.
SOFS is very sensitive on the storage replication side of things. If you have storage replication available and are used to using it, I would use that.
No need for SOFS in this scenario. Just two failover clusters, one at each site with the storage layer handling the replication.
k
Users are distributed at logon, so any given user will connect to any site from time to time.
Would you have 20.000 users with 2 connections to one cluster node?
The idea to use SoFS is to scale out with the number of users per fileserver. And make sure we can update the windows servers with no impact to the Users as there are 24/7 usage.
l
SOFS is going to do the storage replication for you. As long as this is local it should be okay. So your using a virtual desktop broker based setup? Citrix, VMWare?
k
UseCase is XenApp with GSLB.
l
Cool. My suggestion should be okay. Just bear in mind with SOFS the storage replication is handled by Windows. Unless the link is very fast with low latency I would not recommend it cross site.
k
I do not understand that part about the storage beeing replicated by Windows, since what i understand is that we have 1 LUN that is accessable from multible nodes in SoFS and SoFS is just handling witch of the nodes is primary and can write to the LUN.
l
That's not how SOFS works. It's a combination of technologies including storage spaces direct. I've never seen it done differently though, doesn't mean it doesn't do it.
p
In a SOFS setting, the general rule of thumb is # Nodes * 2 = CSV (Cluster Shared Volumes) to deploy. Those CSVs are then distributed across the nodes as far as ownership goes. I/O is then "shared" across the nodes. Shared SAS with two or more nodes is a viable option for ultra-high density (WD/HGST 102 bay with 9 SAS SSDs + balance SAS HDDs for example).
For Storage Spaces Direct being set up in SOFS only mode: East-West traffic plus North-South between compute and storage becomes an important consideration.
l
Cheers Phil, what's about Kelds earlier question. Does SOFS support storage level replication with the same sort of topology as S2D?
p
Storage Replica is a feature available in Windows Server Datacenter edition. It should be fine to use. 5ms or thereabouts and less link between source and destination and it can be synchronous. Anything over 5ms to 7ms and asynchronous meaning the possibility of data loss.
l
That was my understanding too Phil. Thanks for confirming.
b
I use 2 separate virtual S2D clusters with SOFS Share, and the partition is replicated between sites with async storage replica. You can do this design in Azure as well between regions. At ignite they announced server vNext will be able to have S2D stretch clustering, so it will be a single cluster with 2 nodes in each site. And the failover will be automatic instead of scripted.
n
I must be living in bananaland, because the guy who has been a roadblock for months has finally agreed to build an MS file cluster with CA enabled for our FSLogix shares. I should just go home now and call today a success.
p
Heh
Baseline IOPS and bandwidth peaks and valleys taken?
n
Yeah, they've got all of that data available since our current profiles are on the same back end (VMax).
Now I get to migrate 450ish GB of profiles, which should be fun. Going to see if Bvckup 2 works as well as everyone says.
l
It does indeed sir. Its a very good tool!
n
I know I've been talking about SoFS in here, but are there any oddities with regards to VMware to make a standard cluster with CA work?
p
Storage Migration Service in 2019 may be an option?
l
VMWare requires RDM - Raw Device Mappings which basically means VMware passes through the storage directly to the vm. There is no vmdk for these machines. This means no snapshots, you'll be relying on VSS for backups. Either that or you use bvckup to replicate to a third standby mode that you backup and becomes your DR/Failover target.
That's usually what I do btw...
n
So it sounds like you basically need to double your storage estimates to accommodate backups. Ouch.
l
Well..... Depends on your DR and backup solution. If you have a backup solution that's happy with VSS and it's pretty quick then you'll be fine. If you need snapshot based backup then potentially. It all depends don't forget to factor this in though. Microsoft Clustering will require RDM.
n
I'm 99% sure that we use CommVault in that arena.
l
🤮
Lol
n
lol. We used CommVault at my last job, and while that wasn't really my area of expertise, I actually liked it.
l
You need Veeam in your life my friend. It's brilliant.
n
Thankfully, that's not my area (we're pretty silo'd off here). I get to stay in my Citrix lane.
l
It's the best lane 🤪
6 Views
Open in Slack
PreviousNext
Powered by