The Latest Gartner® Magic Quadrant™Hyperconverged Infrastructure Software
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
You need to expose one mirror to one client. Say, target 1 and its replica serve only client 1. Target 2 and its replica are only for client 2. Such approach excludes VMs on client 1 moving to client 2.Or we should connect each those two clients to a different server, so client1 -> target1 and client2 -> target2 while target3 stays free and is only replicating. That would mean, though, that if target1 crashes, client1 will disconnect from storage. Plus, probably target1 and target2..3 have no global locking so clients could corrupt files if accessing the same devices/files.
You can do shares.Any other way to expose HA devices other than creating a failover cluster? I can read there's a script for a HA SMB witness but I'm not sure that could be used for a HA SMB share without the failover cluter.
So while that script, included with SW, is only showing how to create a small (12MB or so, I think) witness share, is that setup suitable to create a bigger share, say 1TB or so ? Would that share be highly-available and fully SMB 3.1.x compatible, with all the bells and whistles ?You can do shares.
Can I please hear more about the issue?clustering and/or SMB might be the issue we're experiencing
Thanks. Are these shares highly-available? Do they support SMB 3.1.1?yaroslav (staff) wrote: ↑Wed Feb 21, 2024 10:48 amHi,
You are always welcome.
That is a sample script. You can create a larger device using the script. But, given the fact that full synchronization is running after the device creation, I'd suggest creating smaller devices and growing them afterward. The witness on SMB share will take 4 KB anyway.
From my personal experience, there is no limitation for SMB shares.
Basically, performances from the cluster are fine but PHP performances accessing those paths/disks are poor. Not clustering fault, according to what I hear. Windows build of PHP lost a lot of performances lately, I heard that this might be an issue with those builds with Windows ASLR but might be something else. We had a lot of PHP apps using SMB (for ex. in IIS) which, all of sudden, simply switched from great performances to very poor performances. I don't believe that has anything to do with locking, as someone says, because we also have those issues when reading and those cluster can read at good speed (4+Gbps, for example the latest we had issues with).Can I please hear more about the issue?
I see there is a confusion. I was referring to the StarWind VSAN file share witness (available only for StarWind VSAN Windows-based app). If you go Windows-based way, you can repurpose HA device for the file share later. We have no restrictions for supported SMB version, to my knowledge. This relates to node majority (https://www.starwindsoftware.com/help/C ... tness.html).Thanks. Are these shares highly-available? Do they support SMB 3.1.1?
You do not need failover clustering if you follow the principle of one HA-one client (e.g., VM or host).In this case we would like to have a setup where we're not forced to use Windows Server failover clustering
Yep, I was referring to this one. The witness share for the Windows Server edition of the software. There's a Powershell scripts for that and I was trying to understand if such share is highly available once created. The reason for this request is that we could keep storage AND applications separated (converged) while exposing the storage as the SMB share (not for witness, of course, a big one like 1TB or so), backed by two or three StarWind machines. But if that share, as created by SW (not the volume, the share) is not highly available then I think that can't help.yaroslav (staff) wrote: ↑Thu Feb 22, 2024 5:52 pmI see there is a confusion. I was referring to the StarWind VSAN file share witness (available only for StarWind VSAN Windows-based app). If you go Windows-based way, you can repurpose HA device for the file share later. We have no restrictions for supported SMB version, to my knowledge. This relates to node majority (https://www.starwindsoftware.com/help/C ... tness.html).
But in such case, that is:You do not need failover clustering if you follow the principle of one HA-one client (e.g., VM or host).
Code: Select all
server1 -> target1
|sync|
server2 -> target2
Building a converged setup where the storage is just presented to the host over iSCSI and that host does SMB sharing could help. Yet, I'd suggest contacting support@starwind.com for more detailed POC environment discussion and building.But if that share, as created by SW (not the volume, the share) is not highly available then I think that can't help.
It all depends on whether the target is HA or not. For HA devices, it will read/write to the replica. For non-HA (e.g., file share), you are 100% right.if target1 crashes, server1 will crash, is that right?
You can expose HAs (all mirrors) to one client without need for clustering. MPIO will mask those different paths as one and do the magic for you so that NTFS will not get upset.So I guess that if we want highly available storage we need to use the Windows Failover Clustering filesystem and expose those targets as ISCSI targets. If not, if go with one client one storage, if the target crashes the client will (probably) crash or at least it won't be able to access the storage.