Add a compute node.
- Connect a compatible node. It appears in inventory as unallocated.
- Select the node and the cluster it should join.
- Submit the configuration. Storm™ applies the node and cluster-service instructions.
Storm™ for HPC and AI
Put bare-metal clusters
under software control.
Adding a node or changing storage can mean chasing configuration changes across your cluster. Storm™ keeps track of what each component provides and what depends on it, then calculates and coordinates the changes those relationships require. Out-of-band management and SAN-backed net-booting bring supported nodes and clusters online with their operating systems, services, and dependencies configured.
Available for deployment · Supplied controller or installation image
On this pageSee it work
See the operator workflow
Select a node. Configure capacity.
Adding capacity connects a machine to the software and services it needs. Storm™ calculates that configuration from the selected cluster, its dependencies, and its recorded state.
Add a packaged application.
- Choose the application in the marketplace.
- Select Run.
- Storm™ calculates and applies the configuration and dependencies.
See the complete sequence in a live virtual demonstration: unallocated nodes become a configured cluster running a workload. Request a live demo
Configuration that stays connected
Change once. Coordinate dependent systems.
Running a script handles the steps you wrote. Keeping a cluster working also means maintaining the relationships behind those steps. Storm™ records those relationships so a component change can carry through to the configurations that depend on it.
Define what connects.
Each configuration declares what it provides and what it depends on. These
provides:dependsrelationships connect storage, networks, operating systems, and applications.Follow the change.
For example, changing a storage endpoint can affect the nodes and applications that use it. Storm™ follows their declared dependencies to calculate which configurations need to change and in what order.
Apply a calculated sequence.
Defined rules, dependencies, and recorded state determine the configuration work. That is deterministic change: the same inputs produce the same configuration decisions, with approvals and maintenance procedures set for your cluster.
OS and scheduler flexibility
Choose your operating system.
Choose the OS, scheduler, and applications that suit your cluster. Storm™ requires no particular node OS and supports user-defined software stacks. Hardware, drivers, boot support, and software versions are qualified together for your deployment.
NetThunder autoconfiguration
Package it. Deploy it.
Software that can be installed manually can be packaged with its service dependencies and the services they require. NetThunder autoconfiguration uses those definitions to calculate and apply the installation automatically.
Available package examples include Kubernetes, vLLM, Open WebUI, PyTorch, and agentic AI tools, with storage options including WEKA as a root filesystem. Versions, hardware, and integration scope follow the selected deployment.
Introduce supported hardware.
Carry the environment definition into capacity additions, replacements, and technology upgrades. New processors, accelerators, and storage still need compatible firmware, drivers, libraries, and data paths before entering service.
Choose your workload's stack.
Kubernetes can be part of a bare-metal stack. Other schedulers and applications can be packaged with their dependencies. Reconfiguring a node for a different role follows the selected maintenance procedure, including running jobs, membership, identity, and retained data.
Plan restarts, software changes, and return to service
Storm™ can restart bare-metal nodes through BMC control. Compute-interrupting changes require maintenance windows; workload recovery depends on application checkpointing or rerunning jobs. The operating design defines which lifecycle actions are automatic, approval-gated, or operator-driven.
Package definitions, validated software combinations, and scheduler maintenance integrations have separate scopes. A change of stack needs validation before nodes return to service.
You can install software manually. Changes to managed dependencies need coordination, and edits made while the controller is disconnected may not be reflected in its recorded state.
Declarative bare-metal control
From request to running cluster.
Rules, templates, dependencies, and recorded state guide the controller's work. Compute accesses its storage directly, with the management path outside workload execution.
Authorize the request.
Define the workload and the resources Storm™ is permitted to use.
Approved cluster definition
Storm™ cluster management
Resolve the dependencies.
Rules, templates, service dependencies, and required state guide the work.
Infrastructure control pathRealize the cluster.
Coordinate supported bare-metal compute, accelerators, storage, fabrics, and cluster services.
Workloads execute directly on bare metalValidate and record.
Evaluate workload-defined acceptance criteria and record intended, observed, and qualified state.
Recorded state informs the next approved change.
Storm™'s out-of-band control stays outside the workload execution path.
Inspect the detailed architecture
Read the architecture sequence
- Authorize resources: The selected operating environment grants an authorized resource allocation and cluster definition.
- Define the cluster: Storm™ resolves service definitions, rules, templates, requirements, dependencies, and required state.
- Realize bare metal and services: Storm™ coordinates supported compute, accelerators, storage, networks, fabrics, and packaged services.
- Start and validate: Storm™ initializes the cluster, evaluates workload-defined acceptance criteria, and records intended, observed, and qualified state.
- Operate: Storm™ carries approved lifecycle changes forward as stateful cluster work.
New deployments and existing clusters
State-of-the-Art Technology Insertions.
Deploy frontier hardware and software resources in your multi-generational data center and bring compatible existing infrastructure under Storm™ management; hardware agnostic, no runtime or orchestration layer is required.
Define the target environment.
Review the servers, storage, fabrics, applications, and workload requirements. Custom libraries and tunings may need initial integration; once integrated, their configuration can be reused. Keeping existing storage and datasets in place depends on the migration and service scope.
Connect the controller and rebuild.
Use a supplied controller or install a controller image on your own compatible node. Connect the out-of-band management path and prepare the supported root-storage configuration, node identities, and writable state for the selected machines.
Move workloads onto Storm™.
Choose a staged migration or a full rebuild, with maintenance windows planned around your workloads. NetThunder, your team, or both can carry out the integration and transition, according to the services and support you need.
Related products
Choose the scope you need.
Storm™ is the cluster-management platform. It can run your scientific-computing and AI applications without requiring Storm AI Factory™.
Building a cloud service?
CloudSpawn™ adds tenant-environment orchestration and zero-trust architecture, with tenant-held keys and root authority and provider management excluded after handoff. Storm™ and CloudSpawn™ are separate platforms with distinct jobs. When paired, Storm™ manages clusters within the tenant boundary.
Explore CloudSpawn™
Want a complete AI appliance?
Storm AI Factory™ packages an AI operations module with Storm™ infrastructure software in an all-in-one inference or training appliance for on-premises or colocation deployment.
Explore Storm AI Factory™Live virtual demo
See Storm™ build a cluster.
Watch Storm™ take unallocated nodes through configuration to a cluster running a workload. Then discuss your hardware, software stack, and the changes you need to manage.