Answer the question
In order to leave comments, you need to log in
Cheap storage for a small virtualization cluster?
Hello dear %username%! My task is to raise a virtualization cluster of two servers, so that in case of a crash or for administrative needs, virtual machines can be launched on another one with minimal delay. This means that the servers must either work with one common storage, or their separate storages must be synchronized by some kind of replication. I previously raised the configuration with local screws in each server and DRBD synchronization. Tell me, does it make sense to abandon this approach and take a shared storage (shared storage, san) in a small budget? Maybe someone has experience using a distributed file system instead of block replication?
There is no money in the budget for a normal SAN, and we only need 8 screws. From a common hardware, a shelf option with two SCSI connections is possible (one per server, sharing requires the use of a cluster file system), or some kind of budget SAN itself. As an option - a "home-made" iSCSI / NFS storage based on a regular server.
Please tell me more options for a cheap shared storage or other options other than block replication.
By the way, since there is no live migration in the requirements, perhaps there are even simpler concepts?
UPD. A system failure for 10-15 minutes is not very important, but a single point of failure with the risk of a long-term loss (for example, a single disk shelf or a single storage server) is critical
Answer the question
In order to leave comments, you need to log in
In your version, there is one significant point of failure - the storage itself.
Either you pay money for its greater reliability (two controllers, two iscsi or sas cards)
Or you pay for two hundred active-active ones.
Both are a lot of money.
If you are raising a failover cluster (and according to the description, you are doing it), then in any case you need an external (in relation to the servers) storage. If there is no money, take a car, install hard drives, raise iscsi target, take care of backing up storage to external storage, for example, another machine with iscsi target;)
An ordinary computer server, with a soft raid, to send images over the network by some kind of nfs.
It is possible to try niksa with iSCSI.
Implemented this for XenServer.
On one server screws in a mirror. If the server burns down, throw the screws into a neighboring server.
There is no live migration, I think, and the time for switching to a reserve is not regulated, then why a cluster?
If it's more complicated, then you need a guardian with controllers, a direct connection to servers, multipath. For tasks with 2 servers, SAN is not needed.
A software solution for organizing storage systems is quite suitable for you. There are several of them on the market now, there are paid and free ones. If interested, then write in a personal.
You actually have the cheapest option. I didn't see why you don't like it.
Its only drawback is the lack of backup at the OS level, because DRBD transfers everything block by block, including the killed OS.
On two servers, I can offer this option: refusing DRBD, virtual machines work on one server, cold replication to another (once a day, for example). The replication program runs in a virtual machine on a backup server. In the event of a failure of the main server, all that is required is to start replicas on the standby. Only it will not be a cluster, the launch delay will be minimal, some loss of data relevance.
If, as you write, there are no requirements for reliability. Take the third server and raise the shared storage on it via iSCSI.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question