US20170193416A1 - Reducing costs related to use of networks based on pricing heterogeneity - Google Patents
Reducing costs related to use of networks based on pricing heterogeneity Download PDFInfo
- Publication number
- US20170193416A1 US20170193416A1 US15/407,459 US201715407459A US2017193416A1 US 20170193416 A1 US20170193416 A1 US 20170193416A1 US 201715407459 A US201715407459 A US 201715407459A US 2017193416 A1 US2017193416 A1 US 2017193416A1
- Authority
- US
- United States
- Prior art keywords
- cloud
- cost
- read
- write
- data block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06313—Resource planning in a project environment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Definitions
- the invention relates generally to networks and, more specifically but not exclusively, to transferring data between networks.
- Cloud providers typically charge their cloud customers for operations that their applications perform in the cloud: input/output (I/O), storage, content delivery, and so forth.
- I/O input/output
- bandwidth accounts for most of the cost associated with running an application in the cloud.
- Cloud customers are charged for both outgoing and incoming bandwidth, but the cost of outgoing bandwidth is typically dominant (e.g., the volume of outgoing traffic is typically greater than the volume of incoming traffic, and the cost of outgoing bandwidth is typically greater than the cost of incoming traffic).
- an apparatus includes a processor and a memory communicatively connected to the processor, where the processor is configured to initiate transfer of data from a first cloud toward a second cloud based on a cost-related trigger, where the cost-related trigger is based on a cost of transferring the data from the first cloud toward the second cloud.
- a computer-readable storage medium stores instructions which, when executed by a computer, cause the computer to perform a method that includes initiating transfer of data from a first cloud toward a second cloud based on a cost-related trigger, where the cost-related trigger is based on a cost of transferring the data from the first cloud toward the second cloud.
- a method includes using a processor for initiating transfer of data from a first cloud toward a second cloud based on a cost-related trigger, where the cost-related trigger is based on a cost of transferring the data from the first cloud toward the second cloud.
- FIG. 1 depicts a high-level block diagram of an exemplary cloud-based communication system
- FIG. 2 depicts one embodiment of a method for determining whether to transfer application data between the first cloud and an end user device directly without using the second cloud or indirectly via the second cloud;
- FIG. 3 depicts an embodiment of a cloud-based architecture configured to support a Multi-Cloud File System (MCFS);
- MCFS Multi-Cloud File System
- FIG. 4 depicts exemplary pseudocode for use by an end user device in utilizing the MCFS of FIG. 3 ;
- FIG. 5 depicts exemplary pseudocode for use by a read cache in supporting the MCFS of FIG. 3 ;
- FIG. 6 depicts exemplary pseudocode for use by a write cache in supporting the MCFS of FIG. 3 ;
- FIG. 7 depicts a model illustrating the read costs associated with the write cache and read cache of FIG. 3 ;
- FIG. 8 depicts one embodiment of a method for reducing one or more costs associated with using multiple clouds for transferring data in a cloud-based environment
- FIG. 9 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.
- a capability for reducing one or more costs related to use of networks (e.g., reducing the costs of data transfers for network-based applications based on pricing heterogeneity, reducing the costs of network-based storage in network-based file systems based on pricing heterogeneity, or the like, as well as various combinations thereof).
- a capability for reducing the costs of data transfers for network-based applications based on pricing heterogeneity is depicted and described with respect to FIGS. 1-2 .
- a capability for reducing the costs of network-based storage in network-based file systems based on pricing heterogeneity is depicted and described with respect to FIGS. 3-7 .
- Various other related capabilities are disclosed herein.
- a capability is provided for reducing the costs of data transfers for network-based (cloud) applications using pricing heterogeneity.
- a cost of providing data from a first network (cloud) to a user is greater than a cost of transferring the data from the first network (cloud) to a second network (cloud) and providing the data to the user from the second network (cloud)
- the data is transferred from the first network (cloud) to the second network (cloud) and provided to the user from the second network (cloud).
- a cost of providing data from a user to a first network (cloud) is greater than a cost of transferring the data from the user to a second network (cloud) and transferring the data from the second network (cloud) to the first network (cloud)
- the data is provided from the user to the second network (cloud) and transferred from the second network (cloud) to the first network (cloud).
- FIG. 1 depicts a high-level block diagram of an exemplary cloud-based communication system.
- cloud-based communication system 100 includes a first cloud 110 1 and a second cloud 110 2 (collectively, clouds 110 ).
- the cloud-based communication system 100 also includes an application data transfer control system 130 .
- the first cloud 110 1 and the second cloud 110 2 are each capable of serving an end user device 120 (although it will be appreciated that, while a single user device 120 is depicted, each of the clouds 110 is capable of supporting a plurality of user devices).
- the first cloud 110 1 and the second cloud 110 2 may be different cloud services of a common cloud provider, different cloud services of different cloud providers, or the like.
- the first cloud 110 1 and the second cloud 110 2 may be different networks or respective portions of a common network.
- the end user device 120 may be any type of user device suitable for communicating with clouds 110 (e.g., a desktop computer, a laptop computer, a tablet computer, a smart phone, or the like).
- the first cloud 110 1 hosts an application 112 .
- the application 112 may be any type of application which may be hosted within a cloud and accessed by an end user device.
- application 112 may be a web-based application, a streaming application, a file system, or the like.
- the first cloud 110 1 is configured to support communication between application 112 and user device 120 , including supporting transport of incoming application data from user device 120 to application 112 and transport of outgoing application data from application 112 to user device 120 .
- the first cloud 110 1 is configured to support communication between the application 112 and the end user device 120 , including egress communication from application 112 and ingress communication to application 112 , directly (i.e., not via second cloud 110 2 ).
- the first cloud 110 1 is configured to support communication between the application 112 and the end user device 120 , including egress communication from application 112 and ingress communication to the application 112 , via second cloud 110 2 .
- the first cloud 110 1 may include cloud resources 113 (e.g., computing resources, memory resources, or the like) which may be used to support communication between the application 112 and the end user device 120 .
- the second cloud 110 2 is configured to support communication between application 112 and user device 120 , including supporting transport of incoming application data from user device 120 to application 112 and transport of outgoing application data from application 112 to user device 120 .
- the second cloud 110 2 may be configured, on-the-fly in response to one or more conditions, to support communication between application 112 and user device 120 .
- the configuration of second cloud 110 2 may include configuring second cloud 110 2 to (1) in the egress direction, receive application data from application 112 via a path between the first cloud 110 1 and the second cloud 110 2 , and propagate the application data from the second cloud 110 2 toward user device 120 or (2) in the ingress direction, receive application data from user device 120 and transfer the application data to application 112 via a path between the second cloud 110 2 and the first cloud 110 1 .
- the configuration of second cloud 110 2 may include configuring cloud resources 114 (e.g., computing resources, memory resources, or the like) of second cloud 1102 to support communication between application 112 and user device 120 .
- the clouds 110 may be configured to employ various data transfer improvement mechanisms when transferring application data therebetween.
- the transfer of application data between clouds 110 may be performed using one or more of redundancy elimination (RE) mechanisms, compression/decompression, or the like, as well as various combinations thereof.
- RE redundancy elimination
- the use of such data transfer improvement mechanisms enables reductions in cost associated with transfer of application data between the clouds 110 .
- These data transfer improvement mechanisms may be provided by cloud resources 113 of first cloud 110 1 and cloud resources 114 of second cloud 110 2 .
- the application data transfer control system 130 is configured to determine whether application data is exchanged between application 112 and user device 120 directly (i.e., without using second cloud 110 2 ) or indirectly (i.e., via second cloud 110 2 ).
- the application data transfer control system 130 is configured to determine whether application data is exchanged between application 112 and user device 120 directly or indirectly based on a cost analysis of costs associated with exchanging application data between application 112 and user device 120 directly or indirectly.
- the application data transfer control system 130 may be configured to determine whether application data is exchanged between application 112 and user device 120 directly or indirectly based on analysis of one or more performance constraints associated with exchanging application data between application 112 and user device 120 directly or indirectly.
- the application data transfer control system 130 is depicted as being in communication with both the first cloud 110 1 and the second cloud 110 2 , for purpose of illustrating that application data transfer control system 130 is able to determine and control routing of application data between application 112 and user device 120 . It should be appreciated that application data transfer control system 130 may be implemented in any suitable manner. In some embodiments, as depicted in FIG. 1 , application data transfer control system 130 may be implemented as a standalone system which may be accessed by first cloud 110 1 or second cloud 110 2 when a determination is to be made regarding routing of the application data to the end user device 120 or from the end user device 120 .
- the application data transfer control system 130 may be implemented on the communication path between the end user device 120 and the first cloud 110 1 (e.g., for intercepting application data requests provided from user device 120 to application 112 such that a determination may be made regarding routing of the application data to the end user device 120 or from the end user device 120 ). In some embodiments, the application data transfer control system 130 may be implemented within the first cloud 110 1 (e.g., for intercepting application data requests provided from user device 120 to application 112 such that a determination may be made regarding routing of the application data to the end user device 120 or from the end user device 120 ). It should be appreciated that various combinations of such embodiments also may be used. It is further noted that the various functions of application data transfer control system 130 may be distributed in various ways, may be deployed at least partially redundantly in various ways, or the like, as well as various combinations thereof.
- application data transfer control system 130 is configured to receive a request to transfer application data from application 112 to user device 120 and to determine whether to transfer the application data via second cloud 110 2 based on a comparison of a cost of transferring the application data without using the second cloud 110 2 (i.e., serving the request directly from first cloud 110 1 ) and a cost of transferring the application data via the second cloud 110 2 (i.e., transferring the application data from first cloud 110 1 to second cloud 110 2 and then providing the application data from second cloud 110 2 to user device 120 ).
- the cost of transferring the application data without using the second cloud 110 2 is the bandwidth cost of outgoing bandwidth from first cloud 110 1 (e.g., as set by the provider of the first cloud 110 1 ).
- the cost of transferring the application data via the second cloud 110 2 is a sum of a data transfer cost (also denoted herein as E_BW_orig_compressed), a cost of hosting within the second cloud 110 2 an element configured to support delivery of application data via second cloud 110 2 (also denoted herein as E_Hosting_exitpoint), and an egress bandwidth cost (also denoted herein as E_BW_exitpoint).
- the data transfer cost is a combination of a cost of processing the application data at the first cloud 110 1 for transmission to the second cloud 110 2 (e.g., the computing cost of performing redundancy elimination (RE) processing on the application data and compressing the application data at the first cloud 110 1 ) and a bandwidth cost of transferring the processed application data from the first cloud 110 1 to the second cloud 110 2 ).
- a cost of processing the application data at the first cloud 110 1 for transmission to the second cloud 110 2 e.g., the computing cost of performing redundancy elimination (RE) processing on the application data and compressing the application data at the first cloud 110 1
- a bandwidth cost of transferring the processed application data from the first cloud 110 1 to the second cloud 110 2 e.g., the bandwidth cost of transferring the processed application data from the first cloud 110 1 to the second cloud 110 2 .
- the cost of hosting an element within the second cloud 110 2 is a cost of hosting, within the second cloud 110 2 , an element configured to receive the compressed and encoded application data from the first cloud 110 1 and configured to process the application data for transmission toward the end user device 120 (e.g., by decompressing the compressed and encoded application data and decoding the decompressed encoded application data to restore the original application data to its original form before first cloud 110 1 applied RE and compression to the application data).
- the egress bandwidth cost is a cost of transmitting the application data from the second cloud 110 2 toward the end user device 120 (e.g., the bandwidth cost of outgoing bandwidth from second cloud 110 2 , as set by the provider of the second cloud 1102 ).
- application data transfer control system 130 determines whether or not to use second cloud 110 2 to provide the application data from application 112 to user device 120 based on evaluation of the following equation: [E_BW_orig ⁇ >E_BW_orig_compressed+E_Hosting_exitpoint+E_BW_exitpoint].
- the application data is provided from application 112 to user device 120 from first cloud 110 1 without using second cloud 110 2 .
- the application 112 of first cloud 110 1 may be instructed to propagate the application data toward the end user device 120 directly.
- the application data is provided from application 112 to user device 120 from first cloud 110 1 via second cloud 110 2 .
- the application 112 of first cloud 110 1 may be instructed to propagate the application data toward the second cloud 110 2 (which also may include instructions to perform RE processing and compression of the application data before the application data is forwarded to the second cloud 110 2 ).
- the application 112 of first cloud 110 1 may be instructed to propagate the application data toward the end user device 120 indirectly via second cloud 110 2 .
- the second cloud 110 2 may be instructed that an exitpoint element(s) is needed in the second cloud 110 2 for receiving application data from the first cloud 110 1 and providing the application data toward second cloud 110 2 , such that second cloud 110 2 may provision or activate the necessary element(s) within second cloud 110 2 .
- application data transfer control system 130 is configured to receive a request to transfer application data from user device 120 to application 112 and to determine whether to transfer the application data via second cloud 110 2 based on a comparison of a cost of transferring the application data without using the second cloud 110 2 (i.e., providing the application data from user device 120 directly to the first cloud 110 1 ) and a cost of transferring the application data via the second cloud 110 2 (i.e., providing the application data from user device 120 to the second cloud 110 2 and then transferring the application data from the second cloud 110 2 to application 112 in first cloud 110 1 ).
- the cost of transferring the application data without using the second cloud 110 2 is the bandwidth cost of incoming bandwidth to first cloud 110 1 (e.g., as set by the provider of the first cloud 110 1 ).
- the cost of transferring the application data via the second cloud 110 2 is a sum of an ingress bandwidth cost (also denoted herein as I_BW_entrypoint), a cost of hosting within the second cloud 110 2 an element configured to support delivery of application data via second cloud 110 2 (also denoted herein as I_Hosting_entrypoint), and a data transfer cost (also denoted herein as I_BW_orig_compressed).
- the ingress bandwidth cost is a cost of receiving the application data at the second cloud 110 2 from the end user device 120 (e.g., the bandwidth cost of incoming bandwidth to second cloud 110 2 , as set by the provider of the second cloud 110 2 ).
- the cost of hosting an element within the second cloud 110 2 is a cost of hosting, within the second cloud 110 2 , an element configured to receive the application data and configured to encode application data using RE and to compress the encoded application data to form compressed and encoded application data.
- the data transfer cost is a combination of a cost of processing the application data at the second cloud 110 2 for transmission to the first cloud 110 1 (e.g., the computing cost of performing redundancy elimination (RE) processing on the application data and compressing the application data at the second cloud 110 2 ) and a bandwidth cost of transferring the processed application data from the second cloud 110 2 to the first cloud 110 1 ).
- RE redundancy elimination
- application data transfer control system 130 determines whether or not to use second cloud 110 2 to provide the application data from user device 120 to application 112 based on evaluation of the following equation: [I_BW_orig ⁇ >I_BW_entrypoint+I_Hosting_entrypoint+I_BW_orig_compressed].
- the application data is provided from user device 120 to application 112 without using second cloud 110 2 .
- the end user device 120 may be instructed to propagate the application data toward the application 112 directly.
- the application data is provided from user device 120 to application 112 via second cloud 110 2 .
- the end user device 120 may be instructed to propagate the application data toward the application 112 indirectly via the second cloud 110 2 .
- the second cloud 110 2 may be instructed that an entrypoint element(s) is needed in the second cloud 110 2 for receiving application data from the end user device 120 and providing the application data toward first cloud 110 1 , such that second cloud 110 2 may provision or activate the necessary element(s) within second cloud 110 2 .
- the application data transfer control system 130 may be configured to determine the costs in any suitable manner. In some embodiments, the application data transfer control system 130 may be configured to compute the costs in response to receipt of an application data transfer request. In some embodiments, the application data transfer control system 130 may be configured to compute the costs independent of receipt of application data transfer requests, such that the costs are available to the application data transfer control system 130 for use in evaluating application data transfer requests when application data transfer requests are received (e.g., the computed costs may be stored for later retrieval and use by application data transfer control system 130 ).
- application data transfer control system 130 may be configured to recomputed various costs (e.g., those impacted by changes in spot pricing) periodically.
- the application data transfer control system 130 may compute the relevant costs, retrieve the relevant costs from one or more databases, or the like.
- the element(s) may be provisioned within the second cloud 110 2 in any suitable manner.
- appropriate computing and memory resources may be allocated within the second cloud 110 2 for handling the application data propagated via the second cloud 110 2 .
- one or more Virtual Machines may be provisioned within the second cloud 110 2 for handling the application data propagated via the second cloud 110 2 .
- the manner in which resources of a cloud (such as cloud 110 2 ) may be allocated or provisioned for handling encoding/decoding, compression/decompression, and receiving/transmitting of data will be understood by one skilled in the art.
- the application data transfer control system 130 may be configured to provide various other functions of the capability for reducing the costs of data transfers for cloud applications using pricing heterogeneity.
- FIG. 2 depicted one embodiment of a method for determining whether to transfer application data between a first cloud and an end user device using a second cloud. It should be appreciated that a portion of the steps of method 200 may be performed contemporaneously, or in a different order than presented in FIG. 2 .
- step 210 method 200 begins.
- step 220 cost information associated with the first cloud and the second cloud is determined.
- a control action is initiated based on the determination as to whether to transfer application data between the first cloud and the end user device directly without using the second cloud or indirectly via the second cloud.
- the control action may include initiating one or more actions in support of the data transfer, initiating control messages to one or more elements to be involved in the data transfer, or the like, as well as various combinations thereof.
- step 240 method 200 ends.
- the application data transfer control system 130 may be configured to evaluate each of the available clouds for determining whether to provide application data to user device 120 directly (i.e., without using any of the available clouds) or indirectly (i.e., using one or more of the available clouds).
- the application data transfer control system 130 may be configured to: (1) determine the cost of transferring application data directly using the primary cloud in which the application is hosted, (2) for each available cloud in addition to the primary cloud in which the application is hosted, determine the cost of transferring application data indirectly between the primary cloud and the end user device via the available cloud, and (3) select the cloud having the lowest associated cost for performing the data transfer.
- the application data also may include application-related data which may not be visible to the application (e.g., log files or other data that is related to the application and stored in the associated cloud in which the application is hosted).
- references herein to application data may be read more generally as references to cloud-based data or, more generally, data.
- a capability is provided for reducing the costs of network-based storage in network-based file systems based on pricing heterogeneity.
- FIG. 3 depicts an embodiment of a cloud-based architecture configured to support a Multi-Cloud File System (MCFS).
- MCFS Multi-Cloud File System
- the cloud-based architecture includes three clouds 310 1 - 310 3 (collectively, clouds 310 ) that are configured to support the MCFS, as well as an end user device 320 configured to use the MCFS via interaction with clouds 310 .
- the clouds 310 may include any suitable types of clouds which may be used to support a file system.
- the clouds 310 may be provided by one or more cloud service providers (CSPs).
- CSPs cloud service providers
- the clouds 310 may be provided using different cloud services of one or more CSP, using cloud services of different CSPs, or the like.
- the clouds 310 each will include various cloud resources (e.g., computing resources, storage resources, or the like), which are omitted for purposes of clarity.
- the clouds 310 are configured to support the MCFS.
- a file system typically uses disk storage and cache storage. It will be appreciated that the disk storage of a file system stores the full set of data items of the file system, whereas the cache storage of a file system stores a subset of the data items of the file system.
- the cache storage may be combined storage configured to support write requests and read requests, or may be a distributed cache storage in which a write cache is generally used to handle write requests and a read cache is generally used to handle read requests. It should be appreciated that the typical operation of a write cache, a read cache, and a disk in a file system will be understood by one skilled in the art. It is further noted that, in general, disk storage has lower storage costs and higher access costs that cache storage.
- the clouds 310 are configured to support the MCFS as follows: cloud 310 1 is configured to support a write cache 312 of the file system, cloud 310 2 is configured to the read cache 314 of the file system, and cloud 310 3 is configured to support the disk 316 of the file system. It should be appreciated that the terms “write cache” and “read cache” used in conjunction with the MCFS may refer to cloud resources used to provide the “write cache” and “read cache” of the MCFS, respectively.
- write cache and “read cache” used in conjunction with the MCFS may refer to one or more servers responsible for handling write requests and read requests, respectively, where, unlike a cache, such a server may be configured to store the data persistently, resize the amount of storage used (e.g., by requesting and releasing resources on demand), utilize certain types of resources (e.g., a VM with CPU and main memory), or the like, as well as various combinations thereof. In this sense, the file system components are separated and placed on different cloud services of one or more CSPs. It is further noted that the designation of the “write cache” 312 and the “read cache” 314 is based on the read costs and write costs associated with the clouds 310 1 and 310 2 , respectively.
- the clouds 310 used to host the file system components may be determined by determining a set of potential CSPs and selecting the set of CSPs used to provide the clouds 310 from the set of potential CSPs.
- the set of potential CSPs considered for use in hosting the file system components may include CSPs satisfying one or more criteria or may be selected from a larger group of CSPs satisfying one or more criteria.
- the one or more criteria may include locality criteria of the CSPs (e.g., geographic locality, network locality, or the like) which may be specified to attempt to satisfy certain levels of performance, criteria related to sets of services supported by the CSPs, criteria related to specific hardware offered by the CPSs, or the like).
- the selection of the set of CSPs used to provide the clouds 310 may be based on cost model information associated with the CSPs and, optionally, other criteria (e.g., criteria discussed above or other suitable types of criteria).
- the set of CSPs used to provide the clouds 310 may be selected as follows: (1) select the potential CSP having the lowest write cost to provide the write cache portion of the MCFS (i.e., the cloud of that CSP is cloud 310 1 which is used to provide write cache 312 ), (2) select the potential CSP having the lowest read cost to provide the read cache portion of the MCFS (i.e., the cloud of that CSP is cloud 310 2 which is used to provide read cache 314 ) and (3) select the potential CSP having the lowest storage cost to provide the disk portion of the MCFS (i.e., the cloud of that CSP is cloud 310 3 which is used to provide disk 316 ).
- determination of the clouds 310 used to host the file system components may be performed by selecting from among cloud storage services of CSPs (e.g., determining a set of potential cloud storage service and selecting ones of the potential cloud storage services used to host the file system components).
- the clouds 310 are interconnected in a mesh to enable communication between the clouds 310 . This enables data items to be transferred between the write cache 312 of cloud 310 1 and the disk 316 of cloud 310 3 , between the read cache 314 of cloud 310 2 and the disk 316 of cloud 310 3 , and between the write cache 312 of cloud 310 1 and the read cache 314 of cloud 310 2 .
- the interconnection of the clouds 310 may be provided using any suitable type(s) of communication network(s).
- the end user device 320 may be any user device which may interact with a cloud-based file system such as MCFS.
- end user device 320 may be a desktop computer, a laptop computer, a tablet computer, a smart phone, or the like.
- end user device 320 is configured to communicate with the write cache 312 of cloud 310 1 and with the read cache 314 of cloud 3102 .
- the MCFS provided by the clouds 310
- For the write cache 312 of cloud 310 1 for example, there is a per-operation write cost (w 1 ) for writing to the write cache 312 and a per-operation read cost (r 1 ) for reading from the write cache 312 .
- For the read cache 314 of cloud 310 2 for example, there is a per-operation read cost (r 2 ) for reading from the read cache 314 and a per-operation write cost (w 2 ) for reading writing to the read cache 314 .
- the various read costs and write costs associated with the MCFS may include various types of costs associated with reading and writing of data blocks in a cloud-based file system, such as I/O costs, computing costs, bandwidth costs, or the like, as well as various combinations thereof. It is further noted that each of the costs may be based on a block of a particular size (e.g., 4 KB, 8 KB, or the like).
- the updated data block is transferred from the write cache 312 to the read cache 314 after k contiguous reads of the updated data block.
- k the costs of the reads and writes can be reduced below the cost of either running completely on the read cache 314 or completely on the write cache 312 . This may be better understood from a simple example. For example, consider a scenario in which there are 50 contiguous writes followed by 50 contiguous reads, and a data block that is updated is transferred from the write cache 312 to the read cache 315 only after 5 contiguous reads.
- a problem associated with choosing the value of k is that there is no a priori knowledge regarding the number of read operations or write operations following a write operation and, thus, the value of k should be chosen without prior knowledge of the types of operations that will follow a write operation (while also adapting the write cache 312 and the read cache 314 , including the pricing of the write cache 312 and the read cache 314 ). For purposes of describing the operation of end user device 120 , read cache 314 , and write cache 312 , it is assumed that the value of k is chosen appropriately.
- the handling of data block requests using clouds 310 is performed using processes associated with end user device 320 , read cache 314 , and write cache 312 , respectively.
- the end user device 320 is configured to use the MCFS.
- the end user device 320 is configured to send requests associated with data blocks (e.g., read requests for reading data blocks and write requests for writing data blocks).
- the end user device 320 is configured to send write requests to write cache 312 and to send read requests to both the read cache 314 and the write cache 312 .
- the read requests are propagated to the write cache 312 to fetch the updated data in cases where it has not yet been propagated to the read cache 314 (i.e., the number of reads for the data is less than k).
- the end user device 320 does not send the read request to the write cache 312 , rather, the read cache 314 is configured to transparently redirect read requests to the write cache 312 if the write cache 312 if the write cache 312 has the latest copy (although this will increase the latency such that it is greater than 1 round trip time (RTT)).
- the appropriate cache then returns the response to the end user device 320 .
- the configuration of the end user device 320 to support write requests and read requests may be implemented as depicted in the exemplary pseudocode of FIG. 4 .
- the exemplary pseudocode 400 for end user device 320 supports handling of read requests (specified in lines 2 - 4 ) and write requests (specified in lines 5 - 7 ).
- the read cache 314 is configured to process requests in the MCFS.
- the read cache 314 stores recently read data blocks.
- the read cache 314 is configured to process read requests from end user device 320 , requests from the write cache 312 to invalidate data blocks, and requests to update the contents of data blocks.
- the read cache 314 is configured to receive, from end user device 320 , a read request for a data block. If the data block has been invalidated by the write cache 312 , an indication of invalidation of the data block is sent to the end user device 320 so that the end user device 320 may retrieve the data block from the write cache 312 . If the data block is present in the read cache 314 and valid, the read cache 314 provides the requested data block to the end user device 320 .
- the read cache 314 may register a lease with the write cache 312 and (a) if the data block is present in the write cache 312 then the read cache 314 replies to the end user device 320 with information indicative that the data block is present in the write cache 312 such that the end user device 320 may then send a read request for the data block to the write cache 312 or (b) if the data block is not present in the write cache 312 , then the data block is obtained from the disk 316 and provided to the end user device 320 .
- the lease that is sent from the read cache 314 to the write cache 312 for the data block indicates that the read cache 314 is interested in learning about updates to the data block (e.g., the read cache 314 is requesting that the write cache 312 send an invalidate update message to the read cache 314 each time that the data block is updated at the write cache 312 ). It should be appreciated that the read cache 314 may not be interested in updates for all data blocks as some data blocks may be write-insensitive.
- the read cache 314 is configured to receive, from write cache 312 , a request to invalidate a data block. This request is sent from the write cache 312 to the read cache 314 when the data block is written. This request indicates that future accesses to the data block should be for the updated data block which is currently cached in the write cache 312 .
- the read cache 314 upon receiving the request to invalidate the data block, marks the data block in a manner for indicating that the data block has been invalidated.
- the read cache 314 may send an indication of invalidation of the data block to the end user device 320 at the time that the data block is invalidated, such that the end user device 320 is preemptively made aware of invalidation of the data block and can direct the next read request for the data block to the write cache 312 , thereby reducing latency.
- the read cache 314 does not send an indication of invalidation of the data block to the end user device 320 at the time that the data block is invalidated, but, rather, waits until a next request for the data block is received, at which time the read cache 314 responds to the end user device 320 in a manner for instructing the end user device 320 to request the data block from the write cache 312 (e.g., with an indication that the data block has been invalidated and that the end user device 320 needs to send a read request for the data block to the write cache 312 ).
- the read cache 314 is configured to receive, from write cache 312 , a request to update the contents of a data block. This request is sent from the write cache 312 to the read cache 314 when the write cache determines that it is optimal to serve the data block from the read cache 314 (e.g., when the number of contiguous read requests for the data block after a write request for the data block is greater than k).
- the data block may be provided from the write cache 312 to the read cache 314 such that subsequent requests for the data block may be served from the read cache 314 rather than from the write cache 312 .
- the configuration of the read cache 314 to support such requests may be implemented as depicted in the exemplary pseudocode of FIG. 5 .
- the exemplary pseudocode 500 for read cache 314 supports handling of read requests (specified in lines 2 - 13 ), requests to invalidate data blocks (specified in lines 14 - 15 ), and request to update contents of data blocks (specified in lines 16 - 17 ).
- the write cache 312 is configured to process requests in the MCFS.
- the write cache 312 stores recently written data blocks.
- the write cache 312 is configured to process write requests from end user device 320 , requests from the read cache 314 to register leases for data blocks, and read requests from end user device 320 .
- the write cache 312 is configured to receive, from end user device 320 , a write request for a data block.
- the updated data block is written to the write cache 312 and an invalidate message is sent from the write cache 312 to the read cache 314 if the read cache 314 has registered a lease for that data block.
- the write cache 312 is configured to receive, from read cache 314 , a request to register a lease for a data block.
- the appropriate data structures of the write cache 212 are updated, and the data block is invalidated in the read cache 314 if it is written in the write cache 312 and not yet flushed to disk 316 .
- the write cache 312 is configured to receive, from end user device 320 , a read request for a data block. If the data block is present in the write cache 312 , the write cache 312 provides the data block to the end user device 320 . If the data block is not present in the write cache 312 , the write cache 312 sends an “invalid request” message to the end user device 320 .
- the end user device 320 upon receiving the “invalid request” message from the write cache 312 , then sends a read request for the data block to the read cache 314 , which then sends the data block to the end user device 320 (e.g., by fetching the data block from the read cache 314 when the data block is present in the read cache 314 or fetching the data block from the disk 316 when the data block is not present in the read cache 314 ).
- the write cache 312 also is configured to monitor the number of read requests received for a block following receipt of a write request for the data block.
- the write cache 312 is configured to send a data block to the read cache 312 based on a determination that k contiguous read requests for the data block are received after a read request is received for the data block. As noted above, this is due to the fact that it will be cheaper to serve the read requests from the read cache 314 in the future.
- the configuration of the write cache 312 to support such requests may be implemented as depicted in the exemplary pseudocode of FIG. 6 .
- the exemplary pseudocode 600 for write cache 312 supports handling of write requests (specified in lines 2 - 4 ), requests to register leases for data blocks (specified in lines 5 - 7 ), read requests (specified in lines 8 - 9 ), and a determination as to whether to transfer a data block to the read cache 314 (specified in lines 10 - 12 ).
- the operation of the MCFS is dependent upon the value of k that is used to control transfers of data blocks from write cache 312 to read cache 314 .
- the overhead of sending invalidation messages from the write cache 312 to the read cache 314 is relatively low, because the invalidation messages are relatively small in size, can be stored in main memory, and only periodically need to be written to the disk for recovery. As a result, the cost incurred from sending such invalidation messages is negligible when compared to the cost of serving data.
- a deterministic process for determining when to transfer a data block from the write cache 312 to the read cache 314 is provided. In some embodiments, a probabilistic process for determining when to transfer a data block from the write cache 312 to the read cache 314 is provided.
- a transfer is defined as the action of transferring a data block from the write cache 312 to the read cache 314 . Any transfer from the write cache 312 to the read cache 314 will involve reading from the write cache 312 and writing into the read cache 314 .
- a data block is accessed for the purpose of making changes, the following is the sequence of operations that may be performed: (1) the data block is copied from the disk (via the read cache) and a local copy of the data block is made at the end user device 320 , (2) after the changes to the data block are complete, the data block is written into the write cache 312 , (3) any read operation on the block will be done from the write cache 312 , (4) at any point in time the data block can be transferred from the write cache 312 to the read cache 314 , (5) once the data block is transferred from the write cache 312 to the read cache 314 , all read operations are served from the read cache 314 , and (6) if the data block is further modified via the end user device 320 , the data block is written into the write cache 312 and the copy that is in the read cache 314 is invalidated.
- any write operation is a new starting point.
- the process that is performed between two write operations on a data block is further considered.
- any read operations on the data block are served out of the write cache 312 . If there are a relatively large number of read operations between the write operations, then it might be more cost effective to transfer the data block from the write cache 312 to the read cache 314 (from which reading of the data block is cheaper, because r 2 ⁇ r 1 ).
- the decision to transfer a data block from the write cache 312 to the read cache 314 depends on the number of read operations for the data block between two write operations for the data block.
- the cost of the disk read in step (1) listed above may, in some cases, be more than the cost of reading the data block from the write cache 312 ; however, the number of disk reads is relatively small as compared to reads from the working set and the disk cost can be managed well using relatively large block sizes and, thus, this cost is ignored for the purposes of simplifying the modeling for determining the value of k.
- an online process is provided for determining, based on the current number of read operations for the data block (without any knowledge of the future) if and when to initiate a transfer of a data block from the write cache 312 to the read cache 314 .
- the performance of an online process may be given as the ratio of the cost incurred by the online process to that of an offline process that has knowledge of the future. The performance ratio depends on the number of read operations between two write operations.
- ONLINE(k) denote the cost of the online process if there are k read operations between two write operations and let OFFLINE(k) denote the corresponding cost of the offline process where the where the value of k is known.
- the worst case competitive ratio of the online algorithm (denoted by ⁇ ) is given by:
- the value of k is known in advance. If there are k read operations between two write operations, then reading the data block from the write cache 312 will incur a cost of r 1 k . If the data block is instead transferred into the read cache 314 before reading, then the cost will be f+r 2 k. Thus, if
- the problem is that the value of k is not known in advance and, thus, it is necessary to determine if and when to transfer a data block from the write cache 312 to the read cache 314 in order to reduce (and, in at least some cases, minimize) cost.
- a deterministic process is used to determine if and when to transfer a data block from write cache 312 to read cache 314 .
- the transfer of a data block from the write cache 312 to the read cache 314 may be performed after a fixed number of read operations.
- the competitive ratio is even better. It should be appreciated that it is possible to show that no purely-deterministic process is able to provide a competitive ratio better than 2 ⁇ .
- the competitive ratio of the deterministic process can be improved by using a probabilistic transfer of the data block at u rather than automatically initiating a transfer of the data block at u.
- this expected competitive ratio may be improved even further by using a fully probabilistic transfer process to determine transfer of a data block from the write cache 312 to the read cache 314 .
- a probabilistic process is used to determine if and when to transfer a data block from the write cache 312 to the read cache 314 .
- p(y) represent the probability that the transfer of the data block from the write cache 312 to the read cache 314 is done after y reads of the data block. Assume that there are £ arrivals to the system.
- the expected cost is given by ⁇ 0 l [r 1 y+f+r 2 (l ⁇ y)]p(y)dy+ ⁇ l u r 1 lp(y)dy, where the first term in the integral is the expected cost if the data transfer is done before arrival l and the second term in the integral is the expected cost if the transfer is done after l arrivals.
- ⁇ e - 1 e - 1 + ⁇ ⁇ ( 1 - ⁇ ) .
- ⁇ e - ⁇ e - 1 + ⁇ ⁇ ( 1 - ⁇ ) .
- the probabilistic process for determining when to transfer a data block from the write cache 312 to the read cache 314 includes steps of: (1) with probability
- the transfer point (in terms of number of read operations on the data block) at which the data block is transferred from write cache 312 to read cache 314 is generated between zero and u from an exponential distribution having a density function of
- the data block is not transferred from write cache 312 to read cache 314 (e.g., the transfer point is set to a large number), and (3) if the number of read operations on the data block reaches the transfer point, the data block is transferred from the write cache 312 to the read cache 314 and all further read operations are handled from the read cache 314 until the next write operation is performed on the data block (at which point the data block is back in the write cache 312 and the process of generating the transfer point can be repeated).
- the probabilistic process has a better worst case competitive ratio than the deterministic process, on any given trace it is possible for the deterministic process to outperform the probabilistic process. This is due to the fact that if there are not too many reads between writes (e.g., less than u reads of the data block between two writes of the data block), then the deterministic process is optimal but the probabilistic process still has an expected competitive ratio given by
- ⁇ e - ⁇ e - 1 + ⁇ ⁇ ( 1 - ⁇ ) .
- one or more of the costs associated with handling of a data block for a client may be different for different client types (e.g., one or more costs may be different when the client is end user device 320 than when the client is one of the clouds 310 ).
- a read cost associated with reading of a data block from a cloud 310 may vary depending on whether the client for which the data block is read is an end user device (illustratively, end user device 320 ) or a cloud (e.g., read cloud 310 2 where the data block is read from write cloud 310 1 for transfer to read cloud 310 2 ).
- a write cost associated with writing of a data block into a cloud 310 may vary depending on whether the client for which the data block is written is an end user device (illustratively, end user device 320 ) or a cloud (e.g., read cloud 310 2 where the data block is transferred to read cloud 310 2 from write cloud 310 1 and written into read cloud 310 2 ).
- differences in a cost may be due to differences associated with any of the cost components from which the cost may be determined (e.g., different I/O costs for different client types, different computing costs for different client types where computing resources are used, different bandwidth costs associated with transfer of the data block to different client types), or the like, as well as various combinations thereof.
- the cost of reading and cost of writing may include any cost components which may be associated with such operations (e.g., I/O costs, computing costs, bandwidth costs, or the like, as well as various combinations thereof).
- the write cache and the read cache of the MCFS may be combined and implemented using a single cloud (i.e., using a single cloud service of a single CSP), such as where the lowest write costs and read costs are provided by a single CSP.
- more than three clouds may be used to host the three components of the MCFS (e.g., where one or more of the components of the MCFS is provided using two or more clouds), such as where two CSPs have identical or nearly identical read costs such that the two clouds of the two CSPs may be used to serve read requests from different geographic regions for performance reasons. It should be appreciated that other arrangements are contemplated.
- the separation of the file system gives flexibility in moving the write cache and the read cache between clouds, even if the disk is unable to be moved.
- the caches are designed to hold only the working set of data blocks, which is typically quite small compared to the total size of the disk (e.g., less than 1% in many cases), and, therefore, each of the caches can be independently migrated between clouds if needed or desired. Additionally, it is expected that, in most cases, a cache will be able to be migrated relatively quickly due to its relatively small size.
- the separation of the file system also supports optimizations for more common cases.
- the MCFS may be configured based on assignment of operation types to clouds based on costs for those operation types, respectively. In other words, rather than providing a MCFS that is workload agnostic, in at least one embodiment the MCFS may be configured based on the underlying workload.
- various capabilities are provided for reducing one or more costs related to use of clouds (e.g., reducing the costs of data transfers for cloud applications based on pricing heterogeneity as depicted and described with respect to FIG. 1 - FIG. 2 , reducing the costs of cloud storage in cloud-based file systems based on pricing heterogeneity as depicted and described with respect to FIG. 3 - FIG. 7 , or the like, as well as various combinations thereof).
- a general method associated with such embodiments is depicted and described with respect to FIG. 8 .
- FIG. 8 depicts one embodiment of a method for reducing one or more costs associated with using multiple clouds for transferring data in a cloud-based environment. It should be appreciated that, although primarily depicted and described herein as being performed serially, at least a portion of the steps of method 800 may be performed contemporaneously or in a different order than presented in FIG. 8 .
- method 800 begins.
- a data request is received. The data request is associated with an environment including a first cloud and a second cloud.
- the data request may be a read request for data maintained at the first cloud, where the read request may be served directly from the first cloud or indirectly via the second cloud (e.g., such as where the first cloud hosts an application and application data is to be provided from the application in the first cloud to an end user device).
- the data request may be a write request for data intended for the second cloud, where the write request may be provided directly to the second cloud or may be provided to the second cloud indirectly via the first cloud (e.g., such as where the second cloud hosts an application and application data is to be provided from an end user device to the application in the second cloud).
- the data request may be a read request for data maintained at the first cloud where the first cloud supports a write cache and the second cloud supports a read cache.
- a determination is made as to whether or not to transfer data specified by the data request from the first cloud toward the second cloud. This is a cost-based determination that may be directly or indirectly based on one or more costs associated with the first cloud or one or more costs associated with the second cloud.
- method 800 ends. It should be appreciated that the operation of method 800 may be better understood when read in conjunction with FIGS. 1-2 or FIGS. 3-7 .
- the data request may be a request to retrieve application data from an application hosted in the first cloud.
- the cost-based determination may be a comparison of a cost of providing the application data to the requesting end user device directly without using the second cloud or indirectly via the second cloud.
- the data request may be a request related to a file system maintained using the first cloud and the second cloud (e.g., where the first cloud maintains a write cache for the file system and the second cloud maintains a read cache for the file system).
- the request may be a read request or a write request.
- the cost-based determination may be a determination as to when to transfer a data block from the write cache to the read cache based on cost information associated with the clouds in which the write cache and read cache are hosted, a determination as to when to serve requests for data blocks from the write cache and when to serve requests for data blocks from the read cache, or the like, as well as various combinations thereof.
- client device is an end user device (illustratively, end user device 120 and end user device 320 )
- client devices may send requests associated with data blocks of the MCFS.
- devices such as servers, processors, or the like may initiate data block read requests and data block write requests.
- client devices may be read more generally as being client devices (e.g., any device suitable for operating as a client of the file system).
- FIG. 9 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.
- the computer 900 includes a processor 902 (e.g., a central processing unit (CPU) and/or other suitable processor(s)) and a memory 904 (e.g., random access memory (RAM), read only memory (ROM), and the like).
- processor 902 e.g., a central processing unit (CPU) and/or other suitable processor(s)
- memory 904 e.g., random access memory (RAM), read only memory (ROM), and the like.
- the computer 900 also may include a cooperating module/process 905 .
- the cooperating process 905 can be loaded into memory 904 and executed by the processor 902 to implement functions as discussed herein and, thus, cooperating process 905 (including associated data structures) can be stored on a computer readable storage medium, e.g., RAM memory, magnetic or optical drive or diskette, and the like.
- the computer 900 also may include one or more input/output devices 906 (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, one or more storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like), or the like, as well as various combinations thereof).
- a user input device such as a keyboard, a keypad, a mouse, and the like
- a user output device such as a display, a speaker, and the like
- an input port such as a display, a speaker, and the like
- an output port such as a receiver, a transmitter
- storage devices e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like
- computer 900 depicted in FIG. 9 provides a general architecture and functionality suitable for implementing functional elements described herein and/or portions of functional elements described herein.
- the computer 900 provides a general architecture and functionality suitable for implementing one or more of application 112 , cloud resources 113 , cloud resources 114 , end user device 120 , application data transfer control system 130 , one or more elements of cloud 310 1 , write cache 312 , one or more elements of cloud 310 2 , read cache 314 , one or more elements of cloud 310 3 , disk 316 , end user device 320 , or the like.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Economics (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Biodiversity & Conservation Biology (AREA)
- Quality & Reliability (AREA)
- Development Economics (AREA)
- Game Theory and Decision Science (AREA)
- Life Sciences & Earth Sciences (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Educational Administration (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
- This application is a continuation of U.S. patent application Ser. No. 14/808,133, filed on Jul. 24, 2015, entitled REDUCING COSTS RELATED TO USE OF NETWORKS BASED ON PRICING HETEROGENEITY, which application is a continuation of U.S. patent application Ser. No. 13/597,614, filed on Aug. 29, 2012, entitled REDUCING COSTS RELATED TO USE OF NETWORKS BASED ON PRICING HETEROGENEITY, which applications are hereby incorporated herein by reference in their entireties.
- The invention relates generally to networks and, more specifically but not exclusively, to transferring data between networks.
- Cloud providers typically charge their cloud customers for operations that their applications perform in the cloud: input/output (I/O), storage, content delivery, and so forth. In many cases, bandwidth accounts for most of the cost associated with running an application in the cloud. Cloud customers are charged for both outgoing and incoming bandwidth, but the cost of outgoing bandwidth is typically dominant (e.g., the volume of outgoing traffic is typically greater than the volume of incoming traffic, and the cost of outgoing bandwidth is typically greater than the cost of incoming traffic).
- Various deficiencies in the prior art are addressed by embodiments for reducing the data transfer costs.
- In some embodiments, an apparatus includes a processor and a memory communicatively connected to the processor, where the processor is configured to initiate transfer of data from a first cloud toward a second cloud based on a cost-related trigger, where the cost-related trigger is based on a cost of transferring the data from the first cloud toward the second cloud.
- In some embodiments, a computer-readable storage medium stores instructions which, when executed by a computer, cause the computer to perform a method that includes initiating transfer of data from a first cloud toward a second cloud based on a cost-related trigger, where the cost-related trigger is based on a cost of transferring the data from the first cloud toward the second cloud.
- In some embodiments, a method includes using a processor for initiating transfer of data from a first cloud toward a second cloud based on a cost-related trigger, where the cost-related trigger is based on a cost of transferring the data from the first cloud toward the second cloud.
- The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:
-
FIG. 1 depicts a high-level block diagram of an exemplary cloud-based communication system; -
FIG. 2 depicts one embodiment of a method for determining whether to transfer application data between the first cloud and an end user device directly without using the second cloud or indirectly via the second cloud; -
FIG. 3 depicts an embodiment of a cloud-based architecture configured to support a Multi-Cloud File System (MCFS); -
FIG. 4 depicts exemplary pseudocode for use by an end user device in utilizing the MCFS ofFIG. 3 ; -
FIG. 5 depicts exemplary pseudocode for use by a read cache in supporting the MCFS ofFIG. 3 ; -
FIG. 6 depicts exemplary pseudocode for use by a write cache in supporting the MCFS ofFIG. 3 ; -
FIG. 7 depicts a model illustrating the read costs associated with the write cache and read cache ofFIG. 3 ; -
FIG. 8 depicts one embodiment of a method for reducing one or more costs associated with using multiple clouds for transferring data in a cloud-based environment; and -
FIG. 9 depicts a high-level block diagram of a computer suitable for use in performing functions described herein. - To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
- In general, a capability is provided for reducing one or more costs related to use of networks (e.g., reducing the costs of data transfers for network-based applications based on pricing heterogeneity, reducing the costs of network-based storage in network-based file systems based on pricing heterogeneity, or the like, as well as various combinations thereof). A capability for reducing the costs of data transfers for network-based applications based on pricing heterogeneity is depicted and described with respect to
FIGS. 1-2 . A capability for reducing the costs of network-based storage in network-based file systems based on pricing heterogeneity is depicted and described with respect toFIGS. 3-7 . Various other related capabilities are disclosed herein. - In some embodiments, a capability is provided for reducing the costs of data transfers for network-based (cloud) applications using pricing heterogeneity.
- In at least some embodiments, when a cost of providing data from a first network (cloud) to a user is greater than a cost of transferring the data from the first network (cloud) to a second network (cloud) and providing the data to the user from the second network (cloud), the data is transferred from the first network (cloud) to the second network (cloud) and provided to the user from the second network (cloud).
- In at least some embodiments, when a cost of providing data from a user to a first network (cloud) is greater than a cost of transferring the data from the user to a second network (cloud) and transferring the data from the second network (cloud) to the first network (cloud), the data is provided from the user to the second network (cloud) and transferred from the second network (cloud) to the first network (cloud).
-
FIG. 1 depicts a high-level block diagram of an exemplary cloud-based communication system. - As depicted in
FIG. 1 , cloud-basedcommunication system 100 includes a first cloud 110 1 and a second cloud 110 2 (collectively, clouds 110). The cloud-basedcommunication system 100 also includes an application datatransfer control system 130. - The first cloud 110 1 and the second cloud 110 2 are each capable of serving an end user device 120 (although it will be appreciated that, while a single user device 120 is depicted, each of the clouds 110 is capable of supporting a plurality of user devices). The first cloud 110 1 and the second cloud 110 2 may be different cloud services of a common cloud provider, different cloud services of different cloud providers, or the like. The first cloud 110 1 and the second cloud 110 2 may be different networks or respective portions of a common network. The end user device 120 may be any type of user device suitable for communicating with clouds 110 (e.g., a desktop computer, a laptop computer, a tablet computer, a smart phone, or the like).
- The first cloud 110 1 hosts an
application 112. Theapplication 112 may be any type of application which may be hosted within a cloud and accessed by an end user device. For example,application 112 may be a web-based application, a streaming application, a file system, or the like. The first cloud 110 1 is configured to support communication betweenapplication 112 and user device 120, including supporting transport of incoming application data from user device 120 toapplication 112 and transport of outgoing application data fromapplication 112 to user device 120. The first cloud 110 1 is configured to support communication between theapplication 112 and the end user device 120, including egress communication fromapplication 112 and ingress communication toapplication 112, directly (i.e., not via second cloud 110 2). The first cloud 110 1 is configured to support communication between theapplication 112 and the end user device 120, including egress communication fromapplication 112 and ingress communication to theapplication 112, via second cloud 110 2. The first cloud 110 1 may include cloud resources 113 (e.g., computing resources, memory resources, or the like) which may be used to support communication between theapplication 112 and the end user device 120. - The second cloud 110 2 is configured to support communication between
application 112 and user device 120, including supporting transport of incoming application data from user device 120 toapplication 112 and transport of outgoing application data fromapplication 112 to user device 120. The second cloud 110 2 may be configured, on-the-fly in response to one or more conditions, to support communication betweenapplication 112 and user device 120. The configuration of second cloud 110 2 may include configuring second cloud 110 2 to (1) in the egress direction, receive application data fromapplication 112 via a path between the first cloud 110 1 and the second cloud 110 2, and propagate the application data from the second cloud 110 2 toward user device 120 or (2) in the ingress direction, receive application data from user device 120 and transfer the application data toapplication 112 via a path between the second cloud 110 2 and the first cloud 110 1. The configuration of second cloud 110 2 may include configuring cloud resources 114 (e.g., computing resources, memory resources, or the like) ofsecond cloud 1102 to support communication betweenapplication 112 and user device 120. - The clouds 110 may be configured to employ various data transfer improvement mechanisms when transferring application data therebetween. For example, the transfer of application data between clouds 110 may be performed using one or more of redundancy elimination (RE) mechanisms, compression/decompression, or the like, as well as various combinations thereof. The use of such data transfer improvement mechanisms enables reductions in cost associated with transfer of application data between the clouds 110. These data transfer improvement mechanisms may be provided by
cloud resources 113 of first cloud 110 1 andcloud resources 114 of second cloud 110 2. - The application data
transfer control system 130 is configured to determine whether application data is exchanged betweenapplication 112 and user device 120 directly (i.e., without using second cloud 110 2) or indirectly (i.e., via second cloud 110 2). The application datatransfer control system 130 is configured to determine whether application data is exchanged betweenapplication 112 and user device 120 directly or indirectly based on a cost analysis of costs associated with exchanging application data betweenapplication 112 and user device 120 directly or indirectly. The application datatransfer control system 130 may be configured to determine whether application data is exchanged betweenapplication 112 and user device 120 directly or indirectly based on analysis of one or more performance constraints associated with exchanging application data betweenapplication 112 and user device 120 directly or indirectly. - The application data
transfer control system 130 is depicted as being in communication with both the first cloud 110 1 and the second cloud 110 2, for purpose of illustrating that application datatransfer control system 130 is able to determine and control routing of application data betweenapplication 112 and user device 120. It should be appreciated that application datatransfer control system 130 may be implemented in any suitable manner. In some embodiments, as depicted inFIG. 1 , application datatransfer control system 130 may be implemented as a standalone system which may be accessed by first cloud 110 1 or second cloud 110 2 when a determination is to be made regarding routing of the application data to the end user device 120 or from the end user device 120. In some embodiments, the application datatransfer control system 130 may be implemented on the communication path between the end user device 120 and the first cloud 110 1 (e.g., for intercepting application data requests provided from user device 120 toapplication 112 such that a determination may be made regarding routing of the application data to the end user device 120 or from the end user device 120). In some embodiments, the application datatransfer control system 130 may be implemented within the first cloud 110 1 (e.g., for intercepting application data requests provided from user device 120 toapplication 112 such that a determination may be made regarding routing of the application data to the end user device 120 or from the end user device 120). It should be appreciated that various combinations of such embodiments also may be used. It is further noted that the various functions of application datatransfer control system 130 may be distributed in various ways, may be deployed at least partially redundantly in various ways, or the like, as well as various combinations thereof. - In the egress direction from the
application 112 toward the end user device 120, application datatransfer control system 130 is configured to receive a request to transfer application data fromapplication 112 to user device 120 and to determine whether to transfer the application data via second cloud 110 2 based on a comparison of a cost of transferring the application data without using the second cloud 110 2 (i.e., serving the request directly from first cloud 110 1) and a cost of transferring the application data via the second cloud 110 2 (i.e., transferring the application data from first cloud 110 1 to second cloud 110 2 and then providing the application data from second cloud 110 2 to user device 120). - In the egress direction, the cost of transferring the application data without using the second cloud 110 2 (also denoted herein as E_BW_orig) is the bandwidth cost of outgoing bandwidth from first cloud 110 1 (e.g., as set by the provider of the first cloud 110 1).
- In the egress direction, the cost of transferring the application data via the second cloud 110 2 is a sum of a data transfer cost (also denoted herein as E_BW_orig_compressed), a cost of hosting within the second cloud 110 2 an element configured to support delivery of application data via second cloud 110 2 (also denoted herein as E_Hosting_exitpoint), and an egress bandwidth cost (also denoted herein as E_BW_exitpoint). The data transfer cost is a combination of a cost of processing the application data at the first cloud 110 1 for transmission to the second cloud 110 2 (e.g., the computing cost of performing redundancy elimination (RE) processing on the application data and compressing the application data at the first cloud 110 1) and a bandwidth cost of transferring the processed application data from the first cloud 110 1 to the second cloud 110 2). The cost of hosting an element within the second cloud 110 2 is a cost of hosting, within the second cloud 110 2, an element configured to receive the compressed and encoded application data from the first cloud 110 1 and configured to process the application data for transmission toward the end user device 120 (e.g., by decompressing the compressed and encoded application data and decoding the decompressed encoded application data to restore the original application data to its original form before first cloud 110 1 applied RE and compression to the application data). The egress bandwidth cost is a cost of transmitting the application data from the second cloud 110 2 toward the end user device 120 (e.g., the bandwidth cost of outgoing bandwidth from second cloud 110 2, as set by the provider of the second cloud 1102).
- In some embodiments, for the egress direction, application data
transfer control system 130 determines whether or not to use second cloud 110 2 to provide the application data fromapplication 112 to user device 120 based on evaluation of the following equation: [E_BW_orig< >E_BW_orig_compressed+E_Hosting_exitpoint+E_BW_exitpoint]. - In some embodiments, based on a determination that [E_BW_orig<E_BW_orig_compressed+E_Hosting_exitpoint+E_BW_exitpoint], the application data is provided from
application 112 to user device 120 from first cloud 110 1 without using second cloud 110 2. Theapplication 112 of first cloud 110 1 may be instructed to propagate the application data toward the end user device 120 directly. - In some embodiments, based on a determination that [E_BW_orig>E_BW_orig_compressed+E_Hosting_exitpoint+E_BW_exitpoint], the application data is provided from
application 112 to user device 120 from first cloud 110 1 via second cloud 110 2. Theapplication 112 of first cloud 110 1 may be instructed to propagate the application data toward the second cloud 110 2 (which also may include instructions to perform RE processing and compression of the application data before the application data is forwarded to the second cloud 110 2). Theapplication 112 of first cloud 110 1 may be instructed to propagate the application data toward the end user device 120 indirectly via second cloud 110 2. Also, the second cloud 110 2 may be instructed that an exitpoint element(s) is needed in the second cloud 110 2 for receiving application data from the first cloud 110 1 and providing the application data toward second cloud 110 2, such that second cloud 110 2 may provision or activate the necessary element(s) within second cloud 110 2. - In the ingress direction from the end user device 120 toward the
application 112, application datatransfer control system 130 is configured to receive a request to transfer application data from user device 120 toapplication 112 and to determine whether to transfer the application data via second cloud 110 2 based on a comparison of a cost of transferring the application data without using the second cloud 110 2 (i.e., providing the application data from user device 120 directly to the first cloud 110 1) and a cost of transferring the application data via the second cloud 110 2 (i.e., providing the application data from user device 120 to the second cloud 110 2 and then transferring the application data from the second cloud 110 2 toapplication 112 in first cloud 110 1). - In the ingress direction, the cost of transferring the application data without using the second cloud 110 2 (also denoted herein as I_BW_orig) is the bandwidth cost of incoming bandwidth to first cloud 110 1 (e.g., as set by the provider of the first cloud 110 1).
- In the ingress direction, the cost of transferring the application data via the second cloud 110 2 is a sum of an ingress bandwidth cost (also denoted herein as I_BW_entrypoint), a cost of hosting within the second cloud 110 2 an element configured to support delivery of application data via second cloud 110 2 (also denoted herein as I_Hosting_entrypoint), and a data transfer cost (also denoted herein as I_BW_orig_compressed). The ingress bandwidth cost is a cost of receiving the application data at the second cloud 110 2 from the end user device 120 (e.g., the bandwidth cost of incoming bandwidth to second cloud 110 2, as set by the provider of the second cloud 110 2). The cost of hosting an element within the second cloud 110 2 is a cost of hosting, within the second cloud 110 2, an element configured to receive the application data and configured to encode application data using RE and to compress the encoded application data to form compressed and encoded application data. The data transfer cost is a combination of a cost of processing the application data at the second cloud 110 2 for transmission to the first cloud 110 1 (e.g., the computing cost of performing redundancy elimination (RE) processing on the application data and compressing the application data at the second cloud 110 2) and a bandwidth cost of transferring the processed application data from the second cloud 110 2 to the first cloud 110 1).
- In some embodiments, for the ingress direction, application data
transfer control system 130 determines whether or not to use second cloud 110 2 to provide the application data from user device 120 toapplication 112 based on evaluation of the following equation: [I_BW_orig< >I_BW_entrypoint+I_Hosting_entrypoint+I_BW_orig_compressed]. - In some embodiments, based on a determination that [E_I_BW_orig<I_BW_entrypoint+I_Hosting_entrypoint+I_BW_orig_compressed], the application data is provided from user device 120 to
application 112 without using second cloud 110 2. The end user device 120 may be instructed to propagate the application data toward theapplication 112 directly. - In some embodiments, based on a determination that [I_BW_orig>I_BW_entrypoint+I_Hosting_entrypoint+I_BW_orig_compressed], the application data is provided from user device 120 to
application 112 via second cloud 110 2. The end user device 120 may be instructed to propagate the application data toward theapplication 112 indirectly via the second cloud 110 2. Also, the second cloud 110 2 may be instructed that an entrypoint element(s) is needed in the second cloud 110 2 for receiving application data from the end user device 120 and providing the application data toward first cloud 110 1, such that second cloud 110 2 may provision or activate the necessary element(s) within second cloud 110 2. - In at least some such embodiments, the application data
transfer control system 130 may be configured to determine the costs in any suitable manner. In some embodiments, the application datatransfer control system 130 may be configured to compute the costs in response to receipt of an application data transfer request. In some embodiments, the application datatransfer control system 130 may be configured to compute the costs independent of receipt of application data transfer requests, such that the costs are available to the application datatransfer control system 130 for use in evaluating application data transfer requests when application data transfer requests are received (e.g., the computed costs may be stored for later retrieval and use by application data transfer control system 130). In some embodiments, in the case of spot pricing (e.g., where one or more of the costs may change periodically), application datatransfer control system 130 may be configured to recomputed various costs (e.g., those impacted by changes in spot pricing) periodically. Thus, when an application data transfer request is received at the application data transfer control system, the application datatransfer control system 130 may compute the relevant costs, retrieve the relevant costs from one or more databases, or the like. - In at least some such embodiments, the element(s) may be provisioned within the second cloud 110 2 in any suitable manner. In some embodiments, appropriate computing and memory resources may be allocated within the second cloud 110 2 for handling the application data propagated via the second cloud 110 2. In some embodiments, one or more Virtual Machines (VMs) may be provisioned within the second cloud 110 2 for handling the application data propagated via the second cloud 110 2. The manner in which resources of a cloud (such as cloud 110 2) may be allocated or provisioned for handling encoding/decoding, compression/decompression, and receiving/transmitting of data will be understood by one skilled in the art.
- The application data
transfer control system 130 may be configured to provide various other functions of the capability for reducing the costs of data transfers for cloud applications using pricing heterogeneity. -
FIG. 2 depicted one embodiment of a method for determining whether to transfer application data between a first cloud and an end user device using a second cloud. It should be appreciated that a portion of the steps ofmethod 200 may be performed contemporaneously, or in a different order than presented inFIG. 2 . - At
step 210,method 200 begins. - At
step 220, cost information associated with the first cloud and the second cloud is determined. - At
step 230, a determination is made, based on the cost information associated with the first cloud and the second cloud, as to whether to transfer application data between the first cloud and the end user device directly without using the second cloud or indirectly via the second cloud. - At
step 240, a control action is initiated based on the determination as to whether to transfer application data between the first cloud and the end user device directly without using the second cloud or indirectly via the second cloud. The control action may include initiating one or more actions in support of the data transfer, initiating control messages to one or more elements to be involved in the data transfer, or the like, as well as various combinations thereof. - At
step 240,method 200 ends. - Referring back to
FIG. 1 , It should be appreciated that, although primarily depicted and described with respect to embodiments in which only a single additional cloud (illustratively, cloud 110 2) is available for use in providing application data to user device 120, in at least one embodiment multiple additional clouds may be available for use in providing application data to user device 120. In some embodiments, the application datatransfer control system 130 may be configured to evaluate each of the available clouds for determining whether to provide application data to user device 120 directly (i.e., without using any of the available clouds) or indirectly (i.e., using one or more of the available clouds). In some embodiments, the application datatransfer control system 130 may be configured to: (1) determine the cost of transferring application data directly using the primary cloud in which the application is hosted, (2) for each available cloud in addition to the primary cloud in which the application is hosted, determine the cost of transferring application data indirectly between the primary cloud and the end user device via the available cloud, and (3) select the cloud having the lowest associated cost for performing the data transfer. - It should be appreciated that, although primarily depicted and described herein with respect to embodiments in which transfer of data between a primary cloud and an end user device (directly or indirectly via one or more additional clouds) is performed for application data visible to an application, It should be appreciated that the application data also may include application-related data which may not be visible to the application (e.g., log files or other data that is related to the application and stored in the associated cloud in which the application is hosted).
- It should be appreciated that, although primarily depicted and described herein with respect to embodiments in which transfer of data between a primary cloud and an end user device (directly or indirectly via one or more additional clouds) is performed for application data associated with an application, various other types of data may be transferred between a primary cloud and an end user device (directly or indirectly via one or more additional clouds). Thus, references herein to application data may be read more generally as references to cloud-based data or, more generally, data.
- In some embodiments, a capability is provided for reducing the costs of network-based storage in network-based file systems based on pricing heterogeneity.
-
FIG. 3 depicts an embodiment of a cloud-based architecture configured to support a Multi-Cloud File System (MCFS). - The cloud-based architecture includes three clouds 310 1-310 3 (collectively, clouds 310) that are configured to support the MCFS, as well as an
end user device 320 configured to use the MCFS via interaction with clouds 310. - The clouds 310 may include any suitable types of clouds which may be used to support a file system. The clouds 310 may be provided by one or more cloud service providers (CSPs). For example, the clouds 310 may be provided using different cloud services of one or more CSP, using cloud services of different CSPs, or the like. The clouds 310 each will include various cloud resources (e.g., computing resources, storage resources, or the like), which are omitted for purposes of clarity.
- The clouds 310 are configured to support the MCFS. In general, a file system typically uses disk storage and cache storage. It will be appreciated that the disk storage of a file system stores the full set of data items of the file system, whereas the cache storage of a file system stores a subset of the data items of the file system. The cache storage may be combined storage configured to support write requests and read requests, or may be a distributed cache storage in which a write cache is generally used to handle write requests and a read cache is generally used to handle read requests. It should be appreciated that the typical operation of a write cache, a read cache, and a disk in a file system will be understood by one skilled in the art. It is further noted that, in general, disk storage has lower storage costs and higher access costs that cache storage.
- The clouds 310 are configured to support the MCFS as follows: cloud 310 1 is configured to support a
write cache 312 of the file system, cloud 310 2 is configured to theread cache 314 of the file system, and cloud 310 3 is configured to support thedisk 316 of the file system. It should be appreciated that the terms “write cache” and “read cache” used in conjunction with the MCFS may refer to cloud resources used to provide the “write cache” and “read cache” of the MCFS, respectively. It is further noted that the terms “write cache” and “read cache” used in conjunction with the MCFS may refer to one or more servers responsible for handling write requests and read requests, respectively, where, unlike a cache, such a server may be configured to store the data persistently, resize the amount of storage used (e.g., by requesting and releasing resources on demand), utilize certain types of resources (e.g., a VM with CPU and main memory), or the like, as well as various combinations thereof. In this sense, the file system components are separated and placed on different cloud services of one or more CSPs. It is further noted that the designation of the “write cache” 312 and the “read cache” 314 is based on the read costs and write costs associated with the clouds 310 1 and 310 2, respectively. - The clouds 310 used to host the file system components may be determined by determining a set of potential CSPs and selecting the set of CSPs used to provide the clouds 310 from the set of potential CSPs. The set of potential CSPs considered for use in hosting the file system components may include CSPs satisfying one or more criteria or may be selected from a larger group of CSPs satisfying one or more criteria. The one or more criteria may include locality criteria of the CSPs (e.g., geographic locality, network locality, or the like) which may be specified to attempt to satisfy certain levels of performance, criteria related to sets of services supported by the CSPs, criteria related to specific hardware offered by the CPSs, or the like). The selection of the set of CSPs used to provide the clouds 310 may be based on cost model information associated with the CSPs and, optionally, other criteria (e.g., criteria discussed above or other suitable types of criteria). In some embodiments, given the set of potential CSPs, the set of CSPs used to provide the clouds 310 may be selected as follows: (1) select the potential CSP having the lowest write cost to provide the write cache portion of the MCFS (i.e., the cloud of that CSP is cloud 310 1 which is used to provide write cache 312), (2) select the potential CSP having the lowest read cost to provide the read cache portion of the MCFS (i.e., the cloud of that CSP is cloud 310 2 which is used to provide read cache 314) and (3) select the potential CSP having the lowest storage cost to provide the disk portion of the MCFS (i.e., the cloud of that CSP is cloud 310 3 which is used to provide disk 316). It should be appreciated that, although primarily described herein with respect to determining clouds 310 used to host the file system components by selection of CSPs used to host the file system components (e.g., where three different cloud storage services of three different CSPs are used to host the file system components), determination of the clouds 310 used to host the file system components may be performed by selecting from among cloud storage services of CSPs (e.g., determining a set of potential cloud storage service and selecting ones of the potential cloud storage services used to host the file system components).
- The clouds 310 are interconnected in a mesh to enable communication between the clouds 310. This enables data items to be transferred between the
write cache 312 of cloud 310 1 and thedisk 316 of cloud 310 3, between theread cache 314 of cloud 310 2 and thedisk 316 of cloud 310 3, and between thewrite cache 312 of cloud 310 1 and theread cache 314 of cloud 310 2. The interconnection of the clouds 310 may be provided using any suitable type(s) of communication network(s). - The
end user device 320 may be any user device which may interact with a cloud-based file system such as MCFS. For example,end user device 320 may be a desktop computer, a laptop computer, a tablet computer, a smart phone, or the like. As depicted inFIG. 3 ,end user device 320 is configured to communicate with thewrite cache 312 of cloud 310 1 and with theread cache 314 ofcloud 3102. - In the MCFS provided by the clouds 310, there are various costs that are associated with use of the MCFS by end user device 120. For the
write cache 312 of cloud 310 1, for example, there is a per-operation write cost (w1) for writing to thewrite cache 312 and a per-operation read cost (r1) for reading from thewrite cache 312. For theread cache 314 of cloud 310 2, for example, there is a per-operation read cost (r2) for reading from theread cache 314 and a per-operation write cost (w2) for reading writing to theread cache 314. Also, there is a transfer cost (f) for transferring from thewrite cache 312 to theread cache 314. It should be appreciated that the various read costs and write costs associated with the MCFS may include various types of costs associated with reading and writing of data blocks in a cloud-based file system, such as I/O costs, computing costs, bandwidth costs, or the like, as well as various combinations thereof. It is further noted that each of the costs may be based on a block of a particular size (e.g., 4 KB, 8 KB, or the like). - In the MCFS, instead of immediately transferring an updated data block from the
write cache 312 to theread cache 314, the updated data block is transferred from thewrite cache 312 to theread cache 314 after k contiguous reads of the updated data block. By identifying an appropriate value of k, the costs of the reads and writes can be reduced below the cost of either running completely on theread cache 314 or completely on thewrite cache 312. This may be better understood from a simple example. For example, consider a scenario in which there are 50 contiguous writes followed by 50 contiguous reads, and a data block that is updated is transferred from thewrite cache 312 to the read cache 315 only after 5 contiguous reads. In this example, the total cost in MCFS is 50*w1+5*r1+f+45*r2, which is 50*1+5*1.46+11.46+45*1=113.76. By contrast, if this were to run completely on theread cache 314, the cost would be 50*w2+50*r2, which is 50*10+50*1=550. Similarly, if this were to run completely on thewrite cache 312, the cost would be 50*r1+50*w1, which is 50*1.46+50*1=123. It should be appreciated that this example is based on assumptions that w1=1, r1=5, w2=10, r2=1, and f=11.46, which are examples of expected costs, normalized for purposes of computation, associated with certain existing CSPs. Thus, use of MCFS is better than running exclusively on the cloud 310 1 associated with thewrite cache 312 or the cloud 310 2 associated with theread cache 314. A problem associated with choosing the value of k is that there is no a priori knowledge regarding the number of read operations or write operations following a write operation and, thus, the value of k should be chosen without prior knowledge of the types of operations that will follow a write operation (while also adapting thewrite cache 312 and theread cache 314, including the pricing of thewrite cache 312 and the read cache 314). For purposes of describing the operation of end user device 120, readcache 314, and writecache 312, it is assumed that the value of k is chosen appropriately. It should be appreciated that, for the processes described for operation of end user device 120, readcache 314, and writecache 312, an assumption is made that a single data block is written and read per I/O operation (for the sake of simplifying the description of the processes). - In the MCFS, the handling of data block requests using clouds 310 is performed using processes associated with
end user device 320, readcache 314, and writecache 312, respectively. - The
end user device 320 is configured to use the MCFS. Theend user device 320 is configured to send requests associated with data blocks (e.g., read requests for reading data blocks and write requests for writing data blocks). Theend user device 320 is configured to send write requests to writecache 312 and to send read requests to both theread cache 314 and thewrite cache 312. The read requests are propagated to thewrite cache 312 to fetch the updated data in cases where it has not yet been propagated to the read cache 314 (i.e., the number of reads for the data is less than k). It should be appreciated that in an alternative embodiment, theend user device 320 does not send the read request to thewrite cache 312, rather, theread cache 314 is configured to transparently redirect read requests to thewrite cache 312 if thewrite cache 312 if thewrite cache 312 has the latest copy (although this will increase the latency such that it is greater than 1 round trip time (RTT)). The appropriate cache then returns the response to theend user device 320. The configuration of theend user device 320 to support write requests and read requests may be implemented as depicted in the exemplary pseudocode ofFIG. 4 . As depicted inFIG. 4 , theexemplary pseudocode 400 forend user device 320 supports handling of read requests (specified in lines 2-4) and write requests (specified in lines 5-7). - Referring back to
FIG. 3 , theread cache 314 is configured to process requests in the MCFS. Theread cache 314 stores recently read data blocks. Theread cache 314 is configured to process read requests fromend user device 320, requests from thewrite cache 312 to invalidate data blocks, and requests to update the contents of data blocks. - The
read cache 314 is configured to receive, fromend user device 320, a read request for a data block. If the data block has been invalidated by thewrite cache 312, an indication of invalidation of the data block is sent to theend user device 320 so that theend user device 320 may retrieve the data block from thewrite cache 312. If the data block is present in theread cache 314 and valid, theread cache 314 provides the requested data block to theend user device 320. If the data block is new to theread cache 314, theread cache 314 may register a lease with thewrite cache 312 and (a) if the data block is present in thewrite cache 312 then theread cache 314 replies to theend user device 320 with information indicative that the data block is present in thewrite cache 312 such that theend user device 320 may then send a read request for the data block to thewrite cache 312 or (b) if the data block is not present in thewrite cache 312, then the data block is obtained from thedisk 316 and provided to theend user device 320. The lease that is sent from theread cache 314 to thewrite cache 312 for the data block indicates that theread cache 314 is interested in learning about updates to the data block (e.g., theread cache 314 is requesting that thewrite cache 312 send an invalidate update message to theread cache 314 each time that the data block is updated at the write cache 312). It should be appreciated that theread cache 314 may not be interested in updates for all data blocks as some data blocks may be write-insensitive. - The
read cache 314 is configured to receive, fromwrite cache 312, a request to invalidate a data block. This request is sent from thewrite cache 312 to theread cache 314 when the data block is written. This request indicates that future accesses to the data block should be for the updated data block which is currently cached in thewrite cache 312. Theread cache 314, upon receiving the request to invalidate the data block, marks the data block in a manner for indicating that the data block has been invalidated. In some embodiments, theread cache 314 may send an indication of invalidation of the data block to theend user device 320 at the time that the data block is invalidated, such that theend user device 320 is preemptively made aware of invalidation of the data block and can direct the next read request for the data block to thewrite cache 312, thereby reducing latency. In some embodiments, which may reduce the overhead at the expense of latency, theread cache 314 does not send an indication of invalidation of the data block to theend user device 320 at the time that the data block is invalidated, but, rather, waits until a next request for the data block is received, at which time theread cache 314 responds to theend user device 320 in a manner for instructing theend user device 320 to request the data block from the write cache 312 (e.g., with an indication that the data block has been invalidated and that theend user device 320 needs to send a read request for the data block to the write cache 312). - The
read cache 314 is configured to receive, fromwrite cache 312, a request to update the contents of a data block. This request is sent from thewrite cache 312 to theread cache 314 when the write cache determines that it is optimal to serve the data block from the read cache 314 (e.g., when the number of contiguous read requests for the data block after a write request for the data block is greater than k). The data block may be provided from thewrite cache 312 to theread cache 314 such that subsequent requests for the data block may be served from theread cache 314 rather than from thewrite cache 312. - The configuration of the
read cache 314 to support such requests may be implemented as depicted in the exemplary pseudocode ofFIG. 5 . As depicted inFIG. 5 , theexemplary pseudocode 500 forread cache 314 supports handling of read requests (specified in lines 2-13), requests to invalidate data blocks (specified in lines 14-15), and request to update contents of data blocks (specified in lines 16-17). - Referring again to
FIG. 3 , thewrite cache 312 is configured to process requests in the MCFS. Thewrite cache 312 stores recently written data blocks. Thewrite cache 312 is configured to process write requests fromend user device 320, requests from theread cache 314 to register leases for data blocks, and read requests fromend user device 320. - The
write cache 312 is configured to receive, fromend user device 320, a write request for a data block. The updated data block is written to thewrite cache 312 and an invalidate message is sent from thewrite cache 312 to theread cache 314 if theread cache 314 has registered a lease for that data block. - The
write cache 312 is configured to receive, fromread cache 314, a request to register a lease for a data block. The appropriate data structures of the write cache 212 are updated, and the data block is invalidated in theread cache 314 if it is written in thewrite cache 312 and not yet flushed todisk 316. - The
write cache 312 is configured to receive, fromend user device 320, a read request for a data block. If the data block is present in thewrite cache 312, thewrite cache 312 provides the data block to theend user device 320. If the data block is not present in thewrite cache 312, thewrite cache 312 sends an “invalid request” message to theend user device 320. Theend user device 320, upon receiving the “invalid request” message from thewrite cache 312, then sends a read request for the data block to theread cache 314, which then sends the data block to the end user device 320 (e.g., by fetching the data block from theread cache 314 when the data block is present in theread cache 314 or fetching the data block from thedisk 316 when the data block is not present in the read cache 314). - The
write cache 312 also is configured to monitor the number of read requests received for a block following receipt of a write request for the data block. Thewrite cache 312 is configured to send a data block to theread cache 312 based on a determination that k contiguous read requests for the data block are received after a read request is received for the data block. As noted above, this is due to the fact that it will be cheaper to serve the read requests from theread cache 314 in the future. - The configuration of the
write cache 312 to support such requests may be implemented as depicted in the exemplary pseudocode ofFIG. 6 . As depicted inFIG. 6 , theexemplary pseudocode 600 forwrite cache 312 supports handling of write requests (specified in lines 2-4), requests to register leases for data blocks (specified in lines 5-7), read requests (specified in lines 8-9), and a determination as to whether to transfer a data block to the read cache 314 (specified in lines 10-12). - Referring again to
FIG. 3 , it should be appreciated, from the foregoing discussion of the operation of the MCFS, that the operation of the MCFS is dependent upon the value of k that is used to control transfers of data blocks fromwrite cache 312 to readcache 314. In analyzing determination of values of k, It should be appreciated that the overhead of sending invalidation messages from thewrite cache 312 to theread cache 314 is relatively low, because the invalidation messages are relatively small in size, can be stored in main memory, and only periodically need to be written to the disk for recovery. As a result, the cost incurred from sending such invalidation messages is negligible when compared to the cost of serving data. In some embodiments, a deterministic process for determining when to transfer a data block from thewrite cache 312 to theread cache 314 is provided. In some embodiments, a probabilistic process for determining when to transfer a data block from thewrite cache 312 to theread cache 314 is provided. These processes may be better understood by first considering certain characteristics of the MCFS ofFIG. 3 . - In the MCFS, assume that all of the files (and their associated data blocks) are stored on the
disk 316, and that there are two clouds (of different CSPs) on which thewrite cache 312 and theread cache 314 are instantiated. In the MCFS, assume that the cost of one read (write) operation on thewrite cache 312 is r1 (w1) and that the cost of one read (write) operation on theread cache 314 is r2 (w2). These costs per access include any bandwidth costs that are incurred (which may be based on block size). - In the MCFS, assume that w1<w2 and that r1>r2. It should be appreciated that β is used to represent the ratio of r2 to r1 (i.e., β is less than one). This model, illustrating the read costs associated with the
write cache 312 and theread cache 314 is depicted inFIG. 7 . InFIG. 7 , the number of reads for a data block is plotted on the x-axis and the cost of the reads is plotted on the y-axis. As the number of read operations increases (on the x-axis), the cost due to r1 (represented by a first curve in the graph) increases faster than the cost due to r2 (represented by a second curve in the graph), but use ofread cache 314 requires an initial investment of f. The plot (line) associated withwrite cache 312 and the plot (line) associated withread cache 314 intersect each other at u read operations. - In the MCFS, there can be a difference between the per unit time storage costs at the
write cache 312 and theread cache 314. It is expected that the difference in the storage costs between the cloud 310 1 and the cloud 310 2 is relatively small when compared to the difference in access costs between the between the cloud 310 1 and the cloud 310 2. Accordingly, for purposes of simplifying the discussion, the difference in storage costs is ignored and the difference in access costs is considered. For the purposes of this discussion, a transfer is defined as the action of transferring a data block from thewrite cache 312 to theread cache 314. Any transfer from thewrite cache 312 to theread cache 314 will involve reading from thewrite cache 312 and writing into theread cache 314. This incurs a cost of f=r1+w2. When a data block is accessed for the purpose of making changes, the following is the sequence of operations that may be performed: (1) the data block is copied from the disk (via the read cache) and a local copy of the data block is made at theend user device 320, (2) after the changes to the data block are complete, the data block is written into thewrite cache 312, (3) any read operation on the block will be done from thewrite cache 312, (4) at any point in time the data block can be transferred from thewrite cache 312 to theread cache 314, (5) once the data block is transferred from thewrite cache 312 to theread cache 314, all read operations are served from theread cache 314, and (6) if the data block is further modified via theend user device 320, the data block is written into thewrite cache 312 and the copy that is in theread cache 314 is invalidated. Thus, any write operation is a new starting point. In order to illustrate the manner in which the value of k may be determined, the process that is performed between two write operations on a data block is further considered. During the time that the data block is in thewrite cache 312, any read operations on the data block are served out of thewrite cache 312. If there are a relatively large number of read operations between the write operations, then it might be more cost effective to transfer the data block from thewrite cache 312 to the read cache 314 (from which reading of the data block is cheaper, because r2<r1). Thus, as noted above, the decision to transfer a data block from thewrite cache 312 to theread cache 314 depends on the number of read operations for the data block between two write operations for the data block. It should be appreciated that the cost of the disk read in step (1) listed above may, in some cases, be more than the cost of reading the data block from thewrite cache 312; however, the number of disk reads is relatively small as compared to reads from the working set and the disk cost can be managed well using relatively large block sizes and, thus, this cost is ignored for the purposes of simplifying the modeling for determining the value of k. - In some embodiments, given that the number of read operations for a data block between two write operations for the data block is not known in advance, an online process is provided for determining, based on the current number of read operations for the data block (without any knowledge of the future) if and when to initiate a transfer of a data block from the
write cache 312 to theread cache 314. The performance of an online process may be given as the ratio of the cost incurred by the online process to that of an offline process that has knowledge of the future. The performance ratio depends on the number of read operations between two write operations. Let ONLINE(k) denote the cost of the online process if there are k read operations between two write operations and let OFFLINE(k) denote the corresponding cost of the offline process where the where the value of k is known. The worst case competitive ratio of the online algorithm (denoted by θ) is given by: -
- In the offline process, as noted above, the value of k is known in advance. If there are k read operations between two write operations, then reading the data block from the
write cache 312 will incur a cost of r1k . If the data block is instead transferred into theread cache 314 before reading, then the cost will be f+r2k. Thus, if -
- then it is more cost effective to keep the file in the
write cache 312 than in theread cache 314. By contrast, if -
- then it is more cost effective to transfer the file from the
write cache 312 to theread cache 314 when the write operation is complete. As noted above, however, the problem is that the value of k is not known in advance and, thus, it is necessary to determine if and when to transfer a data block from thewrite cache 312 to theread cache 314 in order to reduce (and, in at least some cases, minimize) cost. - In some embodiments, a deterministic process is used to determine if and when to transfer a data block from
write cache 312 to readcache 314. The transfer of a data block from thewrite cache 312 to theread cache 314 may be performed after a fixed number of read operations. Let -
- represent the crossover point (as depicted in
FIG. 7 ) where the cost of using thewrite cache 312 or theread cache 314 is the same. Assume that the data block is held in thewrite cache 312 until there are u reads, at which point the data block is transferred from thewrite cache 312 to theread cache 314 and all further reads (until the next write operation for the data block) are from theread cache 314. If the number of read operations is l<u, then the competitive ratio is one. If the number of read operations is l=u, then the optimal cost is r1u and the cost of the online process where the data block is transferred fromwrite cache 312 to readcache 314 after u read operations is given by (r1)u+f, such that the competitive ratio is -
- If the number of read operations is l>u, then the competitive ratio is even better. It should be appreciated that it is possible to show that no purely-deterministic process is able to provide a competitive ratio better than 2−β. The competitive ratio of the deterministic process, however, can be improved by using a probabilistic transfer of the data block at u rather than automatically initiating a transfer of the data block at u.
- In the case of probabilistic transfers, there is a probability (φ) that the data block is transferred from
write cache 312 to readcache 314 at u and a corresponding probability (1−φ) that the data block is not transferred fromwrite cache 312 to readcache 314 at u. If l<u, the competitive ratio is one. If l=u the competitive ratio is -
- If l>u, the competitive ratio is
-
- It may be shown that the competitive ratio is maximized when l→∞ which gives a competitive ratio of
-
- Since, in at least some embodiments, it is desirable to minimize the worst case competitive ratio, the performance of the cases in which l=u and l>u may be equated to obtain the following equation:
-
- Solving this equation for φ result in
-
- and an expected competitive ratio of
-
- It should be appreciated that this expected competitive ratio may be improved even further by using a fully probabilistic transfer process to determine transfer of a data block from the
write cache 312 to theread cache 314. - In some embodiments, a probabilistic process is used to determine if and when to transfer a data block from the
write cache 312 to theread cache 314. Let p(y) represent the probability that the transfer of the data block from thewrite cache 312 to theread cache 314 is done after y reads of the data block. Assume that there are £ arrivals to the system. The expected cost is given by ∫0 l[r1y+f+r2(l−y)]p(y)dy+∫l ur1lp(y)dy, where the first term in the integral is the expected cost if the data transfer is done before arrival l and the second term in the integral is the expected cost if the transfer is done after l arrivals. It is assumed that that the data transfer (if it is done) is performed on or before u reads of the data block. If the number of reads l≦u, then the optimal cost is r1l. If θ is the expected competitive ratio, then it is desirable for θr1l=∫0 l[r1y+f+r2(l−y)]p(y)dy+∫l ur1lp(y)dy. Differentiating both sides with respect to l gives θr1=fp(l)+r2∫0 lp(y)dy+r1∫l up(y)dy, and differentiating again with respect to l gives fp′(l)−(r1−r2)p(l)=0. This equation may be rewritten as -
- The solution to the differential equation is
-
- If an assumption is made that the transfer is done by u reads with probability φ, this gives
-
- Solving this equation for K gives
-
- and, therefore,
-
- Setting l=0 in θr1=fp(l)+r2∫0 lp(y)dy+r1∫l up(y)dy gives θr1=fp(0)+r1φ. Evaluating p(0) in
-
- gives
-
- This is the competitive ratio if l≦u. On the other hand, when l>u, the competitive ratio for this scheme is achieved when l→∞ as in the case when l>u in the deterministic transfer process (i.e., the competitive ratio is
-
- Evaluating the two competitive ratios gives
-
- such that solving for φ gives
-
- Then, calculating the value of θ gives
-
- In some embodiments, the probabilistic process for determining when to transfer a data block from the
write cache 312 to theread cache 314 includes steps of: (1) with probability -
- the transfer point (in terms of number of read operations on the data block) at which the data block is transferred from
write cache 312 to readcache 314 is generated between zero and u from an exponential distribution having a density function of -
- (2) with
probability 1−φ, the data block is not transferred fromwrite cache 312 to read cache 314 (e.g., the transfer point is set to a large number), and (3) if the number of read operations on the data block reaches the transfer point, the data block is transferred from thewrite cache 312 to theread cache 314 and all further read operations are handled from theread cache 314 until the next write operation is performed on the data block (at which point the data block is back in thewrite cache 312 and the process of generating the transfer point can be repeated). - It should be appreciated that, although the probabilistic process has a better worst case competitive ratio than the deterministic process, on any given trace it is possible for the deterministic process to outperform the probabilistic process. This is due to the fact that if there are not too many reads between writes (e.g., less than u reads of the data block between two writes of the data block), then the deterministic process is optimal but the probabilistic process still has an expected competitive ratio given by
-
- It should be appreciated that, although primarily depicted and described herein with respect to embodiments in which an assumption is made that the costs associated with handling of a data block for a client are uniform for different client types, in at least one embodiment one or more of the costs associated with handling of a data block for a client may be different for different client types (e.g., one or more costs may be different when the client is
end user device 320 than when the client is one of the clouds 310). For example, a read cost associated with reading of a data block from a cloud 310 may vary depending on whether the client for which the data block is read is an end user device (illustratively, end user device 320) or a cloud (e.g., read cloud 310 2 where the data block is read from write cloud 310 1 for transfer to read cloud 310 2). Similarly, for example, a write cost associated with writing of a data block into a cloud 310 may vary depending on whether the client for which the data block is written is an end user device (illustratively, end user device 320) or a cloud (e.g., read cloud 310 2 where the data block is transferred to read cloud 310 2 from write cloud 310 1 and written into read cloud 310 2). It should be appreciated that such differences in a cost may be due to differences associated with any of the cost components from which the cost may be determined (e.g., different I/O costs for different client types, different computing costs for different client types where computing resources are used, different bandwidth costs associated with transfer of the data block to different client types), or the like, as well as various combinations thereof. Thus, the value off associated with transfer of a data block from the write cloud 310 1 to the read cloud 310 2 may be written more generally as f=[cost of reading from the write cloud 310 1+cost of writing to the read cloud 310 2], where (1) the cost of reading from the write cloud 310 1 when the data block is being transferred to the read cloud 310 2 may be the same as or different than the cost that would be incurred for reading the data block from the write cloud 310 1 for transmission to end user device 320 (denoted herein as r1) and, similarly, (2) the cost of writing to the read cloud 310 2 when the data block is being transferred to the read cloud 310 2 may be the same as or different than the cost that would be incurred for writing the data block to the read cloud 310 2 when the writing of the data block is initiated by the end user device 320 (denoted herein as w2). Again, It should be appreciated that, in the expression f=[cost of reading from the write cloud 310 1+cost of writing to the read cloud 310 2], the cost of reading and cost of writing may include any cost components which may be associated with such operations (e.g., I/O costs, computing costs, bandwidth costs, or the like, as well as various combinations thereof). - It should be appreciated that, although primarily depicted and described with respect to embodiments in which three different clouds (illustratively, clouds 310) are used to host the three components of the MCFS, in at least one embodiment fewer or more clouds 310 may be used to host the three components of the MCFS. In some embodiments, the write cache and the read cache of the MCFS may be combined and implemented using a single cloud (i.e., using a single cloud service of a single CSP), such as where the lowest write costs and read costs are provided by a single CSP. In some embodiments, more than three clouds may be used to host the three components of the MCFS (e.g., where one or more of the components of the MCFS is provided using two or more clouds), such as where two CSPs have identical or nearly identical read costs such that the two clouds of the two CSPs may be used to serve read requests from different geographic regions for performance reasons. It should be appreciated that other arrangements are contemplated.
- It should be appreciated that separation of the file system components using multiple clouds provides various advantages. The separation of the file system gives flexibility in moving the write cache and the read cache between clouds, even if the disk is unable to be moved. In general, the caches are designed to hold only the working set of data blocks, which is typically quite small compared to the total size of the disk (e.g., less than 1% in many cases), and, therefore, each of the caches can be independently migrated between clouds if needed or desired. Additionally, it is expected that, in most cases, a cache will be able to be migrated relatively quickly due to its relatively small size. The separation of the file system also supports optimizations for more common cases. In many file systems, data blocks are mainly read or mainly written and, further, recently read data is re-read often and recently written data is overwritten often. Similarly, in many file systems, reading and writing of the same data block is relatively rare (although it still needs to be accounted for). In view of the foregoing points, it is expected that separation of the file system using multiple clouds (e.g., mapping the cheapest write service to the write cache, the cheapest read service to the read cache, and the cheapest storage service to the disk) tends to result in significant cost savings.
- It should be appreciated that, although primarily depicted and described with respect to embodiments in which storage types are assigned to clouds based on the costs of those storage types at those clouds (e.g., providing a write cache using a cloud service/CSP having a lowest write cost (of the set of potential cloud services/CSPs), providing a read cache using a cloud service/CSP having a lowest read cost (of the set of potential cloud services/CSPs), and providing a disk using a cloud service/CSP having a lowest storage cost (of the set of potential cloud services/CSPs), in at least one embodiment the MCFS may be configured based on assignment of operation types to clouds based on costs for those operation types, respectively. In other words, rather than providing a MCFS that is workload agnostic, in at least one embodiment the MCFS may be configured based on the underlying workload.
- As noted herein, various capabilities are provided for reducing one or more costs related to use of clouds (e.g., reducing the costs of data transfers for cloud applications based on pricing heterogeneity as depicted and described with respect to
FIG. 1 -FIG. 2 , reducing the costs of cloud storage in cloud-based file systems based on pricing heterogeneity as depicted and described with respect toFIG. 3 -FIG. 7 , or the like, as well as various combinations thereof). A general method associated with such embodiments is depicted and described with respect toFIG. 8 . -
FIG. 8 depicts one embodiment of a method for reducing one or more costs associated with using multiple clouds for transferring data in a cloud-based environment. It should be appreciated that, although primarily depicted and described herein as being performed serially, at least a portion of the steps ofmethod 800 may be performed contemporaneously or in a different order than presented inFIG. 8 . Atstep 810,method 800 begins. Atstep 820, a data request is received. The data request is associated with an environment including a first cloud and a second cloud. In some embodiments, the data request may be a read request for data maintained at the first cloud, where the read request may be served directly from the first cloud or indirectly via the second cloud (e.g., such as where the first cloud hosts an application and application data is to be provided from the application in the first cloud to an end user device). In some embodiments, the data request may be a write request for data intended for the second cloud, where the write request may be provided directly to the second cloud or may be provided to the second cloud indirectly via the first cloud (e.g., such as where the second cloud hosts an application and application data is to be provided from an end user device to the application in the second cloud). In some embodiments, the data request may be a read request for data maintained at the first cloud where the first cloud supports a write cache and the second cloud supports a read cache. Atstep 830, a determination is made as to whether or not to transfer data specified by the data request from the first cloud toward the second cloud. This is a cost-based determination that may be directly or indirectly based on one or more costs associated with the first cloud or one or more costs associated with the second cloud. Atstep 840,method 800 ends. It should be appreciated that the operation ofmethod 800 may be better understood when read in conjunction withFIGS. 1-2 orFIGS. 3-7 . - In the embodiments of
FIGS. 1-2 , for example, the data request may be a request to retrieve application data from an application hosted in the first cloud. Here, the cost-based determination may be a comparison of a cost of providing the application data to the requesting end user device directly without using the second cloud or indirectly via the second cloud. These embodiments will be better understood by way of reference toFIGS. 1-2 . - In the embodiments of
FIGS. 3-7 , for example, the data request may be a request related to a file system maintained using the first cloud and the second cloud (e.g., where the first cloud maintains a write cache for the file system and the second cloud maintains a read cache for the file system). The request may be a read request or a write request. Here, the cost-based determination may be a determination as to when to transfer a data block from the write cache to the read cache based on cost information associated with the clouds in which the write cache and read cache are hosted, a determination as to when to serve requests for data blocks from the write cache and when to serve requests for data blocks from the read cache, or the like, as well as various combinations thereof. - It should be appreciated that, although primarily depicted and described herein with respect to embodiments in which the client device is an end user device (illustratively, end user device 120 and end user device 320), It should be appreciated that other types of client devices may send requests associated with data blocks of the MCFS. For example, devices such as servers, processors, or the like may initiate data block read requests and data block write requests. Thus, in at least some embodiments, various references herein to end user devices may be read more generally as being client devices (e.g., any device suitable for operating as a client of the file system).
-
FIG. 9 depicts a high-level block diagram of a computer suitable for use in performing functions described herein. - The
computer 900 includes a processor 902 (e.g., a central processing unit (CPU) and/or other suitable processor(s)) and a memory 904 (e.g., random access memory (RAM), read only memory (ROM), and the like). - The
computer 900 also may include a cooperating module/process 905. The cooperating process 905 can be loaded intomemory 904 and executed by theprocessor 902 to implement functions as discussed herein and, thus, cooperating process 905 (including associated data structures) can be stored on a computer readable storage medium, e.g., RAM memory, magnetic or optical drive or diskette, and the like. - The
computer 900 also may include one or more input/output devices 906 (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, one or more storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like), or the like, as well as various combinations thereof). - It will be appreciated that
computer 900 depicted inFIG. 9 provides a general architecture and functionality suitable for implementing functional elements described herein and/or portions of functional elements described herein. For example, thecomputer 900 provides a general architecture and functionality suitable for implementing one or more ofapplication 112,cloud resources 113,cloud resources 114, end user device 120, application datatransfer control system 130, one or more elements of cloud 310 1,write cache 312, one or more elements of cloud 310 2, readcache 314, one or more elements of cloud 310 3,disk 316,end user device 320, or the like. - It will be appreciated that the functions depicted and described herein may be implemented in software (e.g., via implementation of software on one or more processors, for executing on a general purpose computer (e.g., via execution by one or more processors) so as to implement a special purpose computer, and the like) and/or may be implemented in hardware (e.g., using a general purpose computer, one or more application specific integrated circuits (ASIC), and/or any other hardware equivalents).
- It is contemplated that some of the steps discussed herein as software methods may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various method steps. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and/or techniques described herein are invoked or otherwise provided. Instructions for invoking the inventive methods may be stored in fixed or removable media, transmitted via a data stream in a broadcast or other signal bearing medium, and/or stored within a memory within a computing device operating according to the instructions.
- It should be appreciated that the term “or” as used herein refers to a non-exclusive “or,” unless otherwise indicated (e.g., “or else” or “or in the alternative”).
- It should be appreciated that, although various embodiments which incorporate the teachings presented herein have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that still incorporate these teachings.
Claims (21)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/407,459 US20170193416A1 (en) | 2012-08-29 | 2017-01-17 | Reducing costs related to use of networks based on pricing heterogeneity |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/597,614 US20140067994A1 (en) | 2012-08-29 | 2012-08-29 | Reducing costs related to use of networks based on pricing heterogeneity |
US14/808,133 US9569742B2 (en) | 2012-08-29 | 2015-07-24 | Reducing costs related to use of networks based on pricing heterogeneity |
US15/407,459 US20170193416A1 (en) | 2012-08-29 | 2017-01-17 | Reducing costs related to use of networks based on pricing heterogeneity |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/808,133 Continuation US9569742B2 (en) | 2012-08-29 | 2015-07-24 | Reducing costs related to use of networks based on pricing heterogeneity |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170193416A1 true US20170193416A1 (en) | 2017-07-06 |
Family
ID=50189007
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/597,614 Abandoned US20140067994A1 (en) | 2012-08-29 | 2012-08-29 | Reducing costs related to use of networks based on pricing heterogeneity |
US14/808,133 Active US9569742B2 (en) | 2012-08-29 | 2015-07-24 | Reducing costs related to use of networks based on pricing heterogeneity |
US15/407,459 Abandoned US20170193416A1 (en) | 2012-08-29 | 2017-01-17 | Reducing costs related to use of networks based on pricing heterogeneity |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/597,614 Abandoned US20140067994A1 (en) | 2012-08-29 | 2012-08-29 | Reducing costs related to use of networks based on pricing heterogeneity |
US14/808,133 Active US9569742B2 (en) | 2012-08-29 | 2015-07-24 | Reducing costs related to use of networks based on pricing heterogeneity |
Country Status (1)
Country | Link |
---|---|
US (3) | US20140067994A1 (en) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103748858B (en) * | 2011-06-30 | 2018-10-26 | 瑞典爱立信有限公司 | Flexible data communication |
WO2014189481A1 (en) * | 2013-05-20 | 2014-11-27 | Empire Technology Development, Llc | Object migration between cloud environments |
US9680708B2 (en) | 2014-03-14 | 2017-06-13 | Veritas Technologies | Method and apparatus for cloud resource delivery |
US20150263980A1 (en) * | 2014-03-14 | 2015-09-17 | Rohini Kumar KASTURI | Method and apparatus for rapid instance deployment on a cloud using a multi-cloud controller |
US9660927B2 (en) * | 2015-04-22 | 2017-05-23 | Accedian Networks Inc. | Preemptive packet transmission |
US9733978B2 (en) * | 2015-08-27 | 2017-08-15 | Qualcomm Incorporated | Data management for multiple processing units using data transfer costs |
US10459657B2 (en) * | 2016-09-16 | 2019-10-29 | Hewlett Packard Enterprise Development Lp | Storage system with read cache-on-write buffer |
US10102856B2 (en) | 2017-01-20 | 2018-10-16 | Essential Products, Inc. | Assistant device with active and passive experience modes |
US11546296B2 (en) * | 2018-10-18 | 2023-01-03 | Bank Of America Corporation | Cloud computing architecture with secure multi-cloud integration |
US10635642B1 (en) * | 2019-05-09 | 2020-04-28 | Capital One Services, Llc | Multi-cloud bi-directional storage replication system and techniques |
US11032371B2 (en) | 2019-05-29 | 2021-06-08 | Red Hat, Inc. | Data migration using read function triggers |
US11146663B2 (en) * | 2019-07-18 | 2021-10-12 | EMC IP Holding Company LLC | Facilitating improved overall performance of remote data facility replication systems |
US11733986B2 (en) * | 2020-01-07 | 2023-08-22 | Chaitanya Kapadia | System for managing multiple clouds and method thereof |
US20220368765A1 (en) * | 2021-05-13 | 2022-11-17 | Agora Lab, Inc. | Universal Transport Framework For Heterogeneous Data Streams |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130117240A1 (en) * | 2010-05-03 | 2013-05-09 | Panzura, Inc. | Accessing cached data from a peer cloud controller in a distributed filesystem |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2820849B1 (en) | 2001-02-15 | 2003-05-16 | Cit Alcatel | COMPUTER DATA STORAGE METHOD AND CORRESPONDING STORAGE DEVICE |
US7113942B2 (en) * | 2003-06-27 | 2006-09-26 | Microsoft Corporation | Scalable storage and processing of hierarchical documents |
US7107403B2 (en) | 2003-09-30 | 2006-09-12 | International Business Machines Corporation | System and method for dynamically allocating cache space among different workload classes that can have different quality of service (QoS) requirements where the system and method may maintain a history of recently evicted pages for each class and may determine a future cache size for the class based on the history and the QoS requirements |
US7783852B2 (en) | 2003-11-26 | 2010-08-24 | Oracle International Corporation | Techniques for automated allocation of memory among a plurality of pools |
US20060075007A1 (en) | 2004-09-17 | 2006-04-06 | International Business Machines Corporation | System and method for optimizing a storage system to support full utilization of storage space |
US7971001B2 (en) | 2004-12-28 | 2011-06-28 | Sap Ag | Least recently used eviction implementation |
US20060174067A1 (en) * | 2005-02-03 | 2006-08-03 | Craig Soules | Method of caching data |
US8151094B2 (en) | 2005-12-30 | 2012-04-03 | Intel Corporation | Dynamically estimating lifetime of a semiconductor device |
US9361326B2 (en) * | 2008-12-17 | 2016-06-07 | Sap Se | Selectable data migration |
WO2010121330A1 (en) * | 2009-04-24 | 2010-10-28 | Aaron Antony Peapell | Data storage system |
US8407190B2 (en) | 2009-06-30 | 2013-03-26 | Commvault Systems, Inc. | Performing data storage operations with a cloud environment, including containerized deduplication, data pruning, and data transfer |
US8799413B2 (en) * | 2010-05-03 | 2014-08-05 | Panzura, Inc. | Distributing data for a distributed filesystem across multiple cloud storage systems |
US8984269B2 (en) * | 2011-02-28 | 2015-03-17 | Red Hat, Inc. | Migrating data among cloud-based storage networks via a data distribution service |
US8719627B2 (en) * | 2011-05-20 | 2014-05-06 | Microsoft Corporation | Cross-cloud computing for capacity management and disaster recovery |
US10878353B2 (en) * | 2011-05-31 | 2020-12-29 | Red Hat, Inc. | Automated cost assessment of cloud computing resources |
US9015708B2 (en) * | 2011-07-28 | 2015-04-21 | International Business Machines Corporation | System for improving the performance of high performance computing applications on cloud using integrated load balancing |
US9075811B2 (en) * | 2011-09-30 | 2015-07-07 | Symantec Corporation | Cloud information migration systems and methods |
-
2012
- 2012-08-29 US US13/597,614 patent/US20140067994A1/en not_active Abandoned
-
2015
- 2015-07-24 US US14/808,133 patent/US9569742B2/en active Active
-
2017
- 2017-01-17 US US15/407,459 patent/US20170193416A1/en not_active Abandoned
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130117240A1 (en) * | 2010-05-03 | 2013-05-09 | Panzura, Inc. | Accessing cached data from a peer cloud controller in a distributed filesystem |
Also Published As
Publication number | Publication date |
---|---|
US20150332191A1 (en) | 2015-11-19 |
US9569742B2 (en) | 2017-02-14 |
US20140067994A1 (en) | 2014-03-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9569742B2 (en) | Reducing costs related to use of networks based on pricing heterogeneity | |
US11349940B2 (en) | Server side data cache system | |
US11016749B1 (en) | Architecture for incremental deployment | |
US10489422B2 (en) | Reducing data volume durability state for block-based storage | |
US9792060B2 (en) | Optimized write performance at block-based storage during volume snapshot operations | |
US9983825B2 (en) | Efficient data volume replication for block-based storage | |
US10860245B2 (en) | Method and apparatus for optimizing data storage based on application | |
US20140115251A1 (en) | Reducing Memory Overhead of Highly Available, Distributed, In-Memory Key-Value Caches | |
CN107197359B (en) | Video file caching method and device | |
EP3161669B1 (en) | Memcached systems having local caches | |
CN114201421B (en) | Data stream processing method, storage control node and readable storage medium | |
CN104252466A (en) | Stream computing processing method, equipment and system | |
CN109714229B (en) | Performance bottleneck positioning method of distributed storage system | |
US20200320154A1 (en) | A webpage loading method, webpage loading system and server | |
CN114840140B (en) | Cloud data caching method, device, equipment and storage medium | |
CA2858081A1 (en) | Autonomous network streaming | |
WO2019041670A1 (en) | Method, device and system for reducing frequency of functional page requests, and storage medium | |
CN113806300A (en) | Data storage method, system, device, equipment and storage medium | |
US8549274B2 (en) | Distributive cache accessing device and method for accelerating to boot remote diskless computers | |
JPH07239808A (en) | Distributed data managing system | |
US10015012B2 (en) | Precalculating hashes to support data distribution | |
CN113490933A (en) | Distributed data processing | |
EP3745680B1 (en) | Apparatus and method for transmitting content | |
US8250177B2 (en) | Uncached data control in server-cached page | |
US12050534B1 (en) | Multi-tenant caching service in a hosted computing environment |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PUTTASWAMY NAGA, KRISHNA P.;KODIALAM, MURALI;VARVELLO, MATTEO;REEL/FRAME:040985/0023 Effective date: 20120920 |
|
AS | Assignment |
Owner name: PROVENANCE ASSET GROUP LLC, CONNECTICUT Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NOKIA TECHNOLOGIES OY;NOKIA SOLUTIONS AND NETWORKS BV;ALCATEL LUCENT SAS;REEL/FRAME:043877/0001 Effective date: 20170912 Owner name: NOKIA USA INC., CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNORS:PROVENANCE ASSET GROUP HOLDINGS, LLC;PROVENANCE ASSET GROUP LLC;REEL/FRAME:043879/0001 Effective date: 20170913 Owner name: CORTLAND CAPITAL MARKET SERVICES, LLC, ILLINOIS Free format text: SECURITY INTEREST;ASSIGNORS:PROVENANCE ASSET GROUP HOLDINGS, LLC;PROVENANCE ASSET GROUP, LLC;REEL/FRAME:043967/0001 Effective date: 20170913 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: NOKIA US HOLDINGS INC., NEW JERSEY Free format text: ASSIGNMENT AND ASSUMPTION AGREEMENT;ASSIGNOR:NOKIA USA INC.;REEL/FRAME:048370/0682 Effective date: 20181220 |
|
AS | Assignment |
Owner name: PROVENANCE ASSET GROUP LLC, CONNECTICUT Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKETS SERVICES LLC;REEL/FRAME:058983/0104 Effective date: 20211101 Owner name: PROVENANCE ASSET GROUP HOLDINGS LLC, CONNECTICUT Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CORTLAND CAPITAL MARKETS SERVICES LLC;REEL/FRAME:058983/0104 Effective date: 20211101 Owner name: PROVENANCE ASSET GROUP LLC, CONNECTICUT Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:NOKIA US HOLDINGS INC.;REEL/FRAME:058363/0723 Effective date: 20211129 Owner name: PROVENANCE ASSET GROUP HOLDINGS LLC, CONNECTICUT Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:NOKIA US HOLDINGS INC.;REEL/FRAME:058363/0723 Effective date: 20211129 |
|
AS | Assignment |
Owner name: RPX CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:PROVENANCE ASSET GROUP LLC;REEL/FRAME:059352/0001 Effective date: 20211129 |