Distributed object placement, replication, and retrieval for cloud-scale storage and data transfer

Abstract

Systems, methods, and computer-readable media for load balancing requests and controlling object replication based on object popularity are provided. A request for an object can be received from a client at a scheduler of a storage system. The scheduler can identify candidate storage nodes of a storage system for providing the object by generating an ordered list of candidate storage nodes using a two-dimensional consistent hash function. Based on the ordered list of candidate storage nodes, allocation of requests for the object can be facilitated by one or more candidate storage nodes for submitting requests for the object. Specifically, one or more candidate storage nodes can be configured to facilitate allocation of requests by selectively submitting requests to a client using a cache permission policy formed based on popularity characteristics of the requested object at the one or more candidate storage nodes.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. non-provisional patent application No. 16 / 379,620, filed on April 9, 2019, entitled “DISTRIBUTED OBJECT PLACEMENT, REPLICATION, AND RETRIEVAL FOR CLOUD-SCALE STORAGE AND DATA DELIVERY,” the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present technology relates to jointly controlling object replication at storage nodes and load balancing between replicated objects based on object popularity, and specifically, to controlling object replication at storage nodes in a distributed manner and on a per-node basis according to the popularity of the objects at the nodes. Background Art

[0004] Object placement strategies in a storage system (e.g., a system implementing a content delivery network (CDN)) can affect the performance of the storage system, e.g., for providing objects to clients. Specifically, the object placement strategy should use storage resources, computing resources, and network resources efficiently, while also scaling to different demands for objects and corresponding different object diversity within the storage system. Specifically, when many clients request the same object, load balancing is performed to control access to the object. Such load balancing can introduce latency when providing objects to clients. One way to reduce latency introduced by load balancing clients accessing objects is to replicate objects across storage nodes. Specifically, object replication can facilitate access to objects while reducing the need to perform load balancing and the corresponding latency associated with performing load balancing. However, object replication across storage nodes utilizes an increased amount of storage and computing resources within the storage system, thereby limiting the storage of other objects across storage nodes. Therefore, there is a tradeoff between object locality and object replication, the former resulting in increased load balancing and latency of object access, and the latter resulting in increased storage and computing resource usage. Therefore, there is a need for a system and method for controlling object replication and subsequent load balancing of object access through an object placement strategy that balances the tradeoff between object locality and object replication.

[0005] Most existing storage systems, e.g., tiered CDNs, use simplified heuristics to control object replication across storage nodes, which may lead to inefficiencies in providing object access. For example, a typical tiered CDN implements an object placement strategy that includes a first-tier storage node that reaches CPU and network limits (e.g., network latency limits), and a second-tier storage node that reaches storage limits. Controlling object replication by popularity can provide a solution to this problem observed in typical tiered CDN implementations. Specifically, an object placement strategy that relies on object popularity can be used to control object replication in a storage system while balancing the trade-off between object locality and object replication.

[0006] However, using popularity to control object replication is difficult to implement for a number of reasons. Specifically, it is difficult to accurately measure object popularity to control object replication for a number of reasons. Specifically, the popularity of an object changes over time. In turn, when popularity measurements are based on past popularity measurements, this can bias popularity measurements over time and at specific time instances. In addition, object state, such as object name, statistics, and lookup data structures, can be used to accurately measure object popularity, for example, to identify object instances for measuring popularity. Given the extremely large number of objects in a storage system and the corresponding hash table space consumption, this state can reach tens of GB of data that must be stored, which can be costly and impair performance. In addition, the popularity distribution is long-tail, meaning that nodes do not really care about the popularity of most objects because most objects are not popular and are therefore not frequently requested. However, in order to understand whether an object is really popular, for example, relative to other objects, the popularity and object state of all objects, including unpopular objects, should be measured and maintained, thus requiring further use of resources. In addition, there are many disadvantages to accurately measuring popularity in a centralized server. Specifically, redundancy is required in order to provide high availability. Furthermore, communication with a centralized server adds latency and computational overhead. Furthermore, popularity may depend on object locality, which makes it difficult to accurately measure popularity in a centralized server. Therefore, there is a need for systems and methods for accurately measuring the popularity of objects to control replication of objects at storage nodes. Specifically, there is a need for systems and methods for controlling object replication and corresponding access load balancing in storage nodes in a distributed manner and by node based on the popularity of the objects at the nodes. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] Figure 1A An example cloud computing architecture is shown;

[0009] Figure 1B An example fog computing architecture is shown;

[0010] Figure 2A A diagram of an example network environment, such as a data center, is shown;

[0011] Figure 2B Another example of a network environment is shown;

[0012] Figure 3 An example environment for controlling replication of objects in a storage system based on popularity of requested objects is shown;

[0013] Figure 4 A scenario for a scheduler for generating an ordered list of candidate servers using varying server diversity is shown;

[0014] Figure 5 A conceptual flow for applying a two-step hashing technique to generate an ordered list of candidate servers is shown;

[0015] Figure 6 A flow chart illustrating an example method for controlling replication of an object based on popularity;

[0016] Figure 7 An example computing system is shown; and

[0017] Figure 8 Example network devices are shown. DETAILED DESCRIPTION

[0018] Various embodiments of the present disclosure are discussed in detail below. Although specific implementations are discussed, it should be understood that this is done for illustrative purposes only. Those skilled in the relevant art will recognize that other components and configurations may be used without departing from the spirit and scope of the present disclosure. Therefore, the following description and drawings are illustrative and should not be interpreted as limiting. Many specific details are described to provide a thorough understanding of the present disclosure. However, in some cases, in order to avoid confusing the description, well-known or conventional details are not described. References to an embodiment or embodiments in the present disclosure may refer to the same embodiment or any one of the embodiments; and, such references mean at least one of the embodiments.

[0019] Reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The phrase "in one embodiment" appearing in various places in the specification is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. In addition, various features are described that may be exhibited by some embodiments but not by others.

[0020] The terms used in this specification generally have their ordinary meanings in the art, in the context of this disclosure, and in the specific context in which each term is used. Alternative language and synonyms may be used for any one or more terms discussed herein, and whether or not a term is elaborated or discussed herein has no special significance. In some cases, synonyms for certain terms are provided. Enumerating one or more synonyms does not exclude the use of other synonyms. The examples used anywhere in this specification, including the examples of any terms discussed herein, are illustrative only and are not intended to further limit the scope and meaning of the disclosure or any example terms. Likewise, the disclosure is not limited to the various embodiments given in this specification.

[0021] Without limiting the scope of the present disclosure, examples of instruments, devices, methods and related results thereof according to embodiments of the present disclosure are given below. It should be noted that, for the convenience of the reader, titles or subtitles may be used in the examples, but this does not limit the scope of the present disclosure. Unless otherwise defined, the technical and scientific terms used herein have the meanings commonly understood by those of ordinary skill in the art to which the present disclosure belongs. In the event of a conflict, this document (including definitions) shall prevail.

[0022] Additional features and advantages of the present disclosure will be set forth in the subsequent description, and in part will be apparent from the description, or may be learned by practicing the principles disclosed herein. The features and advantages of the present disclosure may be realized and obtained by the instruments and combinations specifically pointed out in the appended claims. These and other features of the present disclosure will become more apparent from the following description and the appended claims, or may be learned by practicing the principles set forth herein.

[0023] Overview

[0024] A method may include: receiving a request for an object from a client at a scheduler of a storage system. The method may also include identifying, by the scheduler of the storage system, a candidate storage node in the storage system for providing the object to the client by generating an ordered list of candidate storage nodes using a two-dimensional consistent hash function. Based on the ordered list of candidate storage nodes, allocation of requests for the object may be facilitated by one or more candidate storage nodes among the candidate storage nodes for submitting requests for the object. Specifically, one or more candidate storage nodes may be configured to facilitate allocation of requests by selectively submitting requests for the object to the client using a cache permission policy, the cache permission policy being formed based on popularity characteristics of the requested object at one or more candidate storage nodes.

[0025] A system may include: one or more processors and at least one computer-readable storage medium storing instructions, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: receiving a request for an object from a client at a scheduler of a storage system. The instructions may also cause the one or more processors to perform the following operations: the scheduler identifies a candidate storage node in the storage system for providing an object to a client by generating an ordered list of candidate storage nodes. Specifically, the instructions may cause the one or more processors to perform the following operations: using a two-dimensional consistent hash function to generate an ordered list of candidate storage nodes, the two-dimensional consistent hash function depending on both the stream associated with the request for the object and the object itself. In addition, the instructions may cause the one or more processors to perform the following operations: according to the ordered list of candidate storage nodes, facilitating the allocation of requests for the object through one or more candidate storage nodes in the candidate storage nodes for submitting requests for the object. Specifically, the one or more candidate storage nodes may facilitate the allocation of requests for the object by selectively submitting requests for the object to the client using a cache permission policy, the cache permission policy being formed based on the popularity characteristics of the requested object at one or more candidate storage nodes.

