GlusterFS Transport endpoint not connected from time to time

A brick is any directory on an underlying disk filesystem. For example, you could create 4 "bricks" as /var/export/brick0 /var/export/brick1... etc., even though those directories were all on one disk partition. Not that we recommend this, of course, but it's possible. At its most basic, a brick is simply any filesystem you can export as a GlusterFS mount point. In that way, it's similar to an NFS directory export.

A node is a box in a trusted group of peers.

-John Mark Gluster Community Lead

The problem any cluster-node has when coming up from a full stop is:

Do I have the latest state, or not? I don't want to claim latest if I'm behind the other down nodes.

This is why clustering very often includes some kind of quorum mechanism, so existing nodes can vote on state and converge on a consensus. Two node clusters can't use this mechanism, since there will never be a 'majority' partition. In the 3.7 release, Gluster gained a quorum feature.

http://gluster.readthedocs.org/en/release-3.7.0beta1/Features/server-quorum/

In that document, they state that 2-node clusters can't use it for the very reason I described above.

In your case, you may want to consider creating some management-only nodes in your Gluster setup. These would be peers that are probed into the cluster, but don't host any storage. Their entire reason to exist would be to maintain cluster-state. These can exist in different racks, datacenters, power phases, to try and ensure they are in a different fault-domain than the storage bricks. This will increase the number of members in a cluster, and will improve your chances of having a majority partition if one of the storage-bricks comes up without the other one.

Unfortuonately, the behavior you're seeing is working as designed and can't be changed without adding more servers into the cluster.