Out of the box, EF Portal fits the typical HPC setup: one cluster, its scheduler, its queues. That’s the right default: it’s what most HPC teams run, and EF Portal upgrades don’t interrupt jobs in flight. Enterprise deployments often need more, and that’s exactly where NI SP’s HPC Services Team can help. Building the specific capabilities a production environment actually needs, on top of a platform designed to be extended.
Here are three recent builds from our Professional Services team. Each one addresses a specific need that appears when HPC goes from “one cluster, one team” to “the whole company runs on this”: visibility across infrastructure, control over who gets what, and cost that tracks real demand instead of worst-case planning. All three live inside the same portal your team already logs into.
Multi-region visibility
See load and reserved capacity across every cluster you run, and switch to the right region in one click.
Queue governance
Route user groups to the right queues, and let admins move pending jobs between queues in one action.
Windows DCV auto-scaling
Scale the Auto Scaling Groups behind Windows DCV fleets on real session demand, above a guaranteed floor of persistent nodes.
Give one team visibility across every region they run in
Growing HPC estates rarely stay in one place. A department buys capacity in a second AWS region, another business unit spins up a cluster on a different account, and the same organization ends up running HPC in several places, each with its own portal. The answer: a single view of the load and hardware availability of every cluster the organization runs.
The result is a region selector, sitting top-right in the user portal, listing every configured region alongside the resources available there, such as AWS On-Demand Capacity Reservation (ODCR) instance types. EF Portal constantly monitors each remote cluster and can notify users when a specific resource becomes available. When more hardware is free in another region, one click on its label takes the user straight to that region’s portal.
Administrators see the region selector by default, and publishing the Reservation Status service to other user groups extends it to them. The same information is also available as a standalone Reservation Status service in the left menu and as a widget inside the job submission form, so users can check capacity right where they’re already working, before they submit.
Reservation Status service on the left, region selector dropdown on the right.
Each user group can also see only what matters to it: remote cluster data can be filtered by feature, such as GPU, application license tokens, specific hardware, AWS On-Demand Capacity Reservations or reserved instances.
Configuration is just as light on the admin side: administrators add or edit locations from the portal itself, through a dedicated Configuration service, one row per region in the format <AWS region id>:<region name>:<target portal URL>, for example us-east-1:North Virginia:https://us.hpc.mycompany.com.
Additional regions configuration in Multi-region Configuration portal service.
The benefit compounds with scale. A team running two regions gets convenience, while a team running five gets a real capacity-planning tool: instead of five admins independently guessing where the free hardware is, the portal tells everyone at once, and users can move their work to wherever the hardware is available.
Let admins govern queues without slowing anyone down
EF Portal can control user access to scheduler queues through its Users and Groups management. The result: administrators can enforce which queues a given user can submit to, based purely on who they are, including any hardware or dynamic resource restrictions tied to those queues.
A typical setup: standard users are enforced onto queues backed by AWS EC2 On-Demand Capacity Reservation (ODCR) instances, while specific power-user groups get access to privileged queues with more relaxed restrictions. Access follows group membership, managed through the same Users and Groups management administrators already use.
Switching pending jobs from a restricted queue to a more resource-relaxed one, from the All Jobs page (administrators only).
A smaller addition is just as useful. Jobs submitted to restricted queues can wait longer or be affected by incoming priorities and deadlines, so the All Jobs page now includes a Switch queue action, reserved to administrators. Select one or more jobs, choose the target queue from the list of available queues with their current status, and switch them, for example from a restricted queue to a more resource-relaxed one. It’s the kind of button that looks trivial in a screenshot and becomes essential the day a deadline moves up and an admin needs to reprioritize forty pending jobs in one action instead of forty.
Keep Windows DCV fleets sized to actual demand, automatically
Each Windows instance hosts exactly one DCV session, so the size of a Windows DCV fleet maps one-to-one to its number of concurrent users. That makes the balance between infrastructure cost and user demand easy to see and hard to get right: provision for the busiest day and idle instances keep costing money, size for the average and users wait, or resize by hand.
Our HPC Services Team built a dynamic scaling component that keeps Windows DCV fleets matched to demand. It runs inside EF Portal, checks active DCV sessions against the number of DCV nodes every five minutes through the DCV Session Manager Broker, and adjusts the fleet’s desired capacity based on configured thresholds:
- Automatic scale-out when demand increases
- Automatic scale-in when demand decreases
- Preservation of a minimum number of persistent nodes
- Enforcement of a maximum number of nodes (persistent + scaled)
- Safe execution via locking to prevent rapid consecutive changes
- Support for dry-run and active modes
When utilization crosses the upper threshold (and the maximum isn’t reached), it adds nodes. When it falls below the lower one, it removes them, but never below the persistent floor, for example the nodes covered by AWS Reserved Instances or a Savings Plan. If the fleet ever drops below that floor, it brings it back up.
It isn’t tied to one platform. On AWS, the component drives the Auto Scaling Group behind the fleet, and the same logic applies to other hypervisors: we have projects running it on VMware ESX and KVM.
An example configuration:
persistent_nodes=50(the guaranteed floor)scale_out_at=90(add capacity once occupancy crosses 90%)scale_out_nodes=5(how many nodes join per event)max_scaled_nodes=25(the ceiling on scaled-out nodes)scale_in_at=50andscale_in_nodes=5for the reverse.
Every one of these is a configurable parameter, so the same component adapts to fleets of very different sizes. Locking prevents rapid consecutive changes, and dry-run mode lets a team see what the logic would do before it’s allowed to touch real infrastructure.
For teams running Windows DCV at scale, that’s the difference between provisioning for peak demand year-round and paying for a guaranteed floor plus the capacity actual sessions need.
Where this fits in your environment
In practice, a conversation about a use case like these usually starts with a short scoping call. A customer describes what they want to achieve in their environment, and our engineers map it against what EF Portal already exposes (its APIs, its configuration services, its hook system) to find the most direct way to build it.
If any of these sound familiar (multiple clusters with no shared view, queues that need policing by hand, a Windows fleet sized for the worst day instead of the average one), the most efficient path is usually engineering on top of the EF Portal you already run, not a brand-new product.
Get in touch with our HPC Services to talk through your setup, or explore what it’s built on: EF Portal and DCV.
