> Hooookay, well that was an interesting meeting! o_O
>
>
>
> First, it appears that our head office is replacing their current
> arrangement with a big new SAN.
>
> The concept of a SAN utterly baffles me. As far as I can tell, a "SAN"
> basically means that instead of connecting your HDs to the server that
> wants to use them, you connect them to a network instead, and then the
> server accesses it over the network. This has the following benefits:
>
> * Tens of thousands of times more expensive than a direct connection.
>

For a small or remote office with a couple file-servers, I agree that it 
doesn't make sense but for a data center, it's a different story.  If 
you have 200 servers connected to the SAN, the "unit cost" of the SAN 
hardware becomes a lot more palatable, and you can leverage unused disk 
space that nay servers will have.

> * Hundreds of thousands of times reduced performance compared to a
> direct connection.
>

Not necessarily.  It depends a lot on the configuration of the locally 
attached drives vs. SAN logical disks, and the types of IO requests that 
are made (e.g. long sequential reads or writes vs. lots of short random 
file accesses).  SANs have all kinds of caching mechanisms that can make 
the IO actually faster than a SATA connection.

> * Radically increased complexity compared to a direct connection.
>

That depends on the point of view.  From the server administrator's 
point of view, it's much simpler.  She no longer has to worry about 
spreading her disks across multiple controllers, mirroring, etc.... on 
which partition should the indexes go?  What level of RAID to use? Is 
there enough power in the server's power supplies to drive an additional 
pair of disks?  It's all taken care of at the other end of a pair of 
fibre connectors.

 From the point of view of the backup administrator, it's much simpler 
since he no longer has to worry about making sure that the backup agent 
is running on all the servers and that their schedules don't actually 
step over each other's toes, etc...  it can all be done off-line in the 
background.

You just had a very weird problem?  Just clone the DB to an new set of 
disks, and assign those on a lab server so that the developpers can work 
on the issue all weekend.

The biggest added level of complexity is that all these people have to 
talk to one another.  Scary.  I know.

> * If the storage network fails, ALL servers fail, so you're adding a new
> single point of failure.
>

True, but that rarely happens.  In 15 years, I've seen it happen once, 
and heard of one other occurance.  Compared to a hundred of Compaq 
Proliant drive arrays marking all disks in the RAID bad at once, 
happening on a weekly basis for 6 months, until Compaq admitted they had 
a faulty backplane desing on their units and agreed to replace them all...

> * All the servers now have to share the limited bandwidth available. One
> busy server can bring all the others to a crawl.

What limited bandwidth?  Even a SAN that's been improperly designed, and 
that has seen 5 years of unchecked growth will have more than enough 
bandwitdh to accomodate all the servers.  Have you seen the 
specifications of the SAN your head office wants to implement and were 
able to determine there will be bottlenecks?

> Oh, wait, I just found a real advantage: If you want to move a disk from
> one server to another, you just press a button, rather than having to
> physically move the device.
>
> Oh, well, that /totally/ makes it worth it. And, uh, when will you
> *ever* need to perform this operation? I mean, seriously, I've been
> working at the UK site for almost 10 years now, and I've never once
> wanted to do this. And even if I did, if on one day in 10 years I have
> to shut both servers down to physically move a drive, I think I can
> probably live with that.

My current customer has two data centers with 350 servers in each.  "We 
need more disk space on server XYZ" happens on a daily basis, in fact, 
multiple times a day, in some cases (e.g. a fast growing log file due to 
a change in user traffic, or the activation of a debbugging feature 
during problem troubleshooting)

> First of all, speed. The LTO-3 tape system we currently use has a
> maximum transfer rate of 80 MB/sec. At that rate, 200 GB should
> theoretically take about 41 minutes (which agrees with my actual backup
> logs). But our Internet connection is a piffling 5 Mbit/sec. At that
> speed, 200 GB should theoretically take... 3 days + 17 hours.
>
> And you want to do this /nightly/???
>
> Second, what is the purpose of a backup? The purpose of having a "backup
> copy" of your data is so that if your working copy dies somehow, you can
> use the backup copy to get your data back.
>
> This only works if the backup copy is more reliable than the working
> copy. If your working copy is on spinning disk, and you're stupid enough
> to put your backup copy on spinning disk as well... then it becomes
> equally likely that the /backup copy/ will die and you'll be left with
> just the working copy.

As long as your working copy doesn't disappear before your can recreate 
the backup copy, where's the problem?  Are you saying that RAID is a 
waste of time because there's an equal likelyhood that any of the disks 
in the array will die?

> Third, having access only to the most recent backup is no good. There
> are scenarios where that would be perfectly OK, but in our line of
> business, we sometimes have to recover data from /months/ ago. Data that
> has been accidentally deleted. Data which got corrupted. Data which we
> thought we didn't need any more but actually we do. And so forth.
>

Have they actually stated that you would lose the ability of going back 
to older copies of your backups?

If so, make a business case (or let your boss know) that this is 
unacceptable.  They may reconsider, or decide that it's not worth the 
investment.  Either way, you will have your "I told you so!" e-mail in 
case a problem occurs.

> So it's no good at all just mirroring what's on the server onto another
> server somewhere else. The /history/ must be kept. Now, there are
> various ways you might achieve that, but all of them unavoidably involve
> the set of backup disks being drastically larger than the total size of
> the working disks. And, if we're going to continue our current policy of
> never deleting old backups, then the backup disk set must continue to


> that's far less reliable.
>
> And then there's the fact that you either need to keep all this disk
> spinning (i.e., ever increasing power and cabling demands), or only keep
> the recent backups spinning (i.e., managing powering off and powering on
> drives, which supposedly shortens their lifetime).
>
> In all, this seems like an extremely bad idea.
>

Have they actually stated that they would not be taking tape (or more 
than likely DVD) backups of that data for archival?

In all likelyhood, that remote copy will probably be backed up to 
offsite storage  - if not, it should be, just for the sake of business 
continuity, but in many cases, for legal reasons as well.

>
>
> Still, what I do know? Apparently not a lot.

No offense, but I thought this was an established fact.  ;)

Don't get me wrong, you are extremely knowledgeable in many areas, but 
you seem to be unable to admit that other people may have other reasons 
to do something that you deem unnecessary because it doesn't apply to 
your situation.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message