Admins manage the full lifecycle of Hyperscale infrastructure within the DCT UI, including registering orchestrators, setting defaults, assigning compute, and configuring the infrastructure that a Hyperscale Orchestrator depends on to run jobs.
Registering a Hyperscale Orchestrator
Registering a Hyperscale Orchestrator with DCT is the starting point for administrative setup. As part of registration, the orchestrator is associated with an existing Job Orchestrator to preserve co-location between compute and source data (see Compliance and Hyperscale co-location below).
Mount points are automatically discovered during registration. Within DCT, the only action available for a mount point is "Validate". Configuration and modification of mount points remain the responsibility of Hyperscale Infra and are performed outside DCT.
Engines are handled differently from mount points. If a Hyperscale Orchestrator already has engines attached before registration, those engines are automatically imported into DCT as references. Credentials for those pre-existing engines are not carried over, however; an admin must retroactively add credentials for each imported engine in DCT before it can be used to run jobs. Engines added or moved after registration go through the actions described in Managing the engine pool below.
Connector type and orchestrator scope
A Hyperscale Orchestrator runs in a single connector mode at a time, for example, Oracle. This is a scope restriction worth understanding before provisioning:
-
Running two data types simultaneously, for example, Oracle and MSSQL requires two separate Hyperscale Orchestrators, not one configured for both.
-
An Orchestrator’s connector type can be changed, but it requires restarting the orchestrator infrastructure. Treat this as a planned reconfiguration, not a live toggle between job runs.
Orchestrator-wide defaults
Admins set the base runtime configuration including split size, table-level defaults, and similar settings at the orchestrator level. These defaults apply to every newly created job on that orchestrator, and represent the first tier in the cascading configuration priority described above. Job-level defaults and runtime overrides, set by end users, layer on top of whatever the admin establishes here.
Managing the engine pool
Compute assigned to a Hyperscale Orchestrator is a discrete, dedicated pool, separate from the Compliance Nodes registered to a Job Orchestrator. An engine is not simultaneously shared across both; it belongs to one pool at a time.
Admins move engines between pools directly from the Hyperscale Orchestrator’s Engines table:
-
Import Existing Engine moves an engine from a Job Orchestrator’s pool into the Hyperscale Orchestrator’s pool.
-
Move Engine moves an engine from the Hyperscale Orchestrator’s pool back to a Job Orchestrator’s pool.
Both actions require the engine’s version to be compatible with the target orchestrator type. This gives admins flexibility to reallocate compute as Compliance vs. Hyperscale throughput needs shift, without requiring separate hardware permanently earmarked for each.
Configuring associated infrastructure
Beyond compute, admins configure the supporting infrastructure a Hyperscale Orchestrator depends on, such as staging, to ensure data has a place to land during the unload, mask, and load cycle.
Compliance and Hyperscale co-location
To keep compute co-located with the source data, every connector is already associated with a Job Orchestrator in standard Continuous Compliance. Hyperscale introduces a parallel Hyperscale Orchestrator concept, so to preserve that same co-location guarantee, a Hyperscale Orchestrator must be associated with an existing Job Orchestrator. This association is established during registration (see Registering a Hyperscale Orchestrator above) and is set in the Hyperscale Orchestrator’s settings by a Hyperscale admin.
Enabling end-user opt-in
Running a job on Hyperscale infrastructure requires an explicit opt-in at the job level, covered in the End User section. Admins control this at the permission layer, granting the users or roles who should be able to exercise that opt-in in the first place. This two-part design (admin-granted permission, end-user-expressed intent) prevents jobs from landing on Hyperscale infrastructure by accident.