[0026] A non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the following operations: receiving a request for an object from a client at a scheduler of a storage system. These instructions may cause the processor to perform the following operations: the scheduler identifies a candidate storage node in the storage system for providing the object to the client by generating an ordered list of candidate storage nodes. Specifically, these instructions may cause the processor to perform the following operations: using a two-dimensional consistent hash function to generate an ordered list of candidate storage nodes. In addition, these instructions may cause the processor to perform the following operations: according to the ordered list of candidate storage nodes, one or more candidate storage nodes in the candidate storage nodes for submitting requests for the object are used to facilitate the allocation of requests for the object. Specifically, the scheduler may facilitate the allocation of requests for the object by sending a request for the object to the first candidate storage node in the ordered list of candidate storage nodes. In addition, one or more candidate storage nodes may facilitate the allocation of requests by selectively submitting requests for the object to the client using a cache permission policy, which is formed based on the popularity characteristics of the requested object at one or more candidate storage nodes.

[0027] Example Embodiments

[0028] The disclosed technology addresses the need in the art for controlling object access load balancing and corresponding object replication through a request-driven object placement strategy that balances the tradeoff between object locality and object replication. The technology relates to systems, methods, and computer-readable media for controlling object replication at storage nodes based on object popularity. In addition, the technology relates to systems, methods, and computer-readable media for controlling object replication at storage nodes in a distributed manner and on a per-node basis according to the popularity of the object at the node.

