Distributed object storage

Abstract

The disclosure provides a system, method and computer-readable storage device embodiments. Some embodiments can include an IPv6-centric distributed storage system. An example method includes receiving, at a computing device, a request to create metadata associated with an object from a client, creating the metadata based on the request and transmitting the metadata and an acknowledgment to the client, wherein the metadata contains an address in a storage system for each replica of the object and wherein the metadata can be used to write data to the storage system and read the data from the storage system. There is no file system layer between an application layer and a storage system layer.

Description

TECHNICAL FIELD

The present disclosure relates storage of data and more particularly to a distributed storage system that utilizes a pool of metadata servers and a pool of storage nodes which utilizes unique addresses for content, such as IPv6 (or similar) addresses.

BACKGROUND

A lot of different distributed storage systems exist, such as the Google file system, Ceph, Hadoop, Amazon EC2 are a few of the most common storage systems. Ceph is an object storage system that optionally provides a traditional file system interface with POSIX semantics. Object storage systems complement but do not replace traditional file systems. One can run one storage cluster for object, block and file-based data storage. Ceph's file system runs on top of the same object storage system that provides object storage and block device interfaces. The Ceph metadata server cluster provides a service that maps the directories and file names of the file system to objects stored within RADOS (Reliable Autonomic Distributed Object Store) clusters. The metadata server cluster can expand or contract, and it can rebalance the data dynamically to distribute data evenly among cluster hosts. This ensures high performance and prevents heavy loads on specific hosts within the cluster.

Storage systems with typical architectures have a number of issues that reduce their efficiency. These issues include many layers of software through which communication must pass to write and read data. The heavy layering increases the complexity of the system which can require detailed configuration and optimization efforts. The current architectures also are difficult to scale given the layering and complexity issues. Furthermore, all these architectures are constructed on the fundamental assumption the disks are the performance bottleneck. Much software engineering has been spent to find solutions (e.g. File System caches) to mask poor disk performances. New solid-state device (SSD) technologies are likely to make deciduous this foundational assumption. As a consequence, a whole industry could literally fall apart and be replaced by new approaches in which the storage devices are not any more considered as the performance bottleneck. These and other issues suggest a need in the art for improved processes for managing data storage.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 illustrates an example system configuration;

FIG. 2 illustrates a layering of software for managing object storage;

FIG. 3 illustrates an approach of the communication of metadata servers and storage nodes;

FIG. 4 illustrates a layered structure and raid storage devices and a server;

FIG. 5 illustrates signal processing for a create request;

FIG. 6 illustrates further the process of placing replicas in connection with the create request;

FIG. 7 illustrates the signal processing and a write request;

FIG. 8 illustrates further processing in connection with the write request;

FIG. 9 illustrates processing in a read request;

FIG. 10 illustrates further processing in connection with a read request;

FIG. 11 illustrates the logical view of the response ability of every actor in the storage system;

FIG. 12 illustrates an object storage architecture;

FIG. 13 an aspect of the storage architecture according to this disclosure; and

FIG. 14 illustrates a method example.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.

Overview

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.

The present disclosure addresses the issues raised above with respect to storing and managing large flow tables on switches. The disclosure aims at solving the problems by collapsing layers and averaging new (IPv6, for example) functionalities such as segment routing. The proposed solution also addresses the CPU/Network potential bottleneck consequence of forthcoming super high performance storage devices.

The disclosure provides a system, method and computer-readable storage device embodiments. An example method includes receiving, at a computing device, a request to create metadata associated with an object from a client, creating the metadata based on the request and transmitting the metadata and an acknowledgment to the client, wherein the metadata contains an address in a storage system for each replica of the object and wherein the metadata can be used to write data to the storage system and read the data from the storage system.

An aspect of this disclosure is that there is no filesystem layer between the application layer and the storage system. In another aspect, the file system can become the application as described herein. The storage system contains the pool of metadata servers and the pool of stored servers. Writing and reading the data from the storage system can be accomplished via an IPv6 address stored in or associated with the metadata. The IPv6 address can identify and/or locate the data. In one example, the IPv6 prefix can be used to represent a group of addresses and/or subnets. Moreover, the IPv6 prefix can represent specific nodes and/or classes of data, objects, storage, etc. Classes can be based on one or more factors such as quality of service (QoS) requirements, priorities, policies, size, partitioning, a similarity, a state, a property, usage characteristics, a preference, a parameter, a data type, storage characteristics, etc. For example, an IPv6 prefix can represent, without limitation, a specific node, a specific type of storage, or a specific type of data.

A metadata prefix can represent a metadata server, a storage node, metadata classes, etc. Metadata replicas have distinct IPV6 addresses and in one aspect would not be identified by a prefix. In some cases, a metadata prefix is assigned to each tenant in a multi-tenant environment. This can enable isolation, improve security, facilitate management, prevent collisions, etc. The client can compute a family of pseudorandom seeded hashes based on at least one of an object name and consecutive integers as seeds. The client can compute a family of pseudorandom seeded X-bit hashes based on an object name. X can be less than or equal to 128. The value can depend on the length of the metadata IPv6 prefix assigned to a storage domain. The organization of metadata servers is unknown to the client and can be dynamic if metadata servers are added or removed. Only the global metadata IPv6 prefix is static. The metadata can include, without limitation, the address for metadata replicas, the address of object replicas, state information associated with the object replicas, object name, object characteristics (e.g., size, properties, etc.), storage node or system information (e.g., access control lists, policies, configuration data, etc.), and so forth. Thus, for example, the metadata, when used to write the data to the storage system, can be utilized to write replica data to the storage system.

The method can further include, by the computing device, determining where to store the data on the storage system based on one or more of a placement policy, system-wide metrics, client recommendations, and quality of service requirements. As previously noted, an IPv6 address can be used to identify the data and/or location of the data, and the prefix associated with the IPv6 address can identify or represent the storage node, storage segment, data class, etc.

Description

