Method for Implementing Multi-Tenant / Shared Redis Cluster Using Envoy

Abstract

The present invention relates to a method for implementing a multi-tenant / shared Redis cluster using Envoy. A system and method are disclosed that are associated with: at least one physical data storage instance adapted to contain electronic records; and a shared cluster platform coupled to the data storage, the shared cluster platform including: a computer processor, and a computer memory coupled to the computer processor, the computer memory storing instructions that, when executed by the computer processor, cause the shared cluster platform to: receive a request from a first tenant; select a physical data storage instance in response to the request; generate a first container for the first tenant, wherein the first container maps the first tenant to the selected physical data storage instance; generate a unique first key element for the first tenant; and send a first endpoint of the first container as a proxy for the selected physical data storage instance, wherein the sending implements the request. A variety of other embodiments are provided.

Description

Technical Field

[0001] The present invention relates to a method for implementing a multi-tenant / shared Redis cluster using Envoy (Envoy). Background Art

[0002] Remote Dictionary Server (Redis) is a fast, open-source (BSD-licensed) in-memory key-value database, cache, message broker, and queue. Redis is a data structure store that can provide and support data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperlogs, geospatial indexes, and streams. In short, Redis can simplify enterprise code writing by enabling enterprise developers to write fewer lines of code to store, access, and use data in enterprise applications. For example, if an application has data stored in a hashmap and the developer wants to store that data in a data store, the developer can simply use the Redis hash data structure to store the data. A Redis instance refers to a specific single installation of a Redis server with an associated memory storage.

[0003] Although Redis is an open-source database, typically enterprises ("service consumers") may prefer to use a managed version of Redis provided by a Platform as a Service (PaaS) provider ("PaaS provider") (such as WebServices ("AWS") or Azure). The Paa provider manages the provisioning (configuration, deployment, and management of IT system resources), patching, and other operations of Redis instances, while providing the convenience of enabling service consumers to simply access Redis instances via convenient network endpoints. The Paa provider may provide services that are not suitable for the service consumer's workload.

[0004] Therefore, it is desirable to provide the functionality of Redis in a manner that is more suitable for the consumer's workload. Summary of the Invention

[0005] Describes a system associated with a multi-tenant data store, the system including: at least one physical data store instance adapted to contain electronic records; and a shared cluster platform coupled to the data store, the shared cluster platform including: a computer processor, and a computer memory coupled to the computer processor, the computer memory storing instructions which, when executed by the computer processor, cause the shared cluster platform to: receive a request from a first tenant; in response to the request, select a physical data store instance; generate a first container for the first tenant, wherein the first container maps the first tenant to the selected physical data store instance; generate a unique first key element for the first tenant; and send a first endpoint of the first container as a proxy for the selected physical data store instance, wherein the sending implements the request.

[0006] Also describes a computer-implemented method associated with a multi-tenant data store, the method including: selecting a physical data store instance; generating a first container for a first tenant, wherein the first container maps the first tenant to the selected physical data store instance; generating a unique first key element for the first tenant; generating an authorization password for the first tenant; and sending a first endpoint of the first container as a proxy for the selected physical data store instance.

[0007] Also describes a non-transitory computer-readable medium having stored therein a method of executing executable instructions associated with a multi-tenant data store, the medium including: instructions for receiving a request from a first tenant; instructions for selecting a data store instance based on the request; instructions for generating a first container for the first tenant, wherein the first container maps the first tenant to the selected data store instance; instructions for generating a unique first key element for the first tenant; and instructions for sending a first endpoint of the first container as a proxy for the selected data store instance. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a high-level block diagram of a system according to some embodiments.

[0009] Figure 2 Illustrates a method of provisioning a physical data store instance according to some embodiments.

[0010] Figure 3 Illustrates a method of deprovisioning a physical data store instance according to some embodiments.

[0011] Figure 4 Illustrates a method of requesting data from a local data store instance according to some embodiments.

[0012] Figure 5 is regarding Figure 4 the method described.

[0013] Figure 6 is a device or platform according to some embodiments.

[0014] Figure 7 illustrates a database according to some embodiments.

[0015] Figure 8 illustrates a database according to some embodiments. Detailed Description

[0016] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the embodiments.

[0017] One or more specific embodiments of the present invention will be described below. To provide a concise description of these embodiments, not all features of an actual implementation may be described in the specification. It should be understood that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developer's specific goals (such as meeting system-related and business-related constraints), which may vary from one implementation to another. Additionally, it should be understood that such development efforts may be complex and time-consuming, but would still be a routine task of design, fabrication, and manufacture for those of ordinary skill in the art who have benefited from the present disclosure.