[0029] Firstly, a description of the network environment and architecture for network data access and services is disclosed in this paper, such as Figure 1A , Figure 1B , Figure 2A , Figure 2B Next, a system, method, and computer-readable medium for controlling object replication at storage nodes in a distributed manner and on a per-node basis according to the popularity of the object at the node are discussed, such as Figure 3-Figure 6 Then, the discussion starts with the example device (such as Figure 7 and Figure 8 These variations will be described herein along with the description of various embodiments. The present disclosure now turns to Figure 1A .

[0030] Figure 1AA diagram of an example cloud computing architecture 100 is shown. The architecture may include a cloud 102. The cloud 102 may include one or more private clouds, public clouds, and / or hybrid clouds. In addition, the cloud 102 may include cloud elements 104-114. The cloud elements 104-114 may include, for example, a server 104, a virtual machine (VM) 106, one or more software platforms 108, an application or service 110, a software container 112, and an infrastructure node 114. The infrastructure node 114 may include various types of nodes, such as computing nodes, storage nodes, network nodes, management systems, etc.

[0031] The cloud 102 can provide various cloud computing services through cloud elements 104-114, such as software as a service (SaaS) (e.g., collaboration services, email services, enterprise resource planning services, content services, communication services, etc.), infrastructure as a service (IaaS) (e.g., security services, network services, system management services, etc.), platform as a service (PaaS) (e.g., network services, streaming media services, application development services, etc.), and other types of services, such as desktop as a service (DaaS), information technology management as a service (ITaaS), hosted software as a service (MSaaS), mobile backend as a service (MBaaS), etc.

[0032] The client endpoint 116 can connect to the cloud 102 to obtain one or more specific services from the cloud 102. The client endpoint 116 can communicate with the elements 104-114 through one or more public networks (e.g., the Internet), private networks, and / or hybrid networks (e.g., virtual private networks). The client endpoint 116 may include any device with networking capabilities, such as a laptop, tablet computer, server, desktop computer, smart phone, network equipment (e.g., access point, router, switch, etc.), smart TV, smart car, sensor, GPS device, gaming system, smart wearable object (e.g., smart watch, etc.), consumer object (e.g., Internet refrigerator, smart lighting system, etc.), city or transportation system (e.g., traffic control, toll collection system, etc.), Internet of Things (IoT) device, camera, network printer, transportation system (e.g., airplane, train, motorcycle, boat, etc.), or any smart or connected object (e.g., smart home, smart building, smart retail, smart glasses, etc.), etc.

[0033] Figure 1BA diagram of an example fog computing architecture 150 is shown. The fog computing architecture 150 can include a cloud layer 154, which includes the cloud 102 and any other cloud systems or environments, and a fog layer 156, which includes fog nodes 162. Client endpoints 116 can communicate with the cloud layer 154 and / or the fog layer 156. The architecture 150 can include one or more communication links 152 between the cloud layer 154, the fog layer 156, and the client endpoints 116. Communications can flow upward to the cloud layer 154 and / or downward to the client endpoints 116.

[0034] The fog layer 156 or "fog" provides the computing, storage, and networking capabilities of a traditional cloud network, but closer to the endpoints. Thus, the fog can extend the cloud 102 closer to the client endpoints 116. The fog nodes 162 can be a physical implementation of the fog network. In addition, the fog nodes 162 can provide local or regional services and / or connectivity to the client endpoints 116. Thus, traffic and / or data can be offloaded from the cloud 102 to the fog layer 156 (e.g., through the fog nodes 162). Thus, the fog layer 156 can provide faster services and / or connectivity to the client endpoints 116 with lower latency and other advantages (such as the security advantages of keeping data within (one or more) local or regional networks).

[0035] The fog nodes 162 may include any networked computing devices, such as servers, switches, routers, controllers, cameras, access points, gateways, etc. In addition, the fog nodes 162 may be deployed anywhere with a network connection, such as factory floors, utility poles, railroad tracks, vehicles, oil rigs, airports, airplanes, shopping malls, hospitals, parks, parking lots, libraries, etc.

[0036] In some configurations, one or more fog nodes 162 can be deployed within the fog instances 158, 160. The fog instances 158, 160 can be local or regional clouds or networks. For example, the fog instances 158, 160 can be regional clouds or data centers, local area networks, networks of fog nodes 162, etc. In some configurations, one or more fog nodes 162 can be deployed within the network, or deployed as, for example, independent nodes or single nodes. In addition, one or more of the fog nodes 162 can be interconnected to each other via links 164 in various topologies, including, for example, star, ring, mesh, or hierarchical arrangements.

[0037] In some cases, one or more fog nodes 162 may be mobile fog nodes. Mobile fog nodes may move to different geographic locations, logical locations or networks, and / or fog instances while maintaining connectivity with the cloud layer 154 and / or endpoints 116. For example, a particular fog node may be placed in a vehicle (such as an airplane or a train), which may travel from one geographic location and / or logical location to a different geographic location and / or logical location. In this example, a particular fog node may connect to a particular physical and / or logical connection point with the cloud 154 when located at a starting location, and switch to a different physical and / or logical connection point with the cloud 154 when located at a destination location. Thus, a particular fog node may move within a particular cloud and / or fog instance, thereby providing services to endpoints from different locations at different times.

[0038] Figure 2A A diagram of an example network environment 200, such as a data center, is shown. In some cases, the network environment 200 may include a data center that may support and / or host a cloud 102. The network environment 200 may include a fabric 220 that may represent a physical layer or infrastructure (e.g., an underlay) of the network environment 200. The fabric 220 may include a spine 202 (e.g., a spine router or switch) and leaves 204 (e.g., a leaf router or switch) that may be interconnected for routing or switching traffic in the fabric 220. The spine 202 may interconnect the leaves 204 in the fabric 220, and the leaves 204 may connect the fabric 220 to an overlay or logical portion of the network environment 200, which may include application services, servers, virtual machines, containers, endpoints, etc. Thus, network connectivity in the fabric 220 may flow from the spine 202 to the leaves 204 and vice versa. The interconnections between the leaves 204 and the spine 202 may be redundant (e.g., multiple interconnections) to avoid routing failures. In some embodiments, leaves 204 and spines 202 may be fully connected such that any given leaf is connected to each of the spines 202, and any given spine is connected to each of the leaves 204. A leaf 204 may be, for example, a top of rack ("ToR") switch, an aggregation switch, a gateway, an ingress and / or egress switch, a provider edge device, and / or any other type of routing or switching device.

[0039] The leaf 204 may be responsible for routing and / or bridging tenant or customer packets and applying network policies or rules. Network policies and rules may be driven by one or more controllers 216 and / or implemented or enforced by one or more devices (such as the leaf 204). The leaf 204 may connect other elements to the structure 220. For example, the leaf 204 may connect a server 206, a hypervisor 208, a virtual machine (VM) 210, an application 212, a network device 214, etc. to the structure 220. Such elements may reside in one or more logical or virtual layers or networks (such as overlay networks). In some cases, the leaf 204 may encapsulate and decapsulate packets entering and exiting such elements (e.g., servers 206) so as to be able to communicate throughout the network environment 200 and the structure 220. The leaf 204 may also provide access to the structure 220 for any other device, service, tenant, or workload. In some cases, a server 206 connected to the leaf 204 may similarly encapsulate and decapsulate packets entering and exiting the leaf 204. For example, server 206 may include one or more virtual switches or routers or tunnel endpoints for tunneling packets between an overlay or logical layer hosted by or connected to server 206 and an underlying layer represented by fabric 220 and accessed through leaf 204.

[0040] Applications 212 may include software applications, services, containers, devices, functions, service chains, etc. For example, applications 212 may include firewalls, databases, CDN servers, IDS / IPS, deep packet inspection services, message routers, virtual switches, etc. Applications from applications 212 may be distributed, linked, or hosted by multiple endpoints (e.g., server 206, VM 210, etc.), or may be run or executed entirely from a single endpoint.

[0041] The VM 210 may be a virtual machine hosted by the hypervisor 208 or a virtual machine manager running on the server 206. The VM 210 may include a workload running on a guest operating system on the corresponding server. The hypervisor 208 may provide a software, firmware, and / or hardware layer to create, manage, and / or run the VM 210. The hypervisor 208 may allow the VM 210 to share hardware resources on the server 206 and display the hardware resources on the server 206 as multiple independent hardware platforms. In addition, the hypervisor 208 on the server 206 may host one or more VMs 210.

[0042] In some cases, VMs 210 and / or hypervisors 208 may be migrated to other servers 206. Servers 206 may similarly be migrated to other locations in network environment 200. For example, a server connected to a particular leaf may be changed to connect to a different or additional leaf. Such configuration or deployment changes may involve modifications to settings, configurations, and policies applied to the resources being migrated and other network components.

[0043] In some cases, one or more servers 206, hypervisors 208, and / or VMs 210 may represent or reside in a tenant or customer space. A tenant space may include workloads, services, applications, devices, networks, and / or resources associated with one or more clients or subscribers. Therefore, traffic in the network environment 200 may be routed based on specific tenant policies, spaces, protocols, configurations, and the like. In addition, addressing may vary between one or more tenants. In some configurations, a tenant space may be divided into logical segments and / or networks and separated from logical segments and / or networks associated with other tenants. Addressing, policies, security, and configuration information between tenants may be managed by a controller 216, server 206, leaf 204, and the like.

[0044] Configurations in the network environment 200 can be implemented at a logical level, a hardware level (e.g., physical), and / or both. For example, configurations can be implemented at a logical and / or hardware level through a software defined network (SDN) framework (e.g., an application-centric infrastructure (ACI) or VMWARE NSX) based on endpoint or resource attributes (such as endpoint type and / or application group or profile). For illustration, one or more managers can define configurations at a logical level (e.g., an application or software level) through a controller 216, which can implement or propagate such configurations through the network environment 200. In some examples, the controller 216 can be an application policy infrastructure controller (APIC) in an ACI framework. In other examples, the controller 216 can be one or more management components associated with other SDN solutions, such as an NSX manager.

[0045] Such configurations may define rules, policies, priorities, protocols, attributes, objects, etc., for routing and / or classifying services in the network environment 200. For example, such configurations may define attributes and objects for classifying and processing services based on endpoint groups (EPGs), security groups (SGs), VM types, bridge domains (BDs), virtual routing and forwarding instances (VRFs), tenants, priorities, firewall rules, etc. Other example network objects and configurations are further described below. Business policies and rules may be enforced based on tags, attributes, or other characteristics of the services, such as protocols associated with the services, EPGs associated with the services, SGs associated with the services, network address information associated with the services, etc. Such policies and rules may be enforced by one or more elements in the network environment 200, such as leaves 204, servers 206, hypervisors 208, controllers 216, etc. As previously described, the network environment 200 may be configured according to one or more specific software defined network (SDN) solutions, such as CISCO ACI or VMWARE NSX. These example SDN solutions are briefly described below.

[0046] ACI can provide application-centric or policy-based solutions through scalable distributed enforcement. ACI supports the integration of physical and virtual environments under a declarative configuration model for networks, servers, services, security, requirements, etc. For example, the ACI framework implements EPG, which can include a collection of endpoints or applications that share common configuration requirements (such as security, QoS, services, etc.). An endpoint can be a virtual / logical or physical device, such as a VM, container, host, or physical server connected to the network environment 200. An endpoint can have one or more attributes, such as a VM name, a guest OS name, a security label, an application profile, etc. Application configuration can be applied between EPGs in the form of a contract rather than directly to the endpoint. Leaf 204 can classify incoming traffic into different EPGs. Classification can be based on, for example, a network segmentation identifier, such as a VLAN ID, a VXLAN network identifier (VNID), an NVGRE virtual subnet identifier (VSID), a MAC address, an IP address, etc.

[0047] In some cases, classification in the ACI infrastructure can be implemented by an application virtual switch (AVS), which can run on a host (such as a server or a switch). For example, the AVS can classify traffic based on specified attributes and tag packets of different attribute EPGs with different identifiers, such as network segment identifiers (e.g., VLAN IDs). Finally, the leaf 204 can associate packets with their attribute EPGs based on their identifiers and enforce policies, which can be implemented and / or managed by one or more controllers 216. The leaf 204 can classify which EPG the traffic from the host belongs to and enforce policies accordingly.

[0048] Another example SDN solution is based on VMWARE NSX. With VMWARE NSX, the host can run a distributed firewall (DFW) that can classify and process traffic. Consider the case where three types of VMs, application VMs, database VMs, and network VMs are placed into a Layer 2 network segment. Traffic protection can be provided within the network segment based on the VM type. For example, HTTP traffic between network VMs can be allowed, but HTTP traffic between network VMs and application VMs or database VMs is not allowed. To classify traffic and enforce policies, VMWARE NSX can implement security groups that can be used to group specific VMs (e.g., network VMs, application VMs, database VMs). DFW rules can be configured to enforce policies for specific security groups. To illustrate, in the context of the previous example, the DFW rule can be configured to block HTTP traffic between the network, application, and database security groups.

[0049] Now return to reference Figure 2A , the network environment 200 can deploy different hosts, such as VMWARE ESXi hosts, WINDOWS HYPER-V hosts, bare metal physical hosts, etc., through leaves 204, servers 206, hypervisors 208, VMs 210, applications 212, and controllers 216. The network environment 200 can interoperate with various hypervisors 208, servers 206 (e.g., physical and / or virtual servers), SDN orchestration platforms, etc. The network environment 200 can implement a declarative model to allow its integration with application design and overall network policy.

[0050] The controller 216 may provide centralized access to fabric information, application configuration, resource configuration, application-level configuration modeling of software defined network (SDN) infrastructure, integration with management systems or servers, etc. The controller 216 may form a control plane that interfaces with the application plane through a northbound API and interfaces with the data plane through a southbound API.

[0051] As previously described, the controller 216 may define and manage (one or more) application-level models for configurations in the network environment 200. In some cases, application or device configurations may also be managed and / or defined by other components in the network. For example, a hypervisor or virtual device, such as a VM or container, may run a server or management tool to manage software and services in the network environment 200, including configurations and settings for virtual devices.

[0052] As described above, the network environment 200 may include one or more different types of SDN solutions, hosts, etc. For the purpose of clarity and illustration, various examples in the present disclosure will be described with reference to the ACI framework, and the controller 216 may be interchangeably referred to as a controller, an APIC, or an APIC controller. However, it should be noted that the techniques and concepts herein are not limited to the ACI solution, but may be implemented in other architectures and scenarios, including other SDN solutions, and other types of networks where an SDN solution may not be deployed.

[0053] Furthermore, as referred to herein, the term "host" may refer to a server 206 (e.g., physical or logical), a hypervisor 208, a VM 210, a container (e.g., an application 212), etc., and may run or include any type of server or application solution. Non-limiting examples of a "host" may include a virtual switch or router, such as a distributed virtual switch (DVS), an application virtual switch (AVS), a vector packet processing (VPP) switch; VCENTER and NSX MANAGERS; bare metal physical hosts; Hyper-V hosts; VMs; Docker containers; etc.

[0054] Figure 2BAnother example of a network environment 200 is shown. In this example, the network environment 200 includes an endpoint 222 connected to a leaf 204 in a fabric 220. The endpoint 222 can be a physical and / or logical or virtual entity, such as a server, client, VM, hypervisor, software container, application, resource, network device, workload, etc. For example, the endpoint 222 can be an object representing a physical device (e.g., server, client, switch, etc.), an application (e.g., network application, database application, etc.), a logical or virtual resource (e.g., virtual switch, virtual service device, virtualized network function (VNF), VM, service chain, etc.), a container running a software resource (e.g., application, device, VNF, service chain, etc.), a storage device, a workload or workload engine, etc. The endpoint 222 can have an address (e.g., identity), a location (e.g., host, network segment, virtual routing and forwarding (VRF) instance, domain, etc.), one or more attributes (e.g., name, type, version, patch level, OS name, OS type, etc.), a label (e.g., security label), a profile, etc.

[0055] Endpoints 222 may be associated with corresponding logical groups 218. Logical groups 218 may be logical entities that contain endpoints (physical and / or logical or virtual) grouped together according to one or more attributes, such as endpoint type (e.g., VM type, workload type, application type, etc.), one or more requirements (e.g., policy requirements, security requirements, QoS requirements, customer requirements, resource requirements, etc.), resource names (e.g., VM names, application names, etc.), profiles, platform or operating system (OS) characteristics (e.g., OS type or name, including guest and / or host OS, etc.), associated networks or tenants, one or more policies, tags, etc. For example, a logical group may be an object that represents a collection of endpoints grouped together. For illustration, logical group 1 may contain client endpoints, logical group 2 may contain network server endpoints, logical group 3 may contain application server endpoints, logical group N may contain database server endpoints, etc. In some examples, logical group 218 is an EPG in an ACI environment and / or other logical group (e.g., SG) in another SDN environment.

[0056] Traffic entering and exiting endpoints 222 may be categorized, processed, managed, etc. based on logical groups 218. For example, logical groups 218 may be used to categorize traffic entering and exiting endpoints 222, apply policies to traffic entering and exiting endpoints 222, define relationships between endpoints 222, define roles of endpoints 222 (e.g., whether an endpoint consumes or provides a service, etc.), apply rules to traffic entering and exiting endpoints 222, apply filters or access control lists (ACLs) to traffic entering and exiting endpoints 222, define communication paths for traffic entering and exiting endpoints 222, enforce requirements associated with endpoints 222, implement security and other configurations associated with endpoints 222, and the like.

[0057] In an ACI environment, logical group 218 may be an EPG that is used to define a contract in an ACL. A contract may include rules that specify what communication between EPGs is and how it occurs. For example, a contract may define what services are provided, what services are consumed, and policy objects associated with this consumption relationship. A contract may include policies that define communication paths and all related elements of a communication or relationship between endpoints or EPGs. For example, a network EPG may provide services that are consumed by a client EPG, and this consumption may be subject to filters (ACLs) and a service graph that includes one or more services (such as firewall inspection services and server load balancing).

[0058] As previously mentioned, an object placement strategy in a storage system (e.g., a system implementing a CDN) can affect the performance of the storage system, e.g., for providing objects to clients. Specifically, the object placement strategy should efficiently use storage resources, computing resources, and network resources, while also scaling according to different demands for objects and corresponding different object diversity within the storage system. Specifically, when many clients request the same object, load balancing is performed to control access to the object. Such load balancing introduces latency when providing objects to clients. One way to reduce latency introduced by load-balanced clients accessing objects is to replicate objects across storage nodes. Specifically, object replication can facilitate access to objects while reducing corresponding latency associated with performing load balancing (e.g., resulting from load balancing). However, object replication across storage nodes utilizes an increased amount of storage and computing resources within the storage system, thereby limiting the storage of other objects across storage nodes. Therefore, there is a trade-off between object locality (resulting in increased load balancing and latency for object access) and object replication (resulting in increased storage and computing resource usage).

[0059] Most existing storage systems, e.g., tiered CDNs, use simplified heuristics to control object replication across storage nodes, which can lead to inefficiencies in providing object access. For example, a typical tiered CDN implements an object placement strategy that includes a first-tier storage node that reaches CPU and network limits (e.g., network latency limits), and a second-tier storage node that reaches storage limits. Controlling object replication by popularity can provide a solution to this problem observed in typical tiered CDN implementations. Specifically, an object placement strategy that relies on object popularity can be used to control object replication in a storage system while balancing the trade-off between object locality and object replication.

[0060] However, using popularity to control object replication is difficult to implement for a number of reasons. Specifically, it is difficult to accurately measure object popularity to control object replication for a number of reasons. Specifically, the popularity of an object changes over time. Furthermore, when popularity measurements are based on past popularity measurements, this can bias popularity measurements over time and at specific time instances. In addition, object state, such as object name, statistics, and lookup data structures, can be used to accurately measure object popularity, for example, to identify object instances for measuring popularity. Given the extremely large number of objects in a storage system and the corresponding hash table space consumption, this state can reach tens of GB of data that must be stored, which can be costly and impair performance. In addition, the popularity distribution is long-tailed, which means that nodes do not really care about the popularity of most objects because most objects are not popular and are therefore not frequently requested. However, in order to understand whether an object is really popular, for example, relative to other objects, the popularity and object state of all objects, including unpopular objects, should be measured and maintained, requiring further use of resources. In addition, there are many disadvantages to accurately measuring popularity in a centralized server. In particular, redundancy is required in order to provide high availability. Furthermore, communication with a centralized server adds latency and computational overhead. Furthermore, popularity may depend on object locality, which makes it difficult to accurately measure popularity in a centralized server.

[0061] The present disclosure includes a system, method, and computer-readable medium for controlling object replication based on object popularity. Specifically, a scheduler of a storage system may receive a request for an object from a client. The scheduler may identify candidate storage nodes of a storage system for providing an object to a client by generating an ordered list of candidate storage nodes using a two-dimensional consistent hash function. The two-dimensional consistent hash function may depend on both the stream associated with the request for the object and the object itself. Subsequently, based on the ordered list of candidate storage nodes, the allocation of requests for the object may be facilitated by one or more candidate storage nodes in the candidate storage nodes for submitting requests for the object. Specifically, the scheduler may send a request for the object to a first candidate storage node in the ordered list of candidate storage nodes to facilitate the allocation of requests for the object. In addition, one or more candidate storage nodes may facilitate the allocation of requests for the object by selectively submitting requests for the object to the client using a cache permission policy, which is formed based on the popularity characteristics of the requested object at one or more candidate storage nodes.

[0062] Figure 3 An example environment 300 is shown for controlling object replication in a storage system based on the popularity of a requested object. Specifically, Figure 3 The example environment 300 shown in FIG. 3 can be used to control object replication at storage nodes in a storage system in a distributed manner across storage nodes. More specifically, Figure 3 The example environment 300 shown in the example embodiment can be used to control object replication at storage nodes in a storage system on a node-by-node basis based on object popularity at each of the storage nodes. When controlling object replication based on popularity, the environment 300 can effectively control load balancing of access to objects across storage nodes of the storage system. For example, by replicating objects based on popularity across storage nodes, the environment 300 can be used to control the number of times an object appears in a storage system, thereby adjusting the amount of load balancing used to provide access to objects in the storage system.

[0063] Figure 3 The illustrated example environment 300 may be formed at least in part by an applicable cloud or fog environment, such as, Figure 1A The cloud computing architecture 100 and Figure 1B The fog computing architecture 150 shown. For example, the environment 300 can be implemented as part of a CDN implemented in the cloud computing architecture 100. In addition, in this example, the environment 300 can be used to control object replication at a storage node in the CDN implemented in the cloud computing architecture 100. In addition, the environment 300 can be formed at least in part by an applicable network environment, such as, Figure 2A and Figure 2B The network environment 200 shown in FIG. 300 can be, for example, at least partially implemented by Figure 2A The environment 300 is implemented in a data center formed by the network environment 200 shown. In addition, in this example, the environment 300 can be used to control object replication at storage nodes in the data center formed by the network environment 200.

[0064] Figure 3 The illustrated example environment 300 includes a client 302, a scheduler 304, and a server pool 306. The client 302 is used to request access to an object and subsequently obtain access to the object through the environment 300. As used herein, a client may include an applicable entity that can request and obtain access to an object. Specifically, a client may include a user, a network service, and an application. For example, a client may include a microservice of a structured application that is configured to request and obtain access to an object when executing the structured application.

[0065] The scheduler 304 is used to receive a request for an object from the client 302. The scheduler 304 may be implemented as a part of the client 302. For example, the scheduler 304 may be implemented by an application executed at the client 302. Alternatively, the scheduler 304 may be implemented away from the client 302 and receive the request for the object through a network. For example, the scheduler 304 may be implemented away from the client 302 in the cloud computing architecture 100. Therefore, the scheduler 304 may receive the request for the object in the cloud computing architecture 100 through a network.

[0066] The request for an object received from the client 302 includes an identifier of the requested object. As will be discussed in more detail later, the object identifier may be used to select a candidate server for providing the object to the client 302. In addition, the request for the object may be included as part of or otherwise associated with a data stream for sending and receiving data to and from the client 302. The stream including the request for the object may be associated with a network service provided to the client 302. For example, the stream may be associated with streaming television content to the client 302, and the request for the object may include a request for a portion of the television content. As will be discussed in more detail later, the stream of the requested object may be used to select a candidate server for providing the object to the client 302.

[0067] The scheduler 304 is included as part of a storage system or is otherwise associated with the storage system. The storage system may be an applicable storage system for storing and providing objects. For example, the storage system may be a CDN. The storage system of the scheduler 304 includes a server pool 306. The server pool 306 includes servers S1...S9. Although servers are mentioned throughout the specification, servers are intended to represent applicable storage nodes for storing objects and providing access to objects. Specifically, a server may represent a storage node in a data center. In addition, although only nine servers are shown in the server pool 306, in various embodiments, the server pool 306 may include more or fewer servers.

[0068] Using the received request for the object, the scheduler 304 can identify a candidate server in the server pool 306 for providing the object to the client 302. The candidate server may include a server that stores the requested object locally. In turn, the candidate server may provide the object to the client 302 from its local storage device (e.g., cache). Alternatively, the candidate server may include a server that does not store the requested object locally. Subsequently, and as will be discussed in more detail later, the candidate server may determine whether to retrieve the requested object from another location or forward the request to another candidate server. As will be discussed in more detail later, the candidate server may retrieve the requested object and store the object in the local storage device of the candidate server. Specifically, and as will be discussed in more detail later, the candidate server may use a popularity metric, such as a popularity characteristic of the requested object at the candidate server, to determine whether to retrieve the requested object from another location. Subsequently, the candidate server may store the requested object locally and provide the object to the client 302 from its local storage device.

[0069] The scheduler 304 can identify the candidate servers of the server pool 306 by generating an ordered list of candidate servers. The ordered list of candidate servers includes a sequential list of candidate servers through which object requests can be allocated so as to provide the object to the client 302. Specifically, the request for the object can be allocated through the server pool 306 according to the ordered list of candidate servers so as to ultimately provide the requested object to the client 302. As will be discussed in more detail later, the scheduler 304 can send the object request to the first candidate server in the ordered list of candidate servers. Subsequently and as will be discussed in more detail later, the candidate servers can then sequentially allocate the object request through the candidate servers in the candidate server pool based on the ordered list of candidate servers. Specifically, the candidate servers can allocate the object request based on whether the candidate servers agree to provide the object to the client 302. Alternatively, the scheduler 304 can query each of the candidate servers in a distributed manner to submit the object request. Furthermore, the object can be replicated based at least in part on whether the candidate servers agree to provide the object to the client 302, thereby effectively controlling the replication of the object in the server pool 306.

[0070] The scheduler 304 may use a two-dimensional consistent hashing function to generate an ordered list of candidate servers. For example, a hashing function that may be used by the scheduler 304 to generate an ordered list of candidate servers will be discussed in more detail later. Consistent hashing, as used herein, refers to a technique for allocating flows, e.g., allocating requests for objects corresponding to flows according to a hash value of the flow. Specifically, consistent hashing may be used to allocate requests for objects / flows such that the allocation is robust to changes in the set of servers.

[0071] As will be discussed in more detail later with respect to an example hash function, the scheduler 304 can use a two-dimensional consistent hash function that relies on both the flow associated with the requested object and the object identifier of the requested object to generate an ordered list of candidate servers. Specifically, the scheduler 304 can use the flow information of the flow associated with the requested object to apply the two-dimensional consistent hash function to generate an ordered list of candidate servers. The flow information may include applicable data related to the flow of the requested object. For example, the flow information of the requested object may include a five-tuple of the flow and a client identifier of the client 302.

[0072] The scheduler 304 may apply a two-dimensional consistent hashing function based on varying server diversity to generate an ordered list of candidate servers. Server diversity may be defined as the number of candidate servers that provide services for an object. Server diversity may depend on both the amount of load balancing within the storage system and the amount of object locality, e.g., the probability that a storage node has a given object in the storage system. For example, the scheduler 304 may select one or more candidate servers using a larger server diversity that weights load balancing within the storage system more than object locality, e.g., giving load balancing a higher priority than reducing object replication. In another example, the scheduler 304 may select one or more candidate servers using a smaller server diversity that weights object locality within the storage system more than load balancing, e.g., achieving lower object replication at the expense of reducing the redistribution of ingress load. Thus, applying a two-dimensional consistent hashing function with increased server diversity may increase the number of candidate servers identified because increased server diversity facilitates more load balancing. Reference will be made later to Figure 4 Describe this concept in more detail.

[0073] In addition, since object locality corresponds to the object itself, and load balancing corresponds to the flow of objects, different server diversities may cause the hash function to change the weights of objects and flows of objects in the application. For example, the scheduler 304 may apply a hash function with a larger server diversity that is favorable to load balancing. Subsequently, the hash function may rely more on the flow of objects rather than the objects themselves when selecting one or more candidate servers. In another example, the scheduler 304 may apply a hash function with a smaller server diversity that is favorable to object locality. Subsequently, the hash function may rely more on the object itself rather than the flow of objects when selecting one or more candidate servers.

[0074] Figure 4 Scenario 400 of scheduler 304 is shown for generating an ordered list of candidate servers using varying server diversity. Figure 4 In the illustrated example scenario 400, the scheduler 304 may use an applicable hash function (such as the hash function described herein) to generate an ordered list of candidate servers. Specifically, the scheduler 304 may use a two-dimensional consistent hash function in combination with the request object identifier and the flow information of the object flow to identify the ordered list of candidate servers.

[0075] In addition, the scheduler 304 may apply a varying amount of server diversity in a two-dimensional consistent hash function to different subsets of candidate servers. Specifically, the scheduler 304 may apply a decreasing amount of server diversity in a two-dimensional consistent hash function to generate smaller and smaller subsets of candidate servers. Subsequently, the scheduler 304 may randomly or pseudo-randomly select a candidate server in each subset of the candidate servers to create an ordered list of candidate servers. When a decreasing amount of server diversity is applied in a two-dimensional consistent hash function, object locality, for example, the probability that a candidate server has a request in its storage device, is more favorable as the size of the candidate server subset decreases. Furthermore, the final subset of servers may include another candidate server that is highly favorable for object locality, for example, based on the identification of the object. Since locality is highly favorable, one or more candidate servers in the final subset include a local copy of the requested object. Therefore, the identified list of candidate servers will include at least one candidate server, i.e., the final candidate server in the list, which has a local copy of the object. This can ensure that a copy of the object is accessible to the client 302 between the candidate servers in the ordered list of candidate servers.

[0076] about Figure 4 In the illustrated example scenario 400, the scheduler 304 may apply a hash function with a large server diversity (e.g., a server diversity of 7) to generate a first subset of candidate servers 402. The first subset of candidate servers 402 includes a first server S1, a second server S2, a third server S3, a fifth server S5, a sixth server S6, a seventh server S7, and a ninth server S9. By applying the hash function, the fourth server S4 and the eighth server S8 are excluded from the first subset of candidate servers 402. Because load balancing is more favorable than locality in the larger server diversity used to create the first subset of candidate servers 402, some candidate servers in the first subset of candidate servers 402 may not include a locally stored copy of the object.

[0077] The scheduler 304 may then randomly or pseudo-randomly select a server from the first subset of candidate servers 402 to serve as the first candidate server in the ordered list of candidate servers. Figure 4 In the illustrated example scenario 400, the scheduler 304 selects the third server S3 from the first subset of candidate servers 402. Subsequently, the scheduler 304 may add the identifier of the third server S3 as the first candidate server in the ordered list of candidate servers.

[0078] Next, the scheduler 304 reduces the server diversity amount and applies a hash function to generate a second subset 404 of candidate servers. Specifically, the scheduler 304 may apply a hash function with a reduced server diversity amount (e.g., 3) when compared to the server diversity amount 7 used to generate the first subset 402 of candidate servers. The second subset 404 of candidate servers includes the second server S2, the fifth server S5, and the seventh server S7. The scheduler 304 may then randomly or pseudo-randomly select a server from the second subset 404 of candidate servers to serve as the next candidate server in the ordered list of candidate servers. Specifically, in Figure 4 In the illustrated example scenario 400, the scheduler 304 selects the seventh server S7 from the second subset of candidate servers 404. Subsequently, the scheduler 304 may add the identification of the seventh server S7 as the next candidate server in the ordered list of candidate servers.

[0079] This process of reducing the server diversity amount used to apply the hash function to ultimately identify the candidate server can be repeated as many times as applicable. Specifically, in the example scenario 400, the scheduler reduces the server diversity amount and applies the hash function to generate the third subset 406 of the candidate servers. Specifically, when compared with the server diversity amount 3 used to generate the second subset 404 of the candidate servers, the scheduler 304 can apply a hash function with a reduced server amount (e.g., 1). The third subset 406 of the candidate servers only includes the second server S2. Therefore, the scheduler 304 can select the second server S2 as the next candidate server in the ordered list of candidate servers. Subsequently, the scheduler 304 can add the identification of the second server S2 as the next candidate server in the ordered list of candidate servers. As previously described, since locality is advantageous as server diversity decreases, and since the second server S2 is identified from the hash function when a lower server diversity amount is used, the second server S2 includes a local copy of the object. Specifically, the second server S2 is used as the last candidate server in the ordered list of candidate servers and also includes a local copy of the object.

[0080] The present disclosure now turns to a discussion of different hash functions that the scheduler 304 may use to identify an ordered list of candidate servers.

[0081] In various embodiments, the scheduler 304 may use a weighted Torus two-step hashing technique to generate an ordered list of candidate servers. This hashing technique is based on a 1-D circular hashing technique. In 1-D circular hashing, an object is associated with a server with the closest hash. In the 2-D Torus hashing technique, objects and servers are hashed into points for each coordinate using two different hash functions. Objects and servers may be hashed for each coordinate according to the 2-DTorus hashing technique using a single hash function and salt. In turn, the scheduler may select a candidate server whose hash point is closest to the hash point of the object. Instead of using a simple distance like the Euclidian sqrt(∆ (flow)**2) to determine the distance between hash points, a weight parameter of ∆ (flow): sqrt(α * ∆ (flow)**2 + ∆ (object-id)**2) may be used. In this case, Alpha is server diversity. Subsequently, for α=0, all requests for a given object are sent to the same server. When α = infinity, objects are load balanced across all servers. All other values ​​of alpha provide different levels of tradeoff between load balancing and object locality corresponding to different server diversity. This technique can be generalized to N dimensions (with N parameters and N-1 affinity weights). Furthermore, this technique can be generalized to other distances between servers and objects, rather than using the closest server and object based on hash points.

[0082] In some embodiments, the scheduler 304 may use a ring hashing technique to generate an ordered list of candidate servers. Specifically, the scheduler 304 may use a ring hashing technique with a subset of consistent servers to generate an ordered list of candidate servers. When implementing the ring hashing technique, the scheduler 304 may place all or some of the servers around a circle. For example, the servers may be placed around a circle pseudo-randomly, e.g., by assigning each server a pseudo-random angle. Subsequently, the scheduler 304 may select a subset of servers with a diversity d_i by selecting the d_i servers on the circle / ring that are closest to the content identifier hash (e.g., the content identifier hash of the requested object). Subsequently, the scheduler 304 may use the flow information of the requested object, e.g., the five-tuple and the client_id, to select candidate servers with a flow-based consistent hash. The specific implementation of the ring hashing technique is described below. Specifically, if there are N servers, a list size L is established, and if α_k is the server diversity parameter of the k-th server in the list, where α_1 = N > α_2 >... > α_L = 1, the last server is found by the following formula: s_L = hash_L mod 2*π. The k-th (k < L) server is found by the following formula: s_k = s_L + (hash_k mod 2*π*α_k / N). hash_L is the hash of the object-id, and hash_k (k < L) is a different hash function of the flow-id, and the mod x operator is a shift modulo that returns a value between -x / 2 and +x / 2.

[0083] In another implementation of the ring hashing technique, the α_i servers closest to the s_L server on the ring may be identified (e.g., manually identified). The identified α_i servers closest to the s_L server may then be placed on a newly generated ring. Subsequently, the s_k may be directly used to select candidate servers from the α_i servers placed on the newly generated ring.

[0084] The ring hashing technique is advantageous when a server is removed from the subset of servers. Specifically, when a server is removed, the content / objects stored on this server must be reallocated. Additionally, it is desirable to reallocate the content to the closest server (e.g., the server on the circle that is closest to the removed server) by the ring hashing technique. However, it is likely that the closest server already has this content, thus avoiding unnecessary duplication of the content stored on the removed server.

[0085] In various embodiments, the scheduler 304 may use a two-step hashing technique with a subset of consistent servers to generate an ordered list of candidate servers. Figure 5A conceptual process 500 is shown for applying a two-step hashing technique to generate an ordered list of candidate servers.

[0086] In the first step of the conceptual flow 500, the object ID is mapped to the server arrangement 502 using a first consistent hashing technique. This technique can be derived from Maglev hashing because it relies on the server arrangement 502 to assign buckets to servers. As shown in the conceptual flow 500, a bucket can include multiple servers instead of just a single server per bucket. Specifically, according to the nature of the Maglev technique, k server arrangements are arranged. The variable k can be the number of buckets.

[0087] In the second step of the conceptual process 500, a diversity parameter α is used to select a subset of servers from the arrangement. The greater the diversity, the larger the subset of servers. In addition, as the diversity parameter increases, the growing subsets can include each other. For example, the diversity can be a "number of servers" from 1 to N.

[0088] In the third step of the conceptual process 500, the flow of the object is mapped to the selected subset of servers using a second consistent hashing technique, for example based on the flow information. The second consistent hashing technique may also utilize Maglev hashing. Thus, an ordered list of candidate servers may be generated based on the mapping of the object flow to the servers in the selected subset of servers.

[0089] Back to Figure 3 In the example environment 300 shown, the scheduler 304 can facilitate the allocation of requests for objects through at least a portion of the server pool 306. Specifically, after the scheduler 304 identifies the ordered list of candidate servers, the scheduler 304 can facilitate the allocation of requests through at least a portion of the server pool 306. More specifically, the scheduler 304 can use the ordered list of candidate servers to facilitate the allocation of requests through at least a portion of the candidate servers. As will be discussed in more detail later, requests for objects can be allocated through at least a portion of the server pool 306 in a sequential manner according to the ordered list of candidate servers. Requests can be allocated using an applicable data forwarding protocol. For example, requests can be allocated through an HTTP proxy, sequential HTTP requests, and network-level business control using an applicable protocol (e.g., segment routing local block (SRLB0 or ​​multi-protocol label switching (MPLS)). Specifically, a protocol can be used to forward requests, which allows candidate servers to accept or reject requests based on their local cache permission algorithms, which will be discussed in detail later.

[0090] When facilitating the allocation of a request for an object through the server pool 306, the scheduler 304 may send the request to the first candidate server in the ordered list of candidate servers. Figure 3 In the illustrated example environment 300 , the dispatcher 304 may send the request to the third server S3 .

[0091] Each candidate server in the server pool 306 that receives a request for an object can facilitate the allocation of requests for the object by determining whether to accept or reject the request. If the candidate server decides to accept the request, the candidate server can provide the object to the client 302. Subsequently, if the candidate server accepts the request, the candidate server can avoid forwarding the request to another candidate server. Alternatively, if the candidate server decides to reject the request, the request can be forwarded to another candidate server in the server pool 306. Specifically, if the candidate server device rejects the request, the candidate server can forward the request to the next candidate server in the ordered list of candidate servers. This process itself can be repeated until the candidate server in the ordered list of candidate servers accepts the request. In various embodiments, since the last candidate server in the ordered list of candidate servers is selected when the object locality weight is high, the last candidate server stores the object locally. Therefore, the last candidate server can submit a request for the object, thereby ensuring that the client 302 can access the object.

[0092] The candidate servers in the server pool 306 can determine whether to accept the request based on the popularity characteristics of the requested object at the candidate server. Specifically, the candidate servers in the server pool 306 can determine whether to accept the request for the object based on the popularity characteristics of the requested object at the candidate server. The popularity characteristics include applicable characteristics related to requesting the object at the candidate server. For example, the popularity characteristics of the requested object can include the number of requests for the object received at the candidate server (e.g., each of the candidate storage nodes), whether the candidate server accepts the request, and whether the candidate server rejects the request. The popularity characteristics can be maintained by node, and the subsequent decision of whether to accept the request for the object can be performed by node. For example, the candidate server can determine whether to accept the request for the object based on the number of requests for the object at a specific candidate server. Therefore, the decision of whether to accept the request for the object can be performed in a distributed manner across servers. As will be discussed in more detail later, the replication of the object by the candidate servers in the server pool 306 can therefore be controlled in a distributed manner across servers.

[0093] Candidate servers in server pool 306 can use their local cache permission policies to determine whether to accept a request for an object. The local cache permission policy can, for example, include a list of top-level requested objects at the candidate server. In addition, the local cache permission policy can include applicable policies for controlling cache access and cache storage of requested objects based on popularity characteristics of objects including the requested object. Specifically, the cache permission policy can include applicable policies that allow popular objects to be cached at the candidate server, for example, based on the object request, while avoiding caching unpopular objects. For example, the local cache permission policy can be implemented by a least recently used (LFU) cache technique, a 2Q cache replacement strategy, an LRU-K page replacement technique, and a least recently used (LRFU) cache technique.

[0094] The candidate servers in the server pool 306 can maintain a local cache permission policy on a node basis. Specifically, the candidate servers in the server pool 306 can maintain a local cache permission policy based on requests for objects received at the candidate servers and possibly based on whether the candidate servers accept the requests. For example, a candidate server can receive one hundred requests for a particular object. Subsequently, the candidate server can update its local cache permission policy to allow caching of the requested object based on receiving one hundred requests. In various embodiments, the candidate servers in the server pool 306 can maintain a local cache permission policy based on all requests for objects received at the candidate servers.

[0095] If a candidate server in server pool 306 accepts a request for an object, it may facilitate access to the object by the client, e.g., provide the object to client 302. In providing access to the object, the candidate server may determine whether the object is stored locally at the candidate server, e.g., in a cache. If the candidate server determines that the object is stored locally, the candidate server may provide the object to client 302 from local storage.

[0096] Alternatively, if the candidate server accepts a request for an object and determines that the object is not stored locally at the candidate server, the candidate server can retrieve the object from a location in the storage system. The candidate server can then copy the object to the local storage of the candidate server. For example, the candidate server can retrieve the object from an applicable location (e.g., the last candidate server in the ordered list of candidate servers) and copy the object to the local storage at the candidate server. When retrieving the object and copying the object to the local storage at the candidate server, the candidate server can effectively copy the object in the storage system. Since the candidate server decides whether to accept the request for the object and then retrieves and copies the object on a node-by-node basis, object replication can be controlled in a distributed manner on a node-by-node basis. This can address the previously described drawbacks of controlling object replication in a storage system in a centralized manner.

[0097] about Figure 3 In the example environment 300 shown, as described above, the third server S3 can receive a request for an object from the scheduler 304. Specifically, since the third server S3 is the first candidate server in the ordered list of candidate servers, the third server S3 can receive the request for the object from the scheduler 304. Furthermore, the third server S3 can determine to reject the request for the object. Specifically, the third server S3 can determine to reject the request for the object based on the local cache permission policy of the third server S3 (maintained based on the request for the object received at the third server S3). Subsequently, the third server S3 can forward the request for the object to the next candidate server in the ordered list of candidate servers, that is, the seventh server S7.

[0098] The seventh server S7 may receive a request for an object and determine whether to accept the request. Specifically, the seventh server S7 may use a local cache permission policy to determine whether to accept the request based on popularity. Figure 3 In the illustrated example environment 300, the seventh server S7 accepts the request. Subsequently, the seventh server S7 may determine whether the object is in its local storage. If the object is already locally stored at the seventh server S7, the seventh server S7 may provide the object to the client 302. Alternatively, if the object is not in the local storage at the seventh server S7, the seventh server S7 may retrieve the object and copy the object to the local storage, thereby effectively copying the object. Subsequently, the seventh server S7 may provide the object to the client 302.

[0099] Figure 6 A flow chart of an example method for controlling replication of an object based on popularity is shown. Figure 6The method shown is provided as an example, because there are many ways to perform the method. In addition, although the example method is described with a specific order of steps, a person of ordinary skill in the art will understand that Figure 6 and Figure 6 The modules shown in the diagram may be executed in any order and may include fewer or more modules than shown. Figure 6 Each module shown in the diagram represents one or more steps, processes, methods or routines in the method.

[0100] At step 600, dispatcher 304 receives a request for an object from client 302. Dispatcher 304 may be implemented as part of client 302. Alternatively, dispatcher 304 may be implemented remote from client 302, for example, as a cache server.

[0101] In step 602, the scheduler 304 identifies candidate storage nodes in the storage system for providing objects to the client. Specifically, the scheduler 304 may identify the candidate storage nodes by generating an ordered list of candidate storage nodes using a two-dimensional consistent hash function. More specifically, the scheduler 304 may vary the storage node diversity as an input to the two-dimensional consistent hash function to generate an ordered list of candidate storage nodes.

[0102] In step 604, the allocation of requests through one or more candidate storage nodes is facilitated according to the ordered list of candidate storage nodes so that requests for objects are submitted based on the popularity characteristics of the requested object. Specifically, the scheduler 304 can send a request for the object to the first candidate storage node in the list of candidate storage nodes. Subsequently, the candidate storage nodes including the first candidate storage node can sequentially send requests according to the ordered list of candidate storage nodes based on whether the candidate storage node accepts the request. In addition, one of the candidate storage nodes, once accepting the request, can copy the object to a local storage device (if the object is not in the local storage device), thereby effectively copying the object within the storage system. Therefore, the replication of objects in the storage system can be controlled in a distributed manner across storage nodes and by node.

[0103] The present disclosure now turns to Figure 7 and Figure 8 , which illustrate example network devices and computing devices, such as switches, routers, load balancers, client devices, and the like.

[0104] Figure 7A computing system architecture 700 is shown, in which the components of the system communicate with each other electrically using a connection 705 (such as a bus). The exemplary system 700 includes a processing unit (CPU or processor) 710 and a system connection 705, which couples various system components including a system memory 715 (such as a read-only memory (ROM) 720 and a random access memory (RAM) 725) to the processor 710. The system 700 may include a cache 712 of high-speed memory, which is directly connected to the processor 710, adjacent to the processor 710, or integrated as a part of the processor 710. The system 700 can copy data from the memory 715 and / or the storage device 730 to the cache 712 for fast access by the processor 710. In this way, the cache 712 can provide a performance boost, which avoids delays in the processor 710 when waiting for data. These and other modules can control or be configured to control the processor 710 to perform various actions. Other system memories 715 can also be used. The memory 715 can include a variety of different types of memory with different performance characteristics. Processor 710 may include any general purpose processor and hardware or software services, such as service 1 732, service 2 734, and service 3 736 stored in storage device 730, configured to control processor 710 as well as dedicated processors, where software instructions are incorporated into the actual processor design. Processor 710 may be a completely independent computing system, including multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0105] In order to enable the user to interact with the computing device 700, the input device 745 can represent any number of input mechanisms, such as, a microphone for voice, a touch-sensitive screen for gesture or graphic input, a keyboard, a mouse, motion input, voice, etc. The output device 735 can also be one or more of a variety of output mechanisms known to those skilled in the art. In some cases, a multi-mode system can enable a user to provide multiple types of input to communicate with the computing device 700. The communication interface 740 can generally control and manage user input and system output. There is no restriction on the operation on any particular hardware arrangement, so the basic features here can be easily replaced with improved hardware or firmware arrangements developed.

[0106] The storage device 730 is a non-volatile memory and may be a hard disk or other type of computer-readable medium that can store computer-accessible data, such as magnetic tape, flash memory cards, solid-state memory devices, digital versatile disks, cassettes, random access memory (RAM) 725, read-only memory (ROM) 720, and mixtures thereof.

[0107] Storage device 730 may include services 732, 734, 736 for controlling processor 710. Other hardware or software modules are contemplated. Storage device 730 may be connected to system connection 705. In one aspect, a hardware module that performs a particular function may include a software component stored in a computer-readable medium that interfaces with the necessary hardware components (such as processor 710, connection 705, output device 735, etc.) to perform the function.

[0108] Figure 8 An example network device 800 suitable for performing switching, routing, load balancing, and other networking operations is shown. The network device 800 includes a central processing unit (CPU) 804, an interface 802, and a bus 810 (e.g., a PCI bus). When operating under the control of appropriate software or firmware, the CPU 804 is responsible for performing packet management, error detection, and / or routing functions. The CPU 804 preferably performs all of these functions under the control of software including an operating system and any appropriate application software. The CPU 804 may include one or more processors 808, such as a processor from the INTEL X86 series of microprocessors. In some cases, the processor 808 may be specially designed hardware for controlling the operation of the network device 800. In some cases, a memory 806 (e.g., non-volatile RAM, ROM, etc.) also forms a part of the CPU 804. However, there are many different ways to couple the memory to the system.

[0109] Interfaces 802 are typically provided as modular interface cards (sometimes referred to as "line cards"). Typically, they control the sending and receiving of data packets over the network, and sometimes support other peripheral devices used with network device 800. Interfaces that may be provided include Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various ultra-high-speed interfaces may be provided, such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, WIFI interfaces, 3G / 4G / 5G cellular interfaces, CAN BUS, LoRA, and the like. Typically, these interfaces may include ports suitable for communicating with appropriate media. In some cases, they may also include independent processors, and in some cases, volatile RAM. Independent processors may control communication-intensive tasks such as packet switching, media control, signal processing, cryptographic processing, and management. By providing separate processors for communication-intensive tasks, these interfaces allow the main CPU 804 to effectively perform routing calculations, network diagnostics, security functions, and the like.

[0110] Although Figure 8The system shown is one specific network device of the present technology, but it is by no means the only network device architecture on which the present technology can be implemented. For example, an architecture with a single processor that handles communications as well as routing calculations, etc. is often used. In addition, other types of interfaces and media can also be used with network device 800.

[0111] Regardless of the configuration of the network device, it can use one or more memories or memory modules (including memory 806), which are configured to store program instructions for general network operations and the mechanisms of roaming, route optimization and routing functions described herein. For example, program instructions can control the operation of an operating system and / or one or more applications. One or more memories can also be configured to store tables such as mobility binding, registration and association tables, etc. Memory 806 can also store various software containers and virtualized execution environments and data.

[0112] The network device 800 may also include an application specific integrated circuit (ASIC), which may be configured to perform routing and / or switching operations. The ASIC may communicate with other components in the network device 800 via the bus 810 to exchange data and signals and coordinate various types of operations of the network device 800, such as routing, switching, and / or data storage operations.

[0113] For clarity of explanation, in some cases, the present technology may be presented as including separate functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or a combination of hardware and software.

[0114] In some embodiments, computer-readable storage devices, media, and memories may include cables or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0115] The method according to the above examples can be implemented using computer executable instructions, which are stored or otherwise available from a computer readable medium. Such instructions may include, for example, instructions and data that cause or otherwise configure a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. Some of the computer resources used may be accessed via a network. Computer executable instructions may be, for example, binary, intermediate format instructions, such as assembly language, firmware, or source code. Examples of computer readable media that can be used to store instructions, information used, and / or information created during the method according to the described examples include disks or optical disks, flash memory, USB devices with non-volatile memory, networked storage devices, and the like.

