Hi All

I am new to ESS, can I have a difference between the SSA and ESS
storage.

Thanks in advance

Agas

SSA disk subsystem is directly attached storage, you're connecting it
using SSA HBAs and SSA cables to host system(s), the ESS is the
enterprise class monolitic storate, hosts have access to that storage
either via SAN or Differential SCSI connection (open systems, pSeries
include ) or FICON/ESCON -- zOS... There are more much differences
between two, the only common -- they both uses SSA architecture...

vlad.zam@gmail.com wrote:
> SSA disk subsystem is directly attached storage, you're connecting it
> using SSA HBAs and SSA cables to host system(s), the ESS is the
> enterprise class monolitic storate, hosts have access to that storage
> either via SAN or Differential SCSI connection (open systems, pSeries
> include ) or FICON/ESCON -- zOS... There are more much differences
> between two, the only common -- they both uses SSA architecture...
>

Well...yes but as a point of clarification...that (the above) is
internal to the ESS frame; the controllers (in side the frame) are
essentially RS6Ks running "customized AIX" with their own SSA adapters
controlling the SSA disks/drawers via "redundant"/multiple loops.

Hosts/clients that connect to the ESS, assuming they're connecting via
fiber channel (aka, "FC" HBA/cable), typically connect via fiber - the
config essentially looks like this:

"client" host/HBA --(FIBER CABLE)--> switch---->ESS FA/port (which in
turn, internal to the ESS "talks" to the SSA "DA", aks, disk adapters,
which control the SSA disk/drawers)

I believe that is correct - I just worked w/the IBM CE to update the
firmware/LIC on our ESS model 800 so it's fairly "fresh" :-P

P

From an end user perspective, the ESS is faster (Fiber speeds around
100MB versus 20/40MB for SSA). As long as you use dual fibre paths and
your ESS has dual HBA's you get the same redundancy in connections as
with native SSA. The ESS has its own benefits too - (Flash copy, PPRC, ect).

On Fri, 12 Aug 2005 11:47:29 -0500, Nathan <nathan@nospam.org> wrote:

> From an end user perspective, the ESS is faster (Fiber speeds around
>100MB versus 20/40MB for SSA). As long as you use dual fibre paths and
>your ESS has dual HBA's you get the same redundancy in connections as
>with native SSA. The ESS has its own benefits too - (Flash copy, PPRC, ect).
>
Not to mention battery-backed nvram write cache designed to write the data
before shutting down on power failure.

And two in-loop spare drives in the raid array (floating -- once they
become a 'data' drive, they STAY a 'data' drive, and the replaced bad
drive becomes the new spare) -- you need a small anti-tank missle to loose
data in an ESS failure. It calls home on drive failure and you tend to
find out about it next day (these always come at night for us) when IBM
comes in to install the replacement.

TomK wrote:
> On Fri, 12 Aug 2005 11:47:29 -0500, Nathan <nathan@nospam.org> wrote:
>
>
>>From an end user perspective, the ESS is faster (Fiber speeds around
>>100MB versus 20/40MB for SSA). As long as you use dual fibre paths and
>>your ESS has dual HBA's you get the same redundancy in connections as
>>with native SSA. The ESS has its own benefits too - (Flash copy, PPRC, ect).
>>
>
> Not to mention battery-backed nvram write cache designed to write the data
> before shutting down on power failure.
>
> And two in-loop spare drives in the raid array (floating -- once they
> become a 'data' drive, they STAY a 'data' drive, and the replaced bad
> drive becomes the new spare) -- you need a small anti-tank missle to loose
> data in an ESS failure. It calls home on drive failure and you tend to
> find out about it next day (these always come at night for us) when IBM
> comes in to install the replacement.

Well, with ESS the nvram battery is mandatory, on plain old SSA it's an
option.

And yes, drives seem to always fail in the middle of the night and get
replaced before you get to work in the morning. I think it's a
conspiracy to make CE's look better .

On Mon, 15 Aug 2005 09:09:10 -0500, Nathan <nathan@nospam.org> wrote:

>TomK wrote:
>> On Fri, 12 Aug 2005 11:47:29 -0500, Nathan <nathan@nospam.org> wrote:
>>
>>
>>>From an end user perspective, the ESS is faster (Fiber speeds around
>>>100MB versus 20/40MB for SSA). As long as you use dual fibre paths and
>>>your ESS has dual HBA's you get the same redundancy in connections as
>>>with native SSA. The ESS has its own benefits too - (Flash copy, PPRC, ect).
>>>
>>
>> Not to mention battery-backed nvram write cache designed to write the data
>> before shutting down on power failure.
>>
>> And two in-loop spare drives in the raid array (floating -- once they
>> become a 'data' drive, they STAY a 'data' drive, and the replaced bad
>> drive becomes the new spare) -- you need a small anti-tank missle to loose
>> data in an ESS failure. It calls home on drive failure and you tend to
>> find out about it next day (these always come at night for us) when IBM
>> comes in to install the replacement.
>
>Well, with ESS the nvram battery is mandatory, on plain old SSA it's an
>option.

Yeah -- but on the ESS, it's a complete UPS, so the data is read from the
nvram and written to disk before the ESS shuts down (supposed to be three
to five minutes available power after line power failure on a full-blown
ESS).

>
>And yes, drives seem to always fail in the middle of the night and get
>replaced before you get to work in the morning. I think it's a
>conspiracy to make CE's look better .

Actually, I've only lost one on the current box in three years; the F20
lost 6 or 7 in the same time period.

we can go on and on about good things in ESS (2105) but the cost was a
killer compared to SSA subsystem ( 7311 )... Let's better talk about
all that s/w IBM wrote for MPIO support in AIX... Men, could they just
make RDAC to work with all those creatures ( ESS, DS, f$^^%g EMC and so
on ?). Over years I found it's the most easiest to support/upgrade/deal
with MPIO s/w out there...