11. HPC Platforms, Scheduling and Cloud Deployment

Introduction and Context

High-performance computing (HPC) is not defined only by the speed of an individual processor. Its effectiveness depends on the coordinated operation of compute nodes, high-speed networks, storage systems, operating environments, workload managers, software libraries, and users. A modern HPC platform is therefore an engineered ecosystem in which computational work is submitted, scheduled, executed, monitored, and evaluated according to resource requirements and organizational priorities.

Earlier chapters examined parallel algorithms, performance measurement, distributed execution, and accelerated computing. This chapter moves from computational techniques to the infrastructure on which those techniques operate. A well-designed parallel program can perform poorly if it is placed on an unsuitable node, assigned insufficient memory, delayed by an inappropriate queue policy, or slowed by contention in shared storage. Conversely, a carefully configured platform can make a modest cluster highly productive.

The central operational problem is resource coordination. Several users may request processors, accelerators, memory, storage, and long execution times simultaneously. The platform must decide which job runs, where it runs, how resources are isolated, and how failures are handled. These decisions are made through workload managers and schedulers. Containers improve reproducibility by packaging applications and dependencies, while orchestration systems automate deployment and lifecycle management. Cloud platforms extend HPC capacity elastically, but introduce new concerns involving cost, data movement, security, and service selection.

This chapter develops a practical framework for configuring and using HPC platforms. It compares on-premises, cloud, hybrid, and serverless models and explains why deployment decisions should be based on workload characteristics rather than technology preference alone.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Describe the architecture and operating roles of HPC clusters.

2. Explain how workload managers, resource schedulers, queues, and job arrays operate.

3. Submit, monitor, prioritize, and troubleshoot batch and interactive jobs.

4. Distinguish containers from virtual machines and explain their use in HPC.

5. Describe the role of orchestration systems in distributed and cloud-native workloads.

6. Compare on-premises, cloud, hybrid, and serverless deployment models.

7. Select an appropriate deployment strategy using performance, cost, governance, and data considerations.

8. Identify operational, security, ethical, and sustainability risks in HPC deployment.

The HPC Platform as an Operating Environment

An HPC platform normally contains a login or access layer, a management layer, compute nodes, storage, and a network fabric. Users connect to login nodes to edit files, compile software, prepare job scripts, and inspect results. Heavy computation should not ordinarily be performed on these nodes because their resources are shared and their purpose is access and administration.

Compute nodes execute user jobs. They may be homogeneous, containing similar CPUs and memory capacities, or heterogeneous, combining general-purpose nodes with GPU, high-memory, many-core, or visualization nodes. A heterogeneous cluster requires accurate resource descriptions so that jobs are directed to suitable hardware. A job requiring a GPU cannot be treated as an ordinary CPU job, even if both are submitted through the same interface.

The management layer maintains information about node health, software environments, users, accounts, reservations, and policies. A scheduler uses this information to make placement decisions. Storage commonly includes a home or persistent file system, a shared project space, and node-local temporary storage. The distinction matters: home directories are suitable for source code and modest outputs, while high-throughput applications often require parallel file systems or local scratch space.

The interconnection network influences application performance. Latency-sensitive message-passing programs benefit from low-latency, high-bandwidth fabrics, whereas loosely coupled workloads may tolerate conventional Ethernet. Network topology, oversubscription, routing, and contention can affect performance even when processors are powerful.

A useful abstraction is to treat the cluster as a pool of managed resources. These resources include CPU cores, accelerators, memory, local storage, network bandwidth, and sometimes licenses for proprietary software. A job is a request for a particular combination of these resources for a specified duration. The platform attempts to satisfy the request while maintaining fairness and high utilization.

Workload Managers and Scheduling Decisions

A workload manager combines job submission, queue management, resource allocation, execution control, accounting, and monitoring. Common systems include Slurm, PBS Professional, OpenPBS, and LSF. Their commands and configuration details differ, but their conceptual functions are similar.

A scheduler must answer four questions: which job should run, when should it run, on which nodes should it run, and for how long may it use them? The answers depend on policy and prediction. Users usually provide a wall-time estimate, resource quantities, a queue or partition, and sometimes a priority or project account. The scheduler uses these values to plan allocations.

A queue, partition, or class groups jobs with common properties. For example, a cluster may provide short, standard, GPU, high-memory, and preemptible partitions. Queue design prevents a single workload type from dominating all resources. A short-job queue can improve responsiveness, while a long-job queue can accommodate simulations that cannot complete quickly.

