TwinStor

TwinStor turns the local disks of a two-host XCP-ng pool into shared, replicated storage. Live migration, HA and Rolling Pool Updates work as they do on any shared SR, with no SAN and no third host.

DO NOT USE IN PRODUCTION

TwinStor is a Tech Preview: a pre-release build for lab pools, not for production. Run it on hardware you can afford to break, and keep backing up your VMs.

To get the current build, join the Tech Preview or go to the TwinStor deploy page. Feedback and questions go to the TwinStor thread on the XCP-ng forum.

How it works

Each host keeps a full copy of the data, and both hosts serve it at the same time. There is no passive host and no storage failover.

Both hosts active · one replicated storagesynchronous replicationlocal I/O

• Reads are local. A VM reads from the disk of the host it runs on.
• Writes are on both hosts. A write is confirmed to the VM only once both hosts have it, so losing a host never loses a confirmed write.
• No witness node. When the hosts lose each other, each one checks whether it can still reach the network gateway to know which side was cut off.
• A standard shared SR. Snapshots, backups, Xen Orchestra and HA work as usual. Nothing in XCP-ng is patched.
• Safe on consumer drives. TwinStor turns off volatile write caches on drives that have one, so a confirmed write is really on disk.

You do not manage the replication or the iSCSI layer yourself: twinstor setup builds everything, twinstor status tells you how it is doing, and twinstor uninstall removes it.

What happens when something fails

• A host dies: its VMs restart on the other host. When it comes back, it catches up and redundancy returns on its own.
• A disk dies: VMs keep running from the other copy. Replace the disk when convenient.
• The network between the hosts is cut: the host that lost the network steps aside and the other keeps serving. Everything heals when the link is back.
• TwinStor cannot tell which copy is right: it changes nothing, keeps both copies and raises an alert telling you what to decide.

See Failure behavior for the details.

When not to use TwinStor

• You have more than two hosts. TwinStor is for exactly two.
• You need more than two copies of your data.
• You need several storage tiers. TwinStor provides one SR.

In this section

• Installation: requirements, choosing the network mode, install and setup.
• Administration: daily use, monitoring and alerts, planned maintenance.
• Failure behavior: what heals itself and what waits for you.
• Updates: updating TwinStor and the hosts.
• Troubleshooting and feedback: what to check and how to report a problem.