[0116] Devices implementing methods according to these disclosures may include hardware, firmware, and / or software, and may take any of a variety of form factors. Typical examples of such form factors include laptops, smart phones, small personal computers, personal digital assistants, rack-mounted devices, stand-alone devices, etc. The functionality described herein may also be embodied in peripheral devices or add-on cards. As a further example, such functionality may also be implemented between different chips on a circuit board or different processes executed in a single device.

[0117] Instructions, media for transmitting such instructions, computing resources for executing them, and other structures for supporting such computing resources are means for providing the functionality described in these disclosures.

[0118] Although various examples and other information are used to illustrate various aspects within the scope of the appended claims, limitations on the claims should not be implied based on specific features or arrangements in such examples, as a person of ordinary skill will be able to use these examples to derive a variety of implementations. In addition, although some subject matter may have been described in language specific to examples of structural features and / or method steps, it should be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or actions. For example, such functionality may be distributed differently in components other than those identified herein or performed in components other than those identified herein. Instead, the described features and steps are disclosed as examples of components and methods of systems within the scope of the appended claims.

[0119] Claim language stating "at least one of XXX" refers to at least one item in a group and indicates that one item in the group or multiple items in the group satisfy the claim. For example, claim language stating "at least one of A and B" refers to A, B, or A and B.

