[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vdsm-devel
Subject:    =?utf-8?q?=5Bovirt-devel=5D?= Ovirt and ZFS
From:       Fabio Zaltron <fabio.zaltron () gmail ! com>
Date:       2019-11-28 9:05:36
Message-ID: CAJiqcXb23LrTYtvT_8UUpigOBamkL+kfX5H=w1pduaZ9BM7hww () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

[Attachment #5 (text/html)]

<div dir="ltr"><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Hello guy, I am \
writing to you because I would like to get to know you about a small \
&quot;project&quot; that I developed about Ovirt that for me seems very interesting \
and may interested   develope teams.</p><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">After studying \
Ovirt and seeing that the ideal solution would be to have three nodes, for \
&quot;economic&quot; 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.</p><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">



</p><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">At this point, I \
installed Ovirt as a VM on storage and it ran &quot;normally&quot;, 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 &quot;send&quot; 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 &quot;repository&quot; 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, &quot;attach&quot; 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&#39;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.</p><p class="MsoNormal" \
style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><br></p><p \
class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">If you are \
interesting about this solution, i will be happy to &quot;talk&quot; to you about it. \
</p><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><br></p><p \
class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Thanks a \
lot.</p><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><br></p><p \
class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif">Fabio \
Zaltron</p><p class="MsoNormal" style="margin:0cm 0cm \
8pt;line-height:107%;font-size:11pt;font-family:Calibri,sans-serif"><br></p><div><br></div>-- \
<br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Zaltron \
Fabio</div></div>


[Attachment #6 (text/plain)]

_______________________________________________
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/32XTLECCWSFGJUZ7DPXQ4GXBNGY7KVFC/




[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic