Creating Projects for Data Science Teams and Allocating GPUs
PDF of this doc site
- AI Converged Infrastructures
Data Pipelines, Data Lakes and Management
- NetApp AI Control Plane
- Distributed training in Azure - Click-Through Rate Prediction
- Conversational AI using NVIDIA
- Anthos with NetApp
- DevOps with NetApp Astra
Red Hat OpenShift with NetApp
- NetApp Storage Integrations Overview
Solution Validation and Use Cases
- Red Hat OpenShift Virtualization with NetApp ONTAP
- VMware Tanzu with NetApp
- Data Migration and Data Protection
- Oracle Database
- SnapCenter for Databases
- Modern Data Analytics
NetApp Hybrid Multicloud with VMware
- VMware for Public Cloud
- NetApp for GCP / GCVE
- NetApp Hybrid Multicloud with Red Hat OpenShift
- VMware Virtualization for ONTAP
- Virtual Desktops
- Artificial Intelligence
Researchers can submit workloads through the Run:AI CLI, Kubeflow, or similar processes. To streamline resource allocation and create prioritization, Run:AI introduces the concept of Projects. Projects are quota entities that associate a project name with GPU allocation and preferences. It is a simple and convenient way to manage multiple data science teams.
A researcher submitting a workload must associate a project with a workload request. The Run:AI scheduler compares the request against the current allocations and the project and determines whether the workload can be allocated resources or whether it should remain in a pending state.
As a system administrator, you can set the following parameters in the Run:AI Projects tab:
Model projects. Set a project per user, set a project per team of users, and set a project per a real organizational project.
Project quotas. Each project is associated with a quota of GPUs that can be allocated for this project at the same time. This is a guaranteed quota in the sense that researchers using this project are guaranteed to get this number of GPUs no matter what the status in the cluster is. As a rule, the sum of the project allocation should be equal to the number of GPUs in the cluster. Beyond that, a user of this project can receive an over-quota. As long as GPUs are unused, a researcher using this project can get more GPUs. We demonstrate over-quota testing scenarios and fairness considerations in Achieving High Cluster Utilization with Over-Quota GPU Allocation, Basic Resource Allocation Fairness, and Over-Quota Fairness.
Create a new project, update an existing project, and delete an existing project.
Limit jobs to run on specific node groups. You can assign specific projects to run only on specific nodes. This is useful when the project team needs specialized hardware, for example, with enough memory. Alternatively, a project team might be the owner of specific hardware that was acquired with a specialized budget, or when you might need to direct build or interactive workloads to work on weaker hardware and direct longer training or unattended workloads to faster nodes. For commands to group nodes and set affinity for a specific project, see the Run:AI Documentation.
Limit the duration of interactive jobs. Researchers frequently forget to close interactive jobs. This might lead to a waste of resources. Some organizations prefer to limit the duration of interactive jobs and close them automatically.
The following figure shows the Projects view with four teams created. Each team is assigned a different number of GPUs to account for different workloads, with the total number of GPUs equal to that of the total available GPUs in a cluster consisting of two DGX-1s.