The present disclosure addresses the issues raised above. For example, the architecture disclosed herein is flexible, scalable, and not heavily layered as prior approaches. Accordingly, the imposition of the amount of complexity with so many layers can be reduced into a more simplified system. This can reduce the number of disk I/O's, bottlenecks, use of mass storage, and multiple layers. The approach disclosed herein also improves the ability to expand the scaling of the storage system. The present disclosure addresses these problems and other problems by collapsing layers and leveraging IPv6 functionality such as, but not limited to, segment routing.

The disclosure first discusses in more detail some of the issues with standard storage system. Storage systems generally fall under a particular type of architecture 200 shown in FIG. 2. The application layer 202 runs on top of the storage system. The file system layer 204, while often part of the storage system, is not mandatory if the applications are designed to work directly with an object storage 206. There also can be distributed file systems that run directly on a block storage 208 such as the Google File System (GFS). The object storage and/or block storage 210 are considered the heart of the overall storage system. The structures vary a lot between the different distribution storage systems. FIG. 3 illustrates the general architecture 300 for these various layers.

The system 300 stores metadata about the stored objects, files, and/or the whole system on metadata servers 302. Depending on which system, there can be multiple metadata servers (As in the Hadoop Distributed File System or HDFS) or just one (GFS). In these systems, a protocol 304 is designed for the client applications to communicate with the metadata servers 302. The data is ultimately stored in storage nodes 306. The protocol 302 is often based on HTTP. A pool of storage nodes contains the actual data. These nodes 306 are often organized in a structure: a ring, a tree, or any other structure. The protocol 302 is then used for the clients and the metadata nodes 302 to interact with the storage nodes to write or retrieve data, replicate contents at the file system level, load balance or any other features of the system.

FIG. 4 illustrates a storage node structure 400. The storage nodes 402 includes an application layer 404 that is in charge of receiving requests and handling them based on the protocol mentioned above. The application layer 404 usually sits on top of the local file system 406 having partitions that contain stored contents. For local replication, a redundant array of independent disks (RAID) controller 408 can be used to ensure the data is not lost on the storage node. Note that this level of replication is independent from the system level replication. This can lead to redundancies and cost inefficiencies, because this can effectively lead to a high effective replication factor, which in turn means a much lower ratio of effective data stored in the total system storage capacity.

As noted above, there are a number of issues with standard architectures. For example, the software is heavily layered. A client fetching data must communicate through a large number of software layers, which can be as many as seven or eight layers. These layers are not always designed to interoperate in an optimal way. This translates in reading and writing throughput that are often not optimal. Next, the heavy layering also imposes a fair amount of complexity on the operators. Each of these layers requires complex configuration, optimization, parameterization, and so forth. Furthermore, in these kinds of systems, based on the assumption that the disc inputs and outputs (I/Os) are the effective bottleneck of most storage systems, multiple layers are added on top of one another. This means that different software layers are partly designed to reduce the number of I/O's at the cost of more RAM and/or CPU usage. With upcoming large improvements in disk and flash technologies, this is not going to be the case anymore. Storage I/O's are bound to be a lot faster in a few years, shifting the bottleneck from storage I/O's to network bandwidth and even the CPU. Thus, additional software layers that consume CPU cycles are going to become a hindrance more than a help in storage systems.

Most of these systems have limited scaling capacity. The GFS has built itself around a single-master approach. This means the every client interaction with the system has to go at least once through a single master (replicated for failover but not for load balancing) that contains the useful metadata. Even with lightweight metadata, limited interactions and client caching, the approach scales only to a point as the number of clients grow. Ceph has chosen not to have metadata servers (this is not completely true: metadata servers will need to keep track of the cluster map but this is not usually the main bottleneck of Ceph-based systems). Instead, it places data deterministically by hashing the object name and finding a storage node target according to the hash. While this effectively removes the master bottleneck of GFS, this implies that when a storage nodes is added or removed (voluntarily or upon failure), a non negligible quantity of data has to be moved on the new target node of its deterministic hash. Analytically, the order of magnitude of data that has to be moved is around the capacity of the device added or removed. While this works for small clusters where devices are not often added or removed, this does not easily scale for bigger clusters having numerous big storage nodes.

Furthermore, the capacity of storage devices increases much faster than bandwidth capacity. That is to say, in a few years from now, the network capacity won't be able to sustain adding or removing a petabyte storage node.

The protocols used for intra and inter layers (between metadata servers, storage nodes and clients) create additional overhead for every communication. This overhead is naturally augmented by the complexity of the system. This is because the more layers there are, the more difficult it is to optimize their interactions and deal with exceptional or rare cases without decreasing the overall efficiency.

The disclosure next turns to FIG. 1 which generally describes a computer system, such as a computer client or server.

FIG. 1 illustrates a computing system architecture 100 wherein the components of the system are in electrical communication with each other using a bus 105. Exemplary system 100 includes a processing unit (CPU or processor) 110 and a system bus 105 that couples various system components including the system memory 115, such as read only memory (ROM) 120 and random access memory (RAM) 125, to the processor 110. The system 100 can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 110. The system 100 can copy data from the memory 115 and/or the storage device 130 to the cache 112 for quick access by the processor 110. In this way, the cache can provide a performance boost that avoids processor 110 delays while waiting for data. These and other modules can control or be configured to control the processor 110 to perform various actions. Other system memory 115 may be available for use as well. The memory 115 can include multiple different types of memory with different performance characteristics. The processor 110 can include any general purpose processor and a hardware module or software module, such as module 1132, module 2134, and module 3136 stored in storage device 130, configured to control the processor 110 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 110 may essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing device 100, an input device 145 can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 135 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing device 100. The communications interface 140 can generally govern and manage the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.

Storage device 130 is a non-volatile memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs) 125, read only memory (ROM) 120, and hybrids thereof.

The storage device 130 can include software modules 132, 134, 136 for controlling the processor 110. Other hardware or software modules are contemplated. The storage device 130 can be connected to the system bus 105. In one aspect, a hardware module that performs a particular function can include the software component stored in a computer-readable medium in connection with the necessary hardware components, such as the processor 110, bus 105, display 135, and so forth, to carry out the function.