Scheduling policies commonly combine first-come-first-served ordering, fair-share allocation, job priority, backfilling, reservations, and preemption. Strict first-come-first-served scheduling is simple but can leave resources idle when the next job requires a large contiguous allocation. Backfilling permits smaller jobs to run in available gaps, provided they do not delay a previously reserved job. Fair-share policies adjust priority according to historical resource use, helping prevent a single group from consuming disproportionate capacity.

Preemption allows a higher-priority job to interrupt a lower-priority job. It can improve responsiveness but may waste computation unless jobs support checkpointing or can be safely requeued. Reservations are useful for teaching sessions, demonstrations, maintenance, or time-critical production runs. Every policy involves a trade-off between utilization, predictability, fairness, and administrative complexity.

Batch, Interactive, and Array Jobs

In batch computing, the user submits a script and receives results after the scheduler allocates resources. A typical Slurm script might contain:

```bash

#!/bin/bash

#SBATCH --job-name=simulation

#SBATCH --partition=compute

#SBATCH --nodes=2

#SBATCH --ntasks-per-node=32

#SBATCH --time=02:00:00

#SBATCH --mem=120G

#SBATCH --output=logs/%x-%j.out

module load gcc openmpi

srun ./solver input.dat

```

The directives communicate requirements; they do not guarantee that the application will use resources efficiently. The program must still be configured for the allocated process count, memory, and communication model. Over-requesting resources can increase queue time and reduce cluster utilization. Under-requesting can cause termination, poor performance, or interference with other jobs.

Interactive jobs reserve resources for exploration, debugging, visualization, or iterative development. They are valuable during software development but should not become a substitute for production batch execution. Job arrays represent many related tasks, such as running a model over thousands of parameter combinations. Instead of submitting thousands of independent commands manually, an array identifies an index for each task and allows the scheduler to control concurrency.

Dependencies express relationships among jobs. A post-processing job may be released only after a simulation succeeds; a visualization job may depend on completion of several array elements. These relationships create workflows without requiring a user to monitor every step manually.

Monitoring and Accounting

Professional HPC use requires more than submission. Users should inspect pending reasons, allocated resources, elapsed time, memory consumption, CPU utilization, accelerator utilization, and exit status. Typical commands include `squeue` for queue inspection, `sacct` for accounting, `scontrol` for detailed job information, and `sstat` for running-job statistics in Slurm environments.

Accounting data supports capacity planning and chargeback or showback. A project may be charged according to core-hours, GPU-hours, memory allocation, or storage consumption. However, accounting based only on requested resources can encourage over-requesting. More useful systems compare requested, allocated, and actually consumed resources.

Resource Allocation as a Performance Problem

Scheduling and performance are connected. A parallel job may request 128 cores but scale effectively to only 40. The remaining cores are then reserved but underused. Conversely, a memory-bound application may require fewer cores but substantial memory bandwidth. The correct request reflects the application’s resource profile rather than an aspiration for maximum parallelism.

A practical process begins with a small benchmark. The user measures execution time, memory usage, communication behavior, and accelerator utilization at several scales. The resulting evidence informs a realistic wall-time and resource request. Requests should include a safety margin, but excessive margins should be avoided.

Placement also matters. Some applications benefit from a single node because communication is frequent; others require multiple nodes. CPU binding and process affinity can prevent operating-system migration from disrupting cache locality. NUMA-aware placement is important when memory access time differs between processor sockets. GPUs may require explicit allocation and visibility settings so that multiple jobs do not compete for the same device.

Common operational failures include requesting the wrong partition, omitting a required accelerator, using a shared file system for temporary high-volume I/O, assuming that allocated CPUs automatically imply efficient threading, and setting a wall time so short that a nearly completed job is terminated. These are configuration and modeling errors, not merely scheduler problems.

Containers and Reproducible Execution

An HPC application depends on compilers, numerical libraries, runtime libraries, system packages, and configuration files. Rebuilding this environment on another cluster can be difficult. Containers address the problem by packaging an application and much of its user-space environment into an image.

A container is not the same as a virtual machine. A virtual machine emulates or exposes a complete guest operating system through a hypervisor. A container generally shares the host kernel while isolating processes, files, and namespaces. Containers are usually lighter than virtual machines, although their security and portability depend on implementation and configuration.

