|
Interesting situation. Let's discuss the options. The Shark uses clustered RS6000s inside the frame to provide great reliability. Cache is mirrored using an internal path for redundancy. Performance on mainframes can be optimized greatly by using PAV (parallel access volumes) internally in the array. The Shark is a great performer on mainframe and OK on open systems.
The Compaq solution uses a dual controller with mirrored cache also. Performance is very fast on open systems due to the internal architecture of using six seperate I/O paths to the drives, thereby giving you 240MB per second access per RAID group. The Compaq box also uses a cache algorithm that is dynamic in nature, by "learning" about the type of I/O to each RAID set and tuning cache "on the fly" for that type of access. In other words, an application doing high sequential throughput (video server) will be treated differently in cache than an application doing high random I/O (database).
OK, so now we know the architecture, lets look at the feasibility of one solution over the other.
First of all, the StorageWorks arrays do not support mainframe ESCON connections, nor does it support FICON for mainframe. The Shark does. The Shark array uses technology (PAV) that is not available in StorageWorks. The reason the two companies came together to resell each others solutions in the first place is that IBM did not have an open systems storage solution that was viable and StorageWorks did not have mainframe connectivity. Together they have a compelling story.
In my travels, I too have seen the Shark used mostly for mainframe access. Using open systems and Mainframe in the same array without a switched "point to point" architecture internally could increase contention for cache and bus bandwidth.
Compaq developed the StorageWorks arrays from the ground up for high performance in an open systems or clustered environment(the initial versions were used for VAX VMS clusters). I find it to be a better performer in those environments. IBM can sell the Shark at a very competitive price, but I think the StorageWorks solution would be better suited in the NT environment.
The good news is that your doing the right thing. Don't share Mainframe DASD with NT and Unix unless that solution provides point to point non-blocking connectivity to both platforms. I would keep using StorageWorks on NT, and Shark on Mainframe. In a SAN, you can connect and manage both platforms from a single console with open management platforms like TSM or Veritas and drill down into the arrays themselves with command console from StorageWorks.
You may want to try out Compaq's Virtual Replicator (VR) software for the file and print severs. A VR server could provide Block based I/O over Ethernet (Storage over IP) for file/print, thus decreasing your per port costs for those servers or clients where performance is not crucial. (No switch ports or HBAs needed!) VR also provides pooling and snapshots in software to make backup easier and not impact production. The VR drives look like a physically attached drive to the clients and can provide access speeds close to direct connect disks if your Ethernet environment is robust enough.
Chris
|
