Skip to main content

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. The target can be another on-premises system or a StorONE system running in the cloud — see Example: disaster recovery to Azure for an end-to-end example of replicating to Azure.

Continuous replication

StorONE replicates a volume continuously (also called mirroring): every write is sent 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 replication later without stopping it.

See Starting and stopping replication for how to start one.

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. See Promoting and monitoring replication for the full detail, including exactly what --force does and doesn't override.

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

No comments to display