[0018] One or more embodiments or elements thereof may be implemented in the form of a computer program product that includes a non-transitory computer-readable storage medium having computer-usable program code for performing the method steps indicated herein. Further, one or more embodiments or elements thereof may be implemented in the form of a system (or device) that includes a memory and at least one processor, the at least one processor being coupled to the memory and operative to execute exemplary method steps. Still further, in other aspects, one or more embodiments or elements thereof may be implemented in the form of a device for performing one or more of the method steps described herein; the device may include: (i) hardware modules, (ii) software modules stored in a computer-readable storage medium (or multiple such media) and implemented on a hardware processor, or (iii) a combination of (i) and (ii); any of (i)-(iii) implements the specific techniques set forth herein.

[0019] An enterprise can use one or more applications as part of its computing infrastructure and can also use external organizations to meet its data persistence requirements. Specifically, an enterprise can use PaaS, which in turn can use Redis to meet data persistence. At least one of these applications may require storing its customers' source applications / data in an isolated manner. To this end, the enterprise can request a Redis instance for each customer. For example, the enterprise can store customer A's data on Redis instance ("instance") A and customer B's data on instance B. The first problem with provisioning an instance for each customer is that it takes approximately 20 minutes to provision or deprovision an instance. Thus, if customers provision / deprovision frequently, this process can take a significant amount of time. As used herein, the output of the provisioning process is that the endpoint coordinate of the instance is passed to the requester within a few seconds or other short amount of time. Once provisioned, all requests for data are read / write requests to the instance using the endpoint coordinate. As used herein, the terms "provision" and "onboarding" can be used interchangeably; and the terms "deprovision" and "offboarding" can be used interchangeably. However, it should be noted that the terms onboarding / offboarding are more often used in the context of customers, while provision / deprovision are more used in the context of Redis instances (e.g., when customer A onboards, we provision a logical Redis instance for that customer). The second problem with provisioning an instance for each customer is the cost of the actual instance. By dedicating an instance for each customer, as the customer base grows, the cost can spiral out of control.

[0020] In addition, PaaS providers typically offer various "tiers" or "plans" of managed Redis services to service consumers at varying prices based on the computing power of the "tier" and other service level agreement factors including but not limited to high availability, disaster recovery (DR) capabilities, etc. The PaaS provider can have a fixed set of these "tiers" predefined, which may or may not be suitable for the service consumer workload. Thus, the service consumer may be forced to choose a service tier that exceeds the needs of their application. For example, there may be a 6GB Redis instance, which may be too much for customer A, a good amount for customer B, and not enough for customer C. For an enterprise, the inability to choose the optimal instance size can be a challenge because this can translate into paying more money than is optimal for the workload of any given application.

[0021] Embodiments provide a shared cluster platform (e.g., a shared Redis cluster platform) to address these issues. In an embodiment, the shared cluster platform provides a shared / multi-tenant version of Redis instances by leveraging features supported by a protocol aware proxy while continuing to use the Redis service provided by a PaaS vendor in the background. As further described below, the shared cluster platform enables multiple tenants to share a single large data storage instance while maintaining isolation of customer / tenant data via a unique key element assigned to each tenant and attached to all data requests of that tenant. Embodiments provide benefits to applications of service consumers, including but not limited to the optimal use of data storage instances by using a single large shared data storage instance across multiple tenants and the opportunity to achieve a cost-optimal solution. Embodiments may also provide a physical data storage instance pre-created for an enterprise prior to requests from an application, such that the provisioning of a logical data storage instance can take seconds rather than minutes, thereby allowing for the "on the fly" provisioning of logical data storage instances. As used herein, a logical data storage instance is a proxy instance of a physical data storage instance, as the requesting application will contact the logical data storage instance rather than the physical data storage instance for data operations. Additionally, in scenarios where the physical data storage instance is not pre-created, the subsequent provisioning of logical data storage instances to each tenant can take seconds rather than minutes, in addition to the initial acquisition of the physical data storage instance.

[0022] Figure 1 is a high-level block diagram of a system architecture according to some embodiments. Embodiments are not limited to architecture 100.

[0023] Architecture 100 may include one or more service consumer applications 102 and a shared cluster platform 104. The service consumer applications 102 may send requests to the shared cluster platform 104. The service consumer applications 102 may include executable program code (e.g., compiled code, scripts, etc.) to receive queries from a user 105 and provide results to the user 105 based on electronic record data 106 stored in a Redis instance 108 ("physical data storage instance"). Architecture 100 also includes a service broker 110, a metadata repository 112, a coordinator 114, a container engine 116, and a Redis provider 118.

[0024] One or more service consumer applications 102 can communicate with the shared cluster platform 104 using Redis client libraries (including but not limited to IORedis, Jedis). These types of applications can use the application programming interfaces (APIs) provided by these Redis client libraries to manage and query data stored in the physical data storage instances 108.

