Local Storage vs SAN ...
-
@scottalanmiller said in Local Storage vs SAN ...:
vSAN is any SAN run virtualized
I think that is incorrect. The definition is virtual storage area network. A software defined storage area network if you will.
That is not the same as a virtualized storage area network.
-
@scottalanmiller said in Local Storage vs SAN ...:
@Pete-S said in Local Storage vs SAN ...:
DRBD, Gluster and Ceph are simply technologies used to build a vSAN.
They can be, but 99% of the time no SAN layer will be used. I've never seen Gluster or CEPH used to make a vSAN and DRBD mostly only in a lab. They are so much faster and more robust without the SAN layer that it's not popular to do that. So much of their value comes from removing the need and complexity of the networking layer since the storage itself is already replicated to each node. If you add the vSAN layer, you have to deal with a loss of redundancy (in the connection layer) and build that back in.
I don't think that there is such a thing as a SAN layer by definition.
A SAN is just a storage area network. It doesn't imply that it has to have SAS, iSCSI or fiber channel or any other protocol that is traditionally used by physical SAN units.I'd say a SAN is an architecture more than a specific technology.
-
@Pete-S said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
vSAN is any SAN run virtualized
I think that is incorrect. The definition is virtual storage area network. A software defined storage area network if you will.
That is not the same as a virtualized storage area network.
There's some contention around the "vSAN"/"VSAN" designation.
StarWind and VMware adopted the vSAN designation for their Hyper-Converged Infrastructure solution sets IIRC. Both did.
HCI means local storage on each node, a dedicated network fabric for node to node storage I/O, and resilience/redundancy for the disks based on how many nodes and what kind of performance is needed.
Fault Domains are at the disk and node level while some products allow for a form of Stretch Cluster which could be rack to rack, DC to DC, or intra-DC within a certain amount of latency (S2D/AzSHCI is 5ms or less).
-
@PhlipElder said in Local Storage vs SAN ...:
StarWind and VMware adopted the vSAN designation for their Hyper-Converged Infrastructure solution sets IIRC. Both did.
Both do vSAN. So it makes sense as they run SAN appliances on VMs.
But neither use it to designate hyperconvergence, which is important, because it doesn't.
Both of them offer HCI options, both offer it uses their vSAN products.
Both of them also offer "traditional" SAN that is virtualized using those vSAN products as well.
-
@PhlipElder said in Local Storage vs SAN ...:
HCI means local storage on each node, a dedicated network fabric for node to node storage I/O, and resilience/redundancy for the disks based on how many nodes and what kind of performance is needed.
Well, it doesn't quite mean all of that. It just means putting everything onto the individual node. It doesn't actually imply the network fabric, resiliancy, redundancy or anything like that. All of those concepts were layered onto the term much later by marketing teams. Hyperconvergence itself is much simpler, like all of these terms.
-
@Pete-S said in Local Storage vs SAN ...:
A SAN is just a storage area network. It doesn't imply that it has to have SAS, iSCSI or fiber channel or any other protocol that is traditionally used by physical SAN units.
I'd say a SAN is an architecture more than a specific technology.It is, for sure. But there is a specific type of technology, not specific technology, to make that architecture.
SAS doesn't qualify to be a SAN, for example. If you connect via SAS, that makes it local storage. If you use iSCSI, that makes it SAN attached.
SAS doesn't create a network, iSCSI does. Hence the difference. To be a storage area NETWORK, you need a network protocol. So the architecture designates the type of technology.
SANs came about to address the limitations of direct attach (SAS, SCSI, ATA, etc.) We already had shared storage before we had SAN. SAN let that shared block storage go onto a network. So you need the network protocol to make it a SAN.
-
@Pete-S said in Local Storage vs SAN ...:
I think that is incorrect. The definition is virtual storage area network. A software defined storage area network if you will.
So yes, in the same way that SAN technically refers to the network and not the devices or protocols, but is rarely used that way.
But in that sense, vSAN has existed as long as we had software controlled switches, because thats the "v" piece if we use it that way and then all those Starwind and VMware products can't be vSANs. They are only a vSAN in the sense that the misuse of SAN means the appliance, not the network, and they are that appliance virtualized. In both cases, and all others not mentioned here, it is the virtualization of the appliance, not the network, called vSAN by the vendors, engineers and end users.
In lots of cases, the network is virtualized too, just by the nature of how it is used. But it's virtualized whether vSAN is used or not. That's just SDN.
-
@scottalanmiller said in Local Storage vs SAN ...:
@PhlipElder said in Local Storage vs SAN ...:
StarWind and VMware adopted the vSAN designation for their Hyper-Converged Infrastructure solution sets IIRC. Both did.
Both do vSAN. So it makes sense as they run SAN appliances on VMs.
VMware vSAN runs directly on the hypervisor as far as I know. I haven't installed it myself even if I specced it for customers.
-
@Pete-S said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
@PhlipElder said in Local Storage vs SAN ...:
StarWind and VMware adopted the vSAN designation for their Hyper-Converged Infrastructure solution sets IIRC. Both did.
Both do vSAN. So it makes sense as they run SAN appliances on VMs.
VMware vSAN runs directly on the hypervisor as far as I know. I haven't installed it myself even if I specced it for customers.
They CLAIM that to be true, but they, like MS, often speak in licensing terms rather than how things are physically implemented.
What's funny is that if that is true, it would obviously make it not a vSAN at all. Which is totally plausible as it is a latecomer to the market and like everything with "virtual" or "cloud" slapped on it, they are just playing on the marketing name that people have heard. vSAN is the product name, not its description.
VMware vSAN uses a proprietary SAN protocol to distant nodes (and I assume the local one for transparency) making it... a traditional physical SAN. Just a converged one, rather than a remote one.
None of that is bad. It's all just funny that they claim to explicitly not be the product description whose name they used.
-
Examples in known open source worlds...
If you run ProxMox with DRBD on the Debian (host) layer, it's RLS assuming ProxMox has local disks.
If you then make that block storage available over the network, it becomes a SAN (a traditional / physical SAN.) A SAN with replication for resiliency.
If you run ProxMox and make a VM of Ubuntu and in that VM install DRBD it may or may not be RLS depending on where the host is getting its storage from for that VM. To the VM it will appear as if it is RLS, but we really don't know unless we check the stack. It's just the replication piece here.
If you then make that DRBD block layer in the VM available over the network, it becomes a vSAN.
