Configure
Nodes
How Easy Hybrid DR uses Management Servers, Replication Nodes, Prep Nodes, and DeDup Nodes across protected and recovery sites.
- Product
- Easy Hybrid DR
- Version
- v2.0.3
- Last updated
- Updated
- Reading time
- 3 min read
Nodes are the deployable building blocks of Easy Hybrid DR. The Management Server handles orchestration and metadata, Replication Nodes move and validate data, Prep Nodes prepare Windows recoveries, and optional DeDup Nodes reduce repetitive data transfer.
Component roles
| Component | Primary role | Typical location |
|---|---|---|
| Management Server | UI, CLI, REST APIs, policy, scheduling, monitoring, reporting, inventory, metadata, replication orchestration, and recovery orchestration. | Protected and recovery sites |
| Replication Node | Block replication, incremental change processing, rolling-window transport, parallel streams, flow control, validation, storage writes, and checkpoint finalization. | Protected and recovery sites |
| Prep Node | Windows recovery preparation, boot remediation, file system checks, registry checks, and cross-platform recovery preparation. | Recovery environment |
| DeDup Node | Checksum index, repeated block detection, deduplicated chunk references, and chunk reuse mapping. | Recovery environment |
Management Server
The Management Server is the central orchestration and control-plane component. It coordinates platform activity while maintaining operational metadata, workflow state, inventory, and recovery orchestration logic.
It is responsible for:
- User interface, CLI, and REST APIs
- Policy management
- Replication orchestration
- Recovery orchestration
- Scheduling
- Monitoring and alerting
- Reporting
- Inventory and metadata management
- Day-0 through day-N workflows
Deploy a Management Server at both the protected site and the recovery site. For smaller deployments, the Management Server can additionally function as a Replication Node.
Replication Node
The Replication Node is the primary data-plane component. Replication Engines are deployed at both the protected site and the recovery site.
Replication Nodes are responsible for:
- Block-level replication
- Incremental change processing
- Rolling-window transport management
- Parallel stream handling
- WAN-optimized data transfer
- Descriptor-driven chunk scheduling
- Data integrity validation
- Cloud-native storage writes
- Recovery data reads
- Flow-control management
- Recovery checkpoint finalization
The replication architecture is optimized for fragmented CBT workloads, enterprise-scale replication, many parallel workloads, WAN-constrained environments, cross-cloud replication, high-churn workloads, and cloud-native storage APIs.
Prep Node
The Prep Node is a Windows-based recovery preparation appliance. It is activated only when a workflow requires Windows workload recovery or compatibility preparation.
Prep Nodes are used for:
- VMware-to-cloud recoveries
- Cross-hypervisor migrations
- Cross-cloud recovery operations
- Windows boot remediation
- File system and registry compatibility checks
DeDup Node
The DeDup Node is optional. It reduces WAN bandwidth, cross-cloud transfer cost, replication duration, and repetitive data transfer overhead by maintaining chunk checksum and reuse metadata.
Use DeDup Nodes when workload datasets are similar, operating system builds are standardized, retention periods are long enough to benefit from reuse, or the use case is a one-time migration with large repeated data patterns.
Register a node in the console
Nodes are registered under Configure → Nodes. The local node (the management node you are logged into) registers automatically. Deploy one management node per protected site and one per recovery site; register the recovery-site management node in the protected site's management node. Replication nodes are always added to their local management node; DeDup and Win Prep nodes register with the recovery site's management node.
Click + New and provide:
| Parameter | Type | Required | Description |
|---|---|---|---|
| Name | string | required | Identifies the node. For all non-local nodes, this must match the name of the VM where the node is deployed. |
| Hostname | string | required | FQDN or IP address of the node. |
| Username | string | required | Datamotive engine username (Administrator). |
| Password | string | required | Datamotive engine password. |
| Type | enum | required | Management, Replication, Prep Node, or Dedupe Server. |
For Management type, additional ports are requested: management port (default 5000), replication data port (default 5001), and replication controller port (default 5003). Click Configure to save.
Configuration checklist
Place management capacity
Deploy Management Servers at the protected and recovery sites, then size them for workload count, reporting needs, API activity, and recovery orchestration concurrency.
Assign replication capacity
Deploy Replication Nodes where data movement occurs. Assign workload groups so each node stays within the recommended workload and disk concurrency for the source platform.
Prepare Windows recovery capacity
Add Prep Nodes when Windows recoveries, cross-platform migrations, or boot remediation workflows are in scope.
Enable deduplication where it helps
Add DeDup Nodes for migration waves, similar workload sets, or WAN-constrained environments where duplicate chunks are expected.
Related docs
Was this page helpful?