Docker popularized container workflows, but HPC sites often use Apptainer or Singularity because these tools support unprivileged execution and integrate more naturally with shared clusters. A typical workflow builds or obtains an image, verifies its provenance, transfers it to an approved registry or image store, and executes it with selected host directories and devices exposed.

Containers improve reproducibility, but they do not automatically improve performance. MPI communication, GPU access, file-system mounts, and CPU affinity require explicit integration with the host platform. A container may also conceal inefficient libraries or include incompatible drivers. Images should be versioned, minimal, scanned for vulnerabilities, and built from trusted sources. Reproducibility requires recording the image digest, application version, input data, command line, and relevant scheduler settings.

Orchestration Systems and Workflow Automation

A workload scheduler allocates resources for jobs on an HPC platform. An orchestration system manages the lifecycle and interaction of services, containers, and workflows. Kubernetes is the best-known example. It schedules containers into pods, provides service discovery, supports scaling, and replaces failed instances. Other workflow technologies coordinate data pipelines, scientific stages, dependencies, and retries.

HPC schedulers and Kubernetes are not interchangeable. Traditional tightly coupled MPI applications often require specialized networking, topology awareness, and batch allocation. Kubernetes is well suited to services, elastic microservices, preprocessing, notebooks, APIs, and loosely coupled tasks. Extensions and integrations allow Kubernetes to manage some HPC workloads, but introducing an orchestration layer adds operational complexity.

A useful architecture may combine systems. A conventional scheduler can manage large MPI simulations, while Kubernetes hosts dashboards, experiment-management services, model APIs, and workflow controllers. Containers provide a common packaging format, but resource governance must remain explicit across both environments.

Workflow automation is particularly valuable when an analysis includes data staging, preprocessing, simulation, validation, post-processing, and archival. Declarative workflow definitions make dependencies visible and support retries, provenance, and reproducibility. However, automated retries can duplicate expensive work or hide persistent failures. Workflows should therefore distinguish transient infrastructure errors from deterministic application errors.

Deployment Models: Choosing Where HPC Runs

On-Premises Clusters

An on-premises cluster is owned or controlled by the institution. It offers predictable hardware, direct control over networking and data governance, and potentially lower marginal cost for sustained workloads. It requires capital investment, system administration, cooling, power, physical security, hardware replacement, and capacity planning. Capacity is fixed for long periods, so an institution must estimate demand accurately.

On-premises deployment is attractive when workloads are steady, data is sensitive or very large, specialized hardware is required, or the organization already possesses operational expertise. Its weaknesses become visible during demand spikes, procurement delays, and hardware failures.

Public Cloud HPC

Cloud providers offer configurable virtual machines, accelerator instances, managed storage, high-speed networking, and infrastructure APIs. Capacity can be acquired on demand and released after use. This elasticity is valuable for burst workloads, experiments, and organizations that cannot justify permanent infrastructure.

Cloud cost is multidimensional. Charges may include compute time, storage capacity, input/output operations, data transfer, managed services, and licenses. A short computation may be inexpensive, but repeatedly moving terabytes into and out of the cloud can dominate the bill. Cloud instances also vary in processor generation, network performance, and availability.

Spot or preemptible capacity can reduce cost for checkpointable workloads. It is inappropriate for jobs that cannot tolerate interruption. Cloud deployment should include budgets, tagging, quotas, automated shutdown, and cost monitoring from the beginning rather than after expenditure becomes difficult to control.

Hybrid HPC

A hybrid model combines local infrastructure with cloud resources. Local clusters can serve predictable baseline demand, while cloud capacity absorbs peaks or provides specialized accelerators. Hybrid operation requires identity federation, compatible software environments, secure networking, data-transfer mechanisms, and a policy for deciding which jobs move to the cloud.

Hybrid deployment is not automatically flexible. If data must be copied repeatedly, transfer time and egress cost may eliminate the benefit of cloud elasticity. A better strategy is often to move computation toward the data, cache reusable datasets, and send only compact results across environments.

Serverless and Event-Driven Computing

Serverless platforms execute functions or managed tasks without requiring users to administer servers. They are useful for event-driven preprocessing, metadata extraction, validation, lightweight inference, and orchestration components. They are generally less suitable for long-running, tightly coupled MPI jobs, large-memory simulations, or workloads requiring specialized interconnects.

Serverless computing can complement HPC rather than replace it. For example, an uploaded dataset may trigger a serverless validation function, which then submits a batch job to an HPC cluster. The result can trigger post-processing and notification. Limits on execution duration, memory, local storage, concurrency, and hardware access must be considered.

