Comments on: A SAN is a single point-of-failure, too http://openquery.com/blog/a-san-is-a-single-point-of-failure-too About MySQL, Drizzle, MariaDB and more! Thu, 02 Feb 2012 21:40:24 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Can I have your horror-stories, please? (SANs and VMs) « Open Query blog http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-953 Can I have your horror-stories, please? (SANs and VMs) « Open Query blog Thu, 02 Apr 2009 09:01:47 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-953 [...] somewhat relates to the earlier post A SAN is a single point-of-failure, too. Somehow people get into scenarios where highly virtualised environments with SANs get things like [...] [...] somewhat relates to the earlier post A SAN is a single point-of-failure, too. Somehow people get into scenarios where highly virtualised environments with SANs get things like [...]

]]> By: gentlemoose http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-748 gentlemoose Fri, 13 Mar 2009 18:58:59 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-748 (followed from your more recent article looking for horror stories) SANs don't have to be expensive. I wouldn't go so far as to call that notion a myth, but certainly $25K USD per SAN including switch, HBAs, spindles, etc is not expensive in the grand scheme of things, and we've acquired several low-end EMC SANs for well under that price. I'm pretty sure you could easily pick up a shelf of 750G disks + controller heads for about $15K USD these days. Also, it's reasonable to situationally leverage existing SANs to bolster database infrastructures. For instance, we've dual-purposed several of our SANs which were originally purchased as large-capacity storage devices (many large, moderately fast spindles wherein the concern was space rather than speed) by carving out a few dozen gigs from each bulk storage spindle to create a very fast set of multi-spindle volumes to accommodate some of our databases. 20G * 14, 28 or more spindles across multiple shelves makes for a very fast, reasonably large storage solution for a growing, high-volume database. (followed from your more recent article looking for horror stories)

SANs don’t have to be expensive. I wouldn’t go so far as to call that notion a myth, but certainly $25K USD per SAN including switch, HBAs, spindles, etc is not expensive in the grand scheme of things, and we’ve acquired several low-end EMC SANs for well under that price. I’m pretty sure you could easily pick up a shelf of 750G disks + controller heads for about $15K USD these days.

Also, it’s reasonable to situationally leverage existing SANs to bolster database infrastructures. For instance, we’ve dual-purposed several of our SANs which were originally purchased as large-capacity storage devices (many large, moderately fast spindles wherein the concern was space rather than speed) by carving out a few dozen gigs from each bulk storage spindle to create a very fast set of multi-spindle volumes to accommodate some of our databases. 20G * 14, 28 or more spindles across multiple shelves makes for a very fast, reasonably large storage solution for a growing, high-volume database.

]]> By: pingback_bot http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-747 pingback_bot Fri, 13 Mar 2009 12:30:14 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-747 User <lj user="arjen_lentz"> referenced to your post from <a href="http://arjen-lentz.livejournal.com/151413.html" rel="nofollow">Can I have your horror-stories, please? (SANs and VMs)</a> saying: [...] and when it was all working again (if ever). Thanks! This somewhat relates to the earlier post <a href="http://arjen-lentz.livejournal.com/132978.html" rel="nofollow">A SAN is a single point-of-failure, too</a>. Somehow people get into scenarios where highly virtualised environments with SANs get things like ... [...] User referenced to your post from Can I have your horror-stories, please? (SANs and VMs) saying: [...] and when it was all working again (if ever). Thanks! This somewhat relates to the earlier post A SAN is a single point-of-failure, too. Somehow people get into scenarios where highly virtualised environments with SANs get things like … [...]

]]> By: arjen http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-746 arjen Mon, 29 Sep 2008 09:28:01 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-746 Replication can help with failover or read-scaling, it does not necessarily produce a standby server that's current enough. Depends on the requirements, of course. DRBD can be a good option (for Oracle too). But, the issue is also budget. Having two SANs just doubles the cost there, plus additional infrastructure on top of that. Jeez! Plus, did you see the original post, where a multi-datacenter SAN failed.... Replication can help with failover or read-scaling, it does not necessarily produce a standby server that’s current enough. Depends on the requirements, of course.
DRBD can be a good option (for Oracle too).

