Should I bother to learn Windows Storage Spaces and what about Glances export?
-
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
Hyper-Converged with nested resilience in Storage Spaces Direct takes care of all of these single-points of failure in a neat package.
Yes, HyperConverged would do that. But having external chassis removed the hyperconvergence and takes us back to having additional points of failure to worry about. Having chassis redundancy provides a lot of protection there. But we could move the external chassis into the server chassis for HC to reduce cost and points of failure. Two nodes instead of four. With external chassis for storage, it's still the old HA SAN model (as opposed to the IPOD SAN model), but lacks leveraging bringing everything into the chassis like HC does.
The biggest limiting factor there then is storage capacity, and also storage capacity scaling. Harder to do that if sticking to just a 2-node hardware setup.
-
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
The converged setup in the blog post is about three years old now. It was the best bang for the dollar as far as insurance against downtime at the time.
The blog post was the polar opposite of HC. IPOD is the farthest that you can get from HC. There are steps in between, like your four node, full redundant, but that's still not HC until you actually converge.
Remember that software RAID was an assumption from day one, it predates hardware RAID. So RAID and RAIN systems running in software doesn't move us towards convergence, it was almost a part of unconverged systems.
RAIN improves on a poor RAID system of the past. But it's an improvement, not a change of architecture.
-
@Obsolesce said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
Hyper-Converged with nested resilience in Storage Spaces Direct takes care of all of these single-points of failure in a neat package.
Yes, HyperConverged would do that. But having external chassis removed the hyperconvergence and takes us back to having additional points of failure to worry about. Having chassis redundancy provides a lot of protection there. But we could move the external chassis into the server chassis for HC to reduce cost and points of failure. Two nodes instead of four. With external chassis for storage, it's still the old HA SAN model (as opposed to the IPOD SAN model), but lacks leveraging bringing everything into the chassis like HC does.
The biggest limiting factor there then is storage capacity, and also storage capacity scaling. Harder to do that if sticking to just a 2-node hardware setup.
Harder than having a one storage node setup?
It's a myth that HC limits you in scale out. In makes it easier, in fact, in most cases. You aren't LIMITED to two nodes, it's simply that you don't need any more. In the original IPOD design, you are limited to one node. In the "multi-DataON" models, you can scale out more or less unlimited, same as with HC designs. No HC design has a two node limit (of which I am aware) and most go really big and the biggest, Starwind using RAID not RAIN, is limited only by the platform, not the storage layer.
-
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@Obsolesce said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
Hyper-Converged with nested resilience in Storage Spaces Direct takes care of all of these single-points of failure in a neat package.
Yes, HyperConverged would do that. But having external chassis removed the hyperconvergence and takes us back to having additional points of failure to worry about. Having chassis redundancy provides a lot of protection there. But we could move the external chassis into the server chassis for HC to reduce cost and points of failure. Two nodes instead of four. With external chassis for storage, it's still the old HA SAN model (as opposed to the IPOD SAN model), but lacks leveraging bringing everything into the chassis like HC does.
The biggest limiting factor there then is storage capacity, and also storage capacity scaling. Harder to do that if sticking to just a 2-node hardware setup.
Harder than having a one storage node setup?
It's a myth that HC limits you in scale out. In makes it easier, in fact, in most cases. You aren't LIMITED to two nodes, it's simply that you don't need any more. In the original IPOD design, you are limited to one node. In the "multi-DataON" models, you can scale out more or less unlimited, same as with HC designs. No HC design has a two node limit (of which I am aware) and most go really big and the biggest, Starwind using RAID not RAIN, is limited only by the platform, not the storage layer.
I meant from the point you made of sticking to only two nodes with internal storage. Once that storage is full, you either have to add more nodes, or add storage boxes... therefore, no longer only having 2 hardware nodes.
-
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
HCI or disaggregate with Hyper-V and SOFS S2D are they way we're deploying now. So, the whole conversation is essentially moot.
Not really HCI as described with the DataOn. That's just a software RAID version of the non-HC model.
HC has always meant physical convergence.
I believe I referred to the DataON setup as "Converged" or sometimes "Asymmetric" not Hyper-Converged which is what Storage Spaces Direct is when running with both Storage Spaces and Hyper-V on the nodes.
Disaggregate is where we have two clusters. One running SOFS (could be a similar to DataON setup as was done in the past or S2D in SOFS only mode which is our way forward) and the other running Hyper-V.
In both S2D and disaggregate setups we run with RDMA over Converged Ethernet (RoCE) via Mellanox kit for our ultra-low latency fabric.
-
@Obsolesce said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@Obsolesce said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
Hyper-Converged with nested resilience in Storage Spaces Direct takes care of all of these single-points of failure in a neat package.
Yes, HyperConverged would do that. But having external chassis removed the hyperconvergence and takes us back to having additional points of failure to worry about. Having chassis redundancy provides a lot of protection there. But we could move the external chassis into the server chassis for HC to reduce cost and points of failure. Two nodes instead of four. With external chassis for storage, it's still the old HA SAN model (as opposed to the IPOD SAN model), but lacks leveraging bringing everything into the chassis like HC does.
The biggest limiting factor there then is storage capacity, and also storage capacity scaling. Harder to do that if sticking to just a 2-node hardware setup.
Harder than having a one storage node setup?
It's a myth that HC limits you in scale out. In makes it easier, in fact, in most cases. You aren't LIMITED to two nodes, it's simply that you don't need any more. In the original IPOD design, you are limited to one node. In the "multi-DataON" models, you can scale out more or less unlimited, same as with HC designs. No HC design has a two node limit (of which I am aware) and most go really big and the biggest, Starwind using RAID not RAIN, is limited only by the platform, not the storage layer.
I meant from the point you made of sticking to only two nodes with internal storage. Once that storage is full, you either have to add more nodes, or add storage boxes... therefore, no longer only having 2 hardware nodes.
I know, and my point was that that isn't an applicable thought. Yes, sticking to two nodes would limit you to the capacity of two nodes. but there is no such limit, in either design. Whether you are doing the HC design, or the traditional "multi-storage node" design, you can just add more nodes and get bigger on the storage side.
The only time you are limited is when you go with the IPOD and CAN only have one storage node, then you are much more limited.
-
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
HCI or disaggregate with Hyper-V and SOFS S2D are they way we're deploying now. So, the whole conversation is essentially moot.
Not really HCI as described with the DataOn. That's just a software RAID version of the non-HC model.
HC has always meant physical convergence.
I believe I referred to the DataON setup as "Converged" or sometimes "Asymmetric" not Hyper-Converged which is what Storage Spaces Direct is when running with both Storage Spaces and Hyper-V on the nodes.
I see. Asymmetric is a decent term. What about it is converged, though? It seems "unconverged", if you will. Other than the software RAID running on the storage nodes.
-
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
Disaggregate is where we have two clusters. One running SOFS (could be a similar to DataON setup as was done in the past or S2D in SOFS only mode which is our way forward) and the other running Hyper-V.
Not a term that I usually see, but makes sense. This is what we would normally just call "traditional, legacy HA design", or "HA external storage." It's the standard non-IPOD setups we were seeing in the early 2000s. It's decent, but doesn't require new terminology. But it never really had a term, so maybe one is needed, new or otherwise.
-
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
HCI or disaggregate with Hyper-V and SOFS S2D are they way we're deploying now. So, the whole conversation is essentially moot.
Not really HCI as described with the DataOn. That's just a software RAID version of the non-HC model.
HC has always meant physical convergence.
I believe I referred to the DataON setup as "Converged" or sometimes "Asymmetric" not Hyper-Converged which is what Storage Spaces Direct is when running with both Storage Spaces and Hyper-V on the nodes.
I see. Asymmetric is a decent term. What about it is converged, though? It seems "unconverged", if you will. Other than the software RAID running on the storage nodes.
"Converged" in this case refers to both Hyper-V and Storage Spaces running on the nodes to provide virtual machine and storage cluster based arbitration.
