Synology High Availability Overview

2019-03-31 · synology, highavailability, cluster

A single NAS is a single point of failure, whatever the RAID level. The power supply, the mainboard, a bad DSM update, or a botched drive swap can take every share offline until it's fixed. Synology High Availability (SHA) pairs two identical units into an active/passive cluster with one virtual IP, replicates every write to the passive node, and fails over automatically. Clients keep the same address and mostly notice a short pause.

I'll go through what SHA needs, how to build the cluster on DSM 6.2, and what it won't protect you from, which people tend to overestimate.

What you need on the bench

Two units of the same model, same DSM version, ideally the same drive layout. Mixed models aren't supported.
At least two network ports each: one to the LAN, one as a direct cable between the units for heartbeat and replication. If you have 10 GbE, use it for the heartbeat.
Three LAN addresses: one per node for management, plus the cluster address clients use.
Storage populated on the future active node only. The passive node's volumes get wiped when it joins.

Preparing the passive node

Install DSM on the second unit, update it to exactly the version running on the first (Control Panel → Info Center shows the build number), and give it a static LAN address. Do not create volumes or install packages; SHA replicates the active node's configuration and storage layout to it.

Connect the heartbeat ports directly with a cable. In Control Panel → Network → Network Interface, leave that interface on DHCP or blank; the wizard assigns link-local addresses.

Installing SHA on the active node

Package Center → Synology High Availability → Install on the node that has your data. Open it and click Create high-availability cluster. The wizard asks for:

Heartbeat interface:   LAN 2 (the direct cable)
Cluster name:          nas-ha
Cluster IP:            10.20.30.10
Passive server:        10.20.30.12 (address of the second unit)
Passive server admin credentials

The wizard checks that both units match, then formats the passive node and starts the initial full synchronisation. On a pair with 8 TB of data over 1 GbE this takes most of a day; the cluster is functional during the sync but cannot fail over until it completes.

From this point, the two units' own addresses are only used for the SHA management interface. Everything else, DSM, SMB, NFS, packages, is reached at 10.20.30.10.

Moving clients to the cluster address

Update DNS so the old hostname points to the cluster IP, remount NFS clients, and update any hard-coded addresses in backup jobs or scripts. Because the cluster address is what fails over, anything still pointing at the node address will break the first time a failover happens.

Failover settings and alerts

In the SHA package → Cluster → Manage → Settings:

Enable auto failover: on. Failover triggers when the active node loses power, hangs, or its storage crashes, and optionally when the LAN link goes down.
Auto failover when the network interface goes down: on, for the LAN interface.

Under Control Panel → Notification, enable email for SHA events. A cluster in a degraded state because the passive node dropped out is easy to overlook without an alert; it looks identical to a healthy one from the client side.

Break it on purpose

Do this while it's new and nobody depends on it. I never trust a cluster I haven't failed over myself. From the SHA interface, choose Manage → Switchover. The passive becomes active, services restart on it, and the cluster address moves. Expect about 20 to 60 seconds of interruption for SMB clients, which reconnect on their own. iSCSI and NFS behave similarly; long-running database connections in Docker containers will need to reconnect.

Then test an unplanned one: pull the power on the active node. The heartbeat times out, the passive takes over, and after you power the old active back on it rejoins as the new passive and resynchronises the delta.

Healthy looks like this

SHA → Overview shows both nodes as Healthy and the status "High-availability cluster is operating normally".
ping 10.20.30.10 continues during a switchover with at most a few lost packets.
On a client, a file copy to the cluster share pauses and resumes during switchover rather than failing.
Check replication lag under Cluster → Status; it should read zero when idle.

What SHA does not cover

Data deletion or ransomware: every write, including bad ones, is replicated immediately. Snapshots and Hyper Backup remain necessary.
Same-site disasters: both units are in the same rack. For a second site, Snapshot Replication to a remote unit is the tool.
DSM upgrades without downtime: SHA upgrades the passive first and then switches, which shortens the outage but does not eliminate it.
Performance: writes must be acknowledged by both nodes, so write throughput drops noticeably, especially over a 1 GbE heartbeat. Read performance is unaffected.

Problems

"The passive server does not meet the requirements" in the wizard: DSM versions differ, the passive node has a volume, or a package is installed on it. Reset the passive node to a clean install.
Cluster stuck in "Synchronizing" for days: the heartbeat link is on 1 GbE and the active node is busy. Check the link speed under Network Interface, and schedule the initial sync for a quiet weekend.
After a power failure both nodes come up as passive and no services run. This is split-brain protection. Open the SHA interface on either node's own address and choose which one should become active; pick the one that was active last.
SMB clients see "The specified network name is no longer available" after failover: the DNS or WINS entry still points to a node address instead of the cluster IP.

My take: SHA is worth it when a morning without file shares costs more than a second unit. If you don't already have snapshots and off-site backup, buy those first.