Patent Application
20190045022
The field of invention pertains generally to the information management sciences, and, more specifically, to an edge caching node for remote cloud storage service.
With various large scale functions being migrated to the cloud, points of congestion can arise in the infrastructure deployment that carries information between the cloud and the client devices that use the cloud. As such, information systems managers are looking for new technologies that can alleviate the congestion and/or otherwise reduce any propagation delays stemming from the funneling of large amounts of information to the cloud interface.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
The data center 104, in turn, relies upon a cloud service 106 for one or more IS services (e.g., cloud computing, cloud storage, etc.). Again, not uncommonly, a large geographic distance may separate the entity's data center 104 from the cloud service 106 and one or more high speed trunk lines 107 may couple the data/transaction flow between the data center 104 and the cloud service 106.
One of the more popular cloud services is cloud storage. Here, various client devices 108 (e.g., mobile devices (e.g., smartphones, laptop computers) and/or desktop computers, tower computers, etc.) access data that is stored by the cloud service 106. As a consequence, potentially, large amounts of data traffic are transported over the trunk line 105 between the cloud service 106 and the data center 104 and/or the trunk line 107 between the data center 104 and the central office 101. In a worst case scenario, the aggregate storage needs (in terms of data) of all client devices 108 passes through both of these connections 105, 107.
IS managers have therefore been highly motivated to integrate tiered caching levels across the different nodes of the deployment of
Instead, for instance, if a item of data that is needed by a client 208 is cached at the central office switch's cache 212, the request need only travel from the client device 208 to the central office switch 201 from where the request can be fully serviced. The backbone trunk lines 205, 207, as well as the data center 204 and cloud service 206 themselves, therefore, do not participate in the handling or servicing of the request.
As such, the presence of tiered caching greatly diminishes the traffic handled by the backbone and/or back-ends of the deployment, which, in turn, greatly improves the efficiency of the overall system. Such improvements may include improved response times for requests that are serviced by a cache (because the request/response cycles travel less geographic distance and/or experience less overall queuing delay), and/or, improved responses times for requests that are ultimately serviced by the cloud service (because the back end of the deployment processes/carries less overall traffic as consequence of the caching).
A problem however is the granularity at which the caching levels 211, 212, 213 cache their respective items of data. Here, for instance, a larger client entity may “swamp out” the caching needs of a smaller client entity. For instance, referring to
Here, the office building 209 is apt to have hundreds if not thousands of client systems requesting data. To the extent these client systems are requesting same/similar items of data, such data will be cached by the central office's cache 212 at the expense of the smartphone's caching needs which only generates singular requests for any specific item and not aggregated requests as with the office building 209.
As such, it is altogether possible that little/no caching resources are leftover for the single mobile user 210 who must have its requests satisfied deeper into the deployment (e.g, the data center cache 213) if not all the way back to the cloud 206. This can be problematic not only from a fairness or quality of service perspective (the singular mobile device 210 is not able to enjoy any speed-up from the central office cache 212), but may also bring the performance of the overall deployment farther away from optimum efficiency. For instance, if the single mobile device requires a high bandwidth read-only video stream, whereas many of the office location's requests are simple requests for small items of data, perhaps a disproportionate share of response data is transported/processed by the back end trunks 205, 207 data center 204 and/or cloud service 206 by refusing the mobile device 210 cache service.
As observed in
Emerging non volatile memory chips are often characterized as being resistive in nature (the storage cells record different logic levels by maintaining different resistance values), having write and/or read access times that are faster than traditional flash non volatile semiconductor memory, and/or, can access their data at finer granularities than flash non volatile semiconductor memory (e.g., while flash is traditionally accessed only at larger block or sector granularities, by contrast, emerging non volatile memories can be accessed at cache line granularity and/or are byte addressable (e.g., write operations can be performed with a write data size that is only one byte). Another possible advantage over traditional flash non volatile memory is the integration of the storage cells in the wiring metallurgy/dielectric that resides above the semiconductor substrate rather than embedding the storage cells in the semiconductor substrate (as with DRAM). Here, if the storage cells are manufactured in the wiring metallurgy/dielectric above the semiconductor substrate, three dimensional arrays of storage cells can be formed above the substrate (e.g., by stacking cells over one another). With three-dimensional storage structures, very high storage densities may be achieved which, in turn, can result in very large caching storage space being realized at each node in the deployment.
Examples of such emerging non volatile memory may include a phase change based memory, a three dimensional crosspoint memory, “write-in-place” non volatile main memory devices, memory devices having storage cells composed of chalcogenide, a ferro-electric based memory (e.g., FRAM), a magnetic based memory (e.g., MRAM), a spin transfer torque based memory (e.g., STT-RAM), a resistor based memory (e.g., ReRAM), a Memristor based memory, universal memory, Ge2Sb2Te5 memory, programmable metallization cell memory, amorphous cell memory, Ovshinsky memory, etc.
The non volatile memory 301 may also, conceivably, be implemented with flash memory (albeit while sacrificing potential advantages of emerging non volatile memory as described above). Regardless of the precise nature of the non volatile memory that is used to implement the caching memory 301, the non volatile memory 301 may be locally front-ended with a faster, e.g., DRAM, cache 302 to speed up the observed performance of the non volatile memory.
Importantly, the non volatile memory space has a dedicated storage controller 303 that is responsible for managing customized storage treatment on a per tenant basis. For instance, the storage controller 303 may refer to a set of tenant IDs and corresponding meta data 304 for each tenant ID that describes the caching service for the particular tenant.
Examples of such meta data parameters include: 1) amount of caching resources in the non volatile memory 301 that has been allocated for the tenant (e.g., in MB or GB); 2) the address space range in the non volatile memory 301 that is allocated for the tenant (the allocated address space range should be consistent with the amount of memory space that have been allocated to the tenant); 3) whether local (e.g., DRAM) caching 302 is to be applied for the tenant; 4) whether compression/decompression is to be applied to the tenant's data; 5) whether encryption/decryption is to be applied to the tenant's data; 5) a priority level of the tenant's data (e.g., video stream data may have a higher priority level than nominal data); 6) a file/storage service accessing protocol (e.g., Network File System (NFS), New Technology File System (NTFS), Amazon S3),etc.
As depicted in
In still yet other embodiments, the storage controller 303 implements customized cache eviction policies for each tenant. That is, the storage controller 303 determines which items that are stored in the allocated storage space for each particular tenant are to be evicted from the local cache, and, e.g., moved to a next lower cache (e.g., the cache of a next deeper node in the deployment).
Here, in various embodiments, the storage controller 303 implements any of its aforementioned functions (e.g., file/storage service accessing protocol, cloud storage service protocol mimic-ing, cache eviction policies, etc.) with programmable logic circuitry (e.g., field programmable gate array (FPGA) logic circuitry 312) so as to effectively accelerate these functions as compared to an approach that implements these functions in software/firmware by a processor.
Here, the logic information 313 for each of the individual functions that the storage controller 303 can accelerate with the FPGA 312 are stored as a special type of meta data 304 that is accessed by the storage controller 303. During configuration of each tenant, the FPGA 312 is programmed with a subset of the information 313 that corresponds to the specific FPGA accelerated function to be implemented for the tenant (the selected subset of information is passed as a bit steam to the storage controller 303 and programmed into the FPGA). Here, the FPGA information 313 may include the logic for many different types of functions so that the storage controller has a large menu of possible functions that can be FPGA accelerated for any/all tenants.
As depicted in
In an embodiment, the switch 307 is configured to recognize which incoming packets received from the front end are to receive caching treatment at the node 300 and which fof these packets are not to receive caching treatment at the node 300. Here, again, if node 300 corresponds to the central office switch 201, inbound packets from the mobile device 210 or office building 209 that are not to receive caching treatment at the central office switch node 300 are forwarded by the switch 309 to the outbound trunks 205 for transportation to the data center 204. The inbound packets from the mobile device 210 or office building 209 that are to receiving caching treatment at the central office switch node 300 are forwarded by the switch 309 to a network interface 305 of the node 300 for end-point processing.
Here, each of the inbound packets that are handled by the switch 307 include header information that identify not only destination address (e.g., the cloud storage service in the cloud 206 that is packet is directed to) but also the sender. Here, the sender may be identified with an Internet Protocol (IP) and/or media access control (MAC) address of the client device that sent the request packet. If multiple tenants exist per client device (e.g., different software applications on different client devices are treated as different tenants), the sending tenant may be further identified with higher level information within the packet header structure such as a transmission flow control (TCP) address. Here, different software applications within a same client device may have a same IP address (that of the client device) but different TCP addresses.
Regardless, by processing the aforementioned header information on inbound packets, the switch 307 can quickly discern whether an inbound packet is to be treated with caching services at the node 300 or is to be forwarded to the next deeper node in the deployment. More specifically, in an embodiment, the switch 307 keeps a look-up table 308 (e.g., implemented with memory such as a content addressable memory) that identifies the packet header information of sending tenants that are to receive caching treatment at the node 300. Those incoming packets from local clients having sender header information that matches the entries on the look-up table 304 are identified as packets that are to receive caching treatment at the node 300 and are forwarded to the network interface 305, while, those incoming packets having sender header information that do not match the entries on the look-up table 304 are identified as packets that are not to receive caching treatment at the node 300 and are forwarded to the next deeper node in the deployment (e.g., the data center).
In a further embodiment, in the case where the sender header information corresponds to that of a tenant that is to receive caching treatment at the node 300, the look-up process into the look up table 304 also returns a tenant_ID that is appended to the packet and forwarded to the networking interface bank 305. Note also that destination information in the packet header can be used to identify the specific service in the cloud 206 that the request pertains to. Thus, in various embodiments, not only sender but also destination information is used to identify the tenant_ID. Here, for instance, a same tenant may use two different services in the cloud 206. The destination information is useable to distinguish between the two and assign two different tenant_IDs for a same tenant for the two different services.
The network interface 305 performs the network end point processing that the tenant expects from the destination it is sending to. For instance, if the tenant is configured to write/read data to/from the cloud service according to a specific type of network connection (e.g., a particular Transmission Control Protocol (TCP) version), the network interface processes the request packet from the tenant according to the particulars of the specific network connection type.
Other than implementing flow control according to a particular flow control protocol that the tenant expects, the networking interface 305 may also perform secure connection processes to, e.g., ensure that the request packet was actually sent by the tenant and not an imposter of the tenant. Here, as is known in the art, connections can be deemed secure if the sending entity is able to verify itself by, e.g., providing authenticating credentials when expected or when asked according to the secure authentication process performed by the end point. Here, again, the network interface 305 performs the destination end point authentication process for the tenant's communication and/or any communication related encryption/decryption processes in support thereof. Note that such processes may be very tenant specific. For instance, different tenants may have different secure identifications, may encrypt/decrypt communications with the end point according to a specific encryption/decryption processes, etc.
As such, as with the storage controller 303, the network interface 305 also relies on some form of meta data 306 that defines how communication with the tenant is to be transacted. Such tenant specific meta data 306 may include, for instance: 1) a specific flow control protocol used by the tenant (e.g., TCP, Real Time Streaming Control Protocol (RTSP), Real Time Transport Protocol (RTP), Real Time Control Protocol (RTCP), Hyper Text Transport Protocol (HTTP), a proprietary flow control protocol, etc.); 2) a specific secure communication protocol (e.g., Hyper Text Transfer Protocol Secure (HTTPS), Transport Layer Security (TLS), Secure Sockets Layer (SSL), Secure File Transfer Protocol (SFTP), etc.); 3) authentication details of the tenant. The meta data may also be kept in memory (e.g., content addressable memory) 306 that is local to the network interface 305. The tenant_ID may be used as a look up into the meta data 306.
Ultimately, after processing by the network interface 305 is completed for the inbound packet, the payload of the original packet, which nominally includes the actual request by the tenant and the aforementioned tenant_ID, is forwarded to the storage controller 303.
In an embodiment, the storage controller 303 also uses the tenant ID to look-up the storage meta data 304 for the specific tenant and processes the request packet's request according to the treatment specified in the storage meta data 304. In the case of a basic storage request, the request typically specifies whether the request is a write operation or a read operation. The request also includes an address, object ID, or filepath directory location that uniquely identifies the item to be read or written to that is formatted according to the specific protocol of the cloud storage service that the client technically sent the request to.
In the case of a write operation the request also includes new data that is to be written into the item. An acknowledgement or confirmation of a successful write that is formatted consistently with the protocol of the deeper cloud storage service may be generated by the storage controller 303 and forwarded to the network interface 305 which encapsulates the acknowledgement with the correct end-point header information for the particular connection. The encapsulated acknowledgement and tenant_ID may then be forwarded to the switch 307 which performs a reverse look-up on the tenant_ID to extract and encapsulate the sender information as destination information for the packet. The switch 307 then physically routes the outbound packet back to the sender along an egress line that is coupled to a shallower node. In the case of read operation, the same process is followed except that the acknowledgement payload also includes the requested read information.
In various embodiments, in the inbound direction, the switch's look-up 308 also recognizes any applicable redundancy treatment for any particular tenant and manipulates the data stream in response. In particular, certain cloud storage providers have different quality of service levels with respect to loss of data and/or availability, where, each quality of service level generally corresponds to a respective amount of redundancy. For example, greater guarantees against data loss and against unavailability are generally implemented with greater degrees of redundancy (more instances of the same data item are stored) while lesser guarantees against data loss and against unavailability are generally implemented with lesser degrees of redundancy (fewer instances of the same data item are stored).
Here, for any inbound write operation to be applied to an existing data item or new data item to be cached at the node 300, the switch's look-up 308 also returns how many redundant copies of the data item are to be written to/instantiated. The switch 307 then physically duplicates the request (e.g., by making multiple copies thereof) and directs them, e.g., to different network interface circuits.
Here, as observed in
The different network interfaces concurrently process their respective requests and forward their resultant to the corresponding storage controller in their respective channel. The different channels then each store their data replications in the combined memory resources of the channels. Here, each tenant_ID may have a replica extension (e.g., tenant_ID.rep) where each increment in replica extension corresponds to an additional level of replication.
Replication of incoming packets at the switch 307 also provides for replication across different caching tiers. Thus, for instance, the switch 307 may replicate an incoming request into two identical requests, send one of the requests to a local network interface 305 within the instant node 300, and, e.g., send the other of the requests to a next, deeper node with caching (e.g., from the central office switch caching tier to the data center caching tier).
In an alternative embodiment, replicas are not generated at the switch but instead are generated at the storage controller 303. That is, replica generation may be entirely handled in the storage controller in which case only one network interface 305 is invoked per session regardless of the amount of replication. Further still, other embodiments may include replication both at the switch and at the storage controller for a single tenant. In replication scenarios where more than one network interface 305 and/or storage controller 303 is used to effect replication, a primary network interfaces 305 and/or storage controller 303 is chosen to actually craft communication responses back to the tenant (responses by the other network interfaces and/or storage controllers is squelched and/or disabled).
With the above description of basic traffic flows in mind, it is pertinent to recognize that the overall dataflow path includes per tenant customized information, e.g., at each major function in the data path. Specifically, as discussed above: 1) the storage resources include a storage controller 303 that relies upon customized per tenant meta data 304 to apply proper storage request treatment for each particular tenant; 2) the switch 307 is programmed with a look-up table 308 having, e.g., per tenant entries to uniquely identify the tenant for each incoming packet and/or define what replication is to be uniquely applied to the tenant's incoming packet; and, 3) the network interface 305 relies upon per tenant meta data 306 to inform the network interface 305, e.g., what transport layer protocol is to be used for the tenant, what secure connection technology is to be used for the tenant, etc.
As such, in the node architecture 300 of
In various embodiments, the node controller 309 receives information from a management entity 214 of the deployment that defines the specific treatment for each tenant (replication, transport/security protocols, storage treatment, etc.). The node control function 309 assigns a tenant_ID for each tenant and programs the storage controller 303, switch 307 and network interface 305 look-up meta data 304, 308, 306 with the information to effectively configure/program these functions to process each tenant's requests correctly.
The controller may also collect statistics on the activity of the different tenants it is caching and, e.g., report them back to the management entity 214. Statistics can include various measurements of how frequently or infrequently cached items for a particular tenant are being cached. In response, the management entity 214 may choose to move cached items for certain tenants up or down in the deployment. For example, a tenant whose data items are being cached at the central office switch 201 but whose statistics reveal relatively less frequent access, may have the data items migrated back to the caching resources of the data center 204. Likewise, a tenant whose data items being cached at the data center 204 but whose statistics reveal relatively more frequent access, may the data items migrated up to the caching resources of the central office switch 201. Such caching policy implementation may be performed along with or in-lieu of any caching policy management applied by the storage controller 303 (such as FPGA accelerate caching policy management described above with respect to
In various embodiments, data items that are private to particular tenant or read only data items that can be accessed by more than one tenant are free to moved (e.g., “up”) to nodes in the deployment that do not observe all accesses to the cloud service 206. For instance, any read only data item or any data item that is solely a tenant of device 210 may be migrated all the way up to the caching level of the base station 202. For consistency reasons, items of data that can be written to by multiple tenants/devices, in various embodiments, are only migrated up to the caching resources of a node that can observe all accesses to the data item.
For example, in an embodiment, a data item that is writeable by both device 210 and any client of the office building 209 is only permitted to be migrated as far up as the central office switch 201 because the central office switch 201 is the highest level node in the deployment that will observe all accesses to the data item.
In a further functional extension of the switch 307, the switch's look-up table 308 and associated logic may be configured to: 1) understand which different tenants have write access to a particular data item; 2) the addresses used for each tenant specific instance of the data item stored in its caching resources; 3) detect a write operation to one of these instances by one of the tenants (by analyzing the packet payload against the information of 2) above); 4) replicate the write operation to all tenant specific instances of the data item (combined with any additional replications owing to specific redundancy treatment for any of the tenants).
Alternatively, in order to preserve storage resources, the switch's look-up table 308 and logic, may instead consolidate the number of instances so that each of the different tenants are directed to use the same primary instance in the caching resources, e.g., the instance of just one of the tenants. Here, the look-up table “swaps” or “flips” tenant IDs so that a write request for all tenants that have write access to the data item are swapped to the tenant ID whose is deemed to be the keeper of the primary data item (reads are similarly handled). Each write request may also be duplicated as appropriate (e.g., the primary tenant is the tenant that requires the most redundancy/replication amongst the tenants that have write access to the same data item). In this manner one data item is collectively used for all of the tenants.
In the embodiments described above, the node 300 may be partially or wholly integrated on one or more semiconductor chips. To the extent semiconductor manufacturing uses incompatible processes for, e.g., the memory and the functional logic, such logic and memory may be disposed on different semiconductor chips. In the case where more than one semiconductor chip is used to implement the different logic functions of the node 300, a multitude of different possible combinations exist (e.g., a single semiconductor chip is used for one of the channels 311, a single semiconductor chip is used for multiple channels 311, a semiconductor chip having one or more logical functions of a channel also includes some or all logic of the switch 307 and/or controller 309, etc.
With respect to implementation of the logic specifically, any of the logic described above may be implemented with various forms of logic circuitry including custom hardwired logic circuitry, programmable logic circuitry (e.g., field programmable gate array (FPGA), programmable logic device (PLD), programmable logic array, etc.), or logic circuitry that executes some form of program code (e.g., a general purpose processor, an embedded processor, an embedded controller, a digital signal processor, etc.). Although the
Embodiments of the invention may include various processes as set forth above. The processes may be embodied in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor to perform certain processes. Alternatively, these processes may be performed by specific/custom hardware components that contain hardwired logic circuitry or programmable logic circuitry (e.g., FPGA, PLD) for performing the processes, or by any combination of programmed computer components and custom hardware components.
Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, FLASH memory, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of media/machine-readable medium suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
