Industries

Edge to cloud, operated as one system.

A distributed estate rarely fails from a single weak site; it fails from subtle inconsistencies across sites. AiRE eliminates those variations by running identical software, dataset policies and fleet management across every footprint — from compact edge units to core platforms.

  • One policy model across sites
  • Snapshot-delta replication
  • Autonomous operation at unstaffed sites

The problem

Distributed estates drift.

Edge sites are commissioned over years, by different teams, against different budgets. What starts as one architecture becomes a set of near-misses: similar hardware, similar policies, no two quite the same.

The cost is not the hardware. It is that a single requirement — retain this, encrypt that, recover within this window — has to be verified separately at every site, by someone who has to remember which site is which.

It also makes the estate-wide questions unanswerable at speed. Which sites are behind on updates, which are near capacity, which have not had a successful replication this week. Those should be one query.

Edge-to-cloud topologyFour identical edge sites replicate to a regional aggregation point, which replicates to a core platform. The core sends a one-way copy off-site to Vault. All links carry snapshot deltas only.Edge sitecompact unitEdge sitecompact unitEdge sitecompact unitEdge sitecompact unitAggregationregionalCore4U dual controllerVaultoff-site, EUsnapshot deltas onlyone-wayONE FLEET · ONE POLICY MODEL · ONE CONSOLE
Every link carries snapshot deltas rather than whole data sets, which is what makes frequent replication affordable over ordinary site links. The copy into Vault is one-way, so a compromised site cannot reach the off-site archive.

What STORViX does about it

The same platform, everywhere it runs.

Whether deployed as a compact edge unit or a dual-controller core platform, every AiRE instance delivers identical functionality.

  • Centralised fleet management

    Software updates, configuration changes and commands are distributed to as many instances as needed at once. The estate stays consistent instead of drifting site by site.

    • Fleet-wide updates
    • One console for many instances
    • Consistent configuration by default
  • Autonomous operation where nobody is on site

    AutoPILOT performs optimisation and administration on its own and escalates only what it cannot resolve. CloudSight raises alerts from telemetry before a site notices a problem.

    • Self-healing algorithms
    • Escalation to SmartCARE
    • No local administrator required
  • Replication sized for real links

    Snapshots replicate at block level, synchronising only the differences. That is what makes frequent site-to-core copies a policy decision rather than a bandwidth negotiation.

    • Deltas only
    • Minimal bandwidth and storage
    • Site-to-core and site-to-site
  • Edge-optimised hardware

    A compact single-controller unit with adaptive hybrid flash suits a constrained location. The 4U dual-controller platform serves the core. One software stack across both.

    • Compact unit for constrained sites
    • 4U dual controller for aggregation and core
    • Up to 100 GbE connectivity
  • One policy model end to end

    Encryption, retention, reduction and protection attach to the data set, so a requirement is expressed once and behaves identically at the edge and in the core.

    • Per-data-set encryption
    • Consistent retention
    • Same protection topologies everywhere
  • Capacity forecasting across the fleet

    CloudSight projects future utilisation per instance, which turns edge capacity planning from a site-by-site guess into a schedule.

    • Predictive capacity insights
    • Fleet-wide visibility
    • Supports consumption-based pricing

Outcomes

What changes for a distributed operator

  • One requirement, verified once

    A retention or encryption rule is a data set policy, so it does not need re-checking at every site individually.

  • Sites without staff stay healthy

    Autonomous optimisation and remote assistance mean a remote site does not need a visit to stay within policy.

  • Growth is planned, not discovered

    Fleet-wide capacity forecasting replaces the site that unexpectedly fills up on a Friday.

  • New sites match the existing ones

    Commissioning applies the same configuration rather than approximating the last one, so the estate stops drifting.

Designing the topology

The essential starting point is not asking how much capacity each site needs. It is defining what must survive a site outage and how fast it must recover — because those requirements drive the replication topology and shape most of the cost.

From there the pattern is usually the same: local capacity sized to what must be served without a link, aggregation where several sites converge, core capacity for what is shared, and an off-site copy in Vault for what must outlive the estate. An architect can work that through against your site list.

Bring the site list and the recovery objective.

How many sites, what each must serve without a link, and what has to survive losing one. Those three answers produce a topology; a capacity number does not.