Great question!
On 08/15/16 10:49, Gentry, Steve wrote:
There are at least 3 combinations of DASD usage for Linux implementation. They are: 1) Everything on 3390 storage 2) Everything on non-3390, external disk via a fiber card 3) A combination of 1 & 2
You left out V-Disk, but we'll just focus on physical storage. Linux can also use DCSS for filesystems. Very handy.
What are the thoughts on using these? Is one preferred over the other?
Depends on two (or more) important things from your shop: _is z/VM going to manage the storage?_ and _do you have cultural affinity for one or the other? _ Also _depends on the quantity of data_. If you have large filesystems, you're more likely to go with #3 combo. (On all Unix/Linux, not just z.) It's reasonable that the hypervisor will carve out chunks of physical disk to be given to the guests. On z/VM we call them minidisks, but KVM, Xen, and VMware and the rest have the same concept. z/VM (e.g., VM:Secure, not CP alone) can also sliced up SAN, but you're probably going to want that fed through as EDEV. (So it's not really limited to 3390 unless "cultural affinity" prohibits EDEV.) The storage itself is often managed by different groups. Most shops where I have worked had one team for z disk and another for SAN. These people typically reside on different planets. (Sad because "disk is disk"; see below.) *Personal recommendation*: mix it up. "*think, then mix*" (give it some forethought, but then *do* go with a combination) Put the OS on smaller filesystems backed by hypervisor-managed DASD. Keep the OS separate so you can maintain it apart from the data. Put large quantities of data on SAN (is often more cost effective, but there's another reason; see below). Possibly put smaller data quantities on hypervisor-managed DASD, but in any case keep it separate from the OS. SAN is a network. (FICON is too, but /doesn't look that way/ to zLinux.) Keep the OS separate so it can be maintained separately. It's a pain to have to re-install the data just because you upgraded the operating system. But it happens. Better to have the data (even if smaller quantities) in well though alternative mount point(s) to be imported after op sys refresh. (Quotes from "Mother" come to mind, and don't comingle what IBM gives you and what you do for yourself, but here it's SUSE/RH/Debian too.) Dirty little secret #1: disk is disk A long time ago, I heard that 3390 would be the last disk of its kind. Huh? Turns out that physical 3390 was the last DASD to be washing-machine sized drum of platters. Everything since then has been emulation of ECKD/tracks/records backed by FBA. There are reasons, some of them good, for continuing to use 3390. (Even though it's an illusion.) But keep in mind, in case it helps you, that the backing store is really fixed block. You might get some advantages by going direct. (Bypassing the CKD/track/record emulation.) Some mainframe storage vendors even offer 9336 or 3370 presentation. (That is, FBA on the channel, not via SAN or EDEV.) Dirty little secret #2: SAN is cross-platform This ties indirectly with DLS#1. SAN volumes can be used by any op sys, any platform, any (nearly any) computing hardware in your shop. Depending on the filesystem stamped onto a SAN volume (call it a LUN) you might be able to share it directly with many systems. What does it buy you? Depends on your platform needs. Maybe nothing; maybe lots. Hard to know ahead of time what apps and systems will or will not be able to use a LUN which was created by some other system or app. But just as z/OS and VSE and z/VM can share ECKD DASD, so Linux and AIX and Solaris and HP-UX and even Windows can share LUNs. Same advantages; same risks. Of course, SAN is all fixed block, so that's how DLS#1 and DLS#2 relate. There's also a thing about partitioning or not. (But you've heard enough of my ranting and rambling for Monday, eh?)
Thanks, Steve
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 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
