Installation

Installing TwinStor takes one bundle and one wizard on each host.

warning

The Tech Preview is for lab pools only. Keep backing up your VMs: two copies protect you from a hardware failure, not from a deleted VM or ransomware.

Requirements

• Two XCP-ng hosts in one pool, both fully updated (yum update, then reboot) to the same patch level.
• A free local disk, partition or md-RAID array on each host for the data. The wizard never offers the system disk or a disk that is in use.
• A network between the hosts. 1 Gbit/s works; 10 Gbit/s is better for write-heavy workloads, since every write crosses it.
• "Restore on AC power loss" set to Power On in the BIOS of both hosts, so the pool comes back by itself after a power cut.
• No broken SR in the pool. A host whose SR fails to plug at boot stays disabled, and HA cannot restart VMs on a disabled host.

The bundle includes everything TwinStor needs (DRBD, targetcli and their dependencies). Multipath is enabled by the setup.

ZFS

A ZFS zvol works as the data device (community-supported). Use its /dev/zvol/<pool>/<dataset> path and keep the dataset's sync property at standard.

Pick your topology

The wizard asks you to choose between two network modes. Both keep your data safe. The right one depends on one question: can the two hosts lose each other while both still reach the gateway?

Fate-shared (default)

Use it when the hosts and the gateway are on the same network: a single switch, or a redundant switch pair (MLAG or stack) where a failure cannot leave the hosts cut from each other while both still reach the gateway.

Fate-shared · one switch carries everythingclients + replicationtiebreaker

A host that loses its peer also loses the gateway, so it knows it is the one cut off and steps aside. With a single switch, that switch is the one weak point: if it fails, the whole pool stops cleanly and restarts when it comes back, with no data damage.

Arbitrated (dedicated storage network)

Use it when replication runs on its own network, separate from the gateway (dedicated storage switches or a storage VLAN). In that case you must add a direct cable between the two hosts. It becomes the main replication path, and the switched network takes over automatically, with an alert, if the cable fails. The wizard can configure the direct-link IP addresses for you.

Arbitrated · replication rides a dedicated cablereplicationclientstiebreaker

Choose the mode at install time: changing it later needs a maintenance window.

note

• Keep the management network redundant too (a bond, or the same switch pair). XCP-ng HA heartbeats use it, and a management blip can cause an avoidable HA reboot.
• By default, a host decides whether it can keep serving by pinging the gateway. You can add other targets (a second router, a switch management address) in /etc/twinstor/ping-targets, one IP per line. Never add the direct-link IP.

Install the bundle on both hosts

Get the download link and its SHA-256 checksum from the TwinStor deploy page, then run on each host, as root:

root@twinstor-1: install

# wget -O twinstor-test-<version>.tar.gz "<download URL>"
# echo "<published sha256>  twinstor-test-<version>.tar.gz" | sha256sum -c
# tar xzf twinstor-test-<version>.tar.gz && cd twinstor-test-<version> && ./install.sh

install.sh checks the host, installs the dependencies and the twinstor service. It does not configure anything.

Run the setup wizard

Run twinstor setup on the first host, then on the second:

root@twinstor-1: setup

# twinstor setup

The wizard finds the other host, asks for the network mode, lists the candidate disks and asks you to type yes before it erases one. On the second host it creates the shared SR, plugs it on both hosts and enables HA.

If setup stops halfway (a typo, a network problem), run it again with the same answers, or run twinstor uninstall and start over.

For scripted installs, twinstor setup --peer-ip <IP> --backing-device /dev/disk/by-id/<disk> runs without questions on the first host and prints the command to run on the second. See twinstor --help.

Firewall

Setup opens two ports on each host: 7789/tcp (replication) and 3260/tcp (iSCSI).

Check the result

On both hosts, twinstor status should start with health: healthy and show readiness: ready:

root@twinstor-1: twinstor status

# health: healthy (serving, peer redundant)

   version:     0.7.2
   host:        twinstor-1 (this node), peer twinstor-2
   pool HA:     enabled

[OK] drbd:
     role:       Primary
     disk:       UpToDate
     connection: Connected
     peer role:  Primary
     peer disk:  UpToDate

[OK] readiness:   ready (local serving, peer redundant)

Then check that HA is on and keeps room for one host failure. The command should print true and 1:

root@twinstor-1: check HA

# xe pool-list params=ha-enabled,ha-host-failures-to-tolerate

If not, see HA failover capacity. Otherwise you are done: create VMs on the new SR, migrate them between the hosts, and they restart on the other host if one fails.

Uninstall

twinstor uninstall removes TwinStor from a host and puts things back in order. It refuses while VMs still use the SR.

root@twinstor-1: uninstall

# twinstor uninstall               # asks for confirmation
# twinstor uninstall --keep-data   # do not wipe the data device
# twinstor uninstall --force       # go ahead even if it cannot check that the SR is unused

It leaves in place the network settings of a direct link and any md-RAID array you created. Remove them yourself if you no longer need them.