This disclosure now turns to a more detailed description of the various concepts and examples herein. Among other things, this disclosure proposes a distributed and flexible storage system with a minimal number of layers. Thus, an example architecture can include the removal of the file system 204 shown in FIG. 2 such that the proposed architecture could simply include the application layer 202, an object storage layer 206 in a block storage layer 208. The application layer 202 can represent any application running on top of the storage system 206/208 (210). The system 210 contains a pool of metadata servers and a pool of storage servers.

There are several concepts that apply to the present disclosure. A first concept is that any kind of entity (for example, an object, metadata, a video, a file, and so forth) in the system can be identified and represented by a set of IP addresses, such as an IPv6 address. For example, the IPv6 protocol can provide prefixes which can be used to represent a “group” of such IPv6 addresses. The set of IP addresses can take into account the metadata replicas and the object replicas IPv6 addresses. In one aspect it could be said that the primary metadata replica IPv6 address (the first obtained via hashing) suffices to identify the object.

As the structure contemplated for metadata disclosed herein is an IPv6 address in one aspect, this disclosure shall briefly discuss the structure of an IPv6 address. While IPv6 is not required, and other structures are contemplated, IPv6 is discussed as one embodiment. IPv6 addresses have 128 bits, although for this disclosure, the addresses may have less than 128 significant bits. The design of the IPv6 address space implements a different design philosophy than in IPv4, in which subnetting was used to improve the efficiency of utilization of the small address space. In IPv6, the address space is deemed large enough for the foreseeable future, and a local area subnet most of the time uses 64 bits for the host portion of the address, designated as the interface identifier, while the most-significant remaining bits are used as the routing prefix.

The identifier is only unique within the subnet to which a host is connected. IPv6 has a mechanism for automatic address detection, so that address auto-configuration always produces unique assignments. The 128 bits of an IPv6 address are represented in 8 groups of 16 bits each. Each group is written as four hexadecimal digits and the groups are separated by colons (:). An example of this representation is 2001:0db8:0000:0000:0000:ff00:0042:8329.

An IPv6 packet has two parts: a header and payload. The header consists of a fixed portion with minimal functionality required for all packets and may be followed by optional extensions to implement special features. The fixed header occupies the first 40 bytes (320 bits) of the IPv6 packet. It contains the source and destination addresses, traffic classification options, a hop counter, and the type of the optional extension or payload which follows the header. This Next Header field tells the receiver how to interpret the data that follows the header. If the packet contains options, this field contains the option type of the next option. The “Next Header” field of the last option, points to the upper-layer protocol that is carried in the packet's payload.

Extension headers carry options that are used for special treatment of a packet in the network, e.g., for routing, fragmentation, and for security using the IPsec framework. Without special options, a payload must be less than 64 KB. With a Jumbo Payload option (in a Hop-By-Hop Options extension header), the payload must be less than 4 GB.

Unlike with IPv4, routers never fragment a packet. Hosts are expected to use path maximum transmission unit discovery (PMTUD) to make their packets small enough to reach the destination without needing to be fragmentation. PMTUD is a standardized technique for determining the maximum transmission unit size on the network path between two IPv6 hosts.

An IPv6 address can be abbreviated to shorter notations by application of the following rules. One or more leading zeroes from any groups of hexadecimal digits are removed; this is usually done to either all or none of the leading zeroes. For example, the group 0042 is converted to 42. Another rule is that consecutive sections of zeroes are replaced with a double colon (::). The double colon may only be used once in an address, as multiple use would render the address indeterminate. Some recommend that a double colon must not be used to denote an omitted single section of zeroes.

An example of application of these rules is as follows: Initial address: 2001:0db8:0000:0000:0000:ff00:0042:8329. After removing all leading zeroes in each group: 2001:db8:0:0:0:ff00:42:8329. After omitting consecutive sections of zeroes: 2001:db8::ff00:42:8329. The loopback address, 0000:0000:0000:0000:0000:0000:0000:0001, can be abbreviated to ::1 by using both rules.

Hosts verify the uniqueness of addresses assigned by sending a neighbor solicitation message asking for the Link Layer address of the IP address. If any other host is using that address, it responds. However, MAC addresses are designed to be unique on each network card which minimizes chances of duplication.

The pool of metadata servers that is organized in an architecture, which could be a binary tree but is not limited to such a binary tree. The metadata servers can contain metadata for the objects. They are in one example addressed by a range of IP addresses, each metadata server being assigned an IPv6 prefix (an example of which is defined above), i.e., not a single address. The aggregation of the prefixes of the metadata servers belonging to the same storage domain can be fixed and can be the metadata system IPv6 prefix. For example, if the metadata system prefix is 2001::0/64 and there are 2 metadata servers, they will respectively hold the prefixes 2001::0/65 and 2001::8000:0:0:0/65. If there are 4 metadata servers, they will respectively hold the prefixes 2001::0/66, 2001::4000:0:0:0/66, 2001::8000:0:0:0/66 and 2001::b000:0:0:0/66, hence the possible idea of binary tree.

The structure described herein enables the client to only need to know the metadata system prefix and doesn't apply to storage nodes, as only the metadata servers need to know in advance the storage nodes IPv6 prefixes. The pool of storage nodes can be organized in the same type of architecture. The storage nodes will contain the objects themselves. They are addressed by a range of IP addresses, each storage node being assigned an IPv6 prefix. A storage node is a logical storage device on top of which an application runs that is able to handle requests, assign a unique identifier (such as an IPv6 address or other protocol address) to stored object and retrieve the object according to the unique identifier. The system presented herein is fundamentally not a block storage system as that term is traditionally used for existing systems. It is a native object storage system that behaves as a block storage when the objects all have the same size. There is an advantage to this approach since the present disclosure can support several block storage systems having different block sizes as well as different object storage systems all of them at the same time and possibly sharing the same storage physical backend infrastructure, i.e., the storage nodes.

For example, a /110 prefix with fixed size objects of size 1 MB (for larger typical objects) could address up to approximately 4 TB of data. In another example, a /96 prefix with fixed sized objects of size 8 KB (a typical block size for a file system) could address up to approximately 32 TB of data. Thus, through the usage of different prefixes on the same storage system backend, different block storage systems with different block sizes could be built.

