Cloudera Machine Learning requirements
To launch the Cloudera Machine Learning service, the host must meet several requirements. Review the following CML-specific software, NFS server, and storage requirements.
- The installed OpenShift Container Platform must be version 4.5.
- CML assumes it has
cluster-adminprivileges on the OpenShift cluster.
- Storage: (See Get started with OpenShift requirements, below)
- 4 TB of persistent volume block storage per ML Workspace.
- 1 TB of NFS space recommended per Workspace (depending on user files).
- Access to NFS storage is routable from all pods running in the OpenShift cluster.
- For monitoring, recommended volume size is 60 GB.
- A block storage class must be marked as default in the OpenShift cluster. This may be
rook-ceph-block, Portworx, or another storage system. Confirm the storage class by listing the storage classes (run oc get sc) in the Openshift cluster, and check that one of them is marked
- If external NFS is used, the NFS directory and assumed permissions must be those of
cdswuser. For details see Using an External NFS Server in the Related information section at the bottom of this page.
- If CML needs access to data on the CDP Private Cloud Base cluster, then the user must be authenticated using Kerberos and must have Ranger policies set up to allow read/write operations to the default (or other specified) database.
- Ensure that Kerberos is enabled for all services in the cluster. Custom Kerberos principals are not currently supported. For more information, see Enabling Kerberos for authentication.
- Forward and reverse DNS must be working.
- DNS lookups to sub-domains and the ML Workspace itself should work.
- In DNS, wildcard subdomains (such as
*.cml.yourcompany.com) must be set to resolve to the master domain (such as
cml.yourcompany.com). The TLS certificate (if TLS is used) must also include the wildcard subdomains. When a session or job is started, an engine is created for it, and the engine is assigned to a random, unique subdomain.
- The external load balancer server timeout needs to be set to 5 min. Without this, creating a project in an ML workspace with git clone or with the API may result in API timeout errors. For workarounds, see Known Issue DSE-11837.
- If you intend to access a workspace over https, see Deploy an ML Workspace with Support for TLS.
- For non-TLS ML workspaces, websockets need to be allowed for port 80 on the external load balancer.
- Only a TLS-enabled custom Docker Registry is supported. Ensure that you use a TLS certificate to secure the custom Docker Registry. The TLS certificate can be self-signed, or signed by a private or public trusted Certificate Authority (CA).
- Due to a Red Hat issue with OpenShift Container Platform 4.3.x, the
image registry cluster operator configuration must be set to
- Check if storage is set up in the cluster image registry operator. See Known Issues DSE-12778 for further information.
For more information on requirements, see CDP Private Cloud Base Installation Guide.
filesystemvolumeModes of storage. Ensure that a block storage class is set up. The exact amount of storage classified as block or filesystem storage depends on the specific workload used:
- Machine Learning workload requirements for storage largely depend on the nature of your machine learning jobs. 4 TB of persistent volume block storage is required per Machine Learning Workspace instance for storing different kinds of metadata related to workspace configuration. Additionally, Machine Learning requires access to NFS storage routable from all pods running in the OpenShift cluster (see below).
- Monitoring uses a large Prometheus instance to scrape workloads. Disk usage depends on scale of workloads. Recommended volume size is 60 GB.
|Local Storage (for example, ext4)||Block PV (for example, Ceph or Portworx)||NFS (for ML user project files)|
|Control Plane||N/A||250 GB||N/A|
|CML||N/A||4 TB per workspace||1 TB per workspace (dependent on size of ML user files)|
Cloudera Machine Learning (CML) requires NFS for storing project files and folders. An internal user-space NFS server can be deployed into the cluster which serves a block storage device (persistent volume) managed by the cluster’s software defined storage (SDS) system, such as Ceph or Portworx. This is the recommended option for CML in private cloud. Alternatively, the NFS server can be external to the cluster, such as a NetApp filer that is accessible from the private cloud cluster nodes. NFS storage is to be used only for storing project files and folders, and not for any other CML data, such as PostgreSQL database and LiveLog.
CML does not support shared volumes, such as Portworx shared volumes, for storing project files. A read-write-once (RWO) persistent volume must be allocated to the internal NFS server (for example, NFS server provisioner) as the persistence layer. The NFS server uses the volume to dynamically provision read-write-many (RWX) NFS volumes for the CML clients.