>From Marcy: What's a consisteny option? Does it go across all LCU's and file systems?
Linux does timestamp its i/o. VM does not (currently - see IBM). I'm not familiar with the EMC's consistency. We do use GDPS/XRC for our recovery, giving a recovery point of less than a minute. Does this EMC solution use those? Once you have many many interdependent applications the same point in time recovery becomes very important. My response: We have all VM and Linux volumes on a single physical controller EMC DMX-1000. On z/OS I run a batch job to execute an EMCSNAP utility. EMCSNAP allows me to identify the volumes to snap and to make a consistent (point-in-time) copy. The controller handles the I/O activity such that a point-in-time copy is made to the target volumes. In our mirrored configuration, the local DMX-1000 is mirrored to another DMX-1000 using EMC's SRDF/A feature. The controllers handle all aspects of the mirroring (the remote DMX-1000 is not connected to a host until DR time). You can logically view this mirroring as the local controller performing a consistent snap of all volumes every thirty seconds to the remote controller. We are primarily a z/OS shop and all of the production and system type volumes for z/OS, z/VM, and z/Linux reside on the local DMX-1000 controller. There is a second local EMC controller used to support development environments. It is not mirrored. The z/VM is used to support the z/Linux only. No CMS users other than those to support the systems. The z/Linux servers are used to support a couple of lightly used applications under WebSphere with DB/2 as the database. An Oracle database is also on a z/Linux server and lightly used for a z/OS application. >From Mark Post and David Boyes: Both stress Linux cache will cause problems with recovery and that the databases should be backed up under the Linux OS. My response: We do perform database backups under the Linux OS. They can be used for local site recovery and are available at the DR site (because they are on the DASD that is mirrored and snapped/dumped to tape). I suppose for a tape recovery, the database backups could be used since most of the time the snaps are performed after the database is backed up. The idea behind the mirroring is to reduce the amount of data loss. But, recovering from the database backup and forward recovering with the logs would work. In either case, it just would be easier to IPL and go at the DR site. Since VM and most of the servers are static (little I/O), I don't expect problems getting them started at the DR site. The main concern is recovering the databases. If DB/2 states it can automatically restart/recover after a server failure and reboot, then what is the difference between a failure (where the cache didn't get written) and a consistent snap? I would think DB/2 and Oracle would need to somehow compensate for how Linux caches the write I/Os. Else their claim to be able to restart/recover from a crash is somewhat misleading. I appreciate the feedback. Art ---------------------------------------------------------------------- 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