Claims

1. A method for controlling object replication based on object popularity, comprising: receiving, at a scheduler of the storage system, a request for an object from a client; identifying, by the scheduler, candidate storage nodes in the storage system for providing the object to the client by generating an ordered list of candidate storage nodes using a two-dimensional consistent hashing function, wherein the two-dimensional consistent hashing function depends on both a stream associated with a request for the object and the object itself; as well as Based on the ordered list of candidate storage nodes, distribution of requests for the object is facilitated by one or more of the candidate storage nodes for submitting requests for the object, wherein the one or more candidate storage nodes are configured to: facilitate distribution of requests for the object by selectively submitting requests for the object to the client using a cache permission policy, wherein the cache permission policy is formed based on popularity characteristics of the requested object at the one or more candidate storage nodes.

2. The method according to claim 1, wherein: The scheduler is configured to facilitate allocation of a request for the object by sending the request for the object to a first candidate storage node in the ordered list of candidate storage nodes.

3. The method according to claim 1 or 2, wherein: The one or more candidate storage nodes are configured to selectively submit a request for the object by: determining, at a candidate storage node of the one or more candidate storage nodes, whether to accept a request for the object at the candidate storage node using a cache admission policy of the candidate storage node, the cache admission policy being formed based on a popularity characteristic of the requested object, the popularity characteristic of the requested object including a popularity characteristic of the object being requested; In response to accepting a request for the object at the candidate storage node, identifying whether the object is in a local storage device at the candidate storage node; as well as If the object is identified as being in the local storage, the object is provided to the client from the local storage at the candidate storage node.

