Prerequisites

For a complete list of the hardware and software requirements for Sandbox, generate the report from Software Product Compatibility Reports. For more information about generating the report, see Hardware and software requirements.

Image storage server requirements

To install and run Sandbox, an image storage server to host the Sandbox artifacts, such as Z system volumes, data sets, Sandbox metadata, must be set up. To transfer volumes images files from the image storage server, or transfer volumes images files to the image storage server, you must use SFTP as the transferring method.

Disk space
  • Sufficient space is needed to hold numerous and potentially large files for extracted IBM® Z volumes.
  • 300 GiB 1 of disk space is needed for ADCD z/OS® V2.4 distribution.
Software requirements
A running SFTP server
SFTP server
Open the firewall port for SFTP commands.

Red Hat OpenShift requirements

Red Hat® OpenShift®
Sandbox is supported in customer managed and IBM Cloud® managed Classic or VPC OpenShift 4.8 clusters running on x86_64 architecture
SecurityContextConstraints
The Sandbox Operator and wazi-sandbox container use a privileged security context constraints (SCC).
Figure 1. Custom SecurityContextConstraints definition
allowHostDirVolumePlugin: true
allowHostIPC: true
allowHostNetwork: true
allowHostPID: true
allowHostPorts: true
allowPrivilegeEscalation: true
allowPrivilegedContainer: true
allowedCapabilities:
- '*'
allowedUnsafeSysctls:
- '*'
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: 'wazi-sandbox-operator allows access to all privileged and host
      features and the ability to run as any user, any group, any fsGroup, and with
      any SELinux context.'
  name: wazi-sandbox-operator
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities: null
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
seccompProfiles:
- '*'
supplementalGroups:
  type: RunAsAny
users:
- wazi-sandbox-operator
volumes:
- '*'
The wazi-sandbox-volume-copy container uses the anyuid SCC or a modified definition.
Figure 2. Custom SecurityContextConstraints definition
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  ranges:
  - max: 2500
    min: 2105
  type: MustRunAs
groups: []
kind: SecurityContextConstraints
metadata:
  name: wazi-sandbox-volume-copy
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- KILL
- MKNOD
runAsUser:
  type: MustRunAsRange
  uidRangeMax: 2500
  uidRangeMin: 2105
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  ranges:
  - max: 2500
    min: 2105
  type: MustRunAs
users:
- wazi-sandbox-volume-copy
volumes:
- '*'
Required resources
The required cluster resources for Sandbox depend on:
  • The cluster storage
  • The number of expected sandbox instances
  • The resource requirements from the emulator machine characteristics and device map file (devmap) for the sandbox instances
  • The size of the z/OS volume files for the sandbox instance

Because the compute resources for the cluster storage depend on the specific storage driver and configuration, those compute resources are excluded from the calculations here. The cluster must have sufficient extra compute resources to manage the required storage. Contact your cluster administrator or cloud provider if you need help on these requirements.

Overall, the cluster sizing includes the following requirements:
  • The base resource requirements for control nodes
  • Variable requirements for worker nodes that satisfy the scheduling capacity for the expected number of instances including storage, and compute requirements for that storage

The following tables assume that the devmap specifies P processors including both CP and zIIP and M GiB of memory, and the z/OS volume files are V GiB in total.

Table 1. Cluster base resources
  Count Memory (GiB)
Control nodes 3 16/node
Table 2. Scheduling capacity for worker nodes
Software Memory (GiB) CPU (cores) Ephemeral storage (GiB) Persistent storage (GiB)
1 single sandbox instance M + 2 P + 1 2 V * 1.125

At a minimum, worker nodes must meet the scheduling requirements for a single instance. To support multiple instances, scale up the worker nodes.

For example, for the Extended ADCD image available with Sandbox, M = 8 GiB, P = 3, and V = 270 GiB.

To run each instance, the cluster requires worker nodes with a capacity of at least 10 GiB memory, 4 cores, 2 GiB of ephemeral storage, and approximately 304 GiB of persistent storage.

To run 5 instances, the cluster requires worker nodes with a total capacity of at least 50 GiB memory, 20 cores, 480 GiB of ephemeral storage, 1520 GiB of persistent storage, and also any extra compute capacity to support that storage. This might be 5 nodes each with a capacity for a single sandbox instance, or 2 with a capacity for 3 instances, or a single large node with a capacity for all 5.

Note: Due to the requirements of setting up and running the zPDT® emulator, Sandbox system container requires privileged access. This elevated access might cause security risks because the access might be knowingly or unknowingly used to affect the hosting system. To avoid the security risks, you can run development and test workloads like Sandbox, and production workloads in a separate cluster. Also, the cluster administrators need to be informed about the privileged access that is granted to the Sandbox service account and Sandbox system containers that are executed by the access. For more information about securing your cluster, see Kubernetes documentation.

Installation packages

Ensure that you download the installation packages of Sandbox that are specified in Downloading prerequisites and instructions.

1 GiB means 1,073,741,824 bytes.