[0025] The Redis provider 118 is a PaaS vendor and entity responsible for providing Redis instances as a service. Non-exhaustive examples of the Redis provider 118 are Web Services (“AWS”) and Azure.

[0026] The service broker 110 can be a software application responsible for accepting requests on behalf of the service consumer applications 102 to provision and de-provision data storage instances. The service broker 110 can act as a “middleman” between the service consumer applications 102 and the Redis provider 118 that provides the physical data storage instances 108. The instances provisioned to the service consumer applications 102 by the service broker 110 can be referred to herein as logical data storage instances 120.

[0027] The coordinator 114 is a software application responsible for evaluating the currently provisioned physical data storage instances 108 and determining whether additional physical data storage instances 108 need to be provisioned from the Redis provider 118. The coordinator 114 can also store data related to the current consumption / occupancy levels of the physical data storage instances 108 and the threshold levels 122 set by the service consumer applications. The coordinator 114 can use the stored data to select the physical data storage instances 108 on which to create the logical data storage instances 120, as described further below. The coordinator 114 can request additional physical data storage instances from the Redis provider 118 as needed, based on one or more preset threshold levels 122, or can de-provision / return physical data storage instances to the Redis provider 118 as needed.

[0028] The metadata store 112 can be a logical store accessible to the coordinator 114 and the service broker 110. The metadata store 112 can hold data for performing the processes described herein.

[0029] The container engine 116 can be an on-premise or in-cloud container orchestration engine that generates software containers 138. Non-exhaustive examples of the container engine are

[0030] According to some embodiments, devices including those associated with system architecture 100 and any other devices described herein can exchange information via any communication network, which can be one or more of the following: local area network (LAN), metropolitan area network (MAN), wide area network (WAN), private network, public switched telephone network (PSTN), wireless application protocol (WAP) network, Bluetooth network, wireless LAN network, and / or Internet protocol (“IP”) network, such as the Internet, intranet, or extranet. Note that any device described herein can communicate via one or more such communication networks.

[0031] Elements of system 100 can store information into and / or retrieve information from various data stores (e.g., metadata store 112), and the various data stores can be stored locally or reside remotely from the shared cluster platform 104. Although Figure 1 a single shared cluster platform 104 is shown, any number of such devices can be included. Additionally, the various devices described herein can be combined according to embodiments of the present invention. For example, in some embodiments, the service consumer application 102 and the service broker 110 can include a single device. Some or all of the functions of system 100 can be performed by a cluster of networked devices (such as in a distributed processing or cloud-based architecture).

[0032] According to any of the embodiments described herein, a user 105 (e.g., a database administrator) can access system 100 via a remote device (e.g., a personal computer (PC), tablet, or smartphone) to view information about and / or manage operational information. In some cases, an interactive graphical user interface display can allow an operator or administrator to define and / or adjust specific parameters (e.g., to set thresholds) and / or provide or receive automatically generated results from system 100.

[0033] Embodiments can provide a large shared multi-tenant version of a Redis instance that maintains the security of different tenants sharing the instance. Figure 2 and Figure 3 respectively illustrate methods of provisioning or de-provisioning a Redis instance according to some embodiments. The flowcharts described herein do not imply a fixed order of steps, and embodiments of the present invention can be practiced in any order that is practicable. Note that any method described herein can be performed by hardware, software, automated command scripts, or any combination of these methods. For example, a computer-readable storage medium can store instructions thereon that, when executed by a machine, perform according to any of the embodiments described herein. As another example, the shared cluster platform 104 can be adjusted to execute process 200 / 300 such that the processor 610 of system 100 (Figure 6 ) is a dedicated component configured to perform operations that cannot be performed by a general-purpose computer or device.

[0034] All processes mentioned herein can be performed by various hardware components and / or can be implemented by processor-executable program code read from one or more of non-transitory computer-readable media such as hard disk drives, floppy disks, CD-ROMs, DVD-ROMs, flash drives, flash memories, magnetic tapes, and solid-state random access memory (RAM) or read-only memory (ROM) storage units, and then stored in a compressed format, an uncompiled format, and / or an encrypted format. In some embodiments, hardwired circuitry may be used to replace the program code for implementing the processes according to some embodiments, or hardwired circuitry may be used in combination with the program code for implementing the processes according to some embodiments. Thus, embodiments are not limited to any specific combination of hardware and software.

[0035] Before process 200, the coordinator 114 requests one or more physical data storage instances 108 from the Redis provider 118. Physical data storage instances 108 may be allocated in response to the coordinator's request, where the coordinator 114 receives the endpoint address 124 (host name / IP address) to access the physical data storage instance 108. The endpoint addresses 124 of one or more physical data storage instances 108 (which together form a physical instance pool) may be stored in the metadata store ("pool") 126 of the shared cluster platform 104. In some embodiments, these physical data storage instances 108 may be created before the request of the service consumer application ("application") 102, while in other embodiments, the first physical data storage instance 108 may be created when the application requests an instance. The multiple created physical data storage instances 108 in the pool 126 may be based on the requirements of a particular application 102. The coordinator 114 may store configuration rule data 128 indicating the maximum number of logical data storage instances 120 that can be created on a given physical data storage instance 108. This maximum number may be referred to herein as "maxTenantsAllowed" 130.

