How have you implemented CA VM:Backup in an SSI environment? Below you will find a draft of our recommendations. Do they differ from your experience? Do you have any best practices? Is the information below helpful and adequate?
Feel free to edit this document, adding information that you think could be of use to other customers. Please collaborate with us on creating a set of recommendations.
In an SSI environment, most DASD volumes are globally shared among all members of the complex while certain other volumes are private to each member system. Most virtual machines are able to log on once in the complex on any member, while others will be able to log on multiple times, once per member system in the complex. In order for normal user virtual machines to be able to log on to any member of the complex, minidisks must be allocated on globally shared DASD. Similarly, virtual machines that can log on to more than one member simultaneously should have minidisks that are allocated on private volumes.
It is critical when creating and manipulating directory entries, that you follow this convention:
- Minidisks for normal users must be allocated only on globally shared volumes
- Minidisks defined for IDENTITY virtual machines in a SUBCONFIG be allocated only on volumes that are private to the member on which the SUBCONFIG is built.
Failure to follow this convention may prevent successful backups.
CA VM:Backup can be used in an SSI environment as follows:
- Multiple CA VM:Backup servers must be deployed as normal user IDs. One of these servers (probably VMBACKUP) will be responsible for backing up and restoring normal VM user IDs having minidisks that are allocated on shared DASD. This user ID (VMBACKUP) can be run on any member because it works with DASD volumes that are globally shared.
- VMBACKUP must be prevented from backing up private volumes. This is done by setting up an exclusion file that excludes all of the private DASD volumes as well as user IDs you do not want to backup at all (for example, $ALLOC$). You can do this with the 'Manage Exception/Exclusion Files' screen, which is accessible from the System Administrator Main Menu. This screen allows you to work with a maximum of 12 volsers. If you have more private volumes containing minidisks, you will have to import a TPI exclusion file. In either case, be sure to specify the Exclude DASD volumes and one or more Excluded user IDs.
- The other CA VM:Backup servers (probably named VMBKUP01 through VMBKUP04) will be responsible for backing up minidisks that are defined on private volumes specific to each member. These servers must be run on the specific member that has access to the private DASD to be backed up. You are responsible for ensuring these user IDs will be logged on to the correct member. To ensure these servers back up only private DASD volumes, you must specify the private volsers in the Include DASD fields of the backup template.
Because we are deploying normal servers with unique user IDs, you will be able to control these servers using the VMBACKUP,VMBKUP01, VMBKUP02, VMBKUP03 and VMBKUP04 command modules produced during deployment of the servers. These programs should reside on globally shared minidisks.
In order to issue a VM:Backup command from an IDENTITY virtual machine when the server is on a different SSI member, you must include a DISTRIBUTE IUCV TOLERATE statement in the shared SYSTEM CONFIG file. Because IBM requires the same DISTRIBUTE settings for every member of an SSI complex, you must make the change in the SYSTEM CONFIG file, SHUTDOWN every member, and then re-IPL every member for the change to take effect. You cannot change the DISTRIBUTE setting and then SHUTDOWN and IPL each member one at a time.