<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Am 08.12.2015 um 02:59 schrieb Lindsay
Mathieson:<br>
</div>
<blockquote cite="mid:56663964.7060902@gmail.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Udo, thanks for posting your
volume info settings. Please note for the following, I am not
one of the devs, just a user, so unfortunately I have no
authoritative answers :(<br>
<br>
I am running a very similar setup - Proxmox 4.0, three nodes,
but using ceph for our production storage. Am heavily testing
gluster 3.7 on the side. We find the performance of ceph slow on
these small setups and management of it a PITA.<br>
<br>
<br>
Some more questions<br>
<br>
- how are your VM images being accessed by Proxmox? gfapi?
(Proxmox Gluster storage type) or by using the fuse mount?<br>
<br>
</div>
</blockquote>
<br>
Sorry, forgot to say that: I'm accessing the Gluster Storage via NFS
since (at least in version 3.4 of Proxmox) the gfapi method has some
problems with sockets.<br>
<br>
<blockquote cite="mid:56663964.7060902@gmail.com" type="cite">
<div class="moz-cite-prefix"> - whats your underlying filesystem
(ext4, zfs etc)<br>
</div>
</blockquote>
<br>
a dedicated ext4 partition<br>
<blockquote cite="mid:56663964.7060902@gmail.com" type="cite">
<div class="moz-cite-prefix"> <br>
- Are you using the HA/Watchdog system in Proxmox?<br>
</div>
</blockquote>
<br>
I am now (watchdog HA), but Proxmox was running in non-HA mode at
the time of failure.<br>
<br>
<br>
<blockquote cite="mid:56663964.7060902@gmail.com" type="cite">
<div class="moz-cite-prefix"> <br>
<br>
<br>
On 07/12/15 21:03, Udo Giacomozzi wrote:<br>
</div>
<blockquote cite="mid:56656779.5000707@indunet.it" type="cite">esterday
I had a strange situation where Gluster healing corrupted <b
class="moz-txt-star"><span class="moz-txt-tag">*</span>all<span
class="moz-txt-tag">*</span></b> my VM images. <br>
<br>
<br>
In detail: <br>
I had about 15 VMs running (in Proxmox 4.0) totaling about 600
GB of qcow2 images. Gluster is used as storage for those images
in replicate 3 setup (ie. 3 physical servers replicating all
data). <br>
All VMs were running on machine #1 - the two other machines (#2
and #3) were <b class="moz-txt-star"><span class="moz-txt-tag">*</span>idle<span
class="moz-txt-tag">*</span></b>. <br>
Gluster was fully operating (no healing) when I rebooted machine
#2. <br>
For other reasons I had to reboot machines #2 and #3 a few
times, but since all VMs were running on machine #1 and nothing
on the other machines was accessing Gluster files, I was
confident that this wouldn't disturb Gluster. <br>
But anyway this means that I rebootet Gluster nodes during a
healing process. <br>
<br>
After a few minutes, Gluster files began showing corruption - up
to the point that the qcow2 files became unreadable and all VMs
stopped working. </blockquote>
<br>
<br>
:( sounds painful - my sympathies. <br>
<br>
You're running 3.5.2 - thats getting rather old. I use the gluster
debian repos:<br>
<br>
3.6.7 : <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://download.gluster.org/pub/gluster/glusterfs/3.6/LATEST/Debian/">http://download.gluster.org/pub/gluster/glusterfs/3.6/LATEST/Debian/</a><br>
3.7.6 : <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/jessie/">http://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/jessie/</a><br>
<br>
3.6.x is the latest stable, 3.7 is close to stable(?) 3.7 has some
nice new features such as sharding, which is very useful for VM
hosting - it enables much faster heal times.<br>
</blockquote>
<br>
I'm using the most current version provided by Proxmox APT sources.<br>
<br>
Can 3.6 or even 3.7 Gluster nodes work together with 3.5 node? If
not I'm wondering how I could upgrade...<br>
<br>
You might understand that I hesitate a bit to upgrade Gluster
without having some certainty that it won't make things even worse.
I mean, this is a production system.. <br>
<br>
<blockquote cite="mid:56663964.7060902@gmail.com" type="cite"> <br>
Regards what happened with your VM's, I'm not sure. Having two
servers down should have disabled the entire store making it not
readable or writable. </blockquote>
<br>
I'm not sure if both servers were down at the same time (could be,
though). I'm just sure that I rebootet them rather quickly in
sequence.<br>
<br>
Right now my credo is "<i>never ever reboot/shutdown more than 1
node at a time and most importantly, always make sure that no
Gluster healing is in progress</i>". For sure, I did not respect
that when I crashed my storage.<br>
<br>
<blockquote cite="mid:56663964.7060902@gmail.com" type="cite">I note
that you are missing some settings that need to be set for VM
stores - there will be corruption problems if you live migrate
without them.<br>
<br>
<pre>quick-read=off
read-ahead=off
io-cache=off
stat-prefetch=off
eager-lock=enable
remote-dio=enable
quorum-type=auto
server-quorum-type=server
"stat-prefetch=off" is particularly important.
</pre>
<br>
</blockquote>
<br>
Thanks. Is there a document that explains the reasoning behind this
config?<br>
<br>
Does this apply to volumes for virtual HDD images only? My
"docker-repo" is still "replicate 3" type but is used by the VMs
themselves, not by the hypervisor - I guess other settings apply
there..<br>
<br>
Thanks a lot,<br>
Udo<br>
<br>
</body>
</html>