SAN in an Inverted Pyramid Architecture for Fourteen Physical Servers
-
@Carnival-Boy said:
When the SAN fails you lose access to ALL your business applications. Whereas if one of his servers fails he only loses access to 13/14 of his business applications (about 7%).
You are preaching to the choir
However, there are a few things around this:- At this scale he would be looking at enterprise SAN, not toy SANs. He can look at active/active systems with incredible maintenance plans that are dramatically less likely to fail than a normal server.
- He does not have HA today, so this is not a move from HA to something much less reliable. It is a move from one SA architecture to one that is only nominally less safe (because it is a mainframe class SAN that we are discussing.)
- You have to look at total reliability, not anecdotal failure modes. Yes, if the SAN fails everything goes down. But what are those chances, how quickly can EMC or HP get it fixed or replaced and how does that compare to other risks we are not concerned about such as the building burning down, flooding, snow storm and other "outage creating conditions."
- Unlike inverted pyramid of doom discussions that we normally have, this one is not "SAN at any cost" but "SAN as a means to lower the cost." So you have to ask how much cost savings is it worth to take on a small amount of additional risk. Normally we are talking about scenarios where people spend extra to increase risk and do so with non-enterprise SANs (Equalogic, HP MSA, etc.)
-
@Dashrender said:
Yeah, how is him going to a single SAN not an IPOD?
It sure is. But an IPOD that is lower in cost rather than higher and one that has an enterprise, mainframe class SPOF rather than a fragile, hobby one.
-
In Where to Consider a SAN, this is that use case.
- Many servers to make the SAN about lowering the cost of storage. SANs should always be about cost savings, not features or reliability.
- No HA. A SAN would not work well here if he needed HA. But he does not have it, so the SAN is not breaking that.
So our SAN option meets the necessary criteria for consideration: saves money, does not undermine reliability in any significant way.
-
Slow down. Before suggesting a SAN as a potential solution, the first thing to find out is how many servers he has (not just physical). If he has 14 physical machines but only 18 servers because only 4 of those servers are currently virtualised and the rest are running on bare metal, then the answer is unlikely to be an enterprise SAN. We need way more information before talking about a solution.
-
@scottalanmiller said:
@Dashrender said:
Yeah, how is him going to a single SAN not an IPOD?
It sure is. But an IPOD that is lower in cost rather than higher and one that has an enterprise, mainframe class SPOF rather than a fragile, hobby one.
You're assuming lower cost because you assume the 14 hosts have 30+ VMs on them. What if he has 10 pizza boxes with bare metal (or even virtualized but still only one VM)?
What if servers were purchased for storage reasons not processing reasons? We just don't know anything about the environment yet to even start having a discussion, which is very odd for you
-
@Carnival-Boy said:
Slow down. Before suggesting a SAN as a potential solution, the first thing to find out is how many servers he has (not just physical). If he has 14 physical machines but only 18 servers because only 4 of those servers are currently virtualised and the rest are running on bare metal, then the answer is unlikely to be an enterprise SAN. We need way more information before talking about a solution.
I qualified it above. But all fourteen are bare metal as it was stated above (Hyper-V on BM, ESXi on BM.) SAN as a solution has no dependence at all on what the OS or HV is. That they do or do not run virtualization is not a factor in the effectiveness of a SAN in any way.
-
@Dashrender said:
You're assuming lower cost because you assume the 14 hosts have 30+ VMs on them. What if he has 10 pizza boxes with bare metal (or even virtualized but still only one VM)?
I'm assuming nothing of the sort. I'm unclear what connection you are making between VMs and SAN at all. SAN value is based on nothing except: number of hosts, size of storage. That's it. Why are VMs in the picture at all?
-
@Dashrender said:
What if servers were purchased for storage reasons not processing reasons?
That would swing the discussion that much more heavily towards single unified storage as a cost saving measure. Storage sprawl is even more costly than server sprawl.
However he did state that he had no shared storage. So this seems unlikely.
-
@Dashrender said:
We just don't know anything about the environment yet to even start having a discussion, which is very odd for you
Is it? He stated pretty clearly some factors about his environment and I stated that this would suggest that very likely either he needs to consolidate the servers (like down to one!!) or if he needs so many servers that storage consolidation would generally be a good path.
We know that he has fourteen physical servers, well into the "SAN is almost always cost effective" range, we know that he does not have shared storage today and we know that HA is not needed. Given that information, we have a lot to work from as a starting point.
-
@scottalanmiller said:
@Dashrender said:
You're assuming lower cost because you assume the 14 hosts have 30+ VMs on them. What if he has 10 pizza boxes with bare metal (or even virtualized but still only one VM)?
I'm assuming nothing of the sort. I'm unclear what connection you are making between VMs and SAN at all. SAN value is based on nothing except: number of hosts, size of storage. That's it. Why are VMs in the picture at all?
But you also have no idea how much storage he currently has. We don't know why he has 14 servers. Maybe he's in a dev shop and management is crazy and just bought everyone their own box, we just don't know.
-
@scottalanmiller said:
@Dashrender said:
What if servers were purchased for storage reasons not processing reasons?
That would swing the discussion that much more heavily towards single unified storage as a cost saving measure. Storage sprawl is even more costly than server sprawl.
However he did state that he had no shared storage. So this seems unlikely.
By shared storage I assumed he meant that he has no storage that is shared between two or more hosts for HA purposes, not specifically that he doesn't have file level shares or even block level access. But I could have been reading to much into that. Again not enough information to know.
-
@Dashrender said:
But you also have no idea how much storage he currently has. We don't know why he has 14 servers. Maybe he's in a dev shop and management is crazy and just bought everyone their own box, we just don't know.
I agree, I know nothing about that. What I am unclear on is... why are those important factors? You've mentioned VMs, storage size, etc. But are any of those significant factors in looking at a SAN as a viable approach? Assuming each server has at least basic storage to boot from and since most are stated as hosting VMs, there must be some amount of storage on them.
I feel like you are holding back some thought that I am not seeing. I just don't see where the "unknowns" that you state matter. Sure, there are massively fringe cases where these nodes have no storage at all and not shared storage and that's why I didn't state that SAN is the answer, only very good for consideration. I've not seen anything said that would make that in any way less true.
-
@Dashrender said:
By shared storage I assumed he meant that he has no storage that is shared between two or more hosts for HA purposes, not specifically that he doesn't have file level shares or even block level access. But I could have been reading to much into that. Again not enough information to know.
He stated that he had no shared storage and therefore was unable to do HA. If he has shared file or block he would have the technology that he needed.
-
@scottalanmiller said:
@Dashrender said:
By shared storage I assumed he meant that he has no storage that is shared between two or more hosts for HA purposes, not specifically that he doesn't have file level shares or even block level access. But I could have been reading to much into that. Again not enough information to know.
He stated that he had no shared storage and therefore was unable to do HA. If he has shared file or block he would have the technology that he needed.
I'd be willing to bet there is a disconnect there in the mind of the OP that makes him believe he doesn't have something that he quite possibly does have, therefor his believe that he can't do something. But then again I could be wrong about that.
But now we are just bouncing off each other. I'll bow out of this conversation until the OP returns.
-
That may be. I think that I made it clear that I was providing feedback both on what might be wrong assumptions as well as what would be likely cases if they were not.
-
@Dashrender said:
This is a sweeping statement. How do you know he doesn't need HA?
Because the nature of HA makes this so. If it was needed, it could be afforded. One essentially causes the other. The need for HA can only exist where there are profits so great that HA would not be an issue to implement. If there are no profits, HA is not needed. HA is a tool for high income environments.
Yes, there is the case where it is needed and not realized, but we know that HA has been thought about, discussed and dismissed (even just in this thread.) So while there is room for "something missed" I don't feel that it is in any way sweeping. Everything about the existing design, the statements made and the normal needs of the SMB line up.
Whether he does not need HA because it is not a business concern or because the business decided to not pursue it would be the same result.
-
@Dashrender said:
They could have been lucky and never experienced an outage of any kinda therefore not realizing they need it.
Possible, but generally anecdotal outages do the opposite - they create a fear of outages greater than the likely outcome. Humans react very recklessly to experiencing danger. So company that have had outages tend to get HA where not needed rather than moving towards appropriate risk behaviour.
-
@Dashrender said:
Statements like this are really no different than the opposite - Hey I need HA, why, because we can't afford downtime.
Ah, this is good logic. And I have a reason for my madness. Maybe this is wrong, but this is why I feel that it is very different:
Normal Case: Hey, let's spend money and increase risk up front to mitigate a perceived risk we have not evaluated. HA introduces risk that you would not want to consider without knowing why you are doing it.
This Case: Hey, let's not spend money and increase risk up front to mitigate .... we don't know if this has been calculated or not. Avoiding HA avoids the extra risk.
So yes, I'll agree that I stated "does not need HA" incorrectly. As someone looking to improve the infrastructure they "do not need HA or are currently in a state of their needs not being met." The proposals on ideas to move forward are based around "improving the existing state regardless." Given his current state, these two different approaches (full consolidation and/or storage consolidation) almost certainly mean improvements. If he needs HA that's a complete change that we cannot assume in any way from the post. He gives lots of indication that it has no need to be looked at, but if needed we would actually fall back to the same two approaches of consolidation before looking at it anyway.
So yes, maybe HA is needed. I am approaching this as an "essentially known improvement" that is done regardless of the need for HA but does not address HA itself.
-
@Dashrender said:
I'll bow out of this conversation until the OP returns.
I suspect he may run away screaming and never return
-
Partially why I created a new thread, this was way too divergent from the original topic. Although I do feel that it is important to mention that he may be missing "enterprise-like" opportunities within his existing budget.
