Unsolved
This post is more than 5 years old
207 Posts
0
848
Mainframe SRDF Groups
I am a UNIX/Windows guy that will be implementing SRDF/A for the first time. Unfortunately, I have to start off with our z/OS mainframe before I work on the platforms that I am so comfortable with.
I have asked our z systems programmer to provide me with some info regarding which volumes will be replicated and how they will be grouped. I was hoping he would come back with something like this -
volumes bb0-bdf - OS volumes to be replicated every 8 hours
volumes bc0-bff - Application volumes (DB2, VSAM, flat files to be replicated every 30 seconds).
This would allow me to have a minimum of device groups, RA groups and consistency groups. I feel like the fewer of these things to manage the better. Instead, he is coming back with many (8-12) different smaller groups - some with only a few volumes. There are two different applications on the host so I could easily tolerate 1 OS group and 2 application groups. If I have as many as 12 groups each with a device groups, RA group, and consistency group; will this be difficult to manage? Isn't it better to have fewer of these groups?
Once I'm done with the IBM mainframe I will have to tackle our Unisys, Windows and UNIX environments. I feel like I need to keep the complexity to a minimum. What do you think? Any insight to current z/OS SRDF implementations would be great.
PedalHarder
465 Posts
1
April 11th, 2010 17:00
Hi,
It doesn't make sense to me that the OS is out of step with the application environment. For Example, The OS includes shared services like JES SPOOL, job and report archiving, Job scheduler, perhaps MQ series, sysplex LOGR dataset that may be used by Resource Recovery Services (RRS). RRS is used to handle global synch-point processing in a 2-phase-commit... Definitely application related.
So consider how to work out the state of the databases in a DR when the system volumes are out of time with the apps. You may have had jobs run that modify databases or perform data feeds from one system to another, but because the system volumes are at an older point in time, there is no record of these jobs being run. Another example would be that the payroll has been run and the database reflects this, but the pay slips that were sitting in the output spool don't exist in if there is a DR.
In this regard I suggest a minimum number (or 1) RDF groups. If > 1 then perhaps MSC is required to co-ordinate the cycle switching. Have a good hard look at the real data interdependencies before you decide your RDF groups - there is no point in implementing multiple independent groups only to find a DR scenario fails because of data dependencies that weren't discovered in the RDF design phase. If it's system volume write bandwidth that is a concern, PAGE volumes don’t need constant replication. Neither does any WORK storage pools (provided you can confirm that no data is written to them that would be required in a DR).
Hope this helps.
brad12341
207 Posts
0
April 13th, 2010 13:00
We don't have 2 phase commits. From what I know about the app it is mostly a CICS/DB2 OLTP system. Users are entering transactions most of the day. Those transactions need to get to the DR DB very frequently. Not really any jobs, reports etc going on during the day.
In the middle of the night everything is paused and we get full backups. Then some batch jobs are run and then full backups again. These backups will be de-duped and replicated to the DR site using data domain dd880s. If we ever have a disaster in the middle of the batch cycle we will likely restore from backup and re-run all batch.
On the OS side when infrequent changes are made to the source mainframe they just need to be replicated at some point to the target side. That's why I was thinking of every 4 hours. The application data on the other hand needs to replicate every minute of so. So I was thinking the best way to group things is all application data in one group with 1 minute cycle and all OS stuff in another group with 4 hour cycle.
But maybe I should have just one group as you suggest with the 1 minute cycle time. The infrequent OS changes would just go whenever they are made rather than going as a group every 4 hours.