4. The method according to claim 3, further comprising: If the request for the object is accepted by the candidate storage node and the object is identified as not existing in the local storage at the candidate storage node, retrieving the object from the source storage node by the candidate storage node; as well as The object is copied to a local storage device at the candidate storage node to copy the object at the candidate storage node.

5. The method according to claim 3, further comprising: A cache permission policy at the candidate storage node is updated based on whether the candidate storage node accepts the request for the object.

6. The method according to claim 3, further comprising: If the candidate storage node rejects the request for the object, the candidate storage node will sequentially forward the request for the object to another candidate storage node among the one or more candidate storage nodes, wherein the other candidate storage node is configured to use the cache permission policy of the other candidate storage node to determine whether to accept the request for the object at the other candidate storage node, and the cache permission policy is formed based on the popularity characteristics of the requested object, and the popularity characteristics of the requested object include the popularity characteristics of the requested object.

7. The method according to claim 6, wherein: The another candidate storage node is a next candidate storage node related to the candidate storage node in the ordered list of the candidate storage nodes.

8. The method according to claim 1 or 2, wherein: The cache admission policy is maintained per candidate storage node at each of the candidate storage nodes based on a popularity characteristic of the requested object at each of the candidate storage nodes.

9. The method according to claim 8, wherein: The popularity characteristics of the requested object at each of the candidate storage nodes include a number of times requests for each requested object are received at each of the candidate storage nodes.

