SAN in an Inverted Pyramid Architecture for Fourteen Physical Servers
-
@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.
-
It would be nice to know the Specifics of his environment... 14 servers... wow. He said that some of them are running Hyper-V or ESXi ... What are the Specs on those machines?
What about the rest of his machines?
Could he not potentially build out his own shared storage (a la StarWind) by filling two of his existing servers with large enough drives and using Starwind to replicate between the two?
That helps to mitigate the IPOD (via redundancy), as well as grants him the shared storage.
There's a number of other spins on that that I can think of... Let's hope we haven't scared the OP off, lol.
-
@dafyre said:
Could he not potentially build out his own shared storage (a la StarWind) by filling two of his existing servers with large enough drives and using Starwind to replicate between the two?
Sure, that would support by SAN theory like I said
It would, however, be a major reduction in guests from 14 to 12 making a SAN or SAN cluster far less attractive as you start to head towards harder and harder to justify numbers of guests. -
@scottalanmiller said:
Sure, that would support by SAN theory like I said
It would, however, be a major reduction in guests from 14 to 12 making a SAN or SAN cluster far less attractive as you start to head towards harder and harder to justify numbers of guests.How would that be a reduction of guests? Let's say he has 7 Hyper-V Servers... he could P2V 2 of his Non-Hyper-V servers and use those for his SAN... That would increase the number of Guest VMs he currently is operating.
Let's assume you meant to write hosts instead of guests. Okay, so he goes from 14 physical servers down to 12 physical servers. However, to build his (2-node) SAN, and take steps towards redundancy, he's only having to buy hard drives, instead of a full-boat SAN system from a vendor.
So we're looking at Let's go crazy and say $5,000 worth of hard drives (split evenly in his 2 servers that were taken for storage). That would still be a far cry cheaper than having to purchase 2 x Nimble SAN units for replication.
I see that as a win-win. Because A) It gets him closer to where he wants to go and B) The company only had to spend $5k instead of 35k... (Prices arbitrarily pulled from magic hat).
-
@dafyre said:
How would that be a reduction of guests?
He currently has 14 guests. Converting two of them from guests to storage means 14 - 2 = 12.
-
@dafyre said:
That would increase the number of Guest VMs he currently is operating.
VMs are irrelevant to SAN discussions. It is physical hosts alone that are the determining factor. VMs are a red herring.
-
@dafyre said:
Let's assume you meant to write hosts instead of guests.
I meant physical guests of the SAN, not talking about virtualization or VMs in any way in this discussion.
-
@dafyre said:
Okay, so he goes from 14 physical servers down to 12 physical servers. However, to build his (2-node) SAN, and take steps towards redundancy, he's only having to buy hard drives, instead of a full-boat SAN system from a vendor.
So this is built on the assumption that he can consolidate and that the 14 servers are not needed. The thing is, the idea of using the SAN only makes sense if he can't consolidate and so this would not be an option. If he can consolidate then we are in a completely different discussion.
Two servers as a SAN cluster is definitely an option. But be aware that you will need to replicate the disks so it is buying twice the disks and assumes that his current machines have the necessary storage capacity do to double storage duty. A single SAN approach is only 1x the disk purchase and it is specifically the cost reduction of the storage that makes a SAN viable. He does not have replicated storage today, the assumption is that he does not need it tomorrow.
-
@dafyre said:
So we're looking at Let's go crazy and say $5,000 worth of hard drives (split evenly in his 2 servers that were taken for storage). That would still be a far cry cheaper than having to purchase 2 x Nimble SAN units for replication.
$5,000 is probably low, but we have no idea. But for enterprise drives, which is probably what we would be using, that's only 10 - 20 drives total. Since we need to replicate that's likely low.
No need for dual enterprise SAN. Going to dual enterprise SAN is assuming a need for HA which cannot be achieved with any of the other assumptions in this thread (need for 14 hosts) since you'd have HA storage and no HA elsewhere. So we are looking only at a single SAN here.
So yes, a single SAN is $30K+. But we are assuming no consolidation ability (or the 14 servers count is the issue) and no need for HA (or we have other issues that can't be addressed here anyway without buying more servers.)