[0036] Initially, at S210, the application 102 sends a request 132 to the service broker 110 for the logged-in tenant 504 ( Figure 5)Provide a new instance. Tenant 504 can be a physical customer or end user of a consumer application. As used herein, "onboarding" can refer to the process of adding a new tenant to the system such that they can access the data stored therein via a requesting application. It should be noted that in some instances, the customer may not directly access the data, but rather may call a function in the consuming application that, in turn, reads / writes data on behalf of the tenant to perform the requested function. After the onboarding process is complete, the tenant will be able to access (read and write) the instance.

[0037] Then, at S212, physical data storage instance 108 is selected. Upon receiving the request, service broker 110 sends a request to coordinator 114 to select a physical data storage instance 108 from pool 126. Coordinator 114 can select physical data storage instance 108 based on one or more configuration rules 128 stored at coordinator 114 and data stored at metadata store 112 indicating the number of tenants using a given physical data storage instance. Configuration rules 128 can be based on consumption or consumer application specific configurations such as the aforementioned "maxTensantsAllowed". In one or more embodiments, configuration rules 128 can be set by application 102 or any other suitable party. As a non-exhaustive example, configuration rules 128 can cause coordinator 114 to select the most consumed physical data storage instance 108 (i.e., the physical data storage instance 108 whose current number of logical data storage instances 120 is closest to "maxTenantsAllowed" 130) to optimize instance usage. Coordinator 114 applies the configuration rule 128 to the data stored at metadata store 112 to select physical data storage instance 108. The data stored at the metadata store indicates the current number of logical data storage instances on a given physical data storage instance. For example, if the rule is a maximum of ten tenants and a given physical data storage instance has ten tenants mapped to it, then coordinator 114 will select a different physical data storage instance for the next tenant making a request.

[0038] In S214, after the coordinator 114 selects the physical data storage instance 108, the coordinator 114 sends the selection to the service broker 110. Then, in S216, the service broker 110 creates a logical data storage instance 120 on the physical data storage instance 108 by requesting a corresponding container 138 for the tenant 504 from the container engine 116. The logical data storage instance 120 appears as the container 138. In S217, the container engine 116 generates the container 138. The inventors note that the container engine 116 can generate a container within seconds, making the provisioning of containers much faster than the provisioning of physical data storage instances. As described above, the logical data storage instance 120 is a proxy instance of the physical data storage instance 108 because the service consumer application 102 will contact the logical data storage instance rather than the physical data storage instance for data operations. Then, the logical data storage instance 120 can perform data operations by contacting the physical data storage instance 108. It should be noted that the advantage of this additional "layer" of routing requests via the logical data storage instance (i.e., via the container) is that the container provides an isolated portion for multi-tenancy. Each container has a unique password (unique key-prefix requirement for requests) that ensures tenant isolation. The container 138 can run a protocol-aware proxy server (such as Envoy, Twemproxy, or any other suitable protocol-aware proxy server) / an image of the Redis protocol-aware proxy server. The image can identify the software process running in the software container. In the non-exhaustive example described herein, the image will identify the Envoy proxy. The protocol-aware proxy container 138 can filter requests to the physical data storage instance 108 by applying routing rules to ensure that tenant data remains separate from the data of other tenants. Then, the service broker 110 stores the mapping of the logical data storage instance 120 / container 138 to the tenant 504.

[0039] Next, in S218, the service broker 110 generates a unique key element 134 for the tenant 504. The unique key element 134 can be a string generated by any suitable random / unique string generator. As a non-exhaustive example, the service broker 110 can use the library functions of any programming language to generate the string. The inventors note that it may be desirable to randomly generate the unique key element ("random string element") to enhance security and avoid others easily guessing or inadvertently using the unique key element. The unique key element 134 can be used by the application 102 as a key prefix coupled to all data requests related to a given tenant 504. The unique key element 134 can be generated for the tenant in a one-to-one relationship.

[0040] At S220, service broker 110 generates a second string that will be used as authorization password 136 by application 102 when accessing container 138. Authorization password 136 can also be a randomly generated string and can be generated in the same or different manner as unique key element 134. Service broker 110 can send unique key element 134 and authorization password 136 to application 102 and container engine 116. Application 102 can store the mapping between tenant 504 and the generated unique key element 134 and authorization password 136.

