Windows Failover Clustering... what are your views and why?
-
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
So, 100 GB is actually 300 GB.
Not for the drives themselves. I'm assuming some kind of hardware/software raid, so that 100GB gets split among the drives the data goes to according to RAID level.
Blocks that are accessed more frequently (read data) don't really count as much, as I'm sure there is caching in multiple places.
If I have a VM on the CSV using 100 GB, the whole point of having the vSAN is that every byte exists on the vSAN partners to avoid any downtime of failure. So, it really is copied entirely three times.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
So, 100 GB is actually 300 GB.
Not for the drives themselves. I'm assuming some kind of hardware/software raid, so that 100GB gets split among the drives the data goes to according to RAID level.
Blocks that are accessed more frequently (read data) don't really count as much, as I'm sure there is caching in multiple places.
If I have a VM on the CSV using 100 GB, the whole point of having the vSAN is that every byte exists on the vSAN partners to avoid any downtime of failure. So, it really is copied entirely three times.
Yeah, I know that. But what you shown concern of before was the wear on drives. If you pick out one random drive, it's not getting 3x the data writes.
-
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
How much data changes every day? Do you have 100gb of changes per day? 1Tb?
Last time I ran live optics (a week or two ago), we were at around 6 TB of changes per day
What are your drives warrantied at? What's the dwpd or whatever? The idea is they only need to last 5 years / X dwpd or whatever the period is they are rated for anyways.
1 DWPD, im not so worried about the writes. I just would like to avoid additional writes where not really needed.
WHat drive model are they? How many drives per server? What RAID level is being used? Is it hw/sw raid? If hw, which card?
PERC H740P 8 GB Cache. Drive: MTFDDAK1T9TDN
14 per server Raid6 -
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
So, 100 GB is actually 300 GB.
Not for the drives themselves. I'm assuming some kind of hardware/software raid, so that 100GB gets split among the drives the data goes to according to RAID level.
Blocks that are accessed more frequently (read data) don't really count as much, as I'm sure there is caching in multiple places.
If I have a VM on the CSV using 100 GB, the whole point of having the vSAN is that every byte exists on the vSAN partners to avoid any downtime of failure. So, it really is copied entirely three times.
Yeah, I know that. But what you shown concern of before was the wear on drives. If you pick out one random drive, it's not getting 3x the data use.
Yes, correct. I misunderstood what you are saying. Either way, I am sure we are fine on writes. Im not worried about them. I do however think its silly to use more writes than needed, for data that doesnt need HA, just because we can. By nature, leaving that data where we can take large downtime off of the vSAN, causes less wear on the disks... Why would we want to add wear where not needed...
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
I do however think its silly to use more writes than needed, for data that doesnt need HA, just because we can.
I haven't yet expressed which route to take, I was first trying to understand the data aspect.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
We have a Windows Failover Cluster here using Starwind vSAN over three hosts, all local SSD storage.
I'm sure that this was covered somewhere, but are you saying that this is hyperconverged and that there are three total nodes and that Starwind VSAN is what is clustering them? So not three compute nodes hooked to a remote VSAN, but just standard three node HC?
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
Some applications naturally have HA with how they work, so as long as one VM is on hyper-v on each of the 3 hosts, the application stays up even without the VM being in cluster/CSV storage. So, why take up CSV space.
This is the biggest reason to avoid putting everything on it, IMHO.
-
@Dashrender said in Windows Failover Clustering... what are your views and why?:
Is the local physical storage all part of the pool for the CSV? If so, could you be spiking a single server's storage with a VM on that host, which could then cause performance delay for the whole CSV?
Could you, yes, but when it would happen it would happen in either case. But most of the time you'd reduce. So while the answer is yes, the result of that comes out to be "this points you away from everything on the CSV".
-
@scottalanmiller said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
We have a Windows Failover Cluster here using Starwind vSAN over three hosts, all local SSD storage.
I'm sure that this was covered somewhere, but are you saying that this is hyperconverged and that there are three total nodes and that Starwind VSAN is what is clustering them? So not three compute nodes hooked to a remote VSAN, but just standard three node HC?
Yeah, same system but we eventually decided to have each image on all three hosts rather than two. So, all three hosts now have the starwind provided clustered target.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
Data in the CSV will replicate over all three nodes because of Starwind. So, each write to a CSV is actually three fold. If all VMs are in CSV storage and writing to all three hosts, we could considerably lower the life of our SSDs.
Are you sure that this is the setup? If so, this is non-standard for Starwind (or anyone.) That's a triple mirror RAID 1 design. Really fast and really safe, but generally seen as overkill. Standard on Starwind would be three standard double mirror RAID 1 arrays, one between Node 1 and Node 2, one between Node 2 and Node 3, and one between Node 3 and Node 1. So any data would be replicated, but only once, not twice.
-
@Dashrender said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Dashrender said in Windows Failover Clustering... what are your views and why?:
Oh I see your points for sure, I was only asking if a non CSV based VM could cause a performance bottleneck on a single host - the CSV itself could get stalled out, causing a problem for all CSV based VMs. Now you have another issue to consider when troubleshooting CSV based issues.
Now - perhaps you have so many IOPs that this isn't a real issue, it was only a thought.
Oh I see. As another item on the list of why to not add everything to the cluster storage without that VM needing to be HA? Yeah, ill add that to my list.
So, do you agree option 2 is the way to go? Only add to CSV where needed...
I'm not agreeing or disagreeing - I don't know enough to have an opinion... but my question I think would lean more toward option 1 - because then whole system would be affected equally by the mentioned problem, instead of just a single node, which, which on one side might cause a fail-over and a kicking of this node from the cluster, all the way to crashing the whole cluster (but damn I would hope not).
No, the mentioned problem should make you want option 2, not option 1. You asked the question in a leading way. You didn't look at total performance, only "performance under that one really specific condition" and didn't check if that was better or worse than the alternative.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Dashrender said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Dashrender said in Windows Failover Clustering... what are your views and why?:
Oh I see your points for sure, I was only asking if a non CSV based VM could cause a performance bottleneck on a single host - the CSV itself could get stalled out, causing a problem for all CSV based VMs. Now you have another issue to consider when troubleshooting CSV based issues.
Now - perhaps you have so many IOPs that this isn't a real issue, it was only a thought.
Oh I see. As another item on the list of why to not add everything to the cluster storage without that VM needing to be HA? Yeah, ill add that to my list.
So, do you agree option 2 is the way to go? Only add to CSV where needed...
I'm not agreeing or disagreeing - I don't know enough to have an opinion... but my question I think would lean more toward option 1 - because then whole system would be affected equally by the mentioned problem, instead of just a single node, which, which on one side might cause a fail-over and a kicking of this node from the cluster, all the way to crashing the whole cluster (but damn I would hope not).
If the single non CSV VM could cause a bottleneck on a host, couldnt you argue that that same VM would also cause a bottleneck on the CSV? If anything, as the CSVFS comes with the additional overheads due to being a clustered file system, its more likely having the VM on the CSV would create a performance issue, no?
Correct. In fact, it's like 400% more likely going to cause the issue with the CSV. It can never cause the issue without CSV if it isn't going to cause it with CSV, but the opposite is not true.
-
@scottalanmiller said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
Data in the CSV will replicate over all three nodes because of Starwind. So, each write to a CSV is actually three fold. If all VMs are in CSV storage and writing to all three hosts, we could considerably lower the life of our SSDs.
Are you sure that this is the setup? If so, this is non-standard for Starwind (or anyone.) That's a triple mirror RAID 1 design. Really fast and really safe, but generally seen as overkill. Standard on Starwind would be three standard double mirror RAID 1 arrays, one between Node 1 and Node 2, one between Node 2 and Node 3, and one between Node 3 and Node 1. So any data would be replicated, but only once, not twice.
Yeah, we had that originally but moved to three node replication. Some local storage for vsan, rest for non vsan. The original plan (still is other than this internal argument) was to use the CSV for machines that need HA, and the rest of the local for machines that don't. Just some folk are pushing for making the whole lot of the local CSV storage and making all VM HA in the cluster...
Just trying to see if any reason why that's a good idea. Seems to be bad from all thought processes I have.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
Another thought. CSV data is replicated to all three hosts. So, 100 GB is actually 300 GB. 1 TB is actually 3 TB. Why would it make sense to add VMs (applications) the company can sustain long downtime with to an area where it takes up 3 x the space, on expensive SSDs. Why not put that application you dont care about, on one host, where it takes up one lot of space, leaving the other space for things the company does care about...
Well, the logic would be... if the space is available, why waste it. If the space isn't available, seems like your choice is made for you by design.
-
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
So, 100 GB is actually 300 GB.
Not for the drives themselves. I'm assuming some kind of hardware/software raid, so that 100GB gets split among the drives the data goes to according to RAID level.
Blocks that are accessed more frequently (read data) don't really count as much, as I'm sure there is caching in multiple places.
It's RAID 1 or RAID 1E. I'm asking for clarification on it. But that it is RAID is a given by how Starwind works.
-
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
How much data changes every day? Do you have 100gb of changes per day? 1Tb?
Last time I ran live optics (a week or two ago), we were at around 6 TB of changes per day
What are your drives warrantied at? What's the dwpd or whatever? The idea is they only need to last 5 years / X dwpd or whatever the period is they are rated for anyways.
1 DWPD, im not so worried about the writes. I just would like to avoid additional writes where not really needed.
WHat drive model are they? How many drives per server? What RAID level is being used? Is it hw/sw raid? If hw, which card?
Starwind is software network RAID.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
So, 100 GB is actually 300 GB.
Not for the drives themselves. I'm assuming some kind of hardware/software raid, so that 100GB gets split among the drives the data goes to according to RAID level.
Blocks that are accessed more frequently (read data) don't really count as much, as I'm sure there is caching in multiple places.
If I have a VM on the CSV using 100 GB, the whole point of having the vSAN is that every byte exists on the vSAN partners to avoid any downtime of failure. So, it really is copied entirely three times.
Damn, okay, so definitely RAID 1 Triple Mirror.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@Obsolesce said in Windows Failover Clustering... what are your views and why?:
How much data changes every day? Do you have 100gb of changes per day? 1Tb?
Last time I ran live optics (a week or two ago), we were at around 6 TB of changes per day
What are your drives warrantied at? What's the dwpd or whatever? The idea is they only need to last 5 years / X dwpd or whatever the period is they are rated for anyways.
1 DWPD, im not so worried about the writes. I just would like to avoid additional writes where not really needed.
WHat drive model are they? How many drives per server? What RAID level is being used? Is it hw/sw raid? If hw, which card?
PERC H740P 8 GB Cache. Drive: MTFDDAK1T9TDN
14 per server Raid6So the result is RAID 16. So three copies of the data, each copy on RAID 6 SSD. That's a LOT of overhead. It's a bit more than the 3x you were stating. You get the capacity of 12 drives out of a pool of 42. 71.5% overhead.
-
@scottalanmiller said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
Another thought. CSV data is replicated to all three hosts. So, 100 GB is actually 300 GB. 1 TB is actually 3 TB. Why would it make sense to add VMs (applications) the company can sustain long downtime with to an area where it takes up 3 x the space, on expensive SSDs. Why not put that application you dont care about, on one host, where it takes up one lot of space, leaving the other space for things the company does care about...
Well, the logic would be... if the space is available, why waste it. If the space isn't available, seems like your choice is made for you by design.
The available space has been made for growth expectation over the next few years. If I make all of the local storage CSV and replicated, and copy all VM (including the ones that aren't important) for three times, we won't have that room to grow in to... As it's used for storing the mirror of VMs that don't need HA. Just seems like a waste.
-
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
@scottalanmiller said in Windows Failover Clustering... what are your views and why?:
@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:
Data in the CSV will replicate over all three nodes because of Starwind. So, each write to a CSV is actually three fold. If all VMs are in CSV storage and writing to all three hosts, we could considerably lower the life of our SSDs.
Are you sure that this is the setup? If so, this is non-standard for Starwind (or anyone.) That's a triple mirror RAID 1 design. Really fast and really safe, but generally seen as overkill. Standard on Starwind would be three standard double mirror RAID 1 arrays, one between Node 1 and Node 2, one between Node 2 and Node 3, and one between Node 3 and Node 1. So any data would be replicated, but only once, not twice.
Yeah, we had that originally but moved to three node replication. Some local storage for vsan, rest for non vsan. The original plan (still is other than this internal argument) was to use the CSV for machines that need HA, and the rest of the local for machines that don't. Just some folk are pushing for making the whole lot of the local CSV storage and making all VM HA in the cluster...
Just trying to see if any reason why that's a good idea. Seems to be bad from all thought processes I have.
So really how I see it is...
-
The benefit is a simple, uniform process that wastes gobs and gobs of resources. But wasting resources is kind of how this is designed. This is way beyond nuclear device level protection. Triple Mirror RAID 16 is higher protection than anything I've ever seen, literally ever, including spinners. With enterprise SSD, this is through the roof. You should see data loss from RAID failure, and I'm just guessing, with millions of years between data loss events. Easily tens of millions of years. RAID 1 with spinners is immeasurably high, over 80,000 years. So you can imagine the "adding zeros" math.
-
This saves on resources and might improve performance. But that doesn't seem like a goal too much. Not that good business isn't always a goal, but it seems like someone has a bee in their bonnet about somethings that it might not be worth rocking the boat on. Keeping everything on the CSV with loads of overhead gives you the least to come back and bite you while all of the money lost from doing this is someone else's problem already.
Personally, if it was my company, I'd do #1. If I were an employee of a company doing this, I'd do #2.
-
