GlusterFS is the way to go out of the two. DRDB is used more often for active / passive failover.
The important thing to consider with Gluster is that all client nodes must be connected to all server nodes directly, and that all server nodes cna connect to all server nodes directly. While Gluster can replicate between server nodes, its data propagation is controlled and managed primarily at the client. Clients are responsible for fanning out data to server nodes, as they connect to all relevant nodes simultaneously. Client > server networking is the most important to consider in this case.
Since you would be using your servers as clients in this case (an acceptable practice in small clusters), you need only make sure that these nodes have a good storage network between the two of them.
I would strongly recommend three Gluster nodes for a few reasons. First of all, you cannot resolve split-brain scenarios automatically with only two nodes. You need a third in order to provide a majority rule when one storage node has invalid data or is offline. Secondly, your data integrity itself will be better off, as you can use 3n replication or 2n-a (two node with arbitration) replication.
For your purposes, 2n-a replication would be a likely target. This behaves like three node replication, but performs about as well as two node replication (that is to say, better in most cases). This involves, in its simplest form, two normal data nodes and one arbiter node that contains only metadata meant for measuring the integrity of the other two nodes. As a result, the arbiter node needs only 4k of space for each file it tracks, and requires much less bandwidth than the two full storage nodes. Something to consider.
Finally, GlusterFS is a layer above your filesystems that it uses for data, so do not interact with those filesystems directly after installing GlusterFS. It refers to these filesystems as bricks, however they do not need to be separate filesystems. They can be directories within a single filesystem (not entirely recommended) or something like BTRFS subvolumes (more recommended). In general, any POSIX compliant filesystem will do as a backing brick.
Identical bricks can be created on nodes, and then congealed into a volume. A volume is a multi-server export that behaves much like NFS. At that point, all you need to do is mount that export.
A short document on arbiter volumes: https://gluster.readthedocs.io/en/latest/Administrator%20Guide/arbiter-volumes-and-quorum/
A great guide to how to set up GlusterFS in a simple 2n cluster is here: https://www.digitalocean.com/community/tutorials/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers
