2003-03-26 22:54:16

by Lincoln Dale

[permalink] [raw]
Subject: Re: [PATCH] ENBD for 2.5.64

Andre,

At 02:32 PM 26/03/2003 -0800, Andre Hedrick wrote:
> > in reality, if you had multiple TCP streams, its more likely you're doing
> > it for high-availability reasons (i.e. multipathing).
> > if you're multipathing, the chances are you want to multipath down two
> > separate paths to two different iSCSI gateways. (assuming you're talking
> > to traditional SAN storage and you're gatewaying into Fibre Channel).
>
>Why a SAN gateway switch, they are all LAN limited.

?
hmm, where to start:

why a SAN gateway?
because (a) that's what is out there right now, (b) iSCSI is really the
enabler for people to connect to consolodated storage (that they already
have) at a cheaper price-point than FC.

LAN limited?
10GE is reality. so is etherchannel where you have 8xGE trunked
together. "LAN is limited" is a rather bold statement that doesn't support
the facts.

in reality, most applications do NOT want to push 100mbyte/sec of i/o -- or
even 20mbyte/sec.
sure -- benchmarking programs do -- and i could show you a single host
pushing 425mbyte/sec using 2 x 2gbit/s FC HBAs -- but in reality, thats way
overkill for most people.

i know that your company is working on native iSCSI storage arrays;
obviously its in your interests to talk about native iSCSI access to disks,
but right now, i'll talk about how people deploy TB of storage today. this
is most likely a different market segment to what you're working on (at
least i hope you think it is) - but a discussion on those merits are not
something that is useful in l-k.

> > handling multipathing in that manner is well beyond the scope of what an
> > iSCSI driver in the kernel should be doing.
> > determining the policy (read-preferred / write-preferred / round-robin /
> > ratio-of-i/o / sync-preferred+async-fallback / ...) on how those paths are
> > used is most definitely something that should NEVER be in the kernel.
>
>Only "NEVER" if you are depending on classic bloated SAN
>hardware/gateways. The very operations you are calling never, is done in
>the gateways which is nothing more or less than an embedded system on
>crack. So if this is an initiator which can manage sequencing streams, it
>is far superior than dealing with the SAN traps of today.

err, either you don't understand multipathing or i don't.

"multipathing" is end-to-end between an initiator and a target.
typically that initiator is a host and multipathing software is installed
on that host.
the target is typically a disk or disk-array. the disk array may have
multiple controllers and those show up as multiple targets.

the thing about multipathing is that it doesn't depend on any magic in "SAN
hardware/gateways" (sic) -- its simply a case of the host seeing the same
disk via two interfaces and choosing to use one/both of those interfaces to
talk to that disk.

[..]
>What do you have for real iSCSI and no FC junk not supporting
>interoperability?

?
no idea what you're talking about here.

>FC is dying and nobody who has wasted money on FC junk will be interested
>in iSCSI. They wasted piles of money and have to justify it.

lets just agree to disagree. i don't hold that view.

> > not bad for a single TCP stream and a software iSCSI stack. :-)
> > (kernel is 2.4.20)
>
>Nice numbers, now do it over WAN.

sustaining the throughput is simply a matter of:
- having a large enough TCP window
- ensuring all the TCP go-fast options are enabled
- ensuring you can have a sufficient number of IO operations outstanding
to allow SCSI to actually be able to fill the TCP window.

realistically, yes, this can sustain high throughput across a WAN. but
that WAN has to be built right in the first place.
i.e. if its moving other traffic, provide QoS to allow storage traffic to
have preference.

>Sweet kicker here, if you only allow the current rules of SAN to apply.
>This is what the big dogs want, and no new ideas allowed.

i definitely don't subscribe to your conspiracy theories here. sorry.

>PS poking back at you for fun and serious points.

yes - i figured. i'm happy to have a meaningful technical discussion, but
don't have the cycles to discuss the universe.


cheers,

lincoln.


2003-03-26 23:31:50

by Andre Hedrick

[permalink] [raw]
Subject: Re: [PATCH] ENBD for 2.5.64

On Thu, 27 Mar 2003, Lincoln Dale wrote:

