R
R
realvava2017-05-17 10:50:01
Virtualization
realvava, 2017-05-17 10:50:01

Are there free VirtualSAN solutions with two-way replication?

Creating a failover cluster implies having a shared storage system. In cases of budget solutions, this is no alternative to iSCSI (do not offer AoE :-) ). This leads (again, we are talking about free software) to the lack of alternatives to DRBD. But his whole problem for me is that in the conditions of working with clusterless OS, he is imprisoned for Primary-Secondary, and this is understandable. I, in turn, would like different directories to replicate in reverse directions relative to each other.
Let's say there is node1 and node2, they have directory1 and directory2, of course, on each. That is, if node1 is selected as the primary, then both directories in the work are written to it and replicated to node2. As I understand it, the implementation of the possibility that node 1 was primed only for directory 1, and node 2 for directory - no?
This would be convenient in an implementation similar to StarWind VirtualSAN, when two virtual machines on different hosts are given all the available local server space, and they also provide access to them as a single replicated storage. Only if replication is two-way, it is possible to distribute the load.
Take hypervisor1 and hypervisor2, put on them, respectively, virtualka1 and virtualku2, each of which is issued in the form of a virtual disk all the remaining disk space on the local disk of each of the hypervisors. After, having combined virtual machines into a kind of storage cluster, it would still be more convenient and correct if the virtual machines initiating access from hypervisor1 accessed virtual machine1 as a primary, and VM from hypervisor2 to virtual machine2, respectively. Despite the fact that the data is still chasing "into the network", you will agree that there will be less losses with such an implementation.
It remains to hang some kind of controlling server with heartbits, which, in the event of a failure of one of the hypervisors, along with its storage node, will send commands to start virtual machines through console commands (for example, on HyperV via powershell), or leave the settings of the HyperV failover cluster in stock.

Answer the question

In order to leave comments, you need to log in

3 answer(s)
R
realvava, 2017-05-17
@realvava

The new direction of thought is ClusterOS on ZFS.

A
Armenian Radio, 2017-05-17
@gbg

Ceph, for example

V
Vladimir Zhurkin, 2017-07-28
@icCE

This leads (again, we are talking about free software) to the lack of alternatives to DRBD. But his whole problem for me is that in the conditions of working with clusterless OS, he is imprisoned for Primary-Secondary, and this is understandable

Well, in general, no. There are also GlusterFS, Ceph, Moose, etc.
It all depends on the needs and what you need in the end.
I either do not understand or you want strange.
You have those who write read and there is a place that they read and write. That very place will be replicated among themselves, no matter who wrote it down. If there are rights and access, then go ahead.
Another point is that if you need several systems to write to a certain block device, you need to raise a clustered file system there. For example OCFS2.
First, 2 machines from the cluster do not form a quorum. Therefore, when one node exits, everything will stand up and wait for your action. Next, you must separate hypervisors and storage for them. Storage from the point of view of the hypervisor should be a single place. Those should have one entry point and no matter how many nodes you have in storage. Otherwise, when hypervisor1 crashes, how will virtual machine images crawl onto hypervisor2? Therefore, we set up a cluster of hypervisors, and a cluster of storage. Hypervisors should only have drives to start the system, and all images are stored on storage (the so-called storage system).
No need to reinvent the wheel, where it is not needed.
For starters, what do you still use. If from conditionally open and free - then I would look towards proxmox as hypervisors + they also have finished storage from ceph.
If you have Windows Server and Hyper-V, then it's even easier. You can build storage using StorageSpace + jbod.
It will be possible to set up a separate hyperV replication server, raise the ClasterFileSystem for hyper-v, etc., etc.
There is already a question about this here: How to plan fault-tolerant storage for Hyper-V Cluster?
Well, you can also configure it from ceph for win, via iscsi as the login interface.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question