Case study for logical partitioning of a two-cluster grid
Hardware must be used and managed as effectively as possible to ensure your investments. One of the ways to protect the investment is by using the same hardware for more than one sysplex/host. Important points to consider are described, such as common areas that might need other technical competencies in addition to the storage team to be involved within the information technology (IT) structure for the correct sizing and planning.
It also gives you a practical guideline for aspects of the project, such as naming conventions and checklists. The solution is based on standard functions from IBM z/OS, Data Facility Storage Management Subsystem Removable Media Manager (DFSMSrmm), IBM Resource Access Control Facility (RACF), and functions available in the TS7700 2-cluster grid. A similar implementation can be done in any single-cluster or multi-cluster grid configuration.
The TS7700 R2.0 extended the possibilities of manageability and usability of the cluster or grid by introducing the Selective Device Access Control (SDAC). The SDAC enables you to split the grid or cluster into hard partitions that are accessible by independent hosts or applications.
SDAC, also known as hard partitioning, can isolate and secure environments with various requirements and objectives, shielding them from unintended or malicious interference between hosts. This is accomplished by granting access to determined ranges of logical volumes by selected groups of devices in a logical control unit (LCU) granularity (also referred to as LIBPORT-ID).
An example of a real implementation of this function is provided, going through the necessary steps to separate the environments Production (named PROD) and Test (named TEST) from each other despite sharing the TS7700 2-cluster grid.
This appendix includes the following sections:
•Verification of changes
Overview of partitioning
This description leads you through the steps for the logical partitioning of two hosts from one client: PROD and TEST.
The setup must be as complete as possible and established in a way that generates the best possible protection against unauthorized access to logical volumes dedicated to the other partition. You must protect against unauthorized user access for logical volumes on PROD from TEST and vice versa.
The function SDAC, introduced with R2.0, is used. It can be ordered as Feature Code 5271.
Other requirements must be agreed on before implementation. Depending on whether this is a multiclient or a single client multi-logical partition (LPAR) environment, consider the following requirements:
•Acceptance of sharing the two-cluster grid
•Specific security requirements
•Bandwidth that is needed per host
•Number of Fibre Channel Connection (FICON) channels per host
•Acceptance of shared or dedicated FICON channels
•Number of virtual drives and logical tapes that are needed per host
•Number of physical drives and physical tapes needed
•Tape security in RACF: Volume-related, data set-related, or both
Establish defined naming conventions before making your definitions. This makes it easier to logically relate all definitions and structures to one host when updates are needed.
Figure I-1 gives an overview of the setup. Updates are needed on many places. Adapt your current naming standards to your setup.
Figure I-1 Logical partitioning overview
Definitions and settings in z/OS
The needed definitions are covered in the components that run in z/OS. The same names and numbers must be defined and repeated on the clusters:
•Hardware configuration definitions (HCDs) to define:
– CTLUNITS for the 3490E devices.
– FICON channels.
– Esoteric definitions.
•PARMLIB definitions to define for these areas:
– Object access method (OAM) definitions if the OAM-started task is new on that host.
– Global resource serialization (GRS) parameters to enable the Auto Switchable (AS) function if needed. This is only valid if you have a sysplex with a tape management system (TMS) that is separate from the tape configuration databases (TCDBs).
– Missing Interrupt Handler (MIH) values for the device addresses.
– Category updates.
– Commands member to vary defined devices online.
•DFSMSrmm definitions:
– Volume ranges.
– PRTITION and OPENRULE definitions to avoid usage of volumes from the other host (replacement of REJECT and ANYUSE).
•JES2 JCL Procedure Library updates
JCL definitions to enable start of OAM-started task.
•SMS updates for constructs and ACS routines:
– Definition of libraries and SMS constructs (Storage Class (SC), Management Class (MC), and so on).
– Updates to ACS routines according to your conventions.
•RACF updates:
– Define started task OAM and required RACF profiles.
– Decide and define the required security settings regarding access to tape volumes and data sets on tape.
•Automation updates:
– If OAM is new, several updates are needed.
– If you choose to vary devices online by using the automation product, updates are needed.
– New messages must be evaluated and automated.
Figure I-2 shows the z/OS updates needed in the case study that define specific volume ranges, several device addresses, and scratch (Fast Ready) categories.
Figure I-2 Software updates with sample values on z/OS
Definitions in HCD
In HCD, you define the devices that are needed for each of the hosts and connect them to the LPARS. This case study defines 28 out of 32 CUs for PROD (2 x 224 logical devices) and 4 out of 32 CUs (2 x 32 logical devices) for TEST. The devices for Cluster 0 have addresses from 1000 - 10FF and for Cluster 1 the values are 2000 - 20FF (Table I-1).
Table I-1 HCD definitions
|
Host
|
Cluster
|
CTLUNIT definition
|
LIBPORT-ID
|
|
PROD
|
Cluster 0
|
CUADD 00-0D
(1000 - 10DF) |
01-0E
|
|
Cluster 1
|
CUADD 40-4D
(2000 - 20DF)
|
41-4E
|
|
|
TEST
|
Cluster 0
|
CUADD 0E-0F
(10E0 - 10FF)
|
0F-10
|
|
Cluster 1
|
CUADD 4E-4F
(20E0 - 20FF)
|
4F-50
|
More definitions are needed:
•The devices must be connected to processors.
•Devices must be related to esoterics definitions.
•Definitions regarding the FICON infrastructure and FICON directors are not included.
Normally, you can activate the new definitions dynamically. Details regarding HCD definitions are described in 6.4, “Hardware configuration definition” on page 228.
PARMLIB definitions
Use PARMLIB to define all the essential parameters that are needed to run the z/OS system. Some parameters apply to this case study and definitions can be made with same values on both hosts (TEST and PROD). All the described parameters can be activated dynamically on the current release of z/OS.
See the following resources for complete information about options in PARMLIB, definitions, and commands to activate without IPL:
•MVS System Commands, SA22-7627
•MVS Initialization and Tuning Reference, SA22-7592
The updates are within the following members of PARMLIB, where the suffix and the exact name of the PARMLIB data set apply to your naming standards. It is important to make the changes according to normal change rules. If the updates are not implemented correctly, severe problems can occur when the next IPL is planned.
•IEFSSNxx. These updates apply for TEST and PROD:
– If OAM is new to the installation, the definitions in Example I-1 are required.
Example I-1 OAM subsystem definition
*-------------------------------------------*/
/* OAM - OBJECT ACCESS METHOD - ATL Control */
/*------------------------------------------*/
SUBSYS SUBNAME(OAM1)
INITRTN(CBRINIT)
•SCHEDxx. These updates apply for TEST and PROD:
– If OAM is new to the installation, definitions in Example I-2 are required to start OAM. These definitions require you to start OAM as part of the normal IPL sequence by using your own automation product.
Example I-2 OAM definition in SCHEDxx
PPT PGMNAME(CBROAM) /* OAM ADDRESS SPACE */
KEY(5) /* KEY(5) PROTECTION KEY */
NOSWAP /* NOSWAP NON SWAPPABLE */
SYST /* SYST SYSTEM TASK */
•GRSRNLxx. These updates apply for TEST and PROD:
– If the platform has the prerequisites for use of Auto Switchable (AS) devices, runs in GRS goal mode, or uses Coupling Facilities hardware, AS support can be enabled by the values in Example I-3 on page 924. AS offers the ability to have the devices online on all LPARS in a sysplex and reduces your need for specific products that have similar functions. AS has these requirements:
• Devices are defined as AS in HCD.
• Operators or automation products issue VARY commands.
|
Tip: V 1000,AS,ON makes the specified address available for AS support. When followed by V 1000,ONLINE, it varies the device online. Both commands must be entered on all hosts that need device 1000 online and auto-switchable.
|
Example I-3 illustrates enabling AS support.
Example I-3 GRS definition to enable AS support
/*------------------------------------------------------------------*/
/* Enable AS support */
/*------------------------------------------------------------------*/
RNLDEF RNL(INCL)
TYPE(GENERIC)
QNAME(SYSZVOLS)
|
Note: A Parallel Sysplex must have a shared TMS - plex (TMSplex), SMSplex, and TCBD. In this case, no partitioning can be defined.
|
•IECIOSxx. In this member, you can define specific device ranges, and you must separate TEST from the PROD updates:
– TEST updates are in Example I-4, one line for each range of devices. The MOUNTMSG parameters ensure that the console receives the Mount Pending message (IOS070E) if a mount is not complete within 10 minutes. You can adjust this value. It depends on many factors, such as read/write ratio on the connected host and available capacity in the grid.
Example I-4 IECIOSxx updates for specific TEST device addresses
MIH DEV=(10E0-10FF),TIME=45:00
MIH DEV=(20E0-20FF),TIME=45:00
MIH MOUNTMSG=YES,MNTS=10:00
– PROD updates are in Example I-5, one line for each range of devices.
Example I-5 IECIOSxx updates for specific PROD device addresses
MIH DEV=(1000-10DF),TIME=45:00
MIH DEV=(2000-20DF),TIME=45:00
MIH MOUNTMSG=YES,MNTS=10:00
•DEVSUPxx. In this member, you can define specific device ranges. You must be specific and separate TEST from the PROD updates:
– DEVSUPxx for TEST is shown in Example I-6 for the categories that apply for TEST.
Example I-6 DEVSUPxx updates for specific TEST category
COMPACT=YES,
MEDIA2=0022,
ERROR=002E,
PRIVATE=002F,
VOLNSNS=YES
– DEVSUPxx for PROD is shown in Example I-7 for the categories that apply for PROD.
Example I-7 DEVSUPxx updates for specific PROD category
COMPACT=YES,
MEDIA2=0012,
ERROR=001E,
PRIVATE=001F,
VOLNSNS=YES
•COMMANDxx can be used to vary the range of devices online after IPL:
– For TEST, apply a specific range of devices as shown in Example I-8.
Example I-8 Vary devices online after IPL for TEST
COM='V 10E0-10FF,ONLINE'
COM='V 20E0-20FF,ONLINE'
– For PROD, apply a specific range of devices as shown in Example I-9.
Example I-9 Vary devices online after IPL for PROD
COM='V 1000-10DF,ONLINE'
COM='V 2000-20DF,ONLINE'
DFSMSrmm definitions
In this case study, you have DFSMSrmm as the TMS. Equivalent definitions must be defined if you prefer to use another vendor’s TMS. These definitions can be created by using options in DFSMSrmm PRTITION and OPENRULE. PRTITION is the preferred method for partitioning. REJECT commands, although still supported, must not be used in new installations. If you use REJECT commands, you must convert from the use of REJECT commands to use the PRTITION and commands.
See z/OS DFSMSrmm Implementation and Customization Guide, SC23-6874, for complete information about options for DFSMSrmm. Table I-2 shows the definitions that are needed in this specific case study. You must define the volume range that is connected to the host. Reject use and insertion of volumes that are connected to the other host.
Table I-2 DFSMSrmm options
|
Host
|
VLPOOL definitions
|
PRTITION definitions
|
OPENRULE definitions
|
|
PROD
|
VLPOOL PREFIX(A*) TYPE(S) DESCRIPTION (PROD DEFAULT') MEDIANAME(*)
|
PRTITION VOLUME(B*)
TYPE(NONRMM) SMT(IGNORE)
NOSMT(IGNORE)
|
OPENRULE VOLUME(B*)
TYPE(RMM)
ANYUSE(REJECT)
|
|
TEST
|
VLPOOL PREFIX(B*) TYPE(S) DESCRIPTION (TEST DEFAULT') MEDIANAME(*)
|
PRTITION VOLUME(A*)
TYPE(NONRMM) SMT(IGNORE)
NOSMT(IGNORE)
|
OPENRULE VOLUME(A*)
TYPE(RMM)
ANYUSE(REJECT)
|
JES2 definitions
If OAM is new to the hosts, OAM JCL must be defined in one of the JES2 procedure libraries. These JCL definitions apply for TEST and for PROD as shown in Example I-10.
Example I-10 JCL for OAM-started task
//OAM PROC OSMC=YES,MAXS=2,UNLOAD=9999,RESTART=NO
//IEFPROC EXEC PGM=CBROAM,REGION=64M,
// PARM=('OSMC=&OSMC,APLAN=CBROAM,MAXS=&MAXS,UNLOAD=&UNLOAD',
// 'RESTART=&RESTART')
//*
//SYSABEND DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
SMS constructs and definitions
This description does not explain in detail how to create ACS routines or how to create ACS constructs. It states the ACS constructs that are needed and suggests a naming convention that helps you understand the constructs relationship:
•SC definition :
– Preference Group 0 assigned to volumes that are unlikely to be accessed.
– Preference Group 1 for volumes likely to be accessed.
•MC definition:
Not relevant for the partitioning, but you must have separate sets for TEST and PROD.
•DC definitions:
Definition and relation to logical volume sizes, in this example, 800 MB and 6000 MB.
•SG definitions:
Pointing the SG to the composite library definition.
•ACS and library definitions must also be defined, but they are not described here.
The naming convention in this case defines that all TEST definitions are prefixes with TS and PROD with PR.
ACS constructs and definitions for TEST are in Table I-3. Ensure that the construct names match the names that you define on the Management Interface (MI).
Table I-3 ACS construct names and important values
|
ACS constructs
|
ACS construct name for
TEST/PROD
|
Important value
|
|
SC for Preference Group 0
|
TSSCPG0/PRSCPG0
|
N/A
|
|
SC for Preference Group 1
|
TSSCPG1/PRSCPG1
|
N/A
|
|
MC for one copy in cluster0
|
TSMCCL0/PRMCCL0
|
N/A
|
|
MC for one copy in cluster1
|
TSMCCL1/PRMCCL1
|
N/A
|
|
DC for 800 MB volume
|
TSDC800M/PRDC800M
|
Media recording must be MEDIA2.
Recording tech must be 36TRACKS.
|
|
DC for 6000 MB volume
|
TSDC6GB/PRDC6GB
|
Media recording must be MEDIA2.
Recording tech must be 36TRACKS.
|
|
SG to relate to composite library
|
TSCOMP1/PRCOMP11
|
Library name must match the SMS-defined name for composite library.
|
1 Nomenclature derives from TEST and PROD plus composite library number. Many clients have more than one grid installed.
RACF definitions
General rules for RACF definitions are defined by your policies. Security, in the areas of access to updates of tape information in DFSMSrmm and protection of access to data sets on tape volumes, is improved from IBM z/OS 1.8. However, many installations seem to forget that access to read and write tape volumes and tape data sets is by default not restricted with RACF settings. You need to define your own rules to protect for unauthorized access.
The same rules apply for access to run updates of the content in DFSMSrmm. Various solutions can be implemented.
For more information about options, security options, and access rules, see z/OS DFSMSrmm Implementation and Customization Guide, SC23-6874.
Automation activities
If OAM and TS7700 are new on the host, evaluate these concerns:
•OAM must start after the IPL.
•New messages are introduced.
•Hardware errors and operator interventions occur and must be handled.
See the IBM TS7700 Series Operator Informational Messages White Paper, which is available at the Techdocs library website:
Definitions on the TS7700 Management Interface
Updates and definitions that are needed on the windows of the Management Interface (MI) are covered. The definitions must match the definitions on the z/OS hosts to make it work. Make updates in the areas that are shown in Figure I-3.
Figure I-3 Management Interface updates for logical partitioning of TEST and PROD
Physical volume pools
You must decide based on your requirements whether TEST and PROD can be on the same physical volumes, share volumes from the same physical volume pools, or must be placed on separate physical volumes:
•If sharing of same physical volumes is acceptable, all logical volumes from TEST and PROD are mixed on the physical VOLSERs, and separate pools for PROD and TEST are not required.
•If sharing of same physical volume ranges is unacceptable, total separation of physical volume ranges can be accomplished by assigning specific physical volume ranges for each pool and by using the noborrow/keep options.
The Physical Volume Pool Modify Properties window that is shown in Figure I-4 is used to define reclaim policies for each of the pools. Assign logical volumes to pool 1 for PROD and pool 2 for TEST, as shown in Figure I-9 on page 931.
Figure I-4 Volume pools for PROD and TEST
Scratch (Fast Ready) categories
The TS7700 performs scratch (Fast Ready) mounts directly to the Tape Volume Cache (TVC) with no physical tape involvement. This needs to be enabled on all hosts. At Release 3.0, all categories that are defined as scratch inherit the Fast Ready attribute. In prior releases, it was necessary to set this option in the MI.
Defining constructs
Define the constructs on all clusters in the grid with definitions consistent with your policies. Consider the following information:
1. Define an SC for TEST named TSSCPG0. This is an SC for volumes unlikely to be used (level 0 or PG0), as shown in Figure I-5. The other SCs must be defined in a similar way. Ensure that Tape Volume Cache Preference is set according to the defined SC name.
Figure I-5 Define Storage Class for TEST
2. Define an MC for TEST named TSMCCL0 with only one copy of data and cache residency in cluster0 as shown in Figure I-6. Set the Copy Consistence Point to RUN on cluster0 and NOCOPY on cluster1. The other MCs are defined in a similar way.
|
Remember: Without the use of MC from z/OS, the default is a copy in both clusters.
|
Figure I-6 Management Class for TEST
3. Define a DC for TEST named TSDC800M as shown in Figure I-7.
Figure I-7 Data Class for TEST
4. Also, define a DC for TEST that is named TSDC6GB (6000 MB), as shown in Figure I-8.
Figure I-8 Data Class for TEST with 6000 MB volume size
5. Define an SG for TEST (named TSCOMP1) as shown in Figure I-9. Remember your requirements for secluded physical volumes as described in “Physical volume pools” on page 928. The definition for PROD is not shown, but it must relate to volume pool 1. Define the SG on both clusters in the grid.
Figure I-9 Storage Group for TEST
Library Port Access Groups
The library port access group windows are available only when the Selective Device Access Control (SDAC) feature is installed.
Perform the following steps for Library Port Access Groups:
1. Now, define two access groups to relate the CUs (LIBPORT-IDs) to logical volume ranges by selecting Settings → Library Port Access Group and then clicking Add from the menu.
Figure I-10 shows creating the access group TEST and connecting it to Library Ports 0F and 10 on Cluster 0.
Figure I-10 Add the access group for TEST LPAR
2. Now, use the menu to select Cluster 1 to add Lib Ports 4F and 50 to the TEST access group as shown in Figure I-11.
Figure I-11 Modify an access group for TEST LPAR
3. PROD is connected to both clusters as well, but by using the opposite Lib Ports, 01-0E on Cluster 0, as shown in Figure I-12.
Figure I-12 Add an access group for PROD LPAR
4. Define 41-4E on Cluster 1, as shown in Figure I-13.
Figure I-13 Modify the access group for PROD LPAR
5. Check to see that each access group’s ranges are not overlapping, as shown in Figure I-14.
Figure I-14 Summary display of access groups
6. Define logical volume ranges to the access groups, as shown in Figure I-15.
Figure I-15 Add VOLSER range for TEST LPAR
7. You can see that the ranges are assigned to their correct hosts, as shown in Figure I-16.
Figure I-16 Summary of access groups and VOLSER ranges
Logical volume ranges or insert volumes connected to defined ranges
On the MI window as shown Figure I-17, insert the number of logical volumes that fits your initial need for PROD and TEST. The example shows how to insert 1000 logical volumes for the TEST partition. Normally, you define the inserted volume size to be 800 MB (ECCST). When used on z/OS, the assignment of DC defines the maximum volume size, which is 800 MB or 6000 MB in the case study.
Figure I-17 Insert volumes for TEST
User Management on the Management Interface
Depending on your requirements, you can define roles and rules for the users that use the MI to prevent unauthorized access to data and to set user privileges. For more information, see 9.3.9, “The Access icon” on page 464.
Verification of changes
After setting the definitions, evaluate your setup against the one shown in Figure I-18. If you try to read or write to a logical volume belonging to the other host, the job fails and a message presents the reason.
Figure I-18 Result after all definitions are finished
You can run several procedures to ensure that the setup is correct and ready for production. Be sure that you cover the following points:
•Control that all settings are as expected on z/OS and on the MI.
•Configure the channels online and vary the devices online on your system.
•Enter one logical volume and ensure that the volume is entered in the correct partition.
•Look up the volume by using the started task OAM, or by entering the command:
D SMS,VOL,volser,DETAIL
•Check the values of the scratch tape in DFSMSrmm by using dedicated windows.
•Create a job that creates a tape and evaluate that the constructs are assigned correctly.
•Issue D SMShi,VOL,volser,DETAIL again to check the assignment of constructs from
the grid.
the grid.
•Use the Library Request host console commands to evaluate the status on the created private volume and the status of the physical volume to which it was copied.
•Use the MI to further evaluate the related physical volume pool.
•Ensure that constructs and definitions on both clusters are tested and evaluated.
•Make the last and final evaluation after the next IPL of the system to validate that the dynamic commands that are given are reflected in the required data sets, such as PARMLIB.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.