SCALABLE TRANSPORT WITH CLUSTER-CONSENSUS RENDEZVOUS

• US 20140207850A1
• Filed: 12/03/2013
• Published: 07/24/2014
• Est. Priority Date: 01/23/2013
• Status: Active Grant

• Current Assignee: Nexenta by DDN, Inc.
• Original Assignee: Nexenta Systems Incorporated (DataDirect Networks Incorporated)
• Inventors: BESTLER, Caitlin, NOVAK, Robert E., AIZMAN, Alexander
• Granted Patent: US 9,385,875 B2
• Time in Patent Office: Days
• US Class Current: 709/203
• CPC Class Codes: G06F 16/00 Information retrieval; Database structures therefor; File system structures therefor
• CPC Class Codes: G06F 9/46 Multiprogramming arrangements
• CPC Class Codes: H04L 12/18 for broadcast or conference , e.g. multicast
• CPC Class Codes: H04L 12/185 with management of multicast group membership
• CPC Class Codes: H04L 12/1854 with non-centralised forwarding system, e.g. chaincast
• CPC Class Codes: H04L 12/1877 Measures taken prior to transmission
• CPC Class Codes: H04L 47/15 in relation to multipoint traffic arrangements for broadcast or multicast in data networks H04L12/18
• CPC Class Codes: H04L 67/06 specially adapted for file transfer, e.g. file transfer protocol [FTP]
• CPC Class Codes: H04L 67/1097 for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
• CPC Class Codes: H04L 69/164 Adaptation or special uses of UDP protocol

Abstract

Embodiments disclosed herein provide advantageous methods and systems that use multicast communications via unreliable datagrams sent on a protected traffic class. These methods and systems provide effectively reliable multicast delivery while avoiding the overhead associated with point-to-point protocols. Rather than an exponential scaling of point-to-point connections (with expensive setup and teardown of the connections), the traffic from one server is bounded by linear scaling of multicast groups. In addition, the multicast rendezvous disclosed herein creates an edge-managed flow control that accounts for the dynamic state of the storage servers in the cluster, without needing centralized control, management or maintenance of state. This traffic shaping avoids the loss of data due to congestion during sustained oversubscription. Other embodiments, aspects and features are also disclosed.

Claims

1. A method of distributing a chunk within a cluster of storage servers using a cluster-consensus rendezvous, the method comprising:

multicasting a transaction proposal from an initiating client to storage servers in a negotiating group; and

multicasting proposal responses from the storage servers in the negotiating group to all other storage servers in the negotiating group; and

evaluating the proposal responses by each storage server in the negotiating group.

2. The method of claim 1, wherein the evaluating is consistent between the storage servers in the negotiating group.

3. The method of claim 1, wherein distributing the chunk within the cluster of storage servers comprises performing a chunk put transaction, the transaction proposal comprises a put proposal, and the proposal responses comprise put accept responses.

4. The method of claim 3, wherein the rendezvous group is a non-empty subset of the negotiating group.

5. The method of claim 3 further comprising:

evaluating the put accept responses by each storage server in the negotiating group to select which storage server in the negotiating group is to send a consensus put accept to the initiating client;

receiving the consensus put accept by the initiating client; and

performing the rendezvous transfer by the initiating client multicasting a payload of the chunk to the rendezvous group.

6. The method of claim 3 further comprising:

evaluating the put accept responses by each storage server in the negotiating group to select which storage server in the negotiating group is to send a consensus put accept to the initiating client, determine members of the rendezvous group, and determine a designated time and a designated transmission rate for the rendezvous transfer;

receiving the consensus put accept by the initiating client; and

performing the rendezvous transfer by the initiating client multicasting a payload of the chunk to the rendezvous group at the designated time at the designated transmission rate.

7. The method of claim 1, wherein distributing the chunk within the cluster of storage servers comprises performing a chunk get transaction, the transaction proposal comprises a get request, and the proposal responses comprise get responses.

8. The method of claim 7, wherein the rendezvous group includes at least an initiating client, which is a chunk sink, that initiated the chunk get transaction.

9. The method of claim 8, wherein the rendezvous group further includes a storage server that volunteers to store the chunk.

10. The method of claim 7 further comprising:

evaluating the get responses by each storage server in the negotiating group to select a designated storage server in the negotiating group to perform the rendezvous transfer; and

performing the rendezvous transfer by the designated storage server at a designated time at a designated transmission rate.

11. A system of distributing a chunk within a cluster of storage servers using a cluster-consensus rendezvous, the system comprising:

a network of non-blocking switches communicatively interconnecting the storage servers of the cluster;

an initiating client comprising a client system that communicatively interconnects to the network; and

a transport protocol implemented by the storage servers of the cluster and the initiating client, wherein the transaction protocol comprises multicasting a transaction proposal from the initiating client to storage servers in a negotiating group, multicasting proposal responses from the storage servers in the negotiating group to all other storage servers in the negotiating group, and evaluating the proposal responses by each storage server in the negotiating group.

12. The system of claim 11, wherein the evaluating is consistent between the storage servers in the negotiating group.

13. The system of claim 11, wherein distributing the chunk within the cluster of storage servers comprises performing a chunk put transaction, the transaction proposal comprises a put proposal, and the proposal responses comprise put accept responses.

14. The system of claim 13, wherein the rendezvous group is a non-empty subset of the negotiating group.

15. The system of claim 13, wherein the put accept responses are evaluated by each storage server in the negotiating group to select which storage server in the negotiating group is to send a consensus put accept to the initiating client, the consensus put accept is received by the initiating client, and the rendezvous transfer is performed by the initiating client multicasting a payload of the chunk to the rendezvous group.

16. The system of claim 13, wherein the put accept responses are evaluated by each storage server in the negotiating group to select which storage server in the negotiating group is to send a consensus put accept to the initiating client, determine members of the rendezvous group, and determine a designated time and a designated transmission rate for the rendezvous transfer, wherein the consensus put accept is received by the initiating client, and wherein the rendezvous transfer is performed by the initiating client multicasting a payload of the chunk to the rendezvous group at the designated time at the designated transmission rate.

17. The system of claim 11, wherein distributing the chunk within the cluster of storage servers comprises performing a chunk get transaction, the transaction proposal comprises a get request, and the proposal responses comprise get responses.

18. The system of claim 17, wherein the rendezvous group includes at least an initiating client, which is a chunk sink, that initiated the chunk get transaction.

19. The system of claim 18, wherein the rendezvous group further includes a storage server that volunteers to store the chunk.

20. The system of claim 17, wherein the get responses are evaluated by each storage server in the negotiating group to select a designated storage server in the negotiating group to perform the rendezvous transfer, and wherein the rendezvous transfer is performed by the designated storage server at a designated time at a designated transmission rate.

21. A method of distributing a chunk within a cluster of storage servers using a cluster-consensus rendezvous, the method comprising:

receiving a multicast put proposal from an initiating client by a storage server of a negotiating group;

multicasting a proposal response from the storage server to other storage servers in the negotiating group; and

receiving proposal responses by the storage server from the other storage servers in the negotiating group; and

evaluating the proposal responses by the storage server.