SAN Solution for AS400 (I-Series)?

[Guest.Visitor]

Well by using a SAN you ARE going to get slower performace, that is the biggest thing that made the decision to NOT use it in our shop. I guess it would be better to know what you are trying to accomplish, I mean is it to share disk with NT or other Platforms? Is it to beable to do some sort of flashcopy and then backup from there? AS/400 Guy

[dnmcin@yahoo.com]

The basic idea to want a SAN, is to allow easy addition of less expensive DASD in the future. We have several non-AS400 people here that believe someday we may get rid of our AS400 (you know how that story goes), then we would be stuck with lots of un-usable DASD. As far as speed, I have been told that we can connect the SAN to the AS400 via SCSI and not Fiber Channel which would give us good I/O speed (as good as internal!, they've been told!) The Flashcopy sounds like a nice feature also, allowing backups without down time. Do you know if IBM's Shark has this same capability/feature? I personally would prefer and will probably recommend internal DASD for speed and the initial expense, but I can see their point in that you could use and re-use DASD for different/new platforms for the long term. Even upgrading to newer AS400's could be easier without needing to back-up and restore data onto a new box. Anyway, I'm open to opinions, expertise, and advice on which way to go on this. I will use these responses in our decision process. Also if you or anyone has SAN expertise, what do you think of the EMC(Symmetrix) line verses IBM (Shark) Thanks

[dnmcin@yahoo.com]

Hello All, We are looking into purchasing our own I-series box (we have been leasing space). Can anyone give me feedback on actual experience in using a SAN (Storage Area Network) connected to a AS400? IBM & Non-IBM SAN's? (EMC, Symmetrix, etc?) Any performance impairment, support problems (non-IBM), connectivity problems, response time, backup, COST, etc. All the info prior to making the decision to go SAN or native will be greatly appreciated. Thanks, Don

[magtech@optonline.net]

I can't comment on the Shark arrays since I've not used them. At a recent client, we implemented EMC Symmetrix boxes as an external stroage solution for AS/400 and all other host machines. This was part of an overall Enterprise Systems Management effort. The Symmetrix solution is nice, very manageable but very pricey. You pay a high price for all the cache memory that they put in there to get high performance. (though I suppose that will change inlight of recent earnings reports) In I/O benchmarks that I created to do an analysis of the AS/400's performance with those arrays, the performance compared favorably with and even surpassed the internal drives. I don't know if they've changed the emulation scenario, but when I did this a couple of years ago, the EMC devices and software presented themselves as 9337 drives to OS/400. I wouldn't really classify this as a SAN. These devices were direct SCSI connected to the AS/400 via a 6501 (or 6502) adapter, which as you said probably accounts for the good performance. The things that we always have to remember is that a SAN in general is a shared resource and the ISeries, specifically, performs best with sufficient disk arms for the Single Level Storage to spread out data and limit contention. Forgetting about the DASD re-use issue for a moment, consider Disaster Recovery: EMC provides utilities specific to their boxes (SRDF and Timefinder) which allow high speed local or remote replication of the DASD without effect on the hosts connected. Specific to the AS/400, they also provide library replication/backup facilities (I think it was called CopyPoint) that allows creation of "business continuation volumes" with very short down times. On the other hand, a simpler and cheaper solution that we are currently using is to just go with internal drives and run ISeries specific replication software. In either case, you need two or more ISeries boxes, but the software solution is potentially a lot cheaper than external DASD arrays. HTH, Marc Ornstein