W dniu 10.02.2021 o 11:00, Gadi Ben-Avi pisze:
Hi, Our current configuration consists of: Production site: A z15-t02 running z/OS v2.3 and a z13s running z/OS 2.4 Each computer runs a different application and there is no communication between the two systems. Both systems connect to the same DS8884 using 4 FICON channels each. The DS8884 has separate definitions for each of the systems. There are two resource groups defined in the DS8884 for this purpose. Both systems connect to the same TS7760 using 2 FICON channels each. Each LPAR uses a different category range to separate the virtual volumes belonging to one partition from the ones belonging to the other LPARs. DR site There is one z13s that has all of the LPARs from the two production systems defined. There is a DS8884 that has all of the definitions from the DS8884 in the production site. In addition, it has definitions for a test copy for all of the volumes. There is a TS7760 that is connected in a GRID to the TS7760 at the production site. Replication: All volumes at the production site are replicated to the DR site. All virtual tape volumes are copied to the remote site. We use CSM to manage the replication. The DS8884 in the production site is connected to a Brocade switch that is connected to another switch in the DR site using a dedicated Fiber Channel line. 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? How do define the remote DS8884 to z/OS at the production site? Do I need any new software on z/OS? I've looked at some redbooks, but I got lost. Do I need anything else?
I would start from simpler, but very convenient solution: just make DR dasd physically and logically accessible from prod LPARs. It may need some changes in your SAN configuration, because your prod LPARs should access remote dasd as regular dasd. Topology: CPCprod --- director1 --- DWDM --- director2 --- DASDdr. There are may details to consider: ISL bandwidth, available ports on each device, two CPCs on prod site, etc. I would suggest to start using single IODF for all your shop, I mean all three CPCs in two sites. It is possible and much more convenient than separate IODFs. And less error-prone. Then you should create or customize OS Configs in the IODF. Again, many details, but this will prevent you from duplicate volsers at IPL time and some other problems. Finally you can use DR dasd as local. In case of catastrophic primary dasd failure you can manually switch to dr DASD. IPL (and outage) will be required. Important: vast majority of the task above are prerequisites for Hyperswap, so you go in desired direction. However, AFAIK hyperswap will not prevent you from dasd failure. I assume you don't have and don't plan GDPS/PPRC. Hyperswap without GDPS is good for planned outages. (correct me if I'm wrong here).
HTH -- Radoslaw Skorupka (looking for new job) Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
