<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Gluster gurus,<br>
    <br>
    I'm new to Gluster, so if there is a solution already talked about
    somewhere then gladly point me to it and I'll get out of the way.&nbsp;
    That said, here's my problem:<br>
    <br>
    I have four machines.&nbsp; Each machine is running Ubuntu 12.04 with
    Gluster 3.2.5.&nbsp; Each machine has two drives:<br>
    <br>
    node1:/export/bricks/a<br>
    node1:/export/bricks/b<br>
    node2:/export/bricks/a<br>
    node2:/export/bricks/b<br>
    node3:/export/bricks/a<br>
    node3:/export/bricks/b<br>
    node4:/export/bricks/a<br>
    node4:/export/bricks/b<br>
    <br>
    I created a volume with a single replication, added the bricks,
    mounted it to /mnt, and then created a file with "touch /mnt/this".&nbsp;
    The file "this" appeared on the two bricks located on node1:<br>
    <br>
    node1:/export/bricks/a/this<br>
    and <br>
    node1:/export/bricks/b/this<br>
    <br>
    So if node1 goes down, all access to the file "this" is lost.&nbsp; It
    seemed to me that the order in which bricks were added dictated the
    replication location -- i.e. the second brick added is used as the
    replication destination for the first brick, and so on with the 3rd
    and 4th pair of bricks, 5th and 6th, etc.<br>
    <br>
    I've searched the archives, and this seems to be confirmed in a past
    post located here:<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
href="http://supercolony.gluster.org/pipermail/gluster-users/2013-June/036272.html">http://supercolony.gluster.org/pipermail/gluster-users/2013-June/036272.html</a><br>
    <br>
    <blockquote type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Replica sets are done in order that the bricks are added to the volume.</pre>
    </blockquote>
    ...<br>
    <blockquote type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">So, you have an issue here, that both bricks of a replica set are on the 
same host.</pre>
    </blockquote>
    <br>
    Unfortunately, this was the end of the thread and no more
    information was forthcoming.<br>
    <br>
    Now, I'm just starting out, and my volume is not yet used in
    production, so I have the luxury of removing all the bricks and then
    adding them back in an order that allows for replication to be done
    across nodes the way that I want.&nbsp; But I see this as a serious
    problem.&nbsp; What happens down the road when I need to expand?<br>
    <br>
    How would I add another machine as a node, and then add it's bricks,
    and still have replication done outside of that one machine?&nbsp; Is
    there a way to manually specify master/replication location?&nbsp; Is
    there a way to reshuffle replicant brick on a running system?<br>
    <br>
    A couple of solutions have presented themselves to me:<br>
    1) Only add new nodes in pairs, and make sure to add bricks in the
    correct order.<br>
    2) Only add new nodes in pairs, but setup two Gluster volumes and
    use geo-replication (even though the geographical distance between
    the two clusters may be as little as only 1 inch).<br>
    3) Only add new nodes in pairs, and use RAID or LVM to glue the
    drives together, so that as far as Gluster is concerned, each node
    only has one brick.<br>
    <br>
    But each of these solutions involves adding new nodes in pairs,
    which increases the incremental cost of expansion more than it feels
    like it should.&nbsp; It just seems to me that there should be a smarter
    way to handle things than what I'm seeing before me, so I'm hoping
    that I've just missed something obvious.<br>
    <br>
    So what is the common wisdom among seasoned Gluster admins?<br>
    <br>
    Thanks for your help,<br>
    <br>
    Michael<br>
  </body>
</html>