In one aspect, the identifier can be an IPv6 address which can identify the data, and its prefix can be assigned to the storage node itself. For backward compatibility with existing systems, a library, or any equivalent, will be provided to expose a classical object level interface thus keeping the underlying technical details hidden to the application.

Next, example operations of the distributed storage system are described. First, the process of creating an object is described with reference to FIG. 5. FIG. 5 illustrates a system 500 used to create an object. To create the object, the client library 502 computes a family of pseudorandom seeded X-bit hashes based on the object name and consecutive integers as seeds. In one example, X is less than 128 and depends on the length of the metadata system IPv6 prefix 204. The size of the family is the metadata replication factor and is configurable in the library or from another entity. A high replication factor increases the safety of metadata at the cost of a higher storage overhead for metadata and increases latency in the event where all metadata needs to be updated. High replication also increases the load balancing capabilities for metadata access, which is useful for objects accessed concurrently by a high number of clients.

A first metadata server 504 is in charge of creating the metadata. What the metadata contains can be variable and customized. It is possible that the client 502 creating an object must provide some information to the first metadata server 504 for it to construct the metadata. Several pieces of information can be contained within the metadata. The metadata can include the address of all metadata replicas, in the general case they should just be consecutive hashes of the object name. However, the metadata server 504 could refuse to hold some metadata for several reasons, such as a server could be down, could be full, and so forth. In this case, the next pseudorandom seeded hash would be used as a destination.

The metadata servers 504 holding the replicas should actually notify the former replica holders to complete their metadata. The metadata can also include the address of all object replicas and possibly their state, such as whether they are stale or up-to-date. There are two phases for this process. At the object creation, the first metadata replica holder places all object replicas, according to a given policy. The policy can be determined partly by the storage system itself and partly by the client, and this is a customizable process. When the client first receives metadata, the addresses for the object replicas are generic addresses for the storage node that they should be stored on. For example, the first or last address of the prefix of the storage nodes can be assigned. Later, storage nodes assign a unique IPv6 address to every replica and metadata is updated. The metadata can also include the object name, so that hash collisions can be dealt with. These are improbable but still could happen.

The metadata server 504 also represents replica metadata servers. Multiple metadata servers can be utilized for redundancy and load-balancing. A client may submit a metadata request based on their computation of the metadata hash. If that server is down or overloaded, the client can compute another metadata hash and access replica metadata at a different server.

Any other information relevant to the metadata level for the storage system, such as access control lists (ACLs), total duration of the object in a video chunk, and so forth, can also be contained within the metadata. What the metadata contains is highly customizable. However, it should be remembered that at any time, one of the metadata fields can change, and all metadata replicas have to be updated. For example, for a regular file, every write on the file increments the file size. As such, in one aspect, the system does not store the size of the file in the metadata but rather at the beginning of the object containing the text file itself. Utilizing the various information that the metadata should contain can mean that the metadata creation process is dependent upon the desired policy, both for resiliency and consistency.

As shown in FIG. 5, one example approach is that the client 502 sends a create request to a metadata server 504. The metadata server creates the metadata and replication data and returns the metadata and an acknowledgment to the client 502. In one aspect, the request may include some user designated requirements such as a quality of service, a type of storage hardware, a geographic location, accessibility parameters, and so forth. Thus, if the request is an initial request to write an object to a storage node, particular requirements for that process can be articulated. Matching a request for certain parameters with the actual process of writing or reading data can be accomplished in a number of different ways. One example approach could be performed at the first time when the system receives the metadata prefix. When a user or an administrator requests a certain parameter, the metadata server 504 can essentially match that request with storage nodes implementing policies or qualities of service that match the required parameter. Thus, a certain storage node or group of storage nodes may implement policies (certain QOS, hardware type, etc.) that match the requirement in the request and the metadata created by the metadata server will direct the client to those storage nodes.

In an alternate approach, a hybrid storage servers pool can be established in which the client asks for a QOS (or some other parameter) in the create request. In this scenario, the metadata server holding the first metadata replica could provision or establish the storage of the object by selecting the storage nodes fulfilling the requested QoS and implement the required parameters for the object and its replicas, if any.

FIG. 6 illustrates another aspect of this feature with the graphic 600. The client 502 sends the create metadata request. Three different pathways are described which identify a destination through the use of a hash such as dest: hash(name,0), dest: hash(name, 1) and dest: hash(name, 2). The metadata server 504 places replicas of the data in various storage locations. The metadata from the various metadata servers is returned to the client 502.

FIG. 7 illustrates a write operation 700. To write an object, the client library first fetches the object metadata through metadata request to the metadata server 504. To retrieve the metadata, the client computes the X-bit hashes previously mentioned, which gives the IPv6 address of the metadata. For metadata load balancing, the client 502 can compute any of the X-bit hashes of the previous hash family. With the metadata, the client 502 sends a write request with the data to the dedicated storage nodes 506. This can be done in parallel for the client 502 to ensure that data has been written on all storage nodes. It can also be done in sequence so that the client 502 only waits for a number of storage nodes to acknowledge thus reducing latency, at the cost of a slightly higher probability of failure.

An example policy is a classical quorum policy. For a X:Y quorum policy (typical values are 2:3 or 3:5 depending on the resiliency policy), the client 502 writes data on the primary replica. This primary replica then updates the other replicas. The client receives an acknowledgment only when X out of the Y replicas have been written, so that the main replica receives the acknowledgment for at least one of the replicas for a 2:3 policy. This is also influenced by the expected consistency policy, which is: the smaller the ratio of a quorum policy, the fastest the client gets an acknowledgment, so the smallest the latency is, but the highest chance of having inconsistent replicas exists. This can be a problem if the application is reading a replica that hasn't been updated of the just-modified object after having received an acknowledgment for this update. In one example, if the administrator wants high reliability, the system can establish five replicas of an object. The purpose for such a high number of replicas can be for security, load-balancing, and so forth. When the system is storing the five replicas, one may not want to wait until all five replicas are completely stored before sending an acknowledgment. A policy could be established in which the storage nodes are to send an acknowledgment after storing three of the five copies. Then, to ensure that the five replicas are successfully stored, the policy could include, if there are errors in storing the fourth or fifth copies, that repairs can be made from one of the successfully stored first three copies. This provides one nonlimiting example of got the kind of flexibility that can be available in the storage system used utilizing the IPV6-based approach disclosed herein. Because of this flexibility, users can more easily manage the storage of their data. For example, large video files can be stored for further processing or chunked into multiple smaller pieces and because of the manner in which the storage of data is managed as disclosed herein, any approach which is desired can be easily managed using the IPv6 based storage management system. A policy could be established to store one main copy of an object on the SSD and backup copies on a hard drive.

FIG. 8 illustrates another aspect of the write concept. The client 502 sends a metadata request to the metadata server 504. The metadata server 504 returns the metadata to the client 502. The client 502 sends a write request utilizing the metadata, with the data. The example format is dest: storage node 1, dest: storage node 2, etc. The process includes writing the data to the destination node and returning an acknowledgment to the client 502.

FIG. 9 illustrates an example structure 900 for a read process. To read an object, the client retrieves metadata the same way as for a write request. The client 502 sends a read request to one of the storage nodes based on the received metadata from the metadata server 504. The read request is typically the most frequently used request. There may be an opportunity to load balance, either by having the client 502 selecting a random storage node between the storage nodes that contain the object or on the metadata server side by sending only partial metadata containing a subset of the list of storage nodes holding the object. In some cases, the client 502 can store the metadata for an object. If the client recently retrieve the audit object from storage and has a metadata in its cache, the client could simply submit a read request again to the storage node 506 without requesting the metadata from the metadata server 504.

FIG. 10 illustrates the client 502 sending the metadata request to the metadata server 504 that returns the metadata or, as noted above, partial metadata containing a subset of the list of storage nodes that hold a particular object. Utilizing the metadata, the client 502 sends a read request to the storage node X, or multiple storage nodes, which return the object to the client.

Note that all these operations are transparent to the user application. A client library provides a regular object storage interface to applications using it. This library is configurable to allow for different policies regarding data safety, data and metadata placement, and so forth. The backend storage requires no configuration or change for it to provide different policies on this matter, which greatly simplifies the administration.

FIG. 11 illustrates an overall system 1100 which includes a logical view of the responsibilities of the various actors in the storage program. The client device 502 initiates the request to perform such functions as close, open, write, read, destroy. The client library associated with the client device 502 allows for customizable configuration, computes metadata hashes, interacts with metadata servers and storage nodes, and provides an object storage semantic interface to the client application. The metadata management occurs between the client device 502 and the metadata server 504. The metadata server 504 can be considered a request handler and creates the metadata, oversees the metadata servers and storage nodes repair when required, places data based on systemwide metrics and possibly client recommendations, and can perform load-balancing of data requests and access. The data placement and metadata update occurs between the metadata servers 504 and the storage nodes 506.

The storage node 506 represents request handlers that store the data, and assigns a unique IPv6 identifier to each content replica stored. The data writing and reading occurs between the client device 502 and the storage node 0506.

One example of the system disclosed in FIG. 11 is as follows. A system can include at least one storage node and at least one metadata server, wherein the system is configured to communicate with a client device and the at least one storage node for managing a storing of objects. The at least one metadata server can be configured to receive a request to create metadata associated with an object to be stored, wherein the request comprises a computed metadata hash that is computed at the client device, create the metadata in response to the request and place the object for storage at the storage node based on at least one of system-wide metrics or a client recommendation. Other factors can be used as well for making storage placement decisions. Such can include, but are not limited to, one or more of quality of service requirements, access control lists, load-balancing, premium pricing, user priority, user profile data, data regarding performance of the storage system, and so forth. The at least one storage node can be configured to receive and store the object and assign a unique IPv6 identifier to each replica of the object.

Other characteristics of the storage system include the following features. The system is flexible. Different IPv6 prefixes can be assigned for different types of storage, such as flash, hard drive, and so forth. This effectively makes the nature of the performance of storage almost transparent to the system by just addressing different stores types by selecting different addresses. In a cloud scenario where there are multiple tenants, a metadata prefix can be assigned to each tenant, so that isolation is insured and no collision happens between different users. Through the use of different prefixes, the system can also support different policies for replication, repair, load-balancing, data placement, ready partition of contents, and so forth. The used hashing function can vary to fit the properties that one request for a specific application. For example, a hashing function can be designed to yield close hashes for objects with similar names or oppositely to have a cascade effect, which means that two names with only a bit different can give completely different hashes. In another aspect, the flexibility of the system is provided by the metadata being customized. The metadata can contain enough information to locate the contents, but could also contain many other parameters or types of information, such as access control lists, size, duration a video chunk, or any other type of object metadata.

The system disclosed herein is also not heavily layered. For example, the IPv6-centric design allows for the client to directly connect to the metadata servers and the storage nodes without the need for inter-node communication and a complex metadata maintenance process. The system map is the network itself and does not have to be consistently maintained across all nodes, or shared with clients, and so forth. The client accesses data much like it would do when it uses a simple file system. The client first batches metadata (a functional equivalent of data stored in the filesystem inodes) that give the client information on where the data or the blocks are. In the file system case, the metadata stays totally hidden to the client.

Other benefits of the approach disclosed above include that it does not consume much bandwidth. The approach does not use much bandwidth because the bandwidth is used as almost exclusively dedicated to data transmission between clients and servers and repairs, if need be. The only overhead is the very lightweight request protocol for signaling messages and metadata migration when new servers are added to the metadata server pool. This migration can be caused by the metadata system prefix being static, which means adding or removing metadata servers requires a change in the metadata servers prefix allocation, which in turn leads to a migration to fit the new distribution. This is similar to the Ceph example, only the concept is metadata instead of data. Note that metadata are usually much more lightweight than the content itself, and the metadata can go as small as a few KB for a multi-GB object. This effectively prevents the kind of overhead that other systems suffer when adding a new server.