[0041] In one or more embodiments, container 138 can use instance proxy filter configuration 140, which maps tenant 504 to a selected physical data storage instance 108 with the generated unique key element 134 and authorization password 136. Instance proxy filter configuration 140 can also be configured with connection details of the selected physical data storage instance 108. Non-exhaustive examples of instance proxy filter configuration 140 are as follows:

[0042]

[0043] The above configuration 140 instructs the proxy in the container to forward all data requests with a specified key prefix (unique key element) and use the specified authorization password for the specified physical Redis cluster. Any requests with an incorrect key prefix and / or authorization password will be rejected. This effectively forces application 102 to use the key prefix (unique key element 134) and authorization password 136 and blocks access to any non-conforming requests.

[0044] Using the unique key element 134 and the authorization password 136 allows each tenant to "feel" that they have their own dedicated instance, because each tenant has a different logical data storage endpoint / container authorization password to access what is essentially a shared physical data storage instance. Using the unique key element 134 and the authorization password 136 can prevent data conflicts between different tenants and / or prevent tenants from accessing data that is not theirs. In other words, when tenants share a single physical data storage instance 108, assigning a unique key element 134 and an authorization password 136 to each tenant can keep the data isolated. For example, both tenant A and tenant B can use the key field "Name", and both tenants may want to enter a value for the "Name" field (e.g., for tenant A, "Name" = Bond; and for tenant B, "Name" = Smith). However, without using the unique key element and the authorization password, the value of tenant B may overwrite the value of tenant A because they use the same field in the shared physical data storage instance. Such an overwrite can be referred to as a "data conflict". Embodiments assign the unique key element 134 to a tenant for the tenant to use on all data requests to keep the data of a given tenant isolated from the data of other tenants. The unique key element 134 can be used as a prefix on data requests. Continuing with the above example, tenant A is assigned the unique key element 134 of ABC (prefix: "generated_KeyPrefix" = ABC), and the address to which the cluster identification data is forwarded. All of the operations in tenant A can use this prefix - ABC. To this end, the key value of the name key stored for tenant A is ABC_Name (ABC_Name) = Bond. The container 138 can enforce the key value 134 when the container 138 knows the address of the party making the request, and reject the operation if the tenant does not use the assigned unique key element 134 in data operations.

[0045] Return to process 200. At S222, service broker 110 sends the container connection endpoint 142 of container 138 (i.e., the host name / IP address) to application 102 as the endpoint of logical data storage instance 120 for the given tenant 504. The container connection endpoint 142 is a proxy for the endpoint of the selected physical data storage instance. It should be noted that in one or more embodiments, application 102 does not know the coordinates (host name / IP address) of physical data storage instance 108 and only knows the container connection endpoint 142. Note that application 102 also does not know the password of the physical data storage instance; instead, application 102 knows the coordinates and password of the container. The transmission of the container connection endpoint 142 can implement the login request 132. Then, at S224, application 102 stores the mapping between tenant 504 (including the allocated key element 134 and the authorization password 136) and the generated container connection endpoint 142. Since container 138 running the mirror of the proxy server knows the physical data storage instance 108 protocol, application 102 can continue to use any standard data storage instance client library while connecting to this container 138 running the mirror of the proxy server.

[0046] In one or more embodiments, service broker 110 may also store the mapping between the provisioned logical data storage instance 120, the physical data storage instance 108 to which it is mapped, and the information about the container connection endpoint generated for this logical data storage instance 120, as Figure 7 shown in table 700.

[0047] Process 200 can be repeated to provision additional containers 138 for tenant 504, where the additional containers 138 are mapped to the same physical data storage instance 108 or different physical data storage instances based on configuration rule 128.

[0048] In one or more embodiments, while process 200 is executing, the coordinator 114 can monitor in the background the mapping of tenant 504 to physical data storage instances 108 (i.e., monitor when logical data storage instances are created to evaluate the consumption / occupation level of physical data storage instances in the pool). In the case where the coordinator 114 determines that the occupation level of the physical data storage instance is greater than a preset threshold 122, the coordinator 114 can then provision additional physical data storage instances 108 from the Redis provider 118 or de-provision physical data storage instances 108 back to the Redis provider 118 and update the metadata store 112 accordingly. Such monitoring can ensure that the pool of physical data storage instances is maintained at an optimal level to serve future demands. As a non-exhaustive example, if the threshold 122 is 85%, such that when the number of logical data storage instances is greater than or equal to 85% of maxTenantsAllowed 130, the coordinator 114 will provision additional physical data storage instances.

[0049] Go to Figure 3 , a method 300 for de-provisioning logical data storage instances is provided.

