<div dir="ltr">Thanks for the reply.<div><br></div><div>As per your guidance, the glusterfs information is given below:</div><div><div>Volume Name: share</div><div>Type: Replicate</div><div>Volume ID: bd545058-0fd9-40d2-828b-7e60a4bae53c</div><div>Status: Started</div><div>Number of Bricks: 1 x 2 = 2</div><div>Transport-type: tcp</div><div>Bricks:</div><div>Brick1: master1:/data/brick1/share</div><div>Brick2: master2:/data/brick2/share</div><div>Options Reconfigured:</div><div>performance.readdir-ahead: on</div><div>cluster.self-heal-daemon: enable</div><div>network.ping-timeout: 25</div><div>cluster.eager-lock: on</div></div><div><br></div><div><div>[root@master1 ~]# gluster pool list</div><div>UUID                                    Hostname        State</div><div>5a479842-8ee9-4160-b8c6-0802d633b80f    master2         Connected</div><div>5bbfaa4a-e7c5-46dd-9f5b-0a44f1a583e8    localhost       Connected</div></div><div><br></div><div><br></div><div>Host information is given below:-</div><div><div>192.168.10.103  master1.local   master1 #Fixed</div><div>192.168.10.104  master2.local   master2 #Fixed</div></div><div><br></div><div><br></div><div>Test case is given below:-</div><div>Case 1</div><div>While writing 20MB of files continuously on client side. one of the glusterfs server(Master1) is powered off.</div><div>Impact </div><div>Client IO operation will be on hold for 25 to 30 second and after that it will work normally.</div><div><br></div><div>Case 2</div><div>When failed server is power-up during the IO operation at client side.</div><div>Impact</div><div>Client IO operation will be on hold for 25 to 30 second and after that it will work normally.<br></div><div><br></div><div>Result:</div><div>There will be no IO loss during the event of failure. But there is difference of data size on both the servers.</div><div><b>Master1</b></div><div><div><b>Size </b>/dev/mapper/brick1-brick1                       19912704  508320  19404384   3% /data/brick1<br></div></div><div><div><b>Inodes </b>/dev/mapper/brick1-brick1                        9961472  1556 9959916    1% /data/brick1<br></div></div><div><br></div><div><b>Master2</b></div><div><div><b>Size</b> /dev/mapper/brick2-brick2                               19912704  522608  19390096   3% /data/brick2</div></div><div><div><b>Inodes </b>/dev/mapper/brick2-brick2                        9961472  1556 9959916    1% /data/brick2<br></div></div><div><br></div><div><br></div><div><b>Client</b></div><div><b>Size       </b>master1.local:/share  19912704   522624  19390080   3% /media<br></div><div><b>Inodes   </b>master1.local:/share 9961472   1556 9959916    1% /media</div><div><br></div><div><br></div><div><br></div><div>How we can match the size of data on both the servers or this normal behavior.</div><div>And there will be impact on data integrity.</div><div><br></div><div>Thank You</div><div>Atul Yadav</div><div>09980066464</div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 1:21 AM, Gmail <span dir="ltr">&lt;<a href="mailto:b.s.mikhael@gmail.com" target="_blank">b.s.mikhael@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">find my answers inline.<div><br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div><b>— Bishoy</b></div></div></div></div></div>
</div>
<br><div><span class=""><blockquote type="cite"><div>On Feb 11, 2016, at 11:42 AM, Atul Yadav &lt;<a href="mailto:atulyadavtech@gmail.com" target="_blank">atulyadavtech@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr">HI Team,<div><br></div><div><br></div><div>I am totally new in Glusterfs and evaluating glusterfs for my requirement.</div><div><br></div><div>Need your valuable input on achieving below requirement :-</div><div>File locking </div></div></div></blockquote></span>Gluster uses DLM for locking.<br><blockquote type="cite"><div><div dir="ltr"><div>Performance</div></div></div></blockquote>It depends on your work load (is it small files big files, etc…), the number of drives and the kind of volume you create.</div><div>I suggest you start with just a Distributed Replicated volume and from that point you can plan for the hardware and software configuration.<br><blockquote type="cite"><div><div dir="ltr"><div>High Availability </div></div></div></blockquote>I suggest replicating the bricks across the two nodes, as erasure coding with two nodes and a single drive on each one will not be of any benefit.<br><blockquote type="cite"><div><span class=""><div dir="ltr"><div><br></div><div><br></div><div>Existing Infra details is given below:-</div><div>CentOS 6.6</div><div>glusterfs-server-3.7.8-1.el6.x86_64<br></div><div>glusterfs-client-xlators-3.7.8-1.el6.x86_64<br></div><div>GlusterFS server Quantity 2 with independent 6 TB storage </div><div>24 Glusterfs Client.</div><div>Brick replication</div><div><br></div><div><br></div><div>Thank You</div><div>Atul Yadav</div><div><br></div><div><br></div></div></span>
_______________________________________________<br>Gluster-users mailing list<br><a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br><a href="http://www.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-users</a></div></blockquote></div><br></div></div></blockquote></div><br></div>