Great question, Lionel. pro: SAN looks the same to all platforms which use it SAN connects to mainframe Linux as easily as to other Unix and Linux SAN eliminates unused emulation SAN is cheaper
"SAN looks the same" -- If you DDR a 3390 from one system to another, you get a perfect copy. Nice! In Unix Land, you get almost the same effect from 'dd', except that for CKD volumes there is low-level formatting to do. SAN does not require the low-level formatting. (Neither do SCSI disks. Neither do IDE disks.) This is huge! People just don't get it. You can literally 'dd' your IDE hard disk from your PC to a SAN volume and zLinux will utilize it. (Doesn't even have to be a Linux PC. Mainframe Linux can mount a 'dd' copy of a Windows PC disk which is physically on a SAN vol. No kidding! As long as the target is no smaller than the source vol.) The rest of the world has flattened out track/record/cylinder geometries and gone with "just a bunch of bytes". In other words, with SAN it's all data. This is especially true if you dispense with partitioning or if you restrain yourself from getting careless or excessive about partitioning. "SAN connects the same" -- You can literally share a SAN volume with Solaris, Windows, Linux, z/VM, and presumably AIX and HP and the rest. Eventually z/OS will play along too. (Dunno when they'll get there. Ask an IBMer.) Where CKD has to speak "IBM channel", SAN uses a common dialect. You know how CDL lets z/OS handle backups for Linux on CKD? In the SAN world, that kind of cross-platform access goes way further. Solaris can backup Windows. Linux can backup Solaris. VM can backup Linux. "SAN eliminates emulation" -- FOR LINUX, the CKD emulation slapped on at the disk system and stripped off at the Linux end is wasted overhead. Linux does not care about tracks and records and gaps and such. Linux just wants blocks of bytes. SAN talks "blocks of bytes" by nature. No geometric magic needed. FOR VM this advantage is lost at this time because the I/O protocol is different from what CP and CMS do natively. As a result, a different kind of emulation is needed ... for now. IFF there were a disk system that spoke SAN out one side and "IBM channel" out the other, even this emulation would be eliminiated. (I do not believe such a box exists. I've asked for it for more than a decade. But ... I didn't write the checks then.) "SAN is cheaper" -- I don't usually pay attention to the bills. I'm an engineer. But from what I hear management and others saying, SAN will save us a lot. con: SAN is still a little new on Linux EDEV (needed for z/VM access) presents overhead instrumentation? what instrumentation? "SAN is kind-of new" -- It was a little confusing to get SAN working at first. We run it through LVM2 (or sometimes mount SAN vols individually). Others have gotten SAN working with EVMS. I got a lot of help from various people and sources. We do not want to wire-in the WWPN+LUN addressing to the initial RAMDISK, which is how the distributor would like to support SAN. Stamping CKD addresses into the INITRD for virtual machines is one thing. Stamping WW addressing which varies from guest to guest is quite another. As a result, we have a simple home-grown script that reads a per-guest config and brings the right volumes on-line. But this is minor. It works. EDEV -- Where SAN eliminates CKD wrap/unwrap overhead, EDEV goes the other direction. EDEV is that other kind of emulation I mentioned in a prior paragraph in the "pro" section. VM takes a SAN volume and makes it look like a 9336. It's great! But it is slow. Note that EDEV is required (as far as I know) at this time if you are going to slice up a SAN volume into minidisks. Instrumentation -- Barton Robinson's favorite subject: measure it. There are few tools for doing low-level performance analysis of SAN. Those which exist are even more deeply proprietary that the vendor vector pain we put up with in the CKD world. gotta have it! We are looking at future heavy use of SAN. Up to now, it's all been CKD for our guests. Still not getting N-port ID Virtualization to work. We need NPIV so that each guest is kept to its own space. Apart from VM slicing things into minidisks, there's no real "security" in SAN other than NPIV. SAN is a network. FCP adapters are a lot like OSA. (I think the only difference is the microcode!) The saavy reader will notice that this means data security is pushed out to another place. Blech! To Bob's point, we use a SAN storage system that supports its own mirroring. As far as I can tell, both CKD boxes and SAN boxes have the same capability w/r/t replicated standby volumes. Note: I use the acronym CKD instead of ECKD because the "E" part is not significant in this context. I hope this helps. -- R; ---------------------------------------------------------------------- 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
