>>>
>>> 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.
>
> That's /not/ how a local backup agent works. Indeed, the entire
> /purpose/ of a local backup agent is to construct a consistent image (by
> whatever means that requires) to write to tape.

No. the purpose of a local backup agent is:
1) to have the means to back the files up at shceduled intervals, and
2) talk to the backup unit (be it another locally-mounted file system, 
removable storage media, or file transfer over a network).

Both of these functions are nowadays available directly from the OS, but 
most entreprises will have a separate tool to do this as there are other 
advantages when it comes to centralized management, or the ability to 
lock access to certain files or directories, or able to speak in a 
dialect understood by the application (e.g. Oracle "live backup" agent), 
but in many cases, it is not necessary and the backup job can run while 
the users access their files.  At that point, it becomes a management 
decision based on the relative costs penalty of scheduling down time vs. 
losing absolute file consistency.

>
>> 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.
>
> Nonsense. If you're doing something like that, you're probably using a
> relational database. And any half-decent product of that type provides a
> way to construct a consistent image without ever stopping the database.
> (You do, however, need the cooperation of the server that's running the
> thing. You can't just take a block-level image of the filesystem and
> expect to get anything sensible out of it.)
>

Agreed for databases, but even just a source tree could become 
inconsistent if a programmer is making changes at the same time as the 
backup job is running.  As I said, if it absolutely, positiviely, 
legally requires a consistent copy, means will be taken to achieve that. 
  But if it's just a minor inconvenience for a few persons to have an 
older draft version of their weekly powerpoint presentation to upper 
management having been saved prior to the server failure, then so be it.

>>> 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.
>
> So what you're saying is that you wire up two independent networks, and
> connect every device to both of them, so that if the switch running
> network A fails, you can use network B instead?

The storage network hardware is all interconnected, but the storage 
network is independant from the user-traffic network.

        ----------
      /            \
     |  IP Network  |
      \            /
       -----------
      / /        \ \
  --------     --------
| server |   | server |
|    1   |   |    2   |    Server N, etc...
  --------     --------
    |      \ /      |     /
    |       x       |    /
    |      / \      |   /
  --------     --------
| SAN sw |---| SAN sw |--- Switch N, etc...
|    1   |---|    2   |---
  --------     --------
    |      \ /      |
    |       x       |
    |      / \      |
  --------     --------
| Drive  |   | Drive  |  --> Repeat if uptime service
|  bay   |   |  bay   |      level agreements require
|        |   |        |      site-level diversity, or if
|    1   |   |    2   |      required by capacity.
  --------     --------
           \ /
       ---------
      |  Tape   |
      |  Robot  |
       ---------

Typicially, the SAN switches will have up to 16 or so "front end" ports 
and 2 or more higher-speed "Back-end" ports to the drive bays.  Some 
high-load servers might have direct connections to the drive bays.


>
>>> Unless every single server and every 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.
>
> Damn. This stuff is more expensive than I thought... Still, great way to
> make your department look important, I guess.
>

It's the only way to achieve "five 9s" uptime (i.e. 99.999%), which is 
what most banks and multinationals require.  Again, for a small to 
medium shop, with a dozen to 50 servers or so servers, or no 
requirements for such high SLAs, then it's overkill.

It's worthwhile to note that five-9s uptime also require considerable 
thoughts to the choice of applications, hardware, network design, 
climate control, power management, staffing arrangements, telco 
diversity, disaster prevention and business continuity, in the event 
that a disaster can not be avoided.  This can add one or two orders of 
magnitude to a company's IT budget, so it's not just to make your dept. 
look important.  There has to be a sufficient increase in revenues (or 
decrease in losses!) to justify it.

-- 
/*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