10. The method according to claim 1, wherein: The two-dimensional consistent hashing function is applied based on the varying diversity of storage nodes.

11. The method according to claim 10, wherein: At least a portion of the candidate storage nodes are selected by storage node diversity that gives greater weight to load balancing within the storage system than object locality within the storage system.

12. The method according to claim 10, wherein: At least a portion of the candidate storage nodes are selected by a storage node diversity that gives greater weight to object locality within the storage system than to load balancing within the storage system.

13. The method according to claim 12, wherein: The object is stored in local storage at the last server in the ordered list of candidate storage nodes.

14. A system for controlling object replication based on object popularity, comprising: one or more processors; as well as At least one computer-readable storage medium having instructions stored therein, which, when executed by the one or more processors, cause the one or more processors to perform operations including: receiving, at a scheduler of the storage system, a request for an object from a client; identifying, by the scheduler, candidate storage nodes in the storage system for providing the object to the client by generating an ordered list of candidate storage nodes using a two-dimensional consistent hashing function that depends on both a stream associated with a request for the object and the object itself; as well as Based on the ordered list of candidate storage nodes, distribution of requests for the object is facilitated by one or more of the candidate storage nodes for submitting requests for the object, wherein the one or more candidate storage nodes are configured to facilitate distribution of requests for the object by selectively submitting requests for the object to the client using a cache permission policy, wherein the cache permission policy is formed based on popularity characteristics of the requested object at the one or more candidate storage nodes.

