Dave ... Is this a product SNA or some would deliver? Or are you proposing that IBM step up to it?
-- R; On Tue, 16 May 2006, David Boyes wrote: > Several people asked off-list just what I had in mind wrt to emulated > tape and disk over SCSI/FCP. Attached below is a draft of what I've got > so far. If this is something you could support (and your company would > support), please let me know. > > > -- db > > > SCSI Support Extension Proposal > > Desired Action: > > Complete the emulated device over SCSI/FCP support introduced in z/VM > to include both ECKD disk emulation on SCSI/FCP and > emulation of channel-attached tape to generic SCSI/FCP tape > devices. If possible, the tape emulation should also support a remote tape > server option, mapping the emulated device to a user specified process > over a network connection. > > Business Justification: > > 1) In many small to medium-sized shops, the amount of money available > to invest in mainframe technology is limited compared to the > funding accessible to the open systems environment. Often, > significant disk and tape resources are duplicated or > over-provisioned in the open systems environment, but are not > accessible for reuse in the mainframe environment due to the > requirement for specialized interfaces and separate management to > support mainframe-specific environments. Enabling software > emulation of mainframe devices on top of a generic SCSI/FCP > infrastructure would allow System z infrastructure to leverage > these existing enterprise infrastructure investments directly, > improving the TCO argument for maintaining System z-based > infrastructure. > > (It is clearly acknowledged that software emulation has a > performance impact compared to native ECKD over FICON. In many > cases, this performance vs cost tradeoff is acceptable in that the > development curve for device and storage area network performance > often offsets the disadvantage within a relatively short period of > time, and the cost savings is often an acceptable tradeoff vs > execution time delays due to longer I/O delays. ) > > 2) Even given the recent price reductions for the System z BC and EC > machines, in some cases, the cost differential to implement > separate disk for a System z environment (or add specialized > interfaces to support FICON attachment of an existing disk array) > is such that disk pricing is a deciding factor to preserve a System > z environment. > > Similarly, environmental issues (floor space, power consumption, > heat dissipation) may dictate that additional disk units to support > only a single platform argue against retaining the System z > solution as a "difficult to interoperate with" solution. > > 3) Additional disk volume formats and attachment methods complicate > storage management discipline, adding additional training costs > for storage administrators and possibly additional costs for > software implementation to manage the FICON-attached arrays (not > all vendors support FICON-attached volumes in their basic > management software, but market that support as a enhanced > feature). This increase in complexity further impacts the ROI and > TCO of the System z solution. > > 4) Currently, only VSE, Linux and VM fully support FBA DASD. We are > aware of work being done to z/OS to tolerate FBA disk, but until > this work is completed, ECKD disk is required. If IBM is to open > up additional market opportunity for z/OS or other ECKD-only > systems in the short term, ECKD emulation is necessary to open > those opportunities. > > It is important to note that ECKD emulation on SCSI disk has been > done in the past for the P/390, R/390, and Multiprise systems, and > it is clear from a cursory examination of the z/VM EDEV SCSI stack > that these previous attempts could be used as a starting point to > provide this type of emulated function. > > 5) With regard to tape, currently the largest supported FICON-attached > tape unit supports a 40G uncompressed volume. Open systems tape > units regularly support 200G or greater volume sizes. With the > dramatic increase in data volumes, the inability of System z to > access these commonplace devices argues significanly against > adoption of a System z based solution in place of a Intel or other > platform solution. > > 6) Similar to the ECKD disk emulation code mentioned above, tape > emulation code for 3420 and 3480/90 tape over SCSI also exists, and > offers direct support for all System z operating systems currently > supporting tape without additional development. Emulated tape > devices could easily be mapped to higher-capacity SCSI devices, > providing direct benefit for backup/DR and data exchange purposes. > > 7) Adding ECKD and tape emulation would allow dramatic simplification > of software distribution for System z operating systems, allowing > applications to be directly supplied as disk images on inexpensive > media (CDROM vs tape cartridges). This simplification would allow > inexpensive distribution methods to be used in the future, as well > as sophisticated verification tools that are not possible with > tape-based installation today. > > 8) VSE users have had the option of supporting a remote tape server > for some time now. This option has proven to be very flexible and > helpful to control the costs of a System z solution, and allow > considerable customer control of their data processing > solution. Extending this support to all System z operating systems > via a emulated tape device would be very desirable. > > > Suggested implementation: > > 1) Provide a 3390 ECKD EDEV device type for z/VM Guests > > Similar to the 9336 FBA EDEV, providing a 3390 ECKD EDEV would permit > defining SCSI targets to map to a ECKD emulation layer provided in > CP. Large device support is already present in CP and in most guest > systems, allowing the guest OS to sense the appropriate model of > 3390 and build a real device support block as appropriate. > > 2) Provide a emulated 3422, 3490 or 3590 to SCSI tape device type for > z/VM Guests > > The access model and tape handling model used by the typical SCSI > tape drive are most similar to the 3420 and 3422 devices in that > the 342x media have no defined cartridge size, and rely on the > device to notify the OS of the end of media and other important > details. Defining a emulated 3422 tape device would allow guests > and CMS users to directly manipulate SCSI tape using all the > existing tools without modification. The 3490 and 3590 emulation > would allow 3490 and 3590 drives in libraries shared with > non-System z systems to be defined physically as all-SCSI > devices, allowing workload to be dynamically shifted between > operating environments w/o partitioning libraries or separate > device management. > > 3) Provide a emulated tape to remote tape server option over TCP > > Providing a standardized ability to intercept I/O to a emulated tape and > redirect it to a remote tape server would be very helpful for Linux > and other guests to interact with tape managed by a host VM system > (both SCSI and channel-attached). Mapping the emulated device to a > IUCV service and having a CMS or Linux virtual machine multiplex > the tape I/O to a remote system would be very desirable. >
