Skip to main content

Replication

Replication

Replication keeps a copy of a volume's data continuously up to date on a second, independent StorONE system, so a usable copy of your data exists somewhere else entirely — a different array, a different room, a different site. It's how StorONE provides disaster recovery (DR) and high availability (HA) across systems: if the system hosting your data becomes unreachable or is destroyed, you can bring the copy on the other system online and keep serving your applications from there.

Replication is configured per volume (a volume can't be a vRAID+ striped volume — replicating striped volumes isn't supported). Once you start it, StorONE keeps shipping the volume's changes to the target system for as long as the replication is running, over a network path you configure specifically for replication traffic.

Before you can replicate anything, the two StorONE systems involved need to already be connected to each other (via StorONE's multi-system management, configured separately). Everything in this chapter assumes that's already in place.

Continuous vs. periodic replication

StorONE offers two different ways to replicate a volume, and the right one depends on the network link between your two systems and how much data loss you can tolerate if the primary system is lost.

Continuous replication (also called mirroring) sends every write to the target system as it happens. You choose one of three protocols, which trade off write latency against how current the target is guaranteed to be:

  • Synchronous — a write isn't acknowledged back to the host until the target system has confirmed it too. This gives you zero data loss if the source is lost, but it adds a full round trip to the target system to every single write, so it's only practical over short, low-latency links — typically within a datacenter or between nearby sites.
  • Asynchronous — a write is acknowledged to the host as soon as it lands locally, then streamed to the target in the background. Local write performance is unaffected by the link, but if the source system is lost before the most recent writes have reached the target, those writes are gone. This is the practical choice for links with real latency — across a city, a region, or a continent.
  • Semi-synchronous — a middle ground between the two.

You can change the protocol on a running continuous replication later without stopping it.

Periodic replication ships your volume's snapshots to the target system on the schedule you've already configured for it, replicating only the changes between one snapshot and the next rather than mirroring every write as it happens. Because it doesn't need a live, low-latency handshake on every write, periodic replication tolerates long-distance, higher-latency, or lower-bandwidth links far better than continuous replication — at the cost of a recovery point that's only as current as the last snapshot that finished replicating, rather than the (near-)zero data loss continuous replication aims for. Periodic replication isn't available for encrypted volumes.

See Starting and stopping replication for both.

Primary, secondary, and promotion

Every replicated volume has a role on each system it exists on: primary on the system serving live reads and writes, and secondary on the system(s) receiving the replicated copy. The secondary isn't normally writable directly — it exists to take over if the primary becomes unavailable.

Promoting a secondary volume switches its role to primary (and the remote primary becomes secondary). You'd do this for a planned migration or DR test, or for real during an actual failover after the primary system is lost. Because a promotion is a real cutover — the volume you promote becomes the one your applications should be writing to — StorONE checks the state of the data before allowing it, and the checks differ meaningfully between continuous and periodic replication. See Promoting and monitoring replication for the full detail, including exactly what --force does and doesn't override for each type.

Replication also tracks a volume's consistency group, so when you do need to fail over, you can promote an entire consistency group as a single atomic operation — useful when, for example, a database and its transaction log live in the same group and need to come up together, consistent with each other.

Floating IPs

Two different kinds of floating IP are relevant to replication:

  • Replication IPs — a dedicated address (or pair of addresses, for HA systems) on each system used only for replication traffic, kept separate from the addresses your hosts and clients connect to. You configure these yourself before you can start replicating; see Replication IPs.
  • Client-facing floating IPs — the addresses your hosts actually connect to. These are documented in general in Floating IPs. When you promote a secondary volume to primary, you can optionally have StorONE migrate the relevant client-facing floating IPs over to the newly-promoted system at the same time, so clients can reconnect through the same address right after a failover. That promotion-time behavior is replication-specific and is covered in Promoting and monitoring replication.

Replication witness

Normally, promoting a secondary to primary is something you do deliberately, by hand. The replication witness is an optional arbitration service that continuously monitors both systems in a pairing and can trigger that promotion automatically if it determines the primary side has actually gone down, without you needing to intervene. It's covered in its own page: Replication witness.

In this chapter