Should I bother to learn Windows Storage Spaces and what about Glances export?
-
@DustinB3403 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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
Server maintenance must be performed in any case. An IPOD or a single server still has this requirement. But with an IPOD maintenance could introduce issues that you wouldn't see with a single server.
The IPOD also required much more maintenance.
-
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
We deploy traditional RAID in standalone settings not Storage Spaces.
-
@PhlipElder 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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
-
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
-
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
Only if you are looking for HA/Failover. On a single host with local storage you wouldn't need any of this.
-
@DustinB3403 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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
Only if you are looking for HA/Failover. On a single host with local storage you wouldn't need any of this.
That is true. Most cars have 4 tires. Also true.
-
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
-
@PhlipElder 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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
@PhlipElder cool cool. . . so what happens if that dataon unit fails to the 9's?
Your client would be dead in the water, no?
-
@PhlipElder 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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
Oh SWEET! DataOn. Yeah I wouldn't use anything but that for the purpose.
-
What you are showing us is nothing more than an IPOD with Hyper-V and S2D.
-
@DustinB3403 said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
What you are showing us is nothing more than an IPOD with Hyper-V and S2D.
It seems like he has disk redundancy, but not DAS redundancy.... if I understand the post correctly.
@PhlipElder You have two DAS boxes, are they redundant or stacked? It seems as if they are stacked, making what Dustin said true.
-
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
SOFS does that. But you can use a large range of RAID or RAIN systems to handle it. Gluster, CEPH, Starwind, DRBD, HAST, etc.
-
@DustinB3403 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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
Only if you are looking for HA/Failover. On a single host with local storage you wouldn't need any of this.
He already put in the "to get around" piece.
-
@Obsolesce said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@DustinB3403 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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
Only if you are looking for HA/Failover. On a single host with local storage you wouldn't need any of this.
That is true. Most cars have 4 tires. Also true.
The difference being that most cars should have four tires, most workloads should not have zero downtime maintenance. Some workloads, but not the majority.
-
@DustinB3403 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?:
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
@PhlipElder cool cool. . . so what happens if that dataon unit fails to the 9's?
Your client would be dead in the water, no?
The unit is fully redundant all the way through to the disk. If we have a complete system failure we have Veeam and the ability to spin the VMs up on short order.
-
@DustinB3403 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?:
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
@PhlipElder cool cool. . . so what happens if that dataon unit fails to the 9's?
Your client would be dead in the water, no?
yeah, sounds like a traditional IPOD. Maybe we missed something, are there two DataOn units?
What is the purpose of the DataON there? Why have that extra hardware? With just two nodes, you get WAY higher reliability without having it at all.
-
@scottalanmiller said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@DustinB3403 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?:
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
@PhlipElder cool cool. . . so what happens if that dataon unit fails to the 9's?
Your client would be dead in the water, no?
yeah, sounds like a traditional IPOD. Maybe we missed something, are there two DataOn units?
What is the purpose of the DataON there? Why have that extra hardware? With just two nodes, you get WAY higher reliability without having it at all.
We call that Storage Spaces Direct.
-
@PhlipElder said in Should I bother to learn Windows Storage Spaces and what about Glances export?:
@DustinB3403 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?:
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
@PhlipElder cool cool. . . so what happens if that dataon unit fails to the 9's?
Your client would be dead in the water, no?
The unit is fully redundant all the way through to the disk.
That's what every SAN vendor has always claimed for "single box magic." Not saying that it isn't decently reliable, but any redundancy you get do in there, you can do without it. But with fewer points of failure total. And therefore lower cost potential, too.
Given that we can meet and beat any reliability here simply by removing the DataOn, what purpose is it serving?
And if the DataOn fails (no single chassis is ever fully redundant, it just can't be), you will quickly see the single point of failure. Just turn it off, if turning it off makes things go down, it wasn't redundant.
This looks like going back to traditional inverted pyramid design. Other than using software RAID instead of hardware RAID (something that isn't new either), what's different about this than the standard, textbook "what not to do" design? Too costly, too risky. Exactly the same design we just saw fail in the other thread.
-
@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?:
@DustinB3403 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?:
@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?:
@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?:
It's like that IPOD situation I dealt with yesterday.
What about all of the server maintenance able to be done without having any down time? Or didn't they use it for that, strictly redundancy?
In a cluster setting (SOFS) this is a moot point since nodes can be patched and rebooted without any downtime.
Including the SOFS nodes, you mean. That's the important part. It fixes the single maintenance point of the SAN.
You'd need S2D (or similar tech, like SW vSAN) to get around the single maintenance point of SAN / DAS.
This is the 2-node shared SAS Hyper-V/Storage Spaces cluster mentioned above that runs a 15-18 seat accounting firm.
There are two types of virtual disks set up on Storage Spaces. One with a 64KB interleave with the storage stack similarly configured while the other is the standard 256KB interleave with the defaults for storage stack. There are six to eight server based virtual machines and at least two or three desktop virtual machines running on the cluster at any given time.
EDIT: There are multiple virtual disks set up as Cluster Shared Volumes.
@PhlipElder cool cool. . . so what happens if that dataon unit fails to the 9's?
Your client would be dead in the water, no?
yeah, sounds like a traditional IPOD. Maybe we missed something, are there two DataOn units?
What is the purpose of the DataON there? Why have that extra hardware? With just two nodes, you get WAY higher reliability without having it at all.
We call that Storage Spaces Direct.
SSD doesn't require an IPOD design, though. Just as RAID can be done in a reliable design model, or in an IPOD, so can SSD.
-
@scottalanmiller We add two more units and indeed we have enclosure resilience.
Hyper-Converged with nested resilience in Storage Spaces Direct takes care of all of these single-points of failure in a neat package.
The shared SAS setup is now considered legacy with the only place we're deploying them now being archival storage with up to eight 102 bay JBODs loaded with 12TB drives being stacked with three nodes and full resilience across the board.
HCI or disaggregate with Hyper-V and SOFS S2D are they way we're deploying now. So, the whole conversation is essentially moot.
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.