15. The system of claim 14, wherein: The one or more candidate storage nodes are configured to selectively submit a request for the object by: determining, at a candidate storage node of the one or more candidate storage nodes, whether to accept a request for the object at the candidate storage node using a cache admission policy of the candidate storage node, the cache admission policy being formed based on a popularity characteristic of the requested object, the popularity characteristic of the requested object including a popularity characteristic of the object being requested; In response to accepting a request for the object at the candidate storage node, identifying whether the object is in a local storage device at the candidate storage node; as well as If the object is identified as being in the local storage, the object is provided to the client from the local storage at the candidate storage node.

16. The system of claim 15, wherein: When the instructions are executed by the one or more processors, the one or more processors further cause the one or more processors to perform operations including: If the request for the object is accepted by the candidate storage node and the object is identified as not existing in the local storage at the candidate storage node, retrieving the object from the source storage node by the candidate storage node; as well as The object is copied to a local storage device at the candidate storage node to copy the object at the candidate storage node.

17. The system according to claim 15 or 16, wherein: The instructions, when executed by the one or more processors, further cause the one or more processors to perform operations including updating a cache permission policy at the candidate storage node based on whether the candidate storage node accepts a request for the object.

18. A system according to any one of claims 14 to 16, wherein: The two-dimensional consistent hashing function is applied based on the varying diversity of storage nodes.

19. A non-transitory computer-readable storage medium having instructions stored therein, which, when executed by a processor, cause the processor to perform operations comprising: receiving, at a scheduler of the storage system, a request for an object from a client; identifying, by the scheduler, candidate storage nodes in the storage system for providing the object to the client by generating an ordered list of candidate storage nodes using a two-dimensional consistent hashing function, wherein the two-dimensional consistent hashing function depends on both a stream associated with a request for the object and the object itself; as well as Based on the ordered list of candidate storage nodes, the allocation of requests for the object is facilitated by one or more candidate storage nodes among the candidate storage nodes for submitting requests for the object, wherein the scheduler is configured to: facilitate the allocation of requests for the object by sending the request for the object to a first candidate storage node in the ordered list of candidate storage nodes, and the one or more candidate storage nodes are configured to: facilitate the allocation of requests for the object by selectively submitting requests for the object to the client using a cache permission policy, wherein the cache permission policy is formed based on popularity characteristics of the requested object at the one or more candidate storage nodes.

Images