Agree that all machines are better off in a single IODF. In a site I was at, site1 was connected to both site1dasd and site2dasd. However, only a few volumes from site2dasd were 'live' / accessible; the rest were PPRC targets from site1dasd. Those site2dasd vols that were accessible from site1, were primary/secondary of some sort or data volumes for quick lookup of stuff from site2, if site1 went inaccessible. I think even the live IODF was from site2dasd. The above will depend on the distance b/w sites.
Example: Primary RACF was hosted on site2dasd, secondary in site1dasd. It's easy to think, therefore, "oh ok, CDSA in site1, CDSB in site2." This is to be avoided. Each site should have its own set of locally resilient (keep them on separate, different volumes) CDSes. Across multiple IBM TechDocs (which IBM has basically killed now), IBM recommends having separate CDSes for each site to ease various recovery scenarios. Mark A Brooks has given some seriously incredibly sysplex-specific sessions in the recent SHAREs. If your intent of having site2dasd accessible in site1 is to allow reads from both places.... this requires even more thinking, and is dependent on your replication technology. If it is PPRC, even if the site1mainframes die, you could just go to the DS GUI or CSM to ESTPATH(2to1), ESTPAIR(2to1), DELPAIR(1to2), DELPATH(1to2), etc. 1to2 means primary to secondary and 2to1 vice versa. I found it easy to have separate unit ranges for each site, odds for prod, even for DR, i.e., 1xxx, 3xxx, etc. for prod, 2xxx, 4xxx. Will the extra subchannel sets, SuperPav, etc. and hopefully mod54s, running out of units won't be a problem. You can interconnect storage & tape b/w sites using Brocade IPEX (I think?) or one of those Channel Extenders (SANxxx-xx-R). If any corrections are required on what I've said above, do let me know (listers)! - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 11, 2021 12:27 PM, Timothy Sipples <[email protected]> wrote: > Gadi Ben-Avi wrote: > > > ....What we want to do: > > Allow the computers in the production site to use the DS8884 > > in the DR site. This is to allow us to continue working at the > > production site if there is a catastrophic problem with the > > DS8884 in the production site. When I spoke to our Storage > > salesperson he told us that HyperSwap is the direction to go. > > So I have some questions: > > Is HyperSwap the right solution? > > The steps Radoslaw outlines are the rough prerequisites for HyperSwap, but > it doesn't make much sense to me to make the effort then not enable > HyperSwap. > > Here's the basic question to answer, though: considering your most > demanding (most important) business service, end-to-end, what are your > Recovery Time Objective (RTO) and Recovery Point Objective (RPO)? > Ultimately your organization's top management answers this question, > perhaps at the direction of regulators. And this is always about assuring > end user service delivery. It doesn't matter if your IBM Z is deployed in > a RTO=0/RPO=0 way if nobody can reach it when there's a disaster because > there's one much less reliable server sitting in front that's supposed to > be doing something and isn't. Fundamentally your RTO/RPO are constrained > per the weakest link(s) in service delivery. > > Assuming HyperSwap is helpful or required to achieve your DR and HA > objectives, there are several z/OS HyperSwap deployment variations, as > this recent redbook explains: > > https://www.redbooks.ibm.com/redbooks/pdfs/sg248431.pdf > > Is this the redbook that you already checked? One area where I might > quibble with the redbook is that it seems to imply Parallel Sysplex is a > prerequisite for HyperSwap. While Parallel Sysplexes are common and might > also be helpful or required to achieve your RTO/RPO, they're not strictly > necessary for HyperSwap deployments. > > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > > E-Mail: [email protected] > > --------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