A Decision Framework for Deployment

Deployment selection should begin with workload characterization. Important dimensions include parallelism, duration, memory, accelerator requirements, data volume, data sensitivity, burstiness, tolerance of interruption, software licensing, latency requirements, and expected repetition.

A sustained, predictable CPU workload with highly sensitive data may justify on-premises capacity. A sporadic GPU workload may be better placed in the cloud. A data-intensive institutional workload may use local storage and burst only compute to a compatible cloud environment. A preprocessing trigger may be serverless even when the principal simulation is scheduled through Slurm.

The decision should evaluate at least five dimensions:

• Performance: processor, memory, network, storage, and accelerator behavior.
• Economic efficiency: total cost of ownership, utilization, transfer charges, licensing, and staff effort.
• Governance: privacy, residency, access control, auditability, and contractual obligations.
• Operational resilience: backup, failure recovery, monitoring, maintenance, and portability.
• Sustainability: energy efficiency, hardware utilization, cooling, and unnecessary data movement.

Benchmarking is preferable to relying on vendor specifications. A representative pilot should measure not only runtime but also queue delay, data-transfer time, storage behavior, failure recovery, and reproducibility.

Applied Case: Hybrid Genomic Analysis Platform

Background

This illustrative case concerns a university research group processing genomic datasets. The group performs a stable weekly workload and experiences occasional demand from collaborative projects. Data contains controlled-access human information, and only approved personnel may access raw files.

Situation and Problem

The local cluster provides CPU nodes and a parallel file system but has limited GPU capacity. During collaboration periods, the queue becomes long. Researchers consider moving all work to the public cloud, but raw data is large and governance officers are concerned about uncontrolled copying and unclear retention.

Analysis

The workload consists of three stages. Quality-control and alignment are CPU-intensive and repeatedly access large datasets. Variant-calling includes a GPU-accelerated tool for selected samples. Reporting and dashboard generation are lightweight and event-driven. The first stage is predictable and data-local; the second is bursty; the third does not require a permanent server.

An all-cloud strategy would provide elastic GPUs but would incur transfer costs and require careful compliance configuration. An all-local strategy would preserve data locality but produce unacceptable delays during peaks. The workload therefore supports a hybrid architecture.

Strategy and Solution

Raw data and routine CPU processing remain on the institutional cluster. Approved derived subsets are encrypted and transferred to a controlled cloud project for burst GPU processing. Identity federation, role-based access, private networking, encryption in transit and at rest, and audit logging are required. Container images are signed and versioned so that local and cloud executions use the same software environment.

A scheduler submits ordinary jobs locally and marks burst candidates according to queue delay and deadline. Checkpoints permit cloud jobs to resume after preemption. A workflow engine records dependencies and provenance. Serverless functions validate metadata, initiate approved transfers, and notify researchers when outputs are ready. Automatic expiration policies remove temporary cloud copies after verification.

Outcome

The architecture preserves local control of sensitive raw data while providing additional accelerator capacity when needed. Its success depends not merely on cloud access but on data classification, transfer policy, reproducible containers, cost limits, and measurable exit criteria. The group monitors runtime, queue delay, transfer volume, GPU utilization, failed-job rate, and cost per completed sample.

Learning Points

The case demonstrates that deployment is a workload-design decision. Hybrid systems are effective when boundaries between local and cloud processing are explicit. Security controls, scheduling policy, and data lifecycle management are as important as hardware selection.

Risks, Governance, and Professional Practice

Security begins with least privilege. Users should receive only the permissions required for their projects, and service accounts should not be shared. Secrets must not be placed in job scripts or container images. Images, packages, and workflow definitions should be scanned and updated. Login nodes require multi-factor authentication where available, restricted access, patching, and monitoring.

Data governance includes classification, retention, consent, residency, encryption, access logging, and secure deletion. Research involving personal, medical, or proprietary data may require institutional review and contractual controls. Reproducibility also has an ethical dimension: results should be traceable to software versions, input data, parameters, and execution environments.

Schedulers can reproduce institutional inequities if priority policies consistently favor well-funded projects or technically sophisticated users. Transparent allocation rules, accessible documentation, usage reporting, and appeals processes support procedural fairness. Sustainability requires avoiding unnecessary over-allocation, using efficient hardware, consolidating data movement, and measuring energy where feasible.

