Speaking of S2D deployment,
the two main patterns here infrastructure‑wise are
hyperconverged and disaggregated; also called converged.
Hyperconverged is where your cluster is doing everything.
This would be for a smaller business, as I said,
that's concerned principally about costs,
secondarily about simplified administration.
So, in other words,
your cluster nodes are using the failover clustering software in
Windows to do that high availability and onboard storage with
Storage Spaces Direct for the storage layer.
Now you're not going to get the same kind of performance and availability
as you will in a converged or disaggregated environment.
That's where you've got separate clusters for storage and compute,
and this allows independent scaling, independent maintenance,
and frankly, independent high availability.
And you're also, in this case,
using an external SAN so that you can give your Window Server
nodes back some CPU and some resources because they're not
concerned about maintaining the shared storage like you are in a
hyperconverged infrastructure.
Now how do we add servers to a failover cluster in which
we're using Storage Spaces Direct?
The reason why I'm covering this as a separate topic is
because if you're using Storage Spaces Direct,
then typically,
and I'm going to assume for the exam and for this lesson, that we're in a
hyperconverged environment where we want to enlist each cluster node's
local storage into the Storage Spaces Direct pool.
Okay?
So how does this work?
And I'm showing you this example in Windows PowerShell.
First, of course, we want to Re‑run cluster validation,
bringing in the existing nodes as well as the prospective new host,
and we want to make sure to include among the cluster validation tests,
Storage Spaces Direct for obvious reasons.
We then can do an Add‑ClusterNode to bring the new node in,
and that's really it.
The next time you refresh your storage,
you should find that your storage pool has enlisted
the storage on your new server.
And what happens is,
depending upon how many servers you have and how many disks you have,
it can unlock various raid‑like configurations.
For example, if you've got three,
it's actually three servers with two disks each.
The reason I'm kind of hesitating here in my speech is
that the numbers aren't as important.
But you can do traditional disk mirroring in which
you've got in your storage pool, a virtual disk,
and then behind the scene,
all of its content is being mirrored so that if one of those physical disks on
one of the cluster nodes were to fail and you replaced it,
you could reestablish the data.
Depending upon how many disks you've enlisted into
your Storage Spaces Direct Pool, you can actually do three‑way mirroring,
which would allow the failure of two physical disks,
and you can get your data back.
Now, this is all in terms of internal fault tolerance to Storage Spaces Direct,
I would hope and trust that you're also conducting
backups of your storage pools anyway, but this is from a hardware level.
And I want you to see that these various raid‑like configurations
and storage spaces in Storage Spaces Direct,
they are not, and I repeat not, industry standard RAID.
This is because we're doing it all in software.
It's a logical volume management system.
There's also, as you can see in the last example,
there's dual parity, single and dual parity involved.
And this again, would be analogous to RAID.
The traditional two‑way mirror would be RAID 1.
The traditional striping would be RAID 0, that's no parody.
And then when you get into things like RAID 5 and RAID 6,
that's what we're talking about striping data across multiple physical disks,
which gives you increased input/output. And then single or dual parity
would be that the Storage Spaces Direct pool could survive the loss of one or more than one disk in that array.