RAID Controllers - Stupidly Expensive for what they are
-
Edit: Let's try this again...
I set up a Windows Server 2012 File Server Role as a Failover Cluster (it uses SMB 3 for transparen't failover). The transparent failover worked beautifully. We had a server keel over and release the magic smok and our end users barely noticed the blip as everything failed over to the other server in less than 5 seconds.One other benefit of a modern (Windows) file server is that Deduplication is relatively easy to set up, and on that same File Server, we were getting ~30% deduplication)
NB: This was the original post... skip it if you want.
I set up a Windows Server 2012 File Share Failover Cluster that was backed by a SAN (hush, @scottalanmiller ) and got to experience the SMB3.0 transparent failover a few times...when the file server randomly rebooted a few times. It...was... beautiful (as well as the Deduplication! ~30% savings on a 2TB). -
Uh - maybe I'm confused - I didn't think SMB was a SAN protocol?
-
@Dashrender You missed the part where it was served up from a Windows 2012 File Server... This is what happens when I try to talk about too many technologies in once paragraph, lol... I'll go edit that post for clarity.
-
@dafyre said:
I set up a Windows Server 2012 File Share Failover Cluster that was backed by a SAN (hush, @scottalanmiller ) and got to experience the SMB3.0 transparent failover a few times...when the file server randomly rebooted a few times. It...was... beautiful (as well as the Deduplication! ~30% savings on a 2TB).
What does backed by a SAN mean here?
So you have a Windows Server 2012 box that is sharing via SMB3.0 storage that is on a SAN - OK... the SMB3.0 is providing file services to end users?
-
@Dashrender said:
What does backed by a SAN mean here?
SAN backing is a standard term for what is sitting "behind" the storage that you see. The backing is lower in the stack, heads are higher in the stack. So this would be a one or more Windows file server head with SAN backing.
-
@Dashrender said:
So you have a Windows Server 2012 box that is sharing via SMB3.0 storage that is on a SAN - OK... the SMB3.0 is providing file services to end users?
Correct
-
@Dashrender said:
So you have a Windows Server 2012 box that is sharing via SMB3.0 storage that is on a SAN - OK... the SMB3.0 is providing file services to end users?
Yeah... Sorry for the incoherent babble I wrote. That hurt my head when I went back and re-read it... Post fixed, lol.
But yeah, that's what we run our home-folder redirection on. When a server blips or just flat out dies, the share moves to another member of the cluster and the users are none-the-wiser. 8-)... It has saved our bacon a couple of times.
-
The biggest question would be.... why are servers blipping?
-
@scottalanmiller said:
The biggest question would be.... why are servers blipping?
Dying Power Supply... Dying RAM.... Dying CPU... server dying of old age (these servers were ~8 years old-or better). It finally blipped it's last bleep a few months ago, lol.
-
@dafyre said:
@Dashrender said:
So you have a Windows Server 2012 box that is sharing via SMB3.0 storage that is on a SAN - OK... the SMB3.0 is providing file services to end users?
Yeah... Sorry for the incoherent babble I wrote. That hurt my head when I went back and re-read it... Post fixed, lol.
But yeah, that's what we run our home-folder redirection on. When a server blips or just flat out dies, the share moves to another member of the cluster and the users are none-the-wiser. 8-)... It has saved our bacon a couple of times.
Wouldn't DFS do this as well? did SMB 3.0 solve a problem that DFS did not? - I'm asking in earnest.
-
@Dashrender Technically, this is a problem that DFS should have helped us with... In practice, we had a lot of issues actually getting the files to be synced. Was probably the SysAdmin's fault in that case, though, lol. (Points fingers at me).
I'm not actually sure how DFS responds when a server completely dies... We didn't stay with it long enough.
-
@dafyre said:
Dying Power Supply... Dying RAM.... Dying CPU... server dying of old age (these servers were ~8 years old-or better). It finally blipped it's last bleep a few months ago, lol.
Wouldn't replacing the server with something stable instead of putting in a nice SAN and multiple dying servers have fixed that for cheaper?
-
@Dashrender said:
Wouldn't DFS do this as well? did SMB 3.0 solve a problem that DFS did not? - I'm asking in earnest.
Yes and no. DFS is meant to sort of do that but does it in a very different way and often does not work. DFS is a bit flaky and certainly not designed to be an HA solution.
SMB3 is much more enterprise for high reliability.
-
@scottalanmiller said:
@Dashrender said:
Wouldn't DFS do this as well? did SMB 3.0 solve a problem that DFS did not? - I'm asking in earnest.
Yes and no. DFS is meant to sort of do that but does it in a very different way and often does not work. DFS is a bit flaky and certainly not designed to be an HA solution.
SMB3 is much more enterprise for high reliability.
But requires shared storage to provide the HA, right?
So considering the cost of the SAN and the risk of a single SAN install, is he really any better off?
-
@scottalanmiller Again... budget constraints... User Files were already hosted on the SAN and a single physical server. We hijacked the Physical Server's name for the Cluster Role (and retired that server), so we didn't have to change any folder redirection GPOs, etc...
That setup actually worked fine for about a year before that server died (it only acted up for about a week before it went kaput, lol). Now, AFAIK, the guys that still run that cluster have e-wasted the physical server that died. That just leaves one Windows 2012 Physical server (that has been rock solid) and a Windows 2012 VM running two File Server roles (one running on each server).
I'd have to go look, but the cluster is setup so that even if the other physical server fails, the single, remaining VM can run both file server roles (Node and Disk Majority + Windows File Share Witness, I think).
The net take away from that setup for us, has been Increased uptime and fewer headaches when servers start dropping like flies.
-
@dafyre said:
@scottalanmiller Again... budget constraints... User Files were already hosted on the SAN and a single physical server.
Ah, I see. Maybe the budgets wouldn't have been so constrained without being two devices to do the work of one
There is always an excuse as to why these things happen. But generally if you work back, there is an foundational decision that was bad or weird and led to a cascade of problems.
-
@dafyre said:
The net take away from that setup for us, has been Increased uptime and fewer headaches when servers start dropping like flies.
The net take away should have been "design sensibly from day one and reserve overspending for later improvements." Lower cost, easier management, higher reliability.
-
@scottalanmiller said:
The net take away should have been "design sensibly from day one and reserve overspending for later improvements." Lower cost, easier management, higher reliability.
While I agree, the design was sensible to us from day one. 8-), and as I have stated before, even knowing what I know now, I would have still done it that way because our experience, by and large, was pretty good. I didn't lose any sleep at night when things were working correctly.
They have now reached the Lower Cost (no need to buy another SAN, thanks to Scale), Easier Management (most everything is virutalized) And Higher Reliability phase now... When that last Physical Machine dies? All they gotta do is Spin up a new VM, make sure it is on a diferent Host than the existing one, join it to the cluster, and be happy... (Arguably, they should have already spun up a new VM and made it part of the cluster...).
-
@dafyre said:
While I agree, the design was sensible to us from day one. 8-), and as I have stated before, even knowing what I know now, I would have still done it that way because our experience, by and large, was pretty good. I didn't lose any sleep at night when things were working correctly.
Even thought the cost was more than double a more reliable design? What makes the design sensible or "good" in hindsight? Doesn't hindsight suggest that a lot of money was lost and unnecessary risk was taken on? It might have been "reliable enough", but if you could spend half the money and be "even more reliable", why avoid that?
-
@dafyre said:
They have now reached the Lower Cost (no need to buy another SAN, thanks to Scale), Easier Management (most everything is virutalized) And Higher Reliability phase now... When that last Physical Machine dies? All they gotta do is Spin up a new VM, make sure it is on a diferent Host than the existing one, join it to the cluster, and be happy... (Arguably, they should have already spun up a new VM and made it part of the cluster...).
Scale is pretty awesome. We have a cluster on its way, actually.
