Hello guy, I am writing to you because I would like to get to know you
about a small "project" that I developed about Ovirt that for me seems very
interesting and may interested develope teams.
After studying Ovirt and seeing that the ideal solution would be to have
three nodes, for "economic" needs, I wanted to try buying two SuperMicro
nodes, with two M2 disks on which I installed CentOS, two SSD disks as
cache for writing to speed up I / O operations, 4 rotating 15,000 RPM disks
that I formatted in ZFS, putting 3 as storage for the VMs and one in
reserve.
At this point, I installed Ovirt as a VM on storage and it ran "normally",
thus always creating my VMs on the storage with the normal Ovirt procedure.
The thing that I think is interesting, is that for every VM I assign a
storage quota, so the VM1 will have for example 100Gb of disk assigned,
called Disk1. Obviously, this space is subsequently editable through the
ZFS commands. Always with the ZFS functionalities, I have the possibility
to take a snapshot of disk1 and "send" it to node 2 which is configured
exactly as node 1. This operation, thanks to ZFS, is very fast and need
chip bandwith... In this way, node 1 is the production node, node 2 acts
from a silent "repository" of snapshots that arriving, every few minutes
(even absurdly every minute) from node1. In case of a fault in the VM of
node1, or of the entire node1, I have the possibility to restoring the VM
to the node 2, with a simple ZFS command, the snapshot to tot minutes ago,
"attach" that datastore to the node and restart the VM, having lost as data
only the delta from the last snapshot at the time of the fault. The
procedure I tested and tested several times, coming to inject a
cryptolocker on VM1, turning it off, restoring the last snap on node2 and
restarting it at the last snap, all within a few minutes. In my opinion,
developing a web interface now (something I am not able to do) that would
allow the installation of deciding the ZFS configuration of the storage
disks and then, again via the web, the possibility of defining the cron of
the snapshot and possible restoration, the product would be really
interesting and attractive, because meanwhile I don't have to have three
nodes and more because in case of fault, in a few minutes you can get back
on your feet with a data loss that for the vast majority of companies is
plausible and approachable.
If you are interesting about this solution, i will be happy to "talk" to
you about it.
Thanks a lot.
Fabio Zaltron
--
Zaltron Fabio