Common mistakes include treating cloud capacity as unlimited, selecting hardware from peak specifications rather than benchmarks, ignoring queue time in cost comparisons, running production work interactively, storing temporary files permanently, failing to checkpoint long jobs, and assuming that a container guarantees portability. Administrative policies should be documented and tested through incident response exercises.

Current Developments and Emerging Directions

HPC platforms are increasingly heterogeneous, combining CPUs, GPUs, specialized accelerators, high-bandwidth memory, and programmable network devices. Scheduling systems are consequently becoming more topology-aware and capable of describing complex resource relationships.

Cloud providers and institutions are developing composable infrastructure, in which compute, memory, accelerators, and storage can be assembled more dynamically. Kubernetes-based systems are expanding in AI, data engineering, and service-oriented scientific workflows, while traditional batch schedulers remain central for tightly coupled simulation.

Policy-driven scheduling is also becoming more sophisticated. Machine-learning methods may predict job duration, detect anomalous behavior, or improve placement, but automated decisions must be explainable and monitored. Energy-aware scheduling may shift flexible jobs to efficient nodes or lower-carbon periods, provided that scientific deadlines and fairness are preserved.

The growth of reproducible research is encouraging software bills of materials, signed images, workflow provenance, and portable execution specifications. These developments do not eliminate platform differences, but they make differences measurable and migration more controlled.

Best Practices for HPC Platform Use

1. Characterize the workload before selecting hardware or deployment location.

2. Request realistic resources and validate requests with benchmark data.

3. Use batch scripts for production and interactive allocations for development.

4. Store temporary, high-volume data on suitable scratch storage.

5. Record software versions, container digests, parameters, and input identifiers.

6. Use checkpoints for long, expensive, or preemptible jobs.

7. Monitor actual CPU, memory, I/O, and accelerator utilization.

8. Apply quotas, budgets, tags, and automatic cleanup in cloud environments.

9. Protect credentials, restrict access, and audit sensitive data.

10. Evaluate total workflow performance, including queue delay and data movement.

11. Test failure recovery rather than assuming that infrastructure is reliable.

12. Document allocation policies so that users can plan and use resources fairly.

Chapter Summary

An HPC platform is an integrated environment of compute nodes, networks, storage, software, access controls, and management services. Workload managers allocate these resources through queues, priorities, fair-share policies, backfilling, reservations, and sometimes preemption. Effective users submit realistic resource requests, distinguish batch from interactive work, exploit job arrays and dependencies, and monitor actual utilization.

Containers improve portability and reproducibility, but require careful integration with MPI, GPUs, storage, security, and host libraries. Orchestration systems manage containerized services and workflows, yet they complement rather than universally replace traditional HPC schedulers. On-premises platforms provide control and predictable capacity; cloud platforms provide elasticity; hybrid models combine baseline capacity with burst resources; and serverless systems suit event-driven supporting tasks. The appropriate choice depends on workload behavior, data movement, governance, cost, performance, resilience, and sustainability.

Key Terms

HPC cluster: A coordinated collection of computing nodes used to execute demanding workloads.

Compute node: A machine allocated to execute user applications.

Workload manager: Software that submits, controls, monitors, and accounts for jobs.

Resource scheduler: The component that decides when and where jobs receive resources.

Queue/partition: A policy-defined group of resources and jobs with common characteristics.

Backfilling: Scheduling smaller jobs into available gaps without delaying a reserved job.

Fair-share scheduling: Priority adjustment based partly on historical resource consumption.

Preemption: Interrupting or suspending a lower-priority job for another job.

Job array: A collection of similar indexed jobs submitted and controlled as one unit.

Job dependency: A condition linking the execution of one job to another job’s status.

Wall time: The maximum elapsed time requested for a job.

Container: An isolated user-space execution environment sharing the host kernel.

Container image: A packaged, versioned filesystem and metadata used to create containers.

Orchestration: Automated deployment, scheduling, scaling, and recovery of services or containers.

MPI: A programming interface for communication among processes in distributed-memory systems.

Hybrid deployment: Use of local and external infrastructure within one operational strategy.

Serverless computing: Event-driven execution in which infrastructure management is abstracted from the user.

Data locality: The principle of placing computation near the data it repeatedly accesses.

Checkpointing: Saving execution state so that a job can resume after interruption.

Total cost of ownership: The complete cost of acquiring, operating, supporting, and retiring a platform.

Review Questions

Short Answer Questions

1. What functions are normally provided by an HPC workload manager?

2. Why should heavy computation generally not be performed on a login node?

