Search the docs

Prerequisites, Sizing, and Networking

A multi-site environment can be brought up quickly, but a few prerequisites must be in place first. Hammerspace can use block storage, existing NAS, and cloud/object storage, and installs as a single software load on bare-metal, virtual, or cloud environments.

Pre-deployment readiness checklist

One row per site, before you start Part 1 of Deploy and Configure a Global File System:

  • Hammerspace installed and licensed at every participating site.

  • At least one Anvil per site (HA pair recommended).

  • At least one DSX per site (two or more recommended).

  • Local file storage configured per site (DSX Store volume or NAS export).

  • Shared object bucket reachable from all Anvil and DSX nodes at every site; credentials with required permissions on hand.

  • Ports 443, 9097, 9298, 9299 open between all Anvil nodes across all sites — verified, not assumed (see the port-check pitfall below).

  • If using SMB: all sites joined to the same AD domain/forest.

  • Site names chosen, if using descriptive names (Part 3).

  • Conflict-resolution retention decided (log-xfer-1-<time> period) — see How Conflicts Are Handled.

Requirements and Limits at a Glance

Requirement / limit Detail Source

Anvil per site

At least one (HA pair recommended)

This chapter

DSX per site

At least one (two or more recommended)

This chapter

Shared bucket(s)

At least one (two or more recommended for resilience)

This chapter

Inter-Anvil ports

443, 9097, 9298, 9299

This chapter

ID-mapping source

Same across all sites (Active Directory)

This chapter

Default replication interval

5 seconds

Deploy and Configure a Global File System

Default replication alert threshold

300 seconds

Monitoring and Alerting

Latency envelope

Proven to 200 ms continuous ping latency

This chapter

Shared-OSV capacity guideline

Roughly 14 days of transfer volume

This chapter

Sites per share

Qualified/supported up to 16 — see the note below

Introduction and Solutions
"Sites per share" is phrased here as a qualified, supported configuration limit, not a hard product ceiling — confirm the current supported number against the Hardware and Software Compatibility List before treating it as fixed, since it’s a support-matrix decision rather than something enforced by the product itself.

Minimum Requirements

  • Each site has at least one installed Anvil metadata node (HA recommended).

  • Each site has at least one installed DSX data services node (two or more recommended).

  • One shared cloud/object bucket for cross-site data transfer (two or more recommended for resilience).

  • Network connectivity between Anvil nodes on four ports: 443, 9097, 9298, 9299.

  • The same ID-mapping source across all sites. This is currently supported using Active Directory.

Sizing

  • Anvil — confirm the Anvil’s block storage has sufficient IOPS and low latency for metadata operations; sub-optimal storage degrades replication. Provide adequate CPU and memory for metadata churn and checkpointing, especially with many sites. Work with your Hammerspace Sales Engineer to size correctly.

  • Latency tolerance — GFS is architected to tolerate high latency; higher-latency sites simply lag slightly. Hammerspace is proven to operate with sites at 200 ms continuous ping latency.

  • Capacity planning — size each site’s NAS for its active working set and tier the rest to a shared OSV. Provision enough shared-OSV capacity for cross-site transfer; a working guideline is roughly 14 days of transfer. Site-to-site transfers stall if the shared OSV runs out of capacity.

  • Bucket redundancy — configure a second shared bucket with a higher online-delay objective so all transfers prefer the first bucket and fall back to the second only if the first is unavailable.

Network Connectivity

  • Reliable, high-bandwidth connectivity between all sites — enough to transfer new and estimated changed data to or from any other site.

  • The four Anvil ports above, plus firewall rules permitting Anvil-to-Anvil and DSX-to-shared-bucket traffic.

A recurring deployment failure is REPLICATION_PORT_CHECK_FAILED on ports 9298, 9299, 9097, or 443, which blocks participant-add or flips participants to Suspected/Down. Verify all four ports end-to-end before adding participants. See Troubleshooting: Deployment.
Coordinate upgrades across every site

Per the Installation Guide’s Upgrading global file system environments, upgrading an environment with replicated shares stops metadata replication until every participating site has been upgraded — plan multi-site upgrades to happen close together, ideally simultaneously, to minimize the delay.

Protocol Prerequisites

Global NFS shares

There are no special requirements for NFS to work globally, except when Kerberos is used.

Global SMB shares

For Windows/SMB access, all sites must be joined to the same domain / domain forest so Security Identifiers (SIDs) translate correctly on every site.

Global S3 servers/buckets

Each site presents its own S3 endpoint. See the flag below before relying on this for a cross-site deployment.