I don't really get the point of SAN snapshots
-
@dave247 if you're looking to replace what you have today, let's pretend it's an Inverted Pyramid, you'd likely want to reuse as much of the existing equipment as possible.
Pretending you have 1-2 hypervisors attached to a Dell SAN.
The hypervisors have maybe 1TB of storage each, and 128GB of RAM with a blazing fast CPU, and 6-12 available 2.5 HHD bays.
The simple answer would be, fill either of these servers with enough disks to match or exceed what the SAN provides and move everything onto the hypervisor. Use the second host as a backup target, migration target or a lab. Running on a single host is simple enough and it un-complicates your setup.
This 1 server runs everything, the VMs (and data on them) are backed up to here (maybe the SAN has NAS functionality), and from there to offsite.
-
@dave247 said in I don't really get the point of SAN snapshots:
I mean, I get VM snapshots - if you somehow muck up a server you can quickly roll back from snap vs restore from backups.
Yeah, it's the same concept but more granular, but still not super granular. Same basic concept, though.
-
@scottalanmiller said in I don't really get the point of SAN snapshots:
@dave247 said in I don't really get the point of SAN snapshots:
I mean, I get VM snapshots - if you somehow muck up a server you can quickly roll back from snap vs restore from backups.
Yeah, it's the same concept but more granular, but still not super granular. Same basic concept, though.
If you want to go the scenic route. . . you need a client on the VM that can watch everything.
-
@dave247 said in I don't really get the point of SAN snapshots:
I know in the past, you've recommended vSAN but what would another solution be besides that? The only thing I can think of is having multiple storage servers connected to the compute hosts via iSCSI - basically taking the place of the SAN.
vSAN is the direct replacement for legacy SAN - but vSAN just means a SAN that is virtualized (basically treating the SAN like a production workload.) So it is part of a solution, but not quite the solution on its own. I'll come back to that.
Doing multiple SANs as you describe is actually the only way that a SAN is considered production ready. That's the basic deployment methodology for SAN normally. Lots of SMBs skimp on that, but from a storage engineering perspective, that's not what "deploying a SAN" means. When enterprises deploy SANs, it is just an assumption that there are multiple ones. That SMBs sometimes deploy just one SAN is a different problem from what we are discussing here (the purpose to SANs.)
Likewise, when people say vSAN, they also mean multiple ones.
So what is the alternative? The problem with a SAN conceptually is that it is external and a new, unnecessary point of failure. SAN's problems come from the mixture of being too complex, expensive, and risky... without providing a benefit over simpler approaches.
vSAN is actually a way to replace SAN without changing technologies. On its own, it's a bad idea. Overly complex, but still way better than regular SAN. Not because it is virtual (that's a nice bonus), but from the implication that it will be used hyperconverged. That's the real problem with physical SAN - it has to be separate hardware, extra servers. vSAN we assume is not (but it could be, and that would be the same problem.)
Going past vSAN, we have technology like Gluster, CEPH, DRBD, HAST, and SCRIBE that do local storage replication and do it without needing the SAN layer. Not all products can talk to these, but those that do get big advantages by removing the complexity of iSCSI.
-
Too hard to type, made a video. It is uploading.
-
@scottalanmiller said in I don't really get the point of SAN snapshots:
Too hard to type, made a video. It is uploading.
Lazy. . Bast. . .
-
-
@scottalanmiller said in I don't really get the point of SAN snapshots:
Thanks for doing another video in response to one of my posts! Very cool of you and what a wealth of information.
I lost it at 0:41 with the pause/eye-roll
I had been getting the feeling that the term "SAN" was being used incorrectly becuase as you stated, it refers to a "storage area network" which would be the storage network portion, not the storage controller itself.
I get what you mean now about a single storage controller unit not being redundant. And in our case, ours is not as we only have the one. You probably know this by now about my setup, that we have the "inverted pyramid of doom" going on.
And thanks for the additional clarification. Very good stuff.
-
@dave247 said in I don't really get the point of SAN snapshots:
I get what you mean now about a single storage controller unit not being redundant. And in our case, ours is not as we only have the one. You probably know this by now about my setup, that we have the "inverted pyramid of doom" going on.
Essentially anyone with a SAN has one. Not exactly guaranteed, but almost. It's the key reason SANs are deployed.
Many enterprises knowingly run IPODs because at huge scale, they can be cheap. And while IPODs cannot be as fast or as reliable as alternatives, enterprises also know that performance and reliability are not the end all, be all and that "cheaper" and "fast enough" and "safe enough" can be the right choice.
SMBs tend to copy this, but forget that enterprises make the decision based on scale, and assuming that there must be value, just project that the idea must be fast and reliable. So with the lack of scale, they end up spending a fortune to make their system not work as well. So there are good reasons that it all exists, but they don't apply well to the SMB market.
-
@scottalanmiller said in I don't really get the point of SAN snapshots:
@dave247 said in I don't really get the point of SAN snapshots:
I get what you mean now about a single storage controller unit not being redundant. And in our case, ours is not as we only have the one. You probably know this by now about my setup, that we have the "inverted pyramid of doom" going on.
Essentially anyone with a SAN has one. Not exactly guaranteed, but almost. It's the key reason SANs are deployed.
Many enterprises knowingly run IPODs because at huge scale, they can be cheap. And while IPODs cannot be as fast or as reliable as alternatives, enterprises also know that performance and reliability are not the end all, be all and that "cheaper" and "fast enough" and "safe enough" can be the right choice.
SMBs tend to copy this, but forget that enterprises make the decision based on scale, and assuming that there must be value, just project that the idea must be fast and reliable. So with the lack of scale, they end up spending a fortune to make their system not work as well. So there are good reasons that it all exists, but they don't apply well to the SMB market.
What was IPOD again? I remember you mentioning that in the video but I thought you were making some analogy to Apple iPods, but now I'm wondering if that's not the case. I did listen to most of the video but it was a very distracting morning with lots of interruptions.
-
@dave247 said in I don't really get the point of SAN snapshots:
What was IPOD again?
Inverted Pyramid of Doom
-
@DustinB3403 said in I don't really get the point of SAN snapshots:
@dave247 said in I don't really get the point of SAN snapshots:
What was IPOD again?
Inverted Pyramid of Doom
ooooh yes ok. FFS.
-
An IPOD means you have 2 or more hypervisors with 1-2 switches with a SAN providing storage to your hypervisors.
-
ok so lets say I didn't have a SAN and I didn't want to use vSAN or whatever. Is there another good method, such as maybe having two physical Windows servers basically serving up mirrored storage via iSCSI or FCoE?
-
@DustinB3403 said in I don't really get the point of SAN snapshots:
An IPOD means you have 2 or more hypervisors with 1-2 switches with a SAN providing storage to your hypervisors.
yes I fully get the IPOD thing. I used to be a SpiceSquirts user and endured the many tedious posts of SAM.
-
@dave247 said in I don't really get the point of SAN snapshots:
ok so lets say I didn't have a SAN and I didn't want to use vSAN or whatever. Is there another good method, such as maybe having two physical Windows servers basically serving up mirrored storage via iSCSI or FCoE?
You literally just described vSAN. Two servers mirrored up over either iSCSI or FCoE is vSAN. That's what makes it vSAN.
-
Anything that talks over iSCSI or FCoE (or any other block protocol) is SAN. If you virtualize it, it's vSAN.
-
@scottalanmiller said in I don't really get the point of SAN snapshots:
@dave247 said in I don't really get the point of SAN snapshots:
ok so lets say I didn't have a SAN and I didn't want to use vSAN or whatever. Is there another good method, such as maybe having two physical Windows servers basically serving up mirrored storage via iSCSI or FCoE?
You literally just described vSAN. Two servers mirrored up over either iSCSI or FCoE is vSAN. That's what makes it vSAN.
ooh ok I was thinking VSAN was a product own by VMware, and not just a technical concept of VSAN
Judas Freaking Priest.
-
@dave247 said in I don't really get the point of SAN snapshots:
ok so lets say I didn't have a SAN and I didn't want to use vSAN or whatever.
There are basically four possible choices. This isn't about what is good or bad, just what is theoretically possible....
- Local storage (storage that connects without going over the network.)
- SAN (storage that connects over the network).
Then of each of those, they can be replicated or not replicated.
So you end up with...
- Plain SAN
- Replicated SAN
- Plain Local Storage
- Replicated Local Storage
-
@dave247 said in I don't really get the point of SAN snapshots:
Just a SAN that's virtualized. VMware's vSAN wasn't even the first. Starwind's vSAN is older, for example. And lots of us were building vSANs back around 2005 or earlier. It was common to do it back then, especially in labs.
