From 9e9e3c5620882d2f769694996ff4d7e0cf36cc2b Mon Sep 17 00:00:00 2001 From: raghavendra talur Date: Thu, 20 Aug 2015 15:09:31 +0530 Subject: Create basic directory structure All new features specs go into in_progress directory. Once signed off, it should be moved to done directory. For now, This change moves all the Gluster 4.0 feature specs to in_progress. All other specs are under done/release-version. More cleanup required will be done incrementally. Change-Id: Id272d301ba8c434cbf7a9a966ceba05fe63b230d BUG: 1206539 Signed-off-by: Raghavendra Talur Reviewed-on: http://review.gluster.org/11969 Reviewed-by: Humble Devassy Chirammal Reviewed-by: Prashanth Pai Tested-by: Humble Devassy Chirammal --- done/Features/rdmacm.md | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 done/Features/rdmacm.md (limited to 'done/Features/rdmacm.md') diff --git a/done/Features/rdmacm.md b/done/Features/rdmacm.md new file mode 100644 index 0000000..2c287e8 --- /dev/null +++ b/done/Features/rdmacm.md @@ -0,0 +1,26 @@ +## Rdma Connection manager ## + +### What? ### +Infiniband requires addresses of end points to be exchanged using an out-of-band channel (like tcp/ip). Glusterfs used a custom protocol over a tcp/ip channel to exchange this address. However, librdmacm provides the same functionality with the advantage of being a standard protocol. This helps if we want to communicate with a non-glusterfs entity (say nfs client with gluster nfs server) over infiniband. + +### Dependencies ### +* [IP over Infiniband](http://pkg-ofed.alioth.debian.org/howto/infiniband-howto-5.html) - The value to *option* **remote-host** in glusterfs transport configuration should be an IPoIB address +* [rdma cm kernel module](http://pkg-ofed.alioth.debian.org/howto/infiniband-howto-4.html#ss4.4) +* [user space rdmacm library - librdmacm](https://www.openfabrics.org/downloads/rdmacm) + +### rdma-cm in >= GlusterFs 3.4 ### + +Following is the impact of http://review.gluster.org/#change,149. + +New userspace packages needed: +librdmacm +librdmacm-devel + +### Limitations ### + +* Because of bug [890502](https://bugzilla.redhat.com/show_bug.cgi?id=890502), we've to probe the peer on an IPoIB address. This imposes a restriction that all volumes created in the future have to communicate over IPoIB address (irrespective of whether they use gluster's tcp or rdma transport). + +* Currently client has independence to choose b/w tcp and rdma transports while communicating with the server (by creating volumes with **transport-type tcp,rdma**). This independence was a by-product of our ability to use the tcp/ip channel - transports with *option transport-type tcp* - for rdma connection establishment handshake too. However, with new requirement of IPoIB address for connection establishment, we loose this independence (till we bring in [multi-network support](https://bugzilla.redhat.com/show_bug.cgi?id=765437) - where a brick can be identified by a set of ip-addresses and we can choose different pairs of ip-addresses for communication based on our requirements - in glusterd). + +### External links ### +* [Infiniband Howto](http://pkg-ofed.alioth.debian.org/howto/infiniband-howto.html) -- cgit