Usage models

The following illustrate all supported usage models for BS2000-UFS and remote workstations.

BS2000-UFS

Environment description

Figure 27: HSMS in a HIPLEX for BS2000-UFS: accessibility of POSIX files and HSMS metadata

• A HIPLEX system has several hosts, in this example they are Host 1 and Host 2.

• Each host supports the HSMS functions for its BS2000-UFS.

• The POSIX administrator must store all file system containers which are to be used for HIPLEX support on one of the pubsets (shared or exclusive). In the diagram shown above the file system containers are stored on SM pubset C.

• The affected SM pubsets must be brought under HSMS control (CREATE-SM-PUBSET-PARAMETERS, HSMS 1 for A and C, HSMS 2 for B and C).

• Several archives must be stored on SM pubsets A, B and C.

• On Host 1 the BS2000-UFS must be brought under HSMS control in each environment according to BS2000-UFS (SF pubset for the root file system, SM pubset A for the branch /SM-PUB/A, SM pubset C for the branch /SM-PUB/C):

  //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-F
  //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=A)
  //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=C)
  

   

• On Host 2 the BS2000-UFS must be brought under HSMS control in each environment according to BS2000-UFS (SF pubset for the root file system, SM pubset B for the branch /SM-PUB/B, SM pubset C for the branch /SM-PUB/C):

  //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-F
  //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=B)
  //MODIFY-NODE-PARAMETERS NODE-ID=*BS2000-UFS,ENVIRONMENT=*S-M(CAT-ID=C)
  

During normal operation HSMS saves the corresponding metadata in the environment in which the POSIX data is also saved:

• When you back up a file system which is located under the branch /SM-PUB/A, HSMS stores the metadata in an archive on SM pubset A.

• When you back up a file system which is located under the branch /SM-Pub/C, HSMS stores the metadata in an archive on SM pubset C.

Measures to be taken after a system failure

After a system failure on Host 1, Host 2 is the designated substitute host. Once the following measures have been taken HSMS 2 can continue the work of HSMS 1.

Measures to be taken on Host 1	Measures to be taken on substitute host i.e Host 2
System failure -> Host 1 is no longer available
	The system administrator must take the following measures:
	Import SM pubset A (/IMPORT-PUBSET) Start a POSIX session, if one does not already exist. “Mount” file systems from Host 1 using the POSIX installation program (use SYSDAT.POSIX-BC.FSLIST file); Host 1 users now have the same configuration and access as they did before the system failure. Load and start HSMS, if HSMS is not yet running BS2000-UFS in the new imported environment must be brought under HSMS control.
	The HSMS administrator must take the following measures:
	Enter the HSMS statement RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE for SM pubset A, this allows you to process the requests, which were initiated on Host 1 before the system failure.

Figure 28: HSMS in a HIPLEX for BS2000-UFS: accessibility of POSIX files and HSMS metadata after a system failure

Measures to be taken after recovery from a system failure

Once Host 1 is up and running again, the node files can be brought onto the original Host and the HSMS activities can be transferred back again. To do this the following measures must be taken:

Measures to be taken on Host 1	Measures to be taken on substitute host i.e Host 2
Reason for system failure eliminated -> Host 1 is available again
	The system administrator must take the following measures:
	“Delete” the file system using the POSIX installation program Remove BS2000-UFS in SM pubset A from HSMS control Export SM pubset A (/EXPORT-PUBSET)
The system administrator must take the following measures:
Import SM pubset A (/IMPORT-PUBSET) Update user catalog: Add users which were added to Host 1 during the crash procedures being taken on Host 2; evaluate information in the file SYSDAT.HIPLEX.USERS on the SM pubset A “Mount” file system from Host 1 using the POSIX installation program (use SYSDAT.POSIX-BC.FSLIST file) Bring BS2000-UFS in the environment SM pubset A and C under HSMS control, if this hasn’t already happened.
The HSMS administrator must take the following measures:
Enter HSMS statement RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE for SM pubset A to be able to process the requests initiated on Host 1 before the system failure.

Organization of the file system

The following illustrates the various ways in which the POSIX file system can be organized, to guarantee HIPLEX support for a part of the file system tree.

Figure 29: POSIX-/HSMS mechanism: Client file systems on SM pubsets

The SF pubset contains the root file system and the file system container for USER 1 and USER 2, since these are “non-HIPLEX clients”.

The file system container for USER 3 is located on SM pubset A. The file system container for the normal users are stored on SM pubset B. To do this you must keep to the following conventions:

• If the file system container is located on SM pubset A, the corresponding file system must be mounted under the branch /SM-PUB/A.

• If the file system container is located on SM pubset B, the corresponding file system must be mounted under the branch /SM-PUB/B.

The following diagram shows how the POSIX data and HSMS metadata can be accessed during normal system operation.

Figure 30: Access to POSIX files and HSMS metadata before a system failure

The UNIX file system on SM pubset A is mounted on Host 1. The UNIX file system on SM pubset B is mounted on Host 2.

After a system failure the system administrator must carry out the measures described in section "BS2000-UFS: Measures to be taken after a system failure". This allows activities to be transferred to a substitute host.
POSIX data and metadata can also be accessed in the way shown in the following diagram.

Figure 31: Access to POSIX files and HSMS metadata after a system failure

The UNIX file system on SM pubset A is now no longer mounted on Host 1, it is instead mounted on Host 2. 

Remote workstations

Environment description

Figure 32: HSMS in a HIPLEX for workstations with NFS access: data/metadata stream

• The HIPLEX system includes several hosts.

• Host 1 makes available HSMS functions for the remote workstation WS1.

• The system administrator must save the data for all file systems of the workstations on a single SM pubset (shared or exclusive), in this example on SM pubset A.

• The affected SM pubset (here A) must be brought under HSMS control
  (//CREATE-SM-PUBSET-PARAMETERS, HSMS 1 for A).

• Several archives must be stored on SM pubset A.

• WS1 in the SM pubset environment must be brought under the control of HSMS 1
  (//MODIFY-NODE-PARAMETERS).

• You access the WS1 data with NFS - depending on the type of workstation (see figure 32).

• If you want to be able to access WS1 via NFS (see figure 32), the file system of WS1 must be mounted under /HSMS in the POSIX root file system. In addition, BS2000-UFS must also be brought under HSMS control
  (//MODIFY-NODE-PARAMETERS).

During normal operation HSMS saves the associated metadata in the environment in which the WS1 data is also saved. 

Measures to be taken after a system failure

After a system failure on Host 1, Host 2 is the designated substitute host. Once the following measures have been taken HSMS 2 can continue the work of HSMS 1.

Measures to be taken on Host 1	Measures to be taken on substitute host i.e Host 2
System failure -> Host 1 is no longer available
	The system administrator must take the following measures:
	/CREATE-VIRTUAL-HOST Define the virtual host. (This BCAM command can be entered when starting HIPLEX – or in other words before the system failure.) /BCACT HOST=Host 2 Activates the virtual host which must now replace Host 1. After the system failure the system administrator calls this procedure.) In a TCP/IP network the address of the recently activated host is distributed transparently. Import SM pubset A (/IMPORT-PUBSET) For workstations with access via NFS: Using NFS “mount” remote workstations, which are managed by Host 1 under /HSMS. Load and start HSMS, if HSMS is not yet running
	The HSMS administrator must take the following measures:
	Enter the HSMS statement RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE for SM pubset A, this allows you to process the requests, which were initiated on Host 1 before the system failure.

Figure 33: HIPLEX for workstations with NFS access: Accessibility of data/metadata after a system failure

Measures to be taken after recovery from a system failure

After Host 1 is back up and running, the HSMS activities for the workstation node files can be transferred back to the original host. To do this the following measures must be taken: 

Measures to be taken on Host 1	Measures to be taken on substitute host i.e Host 2
Reason for system failure eliminated -> Host 1 is available again
	The system administrator must take the following measures:
	Only for workstations with access via NFS: Using NFS “unmount” remote file systems which are saved on SM pubset A. /CREATE-VIRTUAL-HOST Define the virtual host. (This BCAM command can be entered when starting HIPLEX – or in other words before the system failure.) /BCACT HOST=Host 2 Activates the virtual host which must now replace Host 1. After the system failure the system administrator calls this procedure.) In a TCP/IP network the address of the recently activated host is distributed transparently. /BCDAC HOST=Host 2 Deactivate the virtual host and return to the original host, Host 1. Export SM pubset A (/EXPORT-PUBSET)
The system administrator must take the following measures:
Import SM pubset A (/IMPORT-PUBSET) Only for workstations with access via NFS: Using NFS “mount” remote workstation which are to be managed by Host 1 under /HSMS.
The HSMS administrator must take the following measures:
Enter HSMS statement RECOVER-REQUESTS REQUEST-DATA-ORIGIN=*NODE for SM pubset A to be able to process the requests initiated on Host 1 before the system failure.

 

Organization of the file system

There are no special prerequisites to be taken into account when organizing workstation file systems which are accessed without the use of NFS.

However, for workstations that are accessed using NFS, the workstation file systems must be mounted under /HSMS in the POSIX root file system.

The following diagram shows how the file systems for the workstations WS1 and WS2 must be organized so that HIPLEX support can be guaranteed.

Figure 34: HIPLEX for workstations with NFS access: Access to metadata before a system failure

Workstation WS1 is mounted on Host 1 and workstation WS2 on Host 2. HSMS accesses both workstations using NFS.

After a system failure on Host 1 the system administrator must take the measures described in "Remote workstations: Measures to be taken after a system failure" so that the activities can be transferred to a substitute host. Once transferred, the data for workstation WS1 and the HSMS metadata are accessed as shown in the following diagram.

Figure 35: HIPLEX for workstations with NFS access: Access to metadata after a system failure

Workstations WS1 and WS2 which are managed by HSMS are now both mounted on Host 2.