Another benefit of the approach is that it is easily manageable. Different policies can be defined for multiple aspect of the whole system and each one of them is associated with an IPv6 prefix. For example, one can imagine a system with two prefixes. One prefix would be dedicated to highly requested and often accessed objects, that have a high replication factor. For example, for load-balancing and resiliency sake, such objects could be highly replicated. The objects are stored on expansive flash discs, or on other dedicated storage means compared to regular object with a smaller replication factor and stored on traditional hard disks, corresponding to the other prefix. Another use could be to give a prefix to each data center and to force the system to store replicas of both metadata and data on different prefixes to have the whole data center level of resiliency. A further use case could be to provide different qualities of service to different types of users for a content delivery network (CDN): some premium range of users would have access to some prefix that has a small capacity caches (well distributed) that store a high quality video content, while regular users would only be allowed to access medium quality content stored under another prefix namespace.

In another aspect, accessing the content can be easily monitored by simple traffic inspection. Each IPv6 address corresponds to one content. Thus, obtaining valuable information about the storage system itself is a very simple and effective task. The use of the IPv6 structure (or similar structure) to address content is an effective feature of an example distributed storage system. The fact that a client request can be routed all the way down to the actual object means that there is no need for redundant communication between nodes to know how to reach any specific content. It also means that every existing Layer 3 tool can be used for different purposes. For example, segment routing can benefit the system for load-balancing between paths by just giving a client a segment routing list instead of just an address pointing to the content. Additionally, the system map is fully stored in the network itself, contrary to other storage systems, where different system maps have to be created, maintained, kept consistent between devices, regularly updated, distributed to every client, and so forth. In the system disclosed herein, the client library only has to know IPv6 prefixes corresponding to different policies. This prefix is static, and each element of the underlying architecture is transparently addressed by the network. The addition or the removal of new storage devices only translates in a few route changes in the datacenter routers and a light metadata rebalancing to fit the new architecture, which are operations the clients are oblivious to. Furthermore, aggregating statistics about network flows is easy and can be done in the network layer. For traditional distribution storage systems, the system itself has to support and integrate analytics tools for this purpose that can be complex and require additional resources on each node.

Another benefit of the approach disclosed herein is that it is easy to build upon. The design of the storage system allows for the incorporation of erasure coding techniques, such techniques encode data in several fragments that are distributed amongst different nodes and have a non-integer replication overhead. One can typically achieve the same resiliency in a 1, 4 ratio. For example, 14 encoded shards from data originally striped in 10 fragments present a better resiliency level than 3 stored replicas, provided they are stored on different storage nodes, effectively more than halving the storage overhead. One could incorporate the encoding information in the metadata into the disclosed storage system rather than just a replica's location. This comes, however, with a price in that the encoding utilized will consume computing resources, require complex metadata and add an encoding/decoding latency. Any traditional authentication method can also be implemented so that metadata servers verify the identity of clients before responding to any query.

The system can be an IPv6 centric distributed storage system that builds around the pool of organized metadata servers and a pool of storage nodes. Both pools are flat pools and do not follow a master/slave architecture so that there is no artificial bottleneck or single point of failure. The system can be globally fully distributed and resilient (No SPOF) and can support elaborated load-balancing policies as well as various deployment models. The system's applicability can include, without limitation, from DC Central storage system to a fully distributed storage suitable for IoE applications.

FIG. 12 presents an example object storage architecture 1200 which can be contrasted with the architecture 1300 shown in FIG. 13. Based on its fully distributed architecture 1300, there is no system wide bottleneck, especially during metadata access (contrary to 1202 for the map or GFS for the singe master access). The system 1202 includes monitors 1206 that maintain the cluster map, distribute the cluster map to clients, reach consensus through Paxos and send a fetched cluster map to the client 1204 each time it changes. In system 1202, a map has to identify every node and the monitors have to have knowledge of every node in the system. The more nodes in the system, the more complex the map becomes. In the system 1202, the client 1204 knows the monitors addresses and knows the hashing function. The client 1204 writes and reads to the database 1210 and directly contacts the object storage devices (OSDs) following the current cluster map and the object hash. The OSDs 1210 store the objects, are organized in a cluster map, and deal with the replication issue. An administrator 1208 sets up the cluster and administrates the nodes.

FIG. 13 illustrates another aspect of the present disclosure. The general concept is to move everything regarding managing the storage of data into the network. Every part of the architecture 1300 can be upscaled by adding more dedicated servers 1310 without impacting the rest of the system. The storage nodes 1310 store the objects, are organized in a cluster map, and deal with replication. The client 1304 retrieves object metadata from the metadata nodes 1306, which store the object metadata and answer the requests addressed to a sub-prefix, and place data following a placement policy which can be dynamic. The client 1304 knows the metadata prefix and the hashing function. The client only needs to know the single metadata prefix to address the whole storage domain which simplifies the amount of data the client needs. The client 1304 writes and reads to the storage nodes 1310 and sends requests to IPv6 addresses stored in object metadata. An administrator 1308 sets up the cluster, maintains a cluster map, and administrates the notes.

A difference between existing storage systems. Everything is identified through the IPv6 protocols or headers. This means that the data is accessible through the network. The client only needs to know the IPv6 prefix of the storage domain that the client links to. This simplifies the most—the client does not have to know what is behind the prefix. It could be one node or 100 nodes. The simplicity is achieved by using the pseudorandom function which hashes the object name and outputs an IPv6 address which has a prefix. When the client desires to write or receive an object, it only has to hash the object name which will give a metadata address, which address will be inside the metadata system prefix. The client will send the request to the address, which address will correspond to a sub-prefix that is held by a metadata server. In FIG. 13, the “M/80” prefix would be split into three as there are three nodes shown (by way of example). Every node will have contiguous prefixes. If you add a new metadata node, to increase the size of the system, you just split the prefix again, and give a part of the prefix to a new metadata node, which will not change the prefix. The metadata system prefix is fixed. The metadata is very light, which is a small amount of information. The metadata might be the size or the type of object. Thus, in FIG. 13, the prefix (M/80) is fixed and the information is simple, rather than a complex cluster map that has to be updated. Additionally, in FIG. 12, the system hashes the object name to find where you store the object. In FIG. 13, you has the object name to find where you store the metadata. In FIG. 13 you balance light metadata when a metadata server is added or removed, whereas the system in FIG. 12, the system balances the objects when a new OSD is added or removed.

