napp-it ZFS Storage, User Manual

Page: 37 / 63

17. Async Data Replikation/ Avalability
Unlike other backup or sync methods, ZFS replication can keep an active ZFS filesystem with open files in
sync with another filesystem on the same or a remote ZFS server. You can run replications down to every
minute to sync filesystems near realtime.
A replication initially transfers the whole filesystem with ZFS properies based on a snapshot. After the first
run, replication works as an incremental transfer based on snaps on source and target that must be in sync
and represents the same data state. On an incremental run, the target filesystem is resetted to the same
state as the last source filesystem snap. A new source snap represents the datablock differences between
this snap and the current state. Only this snap is transferred as a datastream. This makes replication ultra
fast. Napp-it replicates over a buffered netcat connection up to wireframe performance. As replication is
based on snaps , each data state is like a hard shutdown, As a replication run resets a target filesystem to
a former state to be in sync with the source filesystem, you should should not use it beside reads between
replications. If you need to switch to a replicated filesystem a main filesystem. you must stop replication
and set the filesystem to read/write. To switch back, you can replicate the filesystem back.
Snapshots on replicated filesystems.
As a replication target filesystem is resetted to a base snap on every replication run, you can keep older
replication snaps based on date or name. On a source filesystem you can use regular snaps for versioning.
17.1 Sync Data Replikation
If you need realtim sync with the exact same datastate at any time you can use a mirror between
appliances. You need two or more storage nodes (independent ZFS storage servers) that offer a ZFS file-
system over a fast network connection as a FC or iSCSI target. A storagehead can the built a ZFS pool over
these iSCSI targets as a mirror or raid-Z over nodes.
17.2 Data Availability from Backup to active/active HA
There are several steps to increase data availability.
1. Availability due Backup
First step is backup from time to time to a physically separate place.
Especially on a disaster you can restore a former datastate. Restore can last a very long time.
2. Availability due Replication to a backup/spare system
This is near realtime local copy to a spare/backup system. On problems you can switch services to this da-
tastate in a very short time. If you have enough free bays on your backup/spare system and your main pool
is working, you can also move and import the pool to regain service availability.
From a crash, time to regain services is between 15 minutes and an hour
3. High avaiability with a multipath SAS storage and two nodes.
Mostly problems are not related to disks but HBAs, Mainboards or a system configuration.
A typical HA config can share dualpath SAS disks to two identical appliances. A HA Software like
RSF-1 can manage the two appliances and switch services between them in a few seconds.
As an addition you can use two appliances and two storage nodes and connect them via iSCSI. On a
storage node or a storage head problem, you can automatically switch between under control of RSF-1.
HA is usually quite complicated and should be done only under support. Napp-it does not support HA in
the GUI, but you can use RSF-1 from http://www.high-availability.com/zfs-ha-plugin/