SCALABLE TRANSPORT METHOD FOR MULTICAST REPLICATION

• US 20140204940A1
• 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, AIZMAN, Alexander, NOVAK, Robert E.
• Granted Patent: US 9,338,019 B2
• Time in Patent Office: Days
• US Class Current: 370/390
• 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 which encodes data or object metadata within a cluster of storage servers, the method comprising:

encoding the chunk in a sequence of unreliable datagrams; and

multicasting the chunk by transmitting the sequence of unreliable datagrams in a rendezvous transfer to a rendezvous group, which is a multicast group, such that a single transmission of the sequence of the unreliable datagrams results in reception of the chunk by multiple members of the rendezvous group.

2. The method of claim 1 further comprising:

negotiating the rendezvous group by exchanging unreliable datagrams amongst an initiating client and a negotiating group to determine the rendezvous group, wherein the negotiating group comprises a subset of the storage servers, and wherein said exchanging comprises multicasting the unreliable datagrams from the initiating client to the negotiating group.

3. The method of claim 2 further comprising:

determining a designated time and a designated transmission rate for the rendezvous transfer.

4. The method of claim 3 further comprising:

offering a reservation by a storage server granting permission to use an ingress reserved bandwidth on the storage server when the storage server has made a determination to respond to a request from the initiating client and has determined that an aggregate offered bandwidth will not exceed a previously-provisioned ingress reserved bandwidth.

5. The method of claim 2, wherein distributing the chunk within the cluster of storage servers comprises performing a chunk put transaction.

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

7. The method of claim 5 further comprising:

using a client-consensus procedure where an initiating client, which is a chunk source, evaluates delivery options for the chunk put transaction.

8. The method of claim 7 further comprising:

multicasting a put proposal message from the initiating client to the negotiating group; and

unicasting put accept responses from the storage servers in the negotiating group to the initiating client.

9. The method of claim 8 further comprising:

evaluating the put accept responses by the initiating client to determine whether the rendezvous transfer is to be performed based on a number of existing replicas of the chunk indicated by the put accept responses.

10. The method of claim 8 further comprising:

evaluating the put accept responses by the initiating client to determine members of the rendezvous group and the designated time and the designated transmission rate for the rendezvous transfer; and

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

11. The method of claim 5 further comprising:

using a cluster-consensus procedure where each member of the negotiating group evaluates delivery options for the chunk put transaction, wherein the delivery options are evaluated consistently by members of the negotiating group.

12. The method of claim 11 further comprising:

multicasting a put proposal message from the initiating client, which is a chunk source, to the negotiating group; and

multicasting put accept responses from each storage server in the negotiating group to all other storage servers in the negotiating group.

13. The method of claim 12 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.

14. The method of claim 12 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.

15. The method of claim 2, wherein distributing the chunk within the cluster of storage servers comprises performing a chunk get transaction.

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

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

18. The method of claim 16 further comprising:

using a client-consensus procedure where the initiating client evaluates delivery options for the chunk get transaction.

19. The method of claim 18 further comprising:

multicasting a get request message from the initiating client to the negotiating group; and

unicasting get responses from the storage servers in the negotiating group to the initiating client.

20. The method of claim 19 further comprising:

evaluating the get responses by the initiating client to determine which get response is to be accepted.

21. The method of claim 20 further comprising:

multicasting a get accept message from the initiating client to the negotiating group, wherein the get accept message indicates the storage server that is to perform the rendezvous transfer; and

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

22. The method of claim 16 further comprising:

using a cluster-consensus procedure where each member of the negotiating group evaluates delivery options for the chunk get transaction, wherein the delivery options are evaluated consistently by members of the negotiating group.

23. The method of claim 22 further comprising:

multicasting a get request message from the initiating client to the negotiating group; and

multicasting get responses from each storage server in the negotiating group to all other storage servers in the negotiating group.

24. The method of claim 23 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.