<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <tt>Hi List,</tt><tt><br>
    </tt><tt><br>
    </tt><tt>I was wondering if anyone has implemented gluster
      successfully in AWS, and has some tips on streamlining the process
      to increase throughput and possibly reduce latency. (Sorry in
      advance if this list has seen this problem a lot)</tt><tt><br>
    </tt><tt><br>
    </tt><tt>My current setup is as follows;</tt><tt><br>
    </tt><tt><br>
    </tt><tt>gfs-server1 - ap-southeast-2 (AZ1)</tt><tt><br>
    </tt><tt>gfs-server2 - ap-southeast-2 (AZ2)</tt><tt><br>
    </tt><tt>gfs-server3 - ap-southeast-1 (AZ1) (Arbiter)</tt><tt><br>
    </tt><tt>web-server1 - apsoutheast2-az1 (Mounted as gluster/nfs to
      gfs-server1)</tt><tt><br>
    </tt><tt>web-server2 - apsoutheast2-az2 (Mounted as gluster/nfs to
      gfs-server2)</tt><tt><br>
    </tt><tt><br>
      Using latest 3.7 package from the Ubuntu launchpad ppa. <br>
      <br>
    </tt><tt>I have one server in each availability zone within
      Australia with the arbiter volume over in Singapore. This will
      hopefully act as a fall back if ever there is a problem connecting
      internally between the two availability zones in the same region.
      Assuming each gluster server can router externally and not
      internally. </tt><tt><br>
    </tt><tt><br>
    </tt><tt>This is for a webserver with a lot of wordpress + magento
      installations. So it has a lot of files</tt><tt>. <br>
    </tt><tt><br>
    </tt><tt>I mounted the gluster volume and started copying across the
      files and it was terribly slow. (See below for data)</tt><tt> [1]<br>
    </tt><tt><br>
    </tt><tt>My Questions are as follows:</tt><tt><br>
    </tt><tt>I see from the archives and FAQ's that people have sped up
      copies by using xargs and having multiple threads per sub folders.
      While this is a good idea, is there any other way to increase
      throughput?</tt><tt><br>
    </tt><tt>Also I did a few tests against different mount points on
      NFS and GlusterFS to see what the difference was, and NFS kicks
      the glusterfs mount out of the park. Is there a specific reason
      for this?</tt><br>
    <tt><tt>Would removing the arbiter volume or assuming for example
        sake; that there was a third availability zone in ap-southeast-2
        so latency was not an issue, increase my throughput? As the
        gluster-client has to write the </tt>data to the 2 gluster
      volumes and the meta-data to the arbiter would this help in
      reducing the time per file?<br>
      (Also a non-gluster question that no-one has to answer, has anyone
      tried Amazons' Elastic File System (EFS) and is it comparable to
      gluster?)<br>
      <br>
      <br>
      Thank you for reading the wall of text, and I appreciate all the
      hard work everyone has put into this great product. <br>
      <br>
      Cheers,<br>
      Tim<br>
      <br>
      [1] Data:<br>
    </tt>
    <pre><code>time cp -Rv wordpress/ /var/gluster-nfs/dir/wordpress/
real    165m4.445s
user    0m0.592s
sys     0m3.227s</code></pre>
    <tt></tt>
    <pre><code>du -shc wordpress/
374M    wordpress/

find wordpress/ | wc -l        
4955
(It works out to be on average 2 seconds per file)
</code></pre>
    <tt></tt><br>
    <tt>NFS DD Write: </tt>
    <pre><code>sudo dd if=/dev/zero of=./test bs=1024                                                                                                        412738+0 records in
412738+0 records out
422643712 bytes (423 MB) copied, 85.4381 s, 4.9 MB/s</code></pre>
    <tt>
    </tt>
    <p><tt>GlusterFS DD Write (1): </tt></p>
    <tt>
    </tt>
    <pre><code>sudo dd if=/dev/zero of=./testgf bs=1024k count=10000
12+0 records in
12+0 records out
12582912 bytes (13 MB) copied, 117.974 s, 107 kB/s</code></pre>
    <tt>
    </tt>
    <p><tt>GlusterFS DD Write: (2):</tt></p>
    <tt>
    </tt>
    <pre><code>sudo dd if=/dev/zero of=./testgf1 bs=1024 count=10000                                                                                                              10000+0 records in
10000+0 records out
10240000 bytes (10 MB) copied, 56.8728 s, 180 kB/s</code></pre>
  </body>
</html>