Local Storage vs 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.
-
@scottalanmiller said in Local Storage vs SAN ...:
@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.
I meant to click reply to your prior post, the one with the link and no video preview. But my point stands.
-
@JaredBusch said in Local Storage vs SAN ...:
@scottalanmiller said in Local Storage vs SAN ...:
@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.
I meant to click reply to your prior post, the one with the link and no video preview. But my point stands.
That's not an issue of a broken plugin. I cant find any plugin that does that. They removed the youTube plugins from the repos.
-
@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. I know there have been many posts both here and on other forums about SANs being oversold in situations where they are not needed. My gut instinct is that my situation is one that really doesn't require a SAN, yet I still find myself unsure that I understand the various questions that I should be considering when making this decision.
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.
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.
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. Is this functionality that the hypervisor must provide? 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?
In general, for relatively small environments such as mine, is it feasible to even attempt local storage replication? 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. What would an implementation without the SAN look like if I wanted to maintain the replication and the ability for the VMs to be migrated between hosts?
A Hyper-Converged Infrastructure setup would be the best way to go IMO.
Two nodes with decent AMD EPYC 16 Core 155 Watt+ CPU and 8x 64GB ECC if Rome/Milan based or 12x 64GB ECC if Genoa based.
We only do Microsoft's Storage Spaces Direct (S2D) and Azure Stack HCI with most of our HCI platforms being S2D.
The first place to start is here: www.liveoptics.com
Get a baseline for each VM. Daily highs and lows, weekly, and monthly. Get an idea of what the demands are on the current infrastructure.
With solid evidence on-hand, go to planning the HCI setup with enough IOPS to live today and into a 5 year future. That means knowing some company history to get an idea of growth.
-
@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.