[0050] Initially, at S310, the application 102 detects that the tenant 504 has logged out. Such detection can vary depending on the application. As a non-exhaustive example, the application can detect the logout in the case where the customer / end user unsubscribes from the application and / or deletes their account. Then, at S312, the application 102 sends a request 132 to the service broker 110 to de-provision the logical data storage instance 120. At S314, in response to receiving the request, the service broker 110 deletes the container 138 corresponding to the deleted logical data storage instance. Such deletion effectively severs the application 102 from the backing physical data storage instance 108. Next, at S316, the metadata store 112 is updated to reflect such deletion.

[0051] Similar to process 200, while process 300 is executing, the coordinator can monitor in the background the mapping of the tenant to the physical data storage instances 108 and can decide to delete / de-provision one or more physical data storage instances to ensure that the pool of physical data storage instances is maintained at an optimal level to serve future demands.

[0052] Go to Figure 4 and Figure 5 , a method 400 for how the application 102 accesses the physical data storage instance 108 is provided.

[0053] Initially, at S410, application 102 receives a request 506 for a data operation (i.e., read / write / delete / update operation). At S412, application 102 identifies the request as belonging to a given tenant 504a. Such identification may vary by application. As a non-exhaustive example, the identification may be based on information in the session, such as who logged into the session. As Figure 5 shown, multiple tenants (504a, 504b, and 504n) may each be mapped to corresponding containers 138a, 138b, and 138n, and all of these containers 138a, 138b, 138c are mapped to the same physical data storage instance 108. Then, at S414, application 102 obtains the container 138 connection details (connection endpoints, authorization passwords, unique key elements) corresponding to the tenant, which have been previously obtained and stored as Figure 7 table 700 in

[0054] Next, at S416, application 102 provides the authorization password 136 and the unique key element 134 to container 138. It should be noted that although both the authorization password 136 and the unique key element 134 are described as being provided at the same or substantially the same time at S416, in other embodiments, they may be provided sequentially, first providing the authorization password and, if approved, subsequently providing the key element. At S418, container 138 determines whether the authorization password 136 received from the consuming application matches the authorization password stored for the tenant in table 800 ( Figure 8 ).

[0055] In the case where container 138 determines at S418 that the authorization password 136 received from application 102 does not match the stored authorization password 836, the request for the data operation is rejected and process 400 ends at S420.

[0056] In the case where container 138 determines at S418 that the authorization password 136 received from application 102 matches the stored authorization password 836, process 400 continues to S422 and container 138 determines whether the received unique key element 134 matches the unique key element 834 stored for the tenant.

[0057] In the case where container 138 determines at S422 that the received unique key element 134 does not match the unique key element 834 stored for the tenant, the request for the data operation is rejected, the process returns to S420 and ends.

[0058] In the case where the container determines at S422 that the received unique key element 134 matches the unique key element 834 stored for the tenant, at S424, the container 138 forwards the data operation request to the physical data storage instance 108. Then, at S426, the physical data storage instance 108 performs the data operation. In the case of a write operation, the execution of the data operation causes the received data to be written to the physical data storage instance. In the case of a read operation, the execution of the data operation causes data to be retrieved from the physical data storage instance and returned to the application 102 via the container 138 and the service broker 110.

[0059] As described herein, embodiments provide for multiple tenants to share the same large physical data storage. However, the physical data storage instance may not restrict tenants to a specific amount of storage. For example, if the physical data storage instance is 6GB, the coordinator may set configuration rules such that up to 6 tenants may exist on each instance, with the idea that each tenant will have approximately 1GB of storage. The shared cluster platform 104 cannot enforce such usage of space between tenants because the physical data storage instance does not monitor such information. Thus, tenant A may use more storage than its allotted 1GB. To address this issue, one or more embodiments may include an expiration / eviction policy 144 stored by the coordinator 114 as part of the configuration rules 128. The expiration / eviction policy 144 may be set such that old data may be replaced by new data after a given amount of time. The expiration / eviction policy 144 may also use a policy such as LRU (Least Recently Used) to evict keys. For example, the expiration / eviction policy 144 may be set such that when the physical data storage instance is full, the next write operation arriving at the instance may cause the eviction of keys that are not frequently used. Then, the incoming write operation may use the space provided by the deleted / evicted keys. The expiration / eviction policy 144 may ensure that no tenant experiences an "out of memory" error and seemingly has unbounded memory. It should be noted that even though the evicted data in the physical data storage may not be available, the evicted data may persist in a more permanent data storage. Although embodiments may provide an expiration / eviction policy, the level of tenant isolation provided by the embodiments is more suitable for development and test scenarios than production scenarios because tenants may be reluctant to share a single large instance with other tenants in a production environment due to hard data storage requirements (i.e., the amount of storage the tenant needs to set), as described further below. However, the level of tenant isolation provided by the embodiments may also be suitable for production environments.

