>>> Having a general idea of how entrerpise apps like SAP, BEA
>>> Weblogic, or Websphere work is never a bad thing
>>
>> Sure. But (for example) I gather that some people use SAN technology. I
>> cannot for the life of me begin to imagine why you would accept such a
>> massive performance hit in exchange for the mere ability to plug and
>> unplug disks virtually rather than physically. But apparently everybody
>> is doing it, for reasons unknown.
>
> The big advantage to adding disks virtually instead of physically is
> that you are not limited by the form factor of the server, the power
> output of the PSUs and most importantly, they can be done on the fly,
> without having to take an outage.

But you still need to (at a minimum) reboot the server after you change 
the SAN mapping anyway.

> In your environment, it may not be that big of an issue, but when you
> have contracted service level agreements that you will have 99.99%
> uptime, you have no other choice. Do the math, that means 1m42s of
> downtime per month... try powering off a server, taking it out of the
> rack, adding a disk and powering it back on in less than 10 times that!

Uhuh. And when one server physically dies, it's going to be down a tad 
longer than 1m42s. So if you don't have the spare capacity to handle 
that, a SAN still hasn't solved your problem.

> We've also had the performance discussion before. Yes, the theoretical
> access speed of a local SATA drive is much faster than that of a SAN
> attached logical disk, but in actual real world practice, with real
> world data, there's not much of a difference, even on SANs located
> halfway across town in another building.

This makes no sense at all. How the hell can a 6 Gbit/s SATA link 
perform the same as a 100 Mbit/sec Ethernet link? Never mind a 10 
Mbit/sec Internet link. That makes no sense at all. (Unless your actual 
disks are so feeble that all of them combined deliver less than 10 
Mbit/sec of data transfer speed...)

> Which brings us to the last big advantage of SANs. Instant disaster
> recovery! Your main office is now a pile of smoldering ruins? No biggie,
> just reassing the LUNs from that offsite SAN to another machine at the
> business continuity location and power it up, and presto! your business
> is back on its feet.
>
> sometimes, taking a small performance hit on each I/O operation is
> nothing compared to being able to get the company back up and running
> even though a hurricane decided to pay your data centre a visit.

That works if a hurricane takes out the data centre with your SAN in it. 
Not so much if it takes out the data centre with your compute devices in 
it. :-P

For that, you would need [at least] two geographically remote sites 
which duplicate everything - disk and other hardware as well. I'm 
struggling to think of a situation where the volume of data produced per 
hour is so low that you can actually keep it synchronised over the 
Internet. And if it isn't in sync, then a failover to from primary to 
secondary system entails data loss.

>> So in this instance, I know what the world is doing, but I still have
>> absolutely no insight at all. It hasn't helped.
>
> That's because you keep forgetting that other people may have other
> needs than yours.

Perhaps. But saying "we work in the financial industry" doesn't tell me 
how your needs are different than mine. Really, the only way you'd truly 
come to understand this is by actually /working/ in that industry. And 
that's just not possible.

>> I'm still failing to see why this is in any way "useful". Unless you run
>> a news website, which I don't.
>
> It is also very useful for people who READ news websites as you can
> configure an RSS reader to pick up those feeds that interest you and get
> the news you want in Thunderbird, for example, instead of having to read
> half a dozen different web sites every morning, while your coffee brews.

Right. So it's a way to track what's new on multiple sites simultaneously?

If that's all it is, why didn't somebody just *say* so?

Post a reply to this message