Deploy DSX Local into IBM Cloud Private

Verify software requirements

DSX Local is delivered as an integrated set of pods and Kubernetes services. DSX pods use kube-dns to discover each other by a fixed name, so it is important that each independent copy of DSX gets deployed in a separate Kube namespace.

Software requirements:

• IBM Cloud Private Version 2.1 or later (GlusterFS requires Version 2.1.0.2 or later)
• IBM Cloud Private CLI
• Kubectl command line
• Shared storage (GlusterFS or NFS)
• Three worker nodes (minimum 8 cores with 32 GB memory)

Install IBM Cloud Private

To install IBM Cloud Private and IBM Cloud Private CLI, see Installing IBM Cloud Private and Installing the IBM Cloud Private CLI.

Install DSX Local on the ICP catalog

To install DSX Local on the ICP catalog, complete the following steps:

1. Enter the following command to ensure that bx pr and docker are authenticated:

   bx pr login -a https://<cluster_ip>:8443 --skip-ssl-validation
   docker login <cluster_name>:8500

2. In the IBM Cloud Private CLI tool, enter the following command:

   shell
   bx pr load-ppa-archive --archive dsx-icp.tar.gz

   where dsx-icp.tar.gz represents the DSX Local installation TAR file.

3. Go to Manage > Helm Repositories and click Sync Repositories.
4. Go to Catalog > Helm Charts and verify that the ibm-dsx-prod chart now displays.
5. In the IBM Cloud Private App Center, select the user and click Configure Client to configure kubectl. Copy and paste into your terminal. The user must have administrator privileges for the following actions.
6. Set the DSX Local images scope to global by entering the following command with kubectl authenticated:

   for image in $(kubectl get images | tail -n +2 |
   awk '{ print $1; }'); do kubectl get image $image -o yaml | sed
   's/scope: namespace/scope: global/' | kubectl apply -f -; done

   Ignore the following warning if you see it: Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply.

Set up storage

Use only one of the following storage options.

Dynamic provisioning

If you are using storage dynamic provisioning with GlusterFS, simply ensure that the appropriate storage class exists. This can be checked with: kubectl get storageclasses | grep glusterfs. If nothing shows up, then consult your cluster administrator about the availability of GlusterFS.

NFS storage

Alternatively, if you are using NFS as the storage type, then you must set up the Persistent Volumes (PVs) using the following information:

• NFS server IP address
• NFS mount path

NFS also requires you to create five directories in the NFS mount path:

• cloudant
• redis
• spark-metrics
• user-home
• influxdb

In the IBM Cloud Private App Center, go to Platform > Storage and create the following PVs with this information:

Cloudant:

General Tab:

Labels:

Parameters:

Redis:

General:

Labels:

Parameters:

Spark Metrics:

General:

Labels:

Parameters:

User Home:

The size of these PVs should adapt to your needs: 100Gi is the minimum size that you should have, and 1TB is the recommended size.

General:

Labels:

Parameters:

Influxdb:

General:

Labels:

Parameters:

Configure DSX Local on ICP

To configure DSX Local on ICP, complete the following steps:

1. In the IBM Cloud Private App Center, go to Manage > Namespaces and click Create Namespace to create a namespace for DSX Local. Ensure the namespace does not exceed 12 characters.
2. Go to Catalog > Helm Charts, and select ibm-dsx-prod, and select Configure.
3. Name the release in Release Name. For the Namespace to deploy to, select the namespace you created.
4. Recommendation: Set the correct amount of worker nodes with the runtimes.workerNodes parameter, and ensure the runtimes.preloadRuntimes is set to true or checked. This will speed up the launch of notebooks after deployment by preloading notebooks images in each worker node.
5. Changing any of the following values is entirely optional. If using Dynamic Provisioning for storage, check the persistence parameters.

Common parameters

Persistence Parameters

If persistence.useDynamicProvisioning has been set to true, the .storageClassName must be set to the appropriate one, unless the default StorageClass provides Dynamic Provisioning already.

If using NFS, the persistence.size of each should match what was created in the previous step if you are not using Dynamic provisioning.

Description:

• *.name The name of the PVC.
• *.persistence.existingClaimName Use an already existing PVC.
• *.persistence.size The minimum size of the persistent volume to attach to/request.

Containers Parameters

Image Parameters

Default parameters values for the images and tag to use in each container in the format <prefix>.<suffix>. This should not be modified, unless there is a specific reason to do so.

Resources Parameters

Default parameters values for the CPU and memory to use in each container in the format <prefix>.<suffix>

Replicas Parameters

In addition to the number of spark workers, there are some services that also offer the option to have several instance of the same service running for High Availability (HA). This can be adjusted depending on workload and resources available:

Deploy DSX Local on ICP

Complete the deployments and when cloudant, redis, usermgmt, dsx-core, and ibm-nginx are up and ready, you can access the DSX Local client UI by visiting: https://MASTER_NODE_IP:dsxservice.externalPort/.

When the namespace has been deployed, you can check the progress in the IBM Cloud Private App Center at Workloads > Deployments.

See IBM Data Science Experience Local for more documentation on how to use DSX Local.

Uninstall DSX Local from ICP

To uninstall DSX Local from ICP, complete the following steps:

1. In the IBM Cloud Private App Center, go to Workloads > Helm Releases and delete the DSX Local helm release. If you get an error then omit it and refresh the page. Wait a few minutes for the components of DSX Local to be removed.
2. Because runtimes and jobs created post-DSX deployment are not deleted with the release, they need to be removed manually. From the Workloads page, delete the remaining deployments, jobs, and cronjobs belonging to the namespace to which DSX Local was installed.
3. If using NFS as the storage, go to your NFS server and delete the content of the directories that were used for the PVs.
4. In some cases, some of the PVs and PVCs might remain behind. Go to Manage > Storage and delete any remaining PVs and PVCs that were associated with DSX.