[0060] Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example, Figure 6 is possible, for example, in conjunction withFigure 1 Block diagram of an apparatus or platform 600 associated with system 100 (and / or any other system described herein). Platform 600 includes a processor 610 (such as one or more commercially available CPUs in the form of a single-chip microprocessor), which is coupled to a communication device 620 configured to communicate via a communication network (not shown in Figure 6 ). The communication device 620 can be used, for example, to communicate with one or more remote user platforms, tenant data sources, etc. Platform 600 also includes an input device 640 (e.g., a computer mouse and / or keyboard for inputting information about optimization preferences) and an output device 650 (e.g., a computer monitor for presenting a display, sending data, etc.). According to some embodiments, a mobile device and / or a PC can be used to exchange information with platform 600.

[0061] The processor 610 also communicates with a storage device 630. The storage device 630 can be implemented as a single database, or different components of the storage device 630 can be distributed using multiple databases (i.e., different deployment information storage options are possible). The storage device 630 can include any suitable information storage device, including a combination of magnetic storage devices (e.g., hard disk drives), optical storage devices, mobile phones, and / or semiconductor memory devices. The storage device 630 stores a program 612 and / or a shared cluster engine 614 for controlling the processor 610. The processor 610 executes the instructions of programs 612, 614 to operate according to any of the embodiments described herein. For example, the processor 610 can facilitate the automatic provisioning of a given physical data storage instance to multiple tenants.

[0062] Programs 612, 614 can be stored in a compressed format, an uncompiled format, and / or an encrypted format. Programs 612, 614 can also include other program elements, such as an operating system, a clipboard application, a database management system, and / or device drivers used by the processor 610 to interact with peripheral devices.

[0063] As used herein, information can be "received" or "sent" by, for example: (i) platform 600 from other devices; or (ii) a software application or module within platform 600 from other software applications, modules, or any other source, to, for example: (i) platform 600 from other devices; or (ii) a software application or module within platform 600 from other software applications, modules, or any other source.

[0064] In some embodiments (such as the embodiments shown in Figure 6 ), the storage device 630 also stores an application table data store 700 ( Figure 7 ) and a container mapping data store 800 ( Figure 8 ). Now, it will be described forFigure 7 and Figure 8 Examples of databases that can be used in conjunction with platform 600 are described in detail. Note that the databases described herein are only two examples, and additional and / or different information may be stored therein. In addition, various databases can be split or combined according to any of the embodiments described herein.

[0065] Refer to Figure 7 , which shows a table representing an application connection details table 700 that can be stored at platform 600 according to some embodiments. The table can include, for example, entries identifying the tenants that are provisioned to physical data storage instances. The table can also define fields 702, 704, 706, 708, 710 for each of the entries. According to some embodiments, fields 702, 704, 706, 708, 710 can specify: logical data storage instance 702, container endpoint 704, key element identifier 706, authorization password identifier 708, and physical data storage instance 710. The application connection table data store 700 can be created and updated, for example, when a new tenant is provisioned / deprovisioned, etc.

[0066] The key element 706 and the authorization password 708 can be unique alphanumeric tags or links associated with a particular "tenant" in a multi-tenant shared cluster computing architecture that enables tenants to share the same physical Redis instance. The data of each tenant can be isolated and kept invisible to other tenants. The logical instance identifier 702 can represent the logical instance created for the tenant. The container endpoint 704 can represent the endpoint coordinates of the container assigned to the tenant. The physical data storage instance 710 can represent the physical data storage instance shared by the tenant.

[0067] Refer to Figure 8 , which shows a table representing a container tenant table 800 that can be stored at platform 600 according to some embodiments. The table can include, for example, entries identifying the tenants that are provisioned to physical data storage instances. The table can also define fields 834, 836, and physical data storage instance 808 for each of the entries. According to some embodiments, fields 834, 836, and 808 can specify: key element identifier 834, authorization password identifier 836, and physical data storage instance 808. The container tenant table data store 800 can be created and updated, for example, when a new tenant is provisioned / deprovisioned, etc.

[0068] The key element 834 and the authorization password 836 can be unique alphanumeric tags or links associated with a particular "tenant" in a multi-tenant shared cluster computing architecture that enables tenants to share the same physical Redis instance. The data of each tenant can be isolated and kept invisible to other tenants. The physical data storage instance 808 can represent the physical data storage instance shared by the tenant.

[0069] In this way, embodiments can facilitate the ability to use physical Redis instances provided by a PaaS provider in a shared / multi-tenant manner in an efficient and accurate way. Embodiments can provide an optimal use of the Redis service provided by the PaaS provider in terms of both capacity and cost by mapping each tenant to a logical Redis instance rather than a physical Redis instance.

[0070] Embodiments can also improve the provisioning time of data storage instances and provide a satisfactory level of "tenant isolation". Additionally, the various embodiments described herein can provide improvements in productivity, efficiency, and quality.