> > > to traditional SAN storage and you're gatewaying into Fibre Channel).
> >
> >Why a SAN gateway switch, they are all LAN limited.
>
> ?
> hmm, where to start:
>
> why a SAN gateway?
> because (a) that's what is out there right now, (b) iSCSI is really the
> enabler for people to connect to consolodated storage (that they already
> have) at a cheaper price-point than FC.
>
> LAN limited?
> 10GE is reality. so is etherchannel where you have 8xGE trunked
> together. "LAN is limited" is a rather bold statement that doesn't support
> the facts.
>
> in reality, most applications do NOT want to push 100mbyte/sec of i/o -- or
> even 20mbyte/sec.
> sure -- benchmarking programs do -- and i could show you a single host
> pushing 425mbyte/sec using 2 x 2gbit/s FC HBAs -- but in reality, thats way
> overkill for most people.

We agree this is even overkill for people like Pixar and the movie people.

> i know that your company is working on native iSCSI storage arrays;
> obviously its in your interests to talk about native iSCSI access to disks,
> but right now, i'll talk about how people deploy TB of storage today. this
> is most likely a different market segment to what you're working on (at
> least i hope you think it is) - but a discussion on those merits are not
> something that is useful in l-k.

Well we deploy ERL=1 or ERL=2(%80) today on 6TB platforms now.
So the democratization of SAN is now and today.

> > > handling multipathing in that manner is well beyond the scope of what an
> > > iSCSI driver in the kernel should be doing.
> > > determining the policy (read-preferred / write-preferred / round-robin /
> > > ratio-of-i/o / sync-preferred+async-fallback / ...) on how those paths are
> > > used is most definitely something that should NEVER be in the kernel.
> >
> >Only "NEVER" if you are depending on classic bloated SAN
> >hardware/gateways. The very operations you are calling never, is done in
> >the gateways which is nothing more or less than an embedded system on
> >crack. So if this is an initiator which can manage sequencing streams, it
> >is far superior than dealing with the SAN traps of today.
>
> err, either you don't understand multipathing or i don't.
>
> "multipathing" is end-to-end between an initiator and a target.
> typically that initiator is a host and multipathing software is installed
> on that host.
> the target is typically a disk or disk-array. the disk array may have
> multiple controllers and those show up as multiple targets.

Agreed, and apply as series of head-to-toe target-initiator pairs and you
get multipathing support native from the super target. This is all a SAN
gateway/switch does. Not much more than LVM on crack and a six-pack.

> the thing about multipathing is that it doesn't depend on any magic in "SAN
> hardware/gateways" (sic) -- its simply a case of the host seeing the same
> disk via two interfaces and choosing to use one/both of those interfaces to
> talk to that disk.

Well Storage is nothing by a LIE and regardless if one spoofs and ident
mode pages or not, they must track and manage the resource reporting
properly.

> [..]
> >What do you have for real iSCSI and no FC junk not supporting
> >interoperability?
>
> ?
> no idea what you're talking about here.

Erm, shove a MacData and Brocade switch on the same FC network and watch
it turn into a degraded dog.

> >FC is dying and nobody who has wasted money on FC junk will be interested
> >in iSCSI. They wasted piles of money and have to justify it.
>
> lets just agree to disagree. i don't hold that view.

Guess that is why NetAPP snaked a big share of EMC's marketspace with a
cheaper mousetrap. Agreed to "agree to disagree" erm whatever I just
typed.

> > > not bad for a single TCP stream and a software iSCSI stack. :-)
> > > (kernel is 2.4.20)
> >
> >Nice numbers, now do it over WAN.
>
> sustaining the throughput is simply a matter of:
> - having a large enough TCP window
> - ensuring all the TCP go-fast options are enabled
> - ensuring you can have a sufficient number of IO operations outstanding
> to allow SCSI to actually be able to fill the TCP window.
>
> realistically, yes, this can sustain high throughput across a WAN. but
> that WAN has to be built right in the first place.

Well sell more of those high bandwidth switches to the world of
internet-ether to make it faster, I would be happier.

> i.e. if its moving other traffic, provide QoS to allow storage traffic to
> have preference.
>
> >Sweet kicker here, if you only allow the current rules of SAN to apply.
> >This is what the big dogs want, and no new ideas allowed.
>
> i definitely don't subscribe to your conspiracy theories here. sorry.

You should listen to more Art Bell at night, well morning for you.

> >PS poking back at you for fun and serious points.
>
> yes - i figured. i'm happy to have a meaningful technical discussion, but
> don't have the cycles to discuss the universe.

I did the universe once as an academic, it was fun.

http://schwab.tsuniv.edu/t13.html

This was my last time of stargazing and I miss it too!

Cheers,

Andre Hedrick
LAD Storage Consulting Group