Plan and install
Prerequisites
Deployment location, network and firewall, DNS, IP, and access-control prerequisites for deploying the Datamotive solution.
- Product
- Datamotive Platform
- Version
- v2.0.3
- Last updated
- Updated
- Reading time
- 1 min read
Implement these prerequisites before deploying Datamotive nodes. They fall into three areas: deployment location, networking, and access control — plus an optional sandboxed environment for test drills.
Deployment location
- Management Server and Replication Nodes support a replication source or target within one cloud region (or one vCenter Server for VMware).
- Cloud sources: deploy nodes in the same region as the instances to protect. Cloud targets: deploy nodes in the region where instances will be recovered.
- Multi-AZ recovery and VMware datastore-access rules are detailed in Preparing target site.
Networking
| Requirement | Detail |
|---|---|
| Bandwidth | Minimum 150 Mbps dedicated between replication nodes for a fully loaded node (40 parallel disks). Under-provisioning delays replication and can breach the configured RPO; bandwidth throttling is available. |
| Inter-node connectivity | Secured metadata and data transfer between nodes within and across sites — private subnets or VPN tunnels. Port matrix: core/networking/ports. |
| Outbound connectivity | Nodes must reach the platform managers (vCenter Server, AWS/Azure/GCP APIs) over port 443 to orchestrate workflows. No organization data flows on this path. |
| Recovered-entity connectivity | Only if custom recovery scripts must reconfigure recovered instances. |
| DNS | A reachable DNS server resolving vCenter/ESXi hostnames (VMware) or cloud API endpoints and metadata service (cloud). Node hostnames must resolve locally. |
| IP configuration | Static IPs on every node (netplan on VMware; private or reserved/Elastic IPs in cloud). Never two IPs on one node. |
Full details: Networking (planning), Ports, and Firewall.
Access control
Datamotive orchestrates through platform-manager APIs and needs a dedicated role or principal per platform, on both sites:
- VMware — a vCenter role with datastore, VM configuration/inventory/interaction/provisioning/snapshot, replication, and tagging privileges.
- AWS — a dedicated IAM policy and user with access keys; mutations restricted to resources tagged
Protected-By-Datamotive. KMS key access if disks are encrypted. - GCP — compute permissions plus the Service Account User role.
- Azure — an App Registration with Contributor and Storage Blob Data Contributor at subscription or resource-group level.
The complete privilege lists are in Permissions.
Node instance sizing
| Node | Instance size | Storage | Notes |
|---|---|---|---|
| Management Server | 4 vCPU, 16 GB RAM | 50 GB | Hosts the internal database. AWS: r6a.large / t3a.xlarge / t3.xlarge, GP3. |
| Replication Node | 4 vCPU, 16 GB RAM | 50 GB | One per 40 parallel disks. |
| DeDupe Node | 4 vCPU, 16 GB RAM | 500 GB SSD preferred | Size by anticipated unique replication data. |
| Windows Prep Node | 4 vCPU, 16 GB RAM | 50 GB | Azure: instance type supporting 20 disk attachments (e.g. F8). |
| Day2Operation Node | 2 vCPU, 8 GB RAM | 50 GB | Optional central monitoring portal; has an internal database. |
For large environments, see the scale-based sizing profiles in Sizing guidelines and the Scale and performance guide.
Sandboxed environment for test drills
To run non-intrusive test drills, prepare an isolated infrastructure (VPCs, networks, subnets) on the recovery site with no outbound connectivity to production or DR networks. See Preparing target site.
Related docs
Was this page helpful?