[0071] The claims illustrate various additional embodiments of the present invention. These do not constitute a limitation of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to a variety of other embodiments. Additionally, although the above claims have been briefly described for clarity, those skilled in the art will understand how to make changes to the apparatus and methods recited in the claims, as necessary, to adapt to these and other embodiments and applications.

[0072] Although specific hardware and data configurations have been described herein, it should be noted that according to some embodiments of the present invention, any number of other configurations may be provided (e.g., some information associated with the databases described herein may be combined or stored in an external system).

[0073] For illustrative purposes only, the present invention has been described with respect to several embodiments. Those skilled in the art will recognize from this description that the present invention is not limited to the described embodiments, but may be practiced with modifications and changes defined only by the spirit and scope of the appended claims.

Claims

1. A system associated with multi-tenant data storage, comprising: At least one physical data storage instance suitable for containing electronic records; And A shared cluster platform coupled to the data storage, including: A computer processor, and A computer memory coupled to the computer processor, the computer memory storing instructions which, when executed by the computer processor, cause the shared cluster platform to: Receive a request from a first tenant; In response to the request, select a physical data storage instance; Generate a first container for the first tenant, wherein the first container maps the first tenant to the selected physical data storage instance; Generate a unique first key element for the first tenant; and Send a first endpoint of the first container as a proxy for the selected physical data storage instance, wherein the sending implements the request.

2. The system according to claim 1, wherein, The first key element is sent with each data request of the first tenant.

3. The system according to claim 1, wherein, The first tenant is a user of an application suitable for receiving the first endpoint of the sent first container.

4. The system according to claim 1, further comprising instructions for: generating an authorization password for a first tenant; and sending the authorization password and a first key element.

5. The system according to claim 1, further comprising instructions for: receiving a second request from a second tenant; selecting a physical data storage instance mapped to the first tenant in response to the request; Generate a second container for a second tenant, wherein the second container maps the second tenant to the selected physical data storage instance; Generate a unique second key element for the second tenant; and Send a second endpoint of the second container as a proxy for the selected physical data storage instance, wherein the sending implements the second request.

6. The system according to claim 1, wherein, The physical data storage instance is received from a data storage provider.

7. The system according to claim 6, further comprising instructions for: requesting a second physical data storage instance from a data storage provider when a threshold is met.

8. The system according to claim 1, wherein, The first endpoint is the host name and Internet Protocol (IP) address of the first container.

9. The system according to claim 1, wherein, The unique first key element is a random string.

10. A computer-implemented method associated with multi-tenant data storage, comprising: Select a physical data storage instance; Generate a first container for the first tenant, wherein the first container maps the first tenant to the selected physical data storage instance; Generate a unique first key element for the first tenant; Generate an authorization password for the first tenant; and Send a first endpoint of the first container as a proxy for the selected physical data storage instance.

11. The computer-implemented method according to claim 10, wherein, The first key element is sent with each data request of the first tenant.

12. The computer-implemented method according to claim 10, further comprising: Send the authorization password and the first key element.

13. The computer-implemented method according to claim 10, further comprising: Receive a request from a second tenant; Select the physical data storage instance mapped to the first tenant; Generate a second container for the second tenant, wherein the second container maps the second tenant to the selected physical data storage instance; Generate a unique second key element for the second tenant; Send a second endpoint of the second container as a proxy for the selected physical data storage instance, wherein the sending implements the request.

14. The computer-implemented method according to claim 10, wherein, The physical data storage instance is received from a data storage provider.

15. The computer-implemented method according to claim 14, further comprising: Request a second physical data storage instance from the data storage provider when a threshold is met.

16. The computer-implemented method according to claim 10, wherein, The first endpoint is the host name and Internet Protocol (IP) address of the first container.

17. The computer-implemented method according to claim 10, wherein, The unique first key element is a random string.

18. A non-transitory computer-readable medium having executable instructions stored therein for performing a method associated with multi-tenant data storage, the medium comprising: Instructions for receiving a request from a first tenant; Instructions for selecting a data storage instance based on the request; Instructions for generating a first container for a first tenant, wherein the first container maps the first tenant to the selected data storage instance; Instructions for generating a unique first key element for a first tenant; and Instructions for sending a first endpoint of the first container as a proxy for the selected data storage instance.

19. The medium according to claim 18, further comprising: Instructions for receiving a second request from a second tenant; Instructions for selecting the physical data storage instance mapped to the first tenant; Instructions to generate a second container for a second tenant, where the second container maps the second tenant to a selected physical data storage instance; Instructions to generate a unique second key element for the second tenant; and Instructions to send a second endpoint of the second container as a proxy for the selected physical data storage instance, where the sending implements the second request.

20. The medium according to claim 18, wherein, The first endpoint is the host name and Internet Protocol (IP) address of the first container.

Images