To create an on-demand Dask cluster attached to a Domino Workspace, click New Workspace from the Workspaces menu. On the Launch New Workspace dialog select Compute Cluster. Specify the desired cluster settings and launch your workspace. Once the workspace is up, it will have access to the Dask cluster you configured.
Similarly to workspaces, to create an on-demand Dask cluster attached to a Domino job, click on Run from the Jobs menu. On the Start a Job dialog, select Compute Cluster. Specify the desired cluster settings and launch your job. The job will have access to the Dask cluster you configured.
As your command, you can use any Python script that interacts with your Dask cluster.
Domino makes it simple to specify key settings when creating a Dask cluster.
-
Min workers
The number of Dask node workers that will make up the Dask cluster when it starts. If Auto-scale workers is not enabled, this will always be the size of the cluster. The combined capacity of the workers will be available for your workloads.
-
Max workers
The maximum number of Dask node workers that the cluster can reach when Auto-scale workers is enabled. See cluster autoscaling for more details.
-
Cluster size: Limit
The maximum number of workers that you can make available to your cluster is limited by the number of per-user executions that your Domino administrator has configured for your deployment or by the maximum simultaneous executions of the underlying hardware tier used for workers.
In addition to the number of Dask node workers, you will need 1 slot for your cluster master and 1 slot for your workspace or job.
-
Worker hardware tier
The amount of compute resources (CPU, GPU, and memory) that will be made available to each Dask node worker.
-
Scheduler hardware tier
Same mechanics as the worker hardware tier, but applied to the resources that will be available for your Dask cluster scheduler node.
As the name suggests, the Dask scheduler is responsible for determining the worker on which a given task needs to execute. A serialized version of the task is held in the scheduler memory until it is possible to assign the task. This is not necessarily the same amount of memory needed to actually execute the task, but limiting the scheduler memory may prevent work from being scheduled for executions with a very complex task graph.
From a CPU perspective, the needs of the scheduler are likely much lower than your workers.
By default, any hardware tier is available when selecting resources for your executor and scheduler. Domino administrators can optionally configure compute cluster dedicated hardware tiers.
-
Cluster compute environment
Designates your compute environment for the Dask cluster.
-
Dedicated local storage per executor
The amount of dedicated storage in Gigabytes (2^30 bytes) that will be available to each Dask worker.
The storage will be automatically mounted to
/tmp.The storage will be automatically provisioned when the cluster is created and de-provisioned when it is shut down.
WarningThe local storage per worker should not be used for storing any data that must be available after the cluster is shut down.
Cluster auto-scaling allows you to start with a small cluster, which then automatically scales up and down in response to the resource consumption of your workload. This approach utilizes resources more efficiently for bursty workloads.
By default, the cluster size will increase when the average CPU utilization of your workload reaches 80%. A Domino administrator can further refine the auto-scaling settings by including memory utilization or changing the desired scaling thresholds.
Scale down happens if resource utilization is low for a period of at least 5 minutes. Note that depending on the workload that you are executing, scale down may terminate cluster nodes that contain intermediate results which would need to be recomputed.
When provisioning your on-demand Dask cluster, Domino sets up environment variables that hold the information needed to easily connect to your cluster.
The following snippet can be used to connect:
from dask.distributed import Client
import os
...
service_host = os.environ["DASK_SCHEDULER_SERVICE_HOST"]
service_port = os.environ["DASK_SCHEDULER_SERVICE_PORT"]
client = Client(f"{service_host}:{service_port}")
# you should now be connected to the cluster
# Dashboard link from the client object is clickable but will not route in Domino
# Use the embedded Dask Web UI tab instead|
Note
|
|
Printing the client properties in a notebook will give you a Dask dashboard link. While that link is clickable, it will not return an appropriately formatted dashboard link that will work from Domino. Use the embedded Dask web UI as described below instead.
Dask provides a built-in diagnostics dashboard with access to metrics, charts, and other features that helps you understand the components of the Dask cluster and the execution of your workloads.
The dashboard is extremely useful to diagnose performance issues and help improve your understanding of what is happening across your cluster.
Domino makes the Dask web UI available for active on-demand clusters attached to both workspaces and jobs.
|
Note
| In a hybrid Domino deployment, if the data plane is not configured for workspaces, then the user interface link is disabled. An admin can Enable a data plane for workspaces. |
For a more in-depth introduction to the Dask dashboard, refer to the official Dask documentation.
On workspace or job startup, a Domino on-demand Dask cluster with the desired cluster settings is automatically provisioned and attached to the workspace or job as soon as the cluster becomes available.
On workspace or job termination, the on-demand Dask cluster and all associated resources are automatically terminated and de-provisioned. This includes any compute resources and storage allocated for the cluster.
The on-demand Dask clusters created by Domino are not meant for sharing between multiple users. Each cluster is associated with a given workspace or a job instance. Access to the cluster and the Dask web UI is restricted only to users who can access the workspace or the job attached to it. This restriction is enforced at the networking level and the cluster is only reachable from the execution that provisioned it.