FYI....Shark does support FLASHCOPY and PPRC to FCP attached disks.
However, these functions must be managed / initiated by the Shark copy
services web interface; not by Linux or VM.
Regards, Steve.
Steve Wilkins
IBM z/VM Development
Rich Smrcina
<[EMAIL PROTECTED]
om> To
Sent by: Linux on [email protected]
390 Port cc
<[EMAIL PROTECTED]
IST.EDU> Subject
Re: Pros and cons - emulated FBA or
FCP-attached SCSI???
03/28/2005 06:03
PM
Please respond to
Linux on 390 Port
The sky is always blue.
I'm just reminding you what your options are. That's the great thing
about advise, you can take it or leave it.
Tom Duerbusch wrote:
> Hi Rich..
>
> Just what color is the sky in your world? <G>
>
> I just don't live in a world where z/VSE comes out and all the VSE
> systems immediately convert to it without any problems.
>
> Perhaps in the next mainframe/storage subsystem replacement, FCP only
> will be an option. For now, the only mainframe shops that I would ever
> think of making FCP only, are the IFL only shops.
>
> For now, having Ficon and FCP adapters is just doubling up on hardware.
> And if they are going to the same Shark (where you have to pay for both
> sets of adapter there also), it comes down to a performance/cost issue.
> Plus, some management issues.
>
> But the management issues might break both ways. VM wouldn't manage it
> but the server people may have their own methods that they are use to.
> Whether those methods are good or not? ...
>
> Tom Duerbusch
> THD Consulting
>
> Tom Duerbusch
> THD Consulting
>
>
>>>>[EMAIL PROTECTED] 03/28/05 4:40 PM >>>
>
> If you are going to use FCP for Linux and Ficon for VM, you would have
> the extra cost anyway. z/VM, z/VSE and Linux for zSeries can ALL use
> the FCP dasd. So you wouldn't really need the Ficon at all. Except
> that at this point the SCSI part of VSE is not nearly as efficient as
> regular DASD (the overhead is pretty high).
>
> And you're right, I don't think that z/VM or z/VSE support Flashcopy
> of
> SCSI devices. That is a major drawback.
>
> Tom Duerbusch wrote:
>
>>We are in the process of specking out an z/890 with Shark and I went
>>thru the same types of questions.
>>
>>For us, it ended up mostly a cost decision as we still needed some
>
> of
>
>>the Shark to be ficon attached. So the additional cost of FCP
>
> channels
>
>>and lparing the Shark would cost us more.
>>
>>In any matter...
>>
>>z/VM 5.1 can support FCP attached dasd as FBA devices. At that
>
> point,
>
>>anything that runs on VM that supports FBA devices can use the dasd
>
> as
>
>>FBA. You can use an existing SAN for VM or any FBA application
>
> under
>
>>VM.
>>
>>z/Linux supports FCP attached storage directly. It can use SAN
>>attached storage (something about a SAN Switch enters the discussion
>>somewhere here....) With FCP attached storage, you don't have VM
>>entering the mix. No VM packs. You access the storage directly.
>
> You
>
>>can have large volumes without the need for LVM. It should be less
>>overhead as in a z/VM - FICON - Shark mix, the Shark takes 512 byte
>>sectored blocks, chains them together to emulated CKD devices, which
>
> go
>
>>thru the Ficon channels to VM, to Linux that has a device driver
>
> that
>
>>converts CKD storage back into "linux native" 512 byte blocks so
>
> Linux
>
>>sees what it is use to.
>>
>>The mainframe overhead is in the device driver in Linux that
>
> emulates
>
>>512 byte blocks on mainframe dasd. How much? 1%, 5%...I don't
>
> know.
>
>>So if you needed the Shark to be both mainframe and server attached,
>>the mainframe would need FICON and FCP adapters, and the Shark would
>>also need FICON and FCP attachments. (additional cost)
>>
>>If you use FCP attached dasd, VM doesn't see the dasd, and can't
>
> back
>
>>it up. However, Linux can see the dasd and can back it up via
>
> mainframe
>
>>tape or, if you also have FCP attached tape drives, via server type
>>tapes.
>>
>>With FCP attached Shark, you don't seem to have all the goodies that
>>are in the Shark controller. I'm not sure about how it caches the
>
> dasd
>
>>or if it can do Flash Copy or not. Also Remote Copy and such may
>
> also
>
>>not be available.
>>
>>In our case, I was looking to add FCP cards to the z/890 to attach
>
> an
>
>>existing SAN. Looking for cheap, or in the case of existing space,
>
> free
>
>>dasd. But the FCP cards seemed expensive and as it turned out,
>
> wouldn't
>
>>reduce the size of the proposed Shark. So it was just added cost.
>>
>>We may add FCP cards in the future when we run out of Shark and we
>
> are
>
>>faced with more 8-packs or buy FCP adapters and use existing SAN
>
> space.
>
>>Tom Duerbusch
>>THD Consulting
>>
>>
>>
>>>>>[EMAIL PROTECTED] 03/28/05 3:55 PM >>>
>>
>>After reading the following
>>http://www.vm.ibm.com/perf/reports/zvm/html/scsi.html I became very
>>confused (like I wasn't already)... Anyway, we're trying to move
>
> along
>
>>with a file server project and because of strict time lines, I'm
>>trying
>>to avoid reinventing the wheel. Below is a quick rundown of our
>
> system.
>
>>
>>We've got a z890 running z/VM 5.1 on one IFL. We're running several
>>instances of SLES9 in 64 bit mode. Our storage is on a shark and we
>>have
>>one SAN defined with 2 fabrics. We define our devices in 3 ways,
>
> both
>
>>in
>>an effort to have some redundancy;
>>
>> - As your traditional 3390 device (not a part of this question).
>> - As an emulated FBA minidisk (9336) with two defined paths (one
>>through each fabric).
>> - And as a FCP device, using EVMS on Linux to multipath through
>>each
>>fabric.
>>
>>My questions are about the latter two devices. The above document
>
> only
>
>>talks about single path connectivity. How would multipathing effect
>>these different devices? How does the multiple layers (e.g. EVMS,
>
> LVM,
>
>>etc...) effect these devices? In the document above it suggests a
>>substantial increase in CPU for an I/O operation to an FBA device as
>>opposed to an FCP device, how would multipathing effect this? How
>
> much
>
>>overhead is there with EVMS maintaining a multipathed FCP device?
>>Lastly, LVM1 is only available for an EVMS managed disk, is there a
>>noticeable increase in overhead between LVM1 and LVM2 (which can be
>>used
>>with a FBA device)?
>>
>>I guess I don't really need specific answers to these questions,
>
> just
>
>>an
>>idea as to what others are doing. Like I said before, I'd rather not
>>reinvent the wheel. If anyone could shed some light on which one of
>>these devices (Emulated/multipathed/LVM2/FBA or EVMS/LVM1/FCP)
>>would/should perform better, that would be GREAT!
>>
>>Mark Wiggins
>>University of Connecticut
>>Operating Systems Programmer
>>860-486-2792
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> ----------------------------------------------------------------------
>
>>For LINUX-390 subscribe / signoff / archive access instructions,
>>send email to [EMAIL PROTECTED] with the message: INFO
>
> LINUX-390
>
>>or visit
>>http://www.marist.edu/htbin/wlvindex?LINUX-390
>>
>>
>
> ----------------------------------------------------------------------
>
>>For LINUX-390 subscribe / signoff / archive access instructions,
>>send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
>
> or visit
>
>>http://www.marist.edu/htbin/wlvindex?LINUX-390
>>
>
>
> --
> Rich Smrcina
> VM Assist, Inc.
> Main: (262)392-2026
> Cell: (414)491-6001
> Ans Service: (866)569-7378
> rich.smrcina at vmassist.com
>
> Catch the WAVV! http://www.wavv.org
> WAVV 2005 - Colorado Springs - May 20-24, 2005
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
> or visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
>
--
Rich Smrcina
VM Assist, Inc.
Main: (262)392-2026
Cell: (414)491-6001
Ans Service: (866)569-7378
rich.smrcina at vmassist.com
Catch the WAVV! http://www.wavv.org
WAVV 2005 - Colorado Springs - May 20-24, 2005
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