But, the issue is also budget. Having two SANs just doubles the cost there, plus additional infrastructure on top of that. Jeez! Plus, did you see the original post, where a multi-datacenter SAN failed….

]]> By: anonymous http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-745 anonymous Sun, 28 Sep 2008 23:39:52 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-745 Well, depending on how much you are prepared to spend, you can have another SAN and setup certain replication. In Oracle world we create physical standby and for MySQL, that would be master-slave replication. Right? The balance triangle in this case would be: - availability - cost - update performance Well, depending on how much you are prepared to spend, you can have another SAN and setup certain replication. In Oracle world we create physical standby and for MySQL, that would be master-slave replication. Right?

The balance triangle in this case would be:
- availability
- cost
- update performance

]]> By: anonymous http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-744 anonymous Thu, 25 Sep 2008 20:53:43 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-744 Businesses tend to go with a SAN if they have a large number of servers that they wish to provision storage to in an efficient manner. Or at least, to have the potential to do so (not all of them actually manage it!). Yes, it's costly. That's because SANs are a solution to a certain class of availability problems, and - frequently - SOHO environments don't have those same issues. As with anything of this ilk, getting somebody with a clue to architect it before you purchase and configure it is an essential part of having it work. You get what you pay for, whether that's kit or implementation. Yes, other solutions may be cheaper, but then again, the other solutions might not meet your actual requirements. Businesses tend to go with a SAN if they have a large number of servers that they wish to provision storage to in an efficient manner. Or at least, to have the potential to do so (not all of them actually manage it!).

Yes, it’s costly. That’s because SANs are a solution to a certain class of availability problems, and – frequently – SOHO environments don’t have those same issues.

As with anything of this ilk, getting somebody with a clue to architect it before you purchase and configure it is an essential part of having it work. You get what you pay for, whether that’s kit or implementation.

Yes, other solutions may be cheaper, but then again, the other solutions might not meet your actual requirements.

]]> By: arjen http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-743 arjen Tue, 23 Sep 2008 08:54:05 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-743 The question becomes, why go SAN at all. It's tends to be quite costly. Other solutions may be cheaper. The question becomes, why go SAN at all. It’s tends to be quite costly.
Other solutions may be cheaper.

]]> By: bkarwin http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-742 bkarwin Tue, 23 Sep 2008 02:18:38 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-742 I would credit Richard Hamming, an American mathematician at Bell Labs. He pioneered many concepts used in computer science and telecommunications, especially applied to error detection and correction. The concept of partial data failure instead of complete failure can be traced back to his work. But I get it that you're referring more specifically to application of these concepts to online application availability. :-) I would credit Richard Hamming, an American mathematician at Bell Labs. He pioneered many concepts used in computer science and telecommunications, especially applied to error detection and correction. The concept of partial data failure instead of complete failure can be traced back to his work.

But I get it that you’re referring more specifically to application of these concepts to online application availability. :-)

]]> By: laptop006 http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-741 laptop006 Tue, 23 Sep 2008 00:53:40 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-741 Finally someone with a brain. As soon as you've integrated it down to one system, whoops you need to replicate it for when it fails. Finally someone with a brain.

As soon as you’ve integrated it down to one system, whoops you need to replicate it for when it fails.

]]> By: anonymous http://openquery.com/blog/a-san-is-a-single-point-of-failure-too/comment-page-1#comment-740 anonymous Tue, 23 Sep 2008 00:01:34 +0000 http://openquery.com/blogs/a-san-is-a-single-point-of-failure-too#comment-740 We use Sans in our environment as well, and as long as you design your storage processors and network components of your SAN with the same thought in mind (that partial failures are acceptable), then you can lay out your applications/components in such away that they are all fully contained across separate storage processors and network components. Thus, they would not be any more a single point of failure than your network (which, with enough foresight and cash, they too can be set up in the same way). Usually, however, SANs are looked at as a 'shared resource', and managed in that way, instead of carefully deciding which Luns from which storage processors and raid groups get presented to which servers through which switches in terms of application failure scenarios. It takes a lot more work on the SAN admin side to work things this way, but it can be done. We use Sans in our environment as well, and as long as you design your storage processors and network components of your SAN with the same thought in mind (that partial failures are acceptable), then you can lay out your applications/components in such away that they are all fully contained across separate storage processors and network components. Thus, they would not be any more a single point of failure than your network (which, with enough foresight and cash, they too can be set up in the same way).

Usually, however, SANs are looked at as a ‘shared resource’, and managed in that way, instead of carefully deciding which Luns from which storage processors and raid groups get presented to which servers through which switches in terms of application failure scenarios. It takes a lot more work on the SAN admin side to work things this way, but it can be done.

]]>