<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>All,</div><div><br></div><div>I need to have a portion of my gluster setup in high-performance mode while the rest is in high-availability mode. I currently have a replica 3 setup with about 180TB on each of three servers.</div><div><br></div><div>I want to add 4 new servers to act as distributed brick sources (feeding data over a 100G IB connection each) such that this system is a 4th replica. My thinking is the high speed read processes needed to feed the computational cluster pull from these nodes and writes get pushed out to all nodes. Each server will host 14+ bricks. The new systems will be NVME and the older systems are SAS2 drives.</div><div><br></div><div>So far it looks like this is not a workable process as there's no way to specify in the addition of the new bricks how to organize this.</div><div><br></div><div>I've looked at organizing the new 4 systems using OpenZFS and using ZFS to do the split then gluster just sees another replica system. Gluster-block looks like an option for use but I'm unclear on how it will interact with writes in the event of a single node failure in the distributed group.</div><div><br></div><div>Can gluster groups be used to aggregate server nodes?</div><div><br></div><div>I am open to any ideas. I don't want to have to reformat to ZFS and migrate and manually build the replication process that gluster now handles "automagically".</div><div><span><pre><pre>-- <br></pre>James P. Kinney III
Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain
http://heretothereideas.blogspot.com/
</pre></span></div></body></html>