|
 |
>>> I fail to see why RAID is no longer an issue. (Unless you mean that it's
>>> now acceptable to lose data in the event of a hardware fault.)
>>
>> RAID is an issue for the SAN administrator, not the server
>> administrator.
>
> Oh, I see.
>
> This applies only if the SAN administrator and the server administrator
> aren't the same person. In our setup, with a grand total of 4 IT staff,
> I doubt this is relevant.
This is why I said it would be silly to have a SAN for only a handful of
devices. In a data center with 200+ servers, you'll usually end up with
entirely different support teams for Mainframe, mid-range (AS/400,
Tandem, etc...), Unix (sometimes different groups for different flavours
of), Windows, and Netware (if there are still some of it), having a
group of 4 or 5 people dedicated to the SAN administration allows them
to specialize in their field, and hopefully become more competent at it,
and leaving the OS folks deal with patching, tuning processes, etc...
>>> I've also never seen a sever with more than one disk controller, come to
>>> mention it...
>>
>> Then your servers are far from optimal.
>
> Well, I guess you can /always/ have more fault tolerance. But in 10
> years of working here, I've only seen one controller fail. Come to think
> of it, I've only seen about 6 drives fail (including desktop PCs and
> laptops).
Not fault tolerance. PERFORMANCE. You know, that thing you were saying
would degrade with a SAN.
>> With the exception of the OS drive (You don't want to boot off the SAN),
>
>> *Don't run your domain controllers or DNSes from a SAN either.
>
> Any specific reason?
>
Because in the event that the SAN went away, you may end up in a
situation where the DNS or AD is actually required to allow support
personnel to work on the issue (think VPN access for remote support
personnel). As much as you want to, in an environment with hundreds of
servers, you're bound to end up with either having to rely on DNS
services or deal with updating hundreds of local HOSTS files, etc.
>>> I don't see how that works.
>>
>> The DVD or tape drives have direct backplane connections to the disk
>> arrays so they can read the disks without impacting the network or
>> competing with the server's own IO requests.
>
> So how does it obtain a consistent image of the filesystem?
>
The same way you do with a local backup agent. The SAN is not a magical
invention that removes all worldly constraints. In other words, you
schedule the backup at the time where its least likely there will be
changes to the file system, and pray to the deity of your choice.
In other words, in a data center for a multinational corporation where
planes are up in the air, or trading is going on in a stock exchange
somewhere 24 hrs a day, 7 days a week, you NEVER have a consistent copy.
You simply hope to have a GOOD ENOUGH copy.
For systems that require a "snapshot" of the state at specific times,
you schedule downtime at the application level and take the backup
during that time, for that application. For example, at one of my
former customers, the HR/Finance ERP system would switch to read-only
mode from 0h00 to 06h00, every day to allow consistent backups to be
taken. This allowed an accountant burning the midnight oil to be able
to still read the general ledger, while allowing for a clean backup to
be taken.
>>>
>>> If you have a SAN, you have /one/ access channel, which all the servers
>>> have to share between them. If one server decides to hit it really hard
>>> (or just crashes and starts sending gibberish), all the others get
>>> clobbered.
>>
>> Again, wrong. Each server has dedicated access to the SAN fabric and the
>> SAN switches will dispatch I/O requests to the proper drive(s) without
>> impacting other servers' I/O requests.
>
> There is one network switch. All data must pass through this single
> device. If it only processes X bytes per second, than all the servers
> between them cannot access more than X bytes per second. The end.
There are multiple SAN switches (you definitely DON'T want a single
point of failure). Each with enough backplane bandwidth, processor
power and ports to handle I/O requests at wire speed.
A typical set-up would have each server connected to two different SAN
switches (sometimes refered to as "front-end" switches), and these would
in turn be connected to each of the disk bays, on top of having
interconnections between the switches, to prevent a fibre cut from
shutting a part of the storage network down. Said typical set-up would
also probably have performance monitoring software available allowing
the SAN administrators to see where potential bottelnecks will be and
take approriate measure during a scheduled maintenance window.
>
> Unless every single server and several single disk has its own dedicated
> channel to the switch (which is presumably infeasible), there will be
> additional bottlenecks for components sharing channels too.
>
You have presumed wrong. This is exactly what happens.
>>>> Have they actually stated that they would not be taking tape (or more
>>>> than likely DVD) backups of that data for archival?
>>>
>>> Bizarro. Why would you back up to a DVD that holds a piffling 4.2 GB of
>>> data when a single tape holds 400 GB? That makes no sense at all.
>>
>> Tapes degrade over time faster than DVDs do.
>
> In which universe? I would have said the exact opposite was true. I've
> seen CDs and DVDs burned 6 months ago where the ink has faded to the
> point where the disk is utterly unusable. I've yet to see a tape fail to
> read.
Stop buying cheap DVDs then ;). I've seen tapes fail in drives.
<strike>I've seen attack ships fire off the shoulder of Orion</strike>,
I've seen tapes where someone had to actually change the plastic
leader thingie because it had become so mangled from repeated use that
it wouldn't engage in the drive any more. Etc...
>
>> I/O is sequential on a tape. If you need a specific file, you need to
>> read through the whole tape from the beginning.
>
> That's true though. Fortunately, file restoration is a rare event, so it
> doesn't matter too much.
Again that depends on the application. Most large corporations will
have data exchange that still takes place over physical media being
FEDEXed (interbank transfers, payroll data for the bank that issues the
cheques, airline schedule exchanges, government regulatory filings,
etc.) as in some cases, it is still cheaper than setting up dedicated
inter-entreprise connections. Some backups are only for business
recovery, but others are intended for use in the very near future.
>
>> If you only have a 10GB incremental per day, and need to sent it to
>> offsite storage every day (sometimes required by law), using 400GB tape
>> is a serious waste of money.
>
> The way we do it is to store all the tapes off-site, except today's
> tape. Rotate the tapes until they become full, then add in a new tape.
> All 400GB of capacity gets used, and yet at any time the majority of
> tapes are off-site.
>
See above. You can't always reuse the same tape. There may ver Very
Good(tm) reasons for that.
Also, I know that multiple backups can be combined on a tape. This is
exactly what we used to do for the file servers, when I did server
support 15 years ago. All incrementals go on rotating tapes, and the
weekly full backup is done on a different tape, which was then
duplicated and one copy was sent to the offsite vault. However, even in
this scenario, if one of the rotating tapes got damaged or lost, the
missing incrementals could still cause major legal woes for the company.
I've since moved away from server support, so I can't comment on what
the storage admins do nowadays. All I know if they have a really cool
robot that fetches tapes and DVDs from the racks instead of relying on
"tape monkeys" as we used to call them.
--
/*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
|
|
