Fred, The AMS2500 is like a 2nd level cache behind the USP-VM. Any read hits in the USP-VM will perform the same as if they were on internal disk. The FICON IO simply reads it directly from the USP-VM cache without ever referencing the AMS2500. The cache in the AMS2500 may also get some read hits, but it is unlikely because the larger cache on the USP will tend to soak up the cache hits, leaving the very random stuff for the external disks. All device characteristics are provided by the USP-VM (like logical paths, PAV, etc). The AMS2500 is completely masked from the host, just like internal FCAL disks.
Write performance will depend on how the external disks are configured to manage cache. There are several options that can change this, so you need to talk to your HDS team. The AMS2500 is a pretty robust box. HDS moved from FCAL to SAS on midrange storage because it has some speed and path advantages over FCAL. In the HDS USP architecture everything is actually SCSI once you get past the HTP in the Front End Director cards. All of the CKD IO has been encapsulated into FBA before the first track record hits a major microprocessor. Even so, cache hints like Sequential pre-fetch, CFW, etc are still honored as part of the emulation. Remember that the USP-VM is still handling all the FICON IO and CKD emulation, and staging/destaging to the AMS2500 as required. The AMS2500 will see this as server IO and use the required cache strategies (like sequential detection). Any IO on any storage controller can impact other IO in the same controller. If you saturate a component and cause queuing or sibling pend then there will be contention. Tuning the AMS2500 is no different to tuning the USP-VM. There are performance statistics from both controllers that can help you monitor and tune them. The AMS2500 also supports cache partitioning, so you can design the whole thing to give Mainframe volumes dedicated ports, cache and disk drives if you wish. Remote Copy and FlashCopy are all handled by the USP-VM so you do not lose any MF functionality. If you want to use HUR from Darwin to London, then no problem. You want to FlashCopy a dataset from an external disk volume to an internal disk volume, then no problem. Copy products continue to be managed by BCM. The AMS2500 LUNs are recognized by the USP-VM as soon as both controllers and equipment linking them are powered up. I don't have values for power up cycle time and AMS battery backup, but these are questions you HDS account team or CE can get the answer to pretty quickly. Net-net, most of your questions and concerns are not related to SAS disk. Your concerns seem to have more to do with the AMS2500, which is masked by the USP-VM in most cases. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > Fred Schmidt > Sent: Sunday, July 04, 2010 10:38 PM > To: [email protected] > Subject: Re: [IBM-MAIN] Serial Attached SCSI (SAS) disk compared to Fibre > Channel > > Issued: Error! Unknown document property name. iii > > Ron Hawkins wrote: > > Seeing as the USP-VM does not support SAS drives, it is more likely that > they are considering SAS drives that are installed in a HDS or other > vendor's Storage Controller. In that case the performance of IO that goes > past USP-VM cache to the external storage will largely depend on the design > and architecture of that controller, and not just whether it is SAS, FCAL or > SATA. > > > You are right, Ron. Turns out it would be a HDS AMS2500 with Ultrastar 15K600 > disk that would be virtualised SAS disk storage under the USP-VM. > > The specs certainly read well in comparison to our current IBM DS6800. Call me > a nervous Nellie or what have you, but seeing how nobody else here in > Australia is supposedly using SAS disk for the mainframe, I still have the > following concerns... > > - will it support the required number of logical paths for 20 odd > LPAR's? > - could mainframe performance be degraded significantly by load on the > open systems disk, that would make up the majority of data stored on the > AMS2500? > - Can the mainframe DASD part of the storage be isolated from those > "whoops, I formatted the wrong disk" type actions against open systems disk? > - Can it do custom volume sizes for DASD? > - Will it work to mirror to a second DR site? Any distance limitations? > - How long does the battery backup for the cache hold the data not yet > destaged to disk for? > - After total power failure, how long does it take for the AMS2500 and > USP-VM to become operational again? > > Thanks in advance for your help. Sorry for all the questions! > > Regards, > Fred Schmidt > NT Government, Australia > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
