<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hi Ravi (and list),<br>
<br>
We are planning on testing the NFS route to see what kind of
speed-up we get. A little research led us to the following:
<br>
<br>
<a
href="https://gluster.readthedocs.io/en/latest/Administrator%20Guide/NFS-Ganesha%20GlusterFS%20Integration/"
class="OWAAutoLink" id="LPlnk501909" previewremoved="true">https://gluster.readthedocs.io/en/latest/Administrator%20Guide/NFS-Ganesha%20GlusterFS%20Integration/</a><br>
<br>
Is this correct path to take to mount 2 xfs volumes as a single
gluster file system volume? If not, what would be a better path?<br>
<br>
<br>
Pat<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/11/2017 12:21 AM, Ravishankar N
wrote:<br>
</div>
<blockquote
cite="mid:7670ef62-3a15-057a-44bb-436d4a42dafa@redhat.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div class="moz-cite-prefix">On 04/11/2017 12:42 AM, Pat Haley
wrote:<br>
</div>
<blockquote
cite="mid:d0bbb5ee-6d74-ddf4-9866-779c3dd6c191@mit.edu"
type="cite"> <br>
Hi Ravi,<br>
<br>
Thanks for the reply. And yes, we are using the gluster native
(fuse) mount. Since this is not my area of expertise I have a
few questions (mostly clarifications)<br>
<br>
Is a factor of 20 slow-down typical when compare a fuse-mounted
filesytem versus an NFS-mounted filesystem or should we also be
looking for additional issues? (Note the first dd test
described below was run on the server that hosts the
file-systems so no network communication was involved).<br>
</blockquote>
<br>
Though both the gluster bricks and the mounts are on the same
physical machine in your setup, the I/O still passes through
different layers of kernel/user-space fuse stack although I don't
know if 20x slow down on gluster vs NFS share is normal. Why don't
you try doing a gluster NFS mount on the machine and try the dd
test and compare it with the gluster fuse mount results?<br>
<br>
<blockquote
cite="mid:d0bbb5ee-6d74-ddf4-9866-779c3dd6c191@mit.edu"
type="cite"> <br>
You also mention tweaking " write-behind xlator settings".
Would you expect better speed improvements from switching the
mounting from fuse to gnfs or from tweaking the settings? Also
are these mutually exclusive or would the be additional benefits
from both switching to gfns and tweaking?<br>
</blockquote>
You should test these out and find the answers yourself. <span
class="moz-smiley-s1"><span>:-)</span></span><br>
<br>
<blockquote
cite="mid:d0bbb5ee-6d74-ddf4-9866-779c3dd6c191@mit.edu"
type="cite"> <br>
My next question is to make sure I'm clear on the comment " if
the gluster node containing the gnfs server goes down, all
mounts done using that node will fail". If you have 2 servers,
each 1 brick in the over-all gluster FS, and one server fails,
then for gnfs nothing on either server is visible to other nodes
while under fuse only the files on the dead server are not
visible. Is this what you meant?<br>
</blockquote>
Yes, for gnfs mounts, all I/O from various mounts go to the gnfs
server process (on the machine whose IP was used at the time of
mounting) which then sends the I/O to the brick processes. For
fuse, the gluster fuse mount itself talks directly to the bricks.<br>
<blockquote
cite="mid:d0bbb5ee-6d74-ddf4-9866-779c3dd6c191@mit.edu"
type="cite"> <br>
Finally, you mention "even for gnfs mounts, you can achieve
fail-over by using CTDB". Do you know if CTDB would have any
performance impact (i.e. in a worst cast scenario could adding
CTDB to gnfs erase the speed benefits of going to gnfs in the
first place)?<br>
</blockquote>
I don't think it would. You can even achieve load balancing via
CTDB to use different gnfs servers for different clients. But I
don't know if this is needed/ helpful in your current setup where
everything (bricks and clients) seem to be on just one server.<br>
<br>
-Ravi<br>
<blockquote
cite="mid:d0bbb5ee-6d74-ddf4-9866-779c3dd6c191@mit.edu"
type="cite"> Thanks<br>
<br>
Pat<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/08/2017 12:58 AM, Ravishankar
N wrote:<br>
</div>
<blockquote
cite="mid:0b9de8db-606b-95d2-946f-f5d65f4f669e@redhat.com"
type="cite">
<div class="moz-cite-prefix">Hi Pat,<br>
<br>
I'm assuming you are using gluster native (fuse mount). If
it helps, you could try mounting it via gluster NFS (gnfs)
and then see if there is an improvement in speed. Fuse
mounts are slower than gnfs mounts but you get the benefit
of avoiding a single point of failure. Unlike fuse mounts,
if the gluster node containing the gnfs server goes down,
all mounts done using that node will fail). For fuse mounts,
you could try tweaking the write-behind xlator settings to
see if it helps. See the performance.write-behind and
performance.write-behind-window-size options in `gluster
volume set help`. Of course, even for gnfs mounts, you can
achieve fail-over by using CTDB.<br>
<br>
Thanks,<br>
Ravi<br>
<br>
On 04/08/2017 12:07 AM, Pat Haley wrote:<br>
</div>
<blockquote
cite="mid:e8df9693-fea0-d001-88fa-65ed551f504d@mit.edu"
type="cite"> <br>
Hi,<br>
<br>
We noticed a dramatic slowness when writing to a gluster
disk when compared to writing to an NFS disk. Specifically
when using dd (data duplicator) to write a 4.3 GB file of
zeros:<br>
<ul>
<li>on NFS disk (/home): 9.5 Gb/s</li>
<li>on gluster disk (/gdata): 508 Mb/s<br>
</li>
</ul>
The gluser disk is 2 bricks joined together, no replication
or anything else. The hardware is (literally) the same:<br>
<ul>
<li>one server with 70 hard disks and a hardware RAID
card.</li>
<li>4 disks in a RAID-6 group (the NFS disk)</li>
<li>32 disks in a RAID-6 group (the max allowed by the
card, /mnt/brick1)</li>
<li>32 disks in another RAID-6 group (/mnt/brick2)</li>
<li>2 hot spare<br>
</li>
</ul>
<p>Some additional information and more tests results (after
changing the log level):<br>
</p>
<p><span>glusterfs 3.7.11 built on Apr 27 2016 14:09:22</span><br>
<span>CentOS release 6.8 (Final)</span><br>
RAID bus controller: LSI Logic / Symbios Logic MegaRAID
SAS-3 3108 [Invader] (rev 02)<br>
<br>
<br>
<br>
<b>Create the file to /gdata (gluster)</b><br>
[root@mseas-data2 gdata]# dd if=/dev/zero of=/gdata/zero1
bs=1M count=1000<br>
1000+0 records in<br>
1000+0 records out<br>
1048576000 bytes (1.0 GB) copied, 1.91876 s, <b>546 MB/s</b><br>
<br>
<b>Create the file to /home (ext4)</b><br>
[root@mseas-data2 gdata]# dd if=/dev/zero of=/home/zero1
bs=1M count=1000<br>
1000+0 records in<br>
1000+0 records out<br>
1048576000 bytes (1.0 GB) copied, 0.686021 s, <b>1.5 GB/s
- </b>3 times as fast<b><br>
<br>
<br>
Copy from /gdata to /gdata (gluster to gluster)<br>
</b>[root@mseas-data2 gdata]# dd if=/gdata/zero1
of=/gdata/zero2<br>
2048000+0 records in<br>
2048000+0 records out<br>
1048576000 bytes (1.0 GB) copied, 101.052 s, <b>10.4 MB/s</b>
- realllyyy slooowww<br>
<br>
<br>
<b>Copy from /gdata to /gdata</b> <b>2nd time <b>(gluster
to gluster)</b></b><br>
[root@mseas-data2 gdata]# dd if=/gdata/zero1
of=/gdata/zero2<br>
2048000+0 records in<br>
2048000+0 records out<br>
1048576000 bytes (1.0 GB) copied, 92.4904 s, <b>11.3 MB/s</b>
<span>- realllyyy slooowww</span> again<br>
<br>
<br>
<br>
<b>Copy from /home to /home (ext4 to ext4)</b><br>
[root@mseas-data2 gdata]# dd if=/home/zero1 of=/home/zero2<br>
2048000+0 records in<br>
2048000+0 records out<br>
1048576000 bytes (1.0 GB) copied, 3.53263 s, <b>297 MB/s
</b>30 times as fast<br>
<br>
<br>
<b>Copy from /home to /home (ext4 to ext4)</b><br>
[root@mseas-data2 gdata]# dd if=/home/zero1 of=/home/zero3<br>
2048000+0 records in<br>
2048000+0 records out<br>
1048576000 bytes (1.0 GB) copied, 4.1737 s, <b>251 MB/s</b>
<span>- 30 times as fast<br>
<br>
<br>
As a test, can we copy data directly to the xfs
mountpoint (/mnt/brick1) and bypass gluster?<br>
<br>
<br>
Any help you could give us would be appreciated.<br>
<br>
</span>Thanks<br>
</p>
<pre class="moz-signature" cols="72">--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Pat Haley Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:phaley@mit.edu">phaley@mit.edu</a>
Center for Ocean Engineering Phone: (617) 253-6824
Dept. of Mechanical Engineering Fax: (617) 253-8125
MIT, Room 5-213 <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://web.mit.edu/phaley/www/">http://web.mit.edu/phaley/www/</a>
77 Massachusetts Avenue
Cambridge, MA 02139-4301
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-users">http://lists.gluster.org/mailman/listinfo/gluster-users</a></pre>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Pat Haley Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:phaley@mit.edu">phaley@mit.edu</a>
Center for Ocean Engineering Phone: (617) 253-6824
Dept. of Mechanical Engineering Fax: (617) 253-8125
MIT, Room 5-213 <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://web.mit.edu/phaley/www/">http://web.mit.edu/phaley/www/</a>
77 Massachusetts Avenue
Cambridge, MA 02139-4301
</pre>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Pat Haley Email: <a class="moz-txt-link-abbreviated" href="mailto:phaley@mit.edu">phaley@mit.edu</a>
Center for Ocean Engineering Phone: (617) 253-6824
Dept. of Mechanical Engineering Fax: (617) 253-8125
MIT, Room 5-213 <a class="moz-txt-link-freetext" href="http://web.mit.edu/phaley/www/">http://web.mit.edu/phaley/www/</a>
77 Massachusetts Avenue
Cambridge, MA 02139-4301
</pre>
</body>
</html>