3. Define backfilling and explain its scheduling benefit.

4. How does a container differ from a virtual machine?

5. State two situations in which serverless computing can complement HPC.

Long Answer Questions

1. Explain the architecture of an HPC cluster and the roles of compute, storage, networking, and management layers.

2. Discuss how fair-share scheduling, reservations, backfilling, and preemption affect utilization and fairness.

3. Describe a professional workflow for benchmarking, requesting, submitting, monitoring, and improving an HPC job.

4. Compare on-premises, public-cloud, and hybrid HPC deployment models in terms of performance, cost, governance, and resilience.

5. Explain how containers and orchestration systems support reproducible scientific workflows, including their limitations.

Analytical / Application Questions

1. A research group requests 256 CPU cores for every job, although measurements show that performance stops improving after 64 cores. Analyze the consequences and propose a better scheduling and benchmarking strategy.

2. An organization holds sensitive, very large datasets locally but occasionally needs cloud GPUs. Design a hybrid architecture, identifying data-transfer, identity, container, checkpointing, cost, and compliance controls.

3. A cloud-based workflow is cheaper per compute hour than a local cluster but takes many hours to transfer data and frequently exceeds its budget. Determine which measurements and policy changes should be used to decide whether the workflow should remain in the cloud.

22. Multiple Choice Questions with Answers

Question 1

Which scheduling technique allows a smaller job to use an otherwise idle resource gap without delaying a previously planned large job?

A. Preemption

B. Backfilling

C. Serverless execution

D. Containerization

Correct Answer: B. Backfilling

Question 2

A user needs to run thousands of independent parameter combinations using the same program. Which HPC feature is most appropriate?

A. A job array

B. A login-node session

C. A hardware reservation only

D. A virtual machine snapshot

Correct Answer: A. A job array

Question 3

Why can a realistic wall-time request improve cluster operation?

A. It guarantees the job will use every allocated core

B. It removes the need for application benchmarking

C. It helps the scheduler plan resources and reduces unnecessary reservation

D. It automatically converts a serial program into a parallel program

Correct Answer: C. It helps the scheduler plan resources and reduces unnecessary reservation

Question 4

Which statement best describes an HPC container?

A. It is always a complete guest operating system managed by a hypervisor

B. It packages user-space software while generally sharing the host kernel

C. It guarantees identical performance on every cluster

D. It eliminates the need for access control and vulnerability scanning

Correct Answer: B. It packages user-space software while generally sharing the host kernel

Question 5

A tightly coupled MPI application requires low-latency communication and predictable placement. Which deployment concern is most important?

A. Whether the application has a web dashboard

B. Network topology and interconnect performance

C. Whether serverless functions can trigger it

D. The number of container labels

Correct Answer: B. Network topology and interconnect performance

Question 6

Which workload is most suitable for serverless computing?

A. A long-running, tightly coupled MPI simulation

B. A GPU application requiring a specialized interconnect

C. An event-triggered metadata validation task

D. A multi-day job requiring node-local checkpoint storage

Correct Answer: C. An event-triggered metadata validation task

Question 7

A hybrid cloud strategy repeatedly transfers terabytes of raw data for short computations. What is the most likely concern?

A. The scheduler cannot create job arrays

B. Data-transfer time and egress cost may outweigh cloud elasticity

C. Containers cannot be versioned

D. On-premises clusters cannot use encryption

Correct Answer: B. Data-transfer time and egress cost may outweigh cloud elasticity

Question 8

What is the primary purpose of checkpointing a long-running job?

A. To increase the number of login nodes

B. To permit recovery or continuation after interruption

C. To replace resource accounting

D. To prevent all application errors

Correct Answer: B. To permit recovery or continuation after interruption

Question 9

Which measure is most useful when comparing actual resource efficiency of a job?

A. Only the number of requested CPUs

B. Only the advertised peak speed of the processor

C. Actual CPU, memory, I/O, and accelerator utilization

D. The number of users registered on the cluster

Correct Answer: C. Actual CPU, memory, I/O, and accelerator utilization

Question 10

An organization has predictable baseline demand, strict data controls, and occasional GPU peaks. Which strategy is most defensible?

A. Use only serverless functions

B. Use only a permanently oversized local cluster

C. Keep controlled baseline processing locally and burst approved work to cloud GPUs

D. Move all raw data to any public cloud without classification

Correct Answer: C. Keep controlled baseline processing locally and burst approved work to cloud GPUs