Local Storage vs SAN ...
-
@BraswellJay said in Local Storage vs SAN ...:
I bought a copy of Linux Administration Best Practices by @scottalanmiller and am reviewing the chapters on system storage, in particular the parts on SANs, local storage and replicated local storage.
woot woot!!
-
@BraswellJay said in Local Storage vs SAN ...:
Our needs are not sophisticated. We will have only a handful of VMs. A file server, sql server, freepbx, inventory management system server, security system server and an internal application server for a few internal tools. For most of these we can afford some downtime in the event of a host failure. The exception is really the SQL server. While it would not be catastrophic for some downtime it would be far superior from a continuity perspective if it could fail over to a secondary host if necessary.
Remember... SAN causes downtime, it cannot protect against it. If you are concerned about stability, then SAN should be ruled out even more. SAN is only okay when you are willing to take on extra risk because you want some other factor.
If stability or performance are your top priorities, then local storage wins. If you want lower performance, lower stability in exchange for massive scale consolidation then SAN can enter the picture.
-
@BraswellJay said in Local Storage vs SAN ...:
Our needs are not sophisticated. We will have only a handful of VMs.
That right there should have always taken SAN off of the table. Even twenty years ago, that wouldn't have allowed it to be viable.
-
@BraswellJay said in Local Storage vs SAN ...:
With that in mind, I had planned for two hosts so we could survive a failure of one of them. My primary confusion though is how would I accomplish replicated local storage.
How would you do it with SAN?
Do it the same with local storage. The real problem is that you don't do it with the SAN, someone pulls a shell game and gets you to look the other way and ignore the risks. With local storage, you are paying attention and actually trying to mitigate the risk (even though the risk is much less.)
Remember.. ANYTHING with SAN is more reliable without the SAN. If the SAN "feels" reliable, it's because you've missed where the risk was shifted. No exceptions. SAN adds complications and points of failure without any reliability benefits (it's simple physicals, it's impossible for a SAN to be beneficial or useful in a reliability discussion - it only makes it riskier, no exceptions possible.)
-
@BraswellJay said in Local Storage vs SAN ...:
The best practices book mentions several technologies (DRBD, Gluster, CEPH) that can be used for RLS but I would think that these would have to run in the hypervisor itself and not as separate VMs on the host. Is that correct?
They are run wherever the storage is used. The are the same technologies necessary to make a SAN reliable or local storage (remember... from the perspective of the SAN, it is all local storage - the tech doesn't change.)
DRBD, Gluster and CEPH typically run on the hypervisor. But they can also run as a VM. There are lots of ways to design reliable storage. It's even possible to make SAN reliable, but never AS reliable as not SAN.
-
@BraswellJay said in Local Storage vs SAN ...:
Our MSP has quoted an EMC SAN device to the tune of $25k so that VMs could be migrated between hosts with storage being on the SAN
And hopefully your fired them on the spot. Never let them in the door again.
-
@BraswellJay said in Local Storage vs SAN ...:
so that VMs could be migrated between hosts with storage being on the SAN.
Okay but who cares? That's not where your risk is. The risk is 99% in the SAN. Where do you migrate when the SAN fails?
-
MOST IMPORTANT THING>>>>>>>>>>>>>
You are asking the wrong questions. You need to start with "the goal" and ask questions that get you there.
In theory you are proposing that your goal is high availability, but other things you state prove that high availability shouldn't be on your radar. So you have a goal problem right from the start.
Because you have a goal problem, it is really easy to get tricked by the MSP scum that are trying to screw you over (they are seriously trying to screw you, I'm 100% serious when I say to walk them out the door and never speak to them again - these people hate you and your company and will hurt you just for fun.)
They are taking advantage of you. They also are not an MSP, you should not call them that as that, as well, is a sales trick to make them sound like consultants instead of sales people. They are not IT, they are sales. They don't represent your business needs, they represent the vendor. They don't propose what is good for you, they propose what makes EMC the most money. They are a VAR, they can't be in IT if they also do sales. The two by definition have to be exclusive (conflict of interest at the most core level.)
They are a VAR willing to do anything to make a quick buck.
-
@BraswellJay said in Local Storage vs SAN ...:
yet I still find myself unsure that I understand the various questions that I should be considering when making this decision.
This, too, tells you....
If you don't know, then SAN isn't viable. You'd know, you'd have no other choice.
For normal shops, only single servers make ANY sense. In super rare situations, where high availability matters AND you don't run high availability workloads (who falls into this bizarre niche???) then having HA here would always be from hyperconverged solutions, always.
-
I'm going to make a video just for this thread BUT, watch this video first while I'm making it...
-
@scottalanmiller said in Local Storage vs SAN ...:
I'm going to make a video just for this thread BUT, watch this video first while I'm making it...
LOL - nice!
-
Just recorded a forty minute video on this, lol. Uploading now.
-
It's taking a long time to upload
-
@scottalanmiller said in Local Storage vs SAN ...:
It's taking a long time to upload
You know, there are no issues with plugins on my nodebb systems. You should really look closer at what your errors are.
-
@JaredBusch said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
It's taking a long time to upload
You know, there are no issues with plugins on my nodebb systems. You should really look closer at what your errors are.
I'm not uploading it HERE. I'm uploading it to YouTube.
-
@BraswellJay said in Local Storage vs SAN ...:
We are planning a server upgrade and I find myself faced with the question of whether a SAN is necessary.
No, a SAN will not be needed.
What SAN provides is shared storage. Today the preferred solution for shared storage is a vSAN. vSAN is basically local storage from several hosts networked together and replicated. It provides shared storage for the hosts. DRBD, Gluster and Ceph are simply technologies used to build a vSAN.
But maybe you don't need that either. Most don't.
The real question is: what are the business requirements and budget for the applications you run?
-
-
@Pete-S said in Local Storage vs SAN ...:
But maybe you don't need that either. Most don't.
The real question is: what are the business requirements and budget for the applications you run?This is key.
-
@Pete-S said in Local Storage vs SAN ...:
vSAN is basically local storage from several hosts networked together and replicated. It provides shared storage for the hosts. DRBD, Gluster and Ceph are simply technologies used to build a vSAN.
Technically none of those are vSAN. vSAN is a specific means of providing RLS using traditional SAN stack tech. It came about later than RLS. These three all predate vSAN concepts. Starwind does vSAN, for example.
With a vSAN approach you either have something directly on the hypervisor or more commonly a virtualized SAN appliance on a VM. This approach is only common on VMware because it is so lacking in basic features that it is necessary there, just like it is the only platform that requires hardware RAID - everyone else has software RAID built in.
The upside to vSAN is that it "looks" just like SAN in every sense and vendors trying to push you to SAN are fooled because all they see are the iSCSI or ATAoE or whatever adapters in place.
Traditional RLS like CEPH, DRBD, etc. don't have the SAN protocol layer making them simpler, faster, and more robust. There is little value in putting them in a VM so they tend to be deployed in the hypervisor directly.
Some, like Gluster, require a local driver and show up as being Gluster at the driver level. Others, like DRBD, mount as a local filesystem and are undetectable at that level of abstraction and appear as if you are using a regular local disk. Any system trying to detect local disk would believe that that is what it had.
So while the new VMware world vSAN approach has gotten a lot of attention as a way to "replace SAN" using RLS, it's mostly marketing buzz. RLS techniques are old and have been around long before virtualized SAN was imagined as having value. DRBD wasn't the first in 2007, but it was an early player in the enterprise space. But RLS goes back to the 1970s long before SAN or VMware.
Also worth noting, most SAN is actually vSAN. vSAN doesn't imply that it runs on the same box or is RLS. It's a different layer of concept.
SAN refers to block storage over a networking encapsulation protocol and has a set of protocols known as the SAN protocols that are normally used (FC, iSCSI, etc.)
vSAN is any SAN run virtualized (which is how production workloads are generally run, so lots of SAN is done this way.) Most shops building their own SANs will build vSAN without even thinking about it. It's just SAN in a VM. Being in a VM means it COULD be local, could be distant, it's not specified.
Neither SAN or vSAN implies any redundancy, only that the storage is block and over a remote networking protocol and vSAN only then implies that the workload has been virtualized making it all but a useless term (we don't call servers vServers in other contexts.)
RLS refers to the block storage being local AND replicated between nodes. Good SAN deployments have to use RLS to make themselves reliable. This is what a proper 3PAR or Clariion deployment will do - they have multiple nodes and RLS replicates so that a full node can fail. Under the hood, RLS is the only mechanism for redundancy if it truly exists.
For SAN to be truly reliable, it needs RLS. vSAN being SAN, same thing. Lots of vSAN is chosen because it is the smarter way to do SAN, but it still needs RLS to have that value. Many vSAN products include RLS setup out of the box, making people confuse the two, but the concepts are different. Lots of vSAN deployments aren't redundant and lack RLS, some aren't even local.
Starwind, as an example, offers vSAN that is non-redundant and remote (just a traditional SAN but with good technology.) And they offer vSAN that is clustered and redundant, but still remote and just a SAN cluster. Or you can move the VMs onto the hosts that they are providing storage for and make it RLS. All three are as designed.
It's complicated because vendors like VMware use concept names, like vSAN, as product names and market them as meaning something unrelated to their terms.
So all that to say vSAN is definitely an option here, if it is an RLS architected vSAN. Or another way.... vSAN is a tool, RLS is a solution. When solutioning, vSAN is one component that could be used to achieve RLS.
-
@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.