Only metadata are redstributed when a new metadata node is added or removed (unlike system 1202), which keeps the network usage overhead almost minimal during maintenance operations in the datacenter. The number of software layers is kept minimal (unlike other distributed storage systems). This means that computing resources are kept minimal. The voluntarily clean and simple design of the system, as well as its complexity with the network means that there is no need to maintain different maps, distribute them amongst nodes and keep them consistent. The simplicity of the present system also allows for a highly flexible storage system that permits the administrator 1308 to very easily and transparently define totally different policies for different parts of the storage system. The IPv6-centric design of this system, in addition to allowing for the simplicity and flexibility that is already pointed out, makes the administration and analysis of the storage system very easy through the use of unique IPv6 addresses for content. All of these characteristics drastically improve read/write performance and allow for high throughput, easy management and simple analytics gathering.

The system disclosed herein can be independent from the entities using it (the client) and aims at storing very generic data that can range from very small to very large data. It is not simply a mesh network of storage nodes. Furthermore, the disclosure proposes not only to identify data by their IPv6 identifies, but also to classify storage classes by IPv6 prefixes, meaning that instead of combining just identification and location, the disclosure combines identification, location and QoS required for the data. This is an important step in facilitating the maintenance and the organization of a generic distributed storage system, e.g. a data center.

Storing replicas on highly different locations ensures that a localized power failure or accident won't bring down all the available replicas. This is why the ability to define several metadata prefixes can be used to define different failure domains. The approaches disclosed herein can shift the complexity of maintaining a cluster map that has to be distributed to clients and kept self-coherent to the network. In some cases, only the orchestrator (that clients do not access) has to maintain a structure that allocates IPv6 prefixes to metadata nodes. Other than that, clients may only require limited, static information bits, like the system metadata IPv6 prefix or other configuration details, which typically may not change over time. Additionally, this information may not be ‘consciously’ owned or managed by the client since it may be a client library configuration parameter. The capacity to scale the metadata side of the storage system is advantageous because it allows much more flexibility in the storage system designs as well as for operating the system. It can almost indefinitely grow whereas other systems which have a single master node will always in the end be bounded by the capacity of the master node to deal with all incoming requests.

In some cases, the storage for metadata as well as actual client data can be scaled independently, to allow for widely different scenarios (few big objects, small metadata and few metadata servers; numerous small objects, comparable size metadata, and numerous metadata servers). With large amounts of data in the storage system, under the approach in FIG. 12, when one adds new nodes to the storage system, terabytes of data may need to be moved, which is very cumbersome. Thus, scaling and redistribution of data becomes problematic. Using IPv6 is used to provide more finely tuned data for the system. Different policies could be applied to different prefixes. An orchestrator can manage those policies for particular prefixes. Thus, a certain quality of service, or certain hardware profile, or geographic location, could be associated with a certain prefix or sub prefix. Thus, when a client seeks the object metadata for accessing the object or writing the object, the orchestrator can apply the policy for that zone or that prefix. The whole storage system is managed by using different IPv6 prefixes and thus all of the complexity is within the network.

In one example, geographic control or policies can be implemented. For example, if an administrator wants storage nodes to be established across a particular geographic location, such as California and Alaska, the system can assign an IPv6 prefix or prefixes to storage nodes in those geographic locations. Once the assignments are made, policies can be established to route or distribute objects to be stored on those particular nodes in those geographic locations. Thus, through the assignment of addresses or IPv6 prefixes, one can manage the geographic topology of a network in an efficient manner. Another advantage is that identifying storage locations with IPv6 prefixes can also simplify the view of the network in that even if data is moved from one physical storage node to another, the logical view of the stored objects can remain the same. The physical location of the data does not matter.

FIG. 14 illustrates a method embodiment. The method embodiment includes receiving, at a computing device, a request from a client to create metadata associated with an object (1402), creating the metadata based on the request (1404) and transmitting the metadata and an acknowledgment to the client. The metadata can contain an address in a storage system for each replica of the object and can be used to write data to the storage system and read the data from the storage system (1406). The system can open up a connection between the client 502 and the metadata server 504 according to the address. If the node 504 is down, there are metadata replicas (for replication as well as load balancing), so the client can make another request by computing another metadata hash. With the created metadata from the metadata server, a connection can be established between the client 502 and the storage node 506 for writing or retrieving data. The storage node 506 will, in a write scenario, assign a unique IPv6 identifier to each version of the object stored. If the operation is a read operation, the storage node 506 will provide the data to the client device 502.

No filesystem layer is required between the application layer and the storage system. The storage system contains the pool of metadata servers and the pool of stored servers. Writing and reading the data from the storage system can be accomplished via an IPv6 address stored in the metadata. IPv6 prefixes can be used to represent a group of addresses or can be used to provide tailored writing or reading to or from the storage system according to a policy. In another aspect, a metadata prefix can be assigned to each tenant in a multi-tenant environment. The client can compute a family of pseudorandom seeded hashes based on an object name or consecutive integers as seeds. The client can also compute a family of pseudorandom seeded X-bit hashes based on an object name, wherein X is less than or equal to 128. In another aspect, the metadata, when used to write the data to the storage system, is utilized to write replica data to the storage system. For example, the metadata can include information for writing replica data, including identification information for the replicate data and storage system.

The method can further include, by the computing device, determining where to store the data on the storage system based on a placement policy, system-wide metrics, client recommendations, and/or quality of service requirements. Other factors can also be considered for determining where to store data, such as state information, conditions, statistics, preferences, data characteristics, etc. The method can also assign an IPv6 address to the data, which can identify the data and the location of the data. As previously explained, the method can also use prefixes, such as IPv6 prefixes for storing, maintaining, identifying, and/or classifying metadata, metadata servers, data storage nodes, objects, data characteristics, data requirements, tenants, etc.

