Sendense Docs

Infrastructure Requirements

The resources, access, platform objects and validation checks needed before commissioning a Sendense deployment.

Readiness

Confirm The Critical Items First.

Confirm these items before scheduling commissioning.

CloudStack user, cloned Tenant Admin role and getPathForVolume permission.

STYPE CloudStack OS type created and applied to Sendense appliances hosted in CloudStack.

SNAgent deployment approved on relevant Ubuntu KVM/libvirt hosts.

Outbound TCP 443 from each SNA and SNAgent host to the SHA.

Local SSD/NVMe EBA performance tier attached to the SHA.

Controller Template, DHCP network and CloudStack offerings prepared.

Requirements

Requirements By Section.

Each section shows the required items first, with supporting detail kept behind the section control.

01

Appliances

SHA and SNA Resources

Virtual appliance sizing, addressing and placement.

  • 1 x SHA: 16 vCPU, 64 GB RAM, 300 GB SSD, 10 GbE minimum.
  • VMware-side SNAs: 8 vCPU, 16 GB RAM, 100-200 GB SSD each.
  • CloudStack-side SNAs: 8 vCPU, 8 GB RAM, 100-200 GB SSD each.
  • Static IP addresses or DHCP reservations for SHA and SNAs.
Details

SHA provides UI/API, orchestration, EBA services and repository control.

VMware-side SNAs have the higher memory requirement for the VMware backup and replication source workflow.

CloudStack-side SNAs should be placed close to the CloudStack/KVM environment.

Controller appliances require DHCP on the target CloudStack guest network.

02

Storage

EBA Repository

Local performance tier and capacity planning.

  • 500 GB minimum local SSD/NVMe performance tier attached to the SHA.
  • 1 TB performance tier recommended for larger workloads or higher concurrency.
  • Capacity tier sized from protected workload used capacity and retention.
  • Selected VM list must include OS type, disk count and used capacity.
Details

Use selected workload used capacity x 1.5 to 2.5 as an initial capacity planning estimate.

HDD-backed capacity storage is acceptable behind the local SSD/NVMe performance tier.

Keep the initial repository local to the SHA when validating backup and replication behaviour.

Final sizing should be confirmed once the workload list and retention window are agreed.

03

Network

Baseline Access

Core firewall rules for management, inventory and updates.

  • Admin users to SHA on TCP 443.
  • SNA appliances to SHA on outbound TCP 443.
  • SHA/SNA to VMware vCenter or ESXi on TCP 443.
  • SHA/SNA to CloudStack Management API on TCP 443 or TCP 8080.
  • SHA to Sendense support and update services on outbound TCP 443.
Details

SNA to SHA connectivity covers appliance management, control and tunnelled operations.

CloudStack API port depends on the platform configuration.

If direct SNA-to-SNA replication traffic is not permitted, replication can use SHA relay mode.

SHA relay mode requires outbound TCP 443 from both SNAs to the SHA.

04

CloudStack

Tenant, Role And Objects

CloudStack user, permissions, OS type and recovery objects.

  • Dedicated Sendense CloudStack user in the relevant tenant/account.
  • Clone Tenant Admin role and assign it to the Sendense user.
  • Add getPathForVolume as an explicit Allow rule.
  • Create custom OS type STYPE.
  • Apply STYPE to SNAs hosted in CloudStack, and to the SHA if hosted in CloudStack.
  • Import the Sendense Controller Template into the target zone.
  • Provide a DHCP-enabled CloudStack guest network.
  • Create custom compute offering with root disk size 0 and a custom disk offering.
Details

getPathForVolume is mandatory for CloudStack QCOW/NFS backup.

The Controller Template, network and offerings must be visible to the Sendense API user.

The custom disk offering is used for replica and restore disk creation.

The DHCP-enabled network is used when controller appliances are deployed for replication and restore workflows.

05

SNAgent

KVM Host Readiness

Agent installation and host-to-host connectivity.

  • Install SNAgent on relevant Ubuntu KVM/libvirt hypervisor hosts.
  • Use the SHA-generated installer command or script.
  • Each SNAgent host requires outbound TCP 443 to the SHA.
  • TCP 8888 is required only between relevant KVM hosts running SNAgent.
Details

SNAgent downloads directly from the SHA; a manual internet download is not required.

TCP 8888 is KVM-to-KVM SNAgent peer traffic.

The SNA does not require network access to SNAgent on TCP 8888.

SNAgent peer traffic uses HTTPS/mTLS in managed mode.

06

Replication

Relay And Controller Paths

Replication mode, relay ranges and controller connectivity.

  • SHA relay mode: source SNA to SHA to destination SNA over TCP 443.
  • Direct point-to-point mode: source SNAs to destination SNAs on configured relay ranges.
  • Recommended direct range for CloudStack SNA 1: TCP 11000-11099.
  • Recommended direct range for CloudStack SNA 2: TCP 11100-11199.
  • Destination CloudStack SNA to controller appliance on TCP 8080 and TCP 10810-10819.
Details

Direct point-to-point mode is preferred where controlled source-to-destination access is allowed.

A 100-port range per destination SNA gives headroom for concurrent jobs and multi-disk VMs.

Controller TCP 8080 covers management, health, disk discovery and replication preparation.

Controller TCP 10810-10819 carries replication disk data.

Controller to destination SNA TCP 8081 is used where site-local relay mode is enabled.

07

VMware

vCenter Access

VMware reachability, service account and workload selection.

  • VMware-side SNAs must reach vCenter/ESXi on TCP 443.
  • Dedicated VMware service account.
  • Account permissions for inventory, snapshot, CBT and virtual disk access.
  • Selected VMware VM list with OS type, disk count and used capacity.
Details

The selected replication set should be agreed before commissioning.

1 GbE is enough for functional validation.

10 GbE is recommended for meaningful backup and replication throughput testing.

Direct SNA-to-SNA replication paths should use 10/25 GbE where available.

08

Validation

Commissioning Evidence

Minimum checks to confirm the deployment is ready.

  • VMware full and incremental backup complete successfully.
  • CloudStack QCOW/NFS full and incremental backup complete successfully.
  • Agreed VMware workloads replicate into CloudStack successfully.
  • At least one restore to CloudStack completes using agreed objects.
  • Jobs, logs and status are visible in the Sendense UI.
Details

Direct point-to-point replication can be compared with SHA relay mode where firewall policy allows.

Validation should use the agreed workload list, retention window and restore target.

Observed transfer rates should be measured in the customer environment rather than inferred from link speed alone.

Final Checklist

Ready For Commissioning.

Use this list as the practical handoff between infrastructure, security, platform and Sendense delivery teams.

SHA resources allocated

VMware-side SNAs allocated

CloudStack-side SNAs allocated

EBA SSD/NVMe tier attached

EBA capacity tier sized

CloudStack user created

Tenant Admin role cloned

getPathForVolume allowed

STYPE created and applied

Controller Template imported

DHCP guest network ready

Custom compute offering created

Custom disk offering created

SNAgent installation approved

TCP 443 rules confirmed

TCP 8888 KVM-to-KVM rule confirmed

Replication relay ranges agreed

Selected workload details provided

Next: Architecture Overview

Use the architecture guide to understand how SHA, SNAs, EBA, SNAgent and controller appliances connect during backup and replication.

View Architecture