The distributed storage system above can be described as a native object storage system which behaves as a block storage system when the objects all have the same size.

In some embodiments the computer-readable storage devices, mediums, and memories can include a cable or wireless signal containing a bit stream and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals per se.

Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from computer readable media. Such instructions can comprise, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible over a network. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and so on.

Devices implementing methods according to these disclosures can comprise hardware, firmware and/or software, and can take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and so on. Functionality described herein also can be embodied in peripherals or add-in cards. Such functionality can also be implemented on a circuit board among different chips or different processes executing in a single device, by way of further example.

The instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functions described in these disclosures.

Although a variety of examples and other information was used to explain aspects within the scope of the appended claims, no limitation of the claims should be implied based on particular features or arrangements in such examples, as one of ordinary skill would be able to use these examples to derive a wide variety of implementations. Further and although some subject matter may have been described in language specific to examples of structural features and/or method steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or acts. For example, such functionality can be distributed differently or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims. Moreover, claim language reciting “at least one of” a set indicates that one member of the set or multiple members of the set satisfy the claim.

It should be understood that features or configurations herein with reference to one embodiment or example can be implemented in, or combined with, other embodiments or examples herein. That is, terms such as “embodiment”, “variation”, “aspect”, “example”, “configuration”, “implementation”, “case”, and any other terms which may connote an embodiment, as used herein to describe specific features or configurations, are not intended to limit any of the associated features or configurations to a specific or separate embodiment or embodiments, and should not be interpreted to suggest that such features or configurations cannot be combined with features or configurations described with reference to other embodiments, variations, aspects, examples, configurations, implementations, cases, and so forth. In other words, features described herein with reference to a specific example (e.g., embodiment, variation, aspect, configuration, implementation, case, etc.) can be combined with features described with reference to another example. Precisely, one of ordinary skill in the art will readily recognize that the various embodiments or examples described herein, and their associated features, can be combined with each other.

A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A phrase such as a configuration may refer to one or more configurations and vice versa. The word “exemplary” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

Moreover, claim language reciting “at least one of” a set indicates that one member of the set or multiple members of the set satisfy the claim. For example, claim language reciting “at least one of A, B, and C” or “at least one of A, B, or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.

Claims

1. A method comprising: receiving, at a computing device, a request to create metadata associated with an object from a client;creating the metadata based on the request; andtransmitting the metadata and an acknowledgment to the client;wherein the metadata contains an address in a storage system for each replica of the object and wherein the metadata can be used to write data to the storage system and read the data from the storage system;wherein the metadata comprises an IPv6 prefix for a group of IPv6 addresses which are assigned to a the replicas and the object.

2. The method of claim 1, wherein writing and reading the data from the storage system is accomplished via an IPv6 address stored in the metadata.

3. The method of claim 1, wherein the client computes a family of pseudorandom seeded hashes based on at least one of an object name and consecutive integers as seeds.

4. The method of claim 1, wherein the client computes a family of pseudorandom seeded X-bit hashes based on an object name, wherein X is less than or equal to 128.

5. The method of claim 1, wherein the metadata, when used to write the data to the storage system, is utilized to write replica data to the storage system.

6. The method of claim 1, further comprising, by the computing device, determining where to store the data on the storage system based on one or more of a placement policy, system-wide metrics, a client recommendation, and quality of service requirements.

7. The method of claim 1, wherein a metadata prefix is assigned to each tenant in a multi-tenant environment.

8. The method of claim 1, wherein no filesystem layer exists between an application layer and a storage system layer.

9. A non-transitory computer-readable storage device storing instructions which, when executed by at least one processor, cause the at least one processor to perform operations comprising: establishing a static rule to distribute a first flow to a first server and a second flow to a second server;receiving a request to create metadata associated with an object from a client;creating the metadata based on the request, wherein the metadata comprises an address for each replica of the object; andtransmitting the metadata and an acknowledgment to the client, wherein the metadata contains the address in a storage system for each replica of the object and wherein the metadata can be used to write data to the storage system and read the data from the storage system;wherein the metadata comprises an IPv6 prefix for a group of IPv6 addresses which are assigned to a the replicas and the object.

10. The non-transitory computer-readable storage device of claim 9, wherein the address is an Ipv6 address, and wherein writing and reading the data from the storage system is accomplished via the Ipv6 address stored in the metadata.

11. The non-transitory computer-readable storage device of claim 9, wherein the client computes a family of pseudorandom seeded hashes based on at least one of an object name and consecutive integers as seeds.

12. The non-transitory computer-readable storage device of claim 9, wherein the client computes a family of pseudorandom seeded X-bit hashes based on an object name, wherein X is less than or equal to 128.

13. The non-transitory computer-readable storage device of claim 9, wherein the non-transitory computer-readable storage device stores further instructions which, when executed by the at least one processor, cause the at least one processor to perform further operations comprising: determining where to store the data on the storage system based on one or more of a placement policy, system-wide metrics, a client recommendation, and quality of service requirements.

14. A system comprising: at least one non-transitory computer readable medium storing instructions:at least one processor programmed to cooperate with the instructions to perform operations comprising: receiving, at a computing device, a request to create metadata associated with an object from a client;creating the metadata based on the request; andtransmitting the metadata and an acknowledgment to the client;wherein the metadata contains an address in a storage system for each replica of the object and wherein the metadata can be used to write data to the storage system and read the data from the storage system;wherein the metadata comprises an Ipv6 prefix for a group of Ipv6 addresses which are assigned to a the replicas and the object.

15. The system of claim 14, wherein writing and reading the data from the storage system is accomplished via an Ipv6 address stored in the metadata.

16. The system of claim 14, wherein the client computes a family of pseudorandom seeded hashes based on at least one of an object name and consecutive integers as seeds.

17. The system of claim 14, wherein the client computes a family of pseudorandom seeded X-bit hashes based on an object name, wherein X is less than or equal to 128.

18. The system of claim 14, wherein the metadata, when used to write the data to the storage system, is